Add FOR610 tool/workflow knowledge base and data pipeline
Build comprehensive malware analysis knowledge base from 3 sources: - SANS FOR610 course: 120 tools, 47 labs, 15 workflows, 27 recipes - REMnux salt-states: 340 packages parsed from GitHub - REMnux docs: 280+ tools scraped from docs.remnux.org Master inventory merges all sources into 447 tools with help tiers (rich/standard/basic). Pipeline generates: tools.db (397 entries), 397 cheatsheets with multi-tool recipes, 15 workflow guides, 224 TLDR pages, and coverage reports. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
tobias
@@ -0,0 +1,68 @@
|
||||
============================================================
|
||||
Android Malware Analysis
|
||||
============================================================
|
||||
|
||||
Analyze suspicious Android APK files using static and dynamic techniques available in REMnux.
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: APK Triage
|
||||
Tools: file, apkid
|
||||
Verify file type and check for packers/obfuscators.
|
||||
APKiD detects: known packers (DexGuard, Bangcle),
|
||||
obfuscators, anti-debug techniques.
|
||||
|
||||
$ file specimen.exe
|
||||
|
||||
Step 2: Manifest Analysis
|
||||
Tools: apktool
|
||||
Decompile APK: apktool d <apk> -o output/. Examine
|
||||
AndroidManifest.xml for: excessive permissions,
|
||||
receivers, services, exported components, intent
|
||||
filters.
|
||||
|
||||
$ apktool d <app.apk> -o output/
|
||||
|
||||
Step 3: Source Code Recovery
|
||||
Tools: jadx
|
||||
Decompile DEX to Java: jadx <apk> -d output/. Review
|
||||
source code for: C2 URLs, crypto operations, SMS
|
||||
interception, data exfiltration, root checks.
|
||||
|
||||
$ jadx <app.apk> -d output/
|
||||
|
||||
Step 4: Static Analysis
|
||||
Tools: androguard, droidlysis
|
||||
androguard: analyze APK structure, permissions,
|
||||
activities. droidlysis: automated static analysis with
|
||||
IOC extraction. Check for: hardcoded keys, URLs,
|
||||
suspicious API usage.
|
||||
|
||||
$ androguard analyze <app.apk>
|
||||
|
||||
Step 5: Native Library Analysis
|
||||
Tools: strings, radare2
|
||||
If APK contains .so libraries: extract from lib/
|
||||
directory. Analyze with strings and radare2. Native
|
||||
code often hides C2 logic and crypto.
|
||||
|
||||
$ strings binary.exe
|
||||
$ r2 specimen.exe
|
||||
|
||||
Step 6: Dynamic Instrumentation
|
||||
Tools: frida
|
||||
Hook suspicious functions at runtime: frida -U -l
|
||||
hook.js <package>. Intercept: crypto operations,
|
||||
network calls, file access, SMS operations.
|
||||
|
||||
$ 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).
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,66 @@
|
||||
============================================================
|
||||
Behavioral Analysis
|
||||
============================================================
|
||||
|
||||
Monitor runtime behavior in an isolated environment. Applicable to any executable or script on Linux (REMnux) or Windows.
|
||||
|
||||
Related FOR610 Labs: 1.2, 1.4, 1.6, 4.5
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
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: fakedns, inetsim, 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.
|
||||
|
||||
$ fakedns
|
||||
$ inetsim
|
||||
$ fakenet
|
||||
|
||||
Step 3: Monitoring Setup
|
||||
Tools: wireshark, tcpdump, strace
|
||||
Start packet capture (wireshark or tcpdump). On Linux:
|
||||
strace/ltrace for syscalls. Start filesystem
|
||||
monitoring.
|
||||
|
||||
$ wireshark
|
||||
$ tcpdump -i eth0 -w capture.pcap
|
||||
|
||||
Step 4: Emulation (Safe Alternative)
|
||||
Tools: speakeasy, capa
|
||||
Before live execution, try emulation: speakeasy
|
||||
emulates Windows API calls on Linux safely. Use capa
|
||||
-vv for capability overview.
|
||||
|
||||
$ 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: wireshark, procdot
|
||||
Review network capture: follow TCP streams, extract
|
||||
payloads, identify C2 patterns. Analyze process
|
||||
activity logs. Map filesystem changes.
|
||||
|
||||
$ wireshark
|
||||
$ procdot
|
||||
|
||||
Step 7: Extract IOCs
|
||||
Document: contacted domains/IPs, created
|
||||
files/registry keys, spawned processes, persistence
|
||||
mechanisms. Classify behavior: downloader, backdoor,
|
||||
ransomware, etc.
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,69 @@
|
||||
============================================================
|
||||
Cobalt Strike Analysis
|
||||
============================================================
|
||||
|
||||
Analyze Cobalt Strike beacons, configurations, and network traffic using Didier Stevens' CS toolkit on REMnux.
|
||||
|
||||
Related FOR610 Labs: 3.4
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: Beacon Detection
|
||||
Tools: yara, 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.
|
||||
|
||||
$ yara-rules specimen.bin
|
||||
$ capa specimen.exe
|
||||
|
||||
Step 2: Configuration Extraction
|
||||
Tools: 1768-py
|
||||
Parse beacon config: 1768.py <sample>. Extracts: C2
|
||||
URLs, user-agent, beacon interval, watermark, spawn-to
|
||||
process, named pipes, proxy config.
|
||||
|
||||
$ 1768.py shellcode.bin
|
||||
|
||||
Step 3: Metadata Decryption
|
||||
Tools: 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.
|
||||
|
||||
$ cs-decrypt-metadata.py <metadata_hex>
|
||||
|
||||
Step 4: Key Extraction
|
||||
Tools: cs-extract-key-py
|
||||
Extract encryption keys: cs-extract-key.py -f
|
||||
<process_dump>. Recovers AES and HMAC keys used for C2
|
||||
communication encryption.
|
||||
|
||||
$ cs-extract-key.py -f <process_dump>
|
||||
|
||||
Step 5: Traffic Decryption
|
||||
Tools: cs-parse-traffic-py
|
||||
Decrypt C2 traffic: cs-parse-traffic.py -f <pcap> -k
|
||||
<keys>. Reveals: tasking commands, downloaded
|
||||
payloads, exfiltrated data.
|
||||
|
||||
$ cs-parse-traffic.py -f <capture.pcap> -k <keys_file>
|
||||
|
||||
Step 6: Sleep Mask Analysis
|
||||
Tools: 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.
|
||||
|
||||
$ 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.
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,83 @@
|
||||
============================================================
|
||||
Code Injection Analysis
|
||||
============================================================
|
||||
|
||||
Identify and analyze process injection techniques including DLL injection, process hollowing, and reflective loading.
|
||||
|
||||
Related FOR610 Labs: 4.9, 5.4
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: Capability Detection
|
||||
Tools: capa
|
||||
Run capa to identify injection techniques. Look for:
|
||||
'inject code', 'create suspended process', 'allocate
|
||||
RWX memory'. Note MITRE ATT&CK technique IDs.
|
||||
|
||||
$ capa specimen.exe
|
||||
|
||||
Step 2: Injection Type Classification
|
||||
Tools: ghidra, cutter
|
||||
Identify which technique: Classic DLL injection
|
||||
(LoadLibrary), Process Hollowing (CreateProcess
|
||||
SUSPENDED + NtUnmapViewOfSection), Reflective DLL
|
||||
(manual PE loading), APC injection (QueueUserAPC).
|
||||
|
||||
$ ghidra
|
||||
$ cutter specimen.exe
|
||||
|
||||
Step 3: Target Process Analysis
|
||||
Tools: ghidra
|
||||
How does malware choose its target? Look for:
|
||||
CreateToolhelp32Snapshot + Process32First/Next
|
||||
(enumeration), hardcoded process names (svchost.exe,
|
||||
explorer.exe), OpenProcess calls.
|
||||
|
||||
$ ghidra
|
||||
|
||||
Step 4: Payload Identification
|
||||
Tools: ghidra
|
||||
What gets injected? Trace data flow to
|
||||
WriteProcessMemory or NtWriteVirtualMemory. Is it:
|
||||
embedded PE, shellcode, encrypted blob? Check size and
|
||||
content.
|
||||
|
||||
$ ghidra
|
||||
|
||||
Step 5: Memory Allocation Analysis
|
||||
Tools: ghidra
|
||||
Examine VirtualAllocEx parameters: size (hints at
|
||||
payload type), protection flags
|
||||
(PAGE_EXECUTE_READWRITE = 0x40 = suspicious).
|
||||
Allocation address for base relocation.
|
||||
|
||||
$ ghidra
|
||||
|
||||
Step 6: Injection Verification [W]
|
||||
Tools: x32dbg, x64dbg
|
||||
Set breakpoint on WriteProcessMemory. When hit:
|
||||
examine lpBuffer (injected data), nSize (payload
|
||||
size). Dump the buffer to file for separate analysis.
|
||||
|
||||
$ x32dbg.exe specimen.exe
|
||||
$ x64dbg.exe specimen.exe
|
||||
|
||||
Step 7: Extracted Payload Analysis
|
||||
Tools: peframe, capa, strings
|
||||
Analyze the injected payload as standalone file. Route
|
||||
to: Static Analysis Workflow (if PE), Shellcode
|
||||
Workflow (if shellcode), .NET Workflow (if .NET
|
||||
assembly).
|
||||
|
||||
$ 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).
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,84 @@
|
||||
============================================================
|
||||
Malicious Document Analysis
|
||||
============================================================
|
||||
|
||||
Analyze suspicious documents (PDF, Office, RTF, OneNote) for embedded malware, macros, and exploits. Follows Zeltser's 6-step methodology.
|
||||
|
||||
Related FOR610 Labs: 3.1, 3.3, 3.4, 3.5
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: Format Identification
|
||||
Tools: file, trid
|
||||
Identify true format: OLE2 (legacy Office), OOXML
|
||||
(modern Office), RTF, PDF, OneNote. Don't trust the
|
||||
file extension — use magic bytes.
|
||||
|
||||
$ file specimen.exe
|
||||
$ trid document.doc
|
||||
|
||||
Step 2: Structure Analysis
|
||||
Tools: oledump-py, rtfdump-py, pdfid-py, pdf-parser-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.
|
||||
|
||||
$ oledump.py document.docm
|
||||
$ rtfdump.py document.rtf
|
||||
$ pdfid.py document.pdf
|
||||
$ pdf-parser.py document.pdf -a
|
||||
|
||||
Step 3: Password Handling (if encrypted)
|
||||
Tools: msoffcrypto-tool
|
||||
If document is password-protected: msoffcrypto-tool -p
|
||||
<password> <input> <output>. Common passwords:
|
||||
infected, malware, password, 123456.
|
||||
|
||||
$ msoffcrypto-tool -p infected <encrypted.docx> <decrypted.docx>
|
||||
|
||||
Step 4: Macro/Script Extraction
|
||||
Tools: oledump-py, olevba, pcode2code, 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).
|
||||
|
||||
$ oledump.py document.docm
|
||||
$ olevba document.docm
|
||||
$ pcode2code <document.docm>
|
||||
$ xlmdeobfuscator --file <spreadsheet.xlsm>
|
||||
|
||||
Step 5: Payload Decoding
|
||||
Tools: base64dump-py, translate-py, gunzip, numbers-to-string-py, cyberchef
|
||||
Decode embedded payloads. Common chains: Base64 →
|
||||
gunzip → XOR. Use CyberChef for visual multi-step
|
||||
decoding. translate.py for byte-level transforms (byte
|
||||
^ key).
|
||||
|
||||
$ base64dump.py file.txt
|
||||
$ translate.py "byte ^ 35" < input.bin > output.bin
|
||||
$ gunzip -c compressed.gz > output.bin
|
||||
$ oledump.py doc.docm -s A3 -v | numbers-to-string.py -j
|
||||
$ cyberchef
|
||||
|
||||
Step 6: Embedded Object Analysis
|
||||
Tools: scdbgc, xorsearch, yara, 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.
|
||||
|
||||
$ scdbgc /f shellcode.bin /s -1
|
||||
$ XORSearch -W -d 3 file.bin
|
||||
$ yara-rules specimen.bin
|
||||
$ 1768.py shellcode.bin
|
||||
|
||||
Step 7: Document IOCs
|
||||
Record: embedded URLs, downloaded payload hashes, C2
|
||||
addresses, macro behavior (what APIs called), exploit
|
||||
type (CVE if applicable).
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,81 @@
|
||||
============================================================
|
||||
.NET Malware Analysis
|
||||
============================================================
|
||||
|
||||
Analyze .NET malware using decompilation, debugging, and deobfuscation. Works for .NET Framework, .NET Core, and mixed-mode assemblies.
|
||||
|
||||
Related FOR610 Labs: 3.12, 4.8
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: Identification & Metadata
|
||||
Tools: peframe, diec, dnfile, 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.
|
||||
|
||||
$ peframe specimen.exe
|
||||
$ diec specimen.exe
|
||||
|
||||
Step 2: Obfuscator Detection
|
||||
Tools: diec, de4dot
|
||||
Detect obfuscator: DIE identifies ConfuserEx, Eziriz
|
||||
.NET Reactor, Babel, etc. de4dot -d <sample> reports
|
||||
detected obfuscator without modifying the file.
|
||||
|
||||
$ diec specimen.exe
|
||||
$ de4dot obfuscated.exe
|
||||
|
||||
Step 3: Decompilation
|
||||
Tools: ilspycmd, monodis
|
||||
Decompile to C# source: ilspycmd <sample> > output.cs.
|
||||
On REMnux use ilspycmd (CLI). Examine: Main() entry,
|
||||
suspicious class/method names, embedded resources.
|
||||
|
||||
$ ilspycmd assembly.exe > decompiled.cs
|
||||
|
||||
Step 4: Dynamic Loading Detection
|
||||
Tools: visual-studio-code
|
||||
Search decompiled code for: Assembly.Load(byte[]),
|
||||
Assembly.LoadFrom(), Activator.CreateInstance(),
|
||||
MethodInfo.Invoke(), CSharpCodeProvider. These
|
||||
indicate runtime code loading.
|
||||
|
||||
$ code filename.js
|
||||
|
||||
Step 5: Deobfuscation
|
||||
Tools: 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.
|
||||
|
||||
$ de4dot obfuscated.exe
|
||||
|
||||
Step 6: Dynamic Debugging [W]
|
||||
Tools: 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.
|
||||
|
||||
$ dnSpyEx.exe assembly.exe
|
||||
|
||||
Step 7: Extracted Payload Analysis
|
||||
Tools: ilspycmd, 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.
|
||||
|
||||
$ 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.
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,59 @@
|
||||
============================================================
|
||||
Email & Phishing Analysis
|
||||
============================================================
|
||||
|
||||
Analyze suspicious email messages for phishing indicators, malicious attachments, and weaponized links.
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: Header Analysis
|
||||
Tools: emldump-py, mail-parser
|
||||
Parse SMTP headers: emldump.py <email.eml>. Check:
|
||||
Received headers (delivery path), Return-Path vs From
|
||||
(spoofing), SPF/DKIM results, X-Mailer.
|
||||
|
||||
$ emldump.py message.eml
|
||||
$ python3 -c "import mailparser; mail = mailparser.parse_from_file('<email.eml>'); print(mail.subject)"
|
||||
|
||||
Step 2: Attachment Extraction
|
||||
Tools: emldump-py, msg-extractor
|
||||
Extract attachments: emldump.py <email.eml> -d. For
|
||||
MSG format: msg-extractor <email.msg>. List all
|
||||
attachments with types and sizes.
|
||||
|
||||
$ emldump.py message.eml
|
||||
$ extract_msg <email.msg>
|
||||
|
||||
Step 3: Attachment Triage
|
||||
Tools: file, trid, yara, 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).
|
||||
|
||||
$ file specimen.exe
|
||||
$ trid document.doc
|
||||
$ yara-rules specimen.bin
|
||||
|
||||
Step 4: Link Analysis
|
||||
Tools: unfurl
|
||||
Extract all URLs from email body and headers. Use
|
||||
Unfurl to decompose URLs (reveal tracking pixels,
|
||||
redirect chains, encoded parameters).
|
||||
|
||||
$ 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).
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,95 @@
|
||||
============================================================
|
||||
Available Analysis Workflows
|
||||
============================================================
|
||||
|
||||
static-analysis-workflow
|
||||
Static Properties Analysis
|
||||
Systematic static examination of a suspicious file
|
||||
without executing it. Works for PE, ELF, .NET,
|
||||
scripts, and documents.
|
||||
|
||||
behavioral-analysis-workflow
|
||||
Behavioral Analysis
|
||||
Monitor runtime behavior in an isolated environment.
|
||||
Applicable to any executable or script on Linux
|
||||
(REMnux) or Windows.
|
||||
|
||||
network-interception-workflow
|
||||
Network Traffic Interception
|
||||
Redirect and analyze malware network traffic in an
|
||||
isolated REMnux environment. Covers DNS, HTTP,
|
||||
HTTPS, and raw IP interception.
|
||||
|
||||
document-analysis-workflow
|
||||
Malicious Document Analysis
|
||||
Analyze suspicious documents (PDF, Office, RTF,
|
||||
OneNote) for embedded malware, macros, and exploits.
|
||||
Follows Zeltser's 6-step methodology.
|
||||
|
||||
javascript-deobfuscation-workflow
|
||||
JavaScript Deobfuscation
|
||||
Deobfuscate and analyze malicious JavaScript from
|
||||
web pages, email attachments, or document macros.
|
||||
|
||||
unpacking-workflow
|
||||
Unpacking Packed Executables
|
||||
Unpack compressed, encrypted, or obfuscated
|
||||
executables to reveal the original code. Covers
|
||||
automated and manual techniques.
|
||||
|
||||
code-injection-workflow
|
||||
Code Injection Analysis
|
||||
Identify and analyze process injection techniques
|
||||
including DLL injection, process hollowing, and
|
||||
reflective loading.
|
||||
|
||||
dotnet-analysis-workflow
|
||||
.NET Malware Analysis
|
||||
Analyze .NET malware using decompilation, debugging,
|
||||
and deobfuscation. Works for .NET Framework, .NET
|
||||
Core, and mixed-mode assemblies.
|
||||
|
||||
shellcode-analysis-workflow
|
||||
Shellcode Analysis
|
||||
Analyze extracted shellcode from documents,
|
||||
exploits, or injected processes. Covers detection,
|
||||
emulation, and payload identification.
|
||||
|
||||
string-deobfuscation-workflow
|
||||
String & Data Deobfuscation
|
||||
Decode obfuscated strings and data in malware.
|
||||
Covers XOR, Base64, stack strings, custom
|
||||
algorithms, and multi-layer encoding.
|
||||
|
||||
memory-forensics-workflow
|
||||
Memory Forensics
|
||||
Analyze memory dumps to find malware artifacts,
|
||||
injected code, and hidden processes. Uses Volatility
|
||||
3 framework on REMnux.
|
||||
|
||||
android-analysis-workflow
|
||||
Android Malware Analysis
|
||||
Analyze suspicious Android APK files using static
|
||||
and dynamic techniques available in REMnux.
|
||||
|
||||
java-analysis-workflow
|
||||
Java Malware Analysis
|
||||
Analyze malicious Java archives (JAR), applets, and
|
||||
compiled classes. Covers decompilation and code
|
||||
analysis.
|
||||
|
||||
email-analysis-workflow
|
||||
Email & Phishing Analysis
|
||||
Analyze suspicious email messages for phishing
|
||||
indicators, malicious attachments, and weaponized
|
||||
links.
|
||||
|
||||
cobalt-strike-workflow
|
||||
Cobalt Strike Analysis
|
||||
Analyze Cobalt Strike beacons, configurations, and
|
||||
network traffic using Didier Stevens' CS toolkit on
|
||||
REMnux.
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Usage: fhelp workflow <name>
|
||||
Example: fhelp workflow static-analysis
|
||||
@@ -0,0 +1,60 @@
|
||||
============================================================
|
||||
Java Malware Analysis
|
||||
============================================================
|
||||
|
||||
Analyze malicious Java archives (JAR), applets, and compiled classes. Covers decompilation and code analysis.
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: Archive Inspection
|
||||
Tools: unzip, file
|
||||
Extract JAR contents: unzip <file.jar> -d output/.
|
||||
Examine META-INF/MANIFEST.MF for Main-Class entry
|
||||
point. List all .class files.
|
||||
|
||||
$ unzip -P infected sample.zip
|
||||
$ file specimen.exe
|
||||
|
||||
Step 2: Decompilation
|
||||
Tools: cfr, 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.
|
||||
|
||||
$ cfr <file.jar> --outputdir output/
|
||||
$ jd-gui <file.jar>
|
||||
|
||||
Step 3: Multi-Decompiler Comparison
|
||||
Tools: cfr, procyon
|
||||
If one decompiler fails on a class: try Procyon.
|
||||
Compare outputs. Some obfuscators break specific
|
||||
decompilers while others handle them fine.
|
||||
|
||||
$ cfr <file.jar> --outputdir output/
|
||||
|
||||
Step 4: Code Analysis
|
||||
Tools: visual-studio-code
|
||||
Review decompiled source. Search for: Runtime.exec()
|
||||
(command execution), URLConnection (network), Cipher
|
||||
(crypto), File I/O operations, reflection
|
||||
(Class.forName).
|
||||
|
||||
$ code filename.js
|
||||
|
||||
Step 5: Resource Extraction
|
||||
Tools: strings
|
||||
Extract embedded resources and strings. Check for:
|
||||
encoded payloads in resources, config files, embedded
|
||||
binaries. Base64-encoded content is common.
|
||||
|
||||
$ strings binary.exe
|
||||
|
||||
Step 6: Document Findings
|
||||
Record: entry point class, malicious methods,
|
||||
URLs/IPs, downloaded payloads, commands executed, Java
|
||||
version requirements.
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,61 @@
|
||||
============================================================
|
||||
JavaScript Deobfuscation
|
||||
============================================================
|
||||
|
||||
Deobfuscate and analyze malicious JavaScript from web pages, email attachments, or document macros.
|
||||
|
||||
Related FOR610 Labs: 3.6, 3.7
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: Beautification
|
||||
Tools: js-beautify
|
||||
Format minified/compressed JavaScript for readability.
|
||||
Look for: eval() calls, document.write(),
|
||||
String.fromCharCode(), unescape(), atob().
|
||||
|
||||
$ js-beautify malicious.js > beautified.js
|
||||
|
||||
Step 2: Static Review
|
||||
Tools: visual-studio-code
|
||||
Identify obfuscation layers. Search for: eval/Function
|
||||
constructor (code execution), long encoded strings,
|
||||
variable name patterns (single chars = likely
|
||||
obfuscated).
|
||||
|
||||
$ code filename.js
|
||||
|
||||
Step 3: Safe Execution (SpiderMonkey)
|
||||
Tools: 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.
|
||||
|
||||
$ js -f malicious.js
|
||||
|
||||
Step 4: Environment Tuning
|
||||
Tools: visual-studio-code
|
||||
If script expects specific environment (location.href,
|
||||
navigator.userAgent): edit objects.js to provide
|
||||
expected values. Re-run SpiderMonkey.
|
||||
|
||||
$ code filename.js
|
||||
|
||||
Step 5: Alternative Analysis
|
||||
Tools: box-js, jstillery
|
||||
box-js: Node.js sandbox with WScript emulation.
|
||||
JStillery: AST-based deobfuscation. Use when
|
||||
SpiderMonkey can't handle the obfuscation.
|
||||
|
||||
$ 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.
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,81 @@
|
||||
============================================================
|
||||
Memory Forensics
|
||||
============================================================
|
||||
|
||||
Analyze memory dumps to find malware artifacts, injected code, and hidden processes. Uses Volatility 3 framework on REMnux.
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: Image Identification
|
||||
Tools: volatility3
|
||||
Determine OS and profile: vol3 -f <dump> windows.info
|
||||
(or linux.info). Verify image is valid and identify OS
|
||||
version, build, architecture.
|
||||
|
||||
$ vol3 -f <memory_dump> windows.info
|
||||
|
||||
Step 2: Process Analysis
|
||||
Tools: 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.
|
||||
|
||||
$ vol3 -f <memory_dump> windows.info
|
||||
|
||||
Step 3: Network Connections
|
||||
Tools: volatility3
|
||||
List connections: vol3 -f <dump> windows.netscan.
|
||||
Identify: C2 connections, unusual ports, connections
|
||||
to known-bad IPs. Cross-reference with process PIDs.
|
||||
|
||||
$ vol3 -f <memory_dump> windows.info
|
||||
|
||||
Step 4: Injection Detection
|
||||
Tools: 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.
|
||||
|
||||
$ vol3 -f <memory_dump> windows.info
|
||||
|
||||
Step 5: DLL Analysis
|
||||
Tools: 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.
|
||||
|
||||
$ vol3 -f <memory_dump> windows.info
|
||||
|
||||
Step 6: String Search
|
||||
Tools: volatility3, 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.
|
||||
|
||||
$ vol3 -f <memory_dump> windows.info
|
||||
$ strings binary.exe
|
||||
|
||||
Step 7: Process & Code Dumping
|
||||
Tools: 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.
|
||||
|
||||
$ vol3 -f <memory_dump> windows.info
|
||||
|
||||
Step 8: Timeline Reconstruction
|
||||
Tools: volatility3
|
||||
Build timeline: vol3 -f <dump> timeliner.Timeliner.
|
||||
Reconstruct: when malware started, what it did,
|
||||
lateral movement. Correlate with process tree and
|
||||
network data.
|
||||
|
||||
$ vol3 -f <memory_dump> windows.info
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,89 @@
|
||||
============================================================
|
||||
Network Traffic Interception
|
||||
============================================================
|
||||
|
||||
Redirect and analyze malware network traffic in an isolated REMnux environment. Covers DNS, HTTP, HTTPS, and raw IP interception.
|
||||
|
||||
Related FOR610 Labs: 1.3, 1.7, 1.8
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: DNS Interception
|
||||
Tools: fakedns
|
||||
Start fakedns to resolve ALL domains to REMnux IP.
|
||||
Verify: nslookup any-domain.com should return your
|
||||
REMnux IP.
|
||||
|
||||
$ fakedns
|
||||
|
||||
Step 2: Service Emulation
|
||||
Tools: inetsim, fakenet-ng, 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.
|
||||
|
||||
$ inetsim
|
||||
$ fakenet
|
||||
$ httpd
|
||||
|
||||
Step 3: TLS/HTTPS Interception (if needed)
|
||||
Tools: mitmproxy, polarproxy
|
||||
For HTTPS C2: mitmproxy as transparent proxy, or
|
||||
PolarProxy for TLS decryption. Install proxy CA cert
|
||||
on analysis machine if needed.
|
||||
|
||||
$ mitmproxy
|
||||
$ PolarProxy -p 443,80 -w captured.pcap
|
||||
|
||||
Step 4: Packet Capture
|
||||
Tools: wireshark, tcpdump
|
||||
Start capture before executing malware. Filter: not
|
||||
arp and not broadcast. Save to PCAP for later
|
||||
analysis.
|
||||
|
||||
$ 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: wireshark, tshark, ngrep, 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).
|
||||
|
||||
$ wireshark
|
||||
$ tshark -r capture.pcap
|
||||
$ ngrep -I <capture.pcap> 'password'
|
||||
$ tcpflow -r <capture.pcap> -o output/
|
||||
|
||||
Step 7: File Extraction
|
||||
Tools: tcpxtract, networkminer
|
||||
Carve files from PCAP: downloaded payloads,
|
||||
exfiltrated data, second-stage malware. NetworkMiner
|
||||
does this automatically.
|
||||
|
||||
$ tcpxtract -f <capture.pcap> -o output/
|
||||
$ NetworkMiner --pcap <capture.pcap>
|
||||
|
||||
Step 8: IP-Based Redirection (if needed)
|
||||
Tools: iptables
|
||||
If malware uses hardcoded IPs (no DNS): iptables -t
|
||||
nat -A PREROUTING -i eth0 -j REDIRECT. This redirects
|
||||
ALL traffic to local services.
|
||||
|
||||
$ 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.
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,78 @@
|
||||
============================================================
|
||||
Shellcode Analysis
|
||||
============================================================
|
||||
|
||||
Analyze extracted shellcode from documents, exploits, or injected processes. Covers detection, emulation, and payload identification.
|
||||
|
||||
Related FOR610 Labs: 3.4, 3.5, 4.6, 4.7
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: Shellcode Detection
|
||||
Tools: xorsearch, yara, 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.
|
||||
|
||||
$ XORSearch -W -d 3 file.bin
|
||||
$ yara-rules specimen.bin
|
||||
$ capa specimen.exe
|
||||
|
||||
Step 2: Extraction
|
||||
Tools: rtfdump-py, oledump-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.
|
||||
|
||||
$ rtfdump.py document.rtf
|
||||
$ oledump.py document.docm
|
||||
$ pdf-parser.py document.pdf -a
|
||||
|
||||
Step 3: Emulation
|
||||
Tools: scdbgc, 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.
|
||||
|
||||
$ scdbgc /f shellcode.bin /s -1
|
||||
$ speakeasy -t specimen.exe -o report.json 2> report.txt
|
||||
|
||||
Step 4: Framework Identification
|
||||
Tools: yara, 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.
|
||||
|
||||
$ yara-rules specimen.bin
|
||||
$ 1768.py shellcode.bin
|
||||
|
||||
Step 5: Conversion to EXE
|
||||
Tools: shcode2exe
|
||||
Convert shellcode to executable for static analysis:
|
||||
shcode2exe sc.bin sc.exe. Then analyze with peframe,
|
||||
strings, ghidra.
|
||||
|
||||
$ shcode2exe <shellcode.bin> <output.exe>
|
||||
|
||||
Step 6: String & IOC Extraction
|
||||
Tools: strings, floss, cyberchef
|
||||
Extract strings from shellcode. Look for: C2 URLs,
|
||||
download paths, filename markers, encryption keys. Use
|
||||
CyberChef for encoded content.
|
||||
|
||||
$ 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).
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,88 @@
|
||||
============================================================
|
||||
Static Properties Analysis
|
||||
============================================================
|
||||
|
||||
Systematic static examination of a suspicious file without executing it. Works for PE, ELF, .NET, scripts, and documents.
|
||||
|
||||
Related FOR610 Labs: 1.1, 2.1, 4.1
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: File Identification & Hashing
|
||||
Tools: file, trid, exiftool, sha256sum
|
||||
Determine file type using magic bytes. Compute hashes
|
||||
(MD5, SHA256) for lookup and documentation. Record
|
||||
file size and timestamps.
|
||||
|
||||
$ file specimen.exe
|
||||
$ trid document.doc
|
||||
$ exiftool document.pdf
|
||||
|
||||
Step 2: Reputation Check
|
||||
Tools: malwoverview, virustotal-search
|
||||
Look up hash on VirusTotal/MalwareBazaar. If known
|
||||
malware, note family name and detection rate. If clean
|
||||
or unknown, continue analysis.
|
||||
|
||||
$ malwoverview -v <hash>
|
||||
|
||||
Step 3: Packing & Entropy Check
|
||||
Tools: diec, 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.
|
||||
|
||||
$ diec specimen.exe
|
||||
$ peframe specimen.exe
|
||||
|
||||
Step 4: String Extraction
|
||||
Tools: strings, floss, pestr
|
||||
Extract readable strings. Use FLOSS for
|
||||
obfuscated/stack strings. Look for: URLs, IPs,
|
||||
domains, registry keys, file paths, error messages,
|
||||
API names.
|
||||
|
||||
$ strings binary.exe
|
||||
$ floss specimen.exe
|
||||
$ pestr specimen.exe
|
||||
|
||||
Step 5: Capability Detection
|
||||
Tools: capa, yara
|
||||
Identify capabilities mapped to MITRE ATT&CK. Scan
|
||||
with YARA rules for known malware families. Look for:
|
||||
persistence, C2, evasion, lateral movement
|
||||
capabilities.
|
||||
|
||||
$ capa specimen.exe
|
||||
$ yara-rules specimen.bin
|
||||
|
||||
Step 6: Import & Export Analysis
|
||||
Tools: peframe, capa
|
||||
Examine imported DLLs and functions. Map imports to
|
||||
behavior categories: networking (ws2_32), crypto
|
||||
(advapi32), process manipulation (kernel32). Check
|
||||
exports for DLL functionality.
|
||||
|
||||
$ peframe specimen.exe
|
||||
$ capa specimen.exe
|
||||
|
||||
Step 7: Disassembly (if needed)
|
||||
Tools: ghidra, cutter, radare2
|
||||
Load into disassembler for code-level analysis. Start
|
||||
at entry point, trace key functions. Use decompiler
|
||||
for C-like view.
|
||||
|
||||
$ 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?
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,66 @@
|
||||
============================================================
|
||||
String & Data Deobfuscation
|
||||
============================================================
|
||||
|
||||
Decode obfuscated strings and data in malware. Covers XOR, Base64, stack strings, custom algorithms, and multi-layer encoding.
|
||||
|
||||
Related FOR610 Labs: 1.5, 5.2
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: Automated Extraction
|
||||
Tools: floss, strings
|
||||
Start with FLOSS for automatic deobfuscation (static +
|
||||
stack + decoded strings). Compare against plain
|
||||
strings output. FLOSS --no-static for only decoded
|
||||
strings.
|
||||
|
||||
$ floss specimen.exe
|
||||
$ strings binary.exe
|
||||
|
||||
Step 2: Encoding Detection
|
||||
Tools: xorsearch, bbcrack
|
||||
Identify encoding algorithm. XORSearch: detect XOR
|
||||
with known plaintext (http:, MZ, This program).
|
||||
bbcrack: brute-force XOR, ROL, ADD at multiple levels.
|
||||
|
||||
$ XORSearch -W -d 3 file.bin
|
||||
$ bbcrack -l 1 specimen.dll
|
||||
|
||||
Step 3: Single-Byte XOR Recovery
|
||||
Tools: brxor-py, 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.
|
||||
|
||||
$ brxor.py specimen.dll
|
||||
$ xortool <encoded_file>
|
||||
|
||||
Step 4: Multi-Byte / Custom Decoding
|
||||
Tools: translate-py, cyberchef
|
||||
For custom algorithms: translate.py 'byte ^ key' or
|
||||
complex expressions. CyberChef for visual recipe
|
||||
building (XOR → Base64 → Gunzip chains). Document the
|
||||
recipe.
|
||||
|
||||
$ translate.py "byte ^ 35" < input.bin > output.bin
|
||||
$ cyberchef
|
||||
|
||||
Step 5: Stack String Recovery
|
||||
Tools: strdeob-pl, 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.
|
||||
|
||||
$ 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.
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
@@ -0,0 +1,86 @@
|
||||
============================================================
|
||||
Unpacking Packed Executables
|
||||
============================================================
|
||||
|
||||
Unpack compressed, encrypted, or obfuscated executables to reveal the original code. Covers automated and manual techniques.
|
||||
|
||||
Related FOR610 Labs: 4.1, 4.2, 4.3, 5.3, 5.8, 5.10
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
|
||||
Step 1: Packing Identification
|
||||
Tools: diec, 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).
|
||||
|
||||
$ diec specimen.exe
|
||||
$ peframe specimen.exe
|
||||
|
||||
Step 2: Automated Unpacking
|
||||
Tools: upx, de4dot
|
||||
Try known unpackers first. UPX: upx -d <sample>. .NET:
|
||||
de4dot <sample>. If automated unpacking fails
|
||||
(modified packer), proceed to manual.
|
||||
|
||||
$ upx -d packed.exe
|
||||
$ de4dot obfuscated.exe
|
||||
|
||||
Step 3: Emulation-Based Unpacking
|
||||
Tools: speakeasy, 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.
|
||||
|
||||
$ 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: x64dbg, x32dbg
|
||||
Set breakpoints on: VirtualAlloc/VirtualProtect
|
||||
(memory allocation), tail JMP to OEP (end of
|
||||
unpacker), or stack breakpoint (ESP trick). Step to
|
||||
OEP.
|
||||
|
||||
$ x64dbg.exe specimen.exe
|
||||
$ x32dbg.exe specimen.exe
|
||||
|
||||
Step 5: Anti-Debug Bypass [W]
|
||||
Tools: scyllahide
|
||||
If malware detects debugger: enable ScyllaHide.
|
||||
Handles IsDebuggerPresent, NtQueryInformationProcess,
|
||||
timing checks.
|
||||
|
||||
$ Plugins > ScyllaHide > Options > Enable all
|
||||
|
||||
Step 6: Memory Dumping [W]
|
||||
Tools: ollydumpex, scylla
|
||||
At OEP: dump process with OllyDumpEx. Fix IAT with
|
||||
Scylla (IAT Autosearch → Get Imports → Fix Dump).
|
||||
|
||||
$ Plugins > OllyDumpEx > Dump process
|
||||
$ Scylla x64 > Attach to process > Dump > IAT Autosearch > Fix Dump
|
||||
|
||||
Step 7: PE Fixup [W]
|
||||
Tools: pe-unmapper
|
||||
If dump has virtual alignment: pe_unmapper /in <dump>
|
||||
/base 400000 /out <fixed>. Only needed if sections
|
||||
have wrong raw sizes.
|
||||
|
||||
$ pe_unmapper /in dumped.exe /base 400000 /out fixed.exe
|
||||
|
||||
Step 8: Verification
|
||||
Tools: strings, peframe, capa
|
||||
Verify: strings are now visible, imports are
|
||||
reasonable, capa detects capabilities. If good, route
|
||||
to Static Analysis Workflow for full analysis.
|
||||
|
||||
$ strings binary.exe
|
||||
$ peframe specimen.exe
|
||||
$ capa specimen.exe
|
||||
|
||||
────────────────────────────────────────────────────────────
|
||||
Tip: 'fhelp cheat <tool>' for full examples
|
||||
'Ctrl+G' for interactive cheatsheet browser
|
||||
Reference in New Issue
Block a user