# Cyber Threat Intelligence Report Template

*[Use this template to produce a defensible, structured cyber threat intelligence (CTI) report on observed adversary activity. It draws on established intelligence frameworks but intentionally omits some formal mechanics to keep it practical for day-to-day CTI work.*

*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/cyber-threat-intel-report-template) 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.]*

## Contents

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

- [Executive Summary](#executive-summary)
- [Actor Snapshot](#actor-snapshot)
- [Methodology](#methodology)
- [Activity Overview](#activity-overview)
- [Representative Adversary Techniques](#representative-adversary-techniques)
- [Indicators of Compromise](#indicators-of-compromise)
- [Defensive Implications](#defensive-implications)
- [Attribution Analysis](#attribution-analysis)
- [Anticipated Activity](#anticipated-activity)
- [Strategic Analysis (Optional)](#strategic-analysis-optional)
- [Competing Hypotheses (Optional)](#competing-hypotheses-optional)
- [About this Report](#about-this-report)

## Executive Summary

*[Provide a short paragraph that states the central claim about the activity or actor. State the confidence in this claim. Add a likelihood only when the claim is forward-looking; a retrospective conclusion needs confidence alone. This is the main takeaway for the reader.]*

### Key Findings

*[Decision questions in the table below reflect what readers need to decide; sometimes these are called Priority Intelligence Requirements (PIRs).*

*Each finding states a calibrated analytic claim, meaning what you concluded from the evidence. A finding isn't just naming a subject (like "Targeting trends"), and it isn't a raw observation (like "We saw spearphishing emails").*

*Each row pairs a decision question with the finding that answers it. Provide confidence (how strong the evidence is) on every finding. Provide likelihood (the seven-tier ladder) only when the finding is forward-looking; for a retrospective finding, mark the Likelihood cell "Not assessed" or "n/a (observed)." Three to five rows is typical.]*

| Decision question | Finding | Confidence | Likelihood |
|---|---|---|---|
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |

## Actor Snapshot

*[Include a quick summary of the actor. Use this section to help readers understand the actor's key facts at a glance. Where evidence is thin, mark a field "Unknown" or leave it blank. If the report covers several distinct groups, repeat this snapshot for each.]*

|  |  |
|---|---|
| **Internal Designator** | *[Your team's internal cluster name. If you have no internal tracking program (for example, you're synthesizing public reporting), leave this blank and lead with the most stable public alias below. Note the absence rather than inventing a name.]* |
| **Public Aliases** | *[Vendor and government names with citations. For activities with many aliases, expand this field into a structured table.]* |
| **Adversary Roles** | *[When more than one group plays a part, name each role, such as developer, operator, affiliate, initial-access broker, or facilitator. For a single actor, leave this blank or name the one role.]* |
| **Suspected Sponsor or Affiliation** | |
| **Motivation** | *[Espionage, financial gain, destructive intent, hacktivist objective, or unknown.]* |
| **Active Period** | *[Range from earliest observed activity to most recent, or "to present" if still active.]* |
| **Target Sectors** | |
| **Target Regions** | |
| **Tradecraft Summary** | *[One or two sentences naming the threat actor's signature tradecraft, such as characteristic lures, tooling families, and infrastructure patterns.]* |
| **Demonstrated Capability** | *[How effective the actor has been at achieving its objectives, based on observed outcomes such as data exfiltrated, persistence achieved, or operational disruption.]* |
| **Confidence in This Characterization** | *[Confidence: high, moderate, or low, per ICD-203 below. This characterization is retrospective, so likelihood is optional; add it only if you are making a forward-looking claim.]* |

## Methodology

This section documents the report's collection sources, gaps that limited the assessment, and analytic techniques applied.

### Collection

*[Sources used: internal telemetry, partner sharing, OSINT, government reporting, vendor reporting, etc.]*

*[Gaps: name what you couldn't see and how that limited the assessment.]*

### Analytic Techniques

*[Examples: Analysis of Competing Hypotheses (ACH) from Heuer's [Psychology of Intelligence Analysis](https://www.cia.gov/resources/csi/books-monographs/psychology-of-intelligence-analysis-2/); Key Assumptions Check, Quality of Information Check, and link analysis from the [CIA Tradecraft Primer](https://www.cia.gov/resources/csi/static/Tradecraft-Primer-apr09.pdf).]*

### Confidence and Likelihood

This report follows [Intelligence Community Directive 203 (ICD-203)](https://www.dni.gov/files/documents/ICD/ICD-203.pdf) in keeping confidence and likelihood separate. We express confidence as high, moderate, or low. Per ICD-203, we express likelihood using the seven-tier ladder:

| Likelihood Phrase | Probability Range |
|---|---|
| Almost no chance | 01-05% |
| Very unlikely | 05-20% |
| Unlikely | 20-45% |
| Roughly even chance | 45-55% |
| Likely | 55-80% |
| Very likely | 80-95% |
| Almost certain | 95-99% |

Confidence is the primary calibration and applies to every judgment in this report. Likelihood applies to forward-looking claims, meaning what may happen next. For a retrospective conclusion, such as an attribution, an actor characterization, or a measured finding, state confidence and either omit likelihood or mark it "Not assessed." Keep the two dimensions in separate sentences. Don't convert one into the other, assign a likelihood where the evidence only supports "not observed," or attach a likelihood to a directly observed measurement.

## Activity Overview

### Victim Profile

*[Document who was affected. Targeting may be deliberate or opportunistic. Use the table below to summarize the activity by sector and region when multiple victims are involved. The Victims column can hold a count (e.g., "12"), a share of total (e.g., "~40%"), specific named victim organizations, or a mix.*

*Include a narrative description alongside or instead of the table when you need to describe the attacker's targeting style or include context that doesn't fit cleanly in the table.]*

| Sector | Region | Victims | Notes |
|---|---|---|---|
|  |  |  |  |

### Activity Date Range

*[Date range of observed activity.]*

### Related Reporting

*[Cite advisories, vendor blogs, indictments, internal team reports, partner-shared analyses, and other sources covering the same activity.]*

## Representative Adversary Techniques

This report uses the [MITRE ATT&CK®](https://attack.mitre.org) framework to characterize adversary behavior. The table below lists the most representative techniques observed.

*[Adversary activity often involves dozens of techniques. Pick the ones that most clearly characterize the activity. If useful for purple-team handoffs, supply the full set as an [ATT&CK Navigator](https://mitre-attack.github.io/attack-navigator/) JSON layer separately.]*

| Tactic | Technique ID | Technique Name | Procedure Observed |
|---|---|---|---|
|  |  |  |  |

## Indicators of Compromise

*[The rows are based on [David Bianco's Pyramid of Pain](https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html), which ranks indicator types by how costly each is for the adversary to change, extended here with cloud-resource and identity tiers.*

*Identities cover user accounts, OAuth tokens, service principals, and API keys; cloud resources cover bucket URIs, IAM policies and roles, cloud function IDs, and cloud API endpoints. The group names that vendors or governments assign to an actor, such as UNC, DEV, or APT numbers, are not indicators. Put them in the Actor Snapshot and Attribution Analysis, not here.*

*Pick the most informative indicators per tier; leave a tier's row blank if no indicators apply. Supply the full set separately, such as a STIX bundle, when consumers need to ingest it into their tooling.*

*Use the Context column to describe each indicator's role in the activity; for example, command-and-control server, phishing infrastructure, exfiltration host. Label supply-chain and version-control artifacts there, such as a commit hash or a trojanized package version, so their role is clear.]*

| Type | Indicator | Context |
|---|---|---|
| Hash Values |  |  |
| IP Addresses |  |  |
| Domain Names |  |  |
| Cloud Resources |  |  |
| Network Artifacts |  |  |
| Host Artifacts |  |  |
| Identities |  |  |

## Defensive Implications

*[Write a brief prose summary of the section's defensive takeaways (replacing this bracketed guidance) so the reader has an at-a-glance view across this entire section. Note where readers should evaluate their existing controls against the recommended defenses to identify gaps. If responders need procedures for a live incident, point them to the [Incident Response Report Template](https://zeltser.com/incident-response-report-template) as a companion document.]*

### Defensive Measures

*[List defensive actions in the table below, ordered by priority (highest-impact first). Consider using [MITRE D3FEND™](https://d3fend.mitre.org) vocabulary and methodology. In the Addresses column, name the relevant technique from the Representative Adversary Techniques section (by ID or name), or write "Broadly applicable" for defenses not tied to a specific attack technique. Use the Notes column for context or pointers to the detail subsections below.]*

| Defensive Action | Addresses | Notes |
|---|---|---|
|  |  |  |

### Detection Engineering Content

*[Provide detection rules (Sigma, KQL, Splunk SPL, EQL, etc.) or general guidance about behaviors to monitor. Use the Notes column for false-positive characteristics, log source dependencies (what telemetry the rule requires), or any per-row context.]*

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

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

### Vendor Detection Coverage

*[Name the vendor products or platforms with native detections, and link to the relevant detection content or documentation. Write as prose or use a table or bulleted list when listing multiple products.]*

## Attribution Analysis

*[Write the attribution claim based on your analysis of the six signals below (replacing this bracketed guidance), and state your confidence in it. Be specific about what your evidence supports, such as a behavior pattern, a campaign, or a sponsor.*

*Keep confidence (evidence strength) and any forward-looking likelihood in separate sentences. For example, "Activity is consistent with the TA-2026-04 campaign (publicly tracked as APT99). We hold this attribution with high confidence. Continued targeting of the sector is very likely."]*

*[Capture the six attribution signals in the following table. See [Six Signals for Threat Attribution](https://zeltser.com/six-signals-for-threat-attribution) for guidance. Use the Finding column for your conclusion for that signal (one sentence). Use the Notes column for the supporting analysis, such as specific evidence, alternative readings considered, and what the signal can't tell you.*

*Say where each signal's evidence comes from. Signals that all trace to one source or one pivot count as one, not several, so don't present them as independent support. Summarize how the signals converge. If they don't, or if more than one group is involved, say so plainly.]*

| Signal | Finding | Confidence | Notes |
|---|---|---|---|
| Victim |  |  |  |
| Targeting Intent |  |  |  |
| Tradecraft |  |  |  |
| Tooling |  |  |  |
| Identity Artifacts |  |  |  |
| Infrastructure |  |  |  |

## Anticipated Activity

*[Forward-looking analysis of what may come next and the conditions that would shift the picture.]*

**Expected near-term activity:**

**Conditions that would expand or contract the activity:**

## Strategic Analysis (Optional)

*[This section addresses the broader significance of the activity: what the campaign means at a geopolitical, commercial, or ideological level. Include this section only when such analysis is in scope of the report.]*

*[Write a brief prose summary (replacing this bracketed guidance), and capture each strategic implication in the table below. State confidence on each implication; use the Likelihood column only for forward-looking implications and mark it "Not assessed" otherwise. Use the Notes column for the supporting reasoning behind each implication.]*

| Strategic Implication | Confidence | Likelihood | Notes |
|---|---|---|---|
|  |  |  |  |
|  |  |  |  |

## Competing Hypotheses (Optional)

*[Produce this section internally if more than one hypothesis is viable. Attach it to the distributed report selectively, when readers benefit from seeing the analytic work behind the conclusion. In practice, analysts often keep this kind of analysis in their working file rather than the reader-facing version.]*

This section uses the [Analysis of Competing Hypotheses (ACH)](https://www.cia.gov/resources/csi/books-monographs/psychology-of-intelligence-analysis-2/) method to evaluate candidate hypotheses against the evidence. In the matrix below, each cell scores whether the evidence is Consistent (C), Inconsistent (I), or Not Applicable (N/A) for that hypothesis. The leading hypothesis is the one with the fewest inconsistencies.

*[List candidate hypotheses as columns (plausible enough to test) and relevant evidence as rows, such as specific observations, technical findings, victim characteristics, attribution signals, or contextual factors. For example, the evidence "Activity timing aligns with Moscow business hours" is Consistent with a Russian-actor hypothesis and Inconsistent with Chinese or Iranian ones.]*

| Evidence | Hypothesis A | Hypothesis B | Hypothesis C |
|---|---|---|---|
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |

*[After completing the matrix above, capture the conclusions in the fields below.]*

**Leading hypothesis:**

*[The hypothesis with the fewest inconsistencies in the matrix above. State your confidence in it. For example, "Hypothesis A (Russian-actor) is the leading hypothesis, which we hold with high confidence."]*

**Alternative hypotheses not ruled out:**

*[Other candidate hypotheses from the matrix that still have relatively few inconsistencies. The matrix shows the scoring; this field is the analyst's explicit judgment about which alternatives remain serious enough to disclose.]*

**What would change the assessment?**

*[Name the specific evidence that would shift the leading hypothesis. This makes the assessment falsifiable.]*

## 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. When recipients need guidance on what to do with the indicators, add a [Permissible Actions Protocol](https://github.com/MISP/misp-taxonomies/tree/main/PAP).]* |
| **Follow-Up Contact** | *[Specify the person to whom the reader should direct follow-up questions and information requests about this report.]* |

### Report Changelog

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