Add markdown wiki with 473 pages and zk browser
Generate interlinked wiki from master inventory: 397 tool pages, 15 workflow pages, 27 recipe pages, 33 category pages, plus index. All pages use [[wiki-links]] for cross-navigation between tools, workflows, recipes, and categories (1782 links total). Install zk for interactive browsing with fzf search, tag filtering, and backlink discovery. Add 'fhelp wiki' command and Makefile target. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
tobias
@@ -0,0 +1,65 @@
|
||||
# Android Malware Analysis
|
||||
> Analyze suspicious Android APK files using static and dynamic techniques available in REMnux.
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: APK Triage
|
||||
**Tools:** [[tools/file|file]], [[tools/apkid|apkid]]
|
||||
|
||||
Verify file type and check for packers/obfuscators. APKiD detects: known packers (DexGuard, Bangcle), obfuscators, anti-debug techniques.
|
||||
|
||||
```bash
|
||||
file specimen.exe
|
||||
```
|
||||
|
||||
### Step 2: Manifest Analysis
|
||||
**Tools:** [[tools/apktool|apktool]]
|
||||
|
||||
Decompile APK: apktool d <apk> -o output/. Examine AndroidManifest.xml for: excessive permissions, receivers, services, exported components, intent filters.
|
||||
|
||||
```bash
|
||||
apktool d <app.apk> -o output/
|
||||
```
|
||||
|
||||
### Step 3: Source Code Recovery
|
||||
**Tools:** [[tools/jadx|jadx]]
|
||||
|
||||
Decompile DEX to Java: jadx <apk> -d output/. Review source code for: C2 URLs, crypto operations, SMS interception, data exfiltration, root checks.
|
||||
|
||||
```bash
|
||||
jadx <app.apk> -d output/
|
||||
```
|
||||
|
||||
### Step 4: Static Analysis
|
||||
**Tools:** [[tools/androguard|androguard]], [[tools/droidlysis|droidlysis]]
|
||||
|
||||
androguard: analyze APK structure, permissions, activities. droidlysis: automated static analysis with IOC extraction. Check for: hardcoded keys, URLs, suspicious API usage.
|
||||
|
||||
```bash
|
||||
androguard analyze <app.apk>
|
||||
```
|
||||
|
||||
### Step 5: Native Library Analysis
|
||||
**Tools:** [[tools/strings|strings]], [[tools/radare2|radare2]]
|
||||
|
||||
If APK contains .so libraries: extract from lib/ directory. Analyze with strings and radare2. Native code often hides C2 logic and crypto.
|
||||
|
||||
```bash
|
||||
strings binary.exe
|
||||
r2 specimen.exe
|
||||
```
|
||||
|
||||
### Step 6: Dynamic Instrumentation
|
||||
**Tools:** [[tools/frida|frida]]
|
||||
|
||||
Hook suspicious functions at runtime: frida -U -l hook.js <package>. Intercept: crypto operations, network calls, file access, SMS operations.
|
||||
|
||||
```bash
|
||||
frida -l hook.js <process_name>
|
||||
```
|
||||
|
||||
### Step 7: Document Findings
|
||||
|
||||
Record: package name, permissions abused, C2 infrastructure, data exfiltrated, persistence mechanism, targeted user data (SMS, contacts, location).
|
||||
|
||||
#android #apk #mobile #frida #jadx #apktool #workflow
|
||||
@@ -0,0 +1,61 @@
|
||||
# Behavioral Analysis
|
||||
> Monitor runtime behavior in an isolated environment. Applicable to any executable or script on Linux (REMnux) or Windows.
|
||||
|
||||
**FOR610 Labs:** 1.2, 1.4, 1.6, 4.5
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: Environment Preparation
|
||||
|
||||
Revert to clean snapshot. Disconnect from production network. Verify isolation (host-only networking). Set max execution time (2-5 minutes).
|
||||
|
||||
### Step 2: Network Interception Setup
|
||||
**Tools:** [[tools/fakedns|fakedns]], [[tools/inetsim|inetsim]], [[tools/fakenet-ng|fakenet-ng]]
|
||||
|
||||
Start fake DNS and service emulation so malware gets responses. On REMnux: fakedns for DNS, INetSim or FakeNet-NG for HTTP/HTTPS/SMTP/FTP.
|
||||
|
||||
```bash
|
||||
fakedns
|
||||
inetsim
|
||||
fakenet
|
||||
```
|
||||
|
||||
### Step 3: Monitoring Setup
|
||||
**Tools:** [[tools/wireshark|wireshark]], [[tools/tcpdump|tcpdump]], [[tools/strace|strace]]
|
||||
|
||||
Start packet capture (wireshark or tcpdump). On Linux: strace/ltrace for syscalls. Start filesystem monitoring.
|
||||
|
||||
```bash
|
||||
wireshark
|
||||
tcpdump -i eth0 -w capture.pcap
|
||||
```
|
||||
|
||||
### Step 4: Emulation (Safe Alternative)
|
||||
**Tools:** [[tools/speakeasy|speakeasy]], [[tools/capa|capa]]
|
||||
|
||||
Before live execution, try emulation: speakeasy emulates Windows API calls on Linux safely. Use capa -vv for capability overview.
|
||||
|
||||
```bash
|
||||
speakeasy -t specimen.exe -o report.json 2> report.txt
|
||||
capa specimen.exe
|
||||
```
|
||||
|
||||
### Step 5: Execute & Monitor
|
||||
|
||||
Run the sample with a timeout. Monitor for: new processes spawned, files created/modified, network connections, DNS queries. Kill after 2-5 minutes.
|
||||
|
||||
### Step 6: Analyze Results
|
||||
**Tools:** [[tools/wireshark|wireshark]], [[tools/procdot|procdot]]
|
||||
|
||||
Review network capture: follow TCP streams, extract payloads, identify C2 patterns. Analyze process activity logs. Map filesystem changes.
|
||||
|
||||
```bash
|
||||
wireshark
|
||||
procdot
|
||||
```
|
||||
|
||||
### Step 7: Extract IOCs
|
||||
|
||||
Document: contacted domains/IPs, created files/registry keys, spawned processes, persistence mechanisms. Classify behavior: downloader, backdoor, ransomware, etc.
|
||||
|
||||
#behavioral #dynamic #monitoring #emulation #workflow
|
||||
@@ -0,0 +1,67 @@
|
||||
# Cobalt Strike Analysis
|
||||
> Analyze Cobalt Strike beacons, configurations, and network traffic using Didier Stevens' CS toolkit on REMnux.
|
||||
|
||||
**FOR610 Labs:** 3.4
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: Beacon Detection
|
||||
**Tools:** [[tools/yara|yara]], [[tools/capa|capa]]
|
||||
|
||||
Scan suspect file with YARA rules for CS signatures. capa detects 'receive data from C2' and beacon-like capabilities. Check for: characteristic 200KB+ size, sleep patterns.
|
||||
|
||||
```bash
|
||||
yara-rules specimen.bin
|
||||
capa specimen.exe
|
||||
```
|
||||
|
||||
### Step 2: Configuration Extraction
|
||||
**Tools:** [[tools/1768-py|1768-py]]
|
||||
|
||||
Parse beacon config: 1768.py <sample>. Extracts: C2 URLs, user-agent, beacon interval, watermark, spawn-to process, named pipes, proxy config.
|
||||
|
||||
```bash
|
||||
1768.py shellcode.bin
|
||||
```
|
||||
|
||||
### Step 3: Metadata Decryption
|
||||
**Tools:** [[tools/cs-decrypt-metadata-py|cs-decrypt-metadata-py]]
|
||||
|
||||
Decrypt beacon metadata from network captures: cs-decrypt-metadata.py <metadata>. Reveals: computer name, user, process info sent to team server.
|
||||
|
||||
```bash
|
||||
cs-decrypt-metadata.py <metadata_hex>
|
||||
```
|
||||
|
||||
### Step 4: Key Extraction
|
||||
**Tools:** [[tools/cs-extract-key-py|cs-extract-key-py]]
|
||||
|
||||
Extract encryption keys: cs-extract-key.py -f <process_dump>. Recovers AES and HMAC keys used for C2 communication encryption.
|
||||
|
||||
```bash
|
||||
cs-extract-key.py -f <process_dump>
|
||||
```
|
||||
|
||||
### Step 5: Traffic Decryption
|
||||
**Tools:** [[tools/cs-parse-traffic-py|cs-parse-traffic-py]]
|
||||
|
||||
Decrypt C2 traffic: cs-parse-traffic.py -f <pcap> -k <keys>. Reveals: tasking commands, downloaded payloads, exfiltrated data.
|
||||
|
||||
```bash
|
||||
cs-parse-traffic.py -f <capture.pcap> -k <keys_file>
|
||||
```
|
||||
|
||||
### Step 6: Sleep Mask Analysis
|
||||
**Tools:** [[tools/cs-analyze-processdump-py|cs-analyze-processdump-py]]
|
||||
|
||||
Analyze sleep mask: cs-analyze-processdump.py <dump>. Detects if beacon encrypts itself in memory during sleep. Useful for memory forensics.
|
||||
|
||||
```bash
|
||||
cs-analyze-processdump.py <process_dump>
|
||||
```
|
||||
|
||||
### Step 7: Document Findings
|
||||
|
||||
Record: C2 domains/IPs, beacon interval, watermark (operator ID), user-agent strings, named pipe patterns, spawn-to process, malleable C2 profile indicators.
|
||||
|
||||
#cobalt-strike #c2 #beacon #didier-stevens #threat-intel #workflow
|
||||
@@ -0,0 +1,74 @@
|
||||
# Code Injection Analysis
|
||||
> Identify and analyze process injection techniques including DLL injection, process hollowing, and reflective loading.
|
||||
|
||||
**FOR610 Labs:** 4.9, 5.4
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: Capability Detection
|
||||
**Tools:** [[tools/capa|capa]]
|
||||
|
||||
Run capa to identify injection techniques. Look for: 'inject code', 'create suspended process', 'allocate RWX memory'. Note MITRE ATT&CK technique IDs.
|
||||
|
||||
```bash
|
||||
capa specimen.exe
|
||||
```
|
||||
|
||||
### Step 2: Injection Type Classification
|
||||
**Tools:** [[tools/ghidra|ghidra]], [[tools/cutter|cutter]]
|
||||
|
||||
Identify which technique: Classic DLL injection (LoadLibrary), Process Hollowing (CreateProcess SUSPENDED + NtUnmapViewOfSection), Reflective DLL (manual PE loading), APC injection (QueueUserAPC).
|
||||
|
||||
```bash
|
||||
ghidra
|
||||
cutter specimen.exe
|
||||
```
|
||||
|
||||
### Step 3: Target Process Analysis
|
||||
**Tools:** [[tools/ghidra|ghidra]]
|
||||
|
||||
How does malware choose its target? Look for: CreateToolhelp32Snapshot + Process32First/Next (enumeration), hardcoded process names (svchost.exe, explorer.exe), OpenProcess calls.
|
||||
|
||||
```bash
|
||||
ghidra
|
||||
```
|
||||
|
||||
### Step 4: Payload Identification
|
||||
**Tools:** [[tools/ghidra|ghidra]]
|
||||
|
||||
What gets injected? Trace data flow to WriteProcessMemory or NtWriteVirtualMemory. Is it: embedded PE, shellcode, encrypted blob? Check size and content.
|
||||
|
||||
```bash
|
||||
ghidra
|
||||
```
|
||||
|
||||
### Step 5: Memory Allocation Analysis
|
||||
**Tools:** [[tools/ghidra|ghidra]]
|
||||
|
||||
Examine VirtualAllocEx parameters: size (hints at payload type), protection flags (PAGE_EXECUTE_READWRITE = 0x40 = suspicious). Allocation address for base relocation.
|
||||
|
||||
```bash
|
||||
ghidra
|
||||
```
|
||||
|
||||
### Step 6: Injection Verification [W]
|
||||
**Tools:** [[tools/x32dbg|x32dbg]], [[tools/x64dbg|x64dbg]]
|
||||
|
||||
Set breakpoint on WriteProcessMemory. When hit: examine lpBuffer (injected data), nSize (payload size). Dump the buffer to file for separate analysis.
|
||||
|
||||
### Step 7: Extracted Payload Analysis
|
||||
**Tools:** [[tools/peframe|peframe]], [[tools/capa|capa]], [[tools/strings|strings]]
|
||||
|
||||
Analyze the injected payload as standalone file. Route to: Static Analysis Workflow (if PE), Shellcode Workflow (if shellcode), .NET Workflow (if .NET assembly).
|
||||
|
||||
```bash
|
||||
peframe specimen.exe
|
||||
capa specimen.exe
|
||||
strings binary.exe
|
||||
```
|
||||
|
||||
### Step 8: Document Technique
|
||||
|
||||
Record: injection technique, target process criteria, payload type and hash, API call sequence, memory protection flags. Map to MITRE ATT&CK (T1055.x).
|
||||
|
||||
#code-injection #process-hollowing #dll-injection #reflective-loading #workflow
|
||||
@@ -0,0 +1,75 @@
|
||||
# Malicious Document Analysis
|
||||
> Analyze suspicious documents (PDF, Office, RTF, OneNote) for embedded malware, macros, and exploits. Follows Zeltser's 6-step methodology.
|
||||
|
||||
**FOR610 Labs:** 3.1, 3.3, 3.4, 3.5
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: Format Identification
|
||||
**Tools:** [[tools/file|file]], [[tools/trid|trid]]
|
||||
|
||||
Identify true format: OLE2 (legacy Office), OOXML (modern Office), RTF, PDF, OneNote. Don't trust the file extension — use magic bytes.
|
||||
|
||||
```bash
|
||||
file specimen.exe
|
||||
trid document.doc
|
||||
```
|
||||
|
||||
### Step 2: Structure Analysis
|
||||
**Tools:** [[tools/oledump-py|oledump-py]], [[tools/rtfdump-py|rtfdump-py]], [[tools/pdfid-py|pdfid-py]], [[tools/pdf-parser-py|pdf-parser-py]], [[tools/onedump-py|onedump-py]]
|
||||
|
||||
Parse document internals. For Office: oledump.py to list streams (M = macro). For PDF: pdfid.py for risky keywords (/JavaScript, /OpenAction). For RTF: rtfdump.py for hex-heavy groups.
|
||||
|
||||
```bash
|
||||
oledump.py document.docm
|
||||
rtfdump.py document.rtf
|
||||
pdfid.py document.pdf
|
||||
```
|
||||
|
||||
### Step 3: Password Handling (if encrypted)
|
||||
**Tools:** [[tools/msoffcrypto-tool|msoffcrypto-tool]]
|
||||
|
||||
If document is password-protected: msoffcrypto-tool -p <password> <input> <output>. Common passwords: infected, malware, password, 123456.
|
||||
|
||||
```bash
|
||||
msoffcrypto-tool -p infected <encrypted.docx> <decrypted.docx>
|
||||
```
|
||||
|
||||
### Step 4: Macro/Script Extraction
|
||||
**Tools:** [[tools/oledump-py|oledump-py]], [[tools/olevba|olevba]], [[tools/pcode2code|pcode2code]], [[tools/xlmmacrodeobfuscator|XLMMacroDeobfuscator]]
|
||||
|
||||
Extract VBA: oledump.py -s <stream> -v. For p-code: pcode2code. For Excel 4.0 macros: XLMMacroDeobfuscator. Check olevba for auto-execute triggers (AutoOpen, Document_Open).
|
||||
|
||||
```bash
|
||||
oledump.py document.docm
|
||||
olevba document.docm
|
||||
pcode2code <document.docm>
|
||||
```
|
||||
|
||||
### Step 5: Payload Decoding
|
||||
**Tools:** [[tools/base64dump-py|base64dump-py]], [[tools/translate-py|translate-py]], [[tools/gunzip|gunzip]], [[tools/numbers-to-string-py|numbers-to-string-py]], [[tools/cyberchef|cyberchef]]
|
||||
|
||||
Decode embedded payloads. Common chains: Base64 → gunzip → XOR. Use CyberChef for visual multi-step decoding. translate.py for byte-level transforms (byte ^ key).
|
||||
|
||||
```bash
|
||||
base64dump.py file.txt
|
||||
translate.py "byte ^ 35" < input.bin > output.bin
|
||||
gunzip -c compressed.gz > output.bin
|
||||
```
|
||||
|
||||
### Step 6: Embedded Object Analysis
|
||||
**Tools:** [[tools/scdbgc|scdbgc]], [[tools/xorsearch|xorsearch]], [[tools/yara|yara]], [[tools/1768-py|1768-py]]
|
||||
|
||||
If shellcode found: emulate with scdbgc. Scan for known patterns (YARA). Check for Cobalt Strike beacons (1768.py). Route PE payloads to Static Analysis Workflow.
|
||||
|
||||
```bash
|
||||
scdbgc /f shellcode.bin /s -1
|
||||
XORSearch -W -d 3 file.bin
|
||||
yara-rules specimen.bin
|
||||
```
|
||||
|
||||
### Step 7: Document IOCs
|
||||
|
||||
Record: embedded URLs, downloaded payload hashes, C2 addresses, macro behavior (what APIs called), exploit type (CVE if applicable).
|
||||
|
||||
#documents #office #pdf #rtf #macro #onenote #workflow
|
||||
@@ -0,0 +1,74 @@
|
||||
# .NET Malware Analysis
|
||||
> Analyze .NET malware using decompilation, debugging, and deobfuscation. Works for .NET Framework, .NET Core, and mixed-mode assemblies.
|
||||
|
||||
**FOR610 Labs:** 3.12, 4.8
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: Identification & Metadata
|
||||
**Tools:** [[tools/peframe|peframe]], [[tools/diec|diec]], [[tools/dnfile|dnfile]], [[tools/dotnetfile|dotnetfile]]
|
||||
|
||||
Confirm .NET binary (peframe shows 'CLR'). Check runtime version (.NET 2/4/Core). Use dnfile or dotnetfile for .NET-specific metadata. Note entry point and referenced assemblies.
|
||||
|
||||
```bash
|
||||
peframe specimen.exe
|
||||
diec specimen.exe
|
||||
```
|
||||
|
||||
### Step 2: Obfuscator Detection
|
||||
**Tools:** [[tools/diec|diec]], [[tools/de4dot|de4dot]]
|
||||
|
||||
Detect obfuscator: DIE identifies ConfuserEx, Eziriz .NET Reactor, Babel, etc. de4dot -d <sample> reports detected obfuscator without modifying the file.
|
||||
|
||||
```bash
|
||||
diec specimen.exe
|
||||
de4dot obfuscated.exe
|
||||
```
|
||||
|
||||
### Step 3: Decompilation
|
||||
**Tools:** [[tools/ilspycmd|ilspycmd]], [[tools/monodis|monodis]]
|
||||
|
||||
Decompile to C# source: ilspycmd <sample> > output.cs. On REMnux use ilspycmd (CLI). Examine: Main() entry, suspicious class/method names, embedded resources.
|
||||
|
||||
```bash
|
||||
ilspycmd assembly.exe > decompiled.cs
|
||||
```
|
||||
|
||||
### Step 4: Dynamic Loading Detection
|
||||
**Tools:** [[tools/visual-studio-code|visual-studio-code]]
|
||||
|
||||
Search decompiled code for: Assembly.Load(byte[]), Assembly.LoadFrom(), Activator.CreateInstance(), MethodInfo.Invoke(), CSharpCodeProvider. These indicate runtime code loading.
|
||||
|
||||
```bash
|
||||
code filename.js
|
||||
```
|
||||
|
||||
### Step 5: Deobfuscation
|
||||
**Tools:** [[tools/de4dot|de4dot]]
|
||||
|
||||
Run: de4dot <sample> -o <clean>. If de4dot fails: try with --dont-rename flag, or manually rename obfuscated symbols. For ConfuserEx: de4dot handles most variants.
|
||||
|
||||
```bash
|
||||
de4dot obfuscated.exe
|
||||
```
|
||||
|
||||
### Step 6: Dynamic Debugging [W]
|
||||
**Tools:** [[tools/dnspyex|dnspyex]]
|
||||
|
||||
If static analysis insufficient: load in dnSpyEx, set breakpoint on Assembly.Load or suspicious method. Run and inspect Locals window for decrypted payloads. Save byte[] arrays to disk.
|
||||
|
||||
### Step 7: Extracted Payload Analysis
|
||||
**Tools:** [[tools/ilspycmd|ilspycmd]], [[tools/peframe|peframe]]
|
||||
|
||||
Analyze extracted payload: is it another .NET assembly? (recurse this workflow). Is it a PE file? (route to Static Analysis). Document the unpacking chain.
|
||||
|
||||
```bash
|
||||
ilspycmd assembly.exe > decompiled.cs
|
||||
peframe specimen.exe
|
||||
```
|
||||
|
||||
### Step 8: Document Findings
|
||||
|
||||
Record: obfuscator type, .NET version, loading mechanism, payload hashes, C2 endpoints found in decompiled code, encryption keys/algorithms.
|
||||
|
||||
#dotnet #decompilation #deobfuscation #ilspy #de4dot #workflow
|
||||
@@ -0,0 +1,54 @@
|
||||
# Email & Phishing Analysis
|
||||
> Analyze suspicious email messages for phishing indicators, malicious attachments, and weaponized links.
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: Header Analysis
|
||||
**Tools:** [[tools/emldump-py|emldump-py]], [[tools/mail-parser|mail-parser]]
|
||||
|
||||
Parse SMTP headers: emldump.py <email.eml>. Check: Received headers (delivery path), Return-Path vs From (spoofing), SPF/DKIM results, X-Mailer.
|
||||
|
||||
```bash
|
||||
emldump.py message.eml
|
||||
python3 -c "import mailparser; mail = mailparser.parse_from_file('<email.eml>'); print(mail.subject)"
|
||||
```
|
||||
|
||||
### Step 2: Attachment Extraction
|
||||
**Tools:** [[tools/emldump-py|emldump-py]], [[tools/msg-extractor|msg-extractor]]
|
||||
|
||||
Extract attachments: emldump.py <email.eml> -d. For MSG format: msg-extractor <email.msg>. List all attachments with types and sizes.
|
||||
|
||||
```bash
|
||||
emldump.py message.eml
|
||||
extract_msg <email.msg>
|
||||
```
|
||||
|
||||
### Step 3: Attachment Triage
|
||||
**Tools:** [[tools/file|file]], [[tools/trid|trid]], [[tools/yara|yara]], [[tools/sha256sum|sha256sum]]
|
||||
|
||||
For each attachment: identify type, compute hash, scan with YARA. Route to appropriate workflow: Document Analysis (Office/PDF), Static Analysis (PE), JavaScript Deobfuscation (JS/HTML).
|
||||
|
||||
```bash
|
||||
file specimen.exe
|
||||
trid document.doc
|
||||
yara-rules specimen.bin
|
||||
```
|
||||
|
||||
### Step 4: Link Analysis
|
||||
**Tools:** [[tools/unfurl|unfurl]]
|
||||
|
||||
Extract all URLs from email body and headers. Use Unfurl to decompose URLs (reveal tracking pixels, redirect chains, encoded parameters).
|
||||
|
||||
```bash
|
||||
unfurl parse <url>
|
||||
```
|
||||
|
||||
### Step 5: Payload Analysis
|
||||
|
||||
Analyze extracted attachments using the appropriate workflow. Common patterns: Office doc with macro → downloads PE, PDF with link → credential harvester, HTML attachment → phishing page.
|
||||
|
||||
### Step 6: Document IOCs
|
||||
|
||||
Record: sender address and IP, subject line, attachment names and hashes, all URLs, C2/phishing domains, email infrastructure (mail server names).
|
||||
|
||||
#email #phishing #eml #msg #attachments #headers #workflow
|
||||
@@ -0,0 +1,57 @@
|
||||
# Java Malware Analysis
|
||||
> Analyze malicious Java archives (JAR), applets, and compiled classes. Covers decompilation and code analysis.
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: Archive Inspection
|
||||
**Tools:** [[tools/unzip|unzip]], [[tools/file|file]]
|
||||
|
||||
Extract JAR contents: unzip <file.jar> -d output/. Examine META-INF/MANIFEST.MF for Main-Class entry point. List all .class files.
|
||||
|
||||
```bash
|
||||
unzip -P infected sample.zip
|
||||
file specimen.exe
|
||||
```
|
||||
|
||||
### Step 2: Decompilation
|
||||
**Tools:** [[tools/cfr|cfr]], [[tools/jd-gui|jd-gui]]
|
||||
|
||||
Decompile with CFR: cfr <file.jar> --outputdir output/. Or use JD-GUI for visual browsing. CFR handles modern Java (lambdas, try-with-resources) better.
|
||||
|
||||
```bash
|
||||
cfr <file.jar> --outputdir output/
|
||||
jd-gui <file.jar>
|
||||
```
|
||||
|
||||
### Step 3: Multi-Decompiler Comparison
|
||||
**Tools:** [[tools/cfr|cfr]], [[tools/procyon|procyon]]
|
||||
|
||||
If one decompiler fails on a class: try Procyon. Compare outputs. Some obfuscators break specific decompilers while others handle them fine.
|
||||
|
||||
```bash
|
||||
cfr <file.jar> --outputdir output/
|
||||
```
|
||||
|
||||
### Step 4: Code Analysis
|
||||
**Tools:** [[tools/visual-studio-code|visual-studio-code]]
|
||||
|
||||
Review decompiled source. Search for: Runtime.exec() (command execution), URLConnection (network), Cipher (crypto), File I/O operations, reflection (Class.forName).
|
||||
|
||||
```bash
|
||||
code filename.js
|
||||
```
|
||||
|
||||
### Step 5: Resource Extraction
|
||||
**Tools:** [[tools/strings|strings]]
|
||||
|
||||
Extract embedded resources and strings. Check for: encoded payloads in resources, config files, embedded binaries. Base64-encoded content is common.
|
||||
|
||||
```bash
|
||||
strings binary.exe
|
||||
```
|
||||
|
||||
### Step 6: Document Findings
|
||||
|
||||
Record: entry point class, malicious methods, URLs/IPs, downloaded payloads, commands executed, Java version requirements.
|
||||
|
||||
#java #jar #decompilation #cfr #jd-gui #workflow
|
||||
@@ -0,0 +1,57 @@
|
||||
# JavaScript Deobfuscation
|
||||
> Deobfuscate and analyze malicious JavaScript from web pages, email attachments, or document macros.
|
||||
|
||||
**FOR610 Labs:** 3.6, 3.7
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: Beautification
|
||||
**Tools:** [[tools/js-beautify|js-beautify]]
|
||||
|
||||
Format minified/compressed JavaScript for readability. Look for: eval() calls, document.write(), String.fromCharCode(), unescape(), atob().
|
||||
|
||||
```bash
|
||||
js-beautify malicious.js > beautified.js
|
||||
```
|
||||
|
||||
### Step 2: Static Review
|
||||
**Tools:** [[tools/visual-studio-code|visual-studio-code]]
|
||||
|
||||
Identify obfuscation layers. Search for: eval/Function constructor (code execution), long encoded strings, variable name patterns (single chars = likely obfuscated).
|
||||
|
||||
```bash
|
||||
code filename.js
|
||||
```
|
||||
|
||||
### Step 3: Safe Execution (SpiderMonkey)
|
||||
**Tools:** [[tools/spidermonkey|spidermonkey]]
|
||||
|
||||
Execute outside browser with objects.js to simulate browser/WScript APIs. Command: js -f /usr/share/remnux/objects.js -f <script.js>. Captures eval'd code without running it.
|
||||
|
||||
```bash
|
||||
js -f malicious.js
|
||||
```
|
||||
|
||||
### Step 4: Environment Tuning
|
||||
**Tools:** [[tools/visual-studio-code|visual-studio-code]]
|
||||
|
||||
If script expects specific environment (location.href, navigator.userAgent): edit objects.js to provide expected values. Re-run SpiderMonkey.
|
||||
|
||||
```bash
|
||||
code filename.js
|
||||
```
|
||||
|
||||
### Step 5: Alternative Analysis
|
||||
**Tools:** [[tools/box-js|box-js]], [[tools/jstillery|jstillery]]
|
||||
|
||||
box-js: Node.js sandbox with WScript emulation. JStillery: AST-based deobfuscation. Use when SpiderMonkey can't handle the obfuscation.
|
||||
|
||||
```bash
|
||||
box-js --output-dir=/tmp suspicious.js
|
||||
```
|
||||
|
||||
### Step 6: Payload Identification
|
||||
|
||||
What does the deobfuscated JS do? Common patterns: download & execute (dropper), redirect to exploit kit, credential harvesting. Extract all URLs, IPs, file paths.
|
||||
|
||||
#javascript #deobfuscation #spidermonkey #box-js #web #workflow
|
||||
@@ -0,0 +1,79 @@
|
||||
# Memory Forensics
|
||||
> Analyze memory dumps to find malware artifacts, injected code, and hidden processes. Uses Volatility 3 framework on REMnux.
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: Image Identification
|
||||
**Tools:** [[tools/volatility3|volatility3]]
|
||||
|
||||
Determine OS and profile: vol3 -f <dump> windows.info (or linux.info). Verify image is valid and identify OS version, build, architecture.
|
||||
|
||||
```bash
|
||||
vol3 -f <memory_dump> windows.info
|
||||
```
|
||||
|
||||
### Step 2: Process Analysis
|
||||
**Tools:** [[tools/volatility3|volatility3]]
|
||||
|
||||
List processes: vol3 -f <dump> windows.pslist / windows.pstree. Look for: suspicious names, unusual parent-child relationships, processes with no window title, duplicate system processes.
|
||||
|
||||
```bash
|
||||
vol3 -f <memory_dump> windows.info
|
||||
```
|
||||
|
||||
### Step 3: Network Connections
|
||||
**Tools:** [[tools/volatility3|volatility3]]
|
||||
|
||||
List connections: vol3 -f <dump> windows.netscan. Identify: C2 connections, unusual ports, connections to known-bad IPs. Cross-reference with process PIDs.
|
||||
|
||||
```bash
|
||||
vol3 -f <memory_dump> windows.info
|
||||
```
|
||||
|
||||
### Step 4: Injection Detection
|
||||
**Tools:** [[tools/volatility3|volatility3]]
|
||||
|
||||
Detect injected code: vol3 -f <dump> windows.malfind. Shows: processes with executable memory not backed by a file. Dump suspicious regions for further analysis.
|
||||
|
||||
```bash
|
||||
vol3 -f <memory_dump> windows.info
|
||||
```
|
||||
|
||||
### Step 5: DLL Analysis
|
||||
**Tools:** [[tools/volatility3|volatility3]]
|
||||
|
||||
List loaded DLLs: vol3 -f <dump> windows.dlllist --pid <PID>. Look for: DLLs loaded from unusual paths (temp, appdata), unsigned DLLs, DLLs not in known-good baseline.
|
||||
|
||||
```bash
|
||||
vol3 -f <memory_dump> windows.info
|
||||
```
|
||||
|
||||
### Step 6: String Search
|
||||
**Tools:** [[tools/volatility3|volatility3]], [[tools/strings|strings]]
|
||||
|
||||
Search for known IOCs in memory: vol3 -f <dump> windows.strings. Also: strings <dump> | grep -i '<pattern>'. Look for URLs, domains, file paths, commands.
|
||||
|
||||
```bash
|
||||
vol3 -f <memory_dump> windows.info
|
||||
strings binary.exe
|
||||
```
|
||||
|
||||
### Step 7: Process & Code Dumping
|
||||
**Tools:** [[tools/volatility3|volatility3]]
|
||||
|
||||
Extract suspicious processes: vol3 -f <dump> windows.dumpfiles --pid <PID>. Extract injected code regions from malfind results. Analyze dumped files with Static Analysis Workflow.
|
||||
|
||||
```bash
|
||||
vol3 -f <memory_dump> windows.info
|
||||
```
|
||||
|
||||
### Step 8: Timeline Reconstruction
|
||||
**Tools:** [[tools/volatility3|volatility3]]
|
||||
|
||||
Build timeline: vol3 -f <dump> timeliner.Timeliner. Reconstruct: when malware started, what it did, lateral movement. Correlate with process tree and network data.
|
||||
|
||||
```bash
|
||||
vol3 -f <memory_dump> windows.info
|
||||
```
|
||||
|
||||
#memory #forensics #volatility #injection #incident-response #workflow
|
||||
@@ -0,0 +1,86 @@
|
||||
# Network Traffic Interception
|
||||
> Redirect and analyze malware network traffic in an isolated REMnux environment. Covers DNS, HTTP, HTTPS, and raw IP interception.
|
||||
|
||||
**FOR610 Labs:** 1.3, 1.7, 1.8
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: DNS Interception
|
||||
**Tools:** [[tools/fakedns|fakedns]]
|
||||
|
||||
Start fakedns to resolve ALL domains to REMnux IP. Verify: nslookup any-domain.com should return your REMnux IP.
|
||||
|
||||
```bash
|
||||
fakedns
|
||||
```
|
||||
|
||||
### Step 2: Service Emulation
|
||||
**Tools:** [[tools/inetsim|inetsim]], [[tools/fakenet-ng|fakenet-ng]], [[tools/httpd|httpd]]
|
||||
|
||||
Choose emulator based on needed protocols. INetSim: HTTP, HTTPS, DNS, FTP, SMTP (most complete). FakeNet-NG: similar but different engine. httpd: simple HTTP only.
|
||||
|
||||
```bash
|
||||
inetsim
|
||||
fakenet
|
||||
httpd
|
||||
```
|
||||
|
||||
### Step 3: TLS/HTTPS Interception (if needed)
|
||||
**Tools:** [[tools/mitmproxy|mitmproxy]], [[tools/polarproxy|polarproxy]]
|
||||
|
||||
For HTTPS C2: mitmproxy as transparent proxy, or PolarProxy for TLS decryption. Install proxy CA cert on analysis machine if needed.
|
||||
|
||||
```bash
|
||||
mitmproxy
|
||||
PolarProxy -p 443,80 -w captured.pcap
|
||||
```
|
||||
|
||||
### Step 4: Packet Capture
|
||||
**Tools:** [[tools/wireshark|wireshark]], [[tools/tcpdump|tcpdump]]
|
||||
|
||||
Start capture before executing malware. Filter: not arp and not broadcast. Save to PCAP for later analysis.
|
||||
|
||||
```bash
|
||||
wireshark
|
||||
tcpdump -i eth0 -w capture.pcap
|
||||
```
|
||||
|
||||
### Step 5: Execute & Observe
|
||||
|
||||
Run malware on analysis VM. Watch for: DNS queries (domain names), HTTP requests (URLs, user-agents), raw TCP connections (IP:port).
|
||||
|
||||
### Step 6: Traffic Analysis
|
||||
**Tools:** [[tools/wireshark|wireshark]], [[tools/tshark|tshark]], [[tools/ngrep|ngrep]], [[tools/tcpflow|tcpflow]]
|
||||
|
||||
Follow TCP streams for full request/response. Use ngrep for pattern search across packets. Use tcpflow to extract individual streams. Identify beaconing (regular intervals).
|
||||
|
||||
```bash
|
||||
wireshark
|
||||
tshark -r capture.pcap
|
||||
ngrep -I <capture.pcap> 'password'
|
||||
```
|
||||
|
||||
### Step 7: File Extraction
|
||||
**Tools:** [[tools/tcpxtract|tcpxtract]], [[tools/networkminer|networkminer]]
|
||||
|
||||
Carve files from PCAP: downloaded payloads, exfiltrated data, second-stage malware. NetworkMiner does this automatically.
|
||||
|
||||
```bash
|
||||
tcpxtract -f <capture.pcap> -o output/
|
||||
NetworkMiner --pcap <capture.pcap>
|
||||
```
|
||||
|
||||
### Step 8: IP-Based Redirection (if needed)
|
||||
**Tools:** [[tools/iptables|iptables]]
|
||||
|
||||
If malware uses hardcoded IPs (no DNS): iptables -t nat -A PREROUTING -i eth0 -j REDIRECT. This redirects ALL traffic to local services.
|
||||
|
||||
```bash
|
||||
iptables -t nat -A PREROUTING -i ens32 -j REDIRECT
|
||||
```
|
||||
|
||||
### Step 9: Document Network IOCs
|
||||
|
||||
Record: C2 domains/IPs, URI paths, user-agent strings, beacon intervals, downloaded file hashes, TLS certificate details.
|
||||
|
||||
#network #interception #c2 #dns #https #pcap #workflow
|
||||
@@ -0,0 +1,74 @@
|
||||
# Shellcode Analysis
|
||||
> Analyze extracted shellcode from documents, exploits, or injected processes. Covers detection, emulation, and payload identification.
|
||||
|
||||
**FOR610 Labs:** 3.4, 3.5, 4.6, 4.7
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: Shellcode Detection
|
||||
**Tools:** [[tools/xorsearch|xorsearch]], [[tools/yara|yara]], [[tools/capa|capa]]
|
||||
|
||||
Scan carrier file for shellcode patterns. XORSearch -W -d 3 <file> detects common shellcode signatures even when XOR-encoded. YARA rules catch known frameworks.
|
||||
|
||||
```bash
|
||||
XORSearch -W -d 3 file.bin
|
||||
yara-rules specimen.bin
|
||||
capa specimen.exe
|
||||
```
|
||||
|
||||
### Step 2: Extraction
|
||||
**Tools:** [[tools/rtfdump-py|rtfdump-py]], [[tools/oledump-py|oledump-py]], [[tools/pdf-parser-py|pdf-parser-py]]
|
||||
|
||||
Extract shellcode from carrier. For RTF: rtfdump.py -s <group> -H -d > sc.bin. For OLE: oledump.py -s <stream> -d > sc.bin. For PDF: pdf-parser.py -o <obj> -d sc.bin.
|
||||
|
||||
```bash
|
||||
rtfdump.py document.rtf
|
||||
oledump.py document.docm
|
||||
pdf-parser.py document.pdf -a
|
||||
```
|
||||
|
||||
### Step 3: Emulation
|
||||
**Tools:** [[tools/scdbgc|scdbgc]], [[tools/speakeasy|speakeasy]]
|
||||
|
||||
Emulate without execution. scdbgc /f sc.bin /s -1 shows API calls. speakeasy -t sc.bin -r -a x86 for deeper emulation. Look for: URL downloads, file writes, process creation.
|
||||
|
||||
```bash
|
||||
scdbgc /f shellcode.bin /s -1
|
||||
speakeasy -t specimen.exe -o report.json 2> report.txt
|
||||
```
|
||||
|
||||
### Step 4: Framework Identification
|
||||
**Tools:** [[tools/yara|yara]], [[tools/1768-py|1768-py]]
|
||||
|
||||
Check for known frameworks. 1768.py identifies Cobalt Strike beacons. YARA rules detect Metasploit, Cobalt Strike, custom frameworks. Document beacon config if found.
|
||||
|
||||
```bash
|
||||
yara-rules specimen.bin
|
||||
1768.py shellcode.bin
|
||||
```
|
||||
|
||||
### Step 5: Conversion to EXE
|
||||
**Tools:** [[tools/shcode2exe|shcode2exe]]
|
||||
|
||||
Convert shellcode to executable for static analysis: shcode2exe sc.bin sc.exe. Then analyze with peframe, strings, ghidra.
|
||||
|
||||
```bash
|
||||
shcode2exe <shellcode.bin> <output.exe>
|
||||
```
|
||||
|
||||
### Step 6: String & IOC Extraction
|
||||
**Tools:** [[tools/strings|strings]], [[tools/floss|floss]], [[tools/cyberchef|cyberchef]]
|
||||
|
||||
Extract strings from shellcode. Look for: C2 URLs, download paths, filename markers, encryption keys. Use CyberChef for encoded content.
|
||||
|
||||
```bash
|
||||
strings binary.exe
|
||||
floss specimen.exe
|
||||
cyberchef
|
||||
```
|
||||
|
||||
### Step 7: Document Findings
|
||||
|
||||
Record: shellcode offset in carrier, size, encoding/XOR key, framework (Metasploit/CS/custom), C2 address, downloaded payload URL, technique (staged/stageless).
|
||||
|
||||
#shellcode #emulation #cobalt-strike #metasploit #scdbg #workflow
|
||||
@@ -0,0 +1,84 @@
|
||||
# Static Properties Analysis
|
||||
> Systematic static examination of a suspicious file without executing it. Works for PE, ELF, .NET, scripts, and documents.
|
||||
|
||||
**FOR610 Labs:** 1.1, 2.1, 4.1
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: File Identification & Hashing
|
||||
**Tools:** [[tools/file|file]], [[tools/trid|trid]], [[tools/exiftool|exiftool]], [[tools/sha256sum|sha256sum]]
|
||||
|
||||
Determine file type using magic bytes. Compute hashes (MD5, SHA256) for lookup and documentation. Record file size and timestamps.
|
||||
|
||||
```bash
|
||||
file specimen.exe
|
||||
trid document.doc
|
||||
exiftool document.pdf
|
||||
```
|
||||
|
||||
### Step 2: Reputation Check
|
||||
**Tools:** [[tools/malwoverview|malwoverview]], [[tools/virustotal-search|virustotal-search]]
|
||||
|
||||
Look up hash on VirusTotal/MalwareBazaar. If known malware, note family name and detection rate. If clean or unknown, continue analysis.
|
||||
|
||||
```bash
|
||||
malwoverview -v <hash>
|
||||
```
|
||||
|
||||
### Step 3: Packing & Entropy Check
|
||||
**Tools:** [[tools/diec|diec]], [[tools/peframe|peframe]]
|
||||
|
||||
Check for packing indicators and high entropy sections. Look for: unusual section names, small import table, high entropy (>7.0). If packed, consider the Unpacking Workflow.
|
||||
|
||||
```bash
|
||||
diec specimen.exe
|
||||
peframe specimen.exe
|
||||
```
|
||||
|
||||
### Step 4: String Extraction
|
||||
**Tools:** [[tools/strings|strings]], [[tools/floss|floss]], [[tools/pestr|pestr]]
|
||||
|
||||
Extract readable strings. Use FLOSS for obfuscated/stack strings. Look for: URLs, IPs, domains, registry keys, file paths, error messages, API names.
|
||||
|
||||
```bash
|
||||
strings binary.exe
|
||||
floss specimen.exe
|
||||
pestr specimen.exe
|
||||
```
|
||||
|
||||
### Step 5: Capability Detection
|
||||
**Tools:** [[tools/capa|capa]], [[tools/yara|yara]]
|
||||
|
||||
Identify capabilities mapped to MITRE ATT&CK. Scan with YARA rules for known malware families. Look for: persistence, C2, evasion, lateral movement capabilities.
|
||||
|
||||
```bash
|
||||
capa specimen.exe
|
||||
yara-rules specimen.bin
|
||||
```
|
||||
|
||||
### Step 6: Import & Export Analysis
|
||||
**Tools:** [[tools/peframe|peframe]], [[tools/capa|capa]]
|
||||
|
||||
Examine imported DLLs and functions. Map imports to behavior categories: networking (ws2_32), crypto (advapi32), process manipulation (kernel32). Check exports for DLL functionality.
|
||||
|
||||
```bash
|
||||
peframe specimen.exe
|
||||
capa specimen.exe
|
||||
```
|
||||
|
||||
### Step 7: Disassembly (if needed)
|
||||
**Tools:** [[tools/ghidra|ghidra]], [[tools/cutter|cutter]], [[tools/radare2|radare2]]
|
||||
|
||||
Load into disassembler for code-level analysis. Start at entry point, trace key functions. Use decompiler for C-like view.
|
||||
|
||||
```bash
|
||||
ghidra
|
||||
cutter specimen.exe
|
||||
r2 specimen.exe
|
||||
```
|
||||
|
||||
### Step 8: Document Findings
|
||||
|
||||
Record IOCs: hashes, IPs, domains, file paths, registry keys, mutexes. Classify: malware family, capabilities, confidence level. Decide: continue to behavioral analysis?
|
||||
|
||||
#static #triage #pe-analysis #elf-analysis #workflow
|
||||
@@ -0,0 +1,62 @@
|
||||
# String & Data Deobfuscation
|
||||
> Decode obfuscated strings and data in malware. Covers XOR, Base64, stack strings, custom algorithms, and multi-layer encoding.
|
||||
|
||||
**FOR610 Labs:** 1.5, 5.2
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: Automated Extraction
|
||||
**Tools:** [[tools/floss|floss]], [[tools/strings|strings]]
|
||||
|
||||
Start with FLOSS for automatic deobfuscation (static + stack + decoded strings). Compare against plain strings output. FLOSS --no-static for only decoded strings.
|
||||
|
||||
```bash
|
||||
floss specimen.exe
|
||||
strings binary.exe
|
||||
```
|
||||
|
||||
### Step 2: Encoding Detection
|
||||
**Tools:** [[tools/xorsearch|xorsearch]], [[tools/bbcrack|bbcrack]]
|
||||
|
||||
Identify encoding algorithm. XORSearch: detect XOR with known plaintext (http:, MZ, This program). bbcrack: brute-force XOR, ROL, ADD at multiple levels.
|
||||
|
||||
```bash
|
||||
XORSearch -W -d 3 file.bin
|
||||
bbcrack -l 1 specimen.dll
|
||||
```
|
||||
|
||||
### Step 3: Single-Byte XOR Recovery
|
||||
**Tools:** [[tools/brxor-py|brxor-py]], [[tools/xortool|xortool]]
|
||||
|
||||
For single-byte XOR: brxor.py <file> finds English words. xortool <file> guesses key length and probable key. xortool-xor -s <key> -i <file> -o decoded.bin to decode.
|
||||
|
||||
```bash
|
||||
brxor.py specimen.dll
|
||||
xortool <encoded_file>
|
||||
```
|
||||
|
||||
### Step 4: Multi-Byte / Custom Decoding
|
||||
**Tools:** [[tools/translate-py|translate-py]], [[tools/cyberchef|cyberchef]]
|
||||
|
||||
For custom algorithms: translate.py 'byte ^ key' or complex expressions. CyberChef for visual recipe building (XOR → Base64 → Gunzip chains). Document the recipe.
|
||||
|
||||
```bash
|
||||
translate.py "byte ^ 35" < input.bin > output.bin
|
||||
cyberchef
|
||||
```
|
||||
|
||||
### Step 5: Stack String Recovery
|
||||
**Tools:** [[tools/strdeob-pl|strdeob-pl]], [[tools/floss|floss]]
|
||||
|
||||
For strings built on the stack (MOV byte-by-byte): strdeob.pl <file> or FLOSS stack string detection. Common in evasive malware to avoid string extraction.
|
||||
|
||||
```bash
|
||||
strdeob.pl specimen.exe
|
||||
floss specimen.exe
|
||||
```
|
||||
|
||||
### Step 6: Validation & IOC Extraction
|
||||
|
||||
Review decoded strings. Extract IOCs: C2 addresses, registry keys, file paths, API names, credentials. Compare against known malware family patterns.
|
||||
|
||||
#strings #xor #deobfuscation #floss #cyberchef #encoding #workflow
|
||||
@@ -0,0 +1,69 @@
|
||||
# Unpacking Packed Executables
|
||||
> Unpack compressed, encrypted, or obfuscated executables to reveal the original code. Covers automated and manual techniques.
|
||||
|
||||
**FOR610 Labs:** 4.1, 4.2, 4.3, 5.3, 5.8, 5.10
|
||||
|
||||
## Steps
|
||||
|
||||
### Step 1: Packing Identification
|
||||
**Tools:** [[tools/diec|diec]], [[tools/peframe|peframe]]
|
||||
|
||||
Identify packer: DIE detects UPX, ASPack, PECompact, Themida, etc. Check entropy (>7.0 suggests packing). Look for: few imports, unusual section names (.UPX, .packed).
|
||||
|
||||
```bash
|
||||
diec specimen.exe
|
||||
peframe specimen.exe
|
||||
```
|
||||
|
||||
### Step 2: Automated Unpacking
|
||||
**Tools:** [[tools/upx|upx]], [[tools/de4dot|de4dot]]
|
||||
|
||||
Try known unpackers first. UPX: upx -d <sample>. .NET: de4dot <sample>. If automated unpacking fails (modified packer), proceed to manual.
|
||||
|
||||
```bash
|
||||
upx -d packed.exe
|
||||
de4dot obfuscated.exe
|
||||
```
|
||||
|
||||
### Step 3: Emulation-Based Unpacking
|
||||
**Tools:** [[tools/speakeasy|speakeasy]], [[tools/qiling|qiling]]
|
||||
|
||||
Emulate execution to let the unpacker run. Speakeasy and Qiling can trace API calls during unpacking without a debugger. Look for VirtualAlloc followed by memcpy patterns.
|
||||
|
||||
```bash
|
||||
speakeasy -t specimen.exe -o report.json 2> report.txt
|
||||
python3 -c "from qiling import Qiling; ql = Qiling(['<sample>'], '/path/to/rootfs')"
|
||||
```
|
||||
|
||||
### Step 4: Debugger-Based Unpacking [W]
|
||||
**Tools:** [[tools/x64dbg|x64dbg]], [[tools/x32dbg|x32dbg]]
|
||||
|
||||
Set breakpoints on: VirtualAlloc/VirtualProtect (memory allocation), tail JMP to OEP (end of unpacker), or stack breakpoint (ESP trick). Step to OEP.
|
||||
|
||||
### Step 5: Anti-Debug Bypass [W]
|
||||
**Tools:** [[tools/scyllahide|scyllahide]]
|
||||
|
||||
If malware detects debugger: enable ScyllaHide. Handles IsDebuggerPresent, NtQueryInformationProcess, timing checks.
|
||||
|
||||
### Step 6: Memory Dumping [W]
|
||||
**Tools:** [[tools/ollydumpex|ollydumpex]], [[tools/scylla|scylla]]
|
||||
|
||||
At OEP: dump process with OllyDumpEx. Fix IAT with Scylla (IAT Autosearch → Get Imports → Fix Dump).
|
||||
|
||||
### Step 7: PE Fixup [W]
|
||||
**Tools:** [[tools/pe-unmapper|pe-unmapper]]
|
||||
|
||||
If dump has virtual alignment: pe_unmapper /in <dump> /base 400000 /out <fixed>. Only needed if sections have wrong raw sizes.
|
||||
|
||||
### Step 8: Verification
|
||||
**Tools:** [[tools/strings|strings]], [[tools/peframe|peframe]], [[tools/capa|capa]]
|
||||
|
||||
Verify: strings are now visible, imports are reasonable, capa detects capabilities. If good, route to Static Analysis Workflow for full analysis.
|
||||
|
||||
```bash
|
||||
strings binary.exe
|
||||
peframe specimen.exe
|
||||
capa specimen.exe
|
||||
```
|
||||
|
||||
#unpacking #packing #iat #memory-dump #oep #workflow
|
||||
Reference in New Issue
Block a user