Bypassing 2FA with AiTM: How UNIXi Stops Credential Theft

Introduction

Two-factor authentication (2FA) has long been hailed as one of the most effective ways to safeguard online accounts against unauthorized access. However, despite its strength, 2FA is not impervious to clever attackers. One such attack vector that has been gaining traction is the Adversary-in-the-Middle (AiTM) attack. This sophisticated technique allows attackers to bypass 2FA entirely, putting both user credentials and sensitive information at risk.

In this blog post, we will take a technical deep dive into how the AiTM attack works, break down each of its critical steps, and explain how UNIXi’s Solution can mitigate these attacks to protect users from credential theft.

What is the AiTM Attack?

An Adversary-in-the-Middle (AiTM) attack is a specialized form of man-in-the-middle (MitM) where the attacker simultaneously impersonates the user to the authentication server and the server to the user. This dual impersonation allows the attacker to capture credentials and 2FA codes in real-time, enabling unauthorized access to accounts while maintaining the illusion of a legitimate interaction.

How Does the AiTM Attack Work? – The Attacker’s Perspective

Step 1: Initial Reconnaissance and Phishing

I’m sitting at my desk, plotting my next big move. The first thing I need is information. I need to know everything about my target—Company ***. The more I know, the easier it will be to craft a convincing phishing attack.

I start with some Open Source Intelligence. First, I need a list of employees to target. Using tools like Hunter.io and rocketreach, I input the company’s domain, and it generates a list of potential email addresses. It’s quick and effective, giving me dozens of results. To refine this list, I cross-check it with LinkedIn profiles and other public directories. Now I have a targeted set of employees—names, roles, and emails—all mapped out and ready for the next step.

Example RocketReach email address lookup based on the domain “unixi.io”

Next, I run Amass, mapping out the entire domain structure of Company ***. This tool shows me all their subdomains and provides a roadmap of their network. I find that they use Microsoft 365 for their authentication system. Jackpot. Now I know exactly how their users authenticate, and I can mirror the Microsoft login page with frightening precision.

I then create a fake domain designed to look exactly like Microsoft’s. But I’m no amateur. I know better than to use an obvious name like “login-microsoft.com.” That would be too easy to detect. Instead, I craft a more subtle URL, something that looks convincing at first glance. For example: login.microsoftonline.com@%6D%69%63%72%6F%73. It’s a clever trick—the URL encoding hides the real domain. At first, it looks like Microsoft, but in reality, I’ve just made a mask.I set up my cloned login page, duplicating every button, logo, and feature exactly. It’s a perfect copy, no different from the real thing. All I need now is to get my victim to bite. I write a phishing email that appears to be from the company’s IT team, warning them of a security breach and urging them to log in immediately. The message is urgent, designed to trigger fear or distraction. I send it off and wait.

Fake Login Page

Sure enough, within minutes, I see a click. The victim lands on my perfectly cloned page. They type in their username and password, completely unaware that I’m capturing every keystroke. I’ve got their credentials, and now the fun really begins.

Step 2: Exploiting the 2FA Process

I’ve got their username and password, but that’s only half the battle. The real hurdle is 2FA. Sure, it’s another layer of security, but it won’t stop me.

I redirect the victim to the typical 2FA prompt. They receive a text or a push notification from their authenticator app. I can already predict their next move—they’ll enter the 2FA code, thinking they’re dealing with Microsoft. But they’re not.

I use a tool like Evilginx2 to exploit the communication flow between the victim and Microsoft’s authentication server. As the victim enters their 2FA code, the tool captures it without their knowledge. The victim is completely unaware, as I pass the username, password, and 2FA code in real-time to the real Microsoft server. It’s like the victim is logging in, but they’re not—they’re just feeding me everything I need.

Step 3: Stealing Data or Accessing the Account

Now that I’m in, I start poking around. The 2FA barrier is gone, and I’m free to do whatever I want. The victim thinks everything’s fine, but I’m pulling the strings behind the scenes.

I open their email inbox first. It doesn’t take long to find something interesting—a few high-level business emails. I dig deeper and find financial data, client communications, and sensitive internal reports. I’ve hit the motherlode. Everything is ripe for the taking.

Then, I remember: I’m not just here for the data. I’ve already compromised their account, and I’m in a perfect position to launch more attacks. I use the victim’s email to send a phishing email to their colleagues, posing as the victim and requesting approval for a large wire transfer to a “trusted partner.”

I can keep this going forever. No one suspects a thing. The victim thinks they’re safe, but I’ve already infiltrated their entire world. 2FA didn’t stop me, their security didn’t stop me. Now, I can stay inside as long as I need.

Reflection – The Attacker’s Perspective

Looking back, I’m still amazed by how smooth the attack went. The brilliance wasn’t just in capturing credentials, it was in exploiting weaknesses in the authentication process to bypass protections like 2FA. I didn’t need to brute force anything—I simply exploited the trust users place in their login systems, especially when they rely on 2FA.

In this world of man-in-the-middle attacks and social engineering, the game is always evolving. But as long as I have the right tools and know how to use them, there will always be vulnerabilities to exploit.

How UNIXi Can Protect Against AiTM Attacks

Now, imagine if the company had been equipped with UNIXi. This advanced security tool could have stopped my attack cold—no alarms, no breaches, no stolen data.

UNIXi’s whitelist approach would have flagged my cloned login page immediately. Since my phishing URL wasn’t on the list of approved systems, the extension would have blocked the user from entering any credentials. My carefully crafted page? Rendered useless before I could even start collecting information.

But the real masterstroke lies in how UNIXi secures credentials. Even if I managed to steal a password, it would be completely unusable, rendering my phishing attempt pointless.

This two-pronged defense—blocking unauthorized URLs and rendering stolen credentials useless—would have dismantled my attack strategy at every step. It’s not just about spotting threats; it’s about neutralizing them before they can cause harm. With UNIXi, my tactics wouldn’t have stood a chance.

UNIXi doesn’t just protect; it redefines the rules of engagement. Attackers like me rely on predictability, but UNIXi introduces a layer of security so dynamic and effective that the game is over before it even begins.