Learn Ethical Hacking Series):Exercise 1: ELK deployment (abbreviated).
Deployed: Elasticsearch + Logstash + Kibana via Docker Compose.
Agents: Filebeat on Ubuntu server, Winlogbeat on Windows 10 VM.
Dashboard created with 4 panels:
- Events per source (pie chart: 62% Windows, 38% Linux)
- Failed logins over time (time series, showing test burst)
- Process creation events (table: image, command line, user)
- Top 10 source IPs by event count
Verification: SSH failed login on Ubuntu -> appeared in Kibana
within 3 seconds. Windows failed logon -> appeared within 5 seconds.
The 3-second and 5-second detection latencies are excellent for a lab environment -- in production you would see similar numbers with properly configured Beats agents and a healthy Elasticsearch cluster. The 62/38 split between Windows and Linux events is typical for a mixed lab: Windows generates significantly more security events per unit of time because Sysmon and native audit policies produce fine-grained telemetry for process creation, registry modification, network connections, and file access -- while Linux syslog is comparatively quieter unless you are running auditd with aggressive rules. The dashboard design follows a solid pattern: the events per source pie chart gives you an immediate sense of where your data is coming from (and if one source suddenly stops contributing, you know an agent is down), the failed logins over time chart makes brute force attacks visually obvious as a spike in the graph, and the process creation table is the single most valuable panel for threat hunting because it shows you exactly what is executing on every machine. The test verification (SSH failed login appearing in Kibana within seconds) proves the end-to-end pipeline works -- from the event being generated on the endpoint, shipped by Beats over TLS to Logstash, parsed and indexed by Elasticsearch, to the dashboard updating in Kibana. If that pipeline breaks at any point, you are flying blind.
Exercise 2: Sigma rules implementation (abbreviated).
5 rules deployed and tested:
Rule | Attack performed | Detection latency
Kerberoasting (4769/RC4) | Rubeus kerberoast | 2 seconds
PsExec (7045 service) | psexec.py lateral | 1 second
Encoded PowerShell | powershell -enc ... | 3 seconds
LSASS access (Sysmon 10) | mimikatz sekurlsa | 1 second
Brute force (threshold) | 50 failed SSH logins | 8 seconds (after threshold)
All 5 rules triggered correctly. Zero false positives during
the 1-hour test window (tuning will be needed in production).
Five rules, five detections, zero false positives -- exactly what a well-configured detection suite looks like in a controlled environment. The detection latency column is particularly revealing. The brute force rule taking 8 seconds (compared to 1-3 seconds for the others) makes sense because it uses a threshold-based alert -- the SIEM has to accumulate 50 failed login events before firing, and the time to accumulate those events plus the polling interval of the threshold engine adds up to the longer delay. The note about zero false positives "during the 1-hour test window" is honest and important: a lab with 2 machines generates almost no legitimate background noise, so of course you get zero false positives. In a production environment with 500 workstations, 50 servers, and 3,000 users, those same Sigma rules will fire on the backup server that scans every host (looks like lateral movement), the monitoring system that connects to every machine on port 445 (looks like PsExec), and the helpdesk team's password reset tools that trigger Sysmon Event 10 on LSASS. Tuning is not optional -- it is the work that turns a detection engine into a useful one. But getting the rules to fire correctly on real attacks is the necessary first step, and the exercise proves that works ;-)
Exercise 3: Alert fatigue simulation (abbreviated).
Untuned: 500 failed login alerts generated in 5 minutes.
Real attack (Kerberoasting) buried at event #347.
Could I find it? Only by specifically filtering for Event 4769.
In a real SOC with mixed alerts: likely missed.
After tuning (threshold: 10 failures/5min/source):
Failed login alerts reduced from 500 to 3 (3 source IPs)
Kerberoasting alert: clearly visible, not buried in noise
Signal-to-noise ratio: dramatically improved
Lesson: without tuning, the SIEM is a noise generator.
With tuning, it is an attack detector.
The Kerberoasting alert buried at event #347 out of 500 is the perfect illustration of why alert fatigue is the number one SIEM failure mode. An analyst scrolling through 500 alerts in a queue sees "failed login, failed login, failed login" repeated hundreds of times and eventually stops reading them carefully. The real attack (a Kerberoasting request that generates a completely different event type -- Event 4769 instead of 4625) is visually similar enough to the noise that it gets lost. Only by specifically filtering for Event 4769 (which requires the analyst to ALREADY SUSPECT Kerberoasting is happening) can you find it -- and if you already know what to look for, the SIEM is not adding value, you are doing the detection yourself. After tuning, the same 500 failed login events collapse into 3 threshold-based alerts (one per attacking source IP), and the Kerberoasting alert stands out clearly because there are only 4 alerts total instead of 501. The signal-to-noise ratio went from 1:500 (one real alert in 500 noise alerts) to 1:3 (one real alert alongside 3 high-quality brute force alerts). That is the difference between a SIEM that helps and a SIEM that hinders.
Episode 74 covered security monitoring and SIEM -- centralized log collection, Sigma rules for universal detection, ELK Stack and Wazuh deployments, correlation rules that connect events across multiple sources, and the critical challenge of alert fatigue and tuning. That episode built the visibility infrastructure: the ability to collect, index, and search every security event across your entire environment.
But here is the fundamental limitation of everything we built in episode 74. Every SIEM rule, every Sigma detection, every correlation engine -- they are all reactive. Something happens, an alert fires, an analyst investigates. The SIEM waits. It watches. It responds. It does NOT go looking for trouble on its own. And sophisticated attackers know this. They design their operations specifically to avoid triggering the alert rules you wrote. They use Living Off the Land Binaries (LOLBins) -- legitimate Windows tools like certutil.exe and bitsadmin.exe that no SIEM rule blocks because they are part of the operating system. They blend their C2 traffic with normal HTTPS browsing (as we saw in episode 62). They move slowly -- weeks between actions, never tripping a threshold. They target the gaps in your detection coverage, because every SIEM has gaps. The alert does not fire because no rule matches. The attacker wins.
Threat hunting flips this model. Instead of waiting for the SIEM to tell you something is wrong, a threat hunter ASKS: "What if an attacker is already inside our network? What evidence would they leave? Where would I find it?" The hunter forms a hypothesis, searches the data proactively, and looks for indicators that no rule covers. The SIEM is still critical -- it provides the data platform. But the human provides the creativity, the adversarial thinking, and the ability to ask questions that nobody thought to write a rule for. The industry statistic that should make every defender uncomfortable: the average time from initial compromise to detection is 197 days (IBM 2024). Nearly half a year of undetected access. Threat hunting aims to cut that number from months to hours.
The most structured approach to threat hunting starts with a hypothesis -- a specific, testable statement about attacker activity that could be happening in your environment right now:
The hypothesis-driven hunting cycle:
1. FORM a hypothesis based on threat intelligence
"APT29 has been targeting organizations in our sector using
phishing with OAuth consent links. If we were compromised,
we would see unusual Azure AD app registrations and OAuth
token grants from unfamiliar IP addresses."
2. DEFINE the data sources needed
- Azure AD sign-in logs
- Azure AD audit logs (application registrations)
- Conditional Access policy evaluation logs
3. SEARCH the data
- Query for new app registrations in the last 30 days
- Query for OAuth grants from IP addresses not in our
known office/VPN ranges
- Query for consent grants with high-privilege scopes
(Mail.ReadWrite, Files.ReadWrite.All)
4. ANALYZE the results
- Is any result unexplained by legitimate business activity?
- Does any pattern match known APT29 TTPs?
- Are there accounts accessing resources they normally don't?
5. ACT on findings
- True positive: escalate to incident response (episode 51)
- False positive: document for future reference
- No findings: document the hunt, update hypothesis, try next
6. IMPROVE
- Finding found: create a SIEM alert rule for future detection
- Nothing found: hypothesis was wrong OR attacker was not
present. Both are valid outcomes.
The hypothesis is what separates threat hunting from "just searching logs." Without a hypothesis, you are scrolling through events hoping something looks suspicious -- which is exactly what the overwhelmed SOC analyst does with their alert queue, and it is equally ineffective. A hypothesis gives you direction: you know WHAT you are looking for, WHERE to look for it, and WHAT a positive result looks like before you start searching. The APT29 example above is driven by threat intelligence (from episode 52) -- you read that APT29 is targeting organizations in your sector, you understand their TTPs (OAuth consent phishing), and you translate that knowledge into a specific hunt that asks "did this happen to us?"
The IMPROVE step is the most important and the most frequently skipped. If your hunt found something, the natural next step is incident response (episode 51). But the step after THAT -- creating a SIEM alert rule so the same attack is detected automatically next time -- is what compounds the value of hunting over time. Every successful hunt produces a new detection rule. After 50 hunts, your SIEM has 50 new rules that cover attack patterns your original ruleset missed. Your detection coverage grows with every hunt, and the hunters can focus on NEW hypotheses instead of re-hunting for the same things. The cycle is continuous: hunt, find, automate, hunt something new.
Every attacker needs persistence -- a way to maintain access after the initial compromise, survive reboots, and keep a foothold even if one of their tools is discovered and removed. Hunting for unauthorized persistance mechanisms is one of the highest-value hunts because persistence artifacts are durable (they need to survive reboots, which means they are stored on disk or in configuration databases) and detectable (they modify well-known locations that defenders can enumerate):
# Windows persistence hunting queries
# Scheduled tasks (T1053.005)
# Look for: tasks created by non-admin users, tasks with encoded
# commands, tasks running executables from unusual paths
schtasks /query /fo CSV /v | findstr /i /v "Microsoft"
# In SIEM (Splunk example):
index=windows EventCode=4698
| where NOT match(TaskContent, "(?i)microsoft|windows|dell|vmware")
| table _time, ComputerName, SubjectUserName, TaskName, TaskContent
# Registry run keys (T1547.001)
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run"
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"
# In SIEM:
index=sysmon EventCode=13 TargetObject="*\\CurrentVersion\\Run*"
| table _time, Computer, Image, TargetObject, Details
# Services (T1543.003)
# New services created outside of software installation:
index=windows EventCode=7045
| where NOT match(ServiceFileName, "(?i)windows|program files|system32")
| table _time, ComputerName, ServiceName, ServiceFileName
# WMI subscriptions (T1546.003)
Get-WMIObject -Namespace root/Subscription -Class __EventConsumer
Get-WMIObject -Namespace root/Subscription -Class __EventFilter
Each of these queries targets a specific MITRE ATT&CK persistence technique. The scheduled task query (T1053.005) filters out Microsoft's built-in tasks and shows you everything else -- and "everything else" on a healthy system should be a short, recognizable list: your backup software, your monitoring agent, maybe your antivirus update scheduler. Anything that does NOT belong to a known application is suspicious, especially if the TaskContent field contains encoded PowerShell, references an executable in \Users\, \Temp\, or \AppData\, or was created by a non-admin user. We used scheduled task persistence in episode 32 (Windows privilege escalation) as one of the standard post-exploitation steps, and this query is the exact defense against it.
The registry run key query (T1547.001) checks the two most common autorun locations in the registry. These are the classic persistence mechanism -- drop a binary, add a run key, and the binary executes every time the user logs in. Sysmon Event 13 (RegistryEvent: Value Set) gives you real-time visibility when a run key is created or modified, which is far better than the periodic enumeration approach of reg query. The SIEM query filters for any Sysmon Event 13 targeting the \CurrentVersion\Run path, showing you the process that made the change, the registry key that was modified, and the value that was written. If you see powershell.exe writing a base64-encoded command to a run key at 2 AM, you have found persistence.
# Linux persistence hunting
# Cron jobs not owned by root or system packages:
for user in $(cut -f1 -d: /etc/passwd); do
crontab -u $user -l 2>/dev/null
done
# SSH authorized_keys (new keys = possible backdoor):
find /home -name "authorized_keys" -newer /var/log/syslog \
-exec ls -la {} \;
# Systemd services and timers:
systemctl list-unit-files --state=enabled \
| grep -v "snap\|systemd\|dbus"
# Files modified in system directories in the last 7 days:
find /usr/local/bin /usr/bin /etc/cron.d -mtime -7 -type f \
-exec ls -la {} \;
Linux persistence is conceptually simpler than Windows (fewer locations to check) but the same principles apply. Cron jobs are the Linux equivalent of scheduled tasks, and enumerating every user's crontab reveals persistence that might be hidden under a service account that nobody monitors. SSH authorized_keys modifications are one of the stealthiest persistence mechanisms -- the attacker adds their own public key to an existing user's authorized_keys file, and now they can SSH into the system as that user without knowing the password. The find -newer trick is clever: it looks for authorized_keys files that have been modified more recently than the syslog file, which means they changed since the last syslog rotation. New key additions to a machine that should not be receiving new SSH keys are immediate red flags. And systemd services that are not part of the distribution packages (filtering out snap, systemd itself, and dbus) should be a short, recognizable list on any well-managed server.
Lateral movement leaves authentication traces. Hunt for patterns
that indicate an attacker moving between machines:
Query 1: Accounts authenticating to many machines (spray pattern)
index=windows EventCode=4624 Logon_Type=3
| stats dc(ComputerName) as machines by Account_Name
| where machines > 10
| sort -machines
Normal: helpdesk accounts (3-5 machines). Abnormal: 50+ machines.
Query 2: First-time authentication to a server
index=windows EventCode=4624 Logon_Type=3
| stats earliest(_time) as first_seen by Account_Name, ComputerName
| where first_seen > relative_time(now(), "-7d")
An account that has NEVER accessed a server suddenly connects
to it = investigate.
Query 3: Admin-to-admin lateral movement
index=windows EventCode=4624 Logon_Type=3
| where Account_Name IN ("admin*", "svc_*", "t0-*", "t1-*")
| stats count by src_ip, ComputerName, Account_Name
Admin accounts should only come from known admin workstations.
Admin auth from a regular workstation = possible token theft.
Query 4: Service creation on remote hosts (PsExec pattern)
index=windows EventCode=7045
| stats count by ComputerName, ServiceName
| where ServiceName="PSEXESVC" OR match(ServiceName, "^[a-z]{8}$")
PsExec uses a known service name. Custom tools use random names.
The spray pattern in Query 1 is one of the most reliable lateral movement indicators. A normal user authenticates to their workstation, maybe a file server, maybe a web application -- 3 to 5 machines total. A helpdesk technician might hit 10-15 machines in a busy day. An attacker using CrackMapExec to spray stolen credentials across the network hits 50, 100, 200 machines in minutes. The dc(ComputerName) aggregation (distinct count of computer names per account) makes this pattern trivially visible -- sort by machines descending, and the attacker's account jumps to the top of the list.
Query 2 (first-time authentication) catches a subtler pattern. Instead of looking for volume, it looks for novelty -- accounts that have never accessed a particular server suddenly connecting to it. This catches the attacker who has compromised an account and is carefully exploring the network, connecting to one new server at a time rather than spraying everywhere. The earliest(_time) aggregation combined with a recency filter shows you all first-time account-to-machine pairings in the last 7 days. In a stable environment, this list should be short and explainable (new employee, new server deployed, scheduled maintenance). Unexplained first-time connections -- especially to high-value servers like database hosts or domain controllers -- warrant immediate investigation.
Query 3 directly addresses the tiered administration concept from episode 72. If you implemented tiering correctly, admin accounts (matching patterns like admin*, svc_*, t0-*, t1-*) should only authenticate from designated admin workstations and jump boxes. An admin authentication event originating from a regular user workstation means either someone is violating the tiering policy (which needs correction) or an attacker has stolen admin credentials and is using them from a compromised workstation (which needs incident response). Either way, the query surfaces something that needs attention.
C2 communication has characteristic patterns even when encrypted:
1. Beaconing (regular interval connections)
index=firewall action=allowed
| bucket _time span=60s
| stats count by _time, src_ip, dest_ip
| streamstats window=10 avg(count) as avg_count
stdev(count) as std_count by src_ip, dest_ip
| where std_count < 2 AND avg_count > 0
Low standard deviation = regular timing = possible beacon.
2. DNS tunneling indicators
index=dns
| eval query_len=len(query)
| where query_len > 50
| stats count avg(query_len) as avg_len by query
| where avg_len > 40 AND count > 100
Long subdomain labels + high volume = DNS tunneling.
3. JA3/JA3S fingerprint hunting
index=zeek sourcetype=ssl
| stats count by ja3, server_name
| lookup known_ja3 ja3 OUTPUT tool
| where isnotnull(tool)
Known JA3 hashes for Cobalt Strike, Metasploit, Sliver.
4. Long-duration connections
index=zeek sourcetype=conn
| where duration > 28800
| table id.orig_h, id.resp_h, id.resp_p, duration,
orig_bytes, resp_bytes
8+ hour connections to external IPs are unusual for most
workstations. Could indicate: persistent C2, data exfil, tunnel.
The beaconing detection in Query 1 is the statistical approach we introduced with RITA in episode 73, implemented directly as a SIEM query. The streamstats command calculates a rolling standard deviation of connection counts per source-destination pair -- and a low standard deviation means the connection frequency is remarkably consistent, which is the mathematical fingerprint of an automated beacon. Human browsing produces bursty, irregular traffic (click a link, read for 3 minutes, click another, leave for lunch). A C2 beacon produces metronomic traffic (connect every 60 seconds, give or take jitter). The difference is visible in the standard deviation: human traffic has high variance, beacon traffic has low variance. Having said that, a sophisticated attacker who configures very high jitter (200%+ randomization) can push the standard deviation above the detection threshold, which is why beaconing analysis is one layer in the detection stack rather than the only approach ;-)
The JA3 fingerprint approach (Query 3) is particularly elegant. JA3 creates a hash of the TLS Client Hello parameters -- the specific cipher suites, extensions, and elliptic curves that a client offers during the TLS handshake. Every TLS client has a distinctive fingerprint: Chrome has one, Firefox has another, and Cobalt Strike's HTTPS Beacon has its own. Even though the traffic content is encrypted, the handshake parameters are visible, and known C2 framework JA3 hashes have been catalogued by the security community. A Zeek SSL log entry with a JA3 hash matching Cobalt Strike's default profile is a high-confidence indicator of compromise -- although, as we discussed in episode 63, attackers can customize their TLS profiles to produce different JA3 hashes, so a match is definitive but a non-match does not mean safe.
The long-duration connections in Query 4 catch a different class of C2. Some implants do not beacon -- they establish a persistent connection and keep it open for hours or days, sending commands and responses over the same TCP session. For most workstations, an 8-hour connection to an external IP is unusual (web browsers open and close connections rapidly, email clients poll periodically, but nothing holds a single connection open for an entire workday). The exceptions are VPN tunnels, remote desktop sessions, and video conferencing -- and those destinations should be on a whitelist. Anything else warrants investigation.
Maturity levels:
Level 0: No hunting
All detection is alert-based. If no rule fires, no investigation.
Most organizations are here.
Level 1: Ad-hoc hunting
Analysts occasionally search logs when they read about a new
threat. No structured process. No documentation. No metrics.
Level 2: Procedural hunting
Regular hunting schedule (e.g., weekly hunt sessions).
Documented hypotheses and hunt playbooks.
Results tracked and shared with the SOC team.
Level 3: Hypothesis-driven hunting
Hunts driven by threat intelligence specific to the organization.
Hunters have deep knowledge of the environment's normal behavior.
New detections from hunts are automated into SIEM rules.
Metrics: hunts per month, findings per hunt, MTTD improvement.
Level 4: Automated + human hybrid
Statistical anomaly detection identifies candidates automatically.
Human hunters investigate the flagged anomalies.
Continuous hunting, not periodic.
Tight integration with red team exercises feeding hunt hypotheses.
Getting from Level 0 to Level 2 requires: a SIEM with historical
data, an analyst with attacker knowledge, and 4-8 hours per week
dedicated to hunting. That is it. No expensive tools, no dedicated
team -- just one analyst with curiosity and SIEM access.
The maturity model is useful because it gives you a realistic roadmap. Most organizations I have seen are at Level 0 or Level 1 -- they have a SIEM (probably), it generates alerts (definitely too many), and nobody proactively searches for threats that the rules do not cover. Getting to Level 2 is the critical jump, and it is entirely achievable for even a small security team. One analyst, 4-8 hours per week, a documented hunt playbook, and the discipline to record results. The key requirement is not technology (you already have the SIEM from episode 74) but mindset -- the shift from "I wait for alerts" to "I go looking for trouble."
Level 3 adds threat intelligence integration (from episode 52) to the hunting process. Instead of hunting for generic threats, you hunt for the specific techniques used by the threat actors who target your industry, your geography, your technology stack. A financial institution hunts for the TTPs used by FIN7 and Carbanak. A healthcare organization hunts for the techniques used by groups that target patient data. The intelligence narrows the search space and makes each hunt more likely to produce actionable results.
Level 4 is where the boundary between human hunting and automated detection starts to blur. Statistical anomaly detection runs continuously on your log data, surfacing the 50 most unusual events of the day -- the account that accessed 10x more files than its baseline, the DNS query to a domain with an unusually high Shannon entropy score, the workstation that connected to 3 countries it has never communicated with before. The human hunter reviews these anomalies and decides which are worth investigating. This is the hybrid approach that combines the speed and scale of automation with the creativity and judgment of a human analyst -- and it is where the detection capabilities we have been building since episode 71 all converge.
Hunt Name: Kerberoasting Detection
Hunt ID: HUNT-2026-042
Date: 2026-05-18
Hunter: [analyst name]
Hypothesis: "An attacker with a compromised domain account may
have Kerberoasted service accounts in the last 30 days."
Data Sources:
- Windows Security Event Log (Event 4769)
- Domain Controller logs
Query:
EventCode=4769 TicketEncryptionType=0x17
| where ServiceName != "krbtgt" AND NOT match(ServiceName, "\\$$")
| stats count by Account_Name, ServiceName, Client_Address
| where count > 5
Results:
[ ] No suspicious activity found
[x] Suspicious activity found:
Account jsmith requested 47 TGS tickets with RC4 encryption
targeting service accounts across 12 servers on May 15.
Actions Taken:
- Escalated to IR team (INC-2026-0142)
- Created SIEM alert rule for future detection (RULE-4769-RC4)
- Verified service account passwords were rotated
Lessons Learned:
- Service account svc_backup had an 8-char password (crackable)
- Migrated svc_backup to gMSA (128-char auto-rotated password)
- Added all service accounts to "deny interactive logon" GPO
This template is what separates professional threat hunting from casual log searching. The hypothesis is written BEFORE the search begins -- you know what you are looking for and why. The data sources and query are documented so another analyst can repeat the same hunt next month. The results section records what you found (including null results -- "no findings" is a valid and useful outcome that means this attack is not currently happening in your environment). And the actions taken section closes the loop: escalation for true positives, new SIEM rules for automated future detection, and remediation for the underlying vulnerabilities that made the attack possible.
The Kerberoasting hunt above is a good example because it directly connects to episode 33 (Active Directory attacks). The query searches for TGS requests with RC4 encryption type (0x17), which is the specific weakness that makes offline cracking feasible. The filter excludes machine accounts ($ suffix) and the krbtgt account because those generate legitimate RC4 requests. The result -- 47 TGS requests from a single account targeting 12 different service accounts -- is textbook Kerberoasting. No legitimate user requests that many service tickets in one session. And the remediation (migrating to gMSA with 128-character auto-rotated passwords) eliminates the vulnerability entirely, because a 128-character password cannot be cracked offline regardless of the encryption type. This is the complete cycle: hunt, find, respond, remediate, automate.
Every hunt you conduct should produce one of two outcomes: a new SIEM rule (if you found something) or a documented null result (if you did not). Both are valuable. The new rule improves your automated detection coverage. The null result means you can cross that hypothesis off the list and move to the next one. Over time, your detection coverage grows with every hunt, and your hunting program becomes more efficient because you are not re-investigating hypotheses you already covered. This systematic approach is also what makes threat hunting a legitimate business function rather than a hobby project -- you can measure coverage, track progress, and demonstrate value to management in concrete terms.
The transition from finding things in logs to preserving evidence for forensic analysis is a skill that quit some hunters overlook. When a hunt reveals a genuine compromise, the priority shifts from "find more indicators" to "preserve the evidence chain" -- because the same logs you are querying for hunting will become the evidence basis for an incident response investigation, and potentially for legal proceedings. Understanding how to collect, preserve, and analyze digital evidence without contaminating it is a distinct discipline that builds directly on the hunting skills we covered today.
AI is the most exciting development in threat hunting and the most dangerous source of false confidence. An AI that analyzes 10 billion log events and says "no threats detected" sounds authoritative. But if the attacker used a technique the AI was not trained on, "no threats detected" is wrong -- and the organization relaxes because the AI said it was safe.
AI can genuinely help with threat hunting. Statistical anomaly detection, behavioral baselines, automated clustering of similar events -- these are real capabilities that surface candidates for human investigation at a scale no analyst could match manually. An AI that identifies the 50 most anomalous events out of 10 billion is providing genuine value -- IF a human investigates those 50 events.
The danger is when AI replaces human judgment instead of augmenting it. An AI system that auto-closes alerts, auto-triages findings, and auto-reports "all clear" without human review creates blind spots that are invisible precisely because nobody is looking. Threat hunting requires human creativity -- the ability to think like an attacker and ask "what would I do if I were already inside this network?" AI cannot ask that question. AI can help answer it by searching the data efficiently, but the hypothesis itself must come from a human who understands the adversary's mindset. A threat hunter who blindly trusts an AI's "no threats found" verdict has stopped hunting and started hoping.
Exercise 1: Conduct a persistence hunt on your lab Windows VM. Without looking at what you installed during earlier episodes, search for: (a) non-default scheduled tasks, (b) non-default services, (c) registry run key entries, (d) WMI event subscriptions. Document every persistence mechanism you find and determine if it is legitimate or an artifact from earlier exercises. Write a hunt report using the template from this episode and save it to ~/lab-notes/persistence-hunt.md.
Exercise 2: Conduct a lateral movement hunt on your lab AD environment. Analyze authentication logs for the last 7 days and identify: (a) accounts that authenticated to machines they have never accessed before, (b) admin accounts used from non-admin workstations, (c) authentication events outside business hours. Write the SIEM queries you used and the results. Save to ~/lab-notes/lateral-movement-hunt.md.
Exercise 3: Design 5 hunt hypotheses based on the MITRE ATT&CK techniques most commonly used by a threat actor relevant to your industry (use the ATT&CK Navigator from episode 50). For each hypothesis: (a) state the hypothesis, (b) specify the data sources needed, (c) write the SIEM query, (d) define what a positive result looks like. Save your hunt plan to ~/lab-notes/hunt-hypotheses.md.
@scipio