The Conventional Wisdom
Every incident response playbook advises the same: revoke the tokens. When you confirm an identity compromise, you reset the password, kill the sessions, invalidate the refresh tokens, and then start hunting. Against adversary-in-the-middle phishing, where the goal is stealing a session cookie, this works. Revocation ends the incident.
Security teams treat token revocation as eviction. You burn the credential, the attacker loses access, and you've bought time to investigate. It's clean, fast, and has been the right answer for years.
Why We Disagree
Revocation removes a credential. It doesn't remove access.
I realized this while analyzing GraphWorm, a backdoor tied to the APT group Webworm. The implant uses Microsoft Graph and OneDrive as its command-and-control channel. No C2 domain, no beacon to a rented server, no hardcoded address to block. It authenticates to Microsoft Graph as an OAuth application and uses a OneDrive account as a dead drop for tasking and results. The entire channel rides graph.microsoft.com over TLS, from a host that's already talking to Microsoft 365 all day.
Here's what broke the playbook: the implant includes a command called upgrade. When it runs, the handler destroys all five credential strings held in the beacon object, copies five new ones in, rebuilds the OAuth scope structure, tests a connection against a new OneDrive account, writes the replacement configuration to disk, and swaps the live API instance. One task. Entire identity replaced.
You revoke the tokens. The implant's next poll fails. If the operator is watching, they queue an upgrade task pointing at a second OneDrive account they registered months ago. The implant collects it, rotates, and resumes. Same file on disk, different identity behind it. Nothing on the endpoint changed. No new binary, no new persistence mechanism, no new process.
The durable object is the registration, not the tokens it issues. Tokens are leaves; the registration is the root. Containment that stops at revoking has started a timer rather than closed a door.
The Evidence
The implant identifies victims using hardware identifiers, not network identity. It builds an identifier by hashing the network adapter's hardware address together with CPU and disk serial numbers pulled through WMI. Rename the machine, move it to a different subnet, or put it behind a new egress address, and the operator still recognizes it as the same box. Any containment plan that leans on changing the victim's network identity is solving a problem this implant doesn't have.
The detections that actually fire on this family aren't network signatures. They're cloud telemetry queries: the operator's application ID appearing in your sign-in events, authentication against an unfamiliar tenant, a non-browser HTTP library user agent hitting OneDrive, the beacon and fingerprint file names showing up in file telemetry. The application ID is a fixed string. A single query across your sign-in telemetry answers whether it's ever asked your tenant for a token.
The network layer has nothing to say. There's no unusual destination for a firewall to flag, no freshly registered domain for a reputation engine to penalize, no odd port. When the C2 channel is a folder in a cloud tenant, and the identity behind that folder can be swapped by remote command, the artifacts we're trained to chase are precisely the ones an operator can replace most cheaply.
What to Do Instead
Treat revocation as a delay, not an eviction, whenever the C2 rides an application identity. If the registration lives in a tenant you don't control, suspension means filing a report and waiting on somebody else's queue. File early rather than as a last step.
Assume the operator holds a spare. Vault Rotation costs an attacker almost nothing and costs you an entire response cycle. That asymmetry should drive sequencing: remove the endpoint's ability to reach the channel at the same moment you burn the credential, not afterward. Isolating the host or blocking that specific application from authenticating in your own tenant are both moves that don't depend on anyone else's cooperation.
Hunt on the identity plane, because the network plane is blind here. Query your sign-in logs for unfamiliar application IDs. Look for authentication against external tenants. Check for non-browser user agents hitting cloud storage APIs. None of this needs new tooling. It needs the application registration treated as the thing you're trying to kill.
Before calling an identity incident contained, ask what specifically you killed, and whether the adversary can hand themselves a replacement without ever touching the victim's machine. In GraphWorm's case, the answer was yes, and it took one function to prove it.
When the Conventional Wisdom Is Right
Token revocation still works when the attacker doesn't have a mechanism to rotate. Against session hijacking, where the prize is a stolen cookie with a fixed lifetime, revocation ends the incident. Against phishing where you catch it early, before the attacker has established persistence, revocation is the right move.
The conventional wisdom fails when the adversary has built identity rotation into their tooling and when the C2 channel is a legitimate cloud service you can't simply block. It fails when the registration outlives the tokens, and when the operator is watching their heartbeat files closely enough to respond within a poll interval.
We've spent a decade learning to hunt infrastructure, and adversaries answered by not having any. What they can't replace cheaply is the code sitting on the endpoint and the behavior of that code inside your telemetry. Start there.
