Why disabling an account does not kill a live token
You disabled the phished account and reset the password, yet the attacker keeps reading mail. A stolen token keeps working against resources that do not enforce Continuous Access Evaluation.
Disabling an account or resetting a password feels like cutting access. A live access token that was already issued does not get the memo.
How the attack works
After a phishing alert, the team disables the user and resets the password, believing access is severed. But the attacker had already stolen an access token. Against resources that do not enforce Continuous Access Evaluation, that token keeps calling Microsoft Graph for its full lifetime, roughly an hour, because revocation is not instant everywhere. In that window the attacker reads mailbox items and downloads files while the directory shows the account as disabled. Access ends only when the token reaches natural expiry. This maps to T1550, Use Alternate Authentication Material, and T1539, Steal Web Session Cookie.
Why it works
Disabling and resetting affect future authentication and the minting of new tokens. They do not retroactively invalidate a token already in an attacker’s hands, and without CAE the resource has no near-real-time signal telling it to stop honoring that token.
How to fix it
Revoke the user’s refresh tokens and sessions so no new tokens are minted, and enable CAE strict enforcement so resources receive a near-real-time revocation instead of waiting out the lifetime. Waiting, a second password reset, or a single perimeter block do not stop cloud-to-cloud token use. The durable fix is to enable and verify CAE coverage across all apps and resources and to make revoke-sessions a standard step in every compromise response. Scope the disable-to-expiry window from the sign-in and resource logs.
Practice it
We built this as a GraphLattice Range scenario so responders learn that a disable is not a revoke, and how to close the CAE gap.