Diamond Model of Intrusion Analysis: A Framework for Advanced Threat Intelligence

Blocking one malicious IP address is not the same as understanding an intrusion. If your team only chases hashes, domains, and firewall indicators, you can stop one path and still miss the operator, the infrastructure pattern, and the victim strategy behind the attack.

Primary Use	Intrusion analysis and threat intelligence as of August 2026
Core Vertices	Adversary, infrastructure, capability, victim as of August 2026
Best For	Incident response, threat hunting, and campaign analysis as of August 2026
Main Advantage	Shows relationships between evidence instead of isolated indicators as of August 2026
Common Output	Relationship map, case notes, or intelligence report as of August 2026
Framework Pairing	Often used alongside MITRE ATT&CK and CISA guidance as of August 2026
Analyst Benefit	Improves context, confidence, and repeatability in investigations as of August 2026

Why Indicator-Only Analysis Falls Short

Indicator-only analysis is useful for fast containment, but it rarely explains the full attack. A malicious hash can disappear overnight, a phishing domain can be replaced in minutes, and command-and-control traffic can move to a new host before the first alert is fully triaged.

That is the problem with treating every alert as a standalone object. A single IP address or file hash tells you what to block right now, but it does not tell you who is operating, how the intrusion is organized, or whether the same campaign will resurface elsewhere.

Real adversaries design around simple defenses. They recompile malware, register look-alike domains, switch cloud providers, change user-agent strings, and rotate infrastructure fast enough to defeat a detection strategy that depends on one static artifact.

“A block list is a control, not an explanation.”

That distinction matters. If your team blocks a phishing domain and assumes the case is solved, you may miss the same actor using a second domain, a different delivery chain, or a new payload with the same objective.

The stronger approach is to look for repeatable patterns: the same delivery method, the same victim profile, the same tooling, and the same operational behavior. The Diamond Model of Intrusion Analysis gives analysts a way to organize that work so they can separate one-off noise from a real intrusion pattern.

• Fast containment comes from indicators like hashes and domains.
• Deeper understanding comes from connecting those indicators to behavior and relationships.
• Better decisions come from knowing whether you are handling one event or a broader campaign.

That is why indicator-only response often feels busy but incomplete. It creates motion without always creating clarity.

What Is the Diamond Model of Intrusion Analysis?

The Diamond Model of Intrusion Analysis is a framework for studying cyber intrusions through four core vertices: adversary, infrastructure, capability, and victim. It is called a diamond because the model places those four elements into a structured relationship map rather than treating them as disconnected facts.

The value of the model is not in naming the vertices. The value is in asking how each vertex relates to the others. For example, a phishing domain becomes more meaningful when you know which adversary used it, what malware it delivered, and which type of victim it targeted.

This is why the Diamond Model works well in threat intelligence and incident response. It turns an isolated event into a case narrative. Instead of saying “we saw malware,” an analyst can say “we observed a specific capability delivered through a disposable infrastructure pattern against a finance user population.”

The model also supports post-incident review. When a case closes, the relationship map becomes reusable intelligence for future hunts, detections, and executive reporting. That is a stronger outcome than a simple list of IOCs that may be stale by next week.

For analysts working toward practical cybersecurity analysis skills, this is the kind of thinking reinforced in the CompTIA Cybersecurity Analyst (CySA+) CS0-004 course: interpret telemetry, connect events, and explain why the evidence matters. The Diamond Model is one of the cleanest ways to do that.

In plain terms, the framework answers four questions:

• Who is likely behind the activity?
• What infrastructure is being used?
• How is the intrusion being executed?
• Who was targeted and why does that target matter?

That structure makes analysis more defensible because every conclusion is tied to observed relationships, not intuition alone.

For a formal definition of the broader analytical concept, see the glossary entry for Model.

What Are the Four Vertices and How Should You Interpret Them?

Adversary is the actor, group, or operator believed to be behind the intrusion. That may be a known threat group, a criminal crew, an insider, or simply an unknown operator with a provisional label. You do not need perfect attribution to use the model well.

Infrastructure is the set of systems the adversary uses to deliver, support, or hide the intrusion. That includes domains, IPs, cloud services, compromised servers, email accounts, and redirectors. For a precise glossary definition of the word in this context, see Domain.

Capability is the malware, scripts, techniques, tradecraft, or toolset used to carry out the intrusion. It may include ransomware, phishing kits, PowerShell scripts, credential theft tooling, or living-off-the-land tactics. If the payload changes but the behavior stays the same, capability analysis helps you see that continuity.

Victim is the target organization, environment, user group, or asset set. That matters because adversaries often choose victims by role, privilege, geography, industry, or exposure. A finance team, a cloud admin, and a call center user are not interchangeable targets, even if the delivery method looks similar.

Each vertex should carry confidence. Analysts should be able to say, “We know the infrastructure with high confidence, suspect the adversary with medium confidence, and have low confidence on the broader victim set.” That is much more honest and useful than pretending every answer is final.

How to read uncertainty without losing value

Uncertainty does not weaken the Diamond Model. It is part of the model’s design. A well-written case note should distinguish observed facts from inferred links and speculative attribution.

• Observed fact: the malware contacted a domain at 03:14 UTC.
• Inference: the domain is probably part of the attacker’s infrastructure.
• Speculation: the activity may belong to a known criminal group.

That separation keeps analysis honest and makes later review easier. It also reduces the chance that a junior analyst treats a guess as a conclusion.

How Do Relationships Reveal the Bigger Picture?

Relationships are the real power of the Diamond Model. A hash alone is just a file identifier. That same hash becomes more valuable when it is linked to a delivery domain, a process tree, a victim set, and a repeatable intrusion pattern.

Directional relationships matter. An analyst might document that an adversary used infrastructure to deliver a capability against a victim. That simple phrasing turns four disconnected facts into a story about behavior. It also supports better intelligence sharing because the language is explicit about what is known and how it connects.

Repeated relationships across incidents are even more important. If three separate investigations show the same lure theme, the same staging server pattern, and the same malware family, you may be looking at a campaign rather than three random events. That changes the response posture immediately.

Consider a phishing case. One email may use a disposable domain, a stolen logo, and a credential-harvesting page. Another case may use a different domain and a slightly different page design, but the same redirect chain and the same follow-on login theft behavior. The individual indicators changed, but the relationship pattern stayed the same.

The Diamond Model helps analysts ask better questions:

• Who used this infrastructure?
• What capability was delivered through it?
• Which victim profile was targeted?
• Does this relationship appear in prior cases?

When the answer to those questions repeats, you stop dealing with isolated events and start identifying adversary behavior. That is the difference between a reactive team and a real intelligence function.

For a related concept, the first time you map how evidence connects across cases, you are also doing Mapping in the literal analytical sense.

How Do You Use the Diamond Model in a Real Investigation Workflow?

A practical Diamond Model workflow starts with raw evidence, not attribution. The first step is to collect telemetry from endpoint detections, SIEM alerts, email logs, firewall data, DNS records, sandbox reports, and authentication logs. Those sources give you the raw material for building the four vertices.

1. Gather the first evidence set. Pull alerts from the SIEM, EDR console, email gateway, and network sensors. Capture the exact timestamps, hostnames, user IDs, domains, hashes, and process names before they roll off or get normalized.

   If you are investigating a suspected intrusion, preserve the original event IDs and log sources. That makes it possible to validate the timeline later and avoids confusion caused by copied screenshots or partial summaries.

2. Map each artifact to a vertex. Ask whether the evidence points to adversary, infrastructure, capability, or victim. A suspicious email sender may belong in infrastructure, while a PowerShell download chain belongs in capability and the target mailbox belongs in victim.

   At this stage, do not force every clue into a perfect answer. Some artifacts will support multiple vertices, and some will remain unresolved until more evidence arrives.

3. Expand the map with supporting artifacts. Add child details like file hashes, parent and child processes, C2 domains, certificate fingerprints, cloud hostnames, and user accounts. In Windows environments, for example, a process tree from powershell.exe to rundll32.exe to a dropped DLL may tell you more than the initial alert ever did.

   This is the point where tools like EDR, sandbox detonation, and packet capture become critical. They let you see whether the artifact is part of a one-time event or a repeatable tradecraft pattern.

4. Track relationships as the case evolves. Each new artifact should either strengthen, weaken, or redirect your current hypothesis. If a domain appears in two unrelated cases, that raises the possibility of shared infrastructure, a reused kit, or an upstream service being abused by multiple actors.

   Keep notes on source reliability and confidence. A DNS log with direct observation is not the same as a third-party report, and both should be labeled clearly.

5. Use the map to guide response. If the victim vertex shows privileged accounts are involved, prioritize credential resets and session revocation. If the infrastructure vertex shows cloud-hosted command-and-control, block the relevant domains and inspect proxy logs for lateral movement.

   The workflow does more than explain the attack. It tells the incident responder what to do next.

This method lines up cleanly with Incident Response because it keeps triage, containment, scoping, and lessons learned tied to the same analytical structure.

For command-line triage, simple tools still matter. On a Linux sensor, a quick grep through DNS logs or proxy records can expose repeated domains tied to the same activity. On Windows, event log review and process lineage are often the fastest path to reconstructing a capability.

How Does the Diamond Model Turn Indicators into Campaign Intelligence?

Campaign intelligence is the difference between knowing that something happened and understanding how the same adversary operates over time. The Diamond Model helps analysts move from isolated detections to campaign-level patterns by comparing repeated infrastructure, repeated code, repeated lures, and repeated victim selection.

Suppose your team sees three separate phishing incidents over six weeks. The domains are different, but the lure theme is always invoice-related, the credential page structure is similar, and the follow-on activity targets Microsoft 365 accounts in finance roles. That is not three unrelated alerts. That is a pattern worth tracking as a campaign candidate.

The same applies to malware. An adversary may switch file hashes every build, but keep the same loader sequence, persistence mechanism, or beacon timing. Those recurring behaviors are much harder to fake accidentally than a single IP address.

The real analytical gain is scale. Once patterns are documented, analysts can hunt across weeks or months of telemetry looking for the same victim profile, the same delivery chain, or the same post-compromise actions. That creates a more strategic defense posture.

Common campaign questions include:

• Was the same operator involved in multiple events?
• Did the infrastructure change while the capability stayed constant?
• Are the victims linked by industry, geography, or privilege level?
• Do the lures or payloads suggest the same operational playbook?

For broader context around the threat itself, analysts should distinguish the adversary from the Threat they create. A threat can persist even when the exact technical artifact changes.

That is why campaign mapping matters. Adversaries can replace infrastructure quickly, but they usually leave behavioral fingerprints behind.

How Does the Diamond Model Support Threat Intelligence Teams?

Threat intelligence teams need more than IOCs. They need context that can be reused by SOC analysts, incident responders, and leadership. The Diamond Model gives intelligence teams a clean way to turn raw observations into operationally useful reporting.

For tactical intelligence, the model helps correlate indicators across events. For operational intelligence, it helps describe how an adversary is delivering access, moving laterally, and maintaining persistence. For strategic intelligence, it helps explain why a pattern matters to the business and what kinds of controls could reduce risk.

This matters because noisy alerts are hard to brief. A report that says “we blocked 17 domains” does not say much to a manager. A report that says “we identified a repeat operator using disposable phishing infrastructure against finance users with a credential theft objective” is far easier to defend and act on.

The model also improves internal communication. Security operations needs different detail than GRC, and executives need a different summary than analysts. A relationship-based map provides one core truth set that can be repackaged without losing accuracy.

That structure aligns well with the Threat Intelligence function because it preserves evidence, confidence, and context. It also supports sharing across the organization without overclaiming attribution.

That is the kind of reporting that survives scrutiny from leadership, auditors, and other analysts.

Where Does the Diamond Model Fit with Other Frameworks?

The Diamond Model does not replace MITRE ATT&CK. It complements it. ATT&CK helps analysts describe techniques and adversary behavior in a shared language, while the Diamond Model helps organize the relationships around a specific intrusion.

That difference is important. ATT&CK is excellent for answering “what techniques did the adversary use?” The Diamond Model is better at answering “who used what infrastructure, against whom, and in what relationship?” Used together, they make analysis more complete.

CISA guidance and common threat terminology also help analysts stay consistent. If one team calls something a “phishing kit” and another calls it a “delivery platform,” the analysis can get muddy fast. Shared definitions reduce friction during handoffs and reporting.

The framework also works alongside kill chain-style thinking, detection engineering, and case management. The kill chain helps explain sequence. Detection engineering helps turn observed behaviors into alerts. The Diamond Model helps explain how the pieces relate to each other.

Here is the practical difference in a side-by-side view:

MITRE ATT&CK	Describes techniques, procedures, and observed behaviors
Diamond Model	Organizes the relationships between adversary, infrastructure, capability, and victim

For official guidance and terminology, analysts should rely on CISA and the MITRE ATT&CK knowledge base rather than informal labels. Consistent language makes it easier to compare cases and communicate with other teams.

For a practical comparison, ATT&CK helps you say “PowerShell was used for download execution,” while the Diamond Model helps you say “this operator used that capability through this infrastructure against this victim group.” Both are useful. They just answer different questions.

What Are the Practical Steps for Building a Diamond Model Analysis?

Building a Diamond Model analysis means treating the case like a living hypothesis, not a fixed label. The process should start with a clear incident question. Are you trying to determine whether the activity is a campaign, a repeat intrusion, or a single opportunistic event?

1. Define the question first. A focused question keeps the case from drifting into speculation. For example, “Is this credential theft activity part of a repeated finance-targeting campaign?” is better than “Who is behind everything?”

   Good questions lead to better evidence collection because they tell the analyst what to look for next.

2. Capture evidence quality. Record source reliability, timestamps, and confidence for each artifact. A firewall log, an EDR process tree, and a sandbox sample do not carry the same evidentiary weight, even if they point in the same direction.

   That detail helps when the case is reviewed later or handed to another analyst.

3. Build a worksheet or map. Whether you use a visual diagram, a case-management note, or a spreadsheet, the goal is to show connections. Link domains to hosts, hosts to users, users to actions, and actions to outcomes.

   Keep a place for unknowns. Unknowns are not failures; they are part of the investigation record.

4. Revisit the model with new telemetry. New logs often change the story. A server that looked malicious may turn out to be a relay, or a victim host may reveal lateral movement that was invisible during the first triage pass.

   Do not freeze the first theory. Good analysis evolves.

5. Document the decision path. Write down what changed, what remains uncertain, and what action is now justified. If the evidence supports host isolation, account reset, or domain blocking, say why.

   That documentation is what makes the analysis defensible under review.

When analysts follow this workflow, the Diamond Model becomes more than a diagram. It becomes a repeatable investigation method.

If you need a solid foundation for the idea of a Framework, this is it: a repeatable structure that keeps evidence, reasoning, and outcomes aligned.

What Mistakes Should Analysts Avoid?

The most common mistake is over-attribution. Analysts see a familiar malware family or an IP that appears in a blog post and jump straight to naming a threat group. That creates fragile analysis and unnecessary risk when the evidence is still thin.

Another mistake is forcing every case into a perfect four-vertex structure. Real intrusions are messy. Sometimes the victim is unclear, sometimes the adversary is unknown, and sometimes the capability is obscured by packers, loaders, or staged execution. The model should organize the evidence, not distort it.

Teams also make the error of focusing only on malware or network indicators while ignoring context. A domain is not meaningful on its own if you do not know which user opened the email, which host made the request, and whether the activity aligned with prior incidents.

Analysts should also separate observed facts from inference. A sentence like “the actor is APT-X” is far less defensible than “the activity shares infrastructure and tooling characteristics with previous events associated with APT-X.” The second statement is careful, useful, and reviewable.

Finally, do not stop analysis when containment is complete. Remediation often exposes artifacts that were hidden during the active incident, such as alternate persistence mechanisms, additional accounts, or secondary infrastructure. Those findings can materially change the relationship map.

• Do not confuse similarity with identity.
• Do not treat initial attribution as final truth.
• Do not skip victim context in favor of technical artifacts only.

The analysts who avoid these mistakes produce better reports and make fewer false claims.

What Business Value Does the Diamond Model Provide?

Business value is where the Diamond Model earns its keep. It helps security teams move faster because analysts can focus on the next meaningful question instead of chasing every indicator equally. That improves response speed without sacrificing rigor.

It also reduces repeated effort. Once a relationship pattern is documented, future investigations can reuse it. If a new incident resembles an older campaign in infrastructure or capability, the team can pivot faster and avoid rebuilding the same analysis from scratch.

For risk and governance teams, the model creates defensible explanations. Leaders do not want a pile of IOCs; they want to know whether the organization faced a targeted intrusion, whether the exposure is recurring, and what controls should be prioritized. A relationship-based narrative answers those questions more clearly.

The framework can also improve prioritization. If a pattern shows privileged users are repeatedly targeted, that is a strong signal to harden identity controls. If a certain region, business unit, or cloud tenant appears repeatedly in the victim vertex, that points to specific exposure worth addressing.

Better analysis supports better investment decisions. Instead of funding controls based on fear or anecdotes, teams can point to repeated adversary behavior, consistent infrastructure abuse, and measurable victim patterns.

For workforce and role context, the broader cybersecurity job market continues to value analysts who can turn telemetry into decision-ready intelligence. The U.S. Bureau of Labor Statistics reports strong demand for information security analysts in its Occupational Outlook Handbook, and that demand reflects exactly this kind of analytical skill set. See the latest data at BLS Occupational Outlook Handbook.

That is why the Diamond Model is not just an analyst trick. It is a better way to create business-relevant security evidence.

Conclusion

The Diamond Model of Intrusion Analysis helps security teams move beyond single indicators and build a real intrusion narrative. That is the difference between blocking one domain and understanding how an adversary operates.

When you connect adversary, infrastructure, capability, and victim through explicit relationships, your analysis becomes more accurate, more reusable, and easier to explain. That improves containment, supports better attribution, and strengthens long-term defense.

Use the model in your next investigation, your next hunt, and your next intelligence report. The more consistently you apply it, the faster your team will spot patterns that individual indicators will never reveal.

CompTIA® and Security+™ are trademarks of CompTIA, Inc.