You found out your account was compromised. You changed your password immediately — the right instinct. You felt like you’d closed the door.
But the attacker was already inside. Not logging in. Already logged in. Right now, while you reset your password, they’re in your inbox reading your messages. Your password change did nothing to them, because they don’t need your password anymore.
This is session hijacking — and it’s the attack most people don’t know to defend against.
Changing your password didn’t log them out
When you log into a website, the server doesn’t ask for your password on every page you visit. It can’t — that would be unbearable to use. Instead, it hands you a session token: a long, random string stored as a cookie in your browser. Every subsequent request you make sends that token. The server sees the token and says: that’s a valid logged-in user, let them through.
Your password is used once, at login. The session token handles everything after.
If an attacker steals your session token, they have what the server actually checks. They paste it into their browser, and from the server’s perspective, they are you — authenticated, trusted, and already in. They didn’t use your password to get there. Changing your password doesn’t expire their token. It doesn’t trigger a logout on their end.
They stay in until the session token expires on its own — which, on most services, takes days or weeks.
What a session token is
A session token is just a string of characters. Something like a 128-character random hex value. It has no embedded information about who you are, what your password is, or where you’re logging in from. It’s an opaque key that unlocks a specific logged-in state on the server.
Browsers store these tokens as cookies — small files tied to a specific domain. When you visit Gmail, your browser sends your Google session cookie automatically with every request. Google’s servers read it, verify it against their session database, and return your email.
Steal the cookie; impersonate the user. It’s that direct.
Modern web security adds some protection. The HttpOnly flag prevents JavaScript from reading a cookie (blocking some types of theft). The Secure flag ensures the cookie only travels over encrypted HTTPS connections. The SameSite attribute limits which cross-site requests can include the cookie. These help — but they don’t cover all the attack vectors attackers actually use.
How session tokens get stolen
Info-stealer malware is the dominant threat. This is purpose-built software, such as RedLine Stealer, Vidar, and Raccoon Stealer, designed specifically to harvest browser cookies, saved passwords, and session tokens from your local machine.
These tools are not exotic. RedLine Stealer is available as a subscription service for $150–$200. It targets Chrome, Firefox, Edge, and major desktop applications. It dumps your browser’s cookie store, packages everything into a “log,” and sends it to the attacker. The attacker then either uses your active sessions directly or sells the log on a dark web marketplace.
How does malware like this reach your machine? Cracked software downloads. Malicious ads that trigger drive-by downloads. Phishing emails with infected attachments. Pirated games. It lands on machines constantly, in volume, often without any visible sign.
Cross-site scripting (XSS) is a vulnerability in a website itself — not in your machine. If an attacker finds a way to inject JavaScript into a page you visit, that script can read your cookies for that domain and send them to an attacker-controlled server. The attack runs in your browser, silently, while you browse a legitimate site that has a security flaw.
Man-in-the-browser attacks use malware that sits inside your browser and intercepts or modifies traffic in real time. It reads session tokens as they travel, or alters transactions before the request leaves your machine, for example by changing a bank transfer destination.
The info-stealer ecosystem
RedLine, Vidar, and Raccoon Stealer aren’t niche tools. They’ve infected millions of machines. The credentials and session tokens they harvest are sold in bulk on dark web marketplaces. Logs with active Google, Facebook, or bank sessions sell for $5–$50 each, depending on the account’s apparent value.
This is a scaled criminal marketplace. Sellers advertise fresh logs with filter options: country, browser, account types. Buyers purchase in bulk, sort for high-value sessions, and use them before the sessions expire. The pipeline runs continuously — new infections, new logs, new sales.
In 2022, this ecosystem enabled some of the year’s most significant breaches. The Lapsus$ group — responsible for compromising Microsoft, Nvidia, Samsung, and Okta — obtained session tokens from criminal marketplaces and underground forums. They didn’t break into secure systems through advanced technical exploits. They bought access that had already been harvested from compromised machines.
The Uber breach the same year used a contractor’s credentials plus aggressive social engineering to bypass MFA. An attacker spammed the contractor with MFA push notifications until, overwhelmed, they accepted one. Session access followed. The lesson isn’t just about MFA design — it’s that once a session is established, it’s a high-value target.
Real attacks using stolen sessions
The 2022 Uber breach is the clearest public example of how session-level access works in practice. Attackers got a contractor’s VPN credentials (possibly from a stealer log or credential market), then used social engineering to get past MFA. Once inside, they moved through internal systems using the legitimate session — Uber’s security tools saw an authenticated session from a known contractor, not an intruder.
Lapsus$ showed this scaled: they compromised Okta’s support systems using a session obtained through a third-party contractor. Okta serves thousands of businesses. One stolen session, correctly placed, gave access to tools that touched many of them.
Neither attack required breaking encryption or bypassing firewalls. Both used stolen or socially-engineered session access to impersonate legitimate users.
Session hijacking isn’t a theoretical attack. It’s how major breaches actually happen.
How to fully revoke sessions
When you suspect your account has been compromised — or after any known breach involving your credentials — you need to invalidate all active sessions, not just change your password.
Every major service has this capability. Most people don’t know it exists.
Google: Go to myaccount.google.com, then Security > Your devices > Manage all devices. You can sign out of each device individually. Also check Security > Recent security activity for sessions you don’t recognise. Signing out all devices invalidates their session tokens — the next access requires a fresh login with your new password.
Facebook: Settings > Security and Login > Where You’re Logged In. You’ll see a list of active sessions with device type and location. Select any unrecognised session and remove it. There’s also a “Log Out of All Sessions” option that clears everything at once.
Apple ID: Go to appleid.apple.com, scroll to the Devices section. You’ll see every device signed in with your Apple ID. Remove any you don’t recognise — this revokes their session.
For any account: after revoking sessions, check for persistent access that survives a session revocation. In Gmail, check Settings > Forwarding and POP/IMAP for any forwarding rules an attacker may have set up to keep receiving your email after you log them out. Check Settings > Linked accounts or Apps with access for any third-party authorisations an attacker granted themselves.
Session revocation ends their current access. But if they set up forwarding or authorised a connected app, they’ve created a backdoor that outlasts the session. Check both.
What you can do right now
Want to see what data brokers expose about you? See what a scan finds → shows an example report: the kinds of sites that list your name, phone, and address. Once KnytX Shield launches it will find and remove these automatically. Join the waitlist to get in early.