Hacked mailbox: why the new password does not lock the attacker out

On 11 October 2026 Mike Kuketz reported a case from his circle. From an acquaintance's address an urgent payment request reached his sister: he was stuck abroad and needed 850 euros. The owner reacted fast, changed the password, ended the sessions shown, switched on two-factor authentication and ran a virus scanner. When Kuketz looked at the settings the next evening, he found an active forwarding address at a provider the owner had never heard of, and a filter rule that moved messages containing the words security alert, sign-in and verification code into the archive. The password was changed, and the mailbox still delivered every new message to the attacker.

The report deserves attention because the pattern is the same in every mailbox system, and the vendors document it themselves. A password is a sign-in credential. Everything an attacker leaves behind as a setting in the account is stored independently of it. Below is the checklist Microsoft prescribes for the real thing.

What an attacker leaves in the mailbox

Microsoft's documentation on handling compromised mail accounts lists the typical signs of a takeover: a newly created forwarding rule to an external address, rules that move messages into the folders Notes, Junk Email or RSS Subscriptions, convincing signatures in sent messages, changed contact details in the global address list, frequent password changes and account lockouts. Almost every item on this list is a setting and not a sign-in.

A password change renews one credential. The settings of the account stay untouched until someone checks them one by one. (Quelle: Kuketz blog, 11 Oct 2026, and Microsoft documentation on compromised mail accounts)

Translated into objects, these are the places to check after a takeover: forwarding at mailbox level, inbox rules, additional sign-in methods and recovery addresses, app-specific passwords, OAuth permissions granted to applications and, at identity level, assigned roles. A password change deletes or disables none of them. They outlive the password with no deadline.

Microsoft 365: the password change is step one of many

Microsoft's guide for compromised mail accounts is a six-step programme, and its message is clear: changing the password alone is not enough. Step 1 for Microsoft is disabling the account until the investigation ends; if that is impossible, the password change comes next. Then, in the order of the document: revoke sessions, check sign-in methods for foreign devices, check granted application permissions, remove roles, review forwarding and inbox rules.

Two sentences from it are worth knowing. First: app passwords are explicitly not revoked on reset. The document says in so many words that users should delete existing app passwords and create new ones. Second: revoking active sessions is a command of its own, in Graph PowerShell a Revoke-MgUserSignInSession per user. Microsoft justifies it by saying that revoking sessions makes active use of stolen credentials ineffective immediately. A password change does not do that in this sense.

For session revocation there is a restriction that has applied for some years and that you need to know: Continuous Access Evaluation (CAE) treats a password change and an account lockout as critical events and enforces session revocation almost in real time. The document names a latency of up to 15 minutes via event propagation. The first CAE implementation covers Exchange, Teams and SharePoint Online, and even there only if the client negotiates CAE at sign-in. For CAE sessions Microsoft also lifts the static token lifetime, so they last up to 28 hours. A mail client that does not speak CAE therefore stays signed in after a password change for as long as its token or refresh token allows. Positive for everyday Windows use: the Primary Refresh Token document states that a PRT obtained with a password becomes invalid on a password change. The sign-in at the Windows device dies with it, while many cloud sessions only do so where CAE applies.

Google Workspace: password and sessions are two separate steps

Admin documentation for resetting a user's password has two stages: resetting the password itself and resetting the sign-in cookies. Google explains the cookie stage by saying that the user or guest can no longer sign in with the old password afterwards. Only when both are done does the document consider the user signed out of all active sessions. Anyone who only changes the password leaves the signed-in sessions running.

In return Google renews the password-bound access on reset: app-specific passwords for third-party applications, called ASPs there, are all revoked after a password reset and have to be created again. Applications that reach the mailbox over OAuth stop syncing and need a new token. The documentation points to a procedure of its own called "Automatic OAuth 2.0 token revocation upon password change".

Stalwart: the tokens die with the password, the scripts do not

The self-hosted mail server Stalwart, which we run, documents both lifetimes and revocation for OAuth tokens. The vendor's defaults: access token one hour, refresh token 30 days with a renewal window of four days, plus ID token 15 minutes, authorisation codes 10 minutes and device-flow codes half an hour. The real lever is the refresh token, and its 30 days are the number that matters.

The access token is invisible on this scale, and that is the point of revocation: the 30-day refresh token is the object an attacker needs. (Quelle: Stalwart documentation on OAuth tokens)

On revocation, the Stalwart documentation, as of 3 October 2026, says that access and refresh tokens can be revoked by changing the account password and that this invalidates every token issued before. It is available to account owners and administrators. As documented, that is more than Microsoft and Google deliver on a plain password change, but we have not measured it on our version. Settings are not touched by it: Sieve scripts for filters and redirects are mailbox configuration stored in the account and a password change leaves them alone. Kuketz's pattern applies here just the same.

What we measured on our own mail host

Measured on 12 October 2026 on our mail host: the Stalwart image stalwartlabs/stalwart:v0.16, state 0.16.25, container status healthy. Whether the documented token revocation by password change works on exactly this version we have not answered. The changelog of the last 40 releases, read through the GitHub API the same day, has no entry for this mechanism, and the documentation describes the current state without a version. We do not simulate a real takeover on the running mail server; that belongs on a test clone. Until then our checklist contains the manual Sieve and forwarding check, whether or not the tokens die anyway.

The checklist Microsoft prescribes

Anyone who wants to rehearse the real thing needs no imagination: Microsoft's documentation is the checklist. For a Microsoft 365 account, condensed:

Disable the account until the investigation is done. The Graph PowerShell command is Update-MgUser with AccountEnabled set to false.
Reset the password, strong and fresh, and never send it to the user by mail, because the attacker may well be reading that mail. With AD synchronisation this happens in the on-premises AD, and twice there, which invalidates pass-the-hash leftovers.
Delete existing app passwords; they are not revoked on reset.
Revoke sessions with Revoke-MgUserSignInSession. That invalidates the sessions and refresh tokens, the plain password change does not.
Check sign-in methods and devices and remove foreign MFA methods.
Review granted application permissions (consents) and assigned roles and clear them out.
Review forwarding and inbox rules: Get-Mailbox for the forwarding properties and Get-InboxRule -IncludeHidden for rules that stay invisible in Outlook.

For the investigation add the Entra sign-in logs, the audit log in the Defender portal with a time window before the first suspicion, and the message trace for what left the mailbox in the meantime. Which messages have already flowed out is rarely reconstructable from the mailbox itself; an archive of your own, such as a GoBD-compliant mail archive, is the only place that answers the question cleanly. A password-reset mail from this account at another service also means the attacker can keep collecting there as long as their rules run undisturbed.

How we measured and checked

We did not recreate Kuketz's case and report it from his account. The statements about Microsoft, Google and Stalwart come from vendor documents which we re-read on 16 October 2026: six steps in the Microsoft guide, 15 minutes and 28 hours in the CAE description, separate steps for password and sign-in cookies at Google, token lifetimes in the Stalwart documentation. On our mail host we read the image tag and container status on 12 October and searched the changelog of the last 40 releases through the GitHub API for an entry on token revocation. We simulated no takeover. We found no forum discussion of this case.