Overview
Each hunt begins with a written hypothesis: “an adversary is using valid accounts from an unusual geography”, “a scheduled task is being used for persistence”, “data is leaving through a cloud storage API”. An unfocused search through logs finds nothing but volume.
Every hypothesis is then tested against your actual telemetry. The outcome is one of three things: evidence of compromise, evidence that the technique would not be visible if it happened, or a clean result with a detection rule left behind so the question is answered automatically next time.
Engagement at a glance
- Typical duration
- 2 to 4 weeks per hunt cycle
- Telemetry
- EDR, authentication and identity, DNS, proxy, cloud audit logs, email
- Approach
- Hypothesis-driven, mapped to MITRE ATT&CK
- Prerequisite
- Log retention of at least 30 days; 90 preferred
- Deliverable
- Findings, plus durable detection content you keep
- Cadence
- Quarterly cycles, or triggered by threat intelligence
What is covered
Every item below is tested and recorded, so the report shows what held as clearly as what failed.
- Hypothesis development from current threat intelligence
- Endpoint telemetry analysis and anomaly review
- Identity and authentication pattern analysis
- Network, DNS and proxy egress analysis
- Cloud control-plane audit log review
- Persistence mechanism sweeps
- Living-off-the-land binary usage
- Command and control beaconing detection
- Data staging and exfiltration patterns
- Telemetry gap assessment
- Detection engineering and rule handover
- ATT&CK coverage mapping
Test matrix
What is attempted in each class, and what it means when it works.
| Class | What is attempted | Typical impact |
|---|---|---|
| Valid account abuse | Authentication baselined per identity: geography, time, device, impossible travel, service accounts behaving interactively | Intrusion using credentials rather than exploits, the most common and least alerted shape |
| Persistence | Scheduled tasks, services, run keys, WMI subscriptions, cloud functions and roles created outside change windows | Adversary with durable access that survives remediation |
| Beaconing | Periodicity and jitter analysis across egress telemetry, including DNS and cloud-fronted channels | Live command and control that no signature matched |
| Living off the land | Legitimate administrative binaries used in illegitimate sequences | Activity invisible to controls watching for malware |
| Data staging | Archive creation, unusual bulk reads, cloud storage writes outside normal patterns | Exfiltration in progress or in preparation |
| Telemetry gaps | Which ATT&CK techniques your current logging could not evidence even in principle | Blind spots documented before an incident finds them for you |
What we commonly find
It was logged, never queried
The evidence is frequently already in the data. Nobody had asked the question, because no rule was written for it.
Service accounts behaving like people
Interactive logons from accounts that should only ever authenticate to one service, at one time, from one host.
Retention shorter than dwell time
Logs retained for 30 days cannot answer a question about an intrusion that began 90 days ago. That finding alone frequently changes the logging budget.
Old compromises, still live
Persistence from an incident that was declared closed, because remediation removed the malware and not the scheduled task that reinstalled it.
How the engagement runs
Scoping and threat modelling
Map the asset, the attacker profile, and what “compromised” actually means for this business. Rules of engagement, testing windows, excluded techniques and an escalation contact are agreed in writing before anything is sent.
Reconnaissance and surface mapping
Enumerate everything reachable: subdomains from multiple passive sources, every endpoint referenced in JavaScript bundles, exposed services, third-party integrations, and the assets nobody remembers deploying. Coverage is recorded per host, so what was not tested is as visible as what was.
Manual exploitation
Authenticated testing from every role, with at least two accounts per role. Business logic, authorisation boundaries, injection, race conditions and state transitions, with each candidate reproduced live before it is written down. Automated tooling contributes coverage; it never contributes findings.
Verification and impact
Every finding is reproduced in a fresh session, isolated to the single parameter that causes it, and pushed to its maximum realistic impact. A finding that cannot survive a clean-room reproduction does not appear in the report.
Reporting and retest
The report is written twice over: once for the engineer who has to fix it, once for the auditor who has to file it. A walkthrough session follows, then a retest of every finding, closed only when re-exploitation fails.
What you receive
Executive summary
One page for the people who approve budget: what was tested, what was found, what it means in business terms.
Technical findings
Each finding with severity, CVSS, affected component, full request and response, reproduction steps and a working proof of concept.
Attack chains
Where findings combine, the chain is written out end to end, from first request to demonstrated impact.
Remediation guidance
A specific fix for your stack and framework, with the corrected pattern, not a link to a generic reference page.
Audit mapping
Findings mapped to SOC 2, ISO 27001, PCI DSS, HIPAA and OWASP ASVS as applicable, so the report drops straight into an audit pack.
Retest and attestation
Every finding retested in a clean session after remediation, with a signed attestation letter for customers and auditors.
When to run it
- Quarterly, as an ongoing assurance cycle rather than a one-off.
- After threat intelligence indicates your sector or stack is being actively targeted.
- Following a security incident, to confirm the adversary is genuinely gone.
- Before or after a merger, when you inherit an estate whose history you do not know.
Questions
What telemetry do you need?
At minimum: endpoint detection and response data, authentication and identity logs, and DNS or proxy egress records. Cloud audit logs and email telemetry widen coverage considerably. If a data source is missing, that becomes a documented finding in its own right. You cannot hunt for what was never recorded.
What if you find nothing?
A clean hunt is a real result, and it is delivered with the detection content built during it, so the same hypotheses are answered automatically from then on. The engagement always leaves behind durable capability rather than only a verdict.
Is this the same as managed detection and response?
No. MDR is continuous monitoring against known signals. Hunting is a periodic, human, hypothesis-led search specifically for what monitoring is not built to catch. They are complements, hunting typically produces the detection rules that MDR then runs.
What happens if you find an active intrusion?
You are notified immediately by the escalation contact agreed at scoping, before anything else, and we can move directly into incident response under our DFIR service if you want us to.
How much does threat hunting cost?
Scope is driven by estate size, the telemetry available, and whether the engagement is a one-off hunt or a recurring programme. A fixed quote follows scoping. Where telemetry is thin, the first engagement usually pays for itself by identifying what is not being logged.
How is threat hunting different from a penetration test?
A penetration test asks whether an attacker could get in. Threat hunting assumes one already did and goes looking for them in your data. The two answer different questions and neither substitutes for the other; organisations with mature detection usually need the second more than the first.
How far back can you hunt?
As far as your retention allows, which is usually the binding constraint. Thirty days of telemetry limits a hunt to thirty days. Where retention is shorter than the dwell times seen in your sector, that gap becomes a documented finding in its own right, because you cannot hunt for what was never recorded.
Do you provide detection rules we can keep?
Yes. Every hunt leaves engineered detection content behind, written for your stack, so a question asked manually once is answered automatically thereafter. The rules are yours and remain yours whether or not the engagement continues.
Can you hunt in cloud and SaaS environments?
Yes. Cloud control plane logs, identity provider events and SaaS audit trails are where the modern intrusion is visible, and they are frequently the telemetry nobody is reading. Coverage includes anomalous role assumption, consent grants to unexpected applications and access from unusual geographies.