# Malware Analysis Report Writing Guidelines

Best practices for writing clear, actionable, and professional malware analysis reports.

## General Principles

### 1. Know Your Audience

Reports typically serve multiple audiences with different needs:

| Audience | Needs | Focus |
|----------|-------|-------|
| Executive / Management | Business impact, risk level, cost | Executive summary |
| SOC / Incident Response | IOCs, detection rules, containment steps | IOCs, remediation |
| Malware Analysts | Technical details, reverse engineering | Findings, appendices |
| Threat Intelligence | TTPs, attribution, campaign context | ATT&CK, infrastructure |
| Legal / Compliance | Evidence chain, timeline, impact | Timeline, appendices |

### 2. Separate Fact from Interpretation

- **Observations** are factual: "The binary calls `CreateRemoteThread` targeting `explorer.exe`"
- **Analysis** is interpretation: "This indicates process injection for defense evasion"
- **Assessment** is judgment: "This technique is consistent with APT29 tradecraft"

Always make clear which category each statement falls into. Use qualifiers for assessments:
- "almost certainly" (95%+ confidence)
- "likely" (75-95% confidence)
- "probably" (50-75% confidence)
- "possibly" (25-50% confidence)
- "unlikely" (< 25% confidence)

### 3. Be Precise with Technical Details

**Do:**
- Include exact file paths: `C:\Users\Public\Documents\update.exe`
- Provide full hashes: SHA256 in every case, MD5/SHA1 for legacy compatibility
- Use defanged indicators: `hxxps://evil[.]com/gate.php`, `185.100.87[.]42`
- Specify exact API calls, registry keys, and mutex names
- Include timestamps in UTC with timezone clearly marked

**Do not:**
- Use vague descriptions: "the malware connects to the internet"
- Omit hash types: always label which hash algorithm
- Provide partial hashes without indication: use `a1b2c3...` if truncating
- Mix timezones without labeling

### 4. Structure for Scannability

- Use headers, subheaders, and numbered lists
- Put critical information first (inverted pyramid)
- Use tables for IOCs, ATT&CK mappings, and comparison data
- Include a table of contents for reports longer than 5 pages
- Bold key terms and findings for quick scanning

## Section-Specific Guidelines

### Executive Summary

- **Length**: 3-5 sentences, one paragraph
- **Content**: What, So What, Now What
  - What was found (malware family, type)
  - Why it matters (impact, risk)
  - What to do (recommended actions)
- **Avoid**: Technical jargon, API names, hash values
- **Include**: Severity rating, number of affected systems, business impact

### Sample Information

- Always include all three hash types (MD5, SHA1, SHA256)
- Include ssdeep for fuzzy matching
- Note compilation timestamp and whether it appears legitimate
- Record packer/compiler identification
- Include file size (both bytes and human-readable)
- Note first-seen date if available

### Technical Findings

- Order by severity: Critical > High > Medium > Low > Informational
- Each finding should include:
  - Severity rating with consistent criteria
  - Clear title summarizing the behavior
  - Description of what was observed
  - Evidence supporting the finding
  - MITRE ATT&CK technique mapping
- Use code blocks for commands, API calls, and string artifacts
- Include screenshots of relevant sandbox output when available

### Severity Rating Criteria

| Severity | Criteria |
|----------|----------|
| Critical | Remote code execution, active data exfiltration, credential theft, worm capability |
| High | Persistence mechanisms, C2 communication, privilege escalation, defense evasion |
| Medium | Reconnaissance, discovery, staging, configuration changes |
| Low | Information gathering, non-persistent indicators, minor policy violations |
| Informational | Interesting but non-threatening observations, metadata anomalies |

### IOC Section

- Defang all network indicators (domains, IPs, URLs)
- Include context for each IOC (what it is used for)
- Assign confidence levels: high, medium, low
- Group by type: file, network, host
- Format for easy copy-paste into security tools
- Consider providing IOCs in machine-readable format (CSV, STIX, OpenIOC)

### MITRE ATT&CK Mapping

- Use current ATT&CK technique IDs (verify against latest version)
- Include sub-technique IDs where applicable (T1055.012, not just T1055)
- Map to tactics (columns) not just techniques
- Provide evidence for each mapping - do not map speculatively
- Consider using ATT&CK Navigator for visual representation

### Detection Rules

- Test rules before including them (avoid false positive generators)
- Include metadata: author, date, reference, description
- Provide rules in standard formats: YARA, Sigma, Snort/Suricata
- Note known limitations or false positive potential
- Version rules for tracking updates

### Remediation

- Order by priority and urgency
- Separate into phases: Containment, Eradication, Recovery, Prevention
- Make steps specific and actionable (not "improve security posture")
- Include verification steps (how to confirm remediation was successful)
- Note dependencies between steps

## Formatting Standards

### Hash Formatting
```
MD5:    d41d8cd98f00b204e9800998ecf8427e
SHA1:   da39a3ee5e6b4b0d3255bfef95601890afd80709
SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
```

### Network Indicator Defanging
```
Domain: evil-domain[.]com        (replace . with [.])
IP:     185.100.87[.]42          (replace last . with [.])
URL:    hxxps://evil[.]com/path  (replace http with hxxp, . with [.])
Email:  actor[@]evil[.]com       (replace @ with [@])
```

### Timestamp Format
```
2025-01-15T08:30:00Z             (ISO 8601, UTC)
2025-01-15 08:30:00 UTC          (Human-readable, UTC)
```

### Classification Markings

Apply Traffic Light Protocol (TLP) markings consistently:

| TLP Level | Sharing | Use Case |
|-----------|---------|----------|
| TLP:RED | Named recipients only | Sensitive sources, active operations |
| TLP:AMBER | Limited to organization | Internal incident reports |
| TLP:AMBER+STRICT | Limited to organization only | No sharing outside org |
| TLP:GREEN | Community sharing | Sector-wide threat sharing |
| TLP:CLEAR | Public | Published advisories, blog posts |

## Common Mistakes to Avoid

1. **Burying the lead**: Put the most important findings first
2. **Missing IOCs**: Every report should have extractable IOCs
3. **No ATT&CK mapping**: Always map behaviors to ATT&CK framework
4. **Vague remediation**: "Patch systems" is not actionable; specify which patches
5. **Inconsistent hashes**: Use the same hash for the same file throughout
6. **Unfanged indicators**: Always defang network indicators in reports
7. **Missing timestamps**: Include timezone for every timestamp
8. **No confidence levels**: State how certain you are about findings
9. **Copy-paste errors**: Verify all hashes, IPs, and domains are correct
10. **Scope creep**: Stay focused on what was analyzed; note gaps explicitly

## Quality Checklist

Before finalizing a report, verify:

- [ ] Executive summary is understandable by non-technical readers
- [ ] All hashes are correct (cross-reference with original samples)
- [ ] All network indicators are properly defanged
- [ ] IOCs are deduplicated
- [ ] ATT&CK technique IDs are current and correctly applied
- [ ] Detection rules are syntactically valid
- [ ] Remediation steps are specific and actionable
- [ ] Classification marking is applied throughout
- [ ] No sensitive internal data (hostnames, usernames) leaked inappropriately
- [ ] Timestamps are consistent and in UTC
- [ ] Report ID is unique and follows naming convention
- [ ] Appendices are referenced from the main body
- [ ] Spell-check and grammar review completed