threat-detection

Find threats that evaded automated controls

Proactive, hypothesis-driven. Threat hunting starts with a question — "what if a service account was compromised?" — and ends with evidence or explicit closure of the hypothesis.

Hunt methodology (PEAK model)

Purpose → Execution → Analysis → Knowledge

1. Purpose — State the hypothesis explicitly. "I believe attacker X used technique Y (ATT&CK TTP Z) to compromise target W." Scope the data sources needed.
2. Execution — Query SIEM/EDR for the signals that hypothesis predicts. Collect raw evidence before analysis.
3. Analysis — Statistical baselines + anomaly detection + IOC correlation. Distinguish signal from noise.
4. Knowledge — Output: confirmed threat (→ incident-response), false positive (document why), or detection gap (→ new detection rule).

MITRE ATT&CK prioritisation

Not all techniques are equally probable. Prioritise hunts by:

1. Actor relevance — is this technique used by actors that target your industry/region?
2. Control gap — do existing detections cover this technique? No → higher priority.
3. Data availability — do you have the logs to run this hunt? No data = can't hunt.

Weight each 1–3; multiply. Hunt the highest scores first.

IOC analysis

IOCs decay fast. Before sweeping, check freshness (< 30 days for IPs; < 90 days for domains; hashes are permanent).

For each IOC: domain, IP, hash, or user-agent — generate sweep queries for your SIEM/EDR. Correlate hits with process trees and lateral movement signals before escalating.

Anomaly detection signals

Statistical anomaly = behaviour outside the baseline for that entity. Useful baselines:

• Authentication — login frequency, hours, geolocation, user-agent per account.
• Network — outbound connection volume, destination ASN, protocol by host.
• Process — spawned child processes, execution frequency by host and user.
• Data access — file reads per hour, new file extensions accessed.