reverse-skills-max: initial public release (restored, redacted, hardened)
This commit is contained in:
baradok609hecl1pq6qi
@@ -0,0 +1,236 @@
|
||||
---
|
||||
name: malware-report-writer
|
||||
description: Create professional malware analysis reports for enterprise security teams and incident response. Use when you need to write, structure, or improve a malware analysis report, produce executive summaries, author YARA rules, or format IOCs and detection rules for professional delivery.
|
||||
---
|
||||
|
||||
# Malware Report Writer
|
||||
|
||||
Create professional, comprehensive malware analysis reports for enterprise security teams, incident response, and threat intelligence.
|
||||
|
||||
## Execution Model
|
||||
|
||||
- **You write the report.** Read `analysis_state.md` and the evidence directory yourself (triage report, `procmon_summary.txt`, `sysmon_summary.txt`, tshark exports, decoded scripts, detection rule files) and draft every section from that. Ask the user only for what the evidence cannot tell you: engagement name, analyst name, audience, classification/TLP, and gaps you have flagged.
|
||||
- **Locate skill files.** Scripts and reference files ship in this skill's directory. Set `R="${CLAUDE_PLUGIN_ROOT:-<dir containing this SKILL.md>}"` once (when installed as a plugin `$CLAUDE_PLUGIN_ROOT` is set; otherwise it is this skill folder). Your working directory is the user's analysis workspace, so prefix every script path below with `$R`, e.g. `python3 "$R"/scripts/ioc_extract.py`.
|
||||
- **Author the YARA rule from the evidence** (runtime-decrypted strings, unique UA/URI, mutex, PDB path, config markers) and **test it yourself** when `yara` is installed — see **Testing YARA rules**. If it cannot be tested, mark the rule `UNTESTED` in the report; never present an untested rule as validated.
|
||||
- **Defang at write time.** Run any IOC list through `python3 scripts/ioc_extract.py` (repo root) rather than defanging by hand.
|
||||
- **Output is a file.** Write `reports/<sample>_report.md` in the user's workspace (create the directory), then print the executive summary and the quality-checklist result. Never leave template placeholders in the delivered file.
|
||||
- **State what was not done.** Phases skipped, network not observed, packer not defeated — these go in the report's limitations, not silently omitted.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when the user needs to:
|
||||
- Create a complete malware analysis report from analysis findings
|
||||
- Structure analysis results into professional documentation
|
||||
- Write executive summaries for malware samples
|
||||
- Format IOCs and detection rules for delivery
|
||||
- Review or improve existing malware reports
|
||||
- Prepare report documentation for stakeholders
|
||||
|
||||
## Quick Start
|
||||
|
||||
### Creating a New Report
|
||||
|
||||
1. `cat analysis_state.md`; `ls` the evidence and detection directories; read the phase outputs you need
|
||||
2. Copy `assets/report_template.md` to `reports/<sample>_report.md`
|
||||
3. Populate each section from the evidence, citing it (file, line, event) so every claim is traceable
|
||||
4. Author and test the YARA rule; paste Sigma/Suricata rules from `detection-engineer` verbatim
|
||||
5. Run the Quality Checklist below and `references/best_practices.md`; fix, then deliver
|
||||
|
||||
### Report Structure
|
||||
|
||||
The standard report includes these sections in order:
|
||||
|
||||
1. **Executive Summary** - High-level overview for non-technical stakeholders
|
||||
2. **Sample Information** - Basic file metadata and hashes
|
||||
3. **Static Analysis** - File structure, strings, imports/exports, resources
|
||||
4. **Dynamic Analysis** - Runtime behavior, system changes, network activity
|
||||
5. **IOCs** - Organized by type (file, network, host indicators)
|
||||
6. **Detection Rules** - YARA rules and optionally Sigma rules
|
||||
7. **Malware Classification** - Family, type, capabilities
|
||||
8. **Remediation and Mitigation** - Actionable response steps
|
||||
9. **Technical Details** - Additional deep-dive analysis
|
||||
10. **Conclusion** - Final summary and assessment
|
||||
11. **References** - External resources and links
|
||||
12. **Appendix** - Timeline, tools used, screenshots
|
||||
|
||||
## Key Principles
|
||||
|
||||
### Professional Quality
|
||||
- Use precise technical language with clear explanations
|
||||
- Include all three hash types (MD5, SHA1, SHA256)
|
||||
- Provide full context for every finding
|
||||
- Document methodology and tools used
|
||||
- Include timestamps and version information
|
||||
|
||||
### Professional Report Requirements
|
||||
Industry-standard reports require:
|
||||
- Complete technical documentation of malware samples
|
||||
- Professional format suitable for enterprise delivery
|
||||
- Working detection rules based on malware characteristics
|
||||
- Clear IOCs that can be operationalized
|
||||
|
||||
**Critical:** The quality of your report reflects your professionalism. Allocate sufficient time for writing and review.
|
||||
|
||||
### Audience Awareness
|
||||
Structure content for multiple audiences:
|
||||
- **Executive Summary**: Non-technical decision makers
|
||||
- **Technical Sections**: Security analysts and researchers
|
||||
- **IOCs/Detection**: SOC teams and detection engineers
|
||||
- **Remediation**: Incident responders
|
||||
|
||||
## Writing Guidelines
|
||||
|
||||
### Executive Summary
|
||||
- 2-4 paragraphs maximum
|
||||
- Plain language, minimal jargon
|
||||
- Answer: What? How critical? What actions?
|
||||
- Include key findings in bullet points
|
||||
|
||||
### Technical Analysis
|
||||
- Document both positive and negative findings
|
||||
- Provide evidence for every claim
|
||||
- Use code blocks for technical artifacts
|
||||
- Include screenshots when they add value
|
||||
- Connect behaviors to specific evidence
|
||||
|
||||
### IOCs Section
|
||||
**Format:**
|
||||
- Group by type (file, network, host)
|
||||
- Include context for each indicator
|
||||
- Provide confidence levels if uncertain
|
||||
- Test IOCs for accuracy before including
|
||||
|
||||
**Defanging (required):** All IOCs in reports MUST be defanged to prevent accidental activation:
|
||||
- URLs: `http` → `hxxp`, `https` → `hxxps` (e.g., `hxxps://malicious[.]example[.]com/payload`)
|
||||
- Domains: bracket the dot before the TLD (e.g., `evil[.]com`, `sub.domain[.]net`)
|
||||
- Email addresses: `@` → `[@]` (e.g., `attacker[@]evil[.]com`)
|
||||
- IP addresses: bracket each dot separator (e.g., `192[.]168[.]1[.]1`)
|
||||
|
||||
**Avoid:**
|
||||
- Environment-specific artifacts
|
||||
- Personal/analyst system information
|
||||
- Common legitimate values
|
||||
- Untested indicators
|
||||
|
||||
### Detection Rules
|
||||
**YARA Rules:**
|
||||
- Test against sample (must detect)
|
||||
- Test against clean files (must not false positive)
|
||||
- Include metadata: author, date, description, hash
|
||||
- Use meaningful string and variable names
|
||||
- Add comments explaining detection logic
|
||||
- Set appropriate conditions to balance detection and false positives
|
||||
|
||||
**Testing YARA rules** (run these; paste the results into the report's detection section):
|
||||
```bash
|
||||
command -v yara || echo "yara not installed: pip install yara-python / apt install yara — mark rule UNTESTED"
|
||||
yara -w -s detections/yara/family.yar samples/sample.exe # must match; -s shows which strings hit
|
||||
yara -w -s detections/yara/family.yar samples/unpacked.exe # and the unpacked/dropped stages
|
||||
yara -w -r detections/yara/family.yar /usr/lib /usr/bin clean/ 2>/dev/null | head # must print nothing (clean corpus; add a Windows clean dir if available)
|
||||
```
|
||||
A rule that matches only on strings present in the packed sample is a hash in disguise; prefer runtime-decrypted strings, config markers, mutexes, and code patterns, and require `2 of them` or more with a `filesize` bound.
|
||||
|
||||
**Best practices:**
|
||||
```yara
|
||||
rule Malware_Family_Variant {
|
||||
meta:
|
||||
description = "Detects Malware_Family based on C2 configuration"
|
||||
author = "Analyst Name"
|
||||
date = "2025-10-25"
|
||||
hash = "abc123..."
|
||||
reference = "Internal analysis"
|
||||
|
||||
strings:
|
||||
$c2_config = { 48 8B ?? ?? ?? ?? ?? 48 8D ?? ?? } // Config access pattern
|
||||
$ua_string = "Mozilla/4.0 (Suspicious UA)" ascii
|
||||
$mutex = "Global\\UniqueMalwareMutex" wide
|
||||
|
||||
condition:
|
||||
uint16(0) == 0x5A4D and // MZ header
|
||||
filesize < 2MB and
|
||||
2 of them
|
||||
}
|
||||
```
|
||||
|
||||
### Common Mistakes to Avoid
|
||||
- Over-relying on automated tool output without interpretation
|
||||
- Listing findings without explaining significance
|
||||
- Missing critical hashes or file metadata
|
||||
- Weak or untested detection rules
|
||||
- Vague remediation recommendations
|
||||
- Poor grammar/spelling
|
||||
- Inconsistent formatting
|
||||
- Environment-specific artifacts in IOCs
|
||||
|
||||
## Best Practices Reference
|
||||
|
||||
For detailed guidance on report quality, writing style, and common pitfalls, see `references/best_practices.md`.
|
||||
|
||||
Key topics covered:
|
||||
- Report writing principles (clarity, completeness, objectivity)
|
||||
- Structure guidelines for each section
|
||||
- IOC quality standards
|
||||
- Detection rule best practices
|
||||
- Audience considerations
|
||||
- Quality checklist
|
||||
- Efficient workflow strategies
|
||||
|
||||
## Quality Checklist
|
||||
|
||||
Before submitting any report, verify:
|
||||
|
||||
**Technical Accuracy:**
|
||||
- [ ] All three hash types included and verified
|
||||
- [ ] File paths are complete and accurate
|
||||
- [ ] Timestamps include timezone
|
||||
- [ ] Process IDs included for process activity
|
||||
- [ ] Tool versions documented
|
||||
|
||||
**Detection Rules:**
|
||||
- [ ] YARA rules tested against sample (detects correctly)
|
||||
- [ ] YARA rules tested against clean files (no false positives)
|
||||
- [ ] Rules include complete metadata
|
||||
- [ ] Conditions are appropriate and not over-matching
|
||||
|
||||
**IOCs:**
|
||||
- [ ] Grouped by type (file, network, host)
|
||||
- [ ] Context provided for each IOC
|
||||
- [ ] All IOCs defanged (hxxp/hxxps, [.] for domains and IPs, [@] for email)
|
||||
- [ ] No environment-specific artifacts
|
||||
- [ ] All IOCs validated
|
||||
|
||||
**Report Quality:**
|
||||
- [ ] Executive summary is non-technical and actionable
|
||||
- [ ] All sections completed
|
||||
- [ ] Grammar and spelling checked
|
||||
- [ ] Consistent formatting throughout
|
||||
- [ ] Evidence supports all claims
|
||||
- [ ] Remediation steps are specific and prioritized
|
||||
|
||||
**Professional Standards:**
|
||||
- [ ] Report is professional and enterprise-ready
|
||||
- [ ] Detection rules work and are well-documented
|
||||
- [ ] Technical details demonstrate thorough analysis
|
||||
- [ ] Report answers: What is it? What does it do? How to detect? How to remove?
|
||||
|
||||
## Output Format
|
||||
|
||||
Create reports in Markdown format using the template structure. For professional delivery:
|
||||
1. Create report in Markdown using the template
|
||||
2. Convert to PDF for professional appearance (if required)
|
||||
3. Ensure all sections are complete
|
||||
4. Include any screenshots as appendix items
|
||||
5. Verify detection rules are included and tested
|
||||
|
||||
## Example Usage
|
||||
|
||||
**User request:** "Write the report for the ransomware sample"
|
||||
|
||||
**What you do:**
|
||||
1. Read `analysis_state.md`, the triage report, dynamic summaries, and the Sigma/Suricata files already created.
|
||||
2. Copy the template to `reports/<sample>_report.md`; fill all 12 sections from evidence, citing sources.
|
||||
3. Write the YARA rule from runtime strings / ransom-note markers / mutex; run `yara` against the sample and a clean corpus; record the result.
|
||||
4. Defang the IOC section with `ioc_extract.py`; remove lab artifacts.
|
||||
5. Write remediation ordered by urgency (isolate → block C2 → remove persistence → recover), and the limitations section.
|
||||
6. Run the Quality Checklist; ask the user only for analyst name, audience, and any gap you could not close.
|
||||
7. Print the executive summary and the file path.
|
||||
@@ -0,0 +1,298 @@
|
||||
# Malware Analysis Report
|
||||
|
||||
**Analyst:** [Your Name]
|
||||
**Date:** [Analysis Date]
|
||||
**Sample Hash (SHA256):** [Hash]
|
||||
**Report ID:** [Unique ID]
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[2-3 paragraph high-level summary suitable for non-technical stakeholders]
|
||||
|
||||
**Key Findings:**
|
||||
- **Malware Family:** [Family name or "Unknown"]
|
||||
- **Threat Level:** [Critical/High/Medium/Low]
|
||||
- **Primary Functionality:** [Brief description]
|
||||
- **Recommended Actions:** [Immediate actions needed]
|
||||
|
||||
---
|
||||
|
||||
## Sample Information
|
||||
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| **Filename** | [Original filename] |
|
||||
| **File Size** | [Size in bytes/KB/MB] |
|
||||
| **File Type** | [PE32/PE64/Script/Document/etc] |
|
||||
| **MD5** | [MD5 hash] |
|
||||
| **SHA1** | [SHA1 hash] |
|
||||
| **SHA256** | [SHA256 hash] |
|
||||
| **First Seen** | [Date/Time or "Unknown"] |
|
||||
|
||||
---
|
||||
|
||||
## Static Analysis
|
||||
|
||||
### File Header Analysis
|
||||
|
||||
**PE Structure:**
|
||||
- **Architecture:** [x86/x64/ARM]
|
||||
- **Compilation Timestamp:** [Date/Time]
|
||||
- **Entry Point:** [Address]
|
||||
- **Sections:** [Number and names]
|
||||
|
||||
**Packing/Obfuscation:**
|
||||
- **Packed:** [Yes/No]
|
||||
- **Packer Identified:** [Name or "Unknown"]
|
||||
- **Entropy:** [Value - High entropy suggests packing/encryption]
|
||||
|
||||
### Strings Analysis
|
||||
|
||||
**Notable Strings:**
|
||||
- [Key strings that indicate functionality, URLs, file paths, registry keys]
|
||||
- [Decoded/deobfuscated strings if applicable]
|
||||
|
||||
### Import/Export Analysis
|
||||
|
||||
**Key Imports:**
|
||||
- [DLL name]: [Notable functions that indicate malicious behavior]
|
||||
- [Example: kernel32.dll: CreateRemoteThread, VirtualAllocEx (process injection)]
|
||||
- [Example: ws2_32.dll: socket, connect, send (network communication)]
|
||||
|
||||
**Exports:**
|
||||
- [List any exported functions]
|
||||
|
||||
### Resource Analysis
|
||||
|
||||
**Embedded Resources:**
|
||||
- [Icons, images, additional executables, configuration data]
|
||||
- [Any suspicious or high-entropy resources]
|
||||
|
||||
---
|
||||
|
||||
## Dynamic Analysis
|
||||
|
||||
### Behavioral Analysis
|
||||
|
||||
**Execution Environment:**
|
||||
- **Operating System:** [Windows version, architecture]
|
||||
- **Analysis Tools:** [List tools used: Process Monitor, Wireshark, etc.]
|
||||
- **Analysis Duration:** [Time period]
|
||||
|
||||
### Process Activity
|
||||
|
||||
**Process Creation:**
|
||||
- [Parent process → Child processes]
|
||||
- [Process injection or hollowing detected]
|
||||
|
||||
**Command Line Arguments:**
|
||||
- [Any command line execution observed]
|
||||
|
||||
### File System Activity
|
||||
|
||||
**Files Created/Modified:**
|
||||
- [Path]: [Purpose/Description]
|
||||
- [Path]: [Purpose/Description]
|
||||
|
||||
**Files Deleted:**
|
||||
- [List any files deleted]
|
||||
|
||||
### Registry Activity
|
||||
|
||||
**Registry Keys Created/Modified:**
|
||||
- [Registry path]: [Value and purpose]
|
||||
- [Persistence mechanisms identified]
|
||||
|
||||
**Notable Registry Operations:**
|
||||
- [Any suspicious registry behavior]
|
||||
|
||||
### Network Activity
|
||||
|
||||
**DNS Queries:**
|
||||
- [Domain]: [IP resolved]
|
||||
- [Suspicious or newly registered domains]
|
||||
|
||||
**Network Connections:**
|
||||
- **Protocol:** [TCP/UDP/HTTP/HTTPS]
|
||||
- **Remote Address:** [IP:Port]
|
||||
- **Purpose:** [C2 communication/Data exfiltration/Download additional payload]
|
||||
|
||||
**Network Indicators:**
|
||||
- [User-Agent strings]
|
||||
- [URI patterns]
|
||||
- [HTTP headers]
|
||||
|
||||
### System Changes
|
||||
|
||||
**Mutex Creation:**
|
||||
- [Mutex names - used to prevent multiple infections]
|
||||
|
||||
**Service Installation:**
|
||||
- [Service name, display name, description]
|
||||
|
||||
**Scheduled Tasks:**
|
||||
- [Task name and trigger]
|
||||
|
||||
---
|
||||
|
||||
## Indicators of Compromise (IOCs)
|
||||
|
||||
> **Note:** All network and host IOCs MUST be defanged before inclusion in this report.
|
||||
> Defanging rules: URLs use `hxxp`/`hxxps`; domains bracket the dot before the TLD (`evil[.]com`);
|
||||
> IP addresses bracket each dot (`192[.]168[.]1[.]1`); email addresses replace `@` with `[@]`.
|
||||
|
||||
### File Indicators
|
||||
```
|
||||
MD5: [hash]
|
||||
SHA1: [hash]
|
||||
SHA256: [hash]
|
||||
Filename: [name]
|
||||
File Size: [size]
|
||||
```
|
||||
|
||||
### Network Indicators
|
||||
```
|
||||
IP Addresses:
|
||||
[192.168.1.1] → 192[.]168[.]1[.]1 - [Purpose/Description]
|
||||
|
||||
Domains:
|
||||
[domain.com] → domain[.]com - [Purpose/Description]
|
||||
|
||||
URLs:
|
||||
[https://example.com/path] → hxxps://example[.]com/path - [Purpose/Description]
|
||||
```
|
||||
|
||||
### Host Indicators
|
||||
```
|
||||
Registry Keys:
|
||||
[Registry path]
|
||||
|
||||
File Paths:
|
||||
[File path]
|
||||
|
||||
Mutex Names:
|
||||
[Mutex name]
|
||||
|
||||
Service Names:
|
||||
[Service name]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Detection Rules
|
||||
|
||||
### YARA Rule
|
||||
|
||||
```yara
|
||||
rule [RuleName]_[MalwareFamily] {
|
||||
meta:
|
||||
description = "[Brief description]"
|
||||
author = "[Your name]"
|
||||
date = "[Date]"
|
||||
hash = "[Sample SHA256]"
|
||||
|
||||
strings:
|
||||
$string1 = "[hex or text pattern]" [modifiers]
|
||||
$string2 = "[hex or text pattern]" [modifiers]
|
||||
$api1 = "[API call pattern]"
|
||||
|
||||
condition:
|
||||
[Condition logic - e.g., uint16(0) == 0x5A4D and filesize < 500KB and all of ($string*)]
|
||||
}
|
||||
```
|
||||
|
||||
### Sigma Rule (Optional - for behavioral detection)
|
||||
|
||||
```yaml
|
||||
title: [Detection Name]
|
||||
id: [generate a unique UUID, e.g. a1b2c3d4-e5f6-7890-abcd-ef1234567890]
|
||||
status: experimental
|
||||
description: [What behavior this detects]
|
||||
references:
|
||||
- [URLs or references]
|
||||
author: [Your Name]
|
||||
date: [YYYY-MM-DD]
|
||||
tags:
|
||||
- attack.[tactic] # e.g. attack.execution
|
||||
- attack.t[XXXX].[YYY] # e.g. attack.t1059.001
|
||||
logsource:
|
||||
category: [process_creation/network_connection/etc]
|
||||
product: windows
|
||||
detection:
|
||||
selection:
|
||||
[Field]: [Value]
|
||||
condition: selection
|
||||
falsepositives:
|
||||
- [Potential false positives]
|
||||
level: [critical/high/medium/low]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Malware Classification
|
||||
|
||||
**Family:** [Malware family name or "Unknown"]
|
||||
**Type:** [Trojan/Ransomware/Worm/RAT/Backdoor/Dropper/Loader/etc]
|
||||
**Capabilities:**
|
||||
- [Capability 1 - e.g., Data exfiltration]
|
||||
- [Capability 2 - e.g., Remote access]
|
||||
- [Capability 3 - e.g., Keylogging]
|
||||
|
||||
---
|
||||
|
||||
## Remediation and Mitigation
|
||||
|
||||
### Immediate Actions
|
||||
1. [Isolate infected systems]
|
||||
2. [Block network IOCs at firewall/proxy]
|
||||
3. [Search for other instances using IOCs]
|
||||
|
||||
### Long-term Recommendations
|
||||
1. [Update endpoint protection signatures]
|
||||
2. [Deploy detection rules]
|
||||
3. [Review and strengthen security controls]
|
||||
4. [User awareness training if applicable]
|
||||
|
||||
### Recovery Steps
|
||||
1. [Remove malware using antivirus/manual removal]
|
||||
2. [Restore from clean backups if needed]
|
||||
3. [Reset compromised credentials]
|
||||
4. [Monitor for reinfection]
|
||||
|
||||
---
|
||||
|
||||
## Technical Details
|
||||
|
||||
[Additional technical information, screenshots, memory dumps analysis, code snippets, etc.]
|
||||
|
||||
---
|
||||
|
||||
## Conclusion
|
||||
|
||||
[Final summary paragraph with key takeaways and overall assessment]
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
- [VirusTotal Report Link]
|
||||
- [Any.Run Sandbox Report]
|
||||
- [External research/blog posts about similar samples]
|
||||
- [CVE numbers if applicable]
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
### Analysis Timeline
|
||||
- [Timestamp]: [Event]
|
||||
- [Timestamp]: [Event]
|
||||
|
||||
### Tools Used
|
||||
- [Tool name and version]
|
||||
- [Tool name and version]
|
||||
|
||||
### Screenshots
|
||||
[Include relevant screenshots from analysis]
|
||||
@@ -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