The first hour of a credential compromise: a repeatable IR playbook

The alert fires at 4:47 p.m. on a Friday: a sign-in from an unfamiliar location, or a user reporting an MFA prompt they didn't initiate, or an impossible-travel flag from Identity Protection. An account is — or might be — compromised. What you do in the next sixty minutes decides how the rest of the investigation goes, and whether you ever get a clean answer to the four questions a CEO will ask afterwards: what happened, how did they get in, what did they touch, and was any data taken?

The hard part of the first hour isn't knowing what to do. It's doing it consistently, under pressure, without destroying the evidence that answers those questions later. This guide is a repeatable, minute-by-minute playbook for the first hour of a credential compromise — grounded in the NIST SP 800-61 incident-handling lifecycle and the SANS PICERL model, and written around the Microsoft telemetry most organisations actually have.

Why a playbook beats improvising

Every experienced responder has run an investigation where, three days in, they realise they revoked the attacker's sessions before exporting the sign-in logs — and now the token timestamps that would have proven persistence are gone. Or that nobody captured the mailbox rules before the user “helpfully” deleted the suspicious one. The first hour is where these mistakes happen, because it's the hour with the most adrenaline and the least structure.

A playbook converts judgement calls you'd otherwise make at 4:47 p.m. on a Friday into decisions you already made on a calm afternoon. The four phases below map onto SANS PICERL — Identification, Containment, and the start of Eradication — but the real value is the ordering: preserve before you change, collect what expires first, and gate every destructive action.

Minute 0–15: Triage without destroying evidence

Resist the urge to immediately reset the password and block the account. That instinct is right eventually, but doing it first overwrites timestamps, invalidates the tokens you need to fingerprint, and tips off an attacker who may have additional footholds. Three triage decisions come first:

1. Confirmed or suspected? A user who clicked a phishing link but never entered credentials is a different incident from a successful sign-in from a new country. Don't containment-hammer a maybe.
2. What's the blast radius? A standard user, a privileged role, and a service account each demand different handling. A compromised Global Administrator escalates to a tenant-wide incident; a compromised contractor account may not.
3. Snapshot state before you touch anything. Note the current time, the account's current group and role memberships, its registered MFA methods, and any active sessions — before you change a single setting. This is your “time zero” baseline.

The output of this phase is a one-line scope statement — “suspected compromise of a standard user, M365 + Entra ID, single sign-in anomaly” — and a decision to proceed. Write it down. It anchors everything after.

Minute 15–30: Collect the telemetry that expires first

Not all evidence ages at the same rate. Sign-in logs in Entra ID are retained for 30 days on the free tier; endpoint telemetry rolls off faster under volume; and the moment you revoke sessions, the live token state is gone forever. Collect in order of volatility.

Sign-in and authentication evidence. In the Entra admin centre under Monitoring & health > Sign-in logs, or via Log Analytics if you stream them, pull the user's interactive and non-interactive sign-ins for the last 30 days. The query that matters:

SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName == "victim@contoso.com"
| project TimeGenerated, IPAddress, Location, AppDisplayName,
          ClientAppUsed, ResultType, RiskLevelDuringSignIn,
          AuthenticationRequirement, DeviceDetail
| order by TimeGenerated desc

You're looking for the pivot point: the first successful sign-in from the anomalous IP or device, whether MFA was satisfied (and how — a push approved at 3 a.m. is itself a finding), and anyClientAppUsed values that bypass modern auth (legacy IMAP/POP is a classic credential-stuffing tell). Cross-referenceAADNonInteractiveUserSignInLogs for token replay.

Persistence evidence — the part attackers count on you missing. A credential compromise becomes a real incident when the attacker establishes persistence. Two places to look immediately:

• OAuth consent grants. In Enterprise applications, check for app consents the user granted recently, especially apps requesting Mail.Read oroffline_access. A malicious OAuth grant survives a password reset — this is the single most-missed persistence mechanism.
• Mailbox rules and forwarding. Pull the Unified Audit Log for New-InboxRule, Set-InboxRule, andSet-Mailbox (forwarding) operations. Inbox rules that move security alerts to RSS Feeds or delete “password” emails are the BEC fingerprint.

Endpoint evidence. If the identity is tied to a managed device, run a Defender for Endpoint advanced-hunting query againstDeviceLogonEvents and DeviceProcessEvents for the same window. A credential compromise that touched an endpoint — token theft via an infostealer, for example — leaves process-tree evidence that the identity logs alone won't show.

Minute 30–45: Build the timeline and pivot across entities

Now you have raw evidence from three sources on three different clocks. The investigation question — “what happened, in what order?” — only gets answered when you merge them into one timeline normalised to UTC. Stitch the sign-in events, the OAuth grant, the inbox-rule creation, and any endpoint process events into a single chronological view.

Then pivot. Attackers move across users, hosts, and IPs, so your investigation should too. Start from the compromised identity, jump to the device it authenticated from, then to the source IP, then to any other account that touched that same IP or device. This is how a single-account compromise reveals itself as a beachhead for lateral movement — and it's the step under-resourced teams skip because pivoting by hand across consoles takes an afternoon they don't have. For the Active Directory side of that movement, the AD ransomware-precursor playbook covers the lateral-movement sequences to chase next.

Minute 45–60: Contain with an approval gate and an audit trail

Only now — with evidence preserved and a timeline built — do you contain. The first-hour containment set for a confirmed credential compromise:

1. Revoke sessions and refresh tokens (Revoke-MgUserSignInSession). This invalidates the attacker's refresh tokens; note that already-issued access tokens can remain valid for up to roughly an hour, so this is necessary but not instant.
2. Reset the password and require re-registration of MFA — attackers frequently register their own MFA method as persistence, so resetting the password without re-checking MFA methods leaves the door open.
3. Remove the malicious OAuth grants and inbox rules you found in the previous phase. A password reset alone does not touch these.
4. For a privileged account, also pull standing role assignments and review what was changed during the compromise window.

Every one of these actions is destructive and consequential. Each should run through an explicit approval step and land in an audit trail that records who did what, when, and why — both because you may need to justify the containment later, and because an account lockout of the wrong identity during business hours is its own incident. Contain fast, but contain accountably.

The handoff: from first hour to defensible case

At the sixty-minute mark you should be able to state, in one paragraph: how the attacker got in, what persistence they established, what you contained, and what evidence supports each claim. That paragraph is the seed of your incident narrative and, ultimately, the stakeholder report. The discipline that makes it defensible — hashing each artefact, logging every access — is covered in the chain-of-custody guide, and the identity-specific deep dive lives in how to investigate a compromised Entra ID account.

Running this consistently with tooling

A single responder can execute this playbook by hand for one account. The problem is consistency: the first hour is exactly when fatigue, pressure, and context-switching cause the misses — the skipped pivot, the un-exported log, the un-gated containment action.

This is the argument for encoding the playbook in a tool rather than a runbook PDF. In CICADA IR, attaching the Credential Compromise playbook to a case runs the opening moves for you: it collects the sign-in logs, OAuth grants, mailbox audit data, and endpoint signals described above into one investigation, with a chain of custody recorded from the first action. The timeline is merged and normalised to UTC for you, so the minute 30–45 work becomes a review step instead of an afternoon of console-hopping. Containment runs behind the same approval gate and audit trail this guide argues for. None of it replaces your judgement — it removes the steps where tired people drop evidence.

CICADA IR is self-hosted, so wherever you run this — by hand or with the playbook — the case data never leaves your environment.

See Getting Started to set it up, or the companion guides on M365 BEC investigation and PCAP-driven IR for adjacent workflows.