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

# 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

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)

□ 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

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

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

// 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

# 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

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

Multi-Agent Automated Analysis (SentinelHive Architecture)

┌─────────────────────────────────────────────────┐
│                  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

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?