We’ve all been there. You notice suspicious activity on your account, panic, and immediately change your password. It’s the textbook response to a potential breach, and for good reason. But what if that frantic password reset isn’t enough?
We have already talked about session hijacking in a previous post and how it has emerged as a stealthy attack that can keep intruders inside your accounts long after you’ve locked the front door. That is because a password and an active browser session are two different things.
So what happens when you change the password after a session cookie has already been stolen?
This post answers that question and explains how session cookies function and why they persist beyond password resets, which is critical for anyone managing sensitive online identities or professional accounts.
The Anatomy of a Session Cookie
To understand why a password change often fails to stop an intruder, we must first understand what a session cookie actually is.
When you log into a service, be it Google, Facebook, or a corporate dashboard, the server verifies your password and MFA. Upon successful authentication, the server issues a "session token" or "session cookie."
This small file is stored in your browser and acts as a temporary ID card. Every time you click a new page, your browser sends this cookie back to the server. The server reads it, recognizes you as "already logged in," and grants you access without asking for your password again.
READ MORE: Cookies and Their Impact on Browser Profiles
The problem arises when an attacker steals this specific token. By importing your stolen cookie into their own browser, they can present it to the website as if they were you. Because the server only checks the validity of the cookie, not the device, the IP address, or the password, the attacker gains full, authenticated access.
Teams that share browser sessions for collaborative work face additional risk: if one member's authenticated session is compromised, shared access can become an attack path.
Google Cloud’s Mandiant team notes that stealing a valid session token can be equivalent to stealing the authenticated session itself, allowing an attacker to bypass another authentication step such as MFA.
Why doesn't changing your password always log out an attacker?
The most frustrating aspect of session hijacking is that changing your password often does nothing to invalidate an existing, active session cookie.
When you update your credentials, the authentication database gets a new hash, but the session store, the server-side record that links a session ID to your user account, often remains untouched. Unless the website explicitly destroys all active sessions upon a password change, the hijacker stays logged in.
Whether an attacker stays logged in depends on how the platform manages sessions. Some invalidate every active session after a password change, while others require users to manually sign out other devices or apply different rules to different session types.
This is why “I changed my password” does not necessarily mean “every attacker was logged out.” The correct response to a suspected account takeover is therefore broader than changing the password.
The problem is not theoretical. Verizon’s 2025 Data Breach Investigations Report analysed more than 22,000 security incidents and 12,195 confirmed breaches, finding that credential abuse accounted for 22% of initial access vectors. Mandiant also reported that stolen credentials were the second most common initial infection vector in its 2024 investigations, accounting for 16% of cases.
How Attackers Steal Your Sessions
In our article on session hijacking, we explained that there are a number of different methods that could be used. Here is a brief recap of those methods:
- Infostealer Malware: This is the most common method. Malware, often delivered via "cracked" software or phishing links, scans your browser's local storage and database files to extract session tokens for popular sites.
- Man-in-the-Middle (MitM) Attacks: On unsecured public Wi-Fi, attackers can intercept traffic. While HTTPS makes this harder, sophisticated tools can still strip away protection or trick users into accepting malicious certificates.
- Browser Extensions: Malicious or compromised browser extensions often have permission to read your cookies. If you install an untrusted extension, you may be handing your session tokens directly to an attacker.
- Physical Access: If someone gains access to your unlocked device, they can export cookies using browser developer tools or extensions. Even a few seconds of physical access can be enough.
- Session Sidejacking: This older technique involves sniffing network packets to capture cookies sent over unencrypted connections. While HTTPS has made this harder, it still works on sites that haven’t fully migrated.
How to respond if you suspect session hijacking
If you believe someone has accessed an account without permission, do not stop at changing the password.
1. Change the password
Use a new, unique password that has not been used elsewhere. This protects against continued use of the old password and reduces the risk from credential reuse.
2. Revoke active sessions
Look for settings such as Log out of all devices, Sign out everywhere, Active sessions, or Where you're logged in. This step is particularly important because it can invalidate existing browser sessions rather than simply changing the credential used to create them.
Not every service provides the same controls, so check the platform's account-security documentation.
3. Review MFA settings
Check whether an attacker added a new authentication method, recovery email address, phone number, security key, or authenticator. Changing your password is not enough if someone has modified your account's recovery or authentication settings.
4. Check the device
If the session was stolen from your computer, simply resetting the account may not solve the underlying problem. Run an appropriate malware scan, update the operating system and browser, remove suspicious extensions, and investigate anything you installed shortly before the compromise.
If an infostealer is responsible, assume that other credentials stored on the device may also have been exposed.
5. Review account activity
Look for unfamiliar logins, devices, locations, messages, transactions, API keys, connected applications, and changes to account settings. This can help establish whether the attacker merely obtained a session or actually used it.
Best Practices to Defend Your Browsing Sessions
Since changing your password is not enough, you need to adopt a "defense-in-depth" strategy:
- Use a Dedicated Browser for Sensitive Work: Never mix your casual browsing (where you download files or click random links) with your professional account management. Using an anti-detect browser like Incogniton allows you to create truly separate browsing profiles that makes it much harder for cross-site scripting or malware to access sensitive tokens.
- Force Global Logouts: If you suspect a breach, don't just change your password. Go to your account security settings and look for a button labeled "Sign out of all devices" or "Revoke active sessions." This is the only way to force the server to stop accepting the stolen cookie.
- Beware of "Free" Software: Many sessions are stolen when users download "free" tools, games, or pirated software. This is a common delivery vector for infostealer malware.
- Review Your Extensions: Periodically audit your browser extensions. If you don't use it, remove it. If it asks for excessive permissions, uninstall it immediately.
Conclusion
Session hijacking thrives on a simple but overlooked truth: your password is just the key to the front door, but the session cookie is the guest pass that lets someone wander freely inside. Changing the lock doesn’t revoke passes that are already issued. By understanding how stolen cookies survive password changes, you can move beyond reactive security and adopt proactive habits like logging out, monitoring active sessions, and leveraging tools like Incogniton.
