Chapter 53 — Threat hunting and threat intelligence

In one sentence

Threat hunting is proactively searching for compromise you have no alert for yet, driven by a hypothesis rather than a trigger, and threat intelligence is what tells you which hypotheses are worth the time — both turn "waiting for an alert" into actively looking for the intrusions your detections don't yet cover.

Where we are

Ch 51-52 gave you detections and the telemetry to run them against. Detections only catch what you thought to write a rule for. Hunting is the discipline of looking for what you didn't.

How it works

The hunting loop (not alert-driven — hypothesis-driven):

   1. FORM A HYPOTHESIS, sourced from:
        - threat intelligence (below): "actors targeting our sector are
          currently using cloud OAuth consent-phishing (G1/this guide
          Part 6 Ch 39) for initial access."
        - an ATT&CK gap in your coverage heat map (Part 1 Ch 2): "we have
          no detection for T1548 (Abuse Elevation Control Mechanism) in
          our Kubernetes environment."
        - a crown-jewel asset: "if someone were trying to reach the
          per-tenant KMS keys (Part 7 Ch 44), what would that look like
          in the telemetry we already have?"
        - a near-miss or a peer organisation's public incident write-up.
   2. INVESTIGATE using the telemetry (Ch 52) -- structured queries against
      the hot and cold tiers, pivoting on identities, assets, and time
      windows, NOT waiting for a pre-built dashboard.
   3. FIND evidence, or don't. Either outcome is useful: evidence starts
      an incident (Ch 55); NO evidence, if the hunt was thorough,
      increases confidence the gap is currently unexploited (document
      this -- a hunt that finds nothing is not a wasted hunt).
   4. DOCUMENT AND AUTOMATE: if the hunt found a repeatable pattern worth
      catching automatically going forward, it becomes a NEW DETECTION
      (Ch 51's lifecycle) -- this is how hunting FEEDS detection
      engineering rather than being a separate, disconnected activity.
   5. REFINE the hypothesis and repeat.

   STRUCTURED METHODOLOGY: TaHiTI (Targeted Hunting integrating Threat
   Intelligence -- a published Dutch financial-sector framework, free)
   gives a concrete process for step 1-2 if you want more structure than
   "someone has a hunch."

Threat intelligence — the three levels, and why each matters differently:

   STRATEGIC     high-level trends for LEADERSHIP: "ransomware targeting
     our industry vertical rose 40% this year", informing budget and
     program priorities (Ch 62).
   OPERATIONAL   campaign-level TTPs for HUNTERS and detection engineers:
     "this threat actor cluster is currently using consent-phishing +
     living-off-the-land cloud API abuse for persistence" -- this is what
     feeds hunting hypotheses and Part 1 Ch 2's adversary-emulation
     prioritisation.
   TACTICAL      IOCs (hashes, IPs, domains) for AUTOMATED matching --
     the bottom of the Pyramid of Pain (Ch 51): cheap, useful as a
     short-lived tripwire, NOT a strategy on its own.

The intelligence cycle:

   DIRECTION -> what do we need to know? (set by strategic priorities and
     your actual threat model, G1/Part 1 Ch 4)
   COLLECTION -> commercial feeds, ISACs (sector-specific Information
     Sharing and Analysis Centers -- often free or low-cost and highly
     relevant since members share what's ACTUALLY hitting your peers),
     OSINT, government advisories (CISA alerts, sector-CERT advisories),
     and -- frequently the highest-quality source -- YOUR OWN past
     incidents and hunts.
   PROCESSING -> normalise into a usable format; STIX/TAXII for
     structured sharing between tools/organisations; MISP (a free,
     widely-used open-source threat-intel platform) as a practical way to
     collect, correlate, and share this internally and with peers/ISACs.
   ANALYSIS -> what does this mean FOR US specifically? (raw feed data is
     not intelligence until it's contextualised against your own assets
     and attack surface)
   DISSEMINATION -> to hunters (operational), to detection engineers (as
     new hypotheses), to leadership (strategic summaries), and back into
     Part 1 Ch 2's emulation-prioritisation loop.
   FEEDBACK -> did acting on this intelligence find anything? Refine
     collection priorities accordingly.

Enrichment — intelligence making individual alerts smarter:

   An alert that says "connection to 203.0.113.9" is a fact.
   An alert enriched with threat intel that says "connection to
   203.0.113.9, a known C2 IP for [threat cluster], last seen in a
   campaign targeting [your sector] two weeks ago" is a PRIORITISED,
   ACTIONABLE alert. This enrichment step (Ch 52's pipeline) is where
   tactical intelligence earns its keep on a day-to-day basis, distinct
   from the strategic/operational levels' role in shaping hunts and
   priorities.

Worked example

A hunt sourced from operational threat intelligence, ending in a new detection.

   INTELLIGENCE: an ISAC bulletin reports that a threat cluster targeting
   SaaS companies is currently using STOLEN OAUTH REFRESH TOKENS (Part 6
   Ch 39) obtained via consent-phishing, and specifically abusing them
   from RESIDENTIAL PROXY IP RANGES to blend in with normal user traffic
   and evade simple geo/ASN-based anomaly rules.

   HYPOTHESIS: "if this technique has been used against us, we'd see a
   refresh-token-derived access token used from an IP that (a) doesn't
   match the user's historical ASN pattern even after accounting for
   normal VPN/travel variance, AND (b) belongs to a residential-proxy
   ASN specifically (not just 'unusual'), within a short window of an
   OAuth consent grant to a newly-registered or rarely-used third-party
   application."

   INVESTIGATE: query the IdP sign-in logs (Ch 52) joined against OAuth
   consent-grant events (Part 6 Ch 39) and an ASN-reputation enrichment
   feed (residential-proxy ASN lists are a specific, purchasable/OSINT
   threat-intel category) for the last 90 days.

   FIND: no confirmed compromise this time -- but the hunt surfaces THREE
   legitimate-but-risky OAuth grants to third-party apps with broad,
   rarely-needed scopes (Part 6 Ch 39's "illicit consent grant" pattern,
   present but not yet abused) that a standing admin-consent-governance
   process (Part 6 Ch 39's fix) had missed.

   DOCUMENT AND AUTOMATE: the hunt query becomes a SCHEDULED detection
   (Ch 51's lifecycle) running weekly rather than a one-off, because the
   underlying technique is clearly live in the threat landscape (per the
   ISAC bulletin) even though this particular hunt found no active
   exploitation -- exactly the "hunt found nothing, but wasn't wasted"
   outcome, converted into ongoing coverage plus a real, separate finding
   (the over-scoped OAuth grants) that gets remediated regardless.

Practice (75 min)

Join (or research) a relevant ISAC or subscribe to a government/sector advisory feed (CISA alerts, or your national CERT) for one week; pick one bulletin relevant to your environment and turn it into a hunting hypothesis.
Run the hunt: write the structured query against your actual telemetry (Ch 52), joining at least two data sources (e.g. identity logs + an application-layer event).
Whatever you find (or don't), document it per the loop above — including, if you find nothing, an explicit note on what that increases your confidence about and for how long.
Convert one hunt query into a scheduled, automated detection (Ch 51's lifecycle) if the underlying hypothesis is one worth watching continuously rather than one-off.
Set up (or explore) MISP and import one public threat-intel feed; practice enriching a sample alert with a MISP lookup and observe how the enrichment changes its apparent priority.

Common mistakes

Hunting is alert-driven in practice. "We investigated an alert" is incident response, not hunting. A hunt starts from a hypothesis with no triggering alert.
Treating "we found nothing" as a failed or wasted hunt. Document the negative result and what confidence it buys you — that's real value.
Consuming only tactical (IOC) threat intelligence. Cheap, disposable, and the least useful level on its own; operational intelligence is what actually shapes good hunting hypotheses.
No feedback loop from hunting back to detection engineering. A repeatable pattern found by hand should become an automated rule; otherwise every future occurrence needs the same manual effort.
Intelligence collected but never contextualised to your own assets. Raw feed data isn't intelligence until someone asks "does this matter for us, specifically."
No sector/ISAC participation. Peer organisations are often hit by the same campaigns first or simultaneously; this is frequently the highest-signal, lowest-cost intelligence source available and the most commonly skipped.

Check yourself

What distinguishes threat hunting from investigating a triggered alert?
Name the three levels of threat intelligence and who each is primarily for.
Walk through the intelligence cycle's six stages.
Why is "the hunt found nothing" not the same as "the hunt was wasted"?
How should a hunting finding feed back into detection engineering (Ch 51)?
What does an ISAC provide that a commercial threat-intel feed alone typically doesn't?