reverse-skills-max: initial public release (restored, redacted, hardened)
This commit is contained in:
@@ -0,0 +1,115 @@
|
||||
---
|
||||
name: writing-a-malware-analysis-report
|
||||
description: 'Structures a clear, actionable malware analysis report covering summary,
|
||||
sample identity, capabilities, IOCs, ATT&CK mapping, and detection guidance for both
|
||||
technical and decision-making audiences. Activates for requests to write, structure, or
|
||||
review a malware analysis or reverse-engineering report.'
|
||||
domain: cybersecurity
|
||||
subdomain: lab-foundations
|
||||
tags:
|
||||
- malware
|
||||
- reporting
|
||||
- ioc
|
||||
- mitre-attack
|
||||
- documentation
|
||||
- detection
|
||||
version: 1.0.0
|
||||
author: analyst-ai-pack
|
||||
license: Apache-2.0
|
||||
mitre_attack:
|
||||
- T1587
|
||||
d3fend:
|
||||
- D3-FA
|
||||
references:
|
||||
- 'MITRE ATT&CK — https://attack.mitre.org/'
|
||||
- 'MISP core format / STIX 2.1 for IOC representation — https://www.misp-project.org/'
|
||||
---
|
||||
|
||||
# Writing a Malware Analysis Report
|
||||
|
||||
## When to Use
|
||||
|
||||
- You have completed static, dynamic, or reverse-engineering analysis and need to communicate
|
||||
findings to responders, detection engineers, and leadership.
|
||||
- You need a consistent report structure so findings are actionable and comparable across
|
||||
samples.
|
||||
- You are reviewing a draft report for completeness before distribution.
|
||||
|
||||
**Do not use** this as a substitute for analysis; a report only documents work already done.
|
||||
Do not pad a report with tool output that has no analytic conclusion.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Completed analysis artifacts: sample hashes, behavioral notes, extracted IOCs, screenshots,
|
||||
and any reversed routines.
|
||||
- An ATT&CK reference for mapping observed behaviors to techniques.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Lead with an executive summary
|
||||
|
||||
Three to five sentences a non-analyst can act on: what the sample is, what it does, the risk,
|
||||
and the recommended action. State your confidence and the basis for it.
|
||||
|
||||
### Step 2: Record sample identity
|
||||
|
||||
A table the reader can match against their telemetry:
|
||||
|
||||
```text
|
||||
Filename (as received) : invoice.exe
|
||||
SHA-256 : 9f86d0818...
|
||||
SHA-1 / MD5 : ...
|
||||
File type / size : PE32 executable / 412 KB
|
||||
First seen / source : 2026-06-20 / MalwareBazaar
|
||||
Signing : unsigned / invalid certificate
|
||||
```
|
||||
|
||||
### Step 3: Describe capabilities, not just events
|
||||
|
||||
Group findings by capability (persistence, C2, defense evasion, collection), each with the
|
||||
evidence and the ATT&CK technique:
|
||||
|
||||
```text
|
||||
Persistence : Run key HKCU\...\Run "Updater" -> %APPDATA%\svc.exe [T1547.001]
|
||||
C2 : HTTPS beacon to evil[.]com/api every 60s +/- jitter [T1071.001]
|
||||
Defense evasion: UPX-packed; checks for VM artifacts before running [T1027, T1497]
|
||||
```
|
||||
|
||||
### Step 4: Provide IOCs in a usable form
|
||||
|
||||
Defanged for reading, plus a machine-ingestible block (CSV/STIX/MISP) for detection teams.
|
||||
Separate **host** IOCs (paths, registry keys, mutexes) from **network** IOCs (domains, IPs,
|
||||
URLs, JA3).
|
||||
|
||||
### Step 5: Give detection and response guidance
|
||||
|
||||
Concrete next steps: YARA/Sigma rules, what to hunt for, containment, and remediation.
|
||||
|
||||
### Step 6: Generate the skeleton and validate completeness
|
||||
|
||||
```bash
|
||||
python scripts/analyst.py scaffold --sha256 <sha256> --name "Sample" > report.md
|
||||
python scripts/analyst.py check report.md
|
||||
```
|
||||
|
||||
## Validation
|
||||
|
||||
- An incident responder can act on the report without reading the raw tool logs.
|
||||
- Every capability claim cites specific evidence (offset, registry key, packet, decompiled
|
||||
routine).
|
||||
- IOCs appear both defanged (for humans) and in a structured block (for tools).
|
||||
- ATT&CK techniques are valid current IDs and tied to observed behavior, not guessed.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Dumping raw tool output without interpretation — the reader needs conclusions.
|
||||
- Overclaiming attribution ("this is APT-X") from weak signals; state confidence and
|
||||
evidence instead.
|
||||
- Mixing host and network IOCs, or leaving IOCs clickable in the human-readable section.
|
||||
- Mapping to ATT&CK techniques that the evidence does not actually support.
|
||||
|
||||
## References
|
||||
|
||||
- See [`references/api-reference.md`](references/api-reference.md) for the scaffold and
|
||||
completeness-check tooling.
|
||||
- MITRE ATT&CK and MISP/STIX IOC formats (linked in frontmatter).
|
||||
Reference in New Issue
Block a user