In this section
Containment Decisions: Containment Is a Decision, Not a Reflex
The action that feels like containment
The grade is done. The incident is High, you have escalated it, and now you have to stop the harm. The instinct is immediate and almost muscular: disable the account. It is the move every analyst reaches for first, because it is one click, it feels decisive, and it is what containment has always looked like. And against a modern identity attack it can do nothing at all. An attacker who stole a session token does not authenticate through the account you just disabled; they replay the token they already hold, and the token stays valid until it expires or is explicitly revoked, regardless of the account's state. You disabled the account, the dashboard shows it disabled, and the attacker's session keeps reading mail and moving through the tenant, because you contained the wrong thing.
This is the problem the module turns on: containment that targets the wrong object is not containment, however decisive it feels. The grade from TR8 told you how urgent the incident is and what drove it; containment is the act that follows, and the act has to sever the access the attacker is actually using, not the access that is easiest to click. That is routinely got wrong under pressure, because the familiar move is fast and the correct move requires a moment of reading: what is this attacker's live access riding on, and what action severs that. Containment is a decision, and this sub is the mental model that turns the reflex into one.
The disable acts on the account; the attacker's access rides on the token. Only revoking the session severs what the replay depends on.
Contain the capability, not the object
The shift is from objects to capabilities. The reflex thinks in objects, the account, the password, the host, because those are the things with buttons next to them. The decision thinks in capabilities: the attacker has some live access to your environment, that access is riding on a specific mechanism, and containment is whatever action severs that mechanism. Sometimes the mechanism is the account, and disabling it works. Often, in the modern attacks this course has spent eight modules on, it is a stolen session token, an OAuth grant, a planted service principal, or a credential being used from somewhere it should not be, and for each of those the object with the obvious button is not the mechanism the access rides on. The discipline is to ask what the access depends on, then act on that, rather than acting on the object habit puts in front of you.
The triage you have already done hands you the answer. You read the evidence, you classified the incident, you graded it, and in doing so you established what the attacker holds: a replayed token, a standing grant, a compromised credential, a foothold on a host. That classification is the input to the containment decision, because it names the capability, and the capability names the action. An incident triaged as token theft contains by revoking the session, not by resetting a password the token does not depend on. An incident triaged as a standing OAuth backdoor contains by removing the grant, not by disabling the user the grant outlived. The containment decision is not separate from the triage; it is the triage's conclusion turned into an act, and an analyst who triages well and then contains by reflex throws away the very understanding that should have chosen the action.
The decision is a short read, not a long deliberation. Before you contain, you ask one question: what is the attacker's live access riding on right now, according to the evidence I just triaged. If it is the account, disable it; if it is a token, revoke the session; if it is a grant, remove it; if it is a credential being replayed, revoke the session and reset, in that order. The reflex of disabling the account served a decade of password-based attacks, where the account and the access were the same thing, and the modern attacks this course has centred on broke that equation: the access now rides on a token or a grant the disabled flag does not touch.
When account and access were one thing, disabling the account worked. Token theft and grant abuse split them apart, and the reflex aimed at the account misses the access.
The buttons sit next to objects; the access rides on capabilities. The triage you already did names the capability, which names the action that actually severs it.
Seeing it in the evidence
The reflex's failure made concrete: the account disabled while the token replay continues, visible in the non-interactive sign-ins the account state does not touch.
Where to find it
The capability you must contain is read from where the access actually appears. For a stolen token being replayed, the non-interactive sign-in log (Entra AADNonInteractiveUserSignInLogs / Splunk azure:aad:signin:noninteractive) is where the live session shows itself, the token presenting itself to act without a fresh interactive logon. That log is what keeps registering activity after an account disable, because the replay does not go through interactive authentication and the disabled flag does not revoke the already-issued token. Reading it is how you see that the account action missed the capability, and that the session revocation is the move that would not.
SIEM Console
For a suspected token theft, the non-interactive sign-ins show the replayed session continuing to act. If those sign-ins keep appearing after an account disable, the disable missed the capability: the access rides on the token, not the account, and the containment that works is session revocation. The log tells you which object to aim at, so you aim once and correctly.
azure-aad-signin-noninteractive
| stats count as replays, max(_time) as last_seen by userAADNonInteractiveUserSignInLogs
| summarize replays = count(), last_seen = max(TimeGenerated) by UserPrincipalName# The action that actually severs a replayed token: revoke sessions, not disable the account
Revoke-MgUserSignInSession -UserId $userIdRead the output
Predict before running. The panel returns, per user, the count of non-interactive sign-ins and the most recent one, and for a token-theft account those replays continue right up to the present. Read that as the capability you must contain. The replays are the stolen token presenting itself to act, and tellingly they do not pass through interactive authentication, so they are exactly the activity an account disable does not stop, the disabled flag blocks new interactive logons while the already-issued token keeps working.
So if you had reached for the reflex, disabled the account, reset the password, this log would keep showing replays after both actions, which is the silent failure made visible: the dashboard says contained, the evidence says the session is live. The action that would actually flatten this line is session revocation, which invalidates the token the replay depends on. Read the last-seen timestamp as the test of whether your containment worked: if it stops advancing after you act, you aimed at the capability; if it keeps advancing, you aimed at the object and missed.
Run the panel and read it as the thing the containment must sever, not as one more detection: the replayed session is the capability, and the decision is the action that ends it.
Containment as a decision
Before you contain, read what the attacker's live access is riding on, then aim the action at that capability rather than the object habit puts in front of you.
1. Name the capability from the triage
The classification you already made names what the attacker holds: a replayed token, a standing grant, a compromised credential, a foothold. That is the input to the containment decision, because the capability names the action.
2. Ask what the access depends on
A token rides on the session, not the account. A grant rides on the app registration, not the user. A replayed credential rides on both the session and the secret. Aim at the mechanism the access actually depends on.
3. Verify the action hit the capability
Read the evidence again after acting: if the live activity stops, you aimed correctly; if it continues, you contained the object and missed the capability. The last-seen timestamp on the live session is the test.
A containment aimed at the wrong object is zero, not slow
Disabling the account feels decisive and may touch nothing the attacker is using. The reflex served the password era, where account and access were one thing; it fails silently against token and grant attacks. The fastest real containment is the one aimed correctly the first time.
Your turn
You triage an incident and classify it confidently as token theft: a session token stolen via an adversary-in-the-middle proxy and now being replayed. Under time pressure you disable the account and reset the password, and report the incident contained. Ten minutes later the SIEM still shows the account active in the environment. What went wrong, and what action would actually contain it?
Reveal
What went wrong is that you contained the object habit put in front of you, the account and the password, rather than the capability your own triage identified, the replayed token, and neither action touches what the attacker's access actually rides on. You classified the incident correctly as token theft, which means you already knew the attacker holds a stolen session token and is replaying it, and a replayed token does not depend on the account being enabled or on the password, it is a separate, already-issued artifact that remains valid until it expires or is explicitly revoked. Disabling the account blocks new interactive logons, but the attacker is not performing interactive logons, they are replaying a token that was already issued, so the disabled flag does not reach them. Resetting the password invalidates the credential, but the live session is not holding the password, it is holding the token, so the reset changes nothing about the active session. That is why the SIEM still shows activity: the non-interactive sign-ins, the token replaying itself to act, continue after both actions because both actions aimed at objects the access does not depend on. The dashboard shows the account disabled and the password changed, which is exactly the silent failure the sub warns about, the appearance of containment with none of the substance. The action that would actually contain it is session and token revocation: revoking the user's sign-in sessions invalidates the issued tokens the replay depends on, which is the only action that severs the capability the attacker is using. Done first, it flattens the replay activity, and you verify it worked by watching the last-seen timestamp on the non-interactive sign-ins stop advancing. You would still reset the password as part of a complete response, because the credential path may also be compromised, but the password reset is not the containment for the token, and reaching for it first while the session stays live is the reflex failing. The lesson is the sub's core: containment targets the capability the attacker is actually using, which your triage already named, not the object with the obvious button, and against token theft the capability is the session, so the containment is revocation, not account disable.
Where this leads: you have the mental model, containment is a decision that targets the capability the evidence names, not the object habit reaches for. The next sub builds the vocabulary the decision needs: the distinct things you can actually be containing, session and token, credential, grant, host, network path, and how the triage tells you which one the attacker holds.