Account Takeover: Sessions, Tokens and Password Resets

Account Takeover Basics

Account takeover (ATO) happens when an attacker gains control of an account and uses it to read data, change settings, or move money. The attacker’s path often falls into three buckets: credential theft, session hijacking, and recovery abuse. Credential theft includes phishing, credential stuffing, and malware that captures passwords. Session hijacking targets the “logged-in” state, which can persist even after a password changes. Recovery abuse targets password reset and account recovery workflows, sometimes by manipulating the victim’s access to email or phone.

Sessions and tokens are the technical glue behind “staying logged in.” A session is a server-side record or a client-side cookie that marks a browser or app as authenticated. A token is a signed or encrypted credential that proves identity to services without re-entering a password. When attackers steal either, they can keep access while the victim resets a password. I noticed this pattern in incident write-ups from security teams: the password reset completes, yet the attacker’s session remains active until the service revokes it.

Main Problems And Pain Points

People often treat password resets as a universal fix, then stop checking. Many services do revoke sessions after a password change, but not all flows do it consistently across devices, apps, and third-party integrations. Some systems keep long-lived refresh tokens for mobile apps, and those tokens can survive a password reset if the service does not invalidate them.

Another common mistake is assuming that “logged in from a new device” alerts are enough. Attackers can use automation to create realistic browser fingerprints, or they can reuse stolen sessions from the victim’s own device. If the attacker already has a valid session cookie, the login alert may never trigger because the session never “logs in” again.

ATO also depends on supporting technologies that victims rarely see. Email and SMS delivery are frequent weak points because reset links route through them. Browser storage matters too: cookies, local storage, and cached authentication can keep access alive. On the backend, identity systems may use OAuth 2.0 and OpenID Connect, where access tokens and refresh tokens have different lifetimes and revocation behavior. If a service issues a refresh token with a long expiration and does not revoke it on recovery events, the attacker can continue to request new access tokens.

Finally, many users underestimate credential stuffing. Attackers test leaked username-password pairs across many sites, then pivot when a login succeeds. Even strong passwords fail when the same password appears in multiple breaches. The dependency here is not just the password; it is the password reuse pattern across services.

Solutions And Advice

Revoke Sessions, Not Just Passwords

After any suspicious activity, check for a “sign out of all devices,” “revoke sessions,” or “manage active sessions” option in the account settings. If the service offers it, use it immediately after changing the password. If the service does not offer a one-click revocation, sign out from the web session and remove the app’s stored credentials, then reinstall the app if it keeps tokens in a persistent store.

Look for session-specific controls such as “active sessions,” “logged-in devices,” or “recent activity.” A realistic outcome to aim for is reducing the attacker’s ability to keep using a stolen session cookie. In practice, you want the service to invalidate both access tokens and refresh tokens; access tokens expire quickly, but refresh tokens can keep the attacker going for days or weeks depending on the provider’s policy.

As an aside, some providers show session lists with timestamps down to the minute, which helps you correlate with the moment you noticed the issue. If you see a session created after your password change, the service likely did not revoke refresh tokens for that session.

Harden Recovery Channels

Secure the email and phone number used for resets before you touch the main account. Change the email password first, then review email account recovery settings, including secondary addresses and forwarding rules. Attackers often set up forwarding or add new recovery methods so that reset links arrive to them, not you.

For SMS-based recovery, verify whether the provider supports number change delays or additional verification steps. Some services add friction for SIM swap risk, but many do not. If you can, enable account-level protections like authenticator apps or security keys rather than relying on SMS.

In my experience reviewing common ATO timelines, the fastest recovery comes from locking down the inbox and then redoing the main account recovery. If you reset the main account first while the inbox remains compromised, the attacker can often repeat the cycle.

Use Strong Authentication With Limits

Move from SMS codes to an authenticator app or a hardware security key when the service supports it. Authenticator apps reduce exposure to SIM swap attacks, while security keys reduce exposure to phishing when the service supports FIDO2/WebAuthn. If you use an authenticator app, store backup codes offline; many accounts generate backup codes once, and users lose them by saving only to a phone.

Enable multi-factor authentication on the email account first, then on the target account. A realistic outcome is fewer successful logins after credential theft because the attacker still needs a second factor. The limitation is that some recovery flows can bypass MFA if the attacker controls the recovery channel, which is why recovery-channel hardening matters.

Also check for third-party app connections. OAuth integrations can retain access even after you change your password. Remove apps you do not recognize, then watch for reauthorization attempts.

Monitor, Triage, and Document

After you lock things down, review account activity logs for changes to email, phone, password, security settings, and payment methods. If the service offers a “download activity report,” save it for support. Document the approximate time you noticed the issue and the time you changed passwords, because support teams often ask for a timeline.

Contact the service’s fraud or security team if you see money movement, new payees, or repeated login attempts. For financial accounts, also contact your bank or card issuer. Many issuers can freeze transfers or reverse certain transactions, but the window depends on the payment rail and how quickly you report.

For email providers, check rules/filters and “forwarding” settings. I once saw an incident where the victim changed the password, yet the attacker’s forwarding rule remained, so reset emails continued to reach the attacker’s mailbox.

Case Examples

Session Hijack After Password Reset

A user notices a login alert for their email account from a location they do not recognize. They change the email password, then stop because the alerts stop. Two days later, they find a new “sent” message and a changed recovery phone number. The service’s settings show that the attacker’s session remained active until the user revoked sessions from the “active devices” page.

Lesson: password resets can fail to terminate existing sessions. The fix is to revoke sessions, remove unknown recovery methods, and secure the inbox so reset links cannot be intercepted.

Recovery Abuse Through Inbox Forwarding

A user receives a message that their bank account password was changed. They try to reset the bank password, but the reset link never works. After regaining control of their email, they discover forwarding was enabled to an attacker-controlled address and a new recovery email was added. Once they removed forwarding and restored the email account’s security settings, the bank reset flow worked and the account stopped showing new changes.

Lesson: recovery flows route through email or phone. Securing the recovery channel first prevents the attacker from receiving reset links and repeating the takeover.

Comparison Table For Response

Common Mistakes

Resetting only the password without revoking sessions leaves a gap for attackers who already have a valid cookie or refresh token. Users often miss the “active sessions” page because it sits under security settings and looks like a minor detail.

Another mistake is changing the password while the inbox still has forwarding rules or an attacker-controlled recovery method. Reset links then keep arriving to the attacker, and the attacker can reapply changes faster than the victim can notice.

Users also reuse old passwords across accounts. If the attacker obtained one password from a breach, password reuse turns a single incident into multiple takeovers. A password manager with unique passwords reduces this risk, but the key is that the manager’s master password must remain protected.

Finally, people sometimes ignore connected apps. OAuth integrations can keep access to data even after a password change. Removing unknown apps and checking token grants in the account’s “connected services” section closes that path.

FAQ

Do Password Resets Kill Sessions?

Some services revoke sessions and refresh tokens after a password change, but others do not across all devices and app sessions. Check the account’s “active sessions” or “sign out of all devices” control after resetting.

What Is A Refresh Token?

A refresh token is a credential that lets a client obtain new access tokens without re-entering a password. Its lifetime and revocation behavior vary by provider, which is why attackers can persist after a password reset.

How Can An Attacker Hijack A Session?

Attackers can steal session cookies through malware, browser compromise, or phishing that captures authentication data. If the stolen session remains valid, the attacker can act without triggering a new login.

Why Do Reset Links Fail?

Reset links can fail when the recovery channel is compromised, when the account has rate limits, or when the attacker changed the recovery email or phone. Securing the inbox first often resolves the loop.

Should I Contact My Bank Immediately?

Contact your bank or card issuer as soon as you see unauthorized transfers, new payees, or changes to payment methods. Reporting speed affects what can be reversed and which fraud protections apply.

Author's Insight

Account takeover response works best when you treat authentication as layers: password, sessions, tokens, and recovery channels. Password changes address credential-based access, while session revocation addresses cookie and refresh-token persistence. Recovery-channel hardening addresses the reset loop that attackers use to regain control. When services expose controls like active sessions, connected apps, and recovery settings, those controls map directly to the technical failure modes behind ATO.

For readers who want a practical starting point, the safest order is: secure the email/phone used for resets, change the target password, revoke active sessions, then remove unknown connected apps. If you see continued activity after these steps, the incident likely involves deeper compromise or a service-side session policy that did not revoke tokens.

Key Takeaways

• Change passwords, then revoke active sessions; password resets alone often do not terminate stolen sessions.
• Secure the recovery inbox and phone first to stop reset-link interception and forwarding rules.
• Review connected apps and OAuth authorizations; token grants can persist after password changes.
• Document a timeline and check activity logs for security setting changes, not just login alerts.
• Use MFA with an authenticator app or security key when available, and store backup codes offline.