Back to skills
SKILL.md
Malware Analysis Methodology
BSecurityDefensive malware analysis workflow from safe handling in an isolated lab through triage, static analysis, dynamic analysis, and reporting with ATT&CK mapping and YARA, Snort/Suricata, or Sigma signatures. Use when planning or running an analysis of a suspected sample for incident response.
- 4 stars
- 0 votes
- 0 copies
- 0 views
- Added October 1, 2026
Works with
Security analysis
75/100- Modifies startup scripts or system services for persistence
npx -y skills add HermeticOrmus/LibreSecOps-Claude-Code --skill malware-analysis-methodology --agent claude-codeAre you the author of Malware Analysis Methodology?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/hermeticormus-malware-analysis-methodology)---
name: "malware-analysis-methodology"
description: "Defensive malware analysis workflow from safe handling in an isolated lab through triage, static analysis, dynamic analysis, and reporting with ATT&CK mapping and YARA, Snort/Suricata, or Sigma signatures. Use when planning or running an analysis of a suspected sample for incident response."
---
# Malware Analysis Methodology
> Complete reference for the defensive malware analysis workflow, from safe handling and triage through static analysis, dynamic analysis, and reporting.
## Knowledge Base
### Analysis Phases
Malware analysis follows a structured progression from least-interactive to most-interactive techniques. Each phase builds on the previous, and analysts should extract maximum value from safer (non-execution) methods before moving to dynamic analysis.
**Phase 1: Triage (5-15 minutes)**
- File type identification via magic bytes (`file` command, not extension)
- Hash generation (MD5, SHA-1, SHA-256, ssdeep)
- Reputation lookups (VirusTotal, MalwareBazaar, CIRCL hashlookup)
- Quick string scan for obvious indicators
- Decision: known malware (skip to IOC extraction) vs unknown (proceed to Phase 2)
**Phase 2: Static Analysis (30 minutes - several hours)**
- String extraction: ASCII, Unicode, stack strings (FLOSS), encoded strings
- PE/ELF header analysis: compile timestamp, sections, imports/exports
- Entropy analysis: per-section entropy to detect packing/encryption
- Import analysis: categorize API calls by function (network, file, process, crypto, registry)
- Resource analysis: embedded files, icons, version info, manifests
- Packer/compiler identification: signature matching, heuristic detection
- Disassembly: function identification, control flow, key routines
- Decompilation: pseudo-code review for high-level logic understanding
**Phase 3: Dynamic Analysis (1-4 hours)**
- Environment preparation: isolated VM/sandbox, network simulation, monitoring tools
- Execution monitoring: process creation, API calls, file/registry activity
- Network capture: DNS requests, HTTP/HTTPS traffic, raw connections
- Memory analysis: dumping unpacked payloads, injected code, credentials
- Behavioral profiling: persistence installation, lateral movement attempts, data collection
**Phase 4: Reporting and IOC Extraction**
- MITRE ATT&CK technique mapping
- IOC extraction and categorization
- Detection signature creation (YARA, Snort/Suricata, Sigma)
- Analyst report (technical) and executive summary
### Safe Handling Procedures
**Environment requirements**:
- Dedicated analysis VM (REMnux, FlareVM, or custom)
- Snapshot before analysis, revert after
- Network isolation or controlled simulation (INetSim, FakeNet-NG)
- No shared folders with host in unrestricted mode
- Clipboard isolation from host
**File transfer safety**:
- Transfer samples in password-protected ZIP archives (standard password: `infected`)
- Never open samples on production systems
- Disable auto-execution features in analysis environment
- Use write-blocked media for physical transfers
**Analyst OPSEC**:
- Do not upload samples to public services if confidentiality matters
- Use VPN/Tor for reputation lookups on sensitive investigations
- Sanitize reports before sharing (remove internal infrastructure details)
### Tool Reference
| Phase | Tool | Purpose | Platform |
|-------|------|---------|----------|
| Triage | `file`, TrID | File type identification | Cross-platform |
| Triage | `md5sum`, `sha256sum`, `ssdeep` | Hash generation | Cross-platform |
| Static | `strings`, FLOSS | String extraction | Cross-platform |
| Static | `pefile` (Python) | PE parsing | Cross-platform |
| Static | `readelf`, `objdump` | ELF parsing | Linux |
| Static | `binwalk` | Embedded file extraction | Cross-platform |
| Static | Ghidra | Disassembly/decompilation | Cross-platform |
| Static | radare2/Cutter | Disassembly/scripting | Cross-platform |
| Static | YARA | Signature matching | Cross-platform |
| Dynamic | Cuckoo/CAPE Sandbox | Automated analysis | Linux host |
| Dynamic | ANY.RUN | Interactive cloud sandbox | Web |
| Dynamic | Procmon | Process/file/registry monitoring | Windows |
| Dynamic | Wireshark/tshark | Network capture | Cross-platform |
| Dynamic | FakeNet-NG | Network simulation | Windows |
| Dynamic | INetSim | Network simulation | Linux |
| Dynamic | Volatility 3 | Memory forensics | Cross-platform |
| Dynamic | API Monitor | API call tracing | Windows |
## Patterns
### Pattern: Packed Binary Identification
**Indicators**: High overall entropy (>7.0), very few imports (< 10), unusual section names (.aspack, .themida, UPX0/UPX1), section with raw size 0 but large virtual size, small code section with large data sections.
**Response**: Identify packer, attempt automated unpacking (UPX: `upx -d`), or proceed to dynamic analysis for runtime unpacking.
### Pattern: Process Injection Detection
**API sequence**: `OpenProcess` -> `VirtualAllocEx` -> `WriteProcessMemory` -> `CreateRemoteThread` (classic injection), or `CreateProcess (suspended)` -> `NtUnmapViewOfSection` -> `VirtualAllocEx` -> `WriteProcessMemory` -> `ResumeThread` (process hollowing).
**Response**: Identify target process, dump injected memory region, analyze injected code separately.
### Pattern: C2 Beaconing Recognition
**Network pattern**: Regular HTTP/HTTPS requests to the same host at consistent intervals (with jitter). Look for: POST requests with encoded body, cookie values with encoded data, URI patterns with session identifiers, consistent JA3 hash.
**Response**: Extract C2 address, document beaconing interval and jitter, identify protocol (HTTP, DNS, custom), capture JA3/JARM fingerprints.
### Pattern: Persistence Mechanism Identification
**Common locations** (Windows):
- `HKCU\Software\Microsoft\Windows\CurrentVersion\Run`
- `HKLM\Software\Microsoft\Windows\CurrentVersion\Run`
- Scheduled Tasks (`schtasks /create`)
- Services (`sc create`)
- Startup folder shortcuts
- WMI event subscriptions
- COM object hijacking
**Common locations** (Linux):
- Crontab entries
- systemd service units
- `.bashrc` / `.profile` modifications
- `/etc/init.d/` scripts
- LD_PRELOAD injection
### Pattern: Anti-Analysis Technique Detection
**Static indicators**: Imports of `IsDebuggerPresent`, `NtQueryInformationProcess`, `GetTickCount`, `QueryPerformanceCounter`, `CPUID` instructions, checks for VM-specific registry keys or hardware identifiers.
**Response**: Note sophistication level. Samples with heavy anti-analysis are typically more significant threats worth deeper investigation.
## Anti-Patterns
- **Executing samples on production systems** -- Never run suspected malware outside isolated analysis environments, regardless of time pressure
- **Relying solely on VirusTotal detection ratios** -- 0/70 does not mean clean; it means undetected. New malware, targeted samples, and well-packed binaries regularly evade all engines
- **Skipping static analysis for dynamic** -- Dynamic analysis without static context means you may miss dormant capabilities, alternate code paths, or environment-dependent behaviors
- **Sharing unpacked samples publicly** -- Unpacked samples reveal analysis capability. Share hashes and behavioral IOCs, not raw samples, unless through established trust groups
- **Treating IOCs as permanent** -- IPs and domains rotate in hours/days. Hashes change with each recompile. Focus detection on behavioral patterns and TTPs for durable value
- **Ignoring benign functionality** -- Malware often bundles legitimate functionality (system administration tools, file transfer utilities). Distinguish between dual-use tools and purpose-built malware
- **Single-run dynamic analysis** -- Run samples multiple times with different conditions (time, network, user interaction) to trigger conditional behaviors
## References
- SANS FOR610: Reverse-Engineering Malware -- https://www.sans.org/course/reverse-engineering-malware-malware-analysis-tools-techniques
- NIST SP 800-83 Rev 1: Guide to Malware Incident Prevention and Handling -- https://csrc.nist.gov/publications/detail/sp/800-83/rev-1/final
- MITRE ATT&CK Framework -- https://attack.mitre.org/
- Practical Malware Analysis (Sikorski & Honig) -- foundational textbook
- Malware Analyst's Cookbook (Ligh et al.) -- tool-oriented reference
- REMnux Linux distribution -- https://remnux.org/
- FlareVM Windows distribution -- https://github.com/mandiant/flare-vm
- MalwareBazaar sample repository -- https://bazaar.abuse.ch/
- YARA documentation -- https://yara.readthedocs.io/
Attribution
Comments
Loading comments…