A comprehensive reverse engineering analysis of the Akira ransomware variant
This repository contains a comprehensive technical analysis of the Akira ransomware variant, conducted through deep reverse engineering using Ghidra, Frida, and x64dbg. The analysis spans 8,930+ lines of technical documentation with 69 professional diagrams covering every aspect of the malware's operation.
Critical Vulnerabilities Identified:
- Nonce Reuse Vulnerability - Same ChaCha20 key+nonce used across multiple files per thread, enabling XOR-based plaintext recovery
- Case-Sensitivity Bypass - Blacklist filtering uses case-sensitive comparison, allowing "WINDOWS" vs "Windows" bypass
- Weak RNG Implementation - Time-based random number generation with 30-60% recovery success rate in VM environments
Attack Characteristics:
- Encryption Speed: 17 MB/s average, 35 MB/s peak throughput
- Success Rate: 98.5% (9,850 of 10,000 files encrypted)
- Attack Duration: ~50 minutes for 50 GB dataset
- Business Impact: $160K-$710K+ per successful attack
Detection Windows:
- T+0-10s (CRITICAL): 100% file recovery possible
- T+10-300s (HIGH): 70% file recovery possible
- T+300-1500s (MEDIUM): 25-70% file recovery possible
- T+3000s (LOW): Shadow copy deletion prevention only
akira-ransomware-analysis/
├── README.md (this file)
├── docs/
│ ├── technical/ # Complete phase-by-phase analysis
│ ├── findings/ # Vulnerability reports and IOCs
│ └── visualizations/ # Diagram exports (SVG/PNG)
├── yara-rules/ # Detection signatures
└── scripts/ # Analysis utilities
-
Binary & Static Analysis (2,000+ lines)
- Binary characteristics, PE structure, imports/exports
- Startup sequence and initialization
- Main function architecture and control flow
- Command-line interface and configuration
- Complete function reference (25+ functions)
-
Cryptography Analysis (3,000+ lines)
- ChaCha20 stream cipher implementation
- RSA-2048 public key analysis
- Session key generation and RNG analysis
- CRITICAL: Weak time-based RNG vulnerability (CVSS 9.1)
- Attack vectors and decryption feasibility
- Complete cryptographic function reference (22+ functions)
-
Threading & Execution (3,000+ lines)
- Dual thread pool architecture (ASIO library)
- Thread allocation algorithm (30/10/60 split)
- Synchronization mechanisms (critical sections, condition variables)
- Producer-consumer pattern and task queue system
- Drive enumeration and directory traversal
- File filtering system (5 extensions, 11 directories, 13 processes)
- CRITICAL: Restart Manager process termination
- Complete threading function reference (40+ functions)
-
Encryption Strategy & Operational Model (3,000+ lines)
- Three encryption modes (Full, Part, Spot)
- 512-byte footer structure (byte-accurate)
- CRITICAL: NO network communication (fire-and-forget design)
- Victim registration model (pre-configured credentials)
- Data exfiltration strategy (separate tools)
- Anti-analysis assessment (minimal evasion)
- Post-encryption actions (shadow copy deletion only)
- Decryption mechanism analysis
- Recovery possibilities (30-60% for VMs with weak RNG exploit)
- Complete attack timeline (T-30 days to T+7 days)
- Comparison to ransomware families (LockBit, BlackCat, Conti, REvil)
- Detection and prevention strategies (YARA + EDR rules)
- Incident response guidance
- Vulnerability Reports - CVSS scores, exploitation details
- Indicators of Compromise - File, network, and behavioral IOCs
- YARA Detection Rules - Signature-based detection
Execution Phases:
- Logging Initialization (T+0.000s - T+0.012s) - 12ms
- CLI Argument Parsing (T+0.012s - T+0.024s) - 12ms
- Argument Validation (T+0.024s - T+0.071s) - 47ms
- Subsystem Initialization (T+0.071s - T+0.116s) - 45ms ← RSA key parsing bottleneck
- Drive Enumeration (T+0.116s - T+0.166s) - 50ms
- Encryption Campaign (T+0.166s - T+3000s) - 99.9% of total time
- Post-Encryption (T+3000s - T+3002s) - Shadow copy deletion + ransom note
Threading Model:
- Folder Parser Threads: 2-4 threads (ASIO pool #1)
- Encryption Worker Threads: 6-12 threads (ASIO pool #2)
- Synchronization: Single CRITICAL_SECTION mutex + 2 condition variables
- Task Queue: 288-byte task_t structures, 2 billion task limit (backpressure)
ChaCha20 Custom Variant:
Standard ChaCha20 + Custom modifications:
1. S-box substitution (256-byte lookup table)
2. Galois Field GF(2^8) multiplication
3. Modified quarter-round function
4. 20 rounds (standard)
Key: 32 bytes (256-bit)
Nonce: 16 bytes (128-bit) ⚠️ REUSED PER THREAD
Block size: 64 bytes
RSA-2048 Key Encryption:
Public key: 256 bytes (DER format @ 0x1400fa080)
Padding: OAEP with SHA-256
Session key encryption: 32 → 256 bytes
Nonce encryption: 16 → 256 bytes
Footer structure: 512 bytes total
File Footer Structure (512 bytes @ 0x1400b7010):
Offset | Size | Field
-------|------|------------------
0x000 | 8 | Magic ("AKIRA!!!" or similar)
0x008 | 256 | RSA(ChaCha20 session key)
0x108 | 256 | RSA(ChaCha20 nonce)
0x208 | n | Metadata (original size, timestamp, etc.)
Throughput Analysis (50 GB dataset):
- Files processed: 10,000 files
- Files encrypted: 9,850 (98.5% success rate)
- Files skipped: 150 (1.5% - locked, system files, errors)
- Average file size: 5.24 MB
- Total time: 2,834 seconds (47.2 minutes)
- Average throughput: 17 MB/s
- Peak throughput: 35 MB/s
Resource Utilization:
- CPU: 91% sustained (across all cores)
- Disk: 100% saturation ← PRIMARY BOTTLENECK
- Memory: 53-82 MB (depends on task queue depth)
- Threads: 8-16 active (2-4 parsers + 6-12 workers)
Performance Breakdown:
- ChaCha20 encryption: 70% of CPU time
- Disk I/O: 25% of total time
- RSA operations: 3% of CPU time
- Other (filtering, queue management): 2%
Severity: CRITICAL CVE: N/A (malware) Impact: Plaintext recovery via XOR attack
Description: Each worker thread generates a single ChaCha20 key+nonce pair and reuses it for all files processed by that thread. Since ChaCha20 is a stream cipher, reusing the same key+nonce for multiple plaintexts allows XOR-based recovery.
Attack Vector:
Thread 1 encrypts:
File A: C1 = P1 ⊕ Keystream(key, nonce)
File B: C2 = P2 ⊕ Keystream(key, nonce) ← SAME KEYSTREAM
XOR attack:
C1 ⊕ C2 = (P1 ⊕ K) ⊕ (P2 ⊕ K) = P1 ⊕ P2
If P1 or P2 has known plaintext → recover other plaintext
Exploitation:
- Identify files encrypted by same thread (footer RSA ciphertext identical)
- Known plaintext attack (headers: PDF, DOCX, ZIP, etc.)
- Recover XOR of plaintexts:
C1 ⊕ C2 = P1 ⊕ P2 - Statistical analysis to recover full plaintexts
Remediation for Defenders:
- Attempt recovery on files with identical RSA-encrypted nonces in footer
- Focus on files with known headers (Office docs, PDFs, images)
Severity: HIGH Impact: System file encryption possible
Description: Directory blacklist uses case-sensitive string comparison. Windows filesystem is case-insensitive, but blacklist filtering is case-sensitive.
Bypass Example:
Blacklist: "Windows", "Program Files", "System Volume Information"
Bypassed by:
- C:\WINDOWS\system32\kernel32.dll ← "WINDOWS" ≠ "Windows"
- C:\windows\notepad.exe ← "windows" ≠ "Windows"
- C:\PROGRAM FILES\app.exe ← "PROGRAM FILES" ≠ "Program Files"
Impact:
- Critical system files may be encrypted
- System instability/boot failure possible
- Increased damage beyond data loss
Detection:
- Monitor for encryption of uppercase/lowercase variants of system directories
Severity: MEDIUM Impact: Partial key recovery possible (30-60% success in VMs)
Description: Random number generation uses time-based seeding, making it partially predictable in controlled environments (VMs, sandboxes).
Exploitation:
- VM snapshot → execute malware → record encryption timestamp
- Revert snapshot → replay with same timestamp
- 30-60% success rate for RNG prediction in VMs
- Lower success (5-10%) on physical hardware with high-resolution timers
Remediation:
- Attempt key recovery if exact execution timestamp known
- Most viable in VM/sandbox environments
See yara-rules/ directory for detection signatures.
Key Indicators:
- RSA public key DER structure @ 0x1400fa080
- Magic footer signature "AKIRA!!!" or variant
- Custom ChaCha20 S-box table (256 bytes)
- Specific thread pool initialization patterns
- Blacklist strings ("Windows", "Program Files", ".exe", ".dll", etc.)
Critical Detection Windows:
Window 1: Pre-Encryption (T+0-10s) - HIGHEST PRIORITY
- Process: akira.exe or similar name
- Behavior: Rapid thread creation (8-16 threads)
- Registry: No persistence (single-run attack)
- Network: None (offline operation)
- Action: Immediate process termination → 100% file recovery
Window 2: Early Encryption (T+10-300s) - HIGH PRIORITY
- Behavior: Sustained 91% CPU usage across all cores
- Disk: 100% disk saturation (sequential write pattern)
- Files: Rapid .akira extension renames (35-70 files/sec)
- Action: Process termination → 70% file recovery
Window 3: Mid Encryption (T+300-1500s) - MEDIUM PRIORITY
- Behavior: Continued high CPU/disk usage
- Files: 30-75% of files already encrypted
- Action: Process termination → 25-70% file recovery
Window 4: Post-Encryption (T+3000s) - LOW PRIORITY
- Process: PowerShell spawned (shadow copy deletion)
- Command:
vssadmin delete shadows /all /quiet - Action: Block shadow copy deletion → preserve recovery option
File System:
- Mass file renaming to
.akiraextension - 512-byte footer appended to all encrypted files
- Ransom note:
akira_readme.txt(350 copies across filesystem) - Directory targeting (skips: Windows, Program Files, AppData, etc.)
Process Behavior:
- No persistence mechanism (registry, startup, services)
- No network communication (offline operation)
- Single-run execution model
- Restart Manager API calls (RmStartSession) for file locking
Performance:
- Sustained 91% CPU usage (all cores)
- 100% disk saturation
- 8-16 active threads
- 50-100 MB memory footprint
Extension: .akira
Ransom Note: akira_readme.txt
Footer Magic: "AKIRA!!!" (or variant, 8 bytes @ offset -512)
File Size Delta: +512 bytes (footer overhead)
RSA Public Key (DER, 256 bytes):
Address: 0x1400fa080 (typical)
Format: 30 82 01 0a 02 82 01 01 00 ... (DER structure)
ChaCha20 S-box (256 bytes):
Address: 0x1400b6e50 (typical)
Format: Custom substitution table
Task Queue Structure (288 bytes per task):
task_t @ heap allocation
Contains: file path, crypto context, metadata
Process Name: akira.exe (or variant)
Command Line: --path <target> (optional arguments)
Thread Count: 8-16 threads
API Calls:
- CryptGenRandom (key/nonce generation)
- CryptImportKey (RSA public key import)
- CreateThread (worker thread creation)
- FindFirstFileW / FindNextFileW (directory scanning)
- RmStartSession (Restart Manager - file unlocking)
-
Real-Time Behavioral Detection:
- Monitor for rapid thread creation (8-16 threads within 10 seconds)
- Alert on sustained 91% CPU usage + 100% disk saturation
- Detect mass file renaming patterns (.akira extension)
- Block PowerShell shadow copy deletion commands
-
File System Protection:
- Enable Controlled Folder Access (Windows Defender)
- Implement honeypot files in monitored directories
- Enable VSS (Volume Shadow Copy Service) with frequent snapshots
- Maintain offline backups (3-2-1 backup strategy)
-
Network Segmentation:
- Isolate critical file servers from workstations
- Implement least-privilege access controls
- Monitor lateral movement attempts
-
Endpoint Hardening:
- Disable PowerShell for non-administrative users
- Implement application whitelisting
- Enable tamper protection for security tools
If Akira Detected (T+0-10s):
- Immediately terminate process (100% recovery possible)
- Isolate affected system from network
- Preserve memory dump for forensic analysis
- Restore from last known-good backup
If Encryption In Progress (T+10-300s):
- Terminate process immediately (70% recovery possible)
- Identify encrypted vs unencrypted files (.akira extension)
- Restore encrypted files from backup
- Attempt nonce reuse exploitation for identical RSA footer files
If Encryption Complete (T+3000s+):
- Block shadow copy deletion (if not already executed)
- Preserve VSS snapshots for recovery
- Restore from backups (do not pay ransom)
- Conduct forensic analysis to determine entry vector
Static Analysis:
- Ghidra 11.4.2 - Disassembly, decompilation, and reverse engineering
- YARA - Signature-based malware detection
- Python 3.x - Automation scripts and analysis utilities
Dynamic Analysis:
- Frida - Runtime instrumentation and API hooking
- x64dbg - Windows debugger for behavioral analysis
Analysis Techniques:
- Static binary analysis (disassembly, decompilation)
- Data structure recovery (crypto_ctx_t, footer_t, task_t)
- Control flow analysis (7-phase execution model, 21-state FSM)
- Cryptographic algorithm identification (ChaCha20 variant, RSA-2048)
- Performance profiling (17.7 billion function calls analyzed)
- Visualization (69 diagrams: Mermaid, PlantUML, Graphviz, ASCII)
Time Investment:
- Phase 1-10: ~40 hours
- Phase 11: ~12 hours (function documentation)
- Phase 13: ~8 hours (visualizations)
- Total: ~60 hours
Documentation Output:
- Total lines: ~8,930 lines
- Functions documented: 19 critical functions
- Diagrams created: 69 professional diagrams
- Structures documented: 15+ key data structures
This is a completed research project. However, contributions are welcome for:
- Additional YARA rules
- EDR detection signatures
- Decryption tool development (nonce reuse exploitation)
- Automated analysis scripts
Please open an issue or pull request with your contributions.
IMPORTANT: This analysis is provided for educational, research, and defensive security purposes only. The information contained in this repository is intended to help security professionals:
- Understand Akira ransomware TTPs (Tactics, Techniques, Procedures)
- Develop detection and prevention mechanisms
- Improve incident response capabilities
- Conduct threat hunting and forensic analysis
DO NOT:
- Use this information to develop, enhance, or deploy malware
- Attempt to exploit vulnerabilities in production systems without authorization
- Distribute ransomware or malicious code
- Engage in any illegal activities
The authors and contributors are not responsible for any misuse of this information.
This research and documentation are released under the MIT License for educational and defensive security purposes.
See LICENSE file for details.
Research Organization: MottaSec Analysis Date: 2025-11-08 Tools: Ghidra, Python, Custom analysis scripts
Acknowledgments:
- Ghidra development team (NSA)
- Security research community
For questions or collaboration:
- Open an issue in this repository
- GitHub: https://github.com/MottaSec
- LinkedIn: https://www.linkedin.com/company/mottasec
- X (Twitter): https://x.com/mottasec_
Related Research:
- [Link to executive PDF report]
Last Updated: 2025-11-08 Repository Status: Complete Analysis Version: 1.0
| Document | Lines | Coverage | Key Findings |
|---|---|---|---|
| Binary & Static Analysis | 2,000+ | Phases 1-2 | PE structure, startup sequence, main architecture, CLI |
| Cryptography Analysis | 3,000+ | Phase 3 | ChaCha20, RSA-2048, Weak RNG (CVSS 9.1), attack vectors |
| Threading & Execution | 3,000+ | Phases 4-5 | ASIO pools, 30/10/60 split, file filtering, Restart Manager |
| Encryption Strategy | 3,000+ | Phases 6-10 | 3 modes, 512B footer, NO network, recovery (30-60% VMs) |
| Resource | Type | Purpose |
|---|---|---|
| Vulnerabilities | Report | CVSS scores, exploitation details |
| IOCs | Intelligence | File, network, behavioral indicators |
| YARA Rules | Detection | Signature-based detection rules |
| Analysis Scripts | Tools | Python utilities for analysis |
🔒 Akira Ransomware Analysis - Complete Technical Documentation