# Malware Analysis Report Template

*[Use this template to produce a structured, informative report on a malware sample, whether a single file or a set of related artifacts such as a dropper plus its payload chain. When the sample is a set, document each artifact's role and details in the [Component Inventory](#component-inventory) and organize the analysis by role.*

*The text in square brackets is meant to guide you; remove it before finalizing the report. The title above is generic; rename to match your specific report.*

*This template was [created by Lenny Zeltser](https://zeltser.com/malware-analysis-report) and distributed under the [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/) (CC BY 4.0). The license covers the template; any report you produce with it is yours.]*

*[Specify this document's classification or handling marking, such as a [TLP](https://www.first.org/tlp/) label, so the sharing restriction is visible before the report is read or shared.]*

## Contents

*[Update if you add, remove, or reorder sections.]*

- [Executive Summary](#executive-summary)
- [Sample Snapshot](#sample-snapshot)
- [Malware Family Identification](#malware-family-identification)
- [Component Inventory](#component-inventory)
- [Runtime Requirements](#runtime-requirements)
- [Sources](#sources)
- [Capabilities](#capabilities)
- [Indicators of Compromise](#indicators-of-compromise)
- [Analysis Details](#analysis-details)
- [What We Don't Know](#what-we-dont-know)
- [Infection Vector (Optional)](#infection-vector-optional)
- [Detection Engineering (Optional)](#detection-engineering-optional)
- [About this Report](#about-this-report)
- [Appendix: Analysis Environment](#appendix-analysis-environment)
- [Appendix: Analysis Scripts (Optional)](#appendix-analysis-scripts-optional)

## Executive Summary

*[Provide a paragraph that explains what the malware sample is, how it gets in, and what it does. This is the main takeaway for the reader who only reads the summary. Write it to stand on its own when it's handed to a non-analyst, such as a manager deciding whether to escalate. If your audience is a specific organization, include organization-specific context, including significance.]*

## Sample Snapshot

*[Fill in the table to provide a quick-reference profile for the sample.]*

|  |  |
|---|---|
| **Malware Family** | *[Lead with the family you believe this sample belongs to and your confidence in that call, highlighting the most likely conclusions from the [Malware Family Identification](#malware-family-identification) section.]* |
| **Key Capabilities** | *[A short list of the sample's representative capabilities. This should be an excerpt of the contents of the [Capabilities](#capabilities) section.]* |
| **Target Platform** | *[Where the sample runs, such as an OS or an ecosystem (e.g., web browser extensions, npm packages, AI agent skills). Summarize the platform context from the [Runtime Requirements](#runtime-requirements) section.]* |
| **Primary Artifact** | *[The artifact this report centers on. Name it by its Role from the [Component Inventory](#component-inventory) and give its authoritative identifier, a SHA-256 for a file or the ecosystem identifier. Full per-artifact hashes are in the [Indicators of Compromise](#indicators-of-compromise) section.]* |
| **Infection Vector** | *[How the sample arrives, such as phishing attachment, drive-by download, or supply-chain compromise. Summarize from the [Infection Vector](#infection-vector-optional) section.]* |

## Malware Family Identification

*[Capture the family you believe this sample belongs to, the evidence behind the call, and your confidence (high, moderate, or low). Add rows when considering alternative possibilities. Basis is the evidence type (YARA rule, string overlap, code reuse, behavioral pattern, vendor detection).]*

| Family | Basis | Confidence |
|---|---|---|
| *[BRICKSTORM]* | *[YARA rule match against Mandiant's published signature]* | *[High]* |

This report rates confidence in family identification as high, moderate, or low, following [ICD-203](https://www.dni.gov/files/documents/ICD/ICD-203.pdf).

## Component Inventory

*[List each file or artifact in the sample, one per row. Use Role for the component's primary role (e.g., dropper, loader, payload, config, decoy). Per-component identifiers and context (e.g., bundle IDs like com.example.app), if relevant, can go into Notes. List per-component hashes in the [Indicators of Compromise](#indicators-of-compromise) section's Hash Values row, labeled by Role. The table will have one row if the sample has a single file.*

*A row may lack a file name or hash, such as an in-memory stage or a package identified only by name and version. Fill what you have and leave the rest blank rather than dropping the row. When the sample's identity is a version chain rather than a set of files, such as a package that turned malicious in a specific release, note the relevant versions, for example the last clean and the first malicious, by Role.]*

| Role | File Name | File Type | Notes |
|---|---|---|---|
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |

*[For multi-component samples, also add a short paragraph or numbered list below the table describing how the components flow into each other, such as "Stage 1 dropper extracts Stage 2 script, which spawns Stage 3 PowerShell payload." Omit for single-file samples.]*

## Runtime Requirements

*[Document what the sample needs to run. For OS-targeted samples, examples include required DLLs, configuration files, registry keys, network resources, and runtime versions. For ecosystem-targeted samples, examples include required permissions, manifest declarations, host application versions, marketplace identifiers, and abused APIs. Distinguish bundled dependencies from those the sample expects to find on the target system. For a native executable, note the CPU architecture, endianness, and whether it is statically or dynamically linked. A statically linked big-endian MIPS binary, for example, suggests an embedded or IoT target rather than a desktop.]*

## Sources

This section identifies where the sample and supporting data came from.

*[Document sources used, such as internal telemetry, third-party sharing, OSINT, and partner-shared samples. Common OSINT sources include [VirusTotal](https://www.virustotal.com), passive-DNS lookup services, and shared threat-intelligence platforms. Note where the sample was first observed and any chain-of-custody details.]*

## Capabilities

This report uses the [Malware Behavior Catalog](https://github.com/MBCProject/mbc-markdown) (MBC) to characterize what the sample does.

*[Above the table, write a brief prose summary of the sample's top-level MBC Objectives. Examples include Defense Evasion, Discovery, Credential Access, Collection, Impact, Anti-Behavioral Analysis, and Anti-Static Analysis. Pick the behaviors that most clearly characterize the sample. If the sample collects or exfiltrates data, name what it targets, such as credentials, session tokens, SMS or two-factor codes, or financial data. Use the Notes column for per-behavior caveats or specifics.*

*When an observed procedure has no fitting MBC behavior, record it under the closest MBC objective and cite the relevant [ATT&CK](https://attack.mitre.org/) technique in the Notes column, such as T1548.002 for a UAC bypass.]*

| MBC Behavior | Procedure Observed | Notes |
|---|---|---|
|  |  |  |
|  |  |  |
|  |  |  |

## Indicators of Compromise

*[The table is tiered by [David Bianco's Pyramid of Pain](https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html), from lowest to highest cost to the adversary, plus a cloud-resource tier. Pick the most informative indicators per tier and leave a tier's row blank if none apply.]*

*[Use the Context column for each indicator's role and any other useful detail (status, timing, relationships). Role examples include command-and-control server, drop site, persistence artifact, and exfiltration host. Keep role descriptions consistent with the behaviors documented in [Capabilities](#capabilities).]*

*[Supply the full set of indicators separately, such as a [STIX](https://oasis-open.github.io/cti-documentation/stix/intro) bundle or [MISP](https://www.misp-project.org/) event, when someone needs to ingest them into their tooling.]*

*[Defang URLs and bracket the dots in domains and IP addresses (e.g., hxxps://example[.]com and 192.0.2[.]1) to avoid clickable links or resolvable references.]*

*[List an indicator only when the sample actually uses it, such as a domain it resolves, an IP it contacts, or a file it drops. Strings that merely match an indicator pattern, especially ones pulled from packed or encrypted data, are not indicators on their own. Corroborate them, or leave them in the Analysis Details section.]*

| Type | Indicator | Context |
|---|---|---|
| Hash Values | *[SHA-256, an [imphash](https://www.mandiant.com/resources/blog/tracking-malware-import-hashing) for PE files, and a fuzzy hash such as ssdeep or [TLSH](https://github.com/trendmicro/tlsh). Add an MD5 or SHA-1 if your readers expect those legacy hashes. For multi-component samples, give each component its own row and name its Role from the Component Inventory in the Context column.]* | |
| IP Addresses | | |
| Domain Names | | |
| Cloud Resources | *[Bucket URIs, IAM roles, cloud function IDs.]* | |
| Network Artifacts | *[User-agent strings, URI patterns, distinctive HTTP headers, beaconing patterns.]* | |
| Host Artifacts | *[Registry keys, mutexes, named pipes, service names, dropped file paths.]* | |

## Analysis Details

*[This section presents supporting evidence behind the Executive Summary and Capabilities sections. Most readers will likely skim this section, but analysts looking to validate and build upon your work will read it carefully. If you didn't perform a subsection's analysis, keep the subsection and add a note that it wasn't performed, which usually serves the reader better than removing it. For multi-component samples, organize each subsection by component using subheadings that match the Roles in the Component Inventory, such as "### Stage 1 Dropper" or "### invoice.exe".]*

### Automated Analysis

*[Summarize what automated tooling surfaced, such as a malware sandbox detonation. Note which tools were used. Depending on the workflow, these findings may simply orient the deeper analysis that follows, or they may account for much of the analysis itself. When an automated agent or an MCP-driven toolkit produced these findings, name the tool and the analysis depth it ran so a reader can weigh and reproduce them.]*

### Static Properties Analysis

*[List the static properties worth calling out and what each one tells you, rather than dumping every field. In the Property column, note the observation, such as entry point, packing or obfuscation, file or section entropy, codesigning status, key strings, embedded resources, imports and risky API patterns, exports, section hashes, or compile timestamp. In the Significance column, explain why it matters, such as high entropy suggesting packing, a PDB path revealing a possible attribution detail, or an imphash matching a known family. Note any matches to related samples via imphash, ssdeep, or TLSH. If the sample is packed or encrypted, say so and name the packer when you can, then state whether these properties describe the packed form or an unpacked one you produced.]*

| Property | Significance |
|---|---|
|  |  |
|  |  |

### Behavioral Analysis

*[Document what the sample does when executed in a controlled environment. Cover file system activity, registry activity, process activity, network activity, persistence, and privilege escalation. Cite the observations behind each claim.]*

### Memory Analysis

*[Document findings from memory forensics, such as rogue processes, injected or hollowed code, API hooks, unpacked payloads recovered from memory, and in-memory configuration or strings. Note the capture method and the tools used.]*

### Code Analysis

*[Document code-level findings from static disassembly, decompilation, emulation, and dynamic debugging. Reference instruction addresses or function names so other analysts can replicate the work.]*

## What We Don't Know

*[List what you couldn't resolve, trigger, or verify, and the source or methodology limitations behind these unknowns (such as inability to detonate in a representative environment, missing C2 telemetry, or restricted access to the original delivery context).]*

## Infection Vector (Optional)

*[Document how the sample reached the target, if known, referencing [MITRE ATT&CK Initial Access](https://attack.mitre.org/tactics/TA0001/) techniques where applicable. Examples include phishing attachment, drive-by download, supply-chain compromise, removable media, and exploit kit. Note the attack chain that preceded the sample's installation if the data shows it. Include the specific distribution URL or source path when known, such as the direct download link, watering-hole site, or app store listing. Write as a narrative paragraph or numbered list.]*

## Detection Engineering (Optional)

*[Provide detection logic that generalizes beyond the atomic indicators in the [Indicators of Compromise](#indicators-of-compromise) section, such as a [YARA](https://virustotal.github.io/yara/) rule keyed to code or string patterns that catches the family rather than a single listed hash. Behavioral hunting guidance, such as the combination of artifacts or activity to watch for, also belongs here. [Sigma](https://sigmahq.io/) and other SIEM or EDR rules are optional here, since they depend on the log sources and telemetry where they'll run, and are often better written by the team that runs those tools. Use the Notes column for log-source dependencies, false-positive characteristics, or per-row context.]*

| Detection Content | Notes |
|---|---|
|  |  |
|  |  |

*[Include a link to where the rule code is stored, such as a separate file or repository.]*

## About this Report

|  |  |
|---|---|
| **Report Title** | |
| **Author(s) and Organization** | |
| **Publication Date** | |
| **Report Classification** | *[Mark the report's sensitivity using your organization's data classification scheme. For external sharing with the security community, [TLP](https://www.first.org/tlp/) is a common option.]* |
| **Follow-Up Contact** | *[Specify the person responsible for follow-up questions about this report.]* |

### Report Changelog

| **Date** | **Author** | **Change Description** |
|---|---|---|
|  |  |  |

## Appendix: Analysis Environment

*[Document the environment in which the analysis was conducted so other analysts can replicate the work. Cover the analysis distro and version, such as [REMnux](https://remnux.org) or [FLARE VM](https://github.com/mandiant/flare-vm). Include the sandbox configuration, the network isolation setup, and, if relevant, tool versions. Note any environment-specific assumptions that affect the findings. If an automated or agentic tool drove the analysis, such as an MCP server orchestrating a toolkit, record it here with its version and the analysis depth.]*

## Appendix: Analysis Scripts (Optional)

*[Optionally, link the scripts you wrote or used to analyze the sample and reproduce the findings, such as config extractors, deobfuscation or unpacking scripts, and analysis notebooks. Point to where they're stored, such as a separate file or repository. Omit this appendix if you will not be sharing such scripts.]*