practical-malware-analysis

name	practical-malware-analysis
description	Defensive malware analysis and reverse-engineering workflow. Use for authorized lab analysis of suspicious Windows executables, DLLs, shellcode, packed samples, malicious documents, indicators of compromise, static and dynamic triage, IDA/Ghidra/debugger reasoning, anti-analysis handling, unpacking, host/network signature creation, and concise malware reports.

Malware Analysis

Use this skill only for defensive, educational, forensic, incident-response, or lab work on samples the user is authorized to analyze. Keep malware contained. Prefer analysis, containment, detection, and reporting.

Quick Workflow

1. Confirm authorization and containment:
   • Identify the sample source, goal, allowed tools, network policy, and whether execution is permitted.
   • Use an isolated VM snapshot, no shared clipboard/folders unless needed, host-only or simulated networking by default, and synthetic credentials/files.
   • Record hashes before analysis and preserve original evidence read-only.
2. Perform basic static triage:
   • Hash the file, note size/type, check PE headers/sections/imports/exports/resources, extract ASCII/Unicode strings, identify compiler/packer hints, and scan with local/offline reputation if allowed.
   • Treat imports and strings as clues, not conclusions.
3. Decide whether the sample is packed or obfuscated:
   • Look for few imports, unusual section names, high entropy, suspicious entry point section, import reconstruction behavior, or strings appearing only after execution.
   • If packed, read references/anti-analysis-and-unpacking.md.
4. Build a safe dynamic plan:
   • Snapshot first. Run only if authorized. Monitor process, file, registry, service, mutex, network, and child-process activity.
   • Simulate DNS/HTTP where possible; capture traffic; avoid letting malware reach real infrastructure unless the user explicitly authorizes and risk is acceptable.
5. Move to advanced static analysis:
   • Use a disassembler/decompiler to identify entry points, imports, cross-references, strings, command dispatch, crypto/encoding loops, persistence, networking, injection, and privilege behavior.
   • Rename functions and variables as hypotheses improve.
6. Use advanced dynamic analysis when static analysis stalls:
   • Debug user-mode code for runtime strings/configuration, API arguments, branches, anti-debug logic, unpacking stubs, and decoded buffers.
   • Use kernel debugging only for drivers, rootkit behavior, callbacks, SSDT/IRP hooks, or kernel-mode crashes.
7. Extract behavior and indicators:
   • Host indicators: dropped paths, registry keys, services, scheduled tasks, mutexes, injected processes, drivers, persistence points, decoded config, privilege changes.
   • Network indicators: domains, IPs, URI paths, headers, beacons, protocol grammar, TLS/SNI/cert clues, User-Agent, timing, commands, exfil fields.
8. Produce detection and report:
   • Create YARA/host signatures for stable byte, string, import, section, resource, and behavioral traits.
   • Create network signatures from protocol invariants, not brittle packet offsets.
   • Report capabilities, confidence, evidence, IOCs, containment guidance, and unknowns.

Load References As Needed

• Read references/analysis-methodology.md for the workflow, tool map, static/dynamic triage, and report templates.
• Read references/windows-reversing.md for x86, PE, IDA/Ghidra-style workflows, Windows APIs, registry, services, DLLs, networking, shellcode, C++, and x64 hints.
• Read references/anti-analysis-and-unpacking.md for anti-disassembly, anti-debugging, anti-VM, packers, and safe unpacking strategy.
• Read references/behavior-and-detection.md for malware capability taxonomy, host/network indicators, YARA/Snort-style signature guidance, and IOC extraction.

Analysis Rules

• Separate observed facts from inferred intent.
• Work from broad triage to narrow reverse engineering; do not get stuck proving every instruction.
• Pivot among tools when blocked: strings, imports, PE structure, debugger, disassembler, packet capture, registry/file monitors, memory dumps, and sandbox traces each expose different evidence.
• Test one hypothesis at a time and preserve notes: timestamp, tool, sample hash, environment, observation, and confidence.
• Avoid live C2 contact by default. Prefer INetSim/FakeDNS/ApateDNS-style simulation, local listeners, packet capture, and controlled replay.
• Never submit sensitive or targeted samples to public sandboxes without permission.
• Do not run malware on the host OS or a VM with sensitive data.

Default Output Shapes

For a triage request, return:

• Sample identity and environment
• Static observations
• Dynamic observations, if execution was allowed
• Likely capabilities
• IOCs
• Recommended next reverse-engineering steps
• Containment and detection suggestions

For a full report, return:

• Executive summary
• Sample metadata and hashes
• Environment and scope
• Behavior summary
• Persistence, privilege, defense-evasion, networking, payload, and data-access findings
• IOCs and detection logic
• Remediation/containment
• Confidence and unresolved questions