6.3 KiB
6.3 KiB
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.