Playbook: Running an Identity Threat Hunt

An identity hunt looks for misuse of access that is technically valid. The attacker has a password, a session cookie, an OAuth token or an admin role. No exploit fires. No file lands on disk. Every single event looks normal. The signal is in the pattern: the wrong device, the wrong sequence, the wrong identity doing a rare thing.

This playbook gives you a repeatable way to run that hunt, decide when a lead becomes an incident, and turn what you learn into detections. It assumes a cloud identity provider (Microsoft Entra ID, Okta or similar), on-premises Active Directory in a hybrid setup, and a SIEM or data lake that holds the logs. Adjust the field names to your platform.

When to run this hunt

• After a public identity-led campaign or advisory that matches your technology stack.

• After an incident where the initial access was a credential, a session or an app grant, to find what else the same actor touched.

• On a fixed cadence, because identity abuse is the main way attackers stay quiet once they are in.

• Before a major identity change, such as a tenant merge or an IdP migration, to learn what normal looks like first.

If you already have a suspect account or app, stop and investigate it instead. A hunt looks for unknown compromise. An investigation scopes a known one.

Step 1. Check that you can see the identity plane

Most failed identity hunts fail here. Before you pick a hypothesis, confirm the data exists, is searchable and goes back far enough to matter.

Also write down your retention for each source. Confirm it for your license tier rather than assuming. If you only hold a short window, the hunt can only prove a short window, and the report must say so.

Finally, build an identity inventory: privileged human accounts, break-glass accounts, service accounts, app registrations and service principals with their owners. Without it you cannot tell a rare event from a rare event on an account that matters.

Step 2. Pick one hypothesis and bound it

A hunt without a hypothesis becomes browsing. Pick one statement you can prove or disprove with the data you checked in Step 1. Choose it from current threat intelligence, from your own exposure (for example, admins with no phishing-resistant authentication), or from the last incident.

Two hunt styles work well here. A hypothesis-driven hunt tests a specific theory about attacker behavior. A baseline hunt defines normal for an identity class and looks for departures. The PEAK framework describes both, and a third style that uses models. For identity, run hypothesis hunts first. Use baseline hunts when you have no theory, or when you need the baseline to support the next hypothesis.

Six hypotheses cover most of the ground. Each maps to a technique in MITRE ATT&CK so the result can feed detection work later.

Write the hypothesis in one sentence, name the data it needs, set the time window and agree what “done” looks like. A good stopping rule is: every account in scope has been checked against the pattern, or the time box has run out and the gap is recorded.

Step 3. Execute: narrow, pivot, then read the timeline

1. Scope the population. Start with privileged accounts, accounts with access to crown-jewel systems and workload identities with directory or mail permissions. Widen later.

2. Find the rare. Count by identity, device, network and user agent. Sort by least frequent. Rare is a starting point, not a finding.

3. Pivot on the identity, not the event. For each rare item, pull that identity’s full timeline across sign-ins, audit events, device and MFA changes and resource access. Read it in order.

4. Test the benign explanation first. Travel, a new laptop, a contractor, a scheduled change. Ask the owner or check the change record. Most leads end here, and that is the correct result.

5. Look for the second act. A sign-in alone is weak. A sign-in followed by an MFA change, a role assignment or mailbox rule is a story.

6. Keep notes as you go. Queries run, fields used, accounts excluded and why. You will need them for the hunt record and for the detection you write.

Do not use IP addresses as the main pivot. Attackers rotate through residential and cloud proxies, and Microsoft’s own guidance on a nation-state intrusion notes that IP-based indicators alone were not enough. Pivot on behavior: sequence, device, session and privilege change.

Step 4. Decide what each lead becomes

If a lead involves an OAuth app or a third-party integration, switch from hunting to a scoped investigation. The questions change from “is there something here?” to “what did it reach, and how do we cut it off?”

Step 5. Act on what you learned

A hunt that ends with a slide has not finished. Each hunt should leave behind at least one of these.

• A detection. If the pattern is precise enough to alert on, hand it to detection engineering with the query, the benign exclusions you found and sample events.

• A logging fix. Missing fields, uncollected tables and short retention are findings. Raise them as such.

• A hardening ticket. Standing admin access, accounts outside conditional access, or end-user app consent left open are risk reductions the hunt exposed.

• An updated baseline. The “normal” you documented is an asset. Store it.

Keep one hunt record per hunt: hypothesis, data sources and time window, queries, results, benign causes found, leads escalated, detections or fixes raised and the date to re-run. This is what makes the next hunt faster and what proves coverage to leadership.

Where identity hunts go wrong

• Hunting what the data cannot show. Check collection first. A clean result on a log you do not ingest proves nothing.

• Treating a new country as a finding. Travel, VPNs and mobile networks create noise. Require a second signal.

• Ignoring workload identities. Service principals and tokens often hold broader access than any person and are watched less.

• Stopping at the sign-in. Attackers authenticate, then change something. Follow the identity forward.

• Letting the hunter also be the only detection engineer. Keep the hand-off explicit, or the lesson stays in one person’s head.

Use this to strengthen proactive threat hunting: choose one hypothesis from the table, run it against your privileged accounts first, and record the result whether it finds something or not.

Sources

• PEAK Threat Hunting Framework (Splunk SURGe) — hypothesis-driven, baseline and model-assisted hunt types; Prepare, Execute, Act phases.

• MITRE ATT&CK: Web Session Cookie (T1550.004)

• MITRE ATT&CK: Multi-Factor Authentication (T1556.006)

• MITRE ATT&CK: Device Registration (T1098.005)

• MITRE ATT&CK: Multi-Factor Authentication Request Generation (T1621)

• MITRE ATT&CK: Additional Cloud Credentials (T1098.001)

• MITRE ATT&CK: Additional Cloud Roles (T1098.003)

• MITRE ATT&CK: Kerberoasting (T1558.003) — RC4 ticket encryption and request-volume detection guidance.

• MITRE ATT&CK: DCSync (T1003.006)

• Microsoft Security Blog: Midnight Blizzard guidance for responders on nation-state attack — behavioral detection over IP indicators.