Most analysts don’t struggle because they lack alerts. They struggle because they have too many alerts and not enough structure. One endpoint fires on suspicious PowerShell, email security flags a lookalike sender, the SIEM catches odd authentication, and dark web monitoring turns up exposed credentials. Each signal matters, but taken alone, each one pushes the team into reactive triage.
That’s where the Diamond Model of Intrusion Analysis earns its keep. It gives you a way to turn scattered evidence into an event you can reason about, enrich, compare, and reuse. Instead of asking, “What do I do with this IOC?” you start asking, “Who used what, through which infrastructure, against whom, and what happened?”
For smaller internal teams and service providers supporting many clients, this shift is especially important. If you’re tightening the basics alongside structured analysis, this guide to intrusion detection for SMBs is a useful companion because it frames where detection fits before you start layering in threat intelligence and investigation workflows.
Beyond the Alerts An Introduction to Structured Analysis
Analysts often inherit investigations that are already fragmented. One person is focused on a file hash, another on an email header, and a third is digging through proxy logs. Everyone is working, but the team still can’t answer the basic operational question: are these isolated events, or one intrusion unfolding across multiple systems and clients?
Structured analysis fixes that. The point isn’t to create more paperwork. The point is to give every alert a consistent shape so the next analyst can pick it up and keep moving without rebuilding context from scratch.
Why the event matters more than the alert
An alert is a detector’s opinion. An event is an analytical unit. That distinction matters.
When you treat the alert as the center of the investigation, you stay tied to the product that generated it. When you treat the event as the center, you can pull in telemetry from EDR, email, DNS, identity systems, cloud logs, sandboxing, and external intelligence without losing the plot.
Practical rule: If your case notes only preserve indicators and not relationships, you’re saving evidence but losing intelligence.
The Diamond Model gives you that relationship layer. It helps a junior analyst ask better questions and helps a senior analyst build campaign visibility across many cases.
What changes in day to day work
In practice, teams that use the model well stop writing vague notes like “malicious domain contacted by host.” They write something more useful: the victim asset reached adversary-controlled infrastructure using a specific capability, and the result was successful credential capture, payload retrieval, or failed execution.
That structure improves handoffs, escalations, and hunt creation.
A simple working rhythm usually looks like this:
- Capture the first confirmed artifact: Start with the thing you trust most, such as a process tree, a phishing page, or a cloud audit event.
- Assign each known detail to a vertex: Don’t wait for perfect certainty. Unknown is acceptable if the relationship is clear.
- Record the result: Was execution blocked, access granted, data exposed, or outcome still unknown?
- Pivot through the edges: Ask what else shares the same infrastructure, capability, or victim profile.
That’s how you stop chasing noise and start building a defensible analytical picture.
Deconstructing the Diamond The Four Core Vertices
The Diamond Model works because it’s simple enough to use under pressure. The original technical report defines each intrusion as an atomic event made up of four core features, adversary, capability, infrastructure, and victim, connected by six analytically useful edges in a graph structure, as described in the original Diamond Model paper.
Why the event matters more than the alert
Consider a detective working a crime scene. The detective doesn’t log only the weapon and stop. They connect the suspect, the tool, the location, and the target. Cyber analysis works the same way.
A file hash alone rarely tells the whole story. A malicious domain alone rarely tells the whole story. But once you connect a tool, delivery path, target, and operator behavior, your pivots become far more useful.
The edges are where the analytical value shows up. A shared capability can link incidents. Shared infrastructure can expose staging or command paths. Shared victim patterns can reveal targeting intent.
How each vertex works in practice
Adversary
This is the actor behind the activity. Sometimes that means a named threat group. Often it doesn’t. Early in an investigation, “unknown adversary” is a perfectly valid entry.
What matters is that you separate what you know from what you suspect. If you prematurely stamp a case with a threat actor name, the team starts fitting evidence to the label. That’s a common mistake.
Capability
This is the attacker’s method or toolset. It might be malware, a phishing kit, credential theft, abuse of a trusted admin utility, or synthetic media used for impersonation. In hands-on investigations, this vertex usually becomes your bridge into detection engineering because capabilities map closely to observable behavior.
Examples include:
- Script execution: Suspicious PowerShell, shell abuse, or downloader logic
- Credential abuse: Reused passwords, token theft, or session hijacking
- Social engineering: A fake login portal, cloned support page, or executive impersonation
- Cloud misuse: Unauthorized API activity or abuse of exposed keys
Infrastructure
Infrastructure is what carries or supports the intrusion. Analysts often think only of command and control, but the category is broader. It can include malicious domains, staging locations, email accounts, cloud-hosted redirectors, or a marketplace where stolen data is traded.
This is also the vertex that MSPs and MSSPs can often operationalize fastest because it lends itself well to enrichment, blocking, clustering, and external monitoring.
Victim
The victim is the target. That could be an endpoint, a user account, a business unit, a tenant, an executive persona, or a customer-facing brand property.
A lot of weak investigations flatten the victim into “the company.” That isn’t enough. Good victimology tells you why the target mattered and often explains attacker intent better than early attribution guesses.
| Vertex | Practical question | Example |
|---|---|---|
| Adversary | Who is acting? | Unknown operator reusing known patterns |
| Capability | What are they using? | Credential harvesting kit |
| Infrastructure | Through what channel? | Lookalike domain or hosted login page |
| Victim | Who or what was targeted? | Finance user, cloud tenant, or executive persona |
Putting the Model to Work A Practical Workflow
The model becomes useful when you use it in real case flow, not when you admire the diagram. A good starting point is an EDR alert on suspicious PowerShell launched from a user context. That’s not rare, and it’s exactly the kind of signal that can either become a dead-end triage task or the start of a meaningful investigation.
Start with the first solid artifact
Start with what’s confirmed. In this example, the endpoint process tree is your anchor. You know a host executed PowerShell. That immediately gives you a provisional victim and an initial capability.
Don’t jump to attribution yet. Analysts waste time when they try to name the actor before they’ve described the event.
The Diamond Model’s core axiom, introduced when the model was formally published in 2013, states that “For every intrusion event, there exists an adversary taking a step toward an intended goal by using a capability over infrastructure against a victim to produce a result,” as summarized in this Recorded Future overview of the Diamond Model.
Build the first diamond before chasing attribution
Once you have the process event, ask focused questions that populate the missing vertices.
- Victim first: Which user ran it, on what asset, with what privileges?
- Capability next: Was the command a downloader, recon step, credential access attempt, or persistence action?
- Infrastructure after that: Did the process reach an external domain, a hosted script, a redirected cloud object, or an email-delivered artifact?
- Adversary last: Do the capability and infrastructure patterns resemble any tracked activity in your own corpus?
This order works because it keeps the investigation evidence-led.
A compact case note might look like this:
- Victim: User workstation tied to a finance employee
- Capability: PowerShell used to retrieve and execute additional content
- Infrastructure: External hosting location contacted shortly after launch
- Adversary: Unknown, pending overlap analysis
- Result: Execution attempted, with follow-on artifacts under review
Turn one event into a hunt
After the first diamond is populated, pivot outward. Search for the same PowerShell pattern across other endpoints. Look for repeated outbound connections to the same infrastructure. Check whether similar alerts hit other tenants. Review email telemetry for the original delivery path.
That’s also where external intelligence can sharpen internal analysis. If your infrastructure pivot touches criminal forums, exposed credentials, or actor chatter, dark web and OSINT context can add motive and timing. For teams building that capability, this piece on using dark web monitoring for OSINT and investigations is relevant because it extends the same investigative logic outside endpoint and network logs.
Later in the case, a visual explainer can help align the whole team before response actions branch out.
What works in operations is simple: build a small, accurate diamond early, then revise it as evidence matures. What doesn’t work is waiting for complete certainty. By the time the picture is perfect, the attacker has usually moved.
From Single Events to Tracking Adversary Campaigns
Single-event analysis is useful. Campaign analysis is where the Diamond Model starts paying back the effort. The moment you can chain events through shared infrastructure, capability, or victim patterns, you stop cleaning up isolated incidents and start tracking operator behavior.
What shared vertices actually tell you
Suppose three separate clients report unrelated issues. One sees suspicious email redirects, another finds credential abuse in cloud apps, and a third gets hit by a fake support portal. If all three events tie back to the same infrastructure pattern or the same capability set, they may belong to one campaign.
That’s the key shift. You’re no longer asking whether an IOC is malicious in isolation. You’re asking whether multiple events express the same adversary behavior.
A review cited by ThreatConnect found that applying the framework could increase indicator reusability by up to 40–50% compared with siloed IOC handling, and that analysis across 10,000+ intrusion events allowed analysts to consolidate activity into around 30–40 coherent adversary campaigns, as summarized in this ThreatConnect discussion of the Diamond Model.
Good campaign tracking doesn’t require perfect attribution. It requires disciplined grouping logic.
What MSSPs gain from chaining events
Service providers live or die by correlation quality. If every client incident stays in its own ticket lane, analysts duplicate work and miss broad targeting patterns.
Chaining events gives MSSPs several practical advantages:
- Cross-tenant visibility: Shared infrastructure can expose a campaign that looks low-signal inside any single client.
- Better hunting logic: Capabilities often recur before branding, lures, or victim lists do.
- Cleaner reporting: Clients understand “you were part of this campaign pattern” better than a list of unrelated indicators.
- Stronger prioritization: An event tied to an active chain deserves more attention than a one-off weak signal.
A simple way to operationalize this is to maintain campaign candidates, not just incidents. If two or more events share meaningful vertices, create a grouping object and keep updating it. Some groupings will collapse under scrutiny. That’s fine. The discipline still improves your analysis.
Connecting the Diamond to MITRE ATT&CK
The Diamond Model and MITRE ATT&CK solve different problems. Treating them as interchangeable leads to shallow analysis.
They answer different questions
The Diamond Model describes the event and its relationships. It tells you who acted, what they used, what infrastructure supported it, and who got targeted.
MITRE ATT&CK describes behavior in a standardized way. It helps you classify what the attacker did, such as scripting, credential access, discovery, persistence, or exfiltration.
That means the two fit together naturally:
- The capability vertex often maps to one or more ATT&CK techniques.
- The infrastructure vertex can support ATT&CK-informed detection content around command paths, staging, or delivery methods.
- The victim and adversary vertices add context that ATT&CK alone doesn’t try to capture.
A practical mapping approach
A useful workflow is to build the diamond first, then enrich the capability with ATT&CK mappings. That order matters. If you start with ATT&CK alone, you can end up with a long list of techniques but no coherent picture of the actor, target, or delivery path.
Use a simple comparison:
| Diamond Model | ATT&CK contribution | Operational value |
|---|---|---|
| Capability | Technique mapping | Improves detections and hunt queries |
| Infrastructure | Supporting context for delivery or control paths | Improves blocking and enrichment |
| Victim | Targeting context | Helps prioritization and scoping |
| Adversary | Behavioral grouping context | Helps cluster related activity |
ATT&CK helps your team describe behavior consistently. The Diamond Model helps your team explain why those behaviors belong together.
This also improves reporting. Engineers get ATT&CK mappings they can action. Leadership gets a campaign narrative that makes sense.
Advanced Applications for External Threat Intelligence
A lot of Diamond Model guidance still assumes the action starts on an endpoint or inside a network. That’s too narrow for modern MSP and MSSP work. Many real investigations now begin outside the perimeter, with a leaked credential, a fake domain, a cloned profile, a malicious ad, or exposed cloud access.
Modeling threats outside the endpoint
The model holds up well in these cases because the four vertices still apply.
Take a brand impersonation case. The victim might be a customer support persona or executive identity, not just a corporate hostname. The infrastructure might be a lookalike website, social profile, or hosted form. The capability might be credential harvesting, account takeover setup, or synthetic media used to build trust. The adversary may still be unknown at first, but the event is analyzable immediately.
The same logic works for cloud misuse. If an exposed key is abused, the victim might be a tenant or workload, the capability is unauthorized API use, and the infrastructure includes the external systems the actor used to stage or access resources. That gives the team a shared language across cloud, identity, and internet-facing data.
Where traditional playbooks break down
Traditional IR playbooks often assume a malware sample, a compromised host, and an internal containment path. External threats don’t always look like that.
A Vectra overview notes a major blind spot in standard explanations of the model: nearly 40% of brand abuse campaigns now spoof individuals via deepfakes or cloned profiles, which means teams need to represent the victim as a persona and the capability as synthetic media tooling in ways older guides rarely address, as discussed in this Vectra write-up on the Diamond Model.
That matters operationally. If you only model victims as machines, you’ll miss attacks aimed at trust, reputation, and identity.
External monitoring becomes much more useful when you structure it this way:
- Dark web leaks: Actor selling or distributing data, marketplace or forum as infrastructure, theft method as capability, affected organization and users as victims
- Lookalike domains: Domain or social account as infrastructure, phishing kit or impersonation workflow as capability, support staff or customers as victims
- Cloud exposure: Abused access path as capability, external service chain as infrastructure, tenant or workload as victim
Teams that want stronger visibility into these external signals usually benefit from a parallel practice around the benefits of dark web monitoring, especially when investigations depend on early signs before traditional controls fire.
Integrating the Diamond Model into Your Security Operations
You don’t need a new platform to start using the Diamond Model. You need consistent habits. The teams that succeed with it build it into triage, enrichment, and reporting instead of treating it like a specialist exercise for threat intel only.
Three changes that make it stick
First, update case templates. Every incident record should have fields for adversary, capability, infrastructure, victim, and result. If analysts have nowhere to record relationships, they won’t record them.
Second, adjust your enrichment flow. SIEM, EDR, email security, cloud logs, and external feeds should all help populate vertices. That’s especially important when your environment spans internet-facing assets and exposure management. Teams doing broader discovery work often pair this thinking with attack surface analysis so external assets feed directly into investigations.
Third, review incidents as linked events, not isolated tickets. A weekly analytic review that asks “what vertices repeated?” is often more useful than another dashboard.
A practical starting plan:
- Use a worksheet: Even a shared document or whiteboard sketch works at first.
- Train to ask pivot questions: What else uses this infrastructure? Who else was targeted with this capability?
- Score uncertainty openly: Unknown adversary is acceptable. Hidden assumptions are not.
- Promote reusable chains: When events connect, preserve that grouping for future hunts.
Mature SOC work isn’t just faster triage. It’s better memory.
That’s what the Diamond Model gives you when it becomes part of normal operations.
Frequently Asked Questions
Is the Diamond Model the same as the Cyber Kill Chain
No. They model different things. The Cyber Kill Chain describes stages in an attack process. The Diamond Model describes the structure of an intrusion event and the relationships inside it. They can complement each other, but they aren’t substitutes.
Do I need a specific tool to use the Diamond Model
No. It’s a method of analysis first. A whiteboard, case template, spreadsheet, TIP, SIEM, or graph-enabled platform can all support it. Tools help scale the work, but the value comes from how analysts think and document relationships.
Can the adversary vertex be unknown
Yes. In many real cases, it starts unknown. That doesn’t weaken the model. The other vertices often generate the evidence that later supports grouping or attribution.
What’s the most common mistake teams make
They collect indicators without preserving relationships. That leaves the next analyst with artifacts but no narrative. Another common error is forcing attribution too early.
Is the model only useful for malware investigations
No. It works for phishing, account takeover, cloud misuse, dark web credential exposure, brand impersonation, and identity-centric attacks. In those cases, the victim may be a persona, tenant, or brand asset rather than a single endpoint.
How detailed should each diamond be
Only as detailed as the evidence supports. Start small, stay accurate, and expand as the case matures. A partial diamond with clear reasoning is more valuable than a complete-looking one built on guesses.
InsecureWeb helps MSPs, MSSPs, and security teams monitor the parts of the threat environment that sit outside the firewall, including dark web exposure, fake sites and accounts, deepfake abuse, and broader external attack surface risk. If you want to strengthen investigations before they become full incidents, explore InsecureWeb.
