◇ OpenCyber Academy
Technical · Chapter 11 · English

Chapter 11 — Threat intelligence and OSINT: verification

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 11 — Threat intelligence and OSINT: verification

Lesson map

Lesson 11 published. Map, example, EX041.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Verify the intelligence"]
  N2["11.2 Internal corroboration"]
  N3["11.3 Independence"]
  N4["11.4 Verify the control"]
  N5["11.5 Verify the outcome"]
  N6["11.6 Record"]
  N7["11.8 Disagreement"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX041"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Verify the intelligence"]
  N2["11.2 Internal corroboration"]
  N3["11.3 Independence"]
  N4["11.4 Verify the control"]
  N5["11.5 Verify the outcome"]
  N6["11.6 Record"]
  N7["11.8 Disagreement"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX041"]

[Learning outcomes]
    |
    v
[11.1 Verify the intelligence]
    |
    v
[11.2 Internal corroboration]
    |
    v
[11.3 Independence]
    |
    v
[11.4 Verify the control]
    |
    v
[11.5 Verify the outcome]
    |
    v
[11.6 Record]
    |
    v
[11.8 Disagreement]
    |
    v
[Worked example] --> [Exercise EX041]

Learning outcomes

You will (1) verify intelligence before acting; (2) corroborate with independent and internal evidence; (3) verify that controls took effect; (4) record verification.

11.1 Verify the intelligence

Check the indicator's form, its age, whether other independent sources report it, and whether it belongs to shared infrastructure. Use passive sources only.

In the withdrawn-domain case, these checks showed a long legitimate history and hosting on a large content-delivery service. Form checks catch indicators that cannot be right, such as malformed domains or private addresses. Passive sources mean the checks never alert the owner of a suspicious domain that the college is looking at it. Each check and its result goes into the ticket before any block is requested.

11.2 Internal corroboration

Did college logs see it? Internal sightings both confirm relevance and show urgency.

An ESX indicator seen in Ashgrove's DNS logs is more urgent than one that only matched at another college. A match also shows which device or account needs attention. When no internal sighting is found, Tomás records which sources were searched and their retention, so the negative result is read correctly. In the DNS case, two library lookups of a 40-day-old domain showed that the item was relevant to Ashgrove. Tomás passed the library device names to the team that manages those machines, with the times of both lookups.

11.3 Independence

Two reports citing the same original are one source. Ask what each is based on.

A vendor blog and a news story that both cite the same ESX item add no extra weight to it. Tomás traces each report back to its original observation before counting sources. When the original cannot be found, he notes that the reports may not be independent, and the confidence stays lower in the note. This question also applies to sources inside ESX, where several members may repeat one original report. A count of reports is therefore never used as the confidence figure on its own.

11.4 Verify the control

After blocking, test from an approved machine. After an email rule, send a harmless test message. Record results.

The test machine is approved for this purpose, so its lookups are expected in the logs and not mistaken for an incident. A harmless test message checks an email rule without sending anything malicious through the gateway. Recording results gives the owning team evidence that the change worked, attached to the original request. If a test fails, the owning team is told the same day with the result, so the control can be fixed quickly.

11.5 Verify the outcome

A week later, check whether matches dropped. If blocked lookups continue from one machine, that machine may be infected and needs attention.

The outcome check asks whether the change made any difference to what college devices actually do. A drop in matches suggests the block is working, while continued blocked lookups from one device point to something still running there. That device is handed to the team that manages it, and Tomás records the referral. The one-week check is booked in the ticket when the block is made, so it is not forgotten.

11.6 Record

Checks, results, time and person. Others can repeat them.

A record names the check, its result, the time and who performed it, in the ticket for the item. Another member of the team should be able to repeat it from the record alone. Tomás uses the same format for intelligence checks, control tests and outcome checks, so reviewers know where to look. Records are kept with the item for as long as the item stays in the platform. When ESX later withdraws an item, the records show which checks were done before it was used, and which controls it reached.

11.7 Time limits

Urgent items get quick checks; strategic claims can wait for fuller verification. Report what was and was not verified.

An urgent phishing domain might be checked for form, age and internal sightings within minutes and blocked the same morning. A claim about a group targeting colleges can wait for fuller corroboration. In both cases, Tomás's note states which checks were done and which were not, so readers know how far to trust it. Quick checks still cover form, age and internal sightings at a minimum.

11.8 Disagreement

If verification contradicts the source, tell the source politely with evidence. Communities improve through such feedback.

In the withdrawn-domain case, Tomás gave ESX the hosting details, history and certificate owner rather than simply saying the item was wrong. ESX could then check its own records and found the typing error. Polite, evidence-based feedback keeps Ashgrove trusted in the community and improves the shared data for every member. Tomás sends feedback through ESX's agreed channel, with the item's identifier and label, so the right member receives it. A withdrawal by ESX is recorded in the platform, and any related block is removed.

11.9 Never active

Verification never includes visiting suspicious pages, downloading files from them or scanning their servers from college systems.

These actions could alert attackers, trigger downloads of malicious code or break the college's acceptable-use rules. Passive sources and college logs give enough information for the decisions Tomás supports. If a page really must be examined, the request goes to qualified staff with suitable tools, as the safety sheet says. The rule applies to every college device, including the approved test machine used for control checks. Tomás repeats it in the lab rules, so students practise only passive methods.

Verifying with owners

System owners know whether a connection is expected. Before escalating a match on the library server, Tomás asks the library systems officer whether the server legitimately talks to that supplier. A two-minute call often settles what hours of log reading cannot, and owners appreciate being asked rather than surprised by an incident ticket.

Worked example

ESX shares a domain as a phishing site. Tomás finds it on a large content-delivery service, with a long legitimate history and no college lookups. Certificate records show a reputable owner. He tells ESX the domain appears legitimate; ESX checks and withdraws it — the original report had a typing error.

Synthetic case. The domain is invented.

Errors and limits

Verification reduces errors but cannot remove them.

Exercises

Synthesis

Verify intelligence, controls and outcomes passively, record each check and give sources honest feedback.

Continue studying — chapter 11 of 18

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →