Threat Hunting Services

• Hypothesis-driven
• ATT&CK aligned
• Becomes detection content
• Not alert triage

Hunting exists because detection is incomplete by definition. The purpose is not to find something every time — it is to convert each hunt into a detection that fires automatically next time.

What hunting is and is not

Hunting is not working an alert queue faster. An alert means a detection already existed. A hunt starts from a hypothesis about technique — "if an adversary were living off the land in this estate, what would that look like in our telemetry?" — and goes looking in data that raised nothing.

How a hunt runs

1. HypothesisDrawn from your sector's observed threat activity and your own architecture's weak points, mapped to MITRE ATT&CK technique rather than to a vendor category.
2. Data checkConfirm the telemetry needed to test it actually exists. Very often it does not — and that finding alone justifies the hunt.
3. HuntQuery, pivot, eliminate. Most hunts end in nothing found, which is a result, not a failure.
4. ConvertWhatever was queried manually becomes a scheduled detection with a documented false-positive profile. This is the deliverable.
5. Feed backGaps found become either new telemetry sources or an accepted, documented blind spot.

Why the conversion step matters

A hunting program that produces reports and not detections resets to zero every quarter. Ours is measured on detection content shipped and coverage added, not on hours spent or findings raised. You should be able to point at the rule set and say which hunt produced each line of it.

The hunt loop

Where hypotheses come from

Worked example — DLL search-order hijacking hunt

Hypothesis: an adversary has placed a malicious DLL in a directory that a legitimate signed application searches before the system directory, achieving execution under a trusted process.

1. Data checkRequires module-load telemetry with the full path and signer of both the loading process and the module. Confirmed available — but only on Windows endpoints, not on the 60 servers still awaiting agent deployment. That limitation was recorded as part of the result.
2. Baseline queryAll module loads where a signed process loaded an unsigned DLL from a user-writable path. 2,847 hits — far too many to review, which is normal at the first pass.
3. RefineExcluded known development directories and three legitimate applications that ship unsigned plugins. Down to 61.
4. PivotOf those 61, grouped by DLL hash. 58 were a single hash belonging to a legitimate but sloppily packaged accounting plugin. Three were unique.
5. InvestigateTwo were an engineer testing a build. One was a DLL written 14 days earlier to a path searched by a signed backup utility running as SYSTEM, on a host with no ticket explaining it.
6. OutcomeThat one was a genuine persistence mechanism from an intrusion that had not triggered a single alert. Handed to incident response within the hour.
7. ConvertThe refined query became a scheduled detection with the three known-good exclusions encoded and a documented false-positive profile. It now fires automatically.
8. CoverageThe 60 un-agented servers were logged as a blind spot with a remediation date, not quietly ignored.

Note the shape: most of the work was elimination, the finding was incidental, and the durable deliverable was the detection rule plus a documented gap.

Cadence and reporting

We report detections shipped and coverage added. Hours spent and findings raised are inputs, not outcomes, and measuring a hunting program on findings creates pressure to inflate them.