Threat Hunting Bootcamp

Threat hunting is the proactive, human-driven process of searching through networks and endpoint data to find attackers who have evaded automated detection. It is not running reports. It is not reviewing alerts. It is starting with a question — "Are there signs of lateral movement in our environment?" — and systematically searching for evidence that answers it, regardless of whether any alert was triggered.

The philosophical foundation of threat hunting is the Assume Breach model: operate as if adversaries are already inside your network, because sophisticated attackers frequently are — undetected, for months. The 2023 IBM Cost of Data Breach report found the global average dwell time before detection is 204 days. Hunters find attackers during that dwell period. Alerts find attackers only when they make a detectable mistake — and sophisticated actors often don't.

The key distinction between a threat hunter and a SOC analyst: a SOC analyst investigates what the SIEM told them to look at. A threat hunter decides what to look for based on adversary intelligence, environmental knowledge, and analytical reasoning — then goes looking for it with no guaranteed result.

Every hunt starts with a structured hypothesis. An unstructured hunt — "look for anything suspicious" — produces inconsistent results and wastes analyst time. A structured hypothesis frames the exact adversary behaviour being hunted, the data sources that would contain evidence, the specific queries to run, and the criteria for a positive finding.

A good hunt hypothesis has four components: Actor (who are we hunting — a specific group, or a technique common to many actors?), Technique (what ATT&CK technique or behaviour pattern?), Data source (where would evidence exist — Windows event logs, EDR telemetry, network traffic?), and Observable (what specific artefact would confirm the hypothesis — a specific process tree, a registry key, a network pattern?).

Hunting is only as good as your data. If you do not have process creation logs, you cannot hunt for process injection. If you do not have DNS logs, you cannot hunt for DNS tunneling. Before designing hunts, you must know exactly what data your environment collects, how long it is retained, how quickly it is available, and what is missing. A data source gap inventory is the first deliverable of any new hunting programme.

The MITRE ATT&CK Data Sources component (part of ATT&CK since 2021) maps each technique to the data sources that could detect it. This is the reference for understanding what you need to collect to detect specific techniques. If a technique you want to hunt for requires "Network Traffic: Network Connection Creation" and you have no network flow logs — you have a collection gap, not a detection gap. Collection gaps must be resolved before hunting gaps.

Elastic Security (formerly Elastic SIEM) is the best free SIEM available — the full security analytics platform with detection rules, timeline investigation, ML anomaly detection, and hunting capabilities is available in the free (Basic) tier. Combined with the Elastic Agent and Fleet Server for centralised endpoint telemetry, it gives you a production-capable hunt platform at no cost.

Kibana Query Language (KQL) is the primary hunting query interface in Elastic Security. EQL (Event Query Language) is the more powerful correlation query language for hunting multi-event attack sequences. The Elastic Security Detection Rules repository (github.com/elastic/detection-rules — 1,000+ free rules) is both a detection resource and a learning tool — each rule shows how to query for specific ATT&CK techniques in Elastic.

KQL is excellent for single-event queries. EQL (Event Query Language — native to Elastic, also used in Microsoft Defender and other tools) is designed for multi-event sequences — finding attack chains where event A is followed by event B within a time window on the same host. This is the language of real attack hunting, because attacks are sequences of actions, not single events.

EQL's sequence keyword chains events that must occur in order, on the same host or user, within a maximum time window. This is how you find: "a Word document opened PowerShell, which downloaded a file, which was then executed" — a three-event chain that constitutes a macro-based attack. No single event in this chain is necessarily alarming. The sequence is.

Sigma is a generic, open signature format for SIEM systems. A Sigma rule describes a detection pattern that can be converted to KQL (Elastic), SPL (Splunk), YARA-L (Chronicle), SQL (Panther), or any other query language using the free sigmac converter. Writing hunts in Sigma means writing once and running everywhere — critical for hunters who work across multiple environments or want to share hunt outputs with the community.

The SigmaHQ repository (github.com/SigmaHQ/sigma) contains 3,000+ community-contributed rules covering every major attack technique. This is both the primary community resource for detection and an educational tool — reading how expert hunters express detection logic in Sigma teaches query construction patterns.

Velociraptor (free, open-source) is the most powerful free endpoint hunting and response platform available. It deploys a lightweight agent to every endpoint and lets you run VQL (Velociraptor Query Language) queries across your entire fleet simultaneously — in real time. A hunt that would take days of manual investigation can be answered in minutes: "Show me every Windows endpoint in the environment that has svchost.exe running from outside System32." Results from 10,000 endpoints arrive in seconds.

Velociraptor's power comes from its Artifact system — pre-built VQL queries covering hundreds of forensic artefacts (Shimcache, Prefetch, UserAssist, Scheduled Tasks, Services, Autorun locations, browser history, SRUM, and more). Running an artifact fleet-wide lets you hunt at scale without writing a single line of VQL.

Sysmon transforms Windows event logging from coarse (process created, user logged in) to granular (which process created this process, with what command line, from what parent, with what hash, connecting to what IP from what PID). This granularity is what makes Sysmon the foundation of effective endpoint hunting.

The most important Sysmon event for hunting is Event 1 (Process Creation) — it captures the full command line, the parent process, the image hash, and the user. Together these fields answer every process-based hunt question. Event 3 (Network Connection) pairs every network connection with the process that made it. Event 10 (Process Access) captures LSASS access for credential dumping hunting. Event 7 (Image Loaded) tracks DLL loading — critical for DLL hijacking and living-off-the-land hunting. Together these seven events cover 90% of all hunt use cases.

C2 (Command and Control) beaconing is the regular check-in behaviour of malware — it connects to its C2 server at intervals to receive commands. The beacon interval is the attacker's primary operational parameter: short intervals (seconds) mean fast response but more detectable traffic; long intervals (hours) mean slower operations but harder to detect. Sophisticated tools like Cobalt Strike add "jitter" — random variation in the interval — to evade naive beacon detection.

Beacon detection works on the statistical regularity of connections. Even with 30% jitter, a 5-minute beacon interval produces connections at roughly 5-minute intervals for hours or days. The key metrics: connection frequency from a specific source to a specific destination, small but consistent data transfer volumes, consistent duration, and persistent connection over time.

DNS is the most overlooked and most valuable hunt data source. Every connection to the internet starts with a DNS query. Malware that successfully avoids detection in all other channels must still resolve its C2 domain — and that DNS query is logged. DNS logs reveal: C2 domains before the connection is made (giving time to block), DNS tunneling (data exfiltration hidden in DNS queries), Domain Generation Algorithm (DGA) domains (automatically generated nonsense domains used by botnet malware), and newly registered domains (attackers register new domains for each campaign).

DNS hunting uses three primary techniques: frequency analysis (which domains are queried most? least?), string analysis (is the domain randomly generated? Too long? Too many subdomains?), and reputation lookups (when was this domain registered? Is it in threat intelligence?). The combination finds malicious domains that no single technique alone would catch.

ATT&CK-based hunting starts with a specific technique (e.g., T1055.003 — Process Injection: Thread Execution Hijacking) and works systematically toward a hunt query. The process: understand exactly what the technique does at the OS level → identify what Windows APIs or system calls it uses → determine what artefacts those operations leave → identify which data sources contain those artefacts → write queries targeting those artefacts → validate against emulation output → tune for false positives.

The Atomic Red Team project (github.com/redcanaryco/atomic-red-team) provides free, open-source attack emulation tests for 800+ ATT&CK techniques. Running an Atomic test, then hunting for its output, is the most efficient way to validate hunt coverage and develop hunt queries — you know exactly what attack was executed, so you can reverse-engineer what evidence it leaves and write queries targeting that evidence.

Threat intelligence platforms (MISP, OpenCTI) automate the conversion of intelligence into hunt queries. When MISP receives an IOC from a threat feed — a malicious IP address, a C2 domain, a malware hash — it can automatically push that IOC to your SIEM for hunting, to your firewall for blocking, and to your EDR for blocking or alerting. This is the intelligence-to-hunt pipeline that high-maturity security teams operate.

The most valuable use of TI in hunting is not IOC matching — that is threat feed automation. The most valuable use is TTP hunting from intelligence: taking a published report about actor X's techniques, extracting the specific behavioural patterns described, and writing hunt queries targeting those behaviours in your environment. IOCs expire in days; TTPs remain valid for years.

Detection engineering is the systematic process of converting hunt findings and threat intelligence into reliable, maintained, production-quality detection rules. It applies software engineering discipline — version control, testing, review, deployment pipelines, and performance monitoring — to detection content. Without detection engineering discipline, rules accumulate, drift, and generate alert fatigue. With it, every rule is tested, documented, and regularly validated.

The detection-as-code approach stores all detection rules in a Git repository, tests them in a CI/CD pipeline before deployment, and automatically deploys approved rules to the SIEM. This means: no untested rules in production, full audit trail of every rule change, and the ability to roll back any change that causes problems. It treats detection rules with the same rigour as application code.

A threat hunting programme is not a project — it is an ongoing operational capability that requires structure, metrics, and executive visibility to sustain. Hunts must be prioritised, tracked, and reported. Findings — both positive findings (threats found) and negative findings (technique not present, collection gap identified) — have value and must be communicated. The programme's effectiveness must be measured.