You’ve done everything you were told to do.
Your password is strong. You don’t reuse it. You turned on Multi-Factor Authentication (MFA). Maybe you even set up a modern passkey.
So when you see a login notification you don’t recognise, the first question is obvious:
But what if they didn’t?
What if your password was never cracked, your MFA code was never guessed, and the attacker never actually logged in the way you normally would?
There’s another possibility that doesn’t get talked about nearly enough:
And to understand why that matters, we need to look at what happens after you successfully log in.
Let's say you're signing into your email.
You enter your password. Your phone asks you to approve the login. You approve it. Done.
But your email provider can't ask you to repeat that entire verification ceremony every time you click another message, refresh the inbox, or open an attachment. So once you've proved who you are, the service creates a session.
That session is basically how the website remembers:
“This person has already authenticated. Let them continue.”
Usually, your browser carries information associated with that session, often through a session cookie.
The Open Web Application Security Project (OWASP) formally describes session management as the mechanism that allows a web application to associate multiple sequential requests with the same authenticated user.
So the actual login lifecycle is really closer to this:
That final part is critical.
Because if an attacker can obtain a usable authenticated session, they may not need to start again at the password screen.
Think of checking into a hotel. Reception inspects your booking and government ID, then hands you an electronic key card. You don't show your passport every time you return to your room or step into the elevator. You swipe the card because the identity check has already taken place.
Your browser's session works on the exact same principle. And attackers know that.
This is where things get interesting.
Multi-Factor Authentication is still one of the best defenses you can add to an account. If somebody steals your password from an old breach and attempts to log in from across the world, that second factor can stop them in their tracks.
But MFA mainly protects the authentication process.
A session exists after you've completed that process.
One technique that takes full advantage of this gap is called Adversary-in-the-Middle phishing, or AiTM.
Imagine you receive an email saying an urgent financial document has been shared with you.
At that point, most of us would assume everything must be legitimate. After all, Microsoft asked for MFA, your app pinged you, and you verified it.
But an attacker can place phishing infrastructure between you and the real service.
Your credentials are forwarded directly to the legitimate service. The real service asks for MFA. You complete it. Authentication succeeds. The attacker doesn't care about intercepting your temporary 6-digit code—they are interested in what happens immediately next: the authenticated session.
A simplified version looks like this:
Microsoft documented this exact operational pattern in a campaign that attempted to target more than 10,000 organisations. The attackers intercepted credentials and session cookies, allowing them to bypass MFA and subsequently use compromised mailboxes for Business Email Compromise (BEC) financial fraud (Microsoft's investigation into AiTM phishing and cookie theft).
The important point isn't that MFA somehow became useless.
It's almost the opposite:
Now imagine you never clicked a phishing link.
Your password was never entered anywhere suspicious. You still aren't necessarily completely safe from session theft.
Another common route is infostealer malware.
An infostealer (such as Lumma, RedLine, or Vidar) is lightweight malware designed to harvest valuable information directly from an infected computer. Browsers are extraordinarily attractive targets because they hold open doors to virtually our entire digital existence:
And many of those accounts are already logged in.
Instead of asking: “How can I convince this person to give me their password?”, an attacker can simply extract information that is already stored or maintained on the compromised machine.
Google has specifically cited malware stealing authentication cookies from local browser storage as one of the primary motivations behind its work on stronger, device-bound sessions (Google Security on cookie theft and Device Bound Session Credentials).
This is a fundamental shift in how we think about account security:
This is probably something most of us don't think about enough.
How many browser extensions do you have installed right now?
Maybe an ad blocker. A screenshot tool. A grammar checker. A VPN. A shopping coupon finder. An AI assistant. And perhaps a productivity timer you installed six months ago and completely forgot about.
Extensions aren't automatically dangerous. Most are installed because they are genuinely useful.
But they are still software running inside one of the most sensitive applications on your computer.
Some extensions need permissions such as activeTab, scripting, or storage simply to provide their normal features. That creates an interesting security dilemma: a permission isn't automatically suspicious just because it's powerful.
The better question is:
A screenshot extension interacting with the web page you're viewing makes sense. A basic calculator wanting broad access to read and change data on all websites is much harder to justify.
And there's another problem: a malicious extension doesn't necessarily look broken.
A timer can still count down from 25 minutes. A to-do list can still save your tasks. The visible feature can work perfectly while something very different happens behind the scenes.
That's why “it works” and “I downloaded it from an official extension store” shouldn't be our only tests of trust.
At this point, it's worth understanding what a browser cookie actually does.
Cookies aren't malware. They're a normal, essential part of the modern web.
When you log into an application, the server generates a unique session token and tells your browser to store it as a cookie. Every time you navigate to another page on that domain, your browser sends that cookie back in the HTTP headers, allowing the application to recognise your session.
Developers can—and should—add defensive flags to sensitive cookies:
HttpOnly: Prevents client-side JavaScript (like scripts injected via XSS) from reading the cookie directly.Secure: Restricts transmission of the cookie strictly to encrypted HTTPS connections.SameSite: Controls whether the cookie is sent along with cross-site requests, mitigating Cross-Site Request Forgery (CSRF).Those controls matter immensely. But none of them means: “This session can never be stolen.”
Different controls protect against different threat vectors. For example, HttpOnly stops a malicious script in the browser tab from reading document.cookie, but it does nothing to stop malware running on the operating system from reading the SQLite database file where Chrome or Edge stores cookies.
That's why OWASP recommends multiple complementary layers of session protection, including secure cookie flags, appropriate expiration intervals, automatic session rotation, and re-authentication for sensitive actions (OWASP Session Management Cheat Sheet).
There are even more subtle architectural problems involving how cookies are scoped to domains and paths.
This was one of the more interesting technical concepts in the research behind this episode.
Cookies don't just have names and values; they also have scoping rules that determine where they are valid.
Imagine a company operates multiple subdomains:
Depending on how cookies and domain scopes are configured, applications need to be very careful about which cookie they are trusting and where it originated. Related techniques such as cookie tossing or cookie shadowing can exploit weaknesses when a less secure subdomain sets a cookie that overwrites or interferes with a cookie on the primary authenticated domain.
There is also session fixation. Instead of stealing your session after you log in, an attacker tries to establish or influence a session identifier before authentication. If the application continues using that exact same session identifier after you successfully log in, the attacker may already know the token associated with your now-authenticated session.
That is why secure applications must always rotate session identifiers whenever a user's privilege level changes (such as completing login).
This isn't something an ordinary user is expected to fix—it is a developer and platform architecture problem. But it shows just how much security happens quietly after you press Sign in.
Let's say you realise you've fallen for a phishing page.
You immediately change your password. Good. That's exactly something you should do.
But don't stop there.
If the incident involved an authenticated session, you also want to deal with that session. Depending on the service, changing a password does not always terminate active session tokens held on other machines.
Go directly to the account settings and check:
Why check inbox rules? Because an attacker doesn't always want to announce that they've compromised your account. Quiet access can be far more valuable.
They may watch financial correspondence, monitor contract negotiations, wait for payment instructions, or create hidden rules that divert alerts. Microsoft has documented compromised accounts being used for follow-on phishing and Business Email Compromise, emphasizing that session revocation is an indispensable part of incident response (Microsoft's multi-stage AiTM phishing investigation).
After any serious phishing encounter, think beyond: “I changed my password.”
Think: Password changed + sessions revoked + devices audited + MFA verified + connected apps pruned + email rules checked.
And if it's a work account, notify your IT or security team immediately.
This is where the industry is starting to make real progress.
The fundamental flaw of traditional session cookies is that they are bearer tokens: whoever holds the token can present it to the server and be accepted as the legitimate user. If an attacker copies the cookie string to another computer, the server often can't tell the difference.
So researchers and browser vendors have been developing ways to tie sessions cryptographically to the physical device where they were created.
The leading approach is called Device Bound Session Credentials, or DBSC.
The name sounds intimidating, but the concept is straightforward:
Instead of the server only asking: “Do you possess the correct session cookie?”, it also requires cryptographic proof generated by a private key locked inside the device's secure hardware (such as a TPM).
Even if malware manages to dump the cookie from your disk, that cookie is useless on the attacker's machine without the hardware-protected key. The World Wide Web Consortium (W3C) has been developing DBSC as an open web standard specifically designed to neutralize cookie theft hijacking.
It won't solve every single account takeover vector. Nothing does.
But it represents an indispensable evolution in defense:
You don't need to start inspecting raw HTTP headers or decrypting SQLite databases. The practical defensive habits are much simpler:
Diagnose how sessions get compromised and walk through the exact steps to audit and evict unauthorized access across your accounts:
Select a session threat vector to understand the mechanism and execute the eviction checklist:
We used to think about account security almost entirely like this:
Then we added MFA. Now passkeys are improving authentication even further.
But the complete security lifecycle is closer to:
Attackers don't have to break down every single door. They only need to find one layer that works.
That is the constant cycle of cybersecurity.
So if someone gains unauthorized access to an account protected by MFA, don't immediately assume they somehow cracked the encryption or guessed your code. Maybe they didn't. Maybe your password wasn't hacked either.
Maybe you authenticated successfully. Your MFA worked. The website trusted you. And then the attacker targeted the proof that all of those checks had already happened:
That's why protecting an account doesn't end when you press Sign in. In modern web security, that's only half the story.
The threat analysis, technical mechanics, and defense architectures cited in this episode are grounded in documentation from Microsoft Threat Intelligence, Google Security, the W3C standards group, and OWASP:
Have a question or a suggestion? Prepare an email below. Feedback is private and is sent only when you press Send in your email app.
Likes and claps are your personal reactions on this device.
You can also email Poorna directly.
Your feedback stays private. Nothing is sent from this page automatically.
I started Cyber Insight because everywhere online people only talk about cybersecurity in technical terms — and most people are left without a proper understanding of how the digital world works. I work in cybersecurity, but I write here for everyone. No jargon. Just clear, honest explanations.