Users often discover unauthorized access to their email, change the password, enable two-factor authentication, and assume the threat is over. Within days or weeks, however, messages continue to be read and forwarded, revealing that the attacker never relied on the password alone.
Password verification occurs only once during login. After that, the service issues a persistent credential such as a session cookie in the browser or a refresh token in a mail client. These tokens allow continued access without re-entering the password, and a password change does not automatically revoke them.
Attackers commonly retain the following footholds:
- Active sessions – browser cookies stolen by infostealers that bypass password knowledge entirely.
- Application tokens – OAuth grants issued to third-party apps that continue working after the main password reset.
- App passwords – legacy credentials created for older clients that ignore two-factor authentication and survive password changes.
- Mail rules and forwarding – automatic redirection of incoming messages to attacker-controlled addresses or rules that archive replies during business-email-compromise schemes.
- Recovery data – substituted backup email addresses, phone numbers, or recovery codes that let the attacker regain entry later.
- Delegation – explicit sharing permissions granted inside the mail service that password changes do not affect.
Google users should review myaccount.google.com/device-activity, myaccount.google.com/permissions, and myaccount.google.com/apppasswords, then check Gmail settings for forwarding, delegation, and filters. Yandex offers equivalent controls under the security section of id.yandex.ru. Microsoft accounts are managed at account.microsoft.com/security.
In corporate Microsoft 365 environments, administrators can run Revoke-MgUserSignInSession via Microsoft Graph to terminate refresh tokens, although short-lived access tokens may remain valid for roughly one hour. Additional PowerShell queries detect forwarding rules and OAuth consents with scopes such as Mail.Read and offline_access.
The correct remediation order is: first revoke all sessions and tokens, then change the password to a completely new value, review and reset multi-factor methods, update recovery information, and finally audit rules and connected applications. Performing these steps in the wrong sequence allows the attacker to re-establish persistence before the account is fully secured.
