Chapter 24 — Threat intelligence and OSINT: methods I
Lesson map
Lesson 24 published. Map, example, EX070.
flowchart TD
N0["Learning outcomes"]
N1["24.1 Diamond structuring"]
N2["24.2 ATT&CK mapping"]
N3["24.3 Kill-chain controls"]
N4["24.4 Sources and confidence"]
N5["Practice note — Analytic notes"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX070"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["24.1 Diamond structuring"]
N2["24.2 ATT&CK mapping"]
N3["24.3 Kill-chain controls"]
N4["24.4 Sources and confidence"]
N5["Practice note — Analytic notes"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX070"]
[Learning outcomes]
|
v
[24.1 Diamond structuring]
|
v
[24.2 ATT&CK mapping]
|
v
[24.3 Kill-chain controls]
|
v
[24.4 Sources and confidence]
|
v
[Practice note — Analytic notes]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX070]
Learning outcomes
You will (1) apply the Diamond Model to structure an incident's intelligence; (2) map observed behaviour to ATT&CK techniques; (3) place controls along the kill chain; (4) record analytic confidence and sources.
24.1 Diamond structuring
For each event, record adversary (if known), capability (malware, technique), infrastructure (domains, addresses) and victim (asset, organisation). Unknown vertices stay "unknown"; filling them by guess is the classic error.
Kofi's analysts record each vertex with its evidence. A victim's workstation name comes from the endpoint logs, the infrastructure from the proxy, the capability from the sandbox report. The adversary vertex is often empty, and saying so is accurate. A guessed group name spreads quickly once written, and later readers may treat it as established fact.
24.2 ATT&CK mapping
Behaviours map to technique IDs: phishing email → T1566; scripting on the host → T1059 Command and Scripting Interpreter; web-protocol C2 → T1071. Mapping supports detection engineering and comparison with group profiles.
Kofi asks analysts to cite the evidence for each technique tag, such as the log line showing a script interpreter starting from a mail attachment. Tags without evidence are removed in review. Consistent tagging lets the detection team see which techniques recur across incidents and which have no detection at all, which guides their work for the next quarter.
24.3 Kill-chain controls
Hutchins et al. proposed a courses-of-action matrix: detect, deny, disrupt, degrade, deceive and destroy across phases. Lantern produces inputs for several cells — deny at delivery via mail filtering, detect at C2 via DNS analytics.
Kofi drew the matrix for BEN's phishing incidents and found most cells empty beyond deny and detect. Disrupting command traffic, for example by sinkholing a domain at the resolver, was possible but had never been planned. Filling a cell means naming the action, who owns it and how its effect would be measured. Empty cells are a planning gap, not necessarily a failure.
24.4 Sources and confidence
Each analytic statement cites its sources and confidence. Admiralty-style source grading or a simple scale (confirmed, probable, possible) helps readers.
Kofi's reports put a short source line under each judgment, naming the evidence and its reliability, and a confidence word from the team's table. A reader can then tell a claim resting on BEN's own logs from one resting on a single partner bulletin. When sources disagree, the report says so instead of picking one silently. Reviewers send back any judgment that lacks a source line.
24.5 OSINT within limits
Methods include certificate-transparency lookups for related domains and reading public advisories. Researchers do not interact with adversary infrastructure or register accounts on criminal forums for this course.
Certificate transparency logs are public and designed for this kind of search, so looking up certificates issued for names similar to a known phishing domain is within bounds. Visiting the suspect sites is not part of these methods. Kofi records every OSINT query with its purpose, which shows that the research stayed within the agreed limits if anyone later asks.
Practice note — Analytic notes
Each incident's Diamond record carries an analytic note: what was observed, what was inferred and what remains unknown. Separating those three lines prevents later readers from mistaking an inference for an observation when the record is reused months later. Reviewers check that every inference line names the evidence it rests on.
Worked example
A synthetic phishing incident at BEN: capability T1566 plus a script dropper (T1059), infrastructure drop.example, victim a billing clerk's workstation, adversary unknown. Courses of action: deny delivery with a mail rule; detect C2 via DNS for drop.example; hunt for T1059 on other workstations.
Synthetic case. The incident is invented.
Errors and limits
ATT&CK mapping is interpretive; two analysts may differ. Keep evidence linked.
Exercises
- EX070 — Unknown vertex. How should the adversary vertex be recorded in Kofi's incident, and why? Rubric: 3 = unknown; avoid guessing attribution; 2 = unknown; 1 = name a group; 0 = none.
- EX071 — Technique IDs. Give technique IDs for the phishing email and the script execution. Rubric: 3 = T1566 and T1059; 2 = one; 1 = wrong; 0 = none.
- EX072 — Course of action. Give one deny and one detect action with kill-chain phase. Rubric: 3 = deny at delivery (mail rule) + detect at C2 (DNS); 2 = one; 1 = vague; 0 = none.
Synthesis
Structure with the Diamond, map with ATT&CK, act along the kill chain, and keep sources and confidence attached.
Continue studying — chapter 24 of 50
← Chapter 23 (draft) · Course chapter index · Chapter 25 (draft) →