threat-detection

---
name: threat-detection
description: Use when hunting for threats, analyzing IOCs, or detecting behavioral anomalies in telemetry via hypothesis-driven hunting and MITRE ATT&CK-mapped signals.
category: Engineering
version: 1.0.0
tools: []
---

# Threat Detection

Proactive discovery of attacker activity through hypothesis-driven hunting, IOC analysis, and behavioral anomaly detection. This is NOT incident response (reactive containment of declared incidents) or red team operations (offensive simulation) — this is about finding threats that have evaded automated controls before alerts fire.

## Distinction from Other Security Disciplines

| Focus | Approach |
|-------|----------|
| Threat detection (this skill) — finding hidden threats | Proactive — hunt before alerts |
| Incident response — active incidents | Reactive — contain and investigate declared incidents |
| Red team — offensive simulation | Offensive — test defenses from attacker perspective |
| Cloud security — cloud misconfigurations | Posture — IAM, S3, network exposure |

Prerequisites: read access to SIEM/EDR telemetry, endpoint logs, and network flow data. IOC feeds require freshness within 30 days to avoid false positives. Hunting hypotheses must be scoped to the environment before execution.

## Threat Hunting Methodology

Structured threat hunting follows a five-step loop: hypothesis, data source identification, query execution, finding triage, feedback to detection engineering.

**Hypothesis scoring:** priority score = (actor_relevance x 3) + (control_gap x 2) + (data_availability x 1), where actor relevance asks how closely the TTP matches known threat actors in your sector, control gap asks how many existing controls would miss this behavior, and data availability asks whether the telemetry needed to test the hypothesis actually exists.

**High-value hunt hypotheses by tactic:**

| Hypothesis | MITRE ID | Data Sources | Priority Signal |
|-----------|----------|--------------|-----------------|
| WMI lateral movement via remote execution | T1047 | WMI logs, EDR process telemetry | WMI process spawned from WINRM, unusual parent-child chain |
| LOLBin execution for defense evasion | T1218 | Process creation, command-line args | certutil.exe, regsvr32.exe, mshta.exe with network activity |
| Beaconing C2 via jitter-heavy intervals | T1071.001 | Proxy logs, DNS logs | Regular interval outbound connections +/-10% jitter |
| Pass-the-Hash lateral movement | T1550.002 | Windows security event 4624 type 3 | NTLM auth from unexpected source host to admin share |
| LSASS memory access | T1003.001 | EDR memory access events | OpenProcess on lsass.exe from non-system process |
| Kerberoasting | T1558.003 | Windows event 4769 | High volume TGS requests for service accounts |
| Scheduled task persistence | T1053.005 | Sysmon Event 1/11, Windows 4698 | Scheduled task created in non-standard directory |

## IOC Analysis

IOC analysis determines whether indicators are fresh, maps them to required sweep targets, and filters stale data that generates false positives.

| IOC Type | Staleness Threshold | Sweep Target | MITRE Coverage |
|---------|--------------------|--------------|----|
| IP addresses | 30 days | Firewall logs, NetFlow, proxy logs | T1071, T1105 |
| Domains | 30 days | DNS resolver logs, proxy logs | T1568, T1583 |
| File hashes | 90 days | EDR file creation, AV scan logs | T1105, T1027 |
| URLs | 14 days | Proxy access logs, browser history | T1566.002 |
| Mutex names | 180 days | EDR runtime artifacts | T1055 |

IOCs older than their threshold are `stale` and must be excluded from sweep target generation — running sweeps against stale IOCs inflates false positive rates and reduces SOC credibility. Refresh IOC feeds from threat intelligence platforms (MISP, OpenCTI, commercial TI) before every hunt cycle.

## Anomaly Detection

Statistical anomaly detection identifies behavior that deviates from established baselines without relying on known-bad signatures.

**Z-score thresholds:** below 2.0 is normal (no action); 2.0-2.9 is a soft anomaly (log and monitor, increase sampling); 3.0 or above is a hard anomaly (escalate to a hunt analyst, investigate the entity).

Effective anomaly detection requires at least 14 days of historical telemetry to establish a valid baseline. Baselines must be recomputed after security incidents (post-incident behavior change), major infrastructure changes (cloud migrations, new SaaS deployments), and seasonal usage pattern shifts (end of quarter, holiday periods).

**High-value anomaly targets:** DNS resolver queries-per-hour-per-host (beaconing, tunneling, DGA); endpoint unique-process-executions-per-day (malware installation, LOLBin abuse); service account auth-events-per-hour (credential stuffing, lateral movement); email gateway attachment-types-per-hour (phishing campaign spike); cloud IAM API-calls-per-identity-per-hour (credential compromise, exfiltration).

## MITRE ATT&CK Signal Prioritization

Each hunting hypothesis maps to one or more ATT&CK techniques. Techniques with multiple confirmed signals in your environment are higher priority.

| Tactic | Key Techniques | Primary Data Source |
|--------|---------------|--------------------|
| Initial Access | T1190, T1566, T1078 | Web access logs, email gateway, auth logs |
| Execution | T1059, T1047, T1218 | Process creation, command-line, script execution |
| Persistence | T1053, T1543, T1098 | Scheduled tasks, services, account changes |
| Defense Evasion | T1027, T1562, T1070 | Process hollowing, log clearing, encoding |
| Credential Access | T1003, T1558, T1110 | LSASS, Kerberos, auth failures |
| Lateral Movement | T1550, T1021, T1534 | NTLM auth, remote services, internal spearphish |
| Collection | T1074, T1560, T1114 | Staging directories, archive creation, email access |
| Exfiltration | T1048, T1041, T1567 | Unusual outbound volume, DNS tunneling, cloud storage |
| Command & Control | T1071, T1572, T1568 | Beaconing, protocol tunneling, DNS C2 |

## Deception and Honeypot Integration

Deception assets generate high-fidelity alerts — any interaction with a honeypot is an unambiguous signal requiring investigation. Types and placement: honeypot credentials in a vault secrets store (signal: credential access attempt, T1555); honey tokens like fake AWS access keys in git repos or S3 objects (signal: reconnaissance or exfiltration, T1552.004); honey files named like `passwords.xlsx` on file shares or endpoints (signal: collection staging, T1074); honey accounts — dormant AD users (signal: lateral movement pivot, T1078.002); honeypot network services in the DMZ or flat network segments (signal: network scanning or service exploitation, T1046/T1190).

Honeypot alerts bypass the standard scoring pipeline — any hit is an automatic SEV2 until proven otherwise.

## Workflows

**Quick hunt (30 minutes)**, for responding to a new threat intelligence report or CVE alert: score the hypothesis against environment context (actor relevance, control gap, data availability); build an IOC sweep list from the threat intel (IPs, domains, hashes); check for anomalies in the relevant telemetry over the last 24 hours. Escalate to a full hunt if the hunt priority score is 7 or higher, or any IOC sweep hits.

**Full threat hunt (multi-day).** Day 1 — hypothesis generation: review threat intelligence feeds for sector-relevant TTPs, map the last 30 days of security alerts to ATT&CK tactics to find gaps, score the top 5 hypotheses, and prioritize by score. Day 2 — data collection and query execution: pull relevant telemetry from the SIEM (last 14 days), run anomaly detection across entity baselines, execute IOC sweeps for all feeds fresh within 30 days. Day 3 — triage and reporting: triage all anomaly findings (confirm or dismiss), escalate confirmed activity to incident response, document new detection rules from hunt findings, and submit false-positive IOCs back to the TI provider.

**Continuous monitoring:** run anomaly detection against key entity baselines on a recurring cadence (e.g. every 6 hours), and auto-escalate any hard anomaly (z-score >= 3.0) to a hunt analyst immediately rather than batching it into a periodic report.

## Anti-Patterns

1. **Hunting without a hypothesis** — broad queries across all telemetry without a focused question generate noise, not signal. Every hunt must start with a testable hypothesis scoped to one or two ATT&CK techniques.
2. **Using stale IOCs** — indicators older than 30 days generate false positives that train analysts to ignore alerts. Always check IOC freshness before sweeping; exclude stale indicators from automated sweeps.
3. **Skipping baseline establishment** — anomaly detection without a valid baseline produces alerts on normal high-volume days. Require 14+ days of baseline data before enabling statistical alerting on any entity type.
4. **Hunting only known techniques** — exclusively documented ATT&CK techniques miss novel adversary behavior. Regularly include open-ended anomaly analysis that can surface unknown TTPs.
5. **Not closing the feedback loop to detection engineering** — hunt findings that confirm malicious behavior must produce new detection rules; hunting that doesn't improve detection coverage has no lasting value.
6. **Treating every anomaly as a confirmed threat** — a high z-score indicates deviation from baseline, not confirmed malice. All anomalies require human triage before escalation.
7. **Ignoring honeypot alerts** — any interaction with a deception asset is a high-fidelity signal; treating honeypot alerts as noise invalidates the entire deception investment.

## Adjacent Expertise

Confirmed threats from hunting escalate to a teammate with incident-response expertise for triage and containment. Red team exercises generate realistic TTPs that inform hunt hypothesis prioritization — @mention that teammate for input. Cloud posture findings (open S3, IAM wildcards) create hunting targets for data-exfiltration TTPs, and pen-test findings identify attack surfaces threat hunting should monitor post-remediation.