Writing the Analysis Report

The analysis is worthless until a defender can act on it, and that means indicators they can search for tonight.

20 minmalwarereportingiocdetection

What you will learn

-Extract indicators of compromise a SOC can actually hunt with
-Structure a report so responders find what they need in seconds
-Turn behavior into detection and containment guidance

Two hours of unpacking and detonation are academic if the on-call responder can't turn them into a search. The point of the report is not to prove how deep you went. It's to hand a defender the exact , hashes, and paths they need to find this thing across the fleet and rip it out. Write for the person at 2 a.m. staring at an , not for a peer reviewer admiring your technique.

Lead with what to search for. The narrative comes after.

Indicators of compromise, front and center

IOCs are the atomic units a defender searches on. Every one you list should be something a can paste into a query or an hunt right now. Group them by type so they're easy to pull.

File hashes: -256 first, plus for older tools. Include the original sample and everything it dropped.
: , IP addresses, full URIs, and the string. The URI and user-agent catch variants that rotate domains.
artifacts: dropped file paths (%APPDATA%\...), keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run\...), scheduled task names, mutex names, and service names.

A mutex name is quietly one of the best indicators you can give. often creates a named mutex to avoid infecting the same host twice, and that name is frequently unique and hardcoded, so a host with that mutex is infected with near certainty.

attacker@kali

$printf 'SHA256,%s\\nC2,%s\\nDropped,%s\\nRunKey,%s\\n' "$HASH" "$C2" "$DROP" "$RUNKEY"

Emit your IOCs in a flat, greppable format your team can ingest. Better still, produce a STIX bundle or a plain CSV your SIEM imports directly. A pretty PDF that nobody can copy-paste out of is a common and avoidable failure.

Structure that respects the reader's time

Put a two-line verdict at the top: what the sample is and how bad it is. "Cobalt Strike beacon , injects into explorer.exe, beacons to xyz.top over . Priority: high." A responder reads that and knows whether to page people before they read another word.

Then the block, then the behavior narrative, then detection and . That order is deliberate: it goes from most actionable to most detailed, so someone can stop reading at any point and still have something useful.

The behavior narrative is where your dynamic and static findings turn into a story. Describe the chain in the order it happens: initial execution, unpacking, files dropped, set, injection, C2 established. Tie each step to its indicator so the reader can move from "what it does" to "what to search for" without hunting.

Confidence and provenance

Mark how you know each . "Beacons every 60 seconds" from a two-minute capture is an observation, not a confirmed interval; say so. Separate what you observed from what you inferred. A defender who trusts your report because you were honest about uncertainty will act on it faster than one second-guessing an overconfident one.

Make it detectable, not just described

The best reports include detection logic, not just indicators. A rule that matches the family across samples is worth more than one hash, because the hash dies the moment the author recompiles. Write the rule off stable strings you found: the mutex name, a distinctive command string, a hardcoded URI path.

draft and test a YARA rule from your findings

# rule with strings: the mutex, C2 URI, and a unique code string; condition: 2 of them

$nano family_beacon.yar

# test it against your sample set: it should hit the family and not benign files

$yara family_beacon.yar /samples/

# how a responder hunts the rule across a host

$yara -r family_beacon.yar C:\Users\

Close with containment guidance a responder can execute: block the C2 domains and at the proxy and , kill and quarantine the dropped file by hash, delete the persistence key or scheduled task, and isolate any host that resolved the C2 domain. Concrete actions, not "monitor for suspicious activity."

Handle the sample and report responsibly

The report itself often contains live IOCs and sometimes sample fragments; treat it as sensitive and it only through channels cleared for it. If your analysis touched a real , coordinate disclosure with the affected party before publishing anything, and never a 's indicators publicly without sign-off.

You can only include one indicator in a rushed report. Which is most durable against the author simply recompiling the malware?

Exercise

Take the findings from your dynamic-analysis run and write a one-page report: a two-line verdict, an IOC block grouped by type (hashes, network, host artifacts), a short behavior narrative in execution order, and three concrete containment actions. Then write a minimal YARA rule with at least two strings and a condition that requires both.

Strings and Unpacking