Somebody talked the help desk into a reset

Nothing was exploited: somebody asked, and the process said yes. Groups such as Scattered Spider have made this a standard way in, and what follows the reset is usually fast: a new MFA device, a look around the identity platform, then the consoles that matter.

Trigger. The service desk reset a password or an MFA method for a caller, and the real user says it was not them. Or a new MFA method appeared on an account straight after a help desk ticket.

The first 60 minutes2 of 5 expire

01 02 03 04 05

030 min60

01
Revoke sessions and remove every MFA method added since the reset
by 10 minexpires
Revoke refresh tokens and sign-in sessions, then list the account's authentication methods and delete anything registered on or after the reset. Re-enrol the real user's methods only once their identity is confirmed through the channel above.
02
Export the sign-in and audit logs from the reset onwards
by 20 minexpires
Sign-ins with IP address, device and user agent, and audit events for method registration, device registration, role changes and application consents. Export them now: on some licence tiers the retention is a matter of days.
03
Look where the account can reach, not only at its mailbox
by 40 min
Admin roles, and group memberships that reach the identity platform, the password vault, the hypervisors, the cloud consoles and the code repositories. Actors who open with a help desk call go for these next, so check what happened in those consoles since the reset.
04
Find every other call like it
by 60 min
Search the service desk system for resets and MFA changes in the last 30 days where the caller pressed for urgency, said they were new or travelling, or asked for a privileged account. A group that succeeded once has usually tried several times.
05
Change the reset process today, not after the report
A check the caller cannot pass with information from LinkedIn or an old breach: a call back to a number on record, approval from the manager, or a video check with ID for privileged accounts. Tell the desk what happened, without blame. They are the control that was tested, and the next call will come to them.

Tell somebody

The identity team, now, because the access was granted by process rather than taken by exploit
Whoever owns virtualisation and backups, since that is where this kind of actor tends to go
The service desk lead, on the other calls and on changing the process today

Drawn from

The documents these steps come from, so you can check one rather than take it on trust.

The evidence

What each source proves, and what it does not.

Collect it in one go

A read-only script that gathers most of the above in volatility order, with a hash manifest.

Triage collection

Make it yours

Replace the escalation list with real names, and the timings with what your change process actually allows. A playbook that assumes an authority you do not have will stall at the step that needed it.

Revoke sessions and remove every MFA method added since the reset

Export the sign-in and audit logs from the reset onwards

Look where the account can reach, not only at its mailbox

Find every other call like it

Change the reset process today, not after the report