Darja Rihla

Tag: mfa

  • Why MFA Doesn’t Stop Phishing: 7 Critical Weaknesses in Modern Identity Security

    Why MFA Doesn’t Stop Phishing: 7 Critical Weaknesses in Modern Identity Security

    Why MFA doesn’t stop phishing becomes clear when you understand how attackers target sessions instead of passwords.

    Intro

    Why MFA doesn’t stop phishing is one of the most misunderstood problems in modern cybersecurity.

    Most security teams still operate under an outdated assumption:

    password + MFA = secure account

    That model no longer matches how modern identity attacks work.

    MFA still helps against credential stuffing, password reuse, and basic account takeover. But attackers have adapted. They no longer need to defeat authentication in the old sense. Increasingly, they target the user during the login flow, the session after the login flow, or the trust model surrounding both.

    The result is simple but uncomfortable:

    MFA often protects the login challenge, not the authenticated state that follows it.

    That distinction matters because the real asset in modern cloud environments is no longer just the password. It is the authenticated session: the token, the cookie, the trusted state that survives after the prompt is gone.

    If your security model stops at “MFA enabled,” you are defending the wrong layer.

    This is exactly why MFA doesn’t stop phishing in many real-world attacks.

    The diagram below shows exactly how modern phishing bypasses MFA by targeting the session layer.

    why MFA doesn't stop phishing diagram showing session hijacking and AiTM attack flow
    Modern phishing attacks bypass MFA by targeting sessions, not just credentials.

    Why MFA Doesn’t Stop Phishing in Modern Identity Systems

    The Core Mistake: Treating Identity as a Login Event

    Many organizations still think of authentication as a single event. A user enters credentials, completes a second factor, and gets access.

    That is no longer how identity works in practice.

    Modern identity is a chain:

    authentication → token issuance → session establishment → reuse → refresh → policy reevaluation

    MFA protects only one point in that sequence. Everything after it depends on how well the platform protects sessions, evaluates context, enforces device trust, and reacts to risk.

    This is the core strategic mistake in modern identity security:

    teams protect the login, but attackers target the trusted state created by the login.

    Why MFA Solved Yesterday’s Problem

    MFA was designed for a different threat model.

    The old problem looked like this:

    1. attacker steals a password
    2. attacker attempts login
    3. second factor blocks access
    4. attack fails

    Against that model, MFA was and still is a strong improvement over password-only security.

    But identity systems evolved. Cloud services, SaaS platforms, federated sign-in, OAuth, OpenID Connect, SAML, session cookies, access tokens, and refresh tokens changed the attack surface.

    The attacker’s goal shifted from:

    “Can I steal the secret?”

    to:

    “Can I obtain or replay a valid identity state?”

    That is a much more dangerous problem, because a valid session can let an attacker operate as the user without needing to challenge MFA again.

    Where MFA Actually Breaks

    1. Authentication Is Not the Same as Session Trust

    MFA protects the challenge.

    It does not automatically protect what the system issues after the challenge succeeds.

    Once a service grants:

    • session cookies
    • access tokens
    • refresh tokens

    the security question changes. If those artifacts are stolen, replayed, or reused from another context, the service may continue to treat the attacker as legitimate.

    That is why many identity breaches today are not about defeating MFA directly. They are about abusing what happens after MFA succeeds.

    2. Tokens Are the Real Keys in Modern Environments

    The diagram below shows the difference between session theft and credential theft in modern identity attacks.

    session vs credential theft diagram showing how attackers hijack sessions instead of stealing passwords
    Session theft allows attackers to act as the user without logging in, making it more dangerous than credential theft.

    In Microsoft 365, Google Workspace, Slack, Salesforce, and similar platforms, access is often governed by tokens and sessions rather than by the password itself.

    That means:

    steal the token, and you may effectively become the user

    This is what makes session theft more dangerous than classic credential theft. The attacker is not trying to guess or crack authentication. The attacker is stepping into an already trusted state.

    3. Trust Often Persists Too Long

    Many organizations still allow sessions to remain valid too long, refresh silently, or avoid meaningful re-evaluation unless the token naturally expires.

    That creates operational space for attackers.

    An account owner may change the password, suspect something is wrong, or even sign out in one location, while a stolen session remains usable elsewhere. If risk-based reevaluation is weak, the attacker keeps the benefit of the earlier trust decision.

    4. The User Remains Inside the Security Boundary

    Push approvals, codes, and interactive login prompts all assume the user can reliably make safe decisions in real time.

    In reality, users are:

    • busy
    • conditioned by repetitive prompts
    • overloaded by email and app notifications
    • operating on mobile devices
    • trained to move quickly

    Modern phishing exploits exactly that environment.

    Attackers do not always need to beat the user. Sometimes they only need the user to cooperate at the wrong moment.

    5. Weak Fallback Paths Undermine Strong Primary Controls

    A company may deploy security keys or passkeys and still leave open:

    • SMS fallback
    • insecure recovery email flows
    • helpdesk override procedures
    • legacy authentication protocols
    • unmanaged device exceptions

    At that point, the environment is not protected by its strongest control. It is exposed through its weakest allowed route.

    The Real Attack Paths That Bypass Traditional MFA

    Adversary-in-the-Middle (AiTM) Phishing

    This is one of the most important identity attack patterns today.

    In an AiTM flow:

    1. the victim clicks a phishing link
    2. the phishing site acts as a reverse proxy between the victim and the real service
    3. the victim enters credentials
    4. the victim completes MFA on the legitimate service through the proxy
    5. the attacker captures the authenticated session
    6. the attacker reuses that session

    This is the hard truth many teams still resist:

    MFA can work exactly as designed and the organization can still lose.

    The problem is not always failed authentication. The problem is successful authentication being captured and repurposed.

    This is the core reason why MFA doesn’t stop phishing when attackers use AiTM techniques.

    Session Hijacking

    In some attacks, the phishing page is not even the main issue.

    If an attacker gets hold of a valid session cookie or token, they may bypass the entire authentication process and operate directly inside the user’s session context.

    This is post-authentication compromise, and it is exactly why login-centric defenses are no longer enough.

    Push Fatigue and Approval Abuse

    Not all MFA bypasses are technically advanced.

    Some are brutally simple:

    • flood the user with push prompts
    • pretend to be IT support
    • create urgency
    • tell the user to approve “to fix the issue”

    The weakness here is not cryptography. It is workflow manipulation.

    OAuth Consent Phishing

    Some attacks do not try to steal credentials at all.

    Instead, the victim is tricked into authorizing a malicious or overprivileged application. Once granted consent, that application may gain persistent access to data, mail, files, or APIs without ever needing the password.

    In these cases, “MFA enabled” is largely beside the point.

    Legacy Authentication and Weak Recovery

    Older protocols, weak password reset processes, unmanaged devices, and insecure exception handling remain common attack paths.

    Security teams often celebrate strong frontline controls while leaving side entrances open.

    Attackers notice that immediately.

    The Real Shift: From Credentials to Identity State

    The old mental model was simple:

    steal password → gain access

    The new model is more accurate:

    obtain valid identity state → operate as the user

    That identity state may include:

    • an authenticated session
    • valid access or refresh tokens
    • a trusted device context
    • an approved OAuth application
    • a low-risk sign-in posture in the identity provider

    This is why identity defense now has to move beyond passwords and beyond the login screen.

    The real perimeter is no longer static authentication.

    It is dynamic session integrity.

    Why Traditional Security Awareness Falls Short

    Most awareness programs still teach users to:

    • avoid suspicious links
    • check for spelling mistakes
    • look at the sender address

    That is not enough against modern phishing.

    Today’s attacks are often:

    • visually convincing
    • contextually relevant
    • timed to business processes
    • proxied through realistic login flows
    • designed to exploit approval habits, not obvious mistakes

    The skill users actually need is more advanced:

    they must know when not to approve identity-related actions, even when the flow feels familiar.

    Security awareness has to evolve from “spot the typo” to recognizing abnormal identity workflows under pressure.

    Why MFA Feels Safer Than It Sometimes Is

    There is a dangerous psychological effect here.

    When a user sees:

    • a familiar Microsoft or Google login flow
    • a real MFA prompt
    • a successful sign-in

    they often interpret that as proof of legitimacy.

    But in an AiTM attack, the attacker is relaying that exact flow in real time.

    That means MFA can become, in the user’s mind, a false signal of trust rather than a reliable signal of safety.

    This does not mean MFA is useless.

    It means traditional MFA is often context-blind.

    It verifies that a factor was completed. It does not always verify that the authentication request is happening in the right place, on the right origin, under the right conditions.

    What Actually Works

    1. Use Phishing-Resistant Authentication

    The strongest structural improvement is to adopt:

    • FIDO2 security keys
    • passkeys
    • device-bound cryptographic authenticators

    These methods are stronger because they use origin binding and asymmetric cryptography. The private key stays on the device, and the authentication response is tied to the legitimate domain.

    That sharply reduces the value of proxy-based phishing because the attacker cannot simply relay or replay the authentication on another origin.

    This is not just “better MFA.”

    It is a different security property.

    2. Enforce Device and Context Trust

    Authentication without context is weak.

    A stronger model asks:

    • is this a compliant device?
    • is the browser trusted?
    • does the location make sense?
    • is the sign-in risky?
    • is the user’s behavior consistent?
    • should this session exist under these conditions?

    This is where Conditional Access, device compliance, managed browsers, and risk-based policies become critical.

    3. Reevaluate Trust Continuously

    A session should not remain trusted simply because it was once established successfully.

    Continuous reevaluation matters because risk changes over time.

    A user account may become high risk. A token may appear in a suspicious context. A session may suddenly behave differently from its baseline.

    If reevaluation is slow, attackers keep access longer than they should.

    If reevaluation is fast, dwell time shrinks.

    4. Treat Tokens as High-Value Secrets

    Many teams still protect passwords more seriously than tokens.

    That is backwards.

    In modern cloud identity, tokens are temporary keys to systems, data, and workflows. They should be protected, bounded, monitored, and invalidated aggressively when risk changes.

    5. Detect Abuse After Authentication

    A major failure in many programs is that visibility drops after login succeeds.

    That is the wrong point to stop watching.

    Teams need detection for:

    • unusual session reuse
    • mailbox rule manipulation
    • abnormal API behavior
    • suspicious OAuth consent activity
    • unusual access patterns after sign-in
    • token reuse from unexpected contexts

    The breach often becomes visible only after authentication is complete.

    6. Eliminate Weak Fallbacks

    Strong identity systems cannot coexist comfortably with weak recovery and legacy exceptions.

    If you allow phishable fallback methods, attackers will route around your best control.

    This is why many identity hardening projects fail. The organization deploys something strong, then preserves enough weak exceptions to keep the overall environment exposed.

    7. Build Real Identity Incident Response

    A password reset is not enough for a modern identity compromise.

    Effective response may require:

    • global session revocation
    • token invalidation
    • mailbox rule review
    • OAuth application audit
    • device posture review
    • sign-in log analysis
    • consent and persistence investigation

    Identity incidents are not isolated events. They are distributed trust failures across time, devices, sessions, and services.

    The Strategic Reality

    MFA is not broken.

    The problem is that many organizations treat MFA as the end of the identity conversation when it is only one control inside a much larger trust system.

    That is the real failure:

    an incomplete identity model disguised as a mature security posture

    The Hard Truth in One Sentence

    MFA does not protect your account as a whole.
    It protects a single moment in the authentication flow.

    Modern attackers increasingly target:

    • the user during the flow
    • the session after the flow
    • the trust model around the flow

    That is why checkbox MFA is not enough.

    What This Means for Security Leaders

    If your message is still:

    “We enabled MFA, so we are covered”

    you are behind the current threat model.

    If your strategy is:

    • phishing-resistant authentication
    • session governance
    • device trust
    • continuous reevaluation
    • post-authentication detection
    • hard recovery architecture

    then you are defending identity at the level where modern attacks actually happen.

    That is the difference between compliance language and operational reality.

    Move Beyond Checkbox MFA

    Understanding why MFA doesn’t stop phishing is critical for modern identity security.

    Modern phishing does not stop at the login page. Your defenses should not stop there either.

    If you want a serious view of your exposure, the right question is not “Do we have MFA?”

    The right question is:

    Can an attacker still obtain, replay, or persist a trusted identity state in our environment?

    That is where real identity security starts.

    Book an Identity Architecture Review

    If your organization runs on Microsoft 365 or Microsoft Entra ID, we can map the identity attack surface that traditional MFA leaves behind.

    The review focuses on:

    • AiTM exposure
    • token and session risk
    • Conditional Access gaps
    • fallback weaknesses
    • identity recovery blind spots

    You get a prioritized hardening view based on real attack paths, not generic compliance talk.

    [Schedule Your Review →]

    Link this article to:

    • What Is AiTM Phishing and Why It Beats Traditional MFA
    • Passkeys vs MFA Apps: What Actually Changes
    • Why Session Cookies Matter More Than Your Password
    • How Conditional Access Shrinks the Damage of Identity Attacks
    • Why “MFA Enabled” Is a Weak Security KPI

  • Why Session Cookies Matter More Than Your Password

    Why Session Cookies Matter More Than Your Password

    Most people still think the password is the main thing protecting an account.

    It is not.

    Why session cookies matter more than your password becomes clear the moment you understand what happens after login. Your password only matters at the front door. After authentication, the system shifts trust to something else entirely: the session.

    Once a user signs in, the application stops checking the password on every request. It checks whether the browser presents a valid session token.

    That changes everything.

    Modern attackers don’t always need credentials anymore. If they can steal the active session, they can bypass login, bypass MFA, and inherit access instantly.

    credential theft vs session theft diagram showing MFA bypass with session cookies
    Credential theft targets the login. Session theft bypasses it completely.

    HTTP is stateless. Every request is independent unless the application adds memory.

    That memory is the session.

    After login, the server issues a session cookie. The browser automatically sends it with every request. The application treats those requests as authenticated.

    Key insight:

    The password gets you in once.
    The session keeps you in.

    This is exactly why session cookies matter more than your password becomes a critical concept in modern identity security.

    Why Session Cookies Matter More Than Your Password

    1. A session cookie can bypass authentication entirely

    A password is used to create trust. A session cookie represents trust that has already been granted.

    If an attacker steals a valid session cookie, they usually do not need to know the password at all. They also may not need to pass MFA, because MFA was already completed during the original sign-in flow. The attacker simply reuses the authenticated session.

    This is what makes session hijacking so dangerous. The attacker is not attacking the login process. They are skipping it.

    2. Session theft is often faster than credential theft

    Credential attacks usually require one or more steps:

    • phishing the victim
    • cracking weak passwords
    • reusing breached credentials
    • bypassing or intercepting MFA
    • avoiding login-based detections

    Session theft removes much of that work.

    If malware, an AiTM phishing proxy, a malicious browser extension, or a browser compromise can extract the active session, the attacker gets immediate usable access. In many cases, that is operationally easier than stealing credentials and then dealing with the controls that sit around th

    3. A valid session looks legitimate to the application

    That is one of the hardest realities in identity security. Many detections are designed around authentication events such as impossible travel, new-device sign-ins, unusual IP addresses, failed login bursts, or MFA fatigue patterns. But once a request arrives carrying a valid session token, the platform may treat it as normal application traffic.

    That makes session abuse quieter than credential abuse.

    4. Sessions can remain active for a long time

    Many users assume a session lasts only a few minutes. In reality, that is often false.

    Modern applications may keep users signed in for days or weeks. Some use refresh tokens, silent reauthentication, or “remember this device” behavior that extends practical access even further. In SaaS environments, that can give an attacker a large post-compromise window.

    A stolen password is dangerous. A stolen active session is dangerous right now.

    5. MFA protects the login event, not the ongoing session

    This is the misunderstanding that causes false confidence.

    MFA is valuable. It raises the cost of account compromise and blocks many basic attacks. But MFA does not automatically protect the session that exists after the user signs in. Once the platform has issued a valid session token, possession of that token may be enough to act as the user.

    This is exactly why session-based attacks keep growing. Organizations celebrate MFA adoption while attackers move one layer deeper.

    6. Modern attackers increasingly target sessions instead of passwords

    The industry is slowly learning that identity attacks are shifting from credential collection to session capture.

    That shift shows up in several places:

    • AiTM phishing kits that proxy the real login flow and steal the post-authentication session
    • info-stealer malware that extracts browser cookies and tokens
    • malicious browser extensions with excessive permissions
    • cloud identity attacks that focus on token replay rather than password guessing

    The logic is simple. Stronger passwords and wider MFA deployment made direct credential abuse harder

    7. The session is the real operational identity layer

    Security teams often talk about identity as if it begins and ends with passwords, MFA apps, or passkeys.

    That is incomplete.

    Operationally, the session is what the application trusts on each request. That makes session management one of the most important and most underestimated layers in account security. If the session is weak, poorly scoped, too long-lived, or easy to steal, then the strength of the password matters much less than people think.

    Understanding this attack surface is essential to grasp why session cookies matter more than your password in real-world breaches.

    Session cookie theft does not require one single technique. It can happen through multiple attack paths, and that is what makes it dangerous.

    AiTM Phishing

    Reverse proxy attacks capture sessions after MFA.

    How Cyber Attacks Happen: Step-by-Step Breakdown
    What Is AiTM Phishing and Why It Bypasses MFA

    In an adversary-in-the-middle phishing attack, the victim is lured to a phishing site that sits between them and the legitimate service. The victim enters credentials, completes MFA, and the real site issues a valid session. The phishing proxy captures that session token and hands it to the attacker.

    The attacker never needs to defeat MFA directly. They inherit the result of a legitimate MFA flow.

    Info-stealer malware

    Many modern malware families are designed to scrape browsers for stored credentials, cookies, and tokens. In practice, this means they are not just stealing usernames and passwords. They are stealing already authenticated states.

    That can give the attacker immediate access to email, development platforms, enterprise SaaS tools, and cloud-admin surfaces.

    XSS

    If a website is vulnerable to cross-site scripting and cookies are not properly protected with HttpOnly, malicious scripts may be able to read and exfiltrate them. That turns a client-side injection flaw into a session compromise.

    Malicious or over-permissioned browser extensions

    Extensions are often ignored in security conversations, but they can become a direct path into sessions. If an extension can read page content, intercept traffic, or access browser storage in dangerous ways, it may expose authentication artifacts.

    Unsecured transport or legacy weaknesses

    Plain HTTP, weak internal apps, bad reverse proxies, and poorly designed legacy systems can still expose session data in transit. This is less common than before, but it still matters in older environments and internal tooling.

    Physical access to an unlocked device

    Not every session attack is advanced. If a browser is open and the user is authenticated, an attacker with device access may not need the password at all. They already have the session in front of them.

    pass the cookie attack flow showing how stolen session cookies bypass MFA and grant access
    A stolen session cookie allows attackers to replay an authenticated session and gain full access without needing a password or MFA.

    This is why session hijacking and pass-the-cookie attacks are more dangerous than traditional credential theft.

    Pass-the-cookie is the simplest way to explain the risk.

    The attacker obtains the cookie. Then they replay it.

    If the application accepts that cookie as valid, the attacker is treated as the user. They get the same permissions, the same active session context, and the same access level.

    This is why the phrase “stealing the password” can be misleading in modern identity incidents. In many cases, the attacker is not stealing identity at the credential layer. They are replaying it at the session layer.

    Session Fixation: A Different Route to the Same Outcome

    Session theft usually means stealing an already active session. Session fixation is different.

    In a session fixation attack, the attacker forces or tricks the victim into using a session ID that the attacker already knows. If the application fails to rotate the session ID after login, the attacker can later reuse that same authenticated session.

    The weakness here is not theft after login. It is bad session lifecycle management during login.

    A secure application must issue a fresh session after successful authentication. If it does not, it risks turning an unauthenticated session into an authenticated one that the attacker can predict or control.

    Session Prediction: When the Session ID Itself Is Weak

    Some systems fail even earlier.

    If session IDs are predictable, low-entropy, sequential, timestamp-based, or built from guessable values, attackers may be able to predict valid sessions without stealing or fixing them first. This is session prediction.

    This is mostly a legacy or custom-implementation problem now, but it still matters in badly designed applications. Strong session management depends on randomness. If the token is guessable, the whole model collapses.

    Why Defending the Session Is Harder Than People Think

    Developers and defenders do have controls available, but none of them are perfect on their own.

    OWASP Session Management Cheat Sheet
    Microsoft identity security guidance

    HttpOnly

    This helps prevent JavaScript from reading cookies. It is critical against some XSS-based theft paths. But it does not stop every kind of session abuse, and it does nothing against malware already running on the endpoint.

    Secure

    This ensures cookies are only sent over HTTPS. It is necessary, but it does not protect a session once the endpoint itself is compromised.

    SameSite

    This reduces some cross-site abuse patterns, especially around CSRF. It is useful, but it is not a complete defense against cookie theft or token replay from the user’s own environment.

    Short session lifetime

    Reducing session duration limits attacker dwell time, but it also creates friction for users. Most organizations compromise here, and attackers benefit from that tradeoff.

    Reauthentication for sensitive actions

    This is one of the better controls. Even if the session exists, the application can demand fresh proof before allowing high-risk actions such as password changes, payment updates, admin role changes, or privileged operations.

    Device and risk binding

    Some platforms bind sessions to device posture, browser characteristics, IP signals, or conditional access policies. These controls can reduce replay success, but they need careful tuning because legitimate users move, roam, and change networks constantly.

    This complexity further explains why session cookies matter more than your password in modern attack scenarios.

    What Users Can Do

    Users cannot solve session security alone, but they can reduce exposure.

    Log out of sensitive accounts when you are done, especially on shared or semi-trusted devices. Keep browsers updated. Avoid random extensions. Treat extension permissions seriously. Use reputable endpoint protection. Be cautious with phishing links even if they appear to support MFA. Review active sessions on major platforms and revoke sessions you do not recognize.

    The important mental shift is this: do not think only about protecting the password. Think about protecting the live authenticated browser.

    What Organizations Need To Change

    Organizations need to stop treating “MFA enabled” as the end of the identity story.

    A stronger model includes:

    • session-aware detection
    • stronger endpoint security against info-stealers
    • phishing-resistant authentication where possible
    • reauthentication for sensitive actions
    • shorter token lifetime for privileged access
    • conditional access and risk-based session controls
    • secure cookie configuration
    • session revocation and visibility for users and admins
    • testing for fixation, prediction, replay, and token handling flaws

    In other words, identity security has to extend beyond the login page.

    The Real Bottom Line

    Why session cookies matter more than your password comes down to one uncomfortable fact: once a session is active, the application usually trusts the session more than the credentials that created it.

    That is why attackers increasingly go after cookies, tokens, and authenticated browser state. It is faster than cracking passwords, often bypasses MFA, and can look like perfectly normal user activity.

    The password opens the door.

    The session decides who the system believes is already inside.

    Conclusion

    The traditional model of account security starts with credentials. The modern attack model starts after credentials.

    This is ultimately why session cookies matter more than your password in modern cybersecurity.

    That is the shift many teams still underestimate.

    If you only protect the login, but fail to protect the session, you are securing the entrance while leaving the occupied building exposed. Session cookies are not a minor implementation detail. They are the operational trust layer of the modern web.

    That is why session cookies matter more than your password in day-to-day account security, incident response, and modern identity defense.

    Want to understand how modern identity attacks really work beyond passwords and MFA?

    Read these next:

    If you are building a security strategy in 2026, start by asking a harder question:

    What happens after login?