Blog · Deliverability
Password Resets Do Not End an Active OWA Compromise -- Here Is What Actually Does
When an OWA account is compromised, most administrators change the password and consider the incident closed. It is not.
An Exchange Online password change does three things: it sets a new credential, it prevents future login attempts using the old password, and it does almost nothing to sessions that are already open. If the attacker has an active OWA session at the time of the reset, that session keeps working. The new credential does not automatically kill the old session.
This catches a lot of responders off guard. The assumption that "password reset" means "all sessions killed" is wrong, and acting on it leaves the account compromised.
Why Password Reset Does Not End OWA Sessions
Exchange Online uses a token-based session model. When a user authenticates, the system issues a refresh token that remains valid for a configurable period -- up to 90 days by default. Changing the password does not invalidate tokens that have already been issued. Every active OWA tab and every authenticated mobile app continues working until the token expires or is explicitly revoked.
This is the intended behavior. Microsoft designed token-based sessions so that a mid-session password change does not immediately lock out legitimate users. The tradeoff is that it also does not immediately lock out anyone who was already authenticated.
The practical implication: a password reset alone is insufficient remediation. You must revoke the tokens explicitly.
What Actually Terminates an Active OWA Session
To force every session to re-authenticate, run this in Azure AD PowerShell:
Revoke-AzureADUserAllRefreshToken -ObjectId
This immediately invalidates all active tokens for the account. Any open OWA session stops working, and the attacker is kicked out on their next request.
You can do the same thing through the Microsoft 365 admin center:
1. Go to Users > Active users
2. Select the compromised account
3. Click "Sign out of all sessions"
This performs the same revocation from the GUI.
If the account is enrolled in Intune and managed on mobile, a remote wipe command removes corporate data from the device and invalidates all stored tokens on that device.
For accounts protected by Conditional Access policies, the Azure AD portal allows selective session invalidation without a password change. This is useful when you want to kill specific sessions while preserving the current credential.
On-Premises Exchange: Different Rules
Organizations running on-premises Exchange Server do not use the same OAuth token model as Exchange Online. An active OWA session on-premises is tied to an IIS worker process on the server. Changing the AD password does not recycle that worker process, so the session persists.
To kill on-premises OWA sessions:
IISRESET /restart
This restarts the IIS worker process and terminates all active sessions on that server. Alternatively, recycle the OWA Application Pool through IIS Manager.
In hybrid environments where shared OAuth is used for cross-premises access, the on-premises session termination still applies to direct OWA access, while the Exchange Online token revocation covers cloud-connected sessions. Both matter.
The Full Blast Radius of an OWA Compromise
Credential theft is often only the first layer. A compromised OWA account typically includes one or more of the following persistence mechanisms.
Inbox rules -- Attackers commonly create rules that silently forward new mail to an external address, move specific message types to a hidden folder, or mark incoming items as read. These rules run automatically and do not require the account password to operate.
Delegate access -- An attacker who has added themselves as a mailbox delegate with Full Access or Send As permissions can reach the mailbox without any credential at all. The access persists regardless of password changes.
Sent mail hiding -- Some attackers use the Hide from Address Book feature to make the mailbox harder to find, or mark sent messages as unread to hide their activity in the Sent Items folder.
Mailbox-level forwarding -- In addition to inbox rules, a forwarding SMTP address can be set at the mailbox level, which operates independently of user-configured rules.
Step-by-Step: How to Actually End an Exchange Online Compromise
Work through this sequence in order. Do not stop after the password reset.
1. Revoke all active sessions
Run this in Azure AD PowerShell:
Revoke-AzureADUserAllRefreshToken -ObjectId
This is the action that actually ends any active OWA session.
2. Review inbox rules
Get-InboxRule -Mailbox
Look for rules that forward to external domains, move items to unexpected folders, or automatically mark messages as read. Remove anything you did not create:
Remove-InboxRule -Identity
3. Audit mailbox permissions
Get-MailboxPermission -Identity
Remove any permissions granted to accounts that should not have access, including FullAccess, SendAs, and Send on Behalf.
4. Check for mailbox-level forwarding
Get-Mailbox -Identity
If this returns a value, remove it:
Set-Mailbox -Identity
5. Review folder permissions
Get-MailboxFolderPermission -Identity
Remove any grants that were not set by the mailbox owner or an approved administrator.
6. Check sent mail and recoverable items
Open the Sent Items folder and the Recoverable Items folder. Look for messages the user did not send. Attackers frequently use a compromised account to send phishing or spam, often before the compromise is detected. The account owner may not realize this happened.
7. Review Azure AD sign-in logs
Look for login events from unfamiliar locations, IPs, or devices during the suspected compromise window. Also look for sign-in activity that occurs shortly after the password reset -- that pattern indicates an active session survived the reset.
How DMARC Reports Can Surface a Compromise
One of the faster ways to detect that something unauthorized happened is to watch your DMARC aggregate reports.
A compromised account sending through Exchange Online will often produce DMARC authentication failures. If the attacker sends from IPs or servers outside the organization's SPF record, SPF alignment fails. If the From domain does not match the sending infrastructure, DKIM alignment fails as well. The aggregate report captures the sending IP, the envelope FROM, and the From domain -- enough to identify that something sent mail that was not legitimate.
DMARCFlow processes DMARC aggregate reports and surfaces authentication failures, including sudden spikes in failure volume for a specific domain. If you see DMARC failures from IPs not in your SPF record, that is a signal worth investigating. It does not tell you the account was compromised -- other explanations exist -- but it narrows the scope of the investigation.
This does not prevent a compromise. But it can surface one faster than waiting for a user to notice their sent folder contains messages they did not write.
Summary Checklist
- Revoke Azure AD refresh tokens -- kills active sessions
- Review and remove inbox rules -- removes automated forwarding and hiding rules
- Audit mailbox permissions -- removes unauthorized delegate access
- Check mailbox-level forwarding -- removes SMTP forwarding set at the mailbox level
- Review folder permissions -- removes hidden folder grants
- Check sent mail and recoverable items -- finds unauthorized sent messages
- Review sign-in logs -- identifies the scope and timing of the breach
- Monitor DMARC reports -- surfaces outbound mail anomalies that may indicate unauthorized account use