How Hackers Steal Login Sessions and Bypass MFA

Article Summary: Adversary-in-the-Middle (AiTM) attacks are a newer type of phishing attack that steal active login sessions, not just passwords. That matters because it allows attackers to get into accounts even after MFA has been completed. When businesses understand how AiTM works, they’re in a much better position to reduce risk with phishing-resistant sign-ins, tighter session controls, and faster detection of suspicious account activity. 

You click a link, sign in, approve the MFA prompt, and continue with your day. But at that same moment, someone else may have just gained access to your account too. That’s what makes Adversary-in-the-Middle (AiTM) phishing attacks so concerning. They can bypass the protection many businesses assume MFA alone provides, not by breaking MFA itself, but by stealing the authenticated session after login is already complete. 

MFA is still one of the most important security controls a business can have in place. It remains a critical first step in protecting cloud accounts. But AiTM attacks target something MFA was never meant to fully protect: the trusted session that exists after a user has already signed in. 

In this article, we’ll walk through how AiTM phishing attacks work, why they matter for businesses, and what can be done to reduce the risk before it leads to fraud, data exposure, or operational disruption. 

How AiTM phishing attacks go beyond stolen passwords 

Phishing is still one of the most common ways attackers get into business accounts, but what they are trying to steal has changed. Traditional phishing attacks were mostly about collecting usernames and passwords. Today, attackers often want something even more useful right away: the authenticated session itself. 

Security researchers have documented a clear shift toward session and token theft. Instead of stealing credentials and trying to log in later, which MFA can often block, attackers wait until the user successfully signs in and then capture the session token that proves authentication has already happened. 

That shift has made these attacks easier to launch too. Phishing-as-a-Service (PhaaS) platforms now offer ready-made proxy toolkits that allow even low-skilled attackers to run AiTM campaigns against Microsoft 365 and Google Workspace. In other words, this is no longer a rare or highly specialized threat. It is becoming more accessible, more scalable, and more relevant to everyday business risk. 

How AiTM attacks work 

Why the fake login page looks real 

An AiTM phishing page is not just a static copy of a login screen. It works as a live reverse proxy. That means the attacker places their own infrastructure between the user and the real authentication service. Every keystroke, redirect, and server response passes through the attacker’s system in real time. 

From the user’s perspective, the experience may look completely legitimate. The branding looks right. The redirects work. The MFA prompt still appears. In many cases, the only visible sign that something is wrong is a slightly altered URL, and that is easy to miss, especially on a mobile device or when someone is moving quickly. 

That is what makes AiTM attacks so effective. They do not rely on a login page that looks obviously fake. They rely on a process that feels normal enough to trust. 

How AiTM phishing bypasses MFA 

This is where many common assumptions about account security start to fall apart. MFA protects the authentication step. It does not protect everything that happens after authentication is complete. Once a user successfully signs in and completes MFA, the service issues a session cookie. That cookie tells the application the user has already been verified. From that point on, the system trusts the session. No additional password or MFA prompt is needed. 

Whoever has that session cookie has the access. That is what AiTM attacks are designed to steal. Rather than trying to defeat MFA directly, the attacker waits for the user to complete it successfully and then takes the session cookie once it is issued. 

Microsoft tracked a 146% rise in AiTM attacks over the past year as attackers increasingly shifted toward accounts already protected by MFA. Much of that growth has been tied to PhaaS platforms such as Evilginx, which make it easier for lower-skilled attackers to launch convincing reverse-proxy phishing attacks at scale and target major cloud identity providers with relatively little setup. 

How session cookies let attackers hijack access 

Session tokens act as bearer credentials. In simple terms, if someone has the token, they can use the session. No password is required. No MFA challenge is required. Once the attacker steals the session cookie, they can import it into their own browser and continue the session as if they were the legitimate user. This is often referred to as a session replay attack. 

The attacker is not logging in the usual way. They are stepping directly into a session that has already been authenticated and trusted. For businesses, that matters because many standard login-focused security assumptions no longer apply. If the attacker is using a valid session, the activity can look much more normal than a failed or suspicious sign-in attempt. 

What happens after an AiTM attack steals a session 

One of the biggest risks with AiTM attacks is how quietly they can unfold. Because the attacker is operating inside a legitimate, authenticated session, there may be no failed MFA attempts and no obvious sign-in alerts that clearly point to compromise. That makes these attacks harder to catch early. 

Research from Proofpoint shows that attackers who gain access through session hijacking often go on to: 

• create hidden inbox rules to redirect mail 

• register additional MFA methods to maintain access 

• watch email threads for financial conversations 

• use the trusted account to send phishing messages to coworkers or finance teams 

And this is where a technical security issue quickly becomes a business issue. A compromised session can lead to wire fraud, sensitive data exposure, internal phishing, and broader disruption across the organization. By the time the issue is discovered, the damage may already be underway. 

How to reduce the risk of AiTM phishing attacks 

MFA is still essential. It remains a foundational control and should absolutely be part of every business’s security baseline. But reducing AiTM risk means protecting more than just the login event. 

Use phishing-resistant MFA 

Phishing-resistant methods such as FIDO2 hardware keys and passkeys help close the gap AiTM attacks rely on. These methods are tied to the legitimate domain and the user’s device, which means a proxy in the middle cannot simply relay the authentication request the way it can with standard MFA prompts or one-time passcodes. 

If the site is not the real one, the authentication process fails. The Canadian Centre for Cyber Security analyzed more than 100 AiTM campaigns targeting Microsoft Entra ID accounts and found that phishing-resistant MFA consistently blocked session theft where standard MFA methods, including push notifications and one-time passcodes, did not. 

Strengthen conditional access policies  

While Conditional Access does not prevent AiTM attacks on its own, it can significantly reduce their impact. By enforcing requirements such as compliant devices, trusted locations, or risk-based sign-in policies, organizations can make stolen credentials and session tokens far less useful to an attacker. Instead of granting access based solely on a successful authentication, Conditional Access continuously evaluates whether the sign-in meets your organization’s security requirements. 

Watch for warning signs after login 

Stopping AiTM often comes down to what you monitor after login, not just at login. 

That includes watching for things like: 

• new MFA method registrations 

• inbox rules created at unusual times 

• access from unfamiliar locations 

• unusual data activity or behavior that does not fit the user’s normal pattern 

Authentication logs alone will not always show the full picture. Businesses need visibility into account behavior after access is granted, because that is often where AiTM compromise becomes visible. 

Train employees to check URLs carefully 

User awareness still matters, but the message has to evolve. Employees need to know that seeing a real-looking login experience and even a legitimate MFA prompt does not automatically mean the page is safe. If something feels off, especially the URL, that pause matters. 

Helping employees understand what AiTM lures can look like in Microsoft 365 environments can make a real difference. A short, practical walkthrough is often enough to help people recognize that a working login flow can still be part of a phishing attack. 

Why businesses need to protect more than the login screen 

MFA is a baseline. It is not the finish line. The businesses that reduce AiTM risk most effectively are the ones that understand how identity trust actually works, from sign-in through session activity, and build protections around every layer. Because once an attacker gets into a trusted session, the impact goes far beyond one login. 

It can affect financial workflows, internal communication, client trust, and day-to-day operations. That is why this is not just an IT issue. It is a business continuity issue. If you want a clearer picture of where your identity protections may be vulnerable, contact our team, we can help you look at the areas that matter most, before an incident forces the issue. 

FAQs

What Is an AiTM Phishing Attack? 

An AiTM attack is a type of phishing attack where the attacker uses a proxy to intercept the login process in real time and steal the session cookie after authentication is complete. 

Can AiTM Phishing Attacks Bypass MFA? 

Yes, but not by breaking MFA itself. AiTM attacks wait until MFA succeeds and then steal the authenticated session token, which allows the attacker to continue the session without needing to verify again. 

How Can Businesses Reduce the Risk of AiTM Phishing Attacks? 

Businesses can reduce risk by using phishing-resistant MFA, tightening Conditional Access policies, training employees to check URLs carefully, and monitoring for unusual behavior after login.