reverse-skills-max: initial public release (restored, redacted, hardened)
This commit is contained in:
baradok609hecl1pq6qi
@@ -0,0 +1,200 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user