2.4.3. Threat Hunting Concepts

💡 First Principle: Threat hunting assumes threats are already present in your environment and uses proactive analysis to find them — it's the difference between waiting for an alarm to go off and actively checking whether something has already bypassed the alarm.

Standard detection is reactive: alerts fire when a rule matches. Hunting is proactive: analysts form a hypothesis ("I believe an APT may have established persistence via scheduled tasks on our file servers") and then search the evidence to confirm or deny it, regardless of whether any alert fired.

IoC-Based Hunting:

• Collection — Gather IoCs from intelligence sources (hashes, IPs, domains, registry keys, user agents)
• Analysis — Enrich and validate IoCs: is this IP still active? Is this hash a known FP?
• Application — Search historical SIEM data for any past or present matches; deploy as detection rules for ongoing monitoring

Hypothesis-Based Hunting (TTP-Driven): More mature than IoC hunting. The hunter forms a hypothesis based on TTPs (not specific indicators):

• "Based on MITRE ATT&CK T1053 (Scheduled Task), I'll look for recently created scheduled tasks on servers that don't typically have scheduled task changes, running as SYSTEM, pointing to executables in temp directories."
• This detects novel malware that has no known IoC because it targets the behavior (scheduled task as persistence), not the specific tool.

The hunt cycle runs in order: form the hypothesis, collect and query the relevant telemetry, analyze the results to confirm or reject the hypothesis, then operationalize confirmed findings as new detection rules (or escalate to IR). A hunt that finds nothing is still a documented, useful result: it records what was checked and raises confidence in the environment, without proving it is secure. Anomalies that match no SIEM rule are not dismissed; investigate them, and turn confirmed findings into new rules.

Threat Hunting Focus Areas:

Active Defense and Honeypots:

• Active defense — Proactively engaging with adversary activity to gather intelligence or increase cost of attack. Includes honeypots, deception technology, and controlled engagement with threat infrastructure.
• Honeypots — Decoy systems with no legitimate business use. Any interaction with a honeypot is inherently suspicious — legitimate users have no reason to access them. Honeypots detect internal threats, attacker reconnaissance, and credential abuse.

⚠️ Exam Trap: Threat hunting and incident response are not the same activity. IR responds to a confirmed or suspected incident. Threat hunting is proactive investigation with no confirmed incident — the hunter is looking for evidence of compromise that hasn't triggered any alert. Hunting often leads to IR when it finds something.

Atomic and Behavioral Indicators

Lockheed Martin's intelligence-driven defense paper (Hutchins, Cloppert, and Amin) sorts indicators into three types:

CS0-004 names atomic and behavioral. The practical difference is durability: an adversary who recompiles its loader and rents new servers invalidates every atomic and computed indicator from the last campaign, but repeating the same sequence of actions still matches a behavioral detection. This is the Pyramid of Pain seen from the indicator side. In David Bianco's Pyramid of Pain, indicators are ranked by how much it hurts the adversary when you detect and deny them: hash values (trivial to change), IP addresses, domain names, network/host artifacts, tools, and at the top TTPs (the attacker must change how they operate). Detection aimed at the upper levels is the most valuable.

STRIDE for Analysts

STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is usually taught as a design-time threat-modeling method, but each category also maps to the security property it violates, which helps an analyst classify what an observed threat puts at risk:

⚠️ Exam Trap: A shared account with no per-user audit trail is a repudiation problem (a real user can deny a real action), not spoofing. Spoofing needs someone pretending to be someone else.

Threat Mapping

CS0-004 lists threat mapping beside threat modeling without defining it. In practice the term covers two related activities, and the exam can approach either:

• Threat maps — live visualizations that security vendors publish of the attack activity their own sensors observe, usually plotted by source and target location. (Earlier CompTIA exams list threat maps as a threat-intelligence source.) They are good for situational awareness and briefings, and weak for decisions: they show only what that vendor's sensors saw, and they place attacks by source IP, which proxies, VPNs and botnets can put in any country.
• Mapping threats to your environment — take the TTPs of the actors most relevant to your sector, map them onto MITRE ATT&CK, and overlay what your detections actually cover (often as a heat map, such as an ATT&CK Navigator layer). The output is a prioritized list of detection gaps — the likely techniques you currently cannot see — which drives detection engineering and hunt hypotheses.

🎯 Exam Tip: A threat map showing "a surge of attacks from country X" is not a reason to geo-block X: the source IPs are often relays. Treat a public threat map as awareness, and act on your own telemetry.

Reflection Question: An organization deploys a honeypot server named "PROD-DB-BACKUP-OLD" with no legitimate business function. It's given a realistic-looking name and fake database files. Two weeks later, the honeypot logs show an authentication attempt using a valid service account credential. What does this indicate, and why is the honeypot more valuable than a SIEM alert would have been in this case?