ChecklistCONSTRUCTEDUntested
First 15 minutes: a successful sign-in from an IP address nobody recognises
A user's account signed in successfully from an address, country or device that does not fit. How to tell a traveller from a stolen session in five minutes, and what to cut off if it is the second.
high severityInitial AccessT1078.004T1078T1557
The clock starts when
Identity protection, a SIEM rule or the user reports a successful sign-in to a work account from an IP address, country, network or device that does not match how they normally sign in.
Decide whether it was them
If it was not them, cut it off
Find out what the session touched
Do not
- Do not reset the password and close the ticket. Revoke the sessions, and check the MFA methods.
- Do not ask the user about it by email or chat on the account in question. The attacker may be reading it.
- Do not block the IP address and call it contained. Addresses rotate; the account is what you are containing.
Escalate now if
- The account holds an administrative role anywhere: the identity provider, cloud, email or finance systems.
- MFA was satisfied on the sign-in you cannot explain.
- New inbox rules, forwarding, app consents or MFA methods appear after it.
- The same address signed in to other accounts.
Minute sixteen. The checklist ends here and the response does not.
Open the cloud account compromise playbookWhy this order
Most unfamiliar sign-ins are the user: a hotel network, a new phone, a VPN that exits somewhere unexpected. The first five minutes exist to rule that out quickly without tipping off anybody if it is not. The question is never "is this address bad", which you cannot know, but "does this sign-in fit this person".
When it does not fit, the order of the next five minutes matters more than the speed. The modern version of this incident is not a stolen password, it is a stolen session: a phishing page that relays the real login, lets the user complete MFA, and keeps the cookie. A password reset on its own does nothing to that session, which is why revocation comes first.
What this does not cover
How the attacker got the credentials, and whether they used the session to set up anything that outlives it. The playbook linked above takes both. Walk this through in a tabletop before you rely on it, and change the escalation list to match who in your organisation can revoke sessions at two in the morning.