Case file · anonymized · MDR · account takeover · remediation

The sessions were revoked. The password wasn't.

An MDR flagged an account, revoked its sessions, and closed the ticket. Seventy-two hours later the same infrastructure signed back in. The remediation was never actually finished.

July 25, 2026 · 4 min read · worked by the principal

An incumbent MDR raised a medium-severity alert: a user account had signed in from an IP that belonged to a hosting provider — not a residential ISP, not the customer’s campus network. The account holder had no business authenticating from a data center. The MDR’s analyst did the expected thing. They moved the account into a restricted-access group and revoked all of its active sessions. Then they marked the ticket resolved.

Three days later, the same hosting infrastructure signed into the same account again, read the mailbox, and sent mail. No new alert fired. The original ticket had already auto-closed.

We found it on a routine review of the customer’s own sign-in telemetry — not from the MDR, which considered the matter finished.

Why revocation didn’t hold

Session revocation and a password reset solve two different problems, and people conflate them constantly.

Revoking sessions invalidates the refresh and access tokens the account currently holds. Every signed-in session — browser, mobile mail app, desktop client — is forced to re-authenticate. That is genuinely useful. It kills a stolen session cookie immediately.

Resetting the password invalidates the credential itself. It is the only action that stops someone who holds the account’s valid password from simply logging in again.

Here is the failure in one sentence: revoking sessions on an account whose password is still valid tells the attacker to log in again — and hands them a clean new session when they do.

Whoever was using this account still had the password. The moment their revoked session died, they re-authenticated with the credential they still held, and the identity provider issued them a fresh, fully valid session. Nothing about “move to a restricted group and revoke sessions” had touched the credential. The door was never locked; the current visitors were just asked to knock again.

The part that made it worse

Two design choices in the MDR’s process turned an incomplete fix into a silent one.

1. The ticket auto-closed. Once the analyst applied the standard actions, the workflow marked the incident resolved and the case aged out. There was no follow-up check to confirm the account could no longer be accessed — the single test that would have caught the re-entry.
2. Re-entry didn’t re-alert. The detection that flagged the first hosting-provider sign-in did not re-fire on the second one, because from the platform’s perspective the case was closed and the behavior was “known.” The return was invisible on the very dashboard that was supposed to be watching it.

The net effect: the account was accessed, used to read and send mail, and no one on the monitoring side knew — because the record said resolved.

How to spot it in your own tenant

Pull every account your MDR “remediated” in the last 90 days. For each one, in the Microsoft 365 audit log, check two things after the remediation timestamp:

• Any UserLoggedIn events from the same source IP or hosting ASN that triggered the original alert.
• Any MailItemsAccessed or Send operations at all. A truly evicted attacker generates neither.

If you find post-remediation activity, ask the obvious question: was the password ever reset? In our experience, on medium-severity identity alerts, the answer is frequently no — the standard play is revoke-and-restrict, and the credential rotation is left to “the customer,” who was never told they needed to do it.

What complete containment looks like

On any account you believe held a compromised credential, the minimum is not one action. It is a sequence, and you verify the last step:

1. Reset the password — rotate the credential to a value the actor does not have. This is the step that actually locks the door.
2. Revoke all sessions — kill the tokens the old credential already minted.
3. Re-enroll MFA under supervision — an attacker who registered their own authenticator keeps a way back in until you remove it.
4. Close the hybrid loop — if the tenant runs directory sync, disabling or resetting cloud-side alone can be silently reverted by the next on-premises sync cycle. Handle both sides, then force a sync.
5. Verify eviction — the step everyone skips. Confirm, from the logs, that the account cannot be re-accessed. If the case can auto-close before this check runs, your process has the same hole this one did.

Steps one through four take a few minutes. Step five is the difference between a closed ticket and a contained incident.

Session revocation is a real control. It is not, by itself, containment. If your monitoring provider’s remediation for a suspected credential compromise ends at “revoked and restricted” — and the ticket closes before anyone confirms the account is actually locked out — you are one valid password away from the incident you thought you closed.

Anonymized per our marketing policy. The remediation sequence, the 72-hour re-entry, the auto-close behavior, and the post-remediation mailbox activity are real; the customer, the monitoring provider, the account, and the exact dates are generalized.

Want us to check your last 90 days of “remediated” accounts for post-remediation activity? The person who worked this case answers the email.