Diamond Model

Author: Roger C.B. Johnsen

Introduction

The Diamond Model of Intrusion Analysis is a useful framework for structuring what we know, what we think we know, and what we still need to investigate during threat hunting and intrusion analysis.

The model was introduced by Sergio Caltagirone, Andrew Pendergast and Christopher Betz in 2013. It describes intrusion activity through four connected elements:

• adversary
• infrastructure
• capability
• victim

Those four elements form the “diamond”. For threat hunters, the value of the model is not that it magically identifies an attacker. It does not. The value is that it gives the analyst a structured way to organise observations, connect evidence and avoid treating isolated indicators as complete understanding. A suspicious IP address is not the full story. A malware sample is not the full story. A compromised host is not the full story.

The Diamond Model helps the hunter ask:

• What do we know about the adversary?
• What infrastructure is involved?
• What capability or behaviour is being used?
• Who or what is the victim?
• How do these elements connect?

That makes it useful as both an analytical framework and a documentation aid.

The Diamond Model does not solve the intrusion for you. It helps you organise the intrusion so you can reason about it.

– Roger Johnsen

The Four Core Elements

The Diamond Model is built around four vertices.

These elements are connected. That connection is the point. An adversary uses a capability over infrastructure against a victim.

In practice, we may not know all four elements at the beginning of an investigation. That is normal. The model still helps because it gives us a place to put what we do know and a way to see what is missing.

For example:

The model does not require perfect knowledge. It supports structured uncertainty.

Adversary

The adversary represents the actor behind the intrusion activity. This may be:

• a criminal group
• a state-sponsored actor
• an insider
• an initial access broker
• a ransomware affiliate
• a contractor or third party
• an unknown actor

In real investigations, the adversary is often the hardest part of the diamond to complete. Attribution is difficult, and threat hunters should be careful not to overstate confidence.

It is usually safer to describe what we observe than to claim who did it too early.

Weak statement:

This was actor X.

Better statement:

The observed behaviour overlaps with techniques reported for actor X, but the available evidence is not sufficient for attribution.

That distinction matters. A threat hunter may use threat intelligence, MITRE ATT&CK mappings, infrastructure overlaps, malware characteristics, timing, targeting and tradecraft to form an assessment. But assessment is not proof.

Attribution is useful when it is supported. It is dangerous when it becomes a shortcut.

– Roger Johnsen

Infrastructure

Infrastructure describes what the adversary uses to communicate, deliver, stage or control activity. This may include:

• IP addresses
• domains
• URLs
• command-and-control servers
• phishing infrastructure
• compromised hosts
• cloud services
• VPNs
• proxies
• malware delivery sites
• email infrastructure
• remote access tooling
• abused legitimate platforms

Infrastructure is often where investigations start because it is visible in logs. DNS logs, proxy logs, firewall logs, EDR telemetry and email logs may all reveal infrastructure.

But infrastructure should not be treated in isolation. An IP address may be suspicious, benign, compromised, shared, reused or short-lived. A domain may be part of attacker infrastructure, but it may also be a legitimate service abused by the attacker.

The useful question is not only:

Is this infrastructure bad?

The better question is:

How is this infrastructure connected to the capability, the victim and the wider activity?

That shift prevents the investigation from becoming a simple indicator lookup.

Capability

Capability describes what the adversary uses or does. This may include:

• malware
• scripts
• exploits
• credential theft
• phishing
• scheduled tasks
• remote services
• command-line activity
• living-off-the-land techniques
• lateral movement
• persistence mechanisms
• data staging
• exfiltration methods

In threat hunting, capability is often the most useful part of the model because it connects directly to behaviour. Infrastructure changes quickly. Indicators expire. Actor names may be uncertain. But capability often leaves patterns that can be searched for, baselined and turned into detections.

For example:

This is why the Diamond Model works well together with MITRE ATT&CK. ATT&CK can help describe the behaviour. The Diamond Model can help place that behaviour in relation to the adversary, infrastructure and victim.

Victim

The victim is the target of the activity. This may be:

• a user
• a workstation
• a server
• a cloud tenant
• an identity
• an application
• a business process
• a department
• an organisation
• a third party

Threat hunters should be careful not to define the victim too narrowly. A single compromised endpoint may be the first visible victim, but the real target may be a business process, privileged identity, database, file share or cloud environment.

For example:

The victim vertex helps the hunter ask why this target matters. That question is important. Without victim context, the investigation may remain technically interesting but operationally incomplete.

Meta-Features

The Diamond Model also includes meta-features that help describe the activity more precisely. Useful meta-features include:

These features help the analyst build chronology and context. Meta-features make the model operational. Timestamp and phase help the hunter understand sequence. Direction helps describe how activity moved between systems, users or infrastructure. Result helps separate attempted activity from successful activity. Methodology helps connect the observation to tradecraft.

For example:

For example, two events may involve the same domain and same workstation. But if one event is an initial download and the other is command-and-control traffic three hours later, they represent different parts of the intrusion.

The diamond is useful, but the timeline matters too. This is where the Diamond Model starts to support timeline reconstruction, detection engineering and intrusion graph thinking.

Example From The DFIR Report

One strong practical use of the Diamond Model can be seen in reports from The DFIR Report .

For example, in their report IcedID Brings ScreenConnect and CSharp Streamer to ALPHV Ransomware Deployment , they use the model to organise important intrusion details from the investigation.

This is useful because it shows the Diamond Model as more than a theoretical framework. It becomes a compact way to document adversary, infrastructure, capability and victim information from real intrusion activity.

Using the Diamond Model During Threat Hunting

During a threat hunt, the Diamond Model can be used as a note-taking and reasoning structure. As observations appear, place them into the model.

This helps the hunter avoid losing track of the investigation. It also makes gaps visible.

For example:

The model helps structure both evidence and uncertainty.

A good framework does not remove uncertainty. It gives you a disciplined way to handle it.

– Roger Johnsen

Pivoting Through the Diamond

The Diamond Model becomes especially useful when it is used for pivoting. Each vertex can become a starting point for the next question. The hunter does not only document adversary, infrastructure, capability and victim. The hunter moves between them.

For example, a hunt may start with one suspicious workstation contacting an unusual external domain. That first observation gives the hunter infrastructure and victim context.

From there, the hunter can pivot:

• Infrastructure → other hosts contacting the same domain
• Victim → other suspicious activity on the same workstation
• Capability → similar PowerShell or script execution elsewhere
• Adversary assessment → threat intelligence describing related behaviour

This is where the Diamond Model becomes practical. It helps the hunter decide which direction to investigate next without losing the structure of the case.

In practice, investigations often involve multiple connected diamonds rather than one static diamond. One event may describe initial access. Another may describe command and control. Another may describe lateral movement or exfiltration. Linked together over time, those diamonds start to form an intrusion graph.

That is also why the timeline matters. A domain contacted during payload download may have a different meaning than the same domain contacted repeatedly during command-and-control activity.

Repeated pivots across capability, infrastructure and victim context often reveal stable patterns. Those patterns are useful beyond the current investigation. They may become detection logic, triage guidance, enrichment requirements or follow-up hunts.

The Diamond Model is not only a way to document what happened. It is a way to decide where to pivot next.

– Roger Johnsen

Practical Example: Insider Threat and Data Exfiltration

Consider an overly simplified insider threat scenario. The concern is that sensitive data may be leaving the organisation through unusual network activity. The hunter starts by reviewing network traffic and identifies several unusual communication patterns. Each communication point is documented under infrastructure.

The investigation then moves through the diamond.

• First, the hunter documents infrastructure: external domains, IP addresses, cloud services and communication patterns.
• Next, the hunter documents capability: archive creation, large data movement, access to sensitive file paths and outbound transfer behaviour.
• Then the hunter documents victim context: the device, user, department, data location and business role.

The adversary vertex is more difficult. In an insider case, the adversary may be an internal user, a compromised account or an external actor using a valid account. That distinction cannot be assumed.

A careful statement would be:

The observed activity involves a valid internal account transferring large amounts of data to an external file-sharing service outside normal business hours. The current evidence does not determine whether this is malicious insider activity, compromised-account activity or an approved business process.

That is more useful than jumping directly to “insider threat”. The Diamond Model helps keep that distinction visible.

Combining the Diamond Model With MITRE ATT&CK

The Diamond Model and MITRE ATT&CK answer different questions.

They work well together. For example, if the hunter observes scheduled task creation, ATT&CK can help describe the technique. The Diamond Model helps connect that technique to the victim, infrastructure and possible adversary context.

This combination is useful because ATT&CK provides vocabulary, while the Diamond Model provides relationship structure.

When I map observed TTPs, I often use the MITRE ATT&CK Navigator to organise techniques and compare behaviour against known reporting. This does not prove attribution, but it helps structure the adversary assessment and makes the reasoning easier to share.

The mistake is to use either framework mechanically. ATT&CK mapping alone does not explain the intrusion. The Diamond Model alone does not validate the behaviour. The analyst still has to reason.

Using the Model for Handover

One practical value of the Diamond Model is handover. Threat hunts often produce findings that need to be passed to SOC, incident response, detection engineering, threat intelligence or another team. A diamond-structured summary helps the receiving team understand what was found and what remains uncertain.

Example handover:

This is much clearer than handing over a collection of raw indicators. It also helps avoid overstating conclusions. The receiving team can see what is known, what is suspected and what should happen next.

What Usually Goes Wrong

Several mistakes are common when analysts use the Diamond Model.

The model should help the analyst reason. It should not become a decorative diagram added at the end of a report.

Working Position for This Book

The Diamond Model is useful because it helps threat hunters structure intrusion activity around relationships.

It gives the analyst a disciplined way to organise:

Adversary.
Infrastructure.
Capability.
Victim.

But the model is not a shortcut to attribution, and it does not replace investigation.

For this book, the Diamond Model is best treated as a practical reasoning and documentation tool. It helps the hunter connect observations, identify gaps, avoid isolated indicator thinking and prepare better handover.

Use the Diamond Model to organise what you know, expose what you do not know, and explain how the pieces connect.

– Roger Johnsen

Resources

• Diamond Model of Intrusion Analysis - Summary
• Recorded Future: What is the Diamond Model of Intrusion Analysis?
• Threat Intelligence Lab: Understanding the Diamond Model of Intrusion Analysis
• ThreatConnect: The Importance of the Diamond Model
• The DFIR Report
• MITRE ATT&CK Navigator

Revision