Diamond Model: A Practical CTI Investigation Walkthrough

The Diamond Model is useful when an investigation produces more connections than conclusions. A phishing domain shares an IP address with another domain. A page resembles a known kit. A workstation requested the page. Those observations support different claims, and placing them in one graph does not make them equally strong.

A practical Diamond Model investigation records four things for each event: who or what acted, the capability involved, the infrastructure used, and the affected victim. It also records the evidence supporting each relationship, the relevant time, and what remains unknown. The result should help someone make a decision, such as finding exposed accounts, preserving logs, or narrowing a hunt.

This walkthrough uses an entirely synthetic phishing case. Boreal Workshop, the host names, and the domains are fictional. Addresses such as 192.0.2.44 and domains ending in .example are documentation values. Keep the exercise offline; none of its indicators are targets for live enrichment or scanning.

Start with the decision the investigation must support

At 08:42, an employee at fictional Boreal Workshop reports a message linking to documents-boreal.example. The incident lead needs a decision before noon: which accounts require further investigation, which evidence must be preserved, and whether a targeted containment measure is justified.

That request gives the analysis a useful boundary. A named attacker is unnecessary for the immediate decision. A worldwide inventory of domains sharing the same hosting provider would consume time without necessarily identifying another exposed employee. The analyst should collect information that can change the response.

Write the question into the case record: “Did the reported lure reach other Boreal users, and what evidence distinguishes delivery, browsing, and credential submission?” Add the deadline, the intended recipient, and the available telemetry. If authentication logs are unavailable until the afternoon, the noon assessment must identify that gap rather than imply account compromise was excluded.

The original Diamond Model paper, by Caltagirone, Pendergast, and Betz, provides the analytical framework. A 2026 SANS presentation on intelligence requirements also connects the model with collection questions. The workflow below is an original teaching example, not a case reported by those authors.

Describe one event before drawing a campaign

Begin with event E01, the reported message. The victim vertex contains the recipient account and the business context needed to interpret the lure. The infrastructure vertex contains the domain appearing in the link. The capability vertex describes the observed credential-themed message. The adversary vertex remains unknown.

Avoid adding credential theft to the capability merely because the page asks for a password. A page design supports an assessment of intended collection; it does not establish that a user submitted credentials or that an attacker received them. Likewise, an email display name is an observed string, not an identified operator.

Next create event E02 for a proxy request from WORKSTATION-17 to the domain. This event concerns a different observation and may have a different explanation. A security preview service, browser prefetch, or user navigation could generate a request. The event record should keep the available method, timestamp, device association, and any process context.

Connecting E01 and E02 creates an investigative hypothesis: the message may have led to the request. The timeline makes the hypothesis plausible, but the relationship still needs supporting evidence. Preserve the distinction between the link being delivered and the link being acted upon.

Build a small evidence ledger with explicit claim boundaries

Evidence P01 is the reported message, retained with its headers and collection time. It supports the presence of the lure in the recipient's mailbox. It does not establish the full recipient population unless mail logs or message tracing provide that coverage.

Evidence P02 is a proxy log entry at 08:39 associated with WORKSTATION-17. It supports a recorded request within the visibility of that proxy. It does not independently prove that a person clicked, that the response rendered, or that credentials were submitted.

Evidence P03 is an archived page image collected during the exercise at 09:06. Its supplied capture timestamp is 17:20 on the previous day. It shows a credential-themed page associated with the URL at that earlier capture time. It cannot prove what every user received at 08:39 the following morning.

For each item, store the original location, collector, acquisition time, relevant observation time, and any transformations. Attach a short statement beginning with “supports” and another beginning with “does not establish.” These fields make it easier for a reviewer to spot a conclusion that has outgrown its evidence.

Use the same discipline when evaluating threat intelligence sources. A provider verdict is an attributed assessment. It should not silently become a first-hand observation in your ledger.

Keep the clocks separate

The message was delivered at 08:37. The proxy recorded the request at 08:39. The employee reported it at 08:42. The analyst obtained P03 at 09:06, but its capture refers to the previous evening. Sorting everything by collection time would create a misleading sequence of attacker activity.

Record event time, acquisition time, and the time an assessment became available separately. Also preserve timezone, timestamp precision, and any known clock uncertainty. An event with minute-level precision cannot support a claim about a two-second ordering without another source.

The STIX 2.1 specification distinguishes object metadata from observation-related fields. When exchanging the case, check how your exporter carries these meanings. Do not use an object's creation date as a substitute for the time an intrusion occurred.

In the investigation narrative, write the sequence that the evidence supports and identify uncertain ordering. If two systems disagree by several minutes, retain that discrepancy. Quietly adjusting the times to make the story coherent produces an attractive timeline that another analyst cannot reproduce.

Choose pivots according to the question they can answer

The first useful pivot is the mail system: find other deliveries of the same message or the same distinctive URL pattern within the authorized scope. It can identify a population for follow-up. Record the search period and fields used so that “no additional recipients found” has a defined meaning.

The next pivot is endpoint or proxy telemetry for those recipients. It can distinguish delivery from recorded network activity and may identify the process responsible for a request. That supports a more focused investigation than treating every recipient as equally exposed.

A hosting pivot is less decisive. In the synthetic data, the domain resolves to 192.0.2.44, which also hosts many unrelated demonstration sites. Grouping activity solely because its domains share that address would create an unsupported cluster. Keep the shared-hosting observation in a separate lead until another relationship justifies promotion.

Certificate, page, and registration similarities can generate hypotheses. Their value depends on specificity and time. A widely reused template is weaker than a distinctive artifact with a documented relationship. The phishing infrastructure walkthrough provides background for these technical pivots; the case ledger determines whether any particular pivot is relevant here.

Test explanations that would change the response

For E02, compare at least two explanations: a user opened the lure, or an automated preview generated the request. Identify an observation that could distinguish them. Browser process context, preview-service identifiers, and endpoint timestamps may help, depending on the telemetry actually collected.

Do not create a long list of hypothetical explanations simply to appear cautious. Focus on alternatives that fit the evidence and would change the next action. If both explanations require preserving the same logs immediately, preserve them while the distinction is investigated.

An absent endpoint event only becomes evidence against a hypothesis when the relevant sensor was operating, covered the host, and would normally record that behavior. A missing log source is a collection gap. A retention window that already expired cannot support a conclusion that an event never occurred.

The IOC alert investigation guide explains how IP, DNS, and process evidence can narrow these questions. In the Diamond Model case, keep the resulting judgment attached to E02 so that a later campaign summary does not erase the caveat.

Distinguish causal activity threads from activity groups

An activity thread orders causally connected events by phase; links can remain hypotheses. An activity group brings together events or threads by shared features. Sections 8 and 9 of the original paper distinguish these relationships.

For the first employee, record E01, message delivery, followed by E02, the proxy request, in a provisional thread. Mark the proposed delivery-to-request link as a hypothesis until supporting telemetry establishes the connection. The order alone does not prove that the message caused a human to browse.

Suppose mail tracing finds the same lure delivered to another employee, followed by a similar request from WORKSTATION-24. Create E03 for that delivery and E04 for the request, with their own evidence and a separate provisional thread. A shared URL does not establish a causal link between the two employees' activity.

The matching lure destination and compatible delivery window support a provisional activity group, “Boreal credential lure, September exercise,” containing both threads. Record these inclusion criteria and their limits. The group supports investigation of related exposures; its unknown adversary does not become an identified operator through clustering.

If actor identity later becomes a decision requirement, use a separate attribution assessment with competing hypotheses. Keep its confidence distinct from both the hypothesized causal links within each thread and the similarities supporting the group.

Now introduce E05: a second synthetic page on collecte-session.example with a similar visual template. The same kit could be available to unrelated operators. Unless more specific evidence connects the activity, retain E05 as a lead outside the group. Visual similarity alone neither satisfies the inclusion criteria nor establishes causation.

Document both the reason for considering the connection and the reason for withholding it. A future analyst may obtain a distinctive identifier that changes the assessment. Preserving the rejected pivot prevents them from treating your earlier uncertainty as either a positive relationship or a permanent dismissal.

Add ATT&CK mappings only where the evidence supports behavior

An ATT&CK label can help the detection team locate related analytics, but it must describe the behavior supported by the case. A credential-themed message and a network request do not establish every later step of an intrusion chain.

Attach a mapping rationale to the event and include the evidence identifiers. If the rationale relies on an assumption, keep it provisional. A map populated with inferred execution, persistence, and exfiltration techniques would overstate this case and send defenders toward the wrong telemetry.

The guide to mapping defenses with MITRE ATT&CK complements this workflow. The two models answer different practical questions: which event relationships are supported, and which observed behaviors align with a shared vocabulary. Neither provides actor identity merely through a technique match.

When reviewing the event records, ask whether removing a technique label would change the evidence. If the answer is no, the label is an annotation, not an additional source of corroboration.

Turn the model into a response brief

The noon brief should begin with the decision. In this exercise, the evidence supports preserving authentication and endpoint records for two accounts and checking whether automated preview activity explains the proxy requests. It does not yet support claiming that either account was compromised.

State the known scope, the important uncertainty, and the next collection step. Assign an owner and deadline to each action. If a narrow domain block is proposed, record its expected benefit, business impact, approval, and review point. A graph without these decisions remains an analyst's working document.

Keep the evidence ledger as an appendix or linked artifact. The recipient should be able to inspect why a claim was made without reading every collection note. Include a short update condition: for example, evidence of credential submission, suspicious authentication, or a confirmed preview process would change the recommended follow-up.

If additional authorized enrichment is needed for a real indicator, an IsMalicious report can contribute another dated source to the case. The synthetic domains in this exercise should remain offline. Enrichment should answer an identified question, and its findings should retain their original scope.

Use a repeatable case package

A reusable package needs a mandate, event records, evidence ledger, timeline, hypothesis notes, and decision log. The mandate limits the work. The event records preserve the four vertices and their unknowns. The ledger makes claims auditable. The remaining documents show how the assessment changed and what someone did with it.

Before closing the case, have a reviewer trace the most consequential claim back to its evidence. Ask them to identify a relationship that is observed, one that is inferred, and one that was rejected. If the package cannot make those distinctions clear, revise the records before polishing the diagram.

Close when the agreed decision has been supported and the remaining collection gaps have owners or explicit acceptance. Record reopening conditions and preserve the previous assessment when new evidence arrives. A useful Diamond Model investigation leaves the next analyst a defensible starting point, including the places where the evidence stopped.