← All cheat sheets

ACCOUNT COMPROMISE TRIAGE

Plain-text reference · 5 KB. Read it, search it (Ctrl-F) or print it.

SOC playbook for a suspected compromised user account (cloud identity +
on-prem). Goal: confirm, contain the identity, scope what the attacker did,
and recover access safely -- in the right ORDER so you don't lock out
responders or destroy evidence.

SIGNALS THAT OPEN THIS CASE#

- Impossible travel / logins from new country, ASN, or anonymizing IP.
- MFA fatigue (many push prompts) or a sudden MFA method change.
- Mass/unusual email rules (auto-forward, delete, move to RSS/Archive).
- Mailbox accessed from a new client/IP; large mailbox export/search.
- Risky sign-in flagged by the IdP; legacy-auth / token replay.
- New OAuth app consent granted; new device registered/enrolled.
- Password/MFA reset the user did not perform; self-service recovery abuse.

CONTAIN THE IDENTITY FIRST (order matters)#

1. [ ] REVOKE active sessions / refresh tokens. A password reset ALONE does
       not kill existing tokens -- an attacker with a valid refresh token
       keeps access until tokens are revoked. Revoke THEN reset.
       (Entra ID: "Revoke sessions"; Google: sign out all sessions.)
2. [ ] RESET the password (force change at next logon).
3. [ ] Re-establish / re-enroll MFA from a trusted channel; remove any
       attacker-added MFA methods and app passwords.
4. [ ] Review and revoke suspicious OAuth app grants / enterprise app
       consents and newly registered devices.
5. [ ] If high privilege (admin), also rotate anything that account could
       reach: shared secrets, service-account creds it manages, API keys.
Do this BEFORE broad notification so the attacker is not tipped mid-scope,
but keep evidence (see below) as you go.

EVIDENCE / SCOPING -- CLOUD (Entra ID / M365 example)#

[ ] Sign-in logs: successful + failed, IPs, locations, device, client app,
    conditional-access result, MFA status, legacy auth. Note first malicious
    sign-in time (UTC) and source.
[ ] Audit logs: password/MFA changes, OAuth consents, device registrations,
    role/group additions, directory changes made by the account.
[ ] Unified Audit Log / mailbox audit: searches, exports, item access,
    "New-InboxRule" / "Set-InboxRule" / "Set-Mailbox ForwardingSMTPAddress".
[ ] Inbox/transport rules: look for auto-forward to external, delete/mark-read
    rules hiding attacker replies, and mailbox delegation/forwarding.
[ ] Granted app permissions: new service principals, risky Graph scopes.
[ ] Token/risk detections from the IdP's identity-protection features.

Equivalent telemetry on other IdPs: Google Workspace Admin audit + login
audit + "Email log search" + forwarding settings; Okta System Log
(user.session.start, user.mfa.*, app.oauth2.*).

EVIDENCE / SCOPING -- ON-PREM (AD)#

[ ] Security logs on DCs and the user's hosts:
    4624/4625 (logons + types + source IP), 4648 (explicit creds),
    4672 (privileged logon), 4768/4769/4771 (Kerberos), 4776 (NTLM).
[ ] Account/group changes by/for the account: 4720/4722/4724/4738,
    4728/4732/4756 (added to privileged groups).
[ ] VPN / RDP gateway logs for the account; remote-access source IPs.
[ ] Any lateral movement from the account (RDP/SMB/WinRM to other hosts).

ASSESS IMPACT#

[ ] What could this account access? (mailboxes, SharePoint/Drive, file
    shares, SaaS apps, admin roles, secrets vaults).
[ ] What did it actually access? (downloads, exports, searches, sent mail,
    file reads). Pull the relevant audit trails.
[ ] Was it used to pivot? (new accounts created, grants made, phishing sent
    from the mailbox to colleagues/partners -- BEC).
[ ] Data exposure: any personal/regulated data accessed or exfiltrated?
    (feeds the breach-notification decision -- involve legal/DPO).

RECOVERY CHECKLIST#

[ ] Confirm attacker sessions/tokens are dead (re-check sign-in logs show no
    further activity after revocation).
[ ] Remove malicious inbox rules, forwarding, delegations, app consents, and
    attacker MFA methods/devices.
[ ] Restore legitimate MFA and verify the real user regains access via a
    trusted channel (verify identity out-of-band before handing back).
[ ] Quarantine/recall any phishing or BEC messages the account sent.
[ ] Add detections: alert on the TTP seen (e.g. new external forwarding rule,
    impossible travel for this user, consent to high-risk OAuth scopes).
[ ] If privileged or widely exposed, treat as a broader incident and consider
    tenant-wide credential review.

DON'T#

- Don't reset the password without ALSO revoking tokens/sessions.
- Don't delete the malicious inbox rules before recording them (evidence).
- Don't notify the user over the compromised channel (use phone/trusted).
- Don't forget service/shared accounts the user administers.

FAST ORDER OF OPERATIONS (memorize)#

Revoke sessions/tokens -> reset password -> re-enroll MFA ->
remove attacker rules/forwarding/consents/devices -> scope what was accessed
-> notify (legal/DPO if data exposed) -> add detection -> return access
to verified user.

Entra ID / M365 and Google Workspace admin guidance.

Defensive reference on CyberRamen. Offensive / red-team sheets live on OffensiveRamen.com.