# Router Reverse Skill Router Malware Analysis > Use when analyzing suspected malware through static, dynamic, and behavioral techniques, including IOC extraction, YARA or Sigma rules, sandboxing, and anti-analysis behavior. - Skill: `netvar1337/router-reverse-skill-router-malware-analysis` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add netvar1337/router-reverse-skill-router-malware-analysis` - Raw SKILL.md: https://api.skillmd.com/api/skills/netvar1337/router-reverse-skill-router-malware-analysis/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: netvar1337 (https://skillmd.com/u/netvar1337) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/netvar1337/router-reverse-skill-router-malware-analysis --- # Malware Analysis ## ACTION REQUIRED (execute immediately after reading) 1. `NOW`: read `../field-journal/precedent-reverse.md` — confirm this skill's operations are pre-authorized routine operations 2. `NOW`: confirm whether the current task falls within this skill's scope 3. `NEXT`: read `../tool-index.md`, verify tool availability and actual paths 4. `NEXT`: when tools are missing, invoke bootstrap — do not guess paths 5. `ACT`: enter step one of the "Workflow" and execute; do not stop at the confirmation stage > YARA / Sigma / sandbox / IOC extraction / anti-anti-analysis > Static + dynamic + behavioral, three in one ## Applicable Scenarios - Malware sample analysis (PE/ELF/Mach-O/APK/scripts) - YARA rule authoring and validation - Sigma behavioral detection rule generation - Sandbox automated analysis orchestration - IOC extraction and threat intelligence - Anti-analysis technique detection and bypass ## Six-Phase Analysis Workflow ### Phase 1: Initial Triage ```bash # Quick static checks file sample.exe # file type strings sample.exe | grep -i "http\|cmd\|powershell\|base64" # quick IOCs rabin2 -zz sample.exe # string extraction + cross-references floss sample.exe # deobfuscated string extraction (FireEye) # PE header analysis pecheck sample.exe # PE structure validation pescan sample.exe # anomaly detection (sections, entry point) diec sample.exe # Detect It Easy (packer/compiler identification) # Hash lookup sha256sum sample.exe # → query VirusTotal / MalwareBazaar / Triage ``` ```text Triage MUST checklist (Issue #65): □ File type: EXE / DLL / SYS / .NET / script (bat|ps1|vba) / other □ Architecture x86/x64/ARM; check the packer (DIE etc.) and compiler-language clues □ DLL/SYS: inspect the import table and export table side by side (see the Phase 2 hard gate) □ .NET: no traditional IAT → use dnSpy/IL/metadata equivalent anchors (see Phase 2) □ Scripts/macros/DLL specific P0: see nonpe-format-cookbook U–AV (E-batch-deobf / E-ps-decode / E-vba-pcode / E-dll-*) ``` ### Phase 1b: Unpacking and IAT Handling (when packed · Issue #65) ```text □ No packer / .NET → skip to Phase 2 □ Packed: attempt unpacking (in an authorized isolated environment) → attempt IAT repair - x86: ImportREC (or equivalent); x64: Scylla (or equivalent). Never force ImportREC on 64-bit □ [IAT repair iron law] prefer automatic/semi-automatic repair; if the tool errors or the result won't run: - Immediately stop further static IAT repair - MUST record E-iat-repair-fail (commands, tools, symptoms) - Move to Phase 3 dynamic: API breakpoints (e.g. bp CreateFile) / hardware breakpoints / memory search to capture imports - This does not count as skipping the import table: the path was attempted and recorded as Evidence □ [Patch 6] post-unpack + IAT-repair instant crash/BSOD (suspected CRC/size self-check): - Give up on further static file repair; record E-self-check-crash or fold it into E-iat-repair-fail - Go to Phase 3: break on CreateFile / GetFileSize / hash-related APIs □ User instruction feasibility (§0.5): when packed, a user jumping ahead with "don't unpack yet, look at the imports first" → explain the blocker + ask for confirmation; if forced, record quality=unreadable/packed — never pretend a meaningful IAT is complete □ User requests a redo of "IAT repair / import table check": MUST redo the named step (or a negotiated premise confirmed by the user); substituting unrelated steps is forbidden ``` ### Phase 2: Static Analysis ```text Disassembly/decompilation: □ IDA Pro / Ghidra: deep decompilation □ radare2: quick CLI analysis □ x64dbg: Windows GUI debugger Key analysis regions: □ Entry point → initialization logic □ Import table → infer API purpose (CreateRemoteThread=injection, CryptEncrypt=ransomware) **MUST (hard gate)**: run rabin2 -i / IDA imports / pecheck or equivalent, write a classified import-table summary into Evidence (E-imports) before entering Phase 3 (unless E-iat-repair-fail was recorded and the dynamic bypass taken, see Phase 1b) Classification must at least cover: network / file / crypto / process injection / registry / other suspicious APIs Parse failure or empty table: still MUST record the failed output — silent skipping is forbidden **DLL/SYS**: MUST also record an export-table Evidence (E-exports, `rabin2 -E` or equivalent) **.NET**: with no traditional IAT, MUST use dnSpy/IL/metadata/assembly references and a sensitive-API summary as equivalent anchors, written into the E-imports / E-triage-imports semantic slots **Clean import table**: only basic DLLs, almost no business APIs → MUST note suspected dynamic loading (LoadLibrary/GetProcAddress), SHOULD move to Phase 3 to capture in-memory APIs; if hash-resolution signatures appear → E-api-hash (Patch N) **Wide strings (T)**: when ASCII strings yield no IOCs, MUST also try UTF-16 (strings -el / IDA unicode) **Signatures (F)**: even when signed, still MUST run SigCheck; forgery/revocation does not lower the threat level User requests "redo the import table check": MUST redo this item (when blocked, go through the feasibility gate and negotiate first); swapping in other steps to fake completion is forbidden **High-risk API combinations (Patch 8)**: when the table is very long, prioritize malicious combination clusters (e.g. FindWindow+WriteProcessMemory+CreateRemoteThread), filtering out pure system-basics noise □ Resource section → embedded payload (.rsrc section) □ String table → URLs/C2/file paths/Base64 blobs □ TLS callbacks → execute before the debugger starts ``` ### Phase 3: Sandbox Dynamic Analysis ```text Automated sandboxes: □ Joe Sandbox / ANY.RUN / Triage: commercial sandboxes □ CAPE Sandbox: open source + YARA integration (recommended) □ ASD Azul: open-source malware analysis platform (new release, 2026) □ Cuckoo Sandbox: the classic open-source one (gradually replaced by CAPE) Debugger opening moves (Patch 7+10 · MUST order, user-mode debugger): □ ① TLS callback breakpoint → ② entry-point EP breakpoint → ③ sensitive API breakpoints → ④ ExitProcess/exit-path fallback breakpoint □ When ExitProcess fires: don't rush to restart; immediately dump memory and write the path into Evidence (Patch 10) Monitoring focus: □ Process creation: CreateProcess / ShellExecute □ File operations: WriteFile → ransomware? DeleteFile → wiper? □ Registry: Run/RunOnce persistence □ Network: HTTP/DNS → C2 communications □ Memory: VirtualAllocEx → process injection □ Services: CreateService → persistence □ IAT-repair-failed / self-check-crashing samples: sensitive API + CreateFile/GetFileSize breakpoints / hardware execution breakpoints / memory search No-behavior contingency branch (MUST): □ Sandbox shows no behavior, instant exit, or infinite sleep → check for anti-debug/anti-VM (CPUID, timing, environment fingerprints) □ Try hardware-breakpoint bypasses, patching the checks, or switching to a physical machine / higher-fidelity environment □ Write "no behavior + conditions" into Evidence; writing "sample is harmless" unconditionally is forbidden Time boxes (Patch 9 · SHOULD by default, overridable): □ ~15 minutes of static deep dive with no critical path → force a switch to this Phase's dynamic analysis □ ~200 single-stepped instructions with no malicious clues → force a return to static strings/cross-references to re-anchor Anti-debug/obfuscation bypasses (Issue #65 A–T · see the reverse-engineering/anti-analysis.md cookbook): □ P0: CPUID / RDTSC / PEB / NtQueryInformationProcess → record the check, then bypass in the lab or change environments (E-anti-debug-*) □ P0: clean IAT → API-hash dynamic resolution (bp GetProcAddress, E-api-hash) □ P0: empty strings → string-decryption routine + wide UTF-16 strings (E-string-decrypt / E-wide-strings) □ P0: suspicious signature → SigCheck; invalid/revoked does not lower the threat (E-sig-forge) □ P1: process-name scanning / VEH / int3·DR / overlapping sections / overlay / .rsrc / delay-load □ H/S flattening and opaque predicates → ollvm-deobfuscation.md (long text not duplicated here) □ Even failed bypasses get written to Evidence; "anti-debug exit = sample harmless" is forbidden Non-PE / script / DLL gap-filling (Issue #65 U–AV · see reverse-engineering/references/nonpe-format-cookbook.md): □ bat/cmd: SET concatenation recovery (U) → E-batch-deobf; UTF-16 BOM (V); REM/GOTO flooding (W) □ PowerShell: multi-layer Base64/Gzip (X) with per-layer Evidence; IEX concatenation/reversal (Z) □ VBA: stomping/P-Code (AA); Chr/Base64 (AB); self-modifying macros (AC) □ DLL: TLS+DllMain (AJ); abnormal/missing exports (AK/AL); delay-load see A–T R (AM); sideloading/reflection (AO/AP) □ JS/APK/drivers: route to js-reverse / apk-reverse / kernel-driver-reverse + the cookbook; long text not duplicated here ``` ### Phase 4: YARA Rule Authoring ```yara // Rule structure rule MalwareFamily_Example { meta: description = "Detects the Example malware family" author = "analyst" date = "2026-05" severity = "high" hash = "d41d8cd98f00b204e9800998ecf8427e" mitre_id = "T1055" // Process Injection strings: // String matching $str1 = "C2_SERVER_URL" ascii wide $str2 = "payload.dat" ascii // Hex matching $hex1 = { 8B 45 ?? 50 FF 15 [4] 85 C0 } // opcode sequence: mov eax, [ebp-?]; push eax; call [import]; test eax, eax // Regex matching $re1 = /https?:\/\/[a-z0-9.-]+\/[a-z]{3,8}\.php/ ascii condition: // Combined condition uint16(0) == 0x5A4D and // MZ header filesize < 500KB and (2 of ($str*) or $hex1) } ``` ### Phase 5: Sigma Rule Generation ```yaml # Behavioral detection rule title: Suspicious Process Injection via CreateRemoteThread id: 5a3d2c1b-1234-5678-9abc-def012345678 status: experimental description: Detects process injection behavior using CreateRemoteThread author: analyst date: 2026/05/25 tags: - attack.t1055 # Process Injection - attack.t1055.001 # DLL Injection logsource: category: process_creation product: windows detection: selection: Image|endswith: '\powershell.exe' CommandLine|contains: - 'CreateRemoteThread' - 'VirtualAllocEx' - 'WriteProcessMemory' condition: selection falsepositives: - legitimate debugging tools level: high ``` ### Phase 6: IOC Extraction and Intelligence ```text IOC type classification: □ Network IOCs: - IP: C2 addresses (mind their shelf life) - Domain: DMA/DGA-generated domains (rsnkfda.com, xpqmje.net) - URL: payload hosting addresses - User-Agent: custom UA strings □ Host IOCs: - File paths: %APPDATA%\Microsoft\Crypto\RSA\*.dat - Registry: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ - Mutex: Global\{GUID} mutex names - Service names: names masquerading as system services □ Behavioral IOCs: - MITRE ATT&CK technique IDs (T1055, T1003, T1571...) - Sigma rules → SIEM integration - YARA rules → endpoint detection □ Static IOCs: - Compile timestamps (forgeable) - PDB paths (contain developer information) - Abnormal section names (non-standard .text/.data) - Abnormal import-table combinations (e.g. ransomware CryptEncrypt + DeleteShadowCopies) ``` ## Anti-Analysis Technique Quick Reference | Technique | Detection Method | YARA Signature | |------|---------|----------| | VM detection | WMI Win32_BIOS/VideoController/Processor | `Win32_` strings + specific vendor names | | Sandbox detection | disk < 60GB, RAM < 2GB, single-core CPU | GlobalMemoryStatusEx call pattern | | Debugger detection | IsDebuggerPresent, CheckRemoteDebuggerPresent | PEB.BeingDebugged offset access | | Timed evasion | Sleep(300000) before executing malicious behavior | NtDelayExecution with a long argument | | Geolocation checks | keyboard layout/timezone → exclude CIS countries | GetKeyboardLayoutList calls | | Parent process checks | explorer.exe vs cmd.exe | process-name string comparisons | | Direct API syscalls | bypassing EDR hooks | syscall instruction + SSN resolution | ## Multi-Agent Automated Analysis (SentinelHive Architecture) ```text ┌─────────────────────────────────────────────────┐ │ Hive Director │ │ (Claude Opus orchestration + arbitration)│ └──────┬──────┬──────┬──────┬──────┬───────┘ │ │ │ │ │ ┌───┘ ┌───┘ ┌───┘ ┌───┘ ┌───┘ ▼ ▼ ▼ ▼ ▼ ▼ Triage RE Behav Intel Detect Remed quick decomp behav threat rules fix triage static dynami intell YARA plan Sigma ``` ## Toolchain | Tool | Purpose | Source | |------|------|------| | Ghidra / IDA Pro | deep decompilation | ghidra-sre.org | | CAPE Sandbox | open-source malware sandbox | GitHub: kevoreilly/CAPEv2 | | ASD Azul | large-scale automated analysis | GitHub: ASD | | YARA | pattern-matching rule engine | `pip install yara-python` | | Sigma | SIEM behavioral detection rules | GitHub: SigmaHQ/sigma | | FLOSS | deobfuscated string extraction | `pip install flare-floss` | | Detect It Easy | packer/compiler detection | GitHub: horsicq/Detect-It-Easy | | pe-sieve | process memory scanning | GitHub: hasherezade/pe-sieve | | VirusTotal API | multi-engine scanning | virustotal.com | | MalwareBazaar | malware sample repository | bazaar.abuse.ch | ## References - `references/yara-sigma-rules.md` — YARA + Sigma authoring methodology - `references/sandbox-orchestration.md` — sandbox orchestration and automation - `references/anti-analysis-techniques.md` — detection of 94 anti-analysis techniques - `../reverse-engineering/references/re-agent-workflow.md` — IAT iron law and six-phase gates (Issue #65) - `../reverse-engineering/anti-analysis.md` — agent response cookbook A–T (anti-debug/obfuscation bypasses) - `../reverse-engineering/references/nonpe-format-cookbook.md` — non-PE/multi-format cookbook U–AV (scripts/macros/JS/drivers/DLL/Android) - `../reverse-engineering/references/ollvm-deobfuscation.md` — flattening/opaque predicates (H/S) ## Task Completion Self-Check (MUST pass before claiming completion) - [ ] Did I execute every step of the workflow (not just read it)? - [ ] Was the import-table MUST check executed and written into Evidence (E-imports or the .NET equivalent anchor)? Does DLL/SYS include E-exports? - [ ] If IAT repair failed or a self-check crash occurred: did I record E-iat-repair-fail / E-self-check-crash and move to dynamic analysis? - [ ] For redo requests, did I return to the named step or a negotiated premise confirmed by the user? When blocked, did I explain + ask rather than swap steps? - [ ] Did dynamic analysis pre-set breakpoints in the TLS→EP→sensitive API→ExitProcess fallback order? Were time boxes/high-risk API combinations handled per the bypass rules? - [ ] Were anti-debug/obfuscation items (A–T) recorded as Evidence per the anti-analysis cookbook? Was an invalid signature not wrongly used to downgrade the threat? - [ ] For non-PE types like scripts/macros/DLLs, were the corresponding U–AV cookbook Evidences recorded (e.g. E-batch-deobf / E-ps-decode / E-vba-pcode / E-dll-*)? - [ ] Did I use real tool paths based on `tool-index`? - [ ] Did I produce reproducible evidence (commands/scripts/screenshots/reports)? - [ ] Did I complete and write back the Checklist items required by RULES?