What is Threat Hunting?

An alert-driven SOC looks at what a rule already flagged. A hunt starts from the opposite assumption: an attacker may already be inside, using techniques no rule covers, and the only way to find out is to go and look. NIST SP 800-53 writes this into control RA-10 (Threat Hunting) as a capability to search for indicators of compromise and to "detect, track, and disrupt threats that evade existing controls". The guidance attached to the control calls hunting an active means of defense, set against firewalls, intrusion detection and prevention, sandboxes and SIEM, and gives it an objective: track and disrupt adversaries as early as possible in the attack sequence, and measurably improve the speed and accuracy of the response.

A hunt ends in one of three ways, and all three count:

• Evidence of an attacker. The hunt becomes an incident, and the queries go to incident response with the timeline.
• A null result. Nothing in the data you checked. Write down the hypothesis, the time range and the hosts covered, so the next hunter knows what was ruled out and what was never looked at.
• A visibility gap. The data that would answer the question does not exist: a log source nobody collects, retention that is too short. Closing the gap is the result.

Whichever it is, the hunt should leave something permanent behind: a detection rule, a hardening change, or a written reason why neither is possible.

Threat hunting frameworks and hunt types

Most programs borrow their structure from a published framework. The Sqrrl Threat Hunting Reference Model appeared in 2015, and TaHiTI, from the Dutch Payments Association, in 2018. A more recent one is PEAK (Prepare, Execute, and Act with Knowledge), published by Splunk and written by David Bianco, who helped create the Sqrrl model, with Ryan Fetterman. Every PEAK hunt runs through three phases: prepare (pick a topic, research it, plan the data), execute (query and analyze), act (document, automate, communicate). PEAK names three hunt types:

A fourth kind of work often gets called hunting too: sweeping the logs for indicators from a fresh report (hashes, domains, IPs). It is the "search for indicators of compromise" half of RA-10. It is quick and worth doing, but it only finds what someone else has already seen.

Inside a hunt, four data techniques do most of the work:

• Searching: filter for a specific value or pattern, such as one logon type for one class of account.
• Grouping: collect the events that share a set of attributes, for example everything one source IP did in an hour.
• Clustering: let statistics put similar events together, then look at the small clusters left over.
• Stack counting: count how often each combination of values appears and read the bottom of the list first. The hunt below found its lead that way.

A worked hunt: service accounts that log on like people

Simulated example generated by SOCSimulator Research. Hosts, accounts, addresses and times are invented; event IDs, field names and logon type values are Microsoft's.

Hypothesis. An attacker who gets a service account's password (by cracking a Kerberoasted ticket, reading it from a script, or finding it reused) will at some point log on with it interactively or over RDP. The service itself never does: it logs on as type 5 (Service) or type 3 (Network). MITRE ATT&CK v20 lists the behavior as an analytic for Valid Accounts (T1078): "interactive and remote logins by service accounts or users at unusual times, with unexpected child process activity". In v20, T1078 sits under four tactics: Initial Access, Persistence, Privilege Escalation and Stealth.

Data. Event 4624 (an account was successfully logged on) from the Security log of every member server and workstation. The event is written on the machine being logged on to, so domain controller logs alone miss most of it, and it only appears with the Audit Logon subcategory enabled. Microsoft's monitoring guidance for 4624 puts service accounts on its list of high-value accounts, and suggests watching for a mismatch between the logon type and the account that uses it. The logon types that matter here:

Types 3 and 5 are a service account's normal life. Types 2, 10 and 11 are the hunt. Service accounts in this environment follow a svc_ naming convention; if yours don't, swap the name filter for a list exported from Active Directory (accounts with a service principal name are a good start).

Query 1: stack count in Microsoft Sentinel (KQL). Written against the documented SecurityEvent schema; SOCSimulator has not run it against a live workspace.

SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4624 and LogonType in (2, 10, 11)
| where TargetUserName startswith "svc_"
| summarize Logons = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            Sources = make_set(IpAddress, 10), Elevated = make_set(ElevatedToken, 2)
          by TargetUserName, Computer, LogonType
| sort by Logons asc

The same in Splunk (SPL). The field names follow Splunk's own detection for RDP logons (Logon_Type, user, dest, src). Point the index at wherever your Security log lands; if it is ingested as XML, the logon type field may be LogonType instead.

index=wineventlog EventCode=4624 Logon_Type IN (2, 10, 11) user="svc_*"
| stats count AS logons min(_time) AS first_seen max(_time) AS last_seen values(src) AS sources BY user, dest, Logon_Type
| sort logons

The result, rarest first:

TargetUserName  Computer               LogonType  Logons  FirstSeen         Sources        Elevated
svc_backup      FS02.corp.example      10         1       2026-10-11 02:14  10.10.40.77    Yes
svc_scan        WS-0143.corp.example   2          3       2026-09-29 16:02  127.0.0.1      Yes
svc_sqlagent    SQL01.corp.example     2          41      2026-09-17 09:31  127.0.0.1      Yes
svc_backup      BKP01.corp.example     10         58      2026-09-16 08:05  10.10.5.20     Yes

Reading the stack. Every row breaks policy. Only one looks like an attacker.

• svc_backup on BKP01: 58 RDP logons from 10.10.5.20. That address is the admin jump host, and the backup team signs in with the service account to troubleshoot jobs. No intrusion here; the finding is a shared password nobody rotates, and it goes to the identity team as a ticket.
• svc_sqlagent on the SQL01 console: 41 logons, every one inside a maintenance window on the change calendar. The same finding, for the database team.
• svc_scan on WS-0143: three logons in one afternoon. The service desk ticket shows a technician installing the scanner agent by hand with the scanner's credentials. Closed as benign, with a note on the ticket.
• svc_backup on FS02: once, at 02:14 on a Sunday, over RDP from 10.10.40.77, a workstation on the finance floor. No ticket, not the jump host, and an elevated session on a file server the backup account normally reaches only over the network. This is the lead.

The questions that separated the four:

Query 2: what did the session do? Event 4688 (a new process has been created) carries the Logon ID of the session that started the process, the same value 4624 records for the new logon, so the two join on it. The command line is there only if the Include command line in process creation events policy is on; by default the field is empty.

let session = SecurityEvent
| where TimeGenerated > ago(30d) and EventID == 4624 and LogonType in (2, 10, 11)
| where TargetUserName =~ "svc_backup" and Computer =~ "FS02.corp.example"
| project Computer, SubjectLogonId = TargetLogonId, LogonTime = TimeGenerated, SessionIp = IpAddress;
SecurityEvent
| where TimeGenerated > ago(30d) and EventID == 4688
| join kind=inner session on Computer, SubjectLogonId
| project TimeGenerated, Computer, LogonTime, SessionIp, ParentProcessName, NewProcessName, CommandLine
| sort by TimeGenerated asc

02:14:37  4624  svc_backup  LogonType 10  IpAddress 10.10.40.77  ElevatedToken Yes  TargetLogonId 0x8d3a41f
02:15:02  4688  explorer.exe -> cmd.exe
02:15:09  4688  cmd.exe -> whoami.exe      whoami /groups
02:15:31  4688  cmd.exe -> net.exe         net group "Domain Admins" /domain
02:16:04  4688  cmd.exe -> nltest.exe      nltest /dclist:corp.example
02:18:47  4688  cmd.exe -> robocopy.exe    robocopy D:\Shares\Finance C:\ProgramData\fsync /E

The session lists the domain's admins and controllers, then copies the finance share into a folder under C:\ProgramData. A backup job needs none of that.

Pivot: where did the password come from? On the domain controllers, look for event 4769 service ticket requests for svc_backup's service principal name with encryption type 0x17 (RC4) in the days before the logon. ATT&CK's detection for Kerberoasting (T1558.003) looks for exactly that, and an RC4 request from 10.10.40.77 would close the loop. Then check what else 10.10.40.77 logged on to, which gives incident response its scope.

Outcome. The lead went to incident response with both queries, the timeline and the open pivot. The hunt itself closed with two permanent changes.

A detection rule. The hunt query becomes a scheduled rule, scoped by what the stack showed to be legitimate. Console logons (type 2, 127.0.0.1) still alert on purpose: after this hunt, nobody should be signing in at a service account's console.

let JumpHosts = dynamic(["10.10.5.20", "10.10.5.21"]);
SecurityEvent
| where EventID == 4624 and LogonType in (2, 10, 11)
| where TargetUserName startswith "svc_"
| where not(IpAddress in (JumpHosts))
| project TimeGenerated, Computer, TargetUserName, LogonType, IpAddress, WorkstationName, ElevatedToken

A hardening change. Microsoft's guidance is to assign the Deny log on through Remote Desktop Services user right to all service accounts. Its service account guidance lists "deny sign-in locally or interactive sign-in" as a mitigation and recommends group managed service accounts (gMSA) over user accounts where the service supports them. With the deny rights in place, a type 10 logon by a service account means someone changed the policy, which deserves an alert of its own.

Had the stack held only the jump host rows, the hunt would have closed as a null result: the hypothesis, 30 days of data, the hosts that forward their Security log and, just as useful, the ones that don't.

Which platform runs these queries matters less than collecting 4624 from every host. For a comparison of platforms, see threat hunting tools.

Hunting, incident response and detection engineering

Incident response reacts to a confirmed or suspected incident; a hunt looks for incidents nobody has flagged. Alert triage judges what an automated rule found; a hunt builds and tests its own question. Detection engineering is where a successful hunt ends up: the rule above is a detection engineer's work product, written from what the hunt learned about normal behavior in one environment.

A hunting program needs:

• Telemetry with retention. You cannot hunt in data that was never collected or was deleted after a week. The hunt above depends on Security logs from every workstation, and many environments don't forward them.
• Analysts who know the environment. A rare row in a stack means nothing to someone who doesn't know which address is the jump host.
• Fast query tooling, so a pivot takes seconds rather than minutes.
• Time protected from the alert queue, for work whose most common honest result is "nothing found".

In larger SOCs hunting is a dedicated role. The threat hunter career path puts the usual starting point at three to five years of security operations experience and covers the skills and pay range.