Containment Decisions: Token and Session Revocation as First-Class Containment

The action reached for last that should be first

For the attacks that now dominate, the containment most analysts reach for last is the only one that works. Token theft and adversary-in-the-middle replay are the leading way attackers bypass MFA, and the access they give rides entirely on a stolen session token. Against that, the habitual first moves, disable the account, reset the password, do nothing, because the token is independent of both once issued. The action that severs it, session revocation, is the one analysts reach for last, treated as a follow-up step rather than the containment. This sub inverts that: for token-based attacks, session revocation is first-class containment, the first move, not an afterthought to an account action that never touched the access.

TR2 established the mechanics you need here: revoking the session invalidates the token the replay depends on, while a password reset leaves it untouched. This sub takes that from a fact about token theft to a containment discipline. The point is not only that revocation works where reset fails, it is that revocation should be the action you reach for first when the triage names a token, with the same reflex speed you currently reach for account-disable. Making it first-class means changing the order of your instincts: token named, session revoked, then everything else.

Why revocation is the containment and the others are not

The reason comes down to what each action touches and when the token was issued. A session token is minted once, at authentication, and then it is a self-contained bearer artifact: presenting it is sufficient to act as the user, and it stays valid until it expires or is explicitly revoked. Disabling the account changes the account's state going forward, blocking new interactive authentications, but it does not reach back to invalidate a token already issued, so the attacker replaying that token is unaffected. Resetting the password invalidates the credential, which matters for stopping new authentications with that secret, but the live session is not holding the password, it is holding the token, so the reset changes nothing about the active replay. Both actions operate on the wrong layer for a token already in the attacker's hands.

Session revocation operates on the right layer: it invalidates the issued tokens themselves, so the next time the attacker replays, the token is rejected and the session dies. That is why it is the containment and the others are not: against a token, the only action that severs the access is the one that invalidates the token. The practical form is revoking the user's sign-in sessions, which marks the issued refresh and session tokens invalid and forces re-authentication. Done first, it stops the replay; done after a reset and a disable that already failed to touch it, it still works but you have spent the dangerous minutes letting the session run. First-class means first in time, because every minute the revocation waits is a minute the replay continues.

Revoke first, verify, then complete

First-class containment is an order of operations, more than a preferred action. The discipline is three steps. Revoke first: the moment the triage names a token compromise, revoke the user's sign-in sessions, before the account action, before the reset, because that is the step that stops the live harm and every other step can wait the seconds it takes. Verify second: read the evidence to confirm the replay actually stopped, because revocation that did not take, or a second session you missed, leaves the attacker live while you believe you contained them. The non-interactive sign-ins are the verification, if they stop advancing after you revoke, the containment worked; if they continue, you have another session or the revocation failed.

Complete third: now do the reset and any account action, for the credential path and for completeness, because a token theft often rides on a credential compromise too, and a full response addresses both. The order matters because the steps have different urgencies, the revocation is the only time-critical one, the rest can follow once the bleeding stops. This inverts the habitual order, where the reset and disable come first and the revocation, if it happens, comes last, which spends the urgent minutes on the non-urgent actions while the replay runs. Revoke first, verify it took, then complete: that is what making revocation first-class looks like in practice, and it is the difference between stopping the attack in the first minute and stopping it in the tenth.

Seeing it in the evidence

The verify step made concrete: the non-interactive replay you watch to confirm the revocation actually stopped the session.

azure-aad-signin-noninteractive
| stats count as replays, max(_time) as last_seen by user

AADNonInteractiveUserSignInLogs
| summarize replays = count(), last_seen = max(TimeGenerated) by UserPrincipalName

# Step 1 revoke first; step 3 reset follows once the replay is verified stopped
Revoke-MgUserSignInSession -UserId $userId
Reset-MgUserAuthenticationMethodPassword -UserId $userId

Your turn

A token-theft alert fires on a finance user: an AiTM proxy stole the session token and it is being replayed now. You have the containment console open. List the order of actions and, for each, what you would check before moving to the next.

Where this leads: you can make revocation the first-class containment it should be for token attacks, and verify it took. The next sub steps back to the decision that sits over all containment under the triage clock, the trade-off between the narrowest action that stops the harm now and the complete action that takes longer, and when the gap between them costs you.