31. SOC, SIEM and Incident Response
31.10 Threat Hunting
Example first. The SolarWinds attack, found in December 2020, hid inside a trusted software update. For months no alert fired. The security company FireEye found it only because a staff member noticed a second phone was registered for one login, and the team pulled the thread. That is threat hunting: looking for quiet signs when nothing has alerted.
Why it matters
Alerts catch only what you already wrote a rule for. Clever attackers stay below those rules. Threat hunting looks for them on purpose, before damage is done.
What it is
Threat hunting means actively searching your systems for hidden attackers, starting from an idea rather than waiting for an alert.
| Word | Simple meaning |
|---|---|
| Hypothesis | An idea to test, like "an attacker may be using PowerShell to download files". |
| Baseline | What normal looks like, so you can spot what is different. |
| IOC | Indicator of compromise: a clue like a bad IP or file hash (Chapter 39.5). |
| TTP | Tactics, techniques and procedures: how an attacker behaves (Chapter 31.9). |
| Dwell time | How long an attacker stays unseen. Hunting lowers it. |
| Alerting | Threat hunting |
|---|---|
| Waits for a rule to fire | You go looking on purpose |
| Finds known attacks | Finds quiet, unknown ones |
| Automatic | Human-led, curious |
How to run a hunt
- Pick a hypothesis, often from a MITRE ATT&CK technique.
- Decide what data answers it: which logs on which systems.
- Search that data and compare against your baseline.
- Look into anything odd; confirm if it is bad or safe.
- If bad, start incident response (Chapter 31.6).
- Turn a good hunt into a new alert rule so it runs by itself next time.
Worked examples
Worked example 1: Rare parent-child process (Windows)
- Hypothesis: Word or Excel should not start PowerShell.
- Search EDR data for PowerShell whose parent is
winword.exeorexcel.exe. - Any hit is suspicious; check what the command did.
Worked example 2: Odd outbound connections (Linux)
# which programs are connecting out, and where?
sudo ss -tnp | sort -k5A normal web server talks on ports 80 and 443. A shell or cron job calling a strange IP is worth a closer look.
Worked example 3: Logins at strange hours
- Hypothesis: a stolen account may be used at night.
- In the SIEM, list successful logins by hour for each user.
- A user who always works 10am-6pm logging in at 3am is a lead.
- Check the source IP and device; confirm with the person.
Real incident: SolarWinds (2020)
1. What happened
Attackers hid malicious code in a SolarWinds software update. Many large organisations installed it. The attackers stayed hidden for months with no alert.
2. How it was found
- A security team noticed an extra device registered to one user's login.
- They did not ignore the small oddity; they investigated.
- That led them to the hidden backdoor in the update.
3. Lesson
- Hunt for quiet signs, not just loud alerts.
- Build a baseline so odd things stand out.
- Follow small clues to the end.
In short
- Threat hunting = searching for hidden attackers your alerts missed.
- Start from a hypothesis, often a MITRE ATT&CK technique.
- Compare against a baseline of normal.
- Turn good hunts into new alert rules.