Threat Hunting · MITRE ATT&CK · Detections you keep

Threat Hunting — we find what your SOC hasn't

Capable attackers live in the gaps your alerts don't cover. Our team hunts with hypotheses, MITRE ATT&CK and the Pyramid of Pain across your EDR, SIEM and cloud logs, and hands back detections that stay — not just a report that ages.

Request a pilot hunt How we do it See the Managed Security pillar

Approach

Hypothesis-driven, assumed breach

Framework

MITRE ATT&CK + Pyramid of Pain

Outcome

Rules, queries and ATT&CK coverage

Assume the attacker is already in. Then go and find them.

Threat hunting is the proactive, structured search for adversary activity that never triggered an alert. It doesn't replace the SOC or the EDR — it steps in when automated rules can't see a careful attacker.

Our service runs on an assumed-breach premise: we work from the starting point that something may already be inside, and we write testable hypotheses about what that activity might look like — grounded in threat intelligence, sector context and MITRE ATT&CK techniques.

Every hunt ends with more than a report. We hand back detection rules, queries and playbooks so the same thing never gets missed twice.

Key point:

A mature hunting programme isn't measured only by what it found today — it's measured by how much harder it made life for the next attacker.

Hypothesis-driven, not alert-driven

We don't wait for a red light. We form testable hypotheses about what an adversary might already be doing — grounded in threat intel, ATT&CK techniques and your business context — and we test them against real data.

MITRE ATT&CK as the compass

We map your current coverage, detection gaps and adversary techniques onto ATT&CK to prioritise where to hunt first — and which detections are still missing after.

Pyramid of Pain, applied

We go after TTPs, not just hashes or IPs. Chase the level that actually hurts the attacker so your detections don't expire the moment they rotate infrastructure.

Detections as code

Every validated hypothesis ships as reusable rules, queries and dashboards — version-controlled, handed over to your SOC (in-house or third-party), and ready to catch the same thing next Tuesday.

What a real threat hunting programme actually covers

A serious hunt isn't running four queries and closing a ticket. It has a scope, a method, data behind it and things you can ship.

Assumed breach

We start from the premise that something is already inside and hasn't been caught. The job of the hunt is to surface it — not to confirm everything is clean.

Endpoint, cloud and identity

We hunt across EDR/XDR telemetry, cloud logs (Azure/AWS/GCP), identity (Entra ID/AD), network and the SaaS that actually matters to your business.

Tool-agnostic

We work with the SIEM and EDR you already have. Hunting well doesn't require ripping and replacing your stack.

Real handoff

Findings don't die in a PDF. They become detection rules, playbooks and visibility improvements that live inside your SOC.

Telemetry we hunt on

You can't hunt what you can't see. We validate coverage and log quality before promising outcomes. These are the sources we typically integrate:

EDR/XDR (Microsoft Defender, CrowdStrike, SentinelOne, Cortex XDR and equivalents)

SIEM (Microsoft Sentinel, Splunk, Elastic, QRadar and equivalents)

Identity logs (Entra ID / Active Directory, federation, MFA)

Cloud logs (Azure Activity/SignIn, AWS CloudTrail, GCP Audit Logs)

Network telemetry (NetFlow, proxy, DNS, next-gen firewall)

Critical SaaS logs (M365, Google Workspace, core CRM/ERP)

Asset and exposure data (CMDB, vulnerability management)

Threat intelligence (commercial feeds, OSINT, sector sharing)

Deliverables that leave capability behind, not just a PDF

The goal: the next attack has to clear more detections, more visibility and more governance than the last one.

Prioritised hunt plan

Hypotheses for the cycle, ranked by priority, mapped to ATT&CK techniques, with the telemetry needed and the success criteria for each.

Cycle executive report

The board version: hypotheses hunted, findings, residual risk, recommendations and how the posture moved vs the previous cycle.

Technical hunt report

Per-hunt methodology, queries run, evidence collected, analysis, IOCs/TTPs observed and recommended actions.

Rules and queries, ready to ship

SIEM/EDR rules, KQL/SPL (or equivalent) queries and dashboards packaged for your operations team.

ATT&CK coverage map

Current coverage vs gaps, with detection-engineering priorities for the next cycles — not a one-off snapshot.

Lessons learned

Visibility, logging, hardening and governance improvements that came out of the hunt, with owners suggested.

How a threat hunting cycle runs

Iterative cycles, clear hypotheses, a clean audit trail and detections that stick.

Scoping and data readiness

We lock down crown-jewel assets, available sources, log quality, EDR telemetry and SIEM access. No data, no serious hunt.

Hypothesis generation

We pull from threat intel, sector-relevant actors, ATT&CK techniques and the realities of your business to write hypotheses we can actually verify.

Hunt execution

Query the data, apply the analytics, walk the patterns, and either confirm or discard each hypothesis with a clean audit trail.

Triage and escalation

Anything with impact goes straight to your incident response team (or ours) for containment — with chain of custody preserved.

Detection engineering

What we learned becomes persistent rules, queries and playbooks — versioned, tested, and owned — so the same hunt never has to happen twice.

Reporting and review

Executive report, technical report, updated ATT&CK coverage, and the plan for the next cycle. Hunting is iterative, not a one-off.

What a real hunt tends to find

Illustrative examples drawn from the client profile we typically work with. Details are anonymised to protect confidentiality.

Anonymised case

Large European financial group

Hybrid estate with M365, Azure, federated AD and a mature in-house SOC on an established SIEM.

Hypothesis

Hypothesis: OAuth abuse in enterprise apps following a targeted phishing attempt.

Outcome

Found a token granted to an app with anomalous mail permissions. Controlled revocation, a new detection for high-risk consent grants and a tightened approval workflow.

Anonymised case

Public-sector body running 24/7 operations

Mixed estate with EDR rolled out only partially — uneven coverage on legacy servers.

Hypothesis

Hypothesis: service-level persistence on Windows after a peripheral alert had been dismissed by the SOC.

Outcome

Confirmed activity consistent with an implant on servers without EDR. Handoff to IR, isolation, eradication, an EDR-rollout plan for the rest of the estate and a targeted detection rule.

Anonymised case

Industrial group with critical operations

IT environments segmented from OT, with parts of the perimeter maintained by third parties.

Hypothesis

Hypothesis: malicious use of legitimate remote-admin tooling by a third-party integrator.

Outcome

Identified an RMM session outside authorised windows running unusual commands. Account disabled, vendor contract reviewed, and new detections for after-hours access and command-profile anomalies.

If your organisation looks like any of these — regulated, running critical operations, or dependent on third parties — there's almost certainly activity your SOC hasn't seen yet. A pilot hunt confirms it in days.

How Threat Hunting fits with the rest of the service

Hunting is a proactive layer on top of detection, response, vulnerability management and red team. Wired together properly, it closes the defend-attack-detect loop.

SOC/MDR 24/7

Runs continuously on the detections the hunt produces.

Incident response

Takes over when a hunt confirms active malicious activity.

Adversary simulation

Feeds realistic TTPs into hunt hypotheses and hardens detections.

Vulnerability management

Shrinks the attack surface and steers hunts toward what's actually exploitable.

Threat Hunting FAQ

What it is, what it needs, how it's measured, and how it connects to SOC, EDR, IR and red team.

What exactly is threat hunting, and how is it different from a SOC?

Threat hunting is the proactive search for malicious activity that has already bypassed your automated controls. A SOC operates on alerts generated by rules that already exist. A hunt starts from a hypothesis, looks at data with no alert attached, and tries to uncover what wasn't caught. The SOC answers what it already knows about; the hunt goes looking for what it doesn't.

What methodologies do you use?

Industry-standard ones, applied honestly. MITRE ATT&CK for mapping adversary techniques. David J. Bianco's Pyramid of Pain to prioritise detections that actually hurt the attacker. Hunt cycles based on approaches like TaHiTI or PEAK, tuned to your context and maturity — not copied from a slide deck.

What data and visibility do you need to hunt?

The minimum that's honest: EDR/XDR telemetry across the endpoints that matter, identity logs, cloud logs where applicable, network telemetry and logs from critical apps — all with enough retention. Without the data, a hunt falls apart, which is why step one is always validating telemetry coverage and quality.

How often should you hunt?

Hunting is iterative, not a one-off. The common rhythm is a recurring cycle (monthly or quarterly) plus ad-hoc hunts after material changes: new sector-relevant threats, recent incidents, big deployments, or M&A activity.

Does threat hunting replace EDR, SIEM or the SOC?

No. It complements them and makes them stronger. EDR and SIEM provide the telemetry. The SOC runs alerts against SLAs. The hunt finds what those layers missed and ships new detections back to the SOC. A mature posture runs all three together.

How is a hunt different from a red team exercise?

Red team attacks to validate your defences and processes. Threat hunting defends by looking for signs of a real attack in the data you already have. Red team is offensive and bounded. Hunting is defensive and continuous. They feed each other: red-team TTPs become hunt hypotheses, and the detections built afterwards sharpen the next engagement.

How do you measure a threat hunting programme?

With hard numbers. Hypotheses run, ATT&CK coverage gained, findings confirmed, detection rules handed to the SOC, estimated dwell-time reduction, visibility gaps closed and logging improvements shipped. The value isn't only catching the current attacker — it's raising the bar for the next one.

Does this help with DORA, NIS2 or ISO 27001?

Yes. A serious hunting programme generates strong evidence of advanced detection and continuous improvement: recurring reports, ATT&CK coverage, new detections, lessons learned and an audit trail. It fits particularly well as supporting evidence for DORA, NIS2 and ISO 27001.

Do you have to be our SOC to hunt?

No. We work with whatever SIEM and EDR you already have, alongside your in-house or third-party operations team. If we also run your managed SOC, the integration is smoother — but it's not a prerequisite.

What happens when a hunt confirms active malicious activity?

Containment protocol kicks in and we escalate to the incident response team, preserving evidence for forensics, root cause and reporting. The finding stops being an exercise and becomes an incident with the assurances and communications each framework demands.

Inside Managed Security

Threat Hunting is the proactive layer of the Managed Security pillar, alongside SOC/MDR, vCISO and continuous vulnerability management.

See the full Managed Security pillar → See SOC/MDR See Virtual CISO See Vulnerability Management

What if there's already activity on your network that hasn't tripped a single alert?

Start with a pilot hunt on the telemetry you already have. In one closed cycle you'll know what's there, which visibility gap to close, and which detections you keep.

Talk to a threat hunter Call now

SOC/MDR 24/7 Incident response IR retainer Digital forensics Adversary simulation Vulnerability management Threat intelligence Virtual CISO (vCISO) DORA NIS2 Financial sector