Working SOC analyst. I've been writing up alert triage scenarios as a way to onboard new hires on my team — turns out putting them on paper helped me clarify my own thinking as much as theirs. Sharing one here.
The kind of alert that used to take me 30 minutes to make sense of as a Tier 1 and now I see the pattern in 30 seconds.
The scenario
Trigger: identity provider alert — user enrolled a new TOTP token at 03:14 local time.
Subject: User kphillips. Enrollment from IP 71.112.x.x (Comcast residential range, US East Coast).
Context: User is a regional finance manager. Last login before enrollment was 20:42 the prior evening.
The walkthrough
Pull authentication logs for the 24 hours surrounding the enrollment. Look at what's around it, not just the alert itself.
What you'd find:
03:09— successful authentication from the same Comcast IP, with the user's existing TOTP. MFA was actually completed (this is the trap — it looks legit).03:14— new TOTP enrollment.03:16— existing TOTP token deleted.03:18— OAuth grant created to a third-party app named "Mail Tools."
User has never logged in between midnight and 6 a.m. local before. Today they did, completed MFA cleanly, and within nine minutes had replaced their MFA method and granted a third-party app persistent mailbox access.
The pattern
This is account takeover where the attacker has either phished the user or hijacked an active session token, completed MFA from the user's own device (or via real-time relay), then immediately replaced the MFA token to lock the legitimate user out and granted OAuth for persistent access — usually to read the mailbox so password resets and notifications can be intercepted.
The "MFA was completed" part is what fools junior analysts. The thinking should be: MFA being completed doesn't prove the legitimate user did it. It proves someone with access to the second factor did it. If the user's session was hijacked or they were tricked into approving a push notification, MFA is bypassed without ever showing as failed.
Containment
- Revoke all active sessions for the user.
- Force password reset.
- Remove the unauthorized OAuth grant immediately — don't wait for IR to formalize it.
- Contact the user out of band. Phone, not email. The attacker has the mailbox.
- Pull the OAuth app's permissions and check whether mail forwarding rules were created. They usually are.
I've written up 19 more of these in the same format (impossible travel that's actually VPN routing, service account interactive logins, w3wp.exe → cmd.exe → powershell.exe webshell chains, beacon-shaped network behavior, anomalous mailbox rules), plus a week-by-week ramp guide for new analysts. Happy to share the 8-page free sample if anyone wants it: https://drive.google.com/file/d/1hH-6xV929UbQZS0AO1nb08gdRi1O4MdB/view?usp=sharing
If anything in this walkthrough is wrong or could be sharper, please tell me — that's how the next version gets better.