Guides

Threat Hunting for Beginners (Defence)

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

Threat hunting is a defender practice: you form a hypothesis about how an adversary might hide in your environment, query the telemetry you already collect, document findings, and either open an incident, write a new detection, or close the lead with evidence — not wait forever for a perfect SIEM alert.

Hypothesis → Telemetry → Query → Findings → IR or detection or close
No telemetry = sightseeing
No notes = tribal knowledge that quits with you

What do I need before this guide?

• SIEM basics: What is SIEM / how SOC uses it.
• Optional detections: MITRE ATT&CK + Sigma.
• Optional endpoint context: EDR vs Antivirus.

What does beginner hunting look like?

Hunting is not:

1. Random Google of exploit PoCs.
2. Scanning the public internet “for practice”.
3. Ignoring the alert queue while you chase cool graphs.

Hunting is:

1. Structured curiosity against logs you are allowed to see.
2. Mapping ideas to ATT&CK tactics at a high level for shared language.
3. Feeding gaps back into detections and playbooks.

Educational warning: only hunt in labs you own or environments where your role and policy explicitly allow investigation. Unauthorised access to third-party systems is illegal — full stop.

Real incident: SolarWinds (2020) — why hunts beyond alerts matter

Public reporting on the SolarWinds 2020 supply-chain intrusion described stealthy access across many organisations. Classic blue-team lesson: some activity looked like signed software updates or subtle cloud/identity moves that signature-only waiting missed for too long. Hunters and detection engineers who asked “what unusual admin or federation changes do we see?” found more than teams that only closed SIEM tickets.

Takeaways (vertical):

1. What happened — widespread supply-chain compromise with long dwell themes in public analyses.
2. What went wrong (theme) — trust in update channels + gaps in detecting “legit-looking” admin behaviour.
3. Care-take — hunt identity and software distribution anomalies, not only malware hashes.
4. Care-take — baseline “normal admin” so rare patterns stand out.
5. Care-take — document hunts so the next analyst inherits method, not folklore.
6. Bonus parallel — Target 2013 reminds us alerts without response culture also fail; hunt findings need owners.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try

• Live off the land with admin tools so EDR noise looks familiar.
• Move slowly under threshold-based alerts.
• Disable or clear local logging when they can (high-level).
• Abuse valid accounts so events look “authorised”.

Blue Team — defend, detect, respond

• Central immutable-ish logs and EDR retention you can actually query.
• Hypothesis backlog aligned to your crown jewels.
• Hunt → detection promotion with false-positive tuning.
• Escalate quickly when hunt confirms compromise; do not “watch for a week” silently.

How do I run a first hunt step by step?

Step 1 — Choose a hypothesis you can test

1. Bad: “Find all hackers.”
2. Good: “In the last 7 days, did any user succeed on VPN from a country never seen for that user, then create a mailbox forwarding rule within 2 hours?”
3. Good: “Which servers talked DNS to newly registered domains this week?” (lab or authorised DNS logs only).

Step 2 — Check data readiness

1. Identity / SSO logs present?
2. EDR process and network events retained?
3. Email security or Microsoft 365 audit available?
4. If a source is missing, the hunt output is “buy/fix visibility”, not a shrug.

Step 3 — Query narrowly first

1. Start with a short window and one user population (finance, admins).
2. Export a minimal field set: time (label IST), user, host, src IP, action.
3. Avoid dumping entire indexes into a spreadsheet “just in case”.

Step 4 — Pivot and timeline

1. Same IP elsewhere? Same host parent/child process oddities?
2. Build a 5–10 line timeline a manager can read.
3. Mark confidence: confirmed / suspected / benign-proved.

Step 5 — Close the loop

1. Incident — open IR with evidence links.
2. Detection — draft a rule (Sigma-minded) and tune in lab first.
3. Close — write why it was benign; save the query for regression.

Step 6 — Lab practice (authorised only)

1. Generate a controlled oddity on a VM you own (example: unusual local admin logon pattern you create yourself).
2. Hunt it with Wazuh or another lab SIEM.
3. Promote a detection; prove it fires once and stays quiet on normal noise.
4. Never “practice” by attacking neighbour Wi‑Fi or random cloud tenants.

Hypothesis starter pack (safe ideas)

1. Dormant account suddenly active at odd hours.
2. New MFA device registration for privileged users.
3. CloudTrail / audit: StopLogging, unusual AssumeRole, rare region.
4. EDR: scripting host spawning to uncommon network destinations (describe, do not weaponise).
5. DNS: bursts to domains your org never resolved before (authorised resolvers only).

Care-take — hunting that stays ethical and useful

1. Written scope and ticket for every prod hunt.
2. Privacy: minimise access to HR / medical fields.
3. Time-box: 90 minutes for a beginner hunt cycle, then document.
4. Share queries in a team repo with comments.
5. Pair junior + senior until note quality is consistent.
6. Measure “detections born from hunts”, not vanity query counts.

How do I fix common hunting mistakes?

Ghabru naka 😅 — these are the usual ones: