What it is
A proactive search through your own systems for an attacker who is already inside and has not triggered any alert.
Most organisations learn they were breached only when someone outside tells them. Hopefully not a client.
Your security tools catch what they were built to recognise. Hunting looks for what they were not: quiet, legitimate-looking activity. A valid login from the wrong place, a mailbox rule nobody created, an administrative tool running at an odd hour.
Who it's for
Threat hunting is for organisations that want to know if they have already been compromised, even when there are no alerts and no obvious signs of an attack. The usual reasons people call:
- A breach next door. A supplier, partner or competitor in your sector was hit, and you want to know whether you were too
- Leaked credentials. Employee passwords turning up in a leak or an infostealer dump
- An acquisition or a merger. Inheriting an environment whose security history nobody can vouch for
- An alert that was closed but never explained. Filed as a false positive, with no evidence either way
- Assurance after an incident. Proving the attacker is genuinely gone, not just quiet
- A question you have to answer with evidence. From an insurer, a customer's security questionnaire, or your board
- Nobody has ever actually looked. The most common reason of all
What hunts have turned up
At a bank outside Israel, a hunt surfaced an employee who had spent months installing backdoors on machines left unlocked and unattended. Nothing in the environment had flagged it.
At another client, a purpose-built webshell had been sitting on a server for six months, quietly taking customer data.
Neither was found by an alert. Both were found because someone went looking.
What you get
- Hunt report. Every hypothesis tested, the data examined for it, and the verdict, so the clean results are as documented as the findings
- Findings and evidence. Anything confirmed or suspicious, with the evidence behind it, how far it reached, and what to do first
- Detection gaps. The log sources you are missing, the retention windows that are too short, and where in your environment an attacker would be invisible
- Coverage map. The attacker techniques hunted for, mapped to MITRE ATT&CK, and the ones your telemetry could not cover
- Reusable hunt queries. The queries themselves, written to be run again. Your own IT team or your IT provider can put them on a schedule; if you would rather not own that, I can run them for you periodically
- Prioritised action plan. Ordered by risk removed per unit of effort, not by severity label
- Executive summary. Written so a non-technical board can decide and act
How it works
Hunting is not a scan, and not a tool pointed at a network. It runs as a loop: form a specific, testable idea of how an attacker would operate in your environment, then look in the data for the traces it predicts. Every answer sharpens the next question.
- 1 · Scoping and baseline
- 2 · Hypotheses
- 3 · Hunt execution
- 4 · Triage and validation
- 5 · Reporting and handover
A loop: triage feeds new leads back into the hypotheses, and the handover feeds the next hunt
| Phase | What happens |
|---|---|
| 1 · Scoping and baseline | Understanding the environment, what matters most in it, and which telemetry actually exists, and for how long. Establishing what normal looks like, because hunting is largely the discipline of recognising the abnormal. |
| 2 · Hypotheses | A prioritised set of testable statements ("an attacker with a valid password is reading mail through a forwarding rule", "a remote-access tool was installed and is used out of hours") drawn from current threat intelligence for your sector, your architecture, and known attacker behaviour. |
| 3 · Hunt execution | Identity, mail, endpoint and network telemetry are queried for the traces each hypothesis predicts. Anything odd that fits no hypothesis is followed anyway. That is where hunts most often earn their keep. |
| 4 · Triage and validation | Benign explanations are separated from real ones. Every lead is either explained or escalated, nothing is left as "probably fine", and new leads feed straight back into the hypothesis set. |
| 5 · Reporting and handover | Written findings, the detection gaps, the reusable queries, a prioritised plan, and a walkthrough for both your technical team and your management. |
What I need from you
It varies from case to case, but in practice it comes down to two things:
- Read-only access to your telemetry and log sources. Identity, mail, endpoint and network, plus anything else you retain. Read-only throughout: nothing in your environment is changed, and no agent or tool is installed to make the hunt possible
- One technical or security contact on your side. Someone who can grant that access, widen it as the hunt opens new questions, and tell me what counts as normal in your environment
A standard hunt runs about ten working days. Beyond granting access at the start and answering the occasional question, your IT person is barely involved while it is running. Afterwards, how much work lands on your team depends on what was found.
Who does the work
I run the engagement myself. You deal with one person from start to finish. When the work needs extra hands or a specific specialism, I bring in professionals I have worked with before, under the same confidentiality terms, and you always know who is touching your systems.
Confidentiality
What you tell me, and what I find, stays between us. Full confidentiality is guaranteed during the engagement and after it, and an NDA can be signed before we discuss any detail. Your data sits on my systems only for as long as the work needs it. Once we have been through the report together, it is deleted.
Standards the work follows
- MITRE ATT&CK. Shared vocabulary for attacker behaviour, and the basis of the coverage map
- TaHiTI. Targeted Hunting integrating Threat Intelligence: the intelligence-led hunt methodology
- PEAK. Hypothesis-driven hunt structure, including documenting what was ruled out
- NIST CSF 2.0. The functions the findings and gaps map onto
After the hunt
Most hunts end with a short list of gaps in the environment. Closing them, whether logging and retention, identity hardening, EDR tuning, turning findings into alerts that fire by themselves, or repeating the hunt on a regular cycle, is available as follow-on work, never as a condition of the engagement.