Threat Hunting & Detection Engineering

Threat hunting is the proactive, human-led search for adversaries who have evaded automated detection. It flips the SOC's default posture: instead of waiting for an alert, the hunter assumes a breach may already be present and goes looking for evidence of it. The premise is that your tools do not catch everything, so someone has to hunt for what slipped through.

The disciplined form is hypothesis-driven. A hunt starts with a testable statement, usually informed by threat intelligence or knowledge of the environment: "If an adversary were establishing persistence, I would expect to see new scheduled tasks or run-key modifications on servers that rarely change." The hunter then queries telemetry to prove or disprove it.

Hunts come in flavors:

• Intel-driven — pursue IOCs or TTPs from a threat report.
• Hypothesis/TTP-driven — hunt for a specific ATT&CK technique you believe you would be vulnerable to.
• Anomaly/baseline-driven — surface statistical outliers against a known-good baseline.

Two acronyms shape how defenders think about evidence. Indicators of Compromise (IOCs) are forensic artifacts that show a breach has occurred: a malicious file hash, a known-bad IP or domain, a specific registry key, a mutex. They are concrete and easy to share, but they are also reactive — by definition they describe something that already happened and that the attacker can trivially change.

Indicators of Attack (IOAs) focus on behavior and intent — the sequence of actions an adversary must take regardless of the specific tools they use. Example: a process reads credentials from LSASS memory, then uses them to authenticate laterally, then stages data for exfiltration. The attacker can swap malware and infrastructure freely, but the underlying behavior of what they are trying to accomplish is much harder to disguise.

Both matter. IOCs are cheap wins and great for sharing; IOAs are durable detections that survive the attacker retooling. Mature programs invest steadily up the behavioral end.

David Bianco's Pyramid of Pain (2013) is the single best mental model for detection strategy. It ranks the types of indicators you can detect by how much pain it causes the adversary when you deny them — that is, how hard it is for them to adapt. From the trivially-changed base to the deeply-painful peak:

1. Hash values — trivial. Recompile and the hash changes.
2. IP addresses — easy. Attackers rotate infrastructure constantly.
3. Domain names — simple. New domains are cheap.
4. Network/host artifacts — annoying. User-agents, file paths, registry keys take effort to alter.
5. Tools — challenging. Rebuilding or replacing tooling costs real time and skill.
6. TTPs — tough! Changing core tactics, techniques, and procedures forces the adversary to relearn how they operate.

The pyramid does not say "ignore hashes" — low-level indicators are cheap and worth blocking. It says know where each detection sits, and understand that value climbs steeply as you ascend toward behavior.

Detection engineering is the discipline of building, testing, and maintaining detections as a rigorous software-like practice rather than a pile of ad-hoc SIEM rules. The guiding idea is detection-as-code: treat detection logic like source code — version-controlled in Git, peer-reviewed, tested against sample data, and deployed through CI/CD pipelines.

This solves chronic SOC problems. Rules stop being undocumented black boxes one analyst wrote and left; changes are reviewable and revertable; and detections can be automatically validated so a schema change does not silently break coverage. Teams increasingly test their detections against emulated attacks using frameworks like Atomic Red Team or Caldera to confirm a technique actually fires the rule it should.

A common portable format is the Sigma rule — an open, YAML-based, vendor-neutral signature standard for log events. You write the detection logic once in Sigma, then compile it to the query language of whatever backend you run (Splunk SPL, Elastic, Sentinel KQL, and so on). Sigma is, loosely, "what Snort is for network traffic and YARA is for files, but for log-based detections."

MITRE ATT&CK is a free, continuously updated knowledge base of real-world adversary behavior, organized as a matrix of tactics (the adversary's goals — e.g. Initial Access, Persistence, Lateral Movement, Exfiltration) and the techniques and sub-techniques used to achieve each. Every technique has an ID like T1059 (Command and Scripting Interpreter), giving defenders a shared vocabulary that maps directly to how attackers actually operate.

Defenders use ATT&CK to map their detection coverage. By tagging each detection to the technique it catches, you can build a coverage heatmap — often with the ATT&CK Navigator — that shows exactly where you are strong and where you are blind. That visualization turns "are we secure?" into a concrete, answerable question.

You cannot detect a technique you have no telemetry for. Coverage gaps are usually data gaps first.

This is where hunting, detection engineering, and ATT&CK converge. A coverage map reveals telemetry gaps — techniques you could never see because the necessary logs are not collected (say, no command-line auditing, so you are blind to scripting abuse). The fix is not another rule; it is turning on the missing telemetry first, then writing the detection. Prioritize the gaps by which techniques the threats actually facing your organization are known to use.