Threat hunting: internal and external intelligence

Why this matters

Threat hunting is the proactive half of detection: searching for activity that existing detections did not catch, on the working assumption that some of it is there. It exists because detection is built from what is known, and an attacker who avoids known patterns produces no alerts at all.

The distinction CAS-005 tests is between hunting and alert response, and it is clean. Alert response begins with a detection and asks whether it is real. Hunting begins with a hypothesis and asks whether the data supports it. A team that describes itself as hunting while working a backlog of low-priority alerts is doing triage.

The second half of the objective is intelligence — internal and external — and the theme there is usefulness rather than volume. A feed's value is measured by whether it changes a decision. Most do not, and a programme consuming several that do not is paying for noise and treating it as coverage.

The lesson

Hypothesis-driven hunting, and how it differs from responding to an alert

A hunt begins with a statement that can be supported or refuted by data. Good hypotheses are specific and falsifiable:

"An attacker with a foothold on a workstation is using the management agent's service account to reach servers it has never authenticated to before."

That is testable. "Look for anything suspicious" is not, and the difference between the two determines whether the hunt produces anything.

Where hypotheses come from, in decreasing order of yield:

• Threat intelligence about a relevant actor: this group uses this technique, do we see it.
• Coverage gaps from the ATT&CK map in lesson forty-two: we cannot detect this technique, so it would be invisible — go and look manually.
• Your own architecture: what would an attacker do here, given this design? This is the threat model from lesson nine consumed as hunting input.
• Anomalies that were not actionable as alerts but are interesting in aggregate — the broad rule versions that lesson forty-two preserved.
• Incidents elsewhere, in your sector or supply chain.

The method: state the hypothesis; identify the data that would show it and check you actually have that data; query; analyse the results, which are mostly benign and where the work is; and conclude.

The property that makes it a discipline rather than browsing is that the conclusion is recorded either way. A hunt that finds nothing is a result — it says that at this time, over this data, this behaviour was not present, with a known confidence bounded by data coverage. That record is valuable and is routinely not kept, which is why programmes repeat hunts and cannot say what they have looked at.

And the most important output of a hunt is not a finding: it is a new detection. A hunt that found something should end with a rule so it is never hunted again, and a hunt that found nothing should still leave behind either a detection or a documented reason one is not possible. Without that, hunting is labour that does not accumulate.

Internal intelligence: honeypots, honeytokens and user behaviour analytics

Internal sources produce signals specific to your estate, and their great advantage is fidelity.

Honeypots are systems with no legitimate purpose, deployed to be found. Any interaction is suspicious by construction, because nothing has a reason to touch them. They need care: they must be believable enough to be worth touching, isolated enough that compromising one gains nothing, and monitored — an unmonitored honeypot is just an extra vulnerable host.

Honeytokens are the cheaper and, for most organisations, better version: data that should never be used. A credential in a configuration file that no service reads, a decoy record in a database, a document in a share, a DNS name that nothing should resolve, an API key that appears in a repository. Any use is a high-confidence signal with essentially no false positive rate, and the cost is close to zero.

Their particular value is that they fire after other controls have failed. A honeytoken credential being used means someone read a file they should not have; a decoy record being accessed means a query touched data it should not. These are among the few detections that work when the attacker is behaving legitimately in every other respect, which is precisely the situation lesson twenty described for lateral movement.

User and entity behaviour analytics apply the baselining of lesson forty-three to users, hosts and service accounts, scoring deviations. Its strengths are catching a valid credential in the wrong hands and detecting insider misuse, both of which are invisible to signature-based detection. Its weaknesses are the baselining weaknesses from that lesson: new entities have no history, peer groups must be coherent, and anomalous is not malicious — which is why its output belongs in a hunt queue or as a prioritisation signal rather than in the queue that must be worked.

Your own incident history is the last internal source and the most underused. What has been attempted, what worked, which controls failed. It is the most relevant intelligence available and it is free.

External intelligence: OSINT, dark web monitoring, ISACs and vendor feeds

External sources tell you what is happening outside, and their quality varies enormously.

Open sources — vendor research, government advisories, public reporting, vulnerability disclosures, community rule sets. Free, broad, variable in timeliness, and frequently excellent.

Sector sharing organisations are usually the highest-value external source for a given organisation, because the intelligence is from peers facing the same actors with the same technology, and it arrives with context that a commercial feed lacks. Participation is reciprocal, which is part of why it works.

Commercial feeds and research services offer timeliness, curation and analysis. The question to ask of any of them is whether it changes a decision you would otherwise make differently — many are broad collections of indicators that overlap heavily with free sources.

Dark web and criminal forum monitoring is narrower than it is marketed. It genuinely helps with credential exposure — your users' credentials in a breach dump, which is directly actionable — and with early warning that your organisation is being discussed or that access to it is being sold. It is not a general detection capability.

Exposure monitoring belongs here too and is unglamorous and effective: certificate transparency for hostnames on your domains, public code repositories for your leaked secrets, and external attack surface scanning. These tell you what an attacker sees, which no internal source can.

Two evaluation criteria worth applying to any external source, and they are what a scenario about "too many feeds" is asking for. Relevance: does it cover your sector, your technology, your geography — or is it generic. And actionability: does it arrive in a form you can operationalise, and does acting on it change anything. A feed of ten thousand indicators of unknown age, consumed into a block list, is a source of false positives and an availability risk rather than a detection capability.

Threat intelligence platforms, and scoring a feed by whether it changes a decision

A threat intelligence platform aggregates sources, deduplicates, enriches, scores and distributes to the tools that consume intelligence. It is the integration layer, and without one an organisation with several sources is manually reconciling overlapping lists.

What it should do:

• Deduplicate across sources, so one indicator seen in five feeds is one indicator with five corroborations — and corroboration across independent sources is itself a confidence signal.
• Attach and maintain confidence, combining source reliability, age and corroboration.
• Age indicators out. This is the function most often neglected and the most important. Indicators decay: an address that hosted a command-and-control server last year is now probably a legitimate service, and blocking it is self-inflicted disruption. Every indicator needs an expiry.
• Distribute automatically to the SIEM, the gateway, the endpoint platform.
• Record what matched, which is the data needed to evaluate the source.

That last point enables the measure the section is named for. For each source, over a period: how many indicators did it supply, how many matched anything in your estate, how many of those matches were true positives, and how many false positives did it cause. That produces a defensible answer to whether a subscription is worth renewing, and it usually surprises people — a large, expensive feed with zero matches in a year is not providing coverage, whatever its size suggests.

Two operational cautions. Do not block automatically on low-confidence indicators; alert on them and block only on high confidence, because automatic blocking on a poor feed is a denial-of-service vector an attacker can trigger by getting your own addresses listed. And strategic intelligence is not the same as indicators: reporting on how an actor operates informs architecture and detection design, and its value is not measured by match counts at all.

Turning a hunt that found nothing into a detection that would find it next time

The closing discipline, and it is what makes hunting compound rather than repeat.

A hunt ends with three questions:

What did we look for, over what data, for what period? Recorded, with the query. This is the record that lets a future reader know what has been covered and lets the hunt be repeated identically.

What would have made this easier or possible? Almost every hunt reveals a data gap — a source not collected, a field not parsed, retention too short, a join impossible. Those are the concrete requirements that justify the ingestion decisions in lesson forty-one, and they are far more persuasive than a general request for more logging.

What detection should exist now? If the hypothesis was worth testing once, it is worth testing continuously. Convert the hunt query into a rule where the false positive rate allows, or into a scheduled low-priority feed where it does not. Either way the behaviour is no longer hunted manually.

That third question is the one that determines whether a hunting programme accumulates capability or performs the same searches forever. A programme with forty hunts and no new detections has spent its time without changing what it can see.

Two measures worth reporting, and they are small numbers that fit the board report from lesson three: detections created per hunt, and data gaps identified and closed. Both describe capability growth. Neither is "hunts performed", which — like playbook count in lesson twenty-eight and CVE count in lesson thirty-two — measures activity and not effect.