Attackers Are Stealing Sessions, Not Passwords

For years, enterprise identity security was built around a straightforward assumption: if an attacker obtains a user's password, the organization needs another factor to stop that password from being enough.

Multifactor authentication materially improved that model. A stolen password alone could no longer guarantee access, and organizations rightly invested heavily in expanding MFA across cloud applications, privileged accounts and remote access.

Increasingly, sophisticated phishing campaigns are not designed merely to capture credentials. They attempt to intercept the authentication process itself, allowing the attacker to obtain the session established after the user successfully completes MFA. Once that session is stolen, the security problem changes. The attacker may no longer need to reproduce the victim's password or second factor because the identity provider has already authenticated the session they have captured.

This does not mean passwords have become irrelevant or that every identity attack now targets tokens. Credential stuffing, password spraying, infostealers and conventional phishing remain important threats. But the growth of adversary-in-the-middle phishing demonstrates why organizations need to think beyond protecting the moment a user signs in. The valuable asset is increasingly what happens after authentication succeeds.

MFA can succeed and the account can still be compromised

Adversary-in-the-middle, or AiTM, phishing illustrates the problem particularly well. Instead of directing a victim to a simple imitation login page that collects a username and password, an AiTM platform acts as a proxy between the user and the legitimate service. The victim interacts with what appears to be the normal authentication process. Credentials are captured and forwarded to the real service. If an MFA challenge occurs, that interaction can also be relayed.

From the user's perspective, authentication may appear to work normally. Once the legitimate service completes authentication, however, the attacker can capture the resulting session cookie or token and attempt to reuse it.

Microsoft documented this technique in its March 2026 analysis of Tycoon2FA, a phishing-as-a-service platform used against organizations across education, healthcare, finance, government and other sectors. The service allowed attackers to proxy Microsoft 365, Gmail and other authentication flows, intercept credentials and session cookies, and bypass MFA by relaying the authentication process through attacker-controlled infrastructure. Microsoft noted that access could persist even after a password reset if active sessions and tokens were not explicitly revoked. That last point is particularly important operationally.

Security teams have been conditioned to respond to credential compromise by resetting the password. In a conventional password-theft scenario, that makes sense. If the attacker knows the old password and the organization replaces it, the stolen credential loses much of its value. A valid session is different.

If the service continues to recognize an existing token, changing the credential that originally created that session does not necessarily invalidate the session itself. An incident responder can therefore reset the user's password, believe the account has been contained, and still leave an attacker with usable access.

The containment process has to consider the entire authenticated state: passwords, refresh tokens, browser sessions, registered authentication methods, device trust, application consent and any persistence the attacker may have established after gaining access. That is a much broader identity incident than “the user's password was phished.”

Phishing-resistant authentication changes the economics

The obvious response is stronger authentication, but not all forms of MFA provide the same protection. One-time codes delivered by SMS, voice or authenticator applications can improve security substantially over passwords alone. They can still be phished, however, because the user can be persuaded to provide the factor to an attacker-controlled authentication flow.

Push notifications present their own problems when users are conditioned to approve prompts without carefully evaluating why they appeared. Phishing-resistant methods such as passkeys and FIDO2 security keys work differently. They use public-key cryptography and bind authentication to the legitimate service, making it considerably harder for an attacker to relay the user's authentication through a fraudulent domain.

The industry is increasingly treating this distinction as a baseline security issue rather than an advanced feature. Microsoft began making passkeys the default authentication experience for eligible Entra ID users on September 1, 2026, and plans to retire its native SMS and voice MFA delivery on February 1, 2027. Microsoft explicitly describes passkeys as phishing-resistant and is encouraging organizations to move away from authentication methods that can be intercepted or socially engineered.

That is an important direction of travel, but organizations should avoid concluding that phishing-resistant MFA eliminates session risk altogether. Strong authentication makes it much harder for an attacker to trick a user into creating a session through a phishing proxy. It does not automatically prevent malware running on an already compromised endpoint from stealing authentication material after the user has legitimately signed in.

As identity controls improve, attackers have an incentive to move further along the authentication chain. Microsoft's own deployment guidance makes this point explicitly: as phishing-resistant credentials become more common, attackers may increasingly attempt to exfiltrate tokens directly from devices. The defensive objective therefore cannot stop at making the login stronger.

The session needs protection too

If sessions are valuable security objects, they need controls of their own. One emerging approach is token binding. Instead of issuing a token that can be copied and replayed from another system, the identity platform can cryptographically associate it with the device to which it was originally issued.

Microsoft Entra's Token Protection capability, for example, is designed to require supported sign-in session tokens to remain bound to the device that received them. If an attacker steals such a token and attempts to replay it from another device, that binding can prevent it from being accepted for protected resources. Microsoft describes the control as one component of a broader defence-in-depth strategy against token theft rather than a complete solution.

Enterprise identity environments are complicated. Not every application, operating system, browser or authentication path necessarily supports the same protections. Legacy applications may depend on older protocols. Contractors may use unmanaged devices. SaaS applications may apply different session lifetimes and revocation behaviours. Organizations therefore need to understand where stronger session controls can actually be enforced rather than assuming one identity policy protects every application equally.

Conditional Access can also play a larger role after authentication. Device compliance, location, user risk, sign-in risk and other contextual signals can help determine whether an established identity should continue to receive access. Session controls and continuous evaluation mechanisms can allow access decisions to change as circumstances change instead of treating successful login as a durable declaration of trust. This represents an important shift in how identity security is designed.

Authentication should not be considered a single security checkpoint that an attacker either passes or fails. It is the beginning of a session whose trustworthiness may need to be reassessed throughout its lifetime.

Incident response has to follow the attacker

The same shift should affect security operations. Suppose a user reports entering credentials into a suspicious Microsoft 365 login page. Resetting the password should certainly be part of the response, but it should not be the end of it.

Responders need to determine whether authentication was successfully completed through the phishing infrastructure. Existing sessions may need to be revoked. Authentication methods and account recovery information should be checked for unauthorized changes. Sign-in activity should be reviewed for anomalous devices, locations and applications. Mailbox rules, OAuth consent, forwarding configuration and other common persistence mechanisms may require investigation.

For privileged identities, the consequences are greater. A captured administrator session can provide access to systems where the attacker can create new accounts, alter security policies or establish persistence that survives the original session.

This is why the move toward phishing-resistant MFA is particularly important for administrative roles. Microsoft's current guidance recommends requiring phishing-resistant authentication for privileged Entra roles rather than treating generic MFA as sufficient. Organizations should also reconsider how they measure MFA adoption.

A dashboard showing that 98 per cent of users have MFA enabled may look reassuring. It says relatively little about whether those users rely on SMS, push notifications, one-time passwords, passkeys or hardware-backed credentials. It says even less about whether sessions are protected after authentication. The more useful question is no longer simply, “Do we have MFA?” It is, “What attacks is our authentication architecture actually resistant to?”

That is a more demanding question, but it reflects how identity attacks now work. Passwords still matter. MFA still matters. Neither should be abandoned or dismissed simply because attackers have developed ways around particular implementations.

Security controls change attacker behaviour. As organizations make credentials harder to exploit, attackers look for ways to inherit the trust those credentials create. The target moves from the password, to the second factor, to the authenticated session, and potentially to the device holding that session. Identity defence has to move with it.

The next stage of enterprise authentication is therefore not simply adding another factor to the login screen. It is protecting the chain of trust before, during and after authentication.

Because once an attacker has a valid session, whether they know the password may no longer be the most important question.