Consulting · Threat Hunting · Hypothesis-led

We don't wait for alerts. We go looking for what your rules were never written to catch.

A hypothesis-driven engagement that pivots through your SIEM, EDR, DNS logs, and identity telemetry — testing specific adversary tradecraft against the data you already generate. Each hunt returns either a confirmed finding to hand to DFIR, or a verified absence backed by the queries that proved it.

Scope a hunt Read the methodology

The alert-driven SOC problem

The adversary in your logs from six months ago does not trigger today's alerts.

An alert-driven SOC only sees what its rules were written for. If the adversary's tradecraft predates the rule — or the rule never existed — they sit quietly in your logs until something else trips a sensor. Industry median dwell time is still measured in months, not minutes, and that is exactly why.

Detection coverage gaps

A SIEM with ten thousand rules still has thousands of MITRE techniques uncovered. The adversary picks one of those.

Telemetry left unread

You collect DNS, proxy, identity, EDR, cloud audit — terabytes of it. Most of it is queried only when a known IOC arrives. The unknowns sit unread.

No-finding ≠ not-breached

If you never went looking for a technique, "we don't see it" is not the same as "it isn't there". A hunt closes that gap, one technique at a time.

Engagement modes

One hunt to validate one hypothesis. Or a hunt programme that runs alongside your SOC.

SPRINT

Single-hypothesis sprint · 2 weeks

One concrete hypothesis, scoped, hunted, and answered. Pick a technique that keeps you awake — your sector's currently-active adversary, a new CVE, a recent breach in your peer group. Two weeks later you have an evidence-backed finding or absence, plus new detection rules you didn't have before.

· 2-week fixed scope, fixed price
· One named hypothesis · 1–3 ATT&CK techniques
· Output: signed report + Sigma / EQL / YARA rules
· Findings routed to DFIR if confirmed

PROGRAMME

Hunt programme · quarterly cadence

A recurring engagement that runs three to four hypothesis sprints per quarter, prioritised against current threat intelligence and your sector's incident record. New detections drop into your SOC stack every cycle. Hunter mentoring for your in-house team is available as an add-on.

· 3–4 sprints per quarter · prioritised by TI + your sector
· Quarterly hunt-programme review with the CISO
· Detection-rule library grows every cycle
· Optional: hunter shadowing for your team

Methodology

Six phases. One hypothesis at a time. Every hunt converts to a detection.

"The loop maps to industry threat-hunting frameworks — TaHiTI and PEAK — with disciplined hypothesis design at the front and forced codification at the back. A hunt that doesn't measurably harden the environment or close a visibility gap was an audit, not a hunt."

Hunt types we run

Six patterns. Every engagement picks one or two.

TTP hunt

Pick one MITRE technique (or sub-technique). Build the data model. Query every system that would have generated a trace. Result: confirmed activity, false positives understood, new rule.

IOC retro-hunt

New intelligence drops a hash, an IP, a JA3 signature, or a YARA rule. We sweep your historical telemetry — sometimes years deep — to find prior contact.

Anomaly hunt

Statistical baselines on identity, network, or process telemetry. Outliers get a manual second look. Useful when the technique is too novel to have a signature.

Identity-centric hunt

Service accounts, machine accounts, OAuth applications, and admin sessions. The fastest-growing attack surface and the slowest-instrumented one.

Cloud-control-plane hunt

CloudTrail, Activity Logs, GCP audit logs. IAM-trail reconstruction, privilege-escalation paths, suspicious cross-tenant activity.

OT-side hunt

Engineering-workstation behaviour, PLC project changes, HMI session timing. The hunt category that most generalist SOCs do not staff.

Sample hunt · DNS-over-HTTPS C2 · two-week sprint

One hypothesis. End to end. From intel inflow to new detection rule.

A worked example of a single-hypothesis hunt. Hypothesis is real, tradecraft is real, the customer is anonymised; outcome and final detection rule are typical.

Day 1
Intel · why this hypothesis
Recent threat-intel reporting describes adversary tradecraft using DNS-over-HTTPS (DoH) to known public resolvers for command-and-control, evading legacy DNS sinkholing. Sector-relevant. Hypothesis selected.
Day 2
Hypothesise · make it testable
"Non-browser processes are issuing TLS connections to known DoH provider domains/IPs from production endpoints, over a sustained period." Time-boxed: trailing 90 days of telemetry.
Day 3
Instrument · find the gap
Available: EDR network events, Zeek conn logs, TLS SNI. Missing: JA3 fingerprints from the EDR baseline. We enable JA3 capture as a side-deliverable — useful for many future hunts.
Days 4–7
Hunt · query and pivot
Filter EDR + Zeek for TLS connections to a maintained DoH IP/SNI list, grouped by process. Initial result: 1,800 connections from 14 processes. Of these, 11 are browsers (expected). The other three need closer inspection.
Day 8
Confirm · deny · per candidate
Process A: signed Microsoft binary doing Windows-update DoH (expected, deny). Process B: telemetry agent from a vendor — vendor confirms DoH usage (deny). Process C: signed but recently-installed productivity tool with no public reason to use DoH. Memory + process-tree inspection: bundled software dependency pulling updates via DoH. Vendor confirms; expected behaviour but flagged as policy concern. Final result: no adversary activity, but two policy-deviation findings for IT to address.
Days 9–10
Codify · ship the detections
Three Sigma rules added to the SIEM: "TLS to DoH provider from non-browser parent", "TLS to DoH provider from unsigned binary", "Sustained DoH connection volume from an endpoint exceeding baseline". One Zeek script for ongoing JA3-based DoH detection. All four ship with reasonable false-positive thresholds, tested against last 90 days of data.

Outcome

Verified absence of adversary DoH C2 in the 90-day window. Two policy-deviation findings escalated to IT. Three new SIEM rules and one Zeek script shipped into production. JA3 fingerprint capture now standard. Next sprint hypothesis: ADCS misconfiguration paths.

What changes after the first hunt

Detection coverage that grows. Telemetry that gets used. Dwell time that shrinks.

Confirmed finding or verified absence

Each hunt closes one specific question. No more "we don't know if we have it."

Detection-rule library

Every hunt ships Sigma / EQL / YARA rules. The SOC stack gets sharper every sprint.

Telemetry-gap inventory

Hunts surface what you cannot see. Each gap is an instrumentation backlog item with a known reason.

Hunter mentorship

Optional add-on: your team shadows the engagement, learns the discipline, runs the next sprint internally.

Aligned to

CERT-In threat advisories
NCIIPC sector intel feeds
MITRE ATT&CK
TaHiTI
PEAK
Sigma · EQL · KQL · SPL
YARA · YARA-L
Zeek · Suricata · osquery

Practice

"If you have never gone looking for a technique, the answer to whether you have it isn't 'no'. The answer is: you don't know. A hunt is how 'don't know' becomes either 'no' or 'yes, and here is the evidence'."

Threat Hunting · operational principleThe case for hypothesis-driven hunting as a discipline distinct from alert triage.

Name the technique that keeps you awake. Hunt it.

Two-week sprints. Fixed scope. Fixed price. One hypothesis answered, new detection rules shipped, an evidence-backed yes-or-no.

Scope a hunt Programme enquiry