There is a phrase I hear often when I review how identity is set up at a company: “we have two-factor authentication.” It is almost always true. It is almost never enough.
The two-factor authentication protects one very specific moment: the moment someone identifies themselves. You approve the notification, and the service hands you a session token. That token is the real key. As long as it is alive, whoever holds it is you. No password, no code, no questions.
They no longer steal your password; they steal your session
MITRE has cataloged it for years as Steal Web Session Cookie, and there are two paths I see over and over again.
The first is an infostealer on the device. An installer downloaded from a sponsored result, a browser extension, a file that arrived through chat. The program does not even bother with passwords: it copies the browser's cookie store and sends it out. That includes the sessions for email, the CRM, the cloud console and everything else you left open.
The second is a proxy in the middle: a cloned sign-in page that forwards what you type to the real site in real time. You see the usual screen, genuinely approve your second factor and genuinely sign in. The intermediary keeps the cookie the service has just issued.
The uncomfortable part is this: the token does not know it has changed hands. It was issued correctly, after a legitimate authentication, to a legitimate user. Technically, there is nothing to dispute.
Why is fatigue an attack technique?
The other door is even simpler and requires no malware. It is called Multi-Factor Authentication Request Generation, although in practice everyone knows it as fatigue or bombing.
The attacker already has the password, usually from an old leak that nobody rotated. The only thing missing is the second factor, so they request it. Once, ten times, fifty times, at three in the morning. And at some point someone accepts just to make the phone stop ringing.
There is no vulnerability to patch here. The system asked what it had to ask, and the user said yes. That is why the formats that give way most often are precisely the two most convenient ones: the SMS code and the approve-or-deny notification.
The 44,791 tokens someone posted on Telegram
In August, a 7 GB dump of data stolen from 5,871 machines in 162 countries appeared on Telegram. Okta analyzed it and found 44,791 unique JWT tokens. Of those, 1,843 were still valid on the day the file was made public, plus 24 API keys that still worked.
One detail I find worse than the figures: 17.7% of those tokens carried personal data in plain text inside the token itself. Name, email, phone number. They did not even need to be used for there to be a leak.
What really worries me are the identities that are not people
This is where it intersects with my daily work. That same dump contained hundreds of tokens for artificial intelligence services and keys for model providers.
A service account has no phone, and an automated agent does not receive notifications about anything. These are credentials that live for months, sometimes years, with broad permissions because that was the fastest way to get the integration working. When someone walks off with one of them, there is no second factor to check: there is a process that keeps working, punctual and silent, for another owner.
Every automation we add is one more key. It is worth counting them, because usually nobody looks at them until they are needed. That, put in order, is what is called identity and access management.
What is left when authentication no longer has a say?
If the attacker gets in with a valid session, authentication has nothing to say. The only defense left is noticing that the session behaves differently: the same token appearing from a different internet provider, two impossible locations within twenty minutes, a mass mailbox download on a Sunday night.
That is no longer identity work; it is detection work. It is what is done by a SOC monitoring 24/7, and it is the reason why Zero Trust insists that no session is trusted forever.
In practical terms, four things change the outcome. Moving to security keys or passkeys, which cannot be relayed to a proxy. Shortening token lifetimes and binding them to the device that requested them. Monitoring the endpoint with EDR, because the cookie store lives there, not in the cloud. And reviewing machine credentials, the ones nobody remembers creating.
There is one more, and it is the one almost always forgotten when something seems off: changing the password does not close the stolen session. The session has to be revoked. They are two different buttons, and the second one is the one that matters.
If you want to know how exposed you are, start by looking at which sessions and keys are still alive right now. We review this in the free security assessment.
Two-factor authentication did not fail. It correctly answered the question it was supposed to ask. The problem is that the attacker stopped asking that question.
