Skip to content
Back to skills

Malware Analysis Methodology

BSecurity

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.

  • 4 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 1, 2026
securitypythonrustgobashgitapiperformancedocumentation

Works with

  • cli
  • api

Security analysis

B75/100
  • criticalModifies startup scripts or system services for persistence

Pro shows the line behind each finding and how to fix it

Scanned October 1, 2026

npx -y skills add HermeticOrmus/LibreSecOps-Claude-Code --skill malware-analysis-methodology --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Malware Analysis Methodology?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Malware Analysis Methodology
[![Security: B — Skills Directory](https://www.skillsdirectory.com/api/skills/hermeticormus-malware-analysis-methodology/badge)](https://www.skillsdirectory.com/skills/hermeticormus-malware-analysis-methodology)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…