Threat Detection and Analysis
What the exam tests
This domain covers how detections are designed, tested, tuned, and how an analyst moves from a single event to a defensible conclusion using host and network evidence.
Core rules
- Detection logic sits on a spectrum. Atomic indicators such as hashes, IPs and domains are cheap to change; behavioral techniques mapped to MITRE ATT&CK are expensive for an adversary to abandon. Prefer behavioral logic wherever telemetry supports it.
- The Pyramid of Pain ranks indicators from hash and IP up through domain, host artifact, tool, and finally TTP. Detection value rises as you climb.
- Correlation beats single events. One failed logon is noise; fifty failures across many accounts from one source inside two minutes is password spraying.
- Every rule needs an owner, a documented baseline, and a measured false-positive rate. Untuned rules create the alert fatigue that hides real intrusions.
- Hunting is hypothesis-driven: state the behavior, the data source, and the expected evidence before you query.
Worked example
Detection for Kerberoasting. Reasoning: any domain user can request service tickets for accounts holding SPNs and crack them offline. Evidence appears in event 4769 as encryption type 0x17 (RC4-HMAC) where the domain normally negotiates AES, plus a burst of distinct SPNs requested from one source with no matching 4624 logon to those services. Logic: 4769 where ticket encryption is 0x17, service name is not krbtgt, and the hourly count per source exceeds baseline. Tune by excluding legacy applications that still require RC4, and validate against 4768/4769 pairs before enabling.
Traps
- Shipping indicator-only rules and calling the result coverage.
- Counting ATT&CK techniques covered without replaying the rule against real telemetry.
- Suppressing a noisy rule with no compensating detection behind it.
- Treating a single anomalous event as an incident without baseline context.