Token theft after MFA fatigue: what the logs actually show
SBS Identity Team12 August 20269 min read
MFA is not a magic shield. In this engagement the user approved a push notification during a fatigue campaign, and the attacker walked away with a live session token. The interesting part is what the logs showed afterwards — and how a single conditional access gap let the stolen token travel unchallenged.
The approval that shouldn't have happened
The attacker triggered dozens of push prompts over ten minutes. The user, mid-meeting and irritated, approved one to make the buzzing stop.
In the sign-in logs this appears as a successful MFA event — which is exactly why teams that only alert on failed MFA missed it entirely.
Following the token
The stolen session token was replayed from a different ASN within the hour. Because the tenant only required MFA at initial sign-in, the replayed token sailed straight through.
The audit logs revealed the attacker enumerating mailboxes and creating an inbox rule to hide their tracks — a classic BEC precursor.
Closing the gap
Continuous access evaluation and token-binding controls would have invalidated the session the moment the source context changed.
We also recommend alerting on impossible-travel and new-ASN token replay, not just on failed authentications.
Key takeaways
- Alert on successful MFA anomalies, not just failures.
- Enable continuous access evaluation so context changes revoke live sessions.
- Treat new inbox rules and mailbox enumeration as high-priority BEC indicators.