Chapter 8 — Threat intelligence and OSINT: supervised case analysis
Lesson map
Lesson 08 published. Map, example, EX036.
flowchart TD
N0["Learning outcomes"]
N1["8.1 The case"]
N2["8.2 Timeline"]
N3["8.3 Mapping"]
N4["8.4 Diamond view"]
N5["8.5 Confidence and gaps"]
N6["8.6 Lessons"]
N7["8.7 Sharing"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX036"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 The case"]
N2["8.2 Timeline"]
N3["8.3 Mapping"]
N4["8.4 Diamond view"]
N5["8.5 Confidence and gaps"]
N6["8.6 Lessons"]
N7["8.7 Sharing"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX036"]
[Learning outcomes]
|
v
[8.1 The case]
|
v
[8.2 Timeline]
|
v
[8.3 Mapping]
|
v
[8.4 Diamond view]
|
v
[8.5 Confidence and gaps]
|
v
[8.6 Lessons]
|
v
[8.7 Sharing]
|
v
[Worked example] --> [Exercise EX036]
Learning outcomes
You will (1) analyse a realistic incident under supervision; (2) build a timeline; (3) map events to ATT&CK and kill-chain phases; (4) present findings with confidence and gaps.
8.1 The case
A broker receives an email apparently from an insurer announcing new bank details. Finance pays one premium to the new account before call-back verification catches a second request. Priya analyses the case with an external responder as supervisor. The case tests every routine from earlier chapters at once. One premium was paid before the fraud was noticed, so a client's money was at stake. The external responder supervises because Priya has not led a fraud analysis before, and because the findings may support reports to the bank and police. Her job in the case is the UTC timeline and the intelligence view, not the legal steps.
8.2 Timeline
Collect times from the email gateway, finance system and call-back log. Convert all to UTC. Order events: lookalike domain registered; email received; first payment; second request; call-back; fraud confirmed. Converting to UTC matters because systems record time differently, and one wrong offset could reverse the order of the payment and the call-back. Each event keeps a note of its source: the domain registration date from public records, the email from the gateway, the payment from finance and the call-back from its log. The sequence later shows registration four days before the email.
8.3 Mapping
Domain registration: Acquire Infrastructure (T1583) — preparation. Email: Phishing (T1566) as delivery of a pretext. No malware or account compromise is evident. Mapping only what the evidence shows keeps the report honest. There was no link or attachment to exploit, and no BIB account was used by the fraudster, so tagging T1078 or malware techniques would be wrong. The lack of technical techniques is itself a finding, because it explains why process controls, not technical tools, matter most for this threat.
8.4 Diamond view
Adversary: unknown fraud group. Capability: social-engineering pretext. Infrastructure: lookalike domain and a bank account. Victim: BIB finance team. The Diamond view still works when the adversary vertex can only say 'unknown fraud group'. Infrastructure is the most useful vertex for BIB, because the lookalike domain can be shared with FSSG and the receiving bank account can be reported. The victim vertex names a team, not a person, which keeps the analysis focused on the process that failed rather than the staff member involved.
8.5 Confidence and gaps
High confidence in the sequence; low confidence about whether the insurer's own mailbox was compromised. Ask the insurer through proper channels. Separating confidence by question, rather than giving one overall level, keeps the report precise. The sequence rests on BIB's own records, so confidence is high. Whether the insurer's mailbox was compromised depends on records BIB cannot see. Priya does not guess; the open question goes into the report as a gap and the request goes to the insurer through BIB's formal contacts.
8.6 Lessons
Call-back verification worked on the second request; it was not yet mandatory on the first. The call-back step introduced after the FSSG alert in Chapter 2 was still guidance rather than a rule, and the first request was paid without it. The second request was checked by a call-back to the insurer and stopped before payment. That contrast is the strongest evidence for Priya's recommendation to make call-back verification mandatory for every bank-detail change, which the operations manager can act on immediately.
8.7 Sharing
A GREEN item to FSSG with the lookalike domain and pretext, without client details. The FSSG item carries what other brokers can use: the lookalike insurer domain, the bank-detail pretext and the four days between registration and the email. It leaves out the client, the premium amount and the staff involved. Sharing at GREEN lets FSSG members check their own logs and warn their finance teams within the community. Priya's sharing item also passes the responder's review before release, since the same wording standards apply to community products.
8.8 Supervisor review
The responder checks Priya's timeline and wording before release. The responder reads the timeline against the source records and checks that each judgment matches its evidence. Wording gets particular attention: 'no evidence of BIB system compromise' is accurate, while 'BIB was not compromised' would claim more than the logs show. Priya records the responder's comments and the changes made before the report is released. Review by someone outside the case is especially valuable here, because the report may support reports to the bank and police.
8.9 Legal steps
Management reports the fraud to the bank and police; Priya provides the timeline. Priya supplies facts, not legal conclusions: the UTC timeline, the lookalike domain and the payment record from finance. Management decides what to report and when, with legal advice where needed. Her role description does not include contacting police, which is one of the actions listed as needing approval, so the reports go through management. Keeping the timeline in UTC with each source named makes it usable by the bank and police without further explanation from Priya.
Kill chain view
On the kill chain, the case covers weaponization of a pretext, delivery by email and actions on objectives as payment. There is no exploitation or installation, which explains why technical tools saw nothing unusual.
Worked example
Priya's timeline shows the lookalike domain was registered four days before the email. Her report: "Payment fraud using a lookalike insurer domain (high confidence on sequence). No evidence of BIB system compromise. Insurer mailbox compromise not excluded. Recommend mandatory call-back for all bank-detail changes and lookalike monitoring for insurer partners."
Synthetic case. The fraud is invented.
Errors and limits
Missing logs at partners limit conclusions; state them.
Exercises
- EX036 — Timeline order. Order the case's events. Rubric: 3 = registration, email, payment, second request, call-back, confirmation; 2 = mostly; 1 = muddled; 0 = none.
- EX037 — Technique map. Map the registration and email to ATT&CK. Rubric: 3 = T1583; T1566; 2 = one; 1 = wrong; 0 = none.
- EX038 — Diamond vertices. Fill the Diamond vertices for the case. Rubric: 3 = all four correct; 2 = three; 1 = one; 0 = none.
- EX039 — Open question. What remained uncertain, and how should it be resolved? Rubric: 3 = insurer mailbox compromise; ask insurer through channels; 2 = one; 1 = vague; 0 = none.
- EX040 — Recommendation. What two recommendations followed? Rubric: 3 = mandatory call-back; lookalike monitoring for partners; 2 = one; 1 = vague; 0 = none.
Synthesis
Build a UTC timeline, map to models, state confidence and gaps, share sanitised lessons and accept review.
Continue studying — chapter 08 of 12
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →