In the world of enterprise cybersecurity, we are obsessed with the front door. Organizations invest heavily in two-factor authentication (2FA), multi-factor authentication (MFA), hardware keys, and conditional access policies. Login screens look fortified. Compliance checklists are checked. Confidence is high.We look at our fortified login screens and pat ourselves on the back because the perimeter is secure.
But attackers aren’t trying to break down the front door anymore. They are sliding through the open window.
In 2025, the identity perimeter has shifted. It is no longer about Credentials (username and password); it is about Sessions (tokens and cookies). If an attacker steals a session token, your MFA is irrelevant. They don’t need to log in; they are already you.
The Mechanics: Hotel Keys and Valet Drivers
To understand the threat, we first need to understand the keys we are actually protecting. It’s not just your password anymore.
1. The “Hotel Key Card” (Session Cookies)
When you log into Gmail, Slack, or Microsoft 365, you do not re-enter your password for every action. After authentication, the system issues a session cookie, stored in your browser.
This cookie acts like a hotel key card:
-
It proves you already logged in
-
It unlocks resources automatically
-
It does not trigger 2FA again
If a session cookie is stolen through malware, malicious browser extensions, or endpoint compromise, the attacker inherits the session completely.
No password. No MFA. No warning.
2. The “Valet Key” (OAuth Tokens)
OAuth powers features like Sign in with Google, Sign in with Microsoft, and third-party app integrations.
Instead of sharing passwords, OAuth issues access tokens that allow apps to act on a user’s behalf. These tokens often:
-
Persist for long periods
-
Are not tied to device integrity
-
Are not re-challenged by MFA
OAuth tokens are convenient by design. They are also powerful by nature.
Attackers do not steal passwords anymore. They steal tokens.
Like When you connect a third-party app (like a calendar scheduler) to your corporate email, you are using OAuth. You give that app a “Valet Key”- a limited token that lets it park your car (read your calendar) without giving it your main car keys (your password).
The danger? Attackers are stealing the Key Cards and Valet Keys.
Where Two-Factor Authentication (2FA) Fits and Where It Fails
Two-factor authentication is an essential control. It prevents simple credential theft and blocks many automated attacks.
However, 2FA only protects the login event.
Once authentication succeeds:
-
Session cookies are issued
-
OAuth tokens are minted
-
Trust is assumed to persist
If an attacker steals a valid session or token, they do not trigger 2FA again. The system assumes authentication already happened.
This is why many breaches occur after login, not during it.
2FA is necessary. But it is not sufficient on its own.
The Attack: Token Theft & Shadow Integrations
“Pass-the-Hash” is dead. Long live “Pass-the-Cookie.”
In a Token Replay attack, a hacker doesn’t need to guess your password. They simply deploy malware (often via a simple phishing link) to scrape your browser’s local storage. They steal the “Hotel Key Card” (the active session cookie) and import it into their own browser.
The result is terrifyingly simple:
-
No Password Required: The attacker is now logged in as you.
-
No MFA Prompt: The system sees a valid cookie and assumes MFA was already passed.
-
SaaS-to-SaaS Lateral Movement: Once inside, they use OAuth to install malicious apps (“Shadow Integrations”). They might grant a rogue application permission to “Read All Files” on your Google Drive. Even if you change your password later, that rogue app still holds the Valet Key. It stays connected, silently siphoning data.
When the Front Door Fails: The “MFA Fatigue” Nightmare
Even when attackers do try the front door, they have found a psychological loophole to bypass the technology. This is called MFA Fatigue (or “MFA Bombing”), and it specifically targets push-notification systems like Duo Push or other common systems
The tactic is brutal in its simplicity. The attacker, holding your compromised username and password, triggers a login request.
-
You get a notification on your phone: “Login Request: Approve?” You deny it.
-
They send another. And another. And another.
-
At 3:00 AM, frustrated, half-asleep, or confused, the user finally hits “Approve” just to make the phone stop buzzing.
Game over. The attacker is in.
Other Common MFA Abuse Examples
Microsoft Authenticator and Okta Verify Both rely on push approvals by default. Without number matching, attackers can overwhelm users with requests until one is approved.
SMS-based OTP Attackers use SIM swapping or social engineering to intercept one-time passcodes. Once the code is entered, access is granted.
Email-based OTP If an email inbox is already compromised, OTP emails offer no protection at all.
In all cases, the weakness is the same. Authentication trusts user intent, not user certainty.
Real-World Case Study: The Uber Hack (Lapsus$)
This isn’t theoretical. In September 2022, the hacking group Lapsus$ breached Uber using exactly these techniques, proving that a multimillion-dollar security budget can be defeated by a $10 dark web purchase.
The Timeline of the Breach:
-
The Entry: Attackers purchased a contractor’s stolen credentials on the dark web.
-
The Block: They attempted to log in but were stopped by MFA.
-
The Bypass: They spammed the contractor with Duo Push requests for over an hour.
-
The Social Engineering: The attacker contacted the contractor on WhatsApp, pretending to be “IT Support,” claiming the notifications would stop if they just accepted one.
-
The Fallout: The contractor hit “Approve.” Lapsus$ gained VPN access, scanned the intranet for secrets, found hardcoded admin credentials, and took over the company’s AWS, Google Cloud, and Slack instances.
The GiSax Perspective: Identity Is a Continuous System
At gisax.io, identity is treated as infrastructure, not a feature.
Modern environments are shaped by:
-
OAuth tokens
-
session cookies
-
non-human identities
-
automation and AI agents
The real challenge is ensuring that trust does not persist when context changes.
Secure systems must:
-
Continuously evaluate session legitimacy
-
Detect abnormal token behavior
-
Surface shadow integrations
-
Re-challenge identity when risk increases
This shift from authentication to continuous identity governance is foundational for modern SaaS security.
Conclusion: Stop Guarding the Door, Start Watching the House
If your security strategy stops at the login prompt, you are fighting the last war.
We must shift our focus from Authentication (proving who you are) to Continuous Validation (proving you should still be here).
-
Kill the Sessions: We must shorten session lifetimes. A stolen cookie should be useless in 60 minutes, not 60 days.
-
Audit the Valets: Regularly audit all OAuth applications connected to your corporate environment. Revoke access for any “Shadow Integrations” you don’t recognize.
-
Harden the MFA: Switch from simple “Approve/Deny” push notifications to Number Matching (where the user must type a code displayed on the screen). This kills MFA fatigue instantly.
You locked the front door. Now, go check the windows.
FAQs
1. What is OAuth in simple terms?
OAuth allows an application to access your account without sharing your password.
2. What is SaaS-to-SaaS lateral movement?
It is when attackers move between connected cloud applications using stolen tokens instead of passwords.
3. Why does MFA not stop token theft?
MFA protects login attempts, but it does not re-check identity once a session token is active.
4. What is a session cookie?
A session cookie is a small file stored in your browser that proves you are already logged in.
5. What is a shadow integration?
A shadow integration is a third-party app connected via OAuth that is not fully reviewed or monitored by security teams.
6. Can attackers access systems without knowing the password?
Yes. If they steal a valid session token, they can act as the user without logging in again.
7. What is MFA fatigue?
MFA fatigue is when attackers spam push notifications until a user accidentally approves one.
8. Are Sign in with Google and Microsoft unsafe?
No, but they must be governed properly. The risk comes from unmanaged tokens, not the login method itself.
9. What is a token replay attack?
A token replay attack occurs when an attacker steals a valid OAuth token or session cookie and reuses it to impersonate a user.
10. How do attackers steal OAuth tokens?
Through browser malware, malicious extensions, phishing links, compromised endpoints, or insecure local storage access.
11. Why are OAuth tokens dangerous in SaaS environments?
Because they often remain valid for long periods and are not challenged by MFA after issuance.
12. What are non-human identities in SaaS security?
Non-human identities include service accounts, API keys, automation bots, and OAuth applications that act without human interaction.
13. How does token lifetime affect security risk?
Long-lived tokens increase the window of opportunity for attackers to replay stolen credentials.
14. What is the difference between authentication and session validation?
Authentication verifies who you are at login. Session validation ensures you should still have access afterward.
15. How can organizations reduce OAuth risk?
By shortening token lifetimes, auditing OAuth permissions, monitoring token behavior, and enforcing step-up authentication on sensitive actions.
16. Why is number matching better than push-based MFA?
Number matching requires user intent and prevents approval through fatigue or accidental taps.