# Malware Report Writing Best Practices

## Report Writing Principles

### Clarity and Precision
- Use clear, unambiguous language
- Define technical terms when first used
- Avoid assumptions about reader's technical knowledge
- Be specific with details (exact timestamps, full file paths, complete hashes)

### Completeness
- Document all analysis steps taken
- Include negative findings (what wasn't found is also important)
- Provide sufficient context for each finding
- Link behaviors to specific evidence

### Objectivity
- Report facts, not opinions
- Use evidence-based statements
- Clearly distinguish between observations and inferences
- Acknowledge limitations or uncertainties in analysis

### Actionability
- Provide clear IOCs that can be operationalized
- Include detection rules that are tested and validated
- Give specific, prioritized remediation steps
- Consider the audience (technical team, management, stakeholders)

## Structure Guidelines

### Executive Summary
**Purpose:** Provide non-technical decision-makers with key information

**Include:**
- What the malware does (in plain language)
- How critical the threat is
- Immediate actions needed
- Business impact if applicable

**Avoid:**
- Technical jargon without explanation
- Excessive detail
- Assumptions about reader's technical knowledge

**Length:** 2-4 paragraphs maximum

### Technical Analysis Sections
**Purpose:** Provide detailed evidence and technical findings

**Include:**
- Step-by-step methodology
- Evidence with context
- Screenshots/hex dumps when relevant
- Analysis tool outputs
- Timestamps and version information

**Organize by:**
- Analysis phase (static → dynamic)
- System area (file system → registry → network)
- Chronological order of behaviors

### IOCs Section
**Purpose:** Provide immediately usable indicators

**Format Guidelines:**
- Group by type (file, network, host)
- Include context for each IOC
- Note confidence levels if uncertain
- Provide expiration guidance for time-sensitive IOCs

**Quality Checks:**
- Remove personal/environment-specific artifacts
- Verify IOCs aren't common legitimate values
- Test that IOCs actually match the malware
- Include both specific and generic indicators

### Detection Rules
**Purpose:** Enable ongoing detection

**YARA Rules:**
- Test against sample to verify detection
- Test against clean files to avoid false positives
- Use meaningful string names and comments
- Include metadata (author, date, description, hash)
- Set appropriate conditions (avoid over-matching)

**Sigma Rules (if applicable):**
- Target specific behaviors not easily evaded
- Consider false positive scenarios
- Test with sample logs if possible
- Document expected log sources

## Common Pitfalls to Avoid

### Over-reliance on Automated Tools
- Don't just copy-paste tool output
- Interpret and contextualize findings
- Verify automated findings manually when critical
- Acknowledge tool limitations

### Missing Context
- Don't list IOCs without explaining their significance
- Connect behaviors to malware capabilities
- Explain why something is malicious
- Provide the "so what?" for technical findings

### Incomplete IOCs
- Don't provide just one hash type
- Include full paths, not just filenames
- Capture complete URLs, not just domains
- Document registry value data, not just keys

### Poor Detection Rules
- Rules that match too broadly (false positives)
- Rules that are too specific (easily evaded)
- Untested rules
- Rules without context/comments

### Weak Remediation Guidance
- Vague recommendations ("improve security")
- No prioritization of actions
- Steps that aren't actually actionable
- Missing consideration of operational impact

## Writing Style Guide

### Technical Accuracy
- Use precise technical terminology
- Include version numbers for software/tools
- Specify architectures (x86/x64)
- Use full protocol names first mention (HTTP/HTTPS/DNS)

### Tense and Voice
- Use past tense for observations ("The malware created...")
- Use present tense for general facts ("The malware is a trojan...")
- Prefer active voice ("The malware connected to..." vs "A connection was made...")

### Formatting Standards
- Use code blocks for file paths, registry keys, commands
- Use tables for structured data (sample information, IOCs)
- Use bullet points for lists, not paragraphs
- Bold or italicize key terms sparingly
- Use consistent heading hierarchy

### Evidence Documentation
- Include timestamps with timezone
- Provide full file paths
- Include process IDs (PIDs) for process activity
- Document tool versions used
- Include return codes/error messages when relevant

## Audience Considerations

### For Technical Teams
- Include detailed technical evidence
- Provide analysis methodology
- Share tool commands used
- Include raw indicators

### For Management
- Focus on business impact
- Translate technical findings to risk
- Provide clear recommendations
- Include cost/effort estimates for remediation

### For Incident Response
- Prioritize IOCs and detection rules
- Include timeline of events
- Provide containment guidance
- Document lateral movement paths

## Sample Report Improvements

### Before (Poor)
"The malware is bad and does network stuff. Found some registry keys. Use this YARA rule."

### After (Good)
"The malware is a backdoor trojan that establishes C2 communication with 192[.]168[.]1[.]100:8080. It achieves persistence through a registry Run key at HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Update with value C:\Users\Public\svchost.exe. The included YARA rule detects based on unique API call sequences and embedded C2 configuration strings."

## Time Management Strategies

### Phase 1-2: Analysis
- Perform thorough analysis
- Take detailed notes
- Capture all evidence (screenshots, logs)
- Document as you go

### Phase 3: Detection Engineering
- Finish any remaining analysis
- Create detection rules
- Test YARA rules
- Organize all findings

### Phase 4: Report Writing
- Draft all technical sections
- Refine technical sections
- Write executive summary and review
- Final quality check before delivery

**Pro Tip:** Don't wait until the end to start writing. Document findings during analysis to save time.