Revoked the M365 Session? Attackers Can Still Read Mail for 90 Minutes

Clicking “revoke sessions” or resetting the password on a phished Microsoft 365 account doesn’t stop an attacker who reads mail through the APIs, Eye Security says. In new research, the security firm shows that Microsoft Graph, Exchange Web Services and Exchange ActiveSync keep honoring an already-issued access token for up to 90 minutes. Only disabling the account cut them off right away.

For defenders

Why it happens: Revoking sessions invalidates refresh tokens, but access tokens already handed out stay valid until they expire, typically 60 to 90 minutes. Continuous Access Evaluation is supposed to close that gap on critical events such as a revocation, password reset or disabled account, and Eye Security found it does for Outlook desktop, Outlook on the web, Outlook mobile and IMAP. For Graph, EWS and ActiveSync, the attacker’s token kept working after a revoke or reset until it expired. That matters because newer phishing kits harvest mail through Graph, T1550.001 (Use Alternate Authentication Material: Application Access Token) and T1114.002 (Email Collection: Remote Email Collection), rather than logging in to Outlook on the web.

The catch with disabling: Disabling the account blocked all three mail paths in real time. But re-enabling it too soon brings unexpired old tokens back to life, so Eye Security advises keeping the account disabled for 90 minutes after the last access token was issued. It also found the token could still query some non-mail endpoints, such as Entra user lookups, while the account was disabled, and says there’s currently no way to block that. The write-up doesn’t describe a Microsoft response or give detection queries.

Related: Token theft is how device-code kits such as SkyW4lker and the token replay attacks Huntress tracked keep access, so this affects how you run those incidents.

What it means for you

If a criminal tricks someone at your business into signing in on a fake page, the usual fix is to change the password and sign them out everywhere. This research shows that isn’t enough for about an hour and a half: the criminal can keep pulling email through a back channel. Temporarily switching the account off is what actually stops them, even though the employee is locked out for a while.

Do this now

1. Add “disable the account” to your Microsoft 365 phishing response, before or alongside the password reset and session revoke.
2. Keep the account disabled for at least 90 minutes after the last suspicious sign-in before turning it back on.
3. Review Graph and EWS activity for that user in the audit log during the window after you revoked access.
4. Block or limit legacy and API mail access, such as ActiveSync and EWS, for users who don’t need it.

Source article: How attackers keep reading mail after M365 session revocation
Publisher: Eye Security (Eye Research), author Martin Warmer
Published: October 29, 2026
URL: https://labs.eye.security/how-attackers-keep-reading-mail-after-m365-session-revocation/

Executive Summary

Eye Security’s research is not about one named actor: it documents a gap that any attacker holding a stolen Microsoft 365 access token can use, and that is especially relevant to automated phishing kits (device-code and adversary-in-the-middle kits) that harvest mail through Microsoft Graph instead of logging in to Outlook. Entra ID issues an access token valid roughly 60 to 90 minutes and a refresh token valid up to 90 days. Revoking sessions advances the user’s StsRefreshTokenValidFrom timestamp, which kills refresh tokens but not access tokens already issued. Continuous Access Evaluation’s critical event evaluation is meant to cut access within minutes after a revocation, password reset or account disable, and Eye Security found it did so for Outlook classic (MAPI), Outlook on the web, Outlook mobile and IMAP. For Microsoft Graph, Exchange Web Services and Exchange ActiveSync, an already-issued token kept working for up to 90 minutes after a revoke or a password reset. Only disabling the account cut all three off in real time, and re-enabling it too soon revived unexpired tokens; after a disable, the same token could still query non-mailbox Graph endpoints such as Entra user lookups. The intrusion chain these leads target is therefore: token theft through phishing, responder revokes sessions or resets the password, the attacker keeps collecting mail through Graph, EWS or ActiveSync until the token expires, and may keep enumerating the directory even after a disable. The objective is continued mail collection after the defender believes the account is contained; the impact is a larger data exposure than the incident record shows. Hunt leads, false-positive expectations and the telemetry needed are detailed below; the source publishes no indicators, hashes or detection rules, so these leads key on audit and Graph activity log fields documented by Microsoft.

ATT&CK chain: Credential Access → Defense Evasion → Lateral Movement → Discovery → Collection

Hunt Lead Grid

Hunt Lead Level	Hunt Lead Name	ATT&CK	Risk of False Positives
1 (Junior)	Post-Revocation API Mail Access Sweep	T1114.002 (Email Collection: Remote Email Collection)	Low. The sweep is limited to accounts already handled as phished and to the 90 minutes after the revoke or reset, and anchors on the attacker’s IP or session rather than on the user’s own devices, which also re-sync mail after a reset.
2 (Pro)	Account Re-Enabled Within 90 Minutes of a Disable	T1550.001 (Use Alternate Authentication Material: Application Access Token)	Medium. Helpdesk staff routinely re-enable accounts disabled by mistake or for HR reasons, so the rule anchors on accounts that were disabled during a security incident or alongside a revoke or reset, not on every disable/enable pair.
2 (Pro)	Directory Lookups From a Disabled Account	T1087.004 (Account Discovery: Cloud Account)	Low. A disabled user should make no successful Graph requests at all, so any 2xx response for that UserId after the disable time is unusual; the only expected matches are requests already in flight in the first minutes.
3 (Elite)	Revocation-to-Token-Reuse Correlation	T1550.001 (Use Alternate Authentication Material: Application Access Token), T1114.002 (Email Collection: Remote Email Collection)	Low. A successful Graph, EWS or ActiveSync request after a revoke or reset that rides a token issued before that event is exactly the gap Eye Security describes; legitimate background sync from the user’s own device can match, so the rule compares IP and device against the user’s history.

Post-Revocation API Mail Access Sweep

Eye Security shows that after a session revoke or a password reset, an attacker’s existing access token keeps reading mail through Microsoft Graph, Exchange Web Services and Exchange ActiveSync for up to 90 minutes, while the same actions cut off Outlook and IMAP within minutes. Any phished account that was contained with a revoke or reset alone, and not with a disable, may therefore have lost more mail than the incident record shows. The detection logic is a retrospective sweep of the MailItemsAccessed mailbox-audit action for every such account, covering the 90 minutes after the first revoke or reset event (the Entra audit record of the user update that advanced StsRefreshTokenValidFrom, or the password reset). Keep records whose ClientInfoString shows a REST (Graph), EWS or ActiveSync client, and whose ClientIPAddress or SessionId matches the attacker’s earlier activity or does not match the user’s known devices. Bind records list each message by InternetMessageId; sync records cover whole folders.

Use the unified audit log (Search-UnifiedAuditLog with -Operations MailItemsAccessed, or the same data in a SIEM), which Microsoft enables by default for E3/E5 licensed users, together with Entra audit and sign-in logs for the revoke or reset time and the attacker’s IPs. Sweep every phishing incident closed in the last 90 days, since that is how far back the source’s refresh-token window reaches and how long many audit retentions keep MailItemsAccessed. Scope to accounts handled as compromised; do not run it tenant-wide. The user’s own Outlook will usually re-sync right after a reset, so separate their activity by IP, SessionId and ClientInfoString rather than discarding all sync records. A hit means the exposure assessment for that incident was understated: reopen it, extend the list of accessed messages using the InternetMessageId values, and review notification duties. Microsoft’s guidance is to assume every item in a synced folder was compromised. The sweep applies to any token-theft incident, not only the kits named in the summary.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Collection → T1114.002 (Email Collection: Remote Email Collection)

Sources: “How attackers keep reading mail after M365 session revocation”, Eye Security, Oct. 29, 2026, https://labs.eye.security/how-attackers-keep-reading-mail-after-m365-session-revocation/ (source article); “Use MailItemsAccessed to investigate compromised accounts”, Microsoft Learn, June 19, 2026, https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts (additional source; audit field names and search syntax)

Account Re-Enabled Within 90 Minutes of a Disable

Eye Security found that disabling the account is the only action that cuts Graph, EWS and ActiveSync off immediately, and that re-enabling it brings back any access token that has not yet expired. Its advice is to keep the account disabled for about 90 minutes after the last access token was issued. A responder or helpdesk analyst who re-enables a phished user after 10 or 20 minutes, to get them working again, silently hands the attacker back a live token. The detection logic is an Entra ID audit-log rule that pairs a user update setting the account to disabled with a later update re-enabling the same account, and alerts when the gap is under 90 minutes and the account had a session revoke, password reset, risky-user event or open incident in the preceding 24 hours.

Use Entra ID audit logs (user management category) in a SIEM, joined to sign-in logs to find the last token issuance before the disable. Sweep 90 days to find past re-enables that may have reopened access, and check each one with the post-revocation sweep above. Scope to all users, with priority on executives, finance and anyone with mailbox delegation. Tune by excluding disables that carry no security context (HR leave, licensing changes) rather than by excluding the helpdesk accounts that perform re-enables, since those are exactly the actions the rule is meant to catch. Microsoft notes that after a re-enable Exchange Online can take 35 to 40 minutes to recognize the change, which does not shorten the attacker’s token lifetime. A hit should be handled as a process failure plus a possible reopened compromise: check the account’s Graph and mailbox activity for the window after the re-enable. The control generalizes to every token-theft response playbook.

Hunt Lead Level: 2 (Pro)

ATT&CK: Defense Evasion / Lateral Movement → T1550.001 (Use Alternate Authentication Material: Application Access Token) (the rule watches for conditions that let a stolen token be reused; it does not detect the theft itself)

Sources: “How attackers keep reading mail after M365 session revocation”, Eye Security, Oct. 29, 2026, https://labs.eye.security/how-attackers-keep-reading-mail-after-m365-session-revocation/ (source article); “Continuous access evaluation in Microsoft Entra”, Microsoft Learn, updated 2026, https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation (additional source; critical events and re-enable latency)

Directory Lookups From a Disabled Account

After an account was disabled, Eye Security found that Graph requests for mailbox and SharePoint content failed, but the same access token could still query non-mailbox endpoints such as Entra user lookups, and it says there is currently no way to block that. The source demonstrates this as a capability rather than describing a specific attacker doing it, but directory enumeration is a natural next step for an attacker who has lost mailbox access and still holds a token. The detection logic is a Microsoft Graph activity log search for requests with a ResponseStatusCode in the 2xx range whose UserId belongs to an account disabled at the time of the request, with RequestUri paths under /users, /groups, /directoryObjects or /organization, and with IPAddress and UserAgent recorded for the responder. TokenIssuedAt earlier than the disable time confirms the request rides a pre-disable token.

Use MicrosoftGraphActivityLogs streamed to Log Analytics or a SIEM (it needs an Entra ID P1 or P2 licence and a diagnostic setting; events can arrive up to two hours late), joined to Entra audit logs for the disable time. Sweep back to when the logs were first enabled, and run it continuously against a watchlist of accounts disabled in the last 24 hours. The first few minutes after a disable may show legitimate in-flight requests from the user’s own Outlook or Teams; exclude those by the user’s known IPs and device, not by AppId, because the attacker may use a first-party client ID. Blocking the attacker’s IP is useful for that incident but will not stop a kit that rotates hosting, so the containment is waiting out the token while the account stays disabled. Any hit should go to incident response: record what was enumerated, since user and group lists feed follow-on internal phishing.

Hunt Lead Level: 2 (Pro)

ATT&CK: Discovery → T1087.004 (Account Discovery: Cloud Account)

Sources: “How attackers keep reading mail after M365 session revocation”, Eye Security, Oct. 29, 2026, https://labs.eye.security/how-attackers-keep-reading-mail-after-m365-session-revocation/ (source article); “Access Microsoft Graph activity logs for tenant monitoring”, Microsoft Learn, Nov. 25, 2025, https://learn.microsoft.com/en-us/graph/microsoft-graph-activity-logs-overview (additional source; log columns, licensing and delivery delay)

Revocation-to-Token-Reuse Correlation

The core of Eye Security’s finding is a sequence: a critical event (session revoke or password reset) for a user, followed by successful mail access through Graph, EWS or ActiveSync that still uses an access token issued before that event, for up to 90 minutes. Newer phishing kits automate mail collection through Graph, so in a real incident this window is used, not theoretical. The detection logic is a stateful correlation keyed on the user: take each revoke or password-reset audit event as time T; then look for MicrosoftGraphActivityLogs rows for the same UserId with TimeGenerated after T, TokenIssuedAt before T and a 2xx ResponseStatusCode on mailbox paths such as /messages, /mailFolders or /attachments, and for MailItemsAccessed records with an EWS, REST or ActiveSync ClientInfoString after T from an IP not seen for that user in the previous 30 days. Raise severity when the IP or SessionId matches the sign-in that triggered the response.

This needs Entra audit logs, MicrosoftGraphActivityLogs, the unified audit log and sign-in logs in one SIEM, joined on the user (Graph logs carry the Entra object ID, mailbox audit carries the UPN, so keep a mapping table). Microsoft documents joining Graph activity logs to sign-in logs on SignInActivityId and UniqueTokenIdentifier, which ties each request to the token issuance and its IP. Run it continuously with a 120-minute look-forward to cover delivery delays, and back-test over 90 days of past incidents. The user’s own phone or laptop may also make requests on a pre-revoke token; allowlist the user’s managed devices by DeviceId and their usual egress IPs rather than suppressing all first-party clients. The wrong response to a hit is another revoke or password reset, which is the action that did not work: disable the account and keep it disabled until the attacker’s last token has expired. The correlation generalizes to any stolen-token scenario, including device-code and adversary-in-the-middle kits, and also measures whether response playbooks are working.

Hunt Lead Level: 3 (Elite)

ATT&CK: Defense Evasion / Lateral Movement → T1550.001 (Use Alternate Authentication Material: Application Access Token); Collection → T1114.002 (Email Collection: Remote Email Collection)

Sources: “How attackers keep reading mail after M365 session revocation”, Eye Security, Oct. 29, 2026, https://labs.eye.security/how-attackers-keep-reading-mail-after-m365-session-revocation/ (source article); “Access Microsoft Graph activity logs for tenant monitoring”, Microsoft Learn, Nov. 25, 2025, https://learn.microsoft.com/en-us/graph/microsoft-graph-activity-logs-overview (additional source); “Use MailItemsAccessed to investigate compromised accounts”, Microsoft Learn, June 19, 2026, https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts (additional source)

Hash Appendix

No hashes. The source article describes a token-handling gap, not malware, and publishes no files, hashes or network indicators; AlienVault OTX and VirusTotal were not queried because there is nothing to look up.

References Appendix

• “How attackers keep reading mail after M365 session revocation”, Eye Security (Martin Warmer), Oct. 29, 2026, https://labs.eye.security/how-attackers-keep-reading-mail-after-m365-session-revocation/ (source article; protocol-by-action results, token lifetimes, disable guidance)
• “Continuous access evaluation in Microsoft Entra”, Microsoft Learn, updated 2026, https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation (critical events, re-enable latency)
• “Use MailItemsAccessed to investigate compromised accounts”, Microsoft Learn, June 19, 2026, https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts (MailItemsAccessed fields and search syntax)
• “Access Microsoft Graph activity logs for tenant monitoring”, Microsoft Learn, Nov. 25, 2025, https://learn.microsoft.com/en-us/graph/microsoft-graph-activity-logs-overview (Graph activity log columns, sign-in correlation)
• MITRE ATT&CK Enterprise technique pages linked above, MITRE, https://attack.mitre.org/