ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • Microsoft Entra ID • Identity • Refresh Tokens • Session Revocation • Defender XDR • KQL

The Account Was Disabled — But the Refresh Token Still Worked

The incident response looked complete.

The compromised user account had been identified. The password had been reset. The account had been disabled.

Everyone expected the activity to stop.

It didn't.

Agent Foskett had one question: if the attacker could no longer authenticate as the user, what exactly was still keeping the session alive?

Discuss identity security Back to investigations
Agent Foskett investigating Microsoft Entra session activity after an account was disabled
The Session Question

Disabling an identity and terminating every session associated with it are related containment actions — but they are not the same investigation question.

Establish when the account was disabled
Separate new authentication from existing session activity
Revoke sessions and verify containment

The account was disabled at 9:17 AM

The response team had done what seemed obvious: stop the identity from signing in. But telemetry after 9:17 AM still showed activity associated with the user. The first mistake would be assuming every event after disablement represented a brand-new successful login.
The identity was blockedThe account could no longer simply begin a normal new authentication flow as though nothing had happened.
The timeline continuedEvents associated with the user appeared after the containment action, so the analyst needed to determine whether they came from an existing session, token use, an application or another mechanism.
Disable was not the end of the timelineContainment is not complete because an administrative button was clicked. It is complete when the evidence shows the attacker can no longer operate.

First establish the last successful sign-ins

Start by building the identity timeline around the disablement time. In Microsoft Sentinel, SigninLogs can show successful interactive sign-ins, source IP addresses, applications, devices and Conditional Access context. Replace the sample account and time with values from your incident.
successful-signins-before-disable.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let User = "alex@contoso.com";
let DisableTime = datetime(2026-08-25 09:17:00);
SigninLogs
| where TimeGenerated between (DisableTime - 12h .. DisableTime + 2h)
| where UserPrincipalName =~ User
| where ResultType == 0
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          AppDisplayName,
          ClientAppUsed,
          ConditionalAccessStatus,
          DeviceDetail,
          CorrelationId
| order by TimeGenerated asc

Now separate interactive from non-interactive activity

A session can continue without the user typing a password again. Non-interactive sign-in telemetry is therefore critical when investigating token-based access. The goal is not to declare every non-interactive event malicious; it is to identify activity that continues after the containment boundary and compare it with the known attacker context.
noninteractive-after-disable.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
let User = "alex@contoso.com";
let DisableTime = datetime(2026-08-25 09:17:00);
AADNonInteractiveUserSignInLogs
| where TimeGenerated between (DisableTime .. DisableTime + 6h)
| where UserPrincipalName =~ User
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          AppDisplayName,
          ResourceDisplayName,
          ResultType,
          ResultDescription,
          ConditionalAccessStatus,
          DeviceDetail,
          CorrelationId
| order by TimeGenerated asc

Was the same attacker infrastructure still present?

The strongest clue is correlation. Compare the IP addresses, applications and device context seen before disablement with the events that follow it. If the same suspicious infrastructure appears on both sides of the containment action, the timeline deserves immediate attention.
ip-correlation-after-disable.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let User = "alex@contoso.com";
let DisableTime = datetime(2026-08-25 09:17:00);
AADNonInteractiveUserSignInLogs
| where TimeGenerated between (DisableTime - 6h .. DisableTime + 6h)
| where UserPrincipalName =~ User
| summarize Events = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            Apps = make_set(AppDisplayName, 20),
            Results = make_set(ResultType, 10)
    by IPAddress
| order by LastSeen desc

The refresh token changed the containment story

Access tokens are normally short-lived, while refresh tokens and browser or application sessions can allow clients to obtain continued access without repeatedly asking the user for credentials. Microsoft Entra evaluates session and token state through its own controls and policies. For the investigator, the important lesson is simple: password reset, account disablement and session revocation must be understood as separate containment actions.
Authentication already happenedThe attacker may have established a valid session before the incident team disabled the account.
Tokens have their own lifecycleAn analyst should investigate token and session behaviour rather than assuming every cloud request requires a fresh password challenge.
Revocation mattersWhen compromise is confirmed, revoke the user's sessions as part of containment and then verify the result in telemetry.

Do not stop at the identity logs

If the attacker had access before containment, ask what they did with it. Review Microsoft 365 and Defender telemetry for mailbox access, file activity, OAuth consent, role changes, inbox rules and endpoint activity. The identity timeline tells you how access continued; the wider investigation tells you what that access achieved.
Exchange and mailbox activityLook for mailbox access, forwarding, suspicious inbox rules and actions that occurred during the compromised session.
SharePoint and OneDriveDetermine whether files were accessed, synchronised, shared externally or collected while the attacker still had session access.
Persistence beyond the userCheck whether the attacker created OAuth grants, application credentials, privileged assignments or another route that survives remediation of the original account.

Agent Foskett's investigation mindset

A disabled account is an administrative state. Containment is an evidence-based conclusion.
Ask what happened after the fixEvery containment action creates a new point on the timeline. Investigate what occurred immediately after it.
Do not confuse events with new loginsCloud activity, token refresh and interactive authentication are not interchangeable concepts. Classify the telemetry before drawing the conclusion.
Verify containmentAfter revoking sessions and remediating the account, keep watching. The quiet timeline afterwards is part of your evidence.

Investigation findings

The account disablement was necessary, but the incident could not be closed merely because the identity had been blocked. The investigation had to distinguish pre-existing session activity from fresh authentication, revoke active sessions, examine what the attacker accessed and verify that suspicious activity stopped.
The disable time became the pivot9:17 AM divided the investigation into activity established before containment and activity observed afterwards.
The session needed its own investigationThe evidence had to establish whether continued access came from existing session state, non-interactive authentication or another persistence mechanism.
Containment required proofReset credentials, disable the compromised identity where appropriate, revoke sessions, remove persistence and confirm from telemetry that the attacker is gone.

Related Agent Foskett investigations

Continue with identity compromise, session hijacking and Microsoft Entra investigations.
The User Was Disabled — But the Account Was Still ActiveFollow the wider identity investigation when disabling a user does not immediately explain the remaining activity.
The Session Token Never ExpiredExplore why session lifetime and token behaviour matter during identity compromise.
Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills through structured lessons.
The account was disabled. The investigation wasn't.
Never let the administrative action become the closing argument.
Visit the Agent Foskett Academy

Final thought

Identity incidents are rarely solved by one button. A password reset changes credentials. Disabling an account changes whether the identity can sign in. Revoking sessions targets existing session state. The analyst's job is to understand which problem each action solves — and then prove the attacker has actually lost access.
Disable the identityStop new use of the compromised account when your containment plan requires it.
Revoke the sessionsDo not assume credential remediation alone has dealt with session state already established by the attacker.
Then watch the logsBecause the investigation ends when the evidence says the access has stopped — not when the portal says Disabled.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Account Was Disabled — But the Refresh Token Still Worked

This Agent Foskett investigation explores Microsoft Entra identity compromise, existing sessions, refresh-token behaviour and why disabling an account does not replace session revocation and post-containment verification.

Microsoft Entra Sign-In Logs And KQL Investigation

The investigation uses SigninLogs and AADNonInteractiveUserSignInLogs in Microsoft Sentinel to reconstruct successful authentication, non-interactive activity, source IP addresses, applications and events surrounding an account disablement.

Refresh Tokens, Session Revocation And Identity Incident Containment

GEMXIT helps organisations investigate compromised Microsoft identities using evidence-driven timelines, Microsoft Entra telemetry, Defender XDR and KQL to distinguish credential remediation from complete session containment.