A Beginner's Guide to Reading a Malware Analysis Report

A threat intelligence report can look like a document written in code: long hexadecimal strings, ATT&CK identifiers, defanged URLs, a verdict buried on the last page. Everything you need is in there. The trick is knowing which parts to read first, and which parts are just background.

Most reports follow the same skeleton, whether they come from a security vendor, a national CERT, or your own incident response team. Once you recognise the bones, a twenty-page analysis becomes a ten-minute read you can actually act on.

What Is Actually Inside a Threat Report

Nearly every report contains the same five blocks: metadata (who wrote it, when, and where the sample came from), a summary with the verdict, a technical analysis of what the malware does, a list of indicators, and detection or mitigation guidance.

Read the summary first. It usually names the family, the delivery method, and the verdict in plain language. If you only have time for one paragraph, that is the one. Then jump to the indicators, because those are the parts you can feed into your own tooling. Come back to the technical analysis afterwards, when you want to understand why the author reached that conclusion.

Pay attention to dates. A report published eighteen months ago may describe domains that were taken down, re-registered, or recycled by someone else entirely. Old indicators are context, not a blocklist.

Hashes: The File's Fingerprint

A hash is a fixed-length value calculated from a file's contents. Change one byte and the hash changes completely. That makes it a reliable way to say "this exact file, and no other." Reports usually list MD5, SHA-1, and SHA-256. Prefer SHA-256 for comparisons: MD5 and SHA-1 are still useful as labels, but both have known collision problems, so they are weaker as proof of identity.

A few practical notes. Identical hashes always mean identical files; different hashes do not necessarily mean different malware, since repacking or adding a byte of padding changes the value. Analysts sometimes include a fuzzy hash or an import hash to group samples that are variants of the same thing, which is more useful than a single exact match.

When you have the SHA-256, look it up in a multi-engine scanning service. You will see whether other vendors classify the file the same way, what family names they use, and when it was first seen. Disagreement between engines is normal and tells you the sample is unusual or recently changed.

IOCs: The Breadcrumbs

Indicators of compromise are the observable leftovers of an intrusion. They are not all equally trustworthy, and knowing the difference saves you from bad blocking decisions.

• File names and paths. Weak on their own. Attackers reuse names like svchost.exe or update.tmp precisely because they blend in.
• Hashes. Strong for that one file. Useless once the attacker rebuilds it.
• Domains and URLs. Medium strength. Check how old the domain is and whether it looks like a throwaway before you block it broadly.
• IP addresses. The weakest of the network indicators. Shared hosting, content delivery networks, and cloud ranges mean one address can serve thousands of unrelated sites.
• Registry keys, mutexes, and service names. Often distinctive and excellent for host-based hunting, because malware needs them to persist or avoid running twice.
• Email artefacts. Sender patterns, subject lines, and attachment names are useful when you are filtering phishing at the gateway.

You will see indicators written in a defanged form, such as hxxp://evil[.]example[.]com. That is simply a safety convention so nobody clicks a live malicious link. Un-defang them only inside tooling that is meant to handle them.

Indicators also age. Infrastructure is cheap and disposable, so network indicators tend to go stale quickly, while host artefacts often stay valid far longer. When a report includes an expiry date or a "first seen" column, treat it as real information rather than boilerplate.

TTPs: Behaviour You Can Hunt For

Tactics, techniques, and procedures describe how an attacker operates rather than what specific tool they used. Most reports map them to MITRE ATT&CK identifiers, so you might see something like T1566 for phishing, T1059 for command and scripting interpreter, or T1547 for boot or logon autostart.

These matter more than indicators over the long run. An attacker can register a new domain in minutes, but changing from PowerShell-based execution to something else takes effort and carries risk. Behaviour also survives takedowns, sinkholes, and sample rebuilds.

To use them, translate each technique into a question about your own environment. If the report describes scripting interpreters being used to download a payload, ask whether you log those processes and whether you would notice an unusual parent-and-child pairing on a workstation. That question is worth more than another hundred domains on a blocklist.

Tip: if a report lists no indicators you can block, it is not useless. It may still contain the most durable value in the whole document — the behavioural description.

Verdicts, Confidence, and Severity

Verdicts usually fall into a small set of buckets: malicious, suspicious, unwanted or potentially unwanted, benign, and unknown. Confidence is separate and describes how sure the analyst is. Severity is separate again and describes the impact if the sample were to run successfully in your environment.

The combinations guide your response. High confidence plus malicious means act now. Low confidence plus suspicious means hunt quietly and gather your own evidence rather than declaring an incident. Note also that a verdict applies to the sample, not to your organisation — a "benign" tool in the report can still be abused inside your network.

Detection names deserve a caution. Generic labels such as Trojan.Generic tell you roughly what the engine thought, not much else. Named families are more informative because you can look up their usual behaviour.

Walking Through a Report, Top to Bottom

1. Read the title, publication date, and author. A vendor report and an internal incident write-up serve different purposes.
2. Read the summary and note the verdict and confidence level.
3. Copy the SHA-256 and check it in a multi-engine scanner.
4. Collect the indicators into a scratch file, separating network indicators from host indicators.
5. Read the behaviour section and write down any ATT&CK identifiers plus a one-line description of each.
6. Look for detection and mitigation guidance, including any gaps the author admits to.
7. Note what the sample did not do. Missing capabilities tell you what the analyst could not observe.

Turning a Report Into Action

Finish by converting the report into a short, dated task list. Add network indicators to your DNS or proxy filtering with an expiry date, so they do not linger for years. Sweep your endpoints for the host artefacts — file paths, registry keys, mutexes — using whatever endpoint tooling you already have.

Then pick one or two techniques and check whether you would detect them. Write the rule, test it, and log the result. If the report is relevant to peers or your security team, share the summary and what you changed as a result.

One last caution: before blocking an IP address or a cloud domain outright, confirm it is not shared infrastructure. Blocking a content delivery network address because a sample phoned home to it can break legitimate services, and the attacker will have moved on anyway.

Photo: AlphaTradeZone / Pexels