One of the most common mistakes in early threat hunting programs is starting a hunt without a clear hypothesis. Analysts open a query interface, search for something vague (unusual network traffic, suspicious processes, anomalous logins) and end up either overwhelmed by results or unsure whether a clean search means the environment is clean or the search was too narrow.
Hypothesis-driven hunting solves this by treating each hunt like a testable proposition: if a specific attacker behavior is present in our environment, what specific evidence would it leave, and where would we find it? That framing turns hunting from a broad exploration exercise into a structured investigation with a defined scope, a clear data source, and a conclusion that can be documented either way.
What makes a good threat hunting hypothesis
A strong hypothesis has four components.
It names a specific threat behavior: Not "malware" in general, but a specific technique like credential dumping via LSASS memory access, or persistence through a scheduled task created by a non-administrator. Specificity is what makes the hypothesis testable. A vague hypothesis produces vague searches.
It identifies the data source where evidence of that behavior would appear: A hunt for LSASS credential dumping lives in endpoint telemetry — specifically process access events targeting lsass.exe. A hunt for unauthorized OAuth token grants lives in identity provider audit logs. Knowing the data source before starting ensures the hunt looks in the right place.
It defines what evidence of the technique looks like: The specific log fields, process relationships, or behavioral patterns that would indicate the technique is present. This is the detection logic: not "is lsass.exe running" (it always is), but "is a non-system process accessing lsass.exe memory in a way consistent with credential dumping."
It includes a baseline or filter: What normal looks like in this environment, so findings can be evaluated against context rather than flagged indiscriminately. Security tools legitimately access LSASS. Knowing which processes are expected to do so narrows the finding to unexpected ones.
Threat hunting hypothesis examples
Note on scope: these examples are Windows and on-premises weighted, with one identity-provider hunt. See the coverage note at the end for what is deliberately excluded.
The following examples are mapped to MITRE ATT&CK techniques. Each includes the technique, a falsifiable hypothesis with defined scope, the primary data source, the expected baseline, the key indicators to hunt for, the exit criteria, and the required output.
On falsifiability. A hunt hypothesis has to specify, in advance, the result that would make you abandon it. If there is no result that closes the hunt, what you are running is exploratory analysis, not a hunt. That is a legitimate activity, but it should not be scoped, staffed, or reported as a hunt. Every hypothesis below states an expected baseline and an exit condition precisely so that a negative result is a real answer rather than an absence of one.
Before running any of these: validate that the named data source actually covers the asset population in scope. Confirm agent check-in rates, log ingestion continuity over the hunt window, and field-level completeness for the specific fields you intend to pivot on. A hunt run against 60% telemetry coverage that returns zero hits has told you nothing. Record measured coverage as part of the output.
Bracketed values are environment-specific and must be filled in before the hunt is executed.
Credential dumping, LSASS memory access (T1003.001)
Hypothesis: One or more non-allowlisted processes on [Tier-0 and Tier-1 assets] opened a handle to lsass.exe with a GrantedAccess mask permitting memory read, consistent with credential extraction via Mimikatz, comsvcs.dll MiniDump, ProcDump, or a custom injection approach.
Scope and timeframe: [Tier-0 and Tier-1 Windows hosts, n=____]. Trailing [30] days.
Data source: Endpoint telemetry, specifically Sysmon Event ID 10 (ProcessAccess) or EDR equivalent process-handle events. Requires GrantedAccess and CallTrace fields to be populated.
Expected baseline: Near-zero after mask filtering and exclusions. Expect a small, stable residual from platform processes that legitimately touch lsass, including csrss.exe, wininit.exe, services.exe, [named EDR agent], WerFault.exe, Task Manager, and [named backup/DLP agents]. Most of these request masks that do not include memory read, so the mask filter removes them. Enumerate and pin your residual set before the hunt so that anything new stands out.
Hunt for: GrantedAccess masks granting PROCESS_VM_READ, commonly 0x1010, 0x1410, 0x143a, 0x1438, and 0x1fffff. Filter on the mask first, not on signature status or path, because the realistic access paths are signed and legitimate: rundll32 invoking comsvcs.dll MiniDump, ProcDump, WerFault, Task Manager, and living-off-the-land binaries generally. Pivot on CallTrace entries resolving to unbacked memory regions or to dbghelp.dll and dbgcore.dll from unexpected callers. Separately hunt handle-duplication patterns, where a process obtains an lsass handle indirectly rather than opening one, and process-clone approaches (PROCESS_CREATE_PROCESS on lsass) that evade naive ProcessAccess filtering.
Known blind spot: Sysmon registers a kernel object callback through ObRegisterCallbacks, so Event ID 10 fires on handle creation regardless of how the caller reached the kernel. Direct syscalls therefore do not suppress this event. They defeat userland inline hooking, which is an EDR concern rather than a Sysmon concern. PPL likewise does not suppress the event; it strips the requested access, so you generally still see the event with a reduced GrantedAccess value, which is itself worth hunting. What actually blinds this hunt is kernel callback removal via a vulnerable driver (BYOVD), Sysmon configurations that exclude lsass for noise reasons, and agent tampering. Confirm your Sysmon config does not filter lsass before trusting a zero result.
Exit criteria: Zero non-excluded hits across the scoped population with ≥[90]% confirmed Sysmon 10 coverage closes the hunt. Any hit escalates to IR. Coverage below [90]% closes the hunt as inconclusive and opens a visibility gap ticket instead.
Output: One of an incident ticket, a tuned allowlist of legitimate lsass-accessing processes committed to the detection rule, a documented Sysmon 10 coverage gap with affected host list, or a new detection rule keyed on GrantedAccess mask.
Persistence via scheduled task (T1053.005)
Hypothesis: An attacker established persistence on a host in [scope] by creating or modifying a scheduled task that executes a payload on a recurring schedule, using remote task creation, direct task-file or registry manipulation, or security descriptor removal to avoid normal creation logging and operator visibility.
Scope and timeframe: [All Windows servers and workstations, n=____]. Trailing [30] days.
Data source: Endpoint telemetry, specifically Sysmon Event ID 1 (process creation), Sysmon Event ID 11 (file create) scoped to C:\Windows\System32\Tasks, Sysmon Event ID 13 (registry value set) and Event ID 12 (registry key or value delete) scoped to the TaskCache hive, Sysmon Event IDs 17 and 18 (named pipe created and connected), and Windows Event IDs 4698 and 4702.
Expected baseline: [n] task creations per day from [named patch management, EDR deployment, and software distribution accounts]. Non-service-account creations expected at [n] per day.
Note on telemetry: Event IDs 4698 and 4702 require the Other Object Access Events subcategory to be enabled, which is off by default and absent in most environments. This is exactly why the Sysmon 11, 12, and 13 pivots matter. A task whose XML appears in C:\Windows\System32\Tasks\ or whose entry appears under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\ with no corresponding 4698 is a stronger signal than a normally-created task, not a weaker one. Verify which of these sources you actually have before scoping.
Hunt for: Security descriptor removal is the highest-value and most commonly omitted pivot. Deleting the SD value from HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree[taskname] hides the task from schtasks and the Task Scheduler UI while it continues to execute on schedule. This is the Tarrask technique associated with HAFNIUM. A Tree subkey with no SD value is close to a zero-false-positive indicator and should be hunted directly with Sysmon Event ID 12.
Also hunt task modification rather than creation only, using Event ID 4702, since repointing an existing legitimate task is quieter than adding a new one. Remote task creation surfaces as schtasks.exe with the /s flag, or as Sysmon 1 parent chains tracing to a network logon session, but command-line-free remote creation through the ATSvc interface will not. Hunt named pipe activity on \PIPE\atsvc with Sysmon 17 and 18 to catch that path. Round out with task XML files written directly into the Tasks directory with no matching 4698, direct TaskCache Index and Id value writes, tasks whose action points to an executable or script in a user-writable directory (%TEMP%, %APPDATA%, %PUBLIC%, C:\ProgramData subdirectories), and tasks with names typosquatting system tasks. Unprivileged users creating user-context tasks is high-volume and low-signal in most environments, so deprioritize it relative to the above.
Exit criteria: All non-baseline task creations and modifications triaged to a known owner closes the hunt, provided the TaskCache Tree enumeration returns no SD-less entries. Any unattributable task escalates. If neither 4698/4702 nor Sysmon 12/13 is available in scope, close as inconclusive and file the visibility gap.
Output: One of an incident ticket, an enrichment list of legitimate recurring task-creating accounts, a logging change request to enable Object Access auditing or extend Sysmon config to TaskCache, or a detection rule for task-file-without-4698 and for SD-less Tree keys.
Command-and-control beaconing (T1071.001, T1102)
Hypothesis: A host in [scope] is making outbound connections to attacker infrastructure at a machine-driven interval, distinguishable from legitimate automated traffic by destination rather than by periodicity alone. The dual mapping is deliberate. Prevailing tradecraft routes C2 through legitimate web services, which is T1102 rather than T1071.001, and a hunt program tracking coverage against ATT&CK should credit both.
Scope and timeframe: [All egress from user subnets and server VLANs]. Trailing [14] days minimum, since shorter windows cannot resolve long-interval beacons.
Data source: Network flow data, or proxy and firewall logs with connection timestamps, bytes in and out, and destination. The process-to-destination pivot described below cannot be satisfied from flow data alone and requires Sysmon Event ID 3 or EDR network telemetry. Scope that dependency explicitly or drop the pivot.
Expected baseline: The overwhelming majority of perfectly periodic outbound traffic in any enterprise is legitimate, including EDR and telemetry agents, OS and application update checkers, SaaS heartbeats, monitoring probes, NTP, and certificate revocation checks. Expect [thousands] of periodic destination pairs before filtering. Build and subtract a known-automated destination list first, or this hunt is unrunnable.
Hunt for: Do not use low variance as the detector. Every current C2 framework ships with configurable jitter, and a variance threshold will miss anything tuned above roughly 20%. Use jitter-tolerant math instead: median absolute deviation of inter-arrival times, autocorrelation of the connection time series, or FFT over the interval distribution to surface a dominant frequency underneath randomized spacing.
Set a minimum sample count, not just a time window. Frequency-domain methods need data points, and a beacon on a 24-hour interval produces 14 observations over a 14-day window, which will not support autocorrelation or FFT. Require [30] connections per destination pair before applying frequency analysis, and handle low-sample pairs on a separate track using first-seen and rarity logic rather than timing math. Layer on request-size regularity, since beacon check-ins cluster tightly in bytes-out even when timing does not, and on session-count-to-data-volume ratios.
Destination reputation is a weak filter against current tradecraft. Prevailing C2 rides legitimate high-reputation infrastructure including Slack, Discord, Telegram, Google Drive, OneDrive, GitHub, Pastebin-equivalents, and CDN-fronted or domain-fronted endpoints. Newly registered domains and DGA patterns remain worth checking but will not catch the dominant case. The higher-value pivots are a first-seen destination for the enterprise, a destination contacted by exactly one host, TLS fingerprint rarity, and a process-to-destination pairing that is anomalous for the host's role. Prefer JA4 over JA3 for the fingerprint pivot. JA3 has degraded substantially since Chrome began permuting ClientHello extension order, which makes JA3 values unstable across sessions for the same client.
Exit criteria: All periodic destination pairs surviving the automated-traffic subtraction are attributed to a named application or escalated. Zero unattributed pairs closes the hunt.
Output: One of an incident ticket, an expanded known-automated-destination allowlist, a new detection rule on the surviving beacon-scoring logic, or a documented egress logging gap.
Lateral movement via WMI (T1047)
Hypothesis: An attacker executed processes on remote hosts in [scope] using Windows Management Instrumentation, abusing legitimate administrative functionality from a source host that is not a sanctioned management system.
Scope and timeframe: [All Windows servers, n=____]. Trailing [30] days.
Data source: Endpoint telemetry, specifically Sysmon Event ID 1 or Windows Security Event ID 4688 for process creation on the target host, Sysmon Event ID 3 for network connections, and Microsoft-Windows-WMI-Activity/Operational Event ID 5857 (provider loaded) where enabled. Network flow data for RPC.
Correction on event IDs: Sysmon Event IDs 19, 20, and 21 are WmiEventFilter, WmiEventConsumer, and FilterToConsumerBinding. Those record WMI event subscription persistence, which is T1546.003, a different technique with a different hypothesis. The same applies to WMI-Activity Event IDs 5860 and 5861, which record temporary and permanent event consumer registration and belong to the persistence hunt rather than this one. Hunting any of these for remote execution returns nothing and produces a false all-clear. Remote WMI execution surfaces as process creation with WmiPrvSE.exe as the parent.
Expected baseline: WMI-parented process creation originating from [named management servers, SCCM infrastructure, monitoring platforms] at [n] per day. Expected from all other sources: 0.
Hunt for: Process creation events where the parent process is WmiPrvSE.exe and the initiating host is not on the sanctioned management list. Correlate with an inbound connection to TCP 135 followed by a session on an ephemeral high port from the same source. Prioritize WMI-spawned children that are anomalous for the target's role. PowerShell, cmd.exe, rundll32.exe, or regsvr32.exe spawned by WmiPrvSE on a database server or domain controller is a notable anomaly regardless of the source host. Also check for WMI execution where the target's own event log shows a Type 3 logon from the source immediately prior.
Adjacent hunt worth running separately: WMI event subscription persistence (T1546.003) via Sysmon 19, 20, and 21 and WMI-Activity 5860 and 5861, looking for CommandLineEventConsumer or ActiveScriptEventConsumer bindings, which are almost never legitimate outside of specific management tooling.
Exit criteria: All WmiPrvSE-parented executions attributed to a sanctioned source and a known administrative workflow closes the hunt. Any unattributed execution escalates.
Output: One of an incident ticket, a documented allowlist of legitimate WMI management sources, a detection rule on WmiPrvSE-parented process creation from non-management sources, or a WMI-Activity logging enablement request.
Unauthorized OAuth application grant (T1528)
Hypothesis: An attacker who obtained user credentials in [tenant] induced or performed a consent grant to a malicious or attacker-controlled OAuth application, obtaining access to cloud resources that survives password reset and MFA re-enrollment.
Scope and timeframe: [Entra ID / Okta / Google Workspace tenant, all users]. Trailing [90] days, since OAuth persistence is long-lived and short windows miss the initial grant.
Data source: Identity provider audit logs. Requires consent and application events, specifically the Entra ID operations Consent to application, Add delegated permission grant, Add app role assignment grant to user, and Add OAuth2PermissionGrant; the Okta System Log events under application.user_membership and app.oauth2.*; or the Google Workspace token audit log.
Retention warning: Entra ID retains audit and sign-in logs for 7 days on the free tier and 30 days with P1 or P2. A 90-day window is only executable if diagnostic settings already export these logs to Log Analytics, Sentinel, or equivalent storage. Confirm export is configured and backfilled before scoping this hunt, or reduce the window to your actual retention and document the resulting gap. Okta retains System Log data for 90 days and Google Workspace for 6 months, so both support the full window natively.
Expected baseline: [n] consent grants per week, of which [n] are to applications on the approved catalog.
Hunt for: Risky scope combinations rather than grant timing. Prioritize offline_access combined with Mail.Read or Mail.ReadWrite, Files.ReadWrite.All, full_access_as_user, Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, and Application.ReadWrite.All. The combination of AppRoleAssignment.ReadWrite.All with Application.ReadWrite.All deserves its own rule, because together they permit an application to grant itself additional permissions and escalate to Global Administrator without further consent.
Also hunt applications from unverified publishers, first-seen application IDs in the tenant, and grants where the consenting user's role does not plausibly require the requested scope. Cross-tenant prevalence, meaning application IDs seen in fewer than [5] tenants industry-wide, is a strong pivot but requires Microsoft Defender for Cloud Apps app governance or a comparable third-party data set. If you do not have that telemetry, substitute tenant-local first-seen and drop the prevalence criterion rather than leaving it unfilled.
Grant timing outside business hours is a weak signal on its own, since grants are noisy and often automated. Use it only as a secondary ranking factor.
Exit criteria: All grants in the window attributed to a named owner and a documented business purpose closes the hunt. Any unattributable grant escalates.
Output: One of an incident ticket, an approved-application catalog update, a conditional access or admin-consent-workflow policy change, or a detection rule on high-risk scope combinations.
Additional credentials on an existing service principal (T1098.001)
Hypothesis: An attacker added a client secret, certificate, or federated identity credential to an existing, already-approved service principal or application registration in [tenant], establishing authentication persistence that survives user password reset, MFA re-enrollment, token revocation, and most incident response.
This is separated from the consent-grant hunt above because it has a different data source, a different baseline, and materially different response implications. It is also the more frequently missed of the two, precisely because the application involved is legitimate and pre-approved, so nothing about the identity looks new.
Scope and timeframe: [All service principals and application registrations in tenant]. Trailing [90] days, subject to the same retention warning as above.
Data source: Identity provider audit logs. In Entra ID, the relevant operations are Add service principal credentials, Update application, and Update application – Certificates and secrets management. Federated identity credential additions appear as Update application and require inspection of the modified properties, not the operation name alone.
Expected baseline: Service principal credential additions expected at [n] per month from [named automation and certificate rotation processes]. Federated identity credential additions expected at [n] per quarter from [named CI/CD workload identity configuration]. Everything outside those two sets is investigated.
Hunt for: Any credential or certificate addition to a service principal that is not attributable to a documented rotation schedule. Prioritize additions to applications holding the high-privilege scopes listed in the previous hunt, additions performed by an account that does not normally administer applications, and additions where the credential lifetime is unusually long.
Federated identity credentials warrant their own rule. They allow an external issuer to obtain tokens for the service principal without any secret existing in the tenant, so a defender auditing only secrets and certificates will not see them. Check the issuer and subject values on every federated credential against the CI/CD systems you actually operate.
Exit criteria: Every credential and federated credential addition in the window is attributed to a named owner and a documented rotation or workload-identity purpose. Any unattributable addition escalates immediately given the persistence implications.
Output: One of an incident ticket, a documented inventory of service principals with their legitimate credential owners and rotation schedules, a policy change restricting who may add application credentials, or a detection rule on service principal credential and federated credential addition.
Data staging before exfiltration (T1074, T1560)
Hypothesis: An attacker is aggregating data from multiple sources into a staging location, whether a local directory, an archive file, or attacker-controlled cloud storage, in [scope] prior to exfiltration.
Scope and timeframe: [File servers, endpoints with access to sensitive shares, and monitored SaaS storage]. Trailing [30] days.
Data source: Endpoint telemetry (Sysmon Event ID 11 file create, Sysmon Event ID 1 for tooling execution, EDR file events), DLP, and cloud audit logs (SharePoint, OneDrive, Google Drive, S3 access logs).
Expected baseline: [n] archive creation events per day across scope from [named backup and packaging tooling]. Bulk file access above [n] files/hour per user expected only from [named accounts/systems]. Exfiltration utility execution on servers: 0.
Hunt for: Archive creation is the highest-signal indicator and is missing from most staging hunts. Look for creation of .rar, .7z, .zip, .cab, or .tar files, especially password-protected archives, especially by rar.exe, 7z.exe, or WinRAR variants renamed to blend in, and especially in %TEMP%, %APPDATA%, C:\ProgramData, or the recycle bin path. Archive files unusually large relative to the creating user's history are worth ranking up.
Extension-based matching alone will miss the common case where both the tool and its output are renamed. Where your tooling supports content inspection, hunt on file magic bytes instead, checking for the Rar! signature, PK for zip, and 7z for 7-Zip, regardless of the extension on disk.
Add execution of transfer utilities on hosts that have no business running them. Rclone, MEGAsync, FileZilla, and WinSCP appearing on a file server or domain controller is one of the highest-signal staging-to-exfiltration indicators in ransomware intrusions, and it frequently precedes the archive step rather than following it. Rclone in particular is often renamed, so pair the filename hunt with a command-line hunt for its characteristic flags.
Also hunt unusual volumes of copy and move operations converging on a single directory, weighted toward document types matching sensitive data categories such as finance, HR, source code, or customer records. Look for accounts accessing file shares outside their normal working set or normal hours, and for cloud-native staging that never touches an endpoint file system, including bulk downloads or server-side copies within SharePoint and Drive, and writes to newly created or externally shared buckets and folders. Cross-reference with outbound transfer volume in the [72] hours following the staging activity.
Exit criteria: All bulk-access events, archive-creation events, and transfer-utility executions attributed to a known business process closes the hunt. Any unattributed staging pattern escalates.
Output: One of an incident ticket, a baseline of legitimate bulk-access accounts and archive tooling, a DLP policy tuning change, or a detection rule on password-protected archive creation in user-writable paths and on transfer-utility execution by host role.
Discovery via enumeration (T1087, T1018)
Hypothesis: An attacker with initial access in [scope] executed a burst of system, account, or domain discovery activity, which is typical early post-exploitation behavior, via command-line tooling, LDAP queries, ADWS queries, or in-process API calls.
Scope and timeframe: [All Windows servers and workstations, plus all domain controllers]. Trailing [30] days.
Data source: Endpoint telemetry (process execution with command line arguments), domain controller directory service logs (Event ID 1644), LDAP query logging, and network telemetry for TCP 9389.
Note on 1644: This event requires two separate configuration changes, not one. Set the Field Engineering diagnostic level to 5 under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics, and then tune down Search Time Threshold (msecs), Expensive Search Results Threshold, and Inefficient Search Results Threshold under the NTDS\Parameters key. With the diagnostic level raised but the thresholds left at their defaults, you will log almost nothing and conclude incorrectly that the telemetry is in place. Validate with a known test query before relying on it, and be aware that aggressive threshold tuning is expensive on busy domain controllers.
Expected baseline: Discovery command bursts expected from [named admin accounts and jump hosts] at [n] per week. Expected from server-role hosts and non-admin workstations: 0. ADWS connections expected only from [named management hosts running the AD PowerShell module].
Hunt for: Rapid sequential execution of discovery commands such as net user, net group, net localgroup, whoami, ipconfig, nltest, systeminfo, arp, quser, and tasklist from a single process or shell session inside a short window. A single net user from an analyst workstation is normal; five discovery commands within 90 seconds on a server is not. Threshold on burst density and host role, not on individual command presence.
Known blind spot, and the reason this hunt alone is insufficient: mature actors have largely moved off command-line enumeration. SharpHound, direct LDAP and ADSI queries, .NET reflection, and in-process BOF execution perform the same discovery without spawning a process, producing no command line to hunt. Pair this hunt with LDAP-side detection covering anomalous query volume from a single source, queries retrieving large object sets, and the characteristic filter patterns used by BloodHound collectors.
LDAP coverage alone still leaves a hole. Active Directory Web Services on TCP 9389 exposes the same directory data over SOAP, and collection through that path generates no LDAP query logs at all. SOAPHound and the Microsoft AD PowerShell module both use it. Add a third leg to this hunt covering ADWS connections from hosts that are not on the sanctioned management list, using network telemetry or Sysmon Event ID 3 scoped to port 9389, since that is the pivot most environments are missing entirely.
Exit criteria: All discovery bursts attributed to a named administrator or automated inventory process closes the command-line leg. The LDAP leg closes when anomalous query sources are attributed. The ADWS leg closes when all 9389 sources are on the sanctioned management list. Absent LDAP logging or 9389 visibility, close as partial and file the corresponding gap.
Output: One of an incident ticket, a baseline of legitimate discovery-command and ADWS sources, an LDAP diagnostic logging enablement request, or a detection rule on burst density scoped by host role.
Note on coverage: this set is Windows and on-premises weighted, with one identity-provider pair. It does not cover ESXi and hypervisor targeting, Kubernetes and container escape, Linux or macOS, CI/CD and supply chain, SaaS-to-SaaS lateral movement, or email-based initial access. It also demonstrates only technique-driven hunting. Intel-driven, crown-jewel-driven, and anomaly-driven hunts follow different structures and are worth documenting separately.
Building a threat hunting hypothesis program
These examples share a structural pattern that can be applied to any technique in the MITRE ATT&CK framework: technique name, hypothesis statement, data source, indicators to hunt for, and baseline context to filter against.
The practical approach for building a hypothesis program is to start with coverage gaps. Run a coverage assessment against MITRE ATT&CK to identify which techniques you currently have detection coverage for and which ones you're flying blind on. Techniques with no existing detection rule and meaningful attacker usage in the wild are the highest-priority candidates for hunting hypotheses.
AI-assisted threat hunting platforms can automate parts of this process — surfacing hypothesis suggestions based on ATT&CK coverage analysis and recent threat intelligence, generating the underlying queries, and flagging anomalies that match the hypothesis criteria without requiring analysts to write every search from scratch. The hypothesis library still comes from human judgment about what's most relevant to the environment; the tooling accelerates the execution.
This shift in workflow is sometimes described as vibe hunting — a model where the analyst provides the hypothesis and the AI handles the mechanical execution: generating queries, stitching telemetry across sources, and surfacing findings without requiring the analyst to write every search from scratch. The practical effect is that hypothesis-driven hunting becomes faster to execute and accessible to a wider range of analysts, not just those with deep query expertise in every data source.
Completed hunts should be documented regardless of outcome. A hunt that returns no findings is still valuable if it was designed well — it demonstrates coverage and provides evidence for compliance and audit purposes that specific techniques were actively looked for. Detection engineering supports this loop, converting positive hunt findings into formal detection rules so the coverage becomes persistent rather than requiring re-hunting on a schedule.
According to IBM's 2026 Cost of a Data Breach Report, organizations with strong threat detection capabilities — those that found breaches themselves rather than through external notification — had substantially lower breach costs. Hypothesis-driven hunting is one of the most direct ways to build that internal detection capability systematically, technique by technique.
