Phishing 2.0 – how phishing toolkits are evolving with AitM

Phishing attacks have always been a go-to technique for both red teamers and real-world threat actors alike. Whether focused on harvesting creds or running malicious payloads, phishing has continued to be adapted to circumvent defenses and has remained highly effective due to this.

As MFA has become more common, classic password harvesting focused phishing attacks have become less effective. Typically, for a full account compromise, an MFA push notification or a one-time passcode (OTP) needs to be entered at the time of login. This means harvesting passwords and using them later is no longer effective alone, because an MFA factor is still required each time a valid login is performed.

Adversary-in-the-Middle (AitM) phishing is a newer variant of phishing that allows attackers to circumvent MFA protection. In this article, we’re going to look at what AitM phishing is, how it works, and what you can do about it.

What is AitM phishing?

AitM phishing is a technique that uses dedicated tooling to act as a proxy between the target and a legitimate login portal for an application, principally to make it easier to defeat MFA protection. 

While any login portal can be a target, attackers typically look for SSO login portals such as Microsoft Entra, Okta, or Google Workspace. This allows the target to log in successfully with a legitimate service they use and even continue to interact with it, while providing additional access to connected SSO apps if the attack is successful. 

As it’s a proxy to the real application, the page will appear exactly as the user expects, because they are logging into the legitimate site – just taking a detour via the attacker’s device. For example, if accessing their webmail, the user will see all their real emails; if accessing their cloud file store then all their real files will be present, etc. This gives the method an increased sense of authenticity and makes the compromise less obvious to the user. However, because the attacker is sitting in the middle of this connection, they are able to observe all interactions and also take control of the authenticated session to gain control of the user account. 

While this access is technically temporary, since the attacker is unable to re-authenticate in future without additional MFA prompts, in practice authenticated sessions can often last as long as 30 days or more if kept active. Additionally, there are a wide range of persistence techniques that allow an attacker to maintain some level of access to the user account and/or targeted application indefinitely. 

We’ll revisit this point later, but for now let’s consider the two main techniques that are used to implement AitM phishing: Reverse web proxies and Browser-in-the-Middle techniques.

Reverse web proxy techniques

One common AitM phishing approach is to use tooling that acts as a reverse web proxy. For example, let’s say a victim is tricked into visiting a malicious domain. Under the hood, HTTP requests are passed between the victim’s browser and the real site via the malicious site. When the malicious site receives an HTTP request, it forwards this request on to the legitimate site it is impersonating, receives the response, and then forwards that on to the victim. 

In practice, there are many technical challenges, such as rewriting all links and references to the impersonated site to ensure everything continues to be sent to the attacker. However, at a high level, it really is just acting as a reverse web proxy.

This is arguably the most scalable and reliable approach from an attacker’s point of view. Open-source tools that demonstrate this method include Modlishka, Muraena, and the ever popular Evilginx. In the criminal world, there are also similar private toolsets available that have been used in many breaches in the past. A good example of this would be Evilproxy.

One downside to this approach is that there are controls that can be put in place to block it. For example, application developers can hide obfuscated JavaScript code that will fail if the correct value is not produced, checking that the origin matches the expected (legitimate) domains or contains encrypted tokens including this material sent as part of the login process. 

While your average small website is not going to be implementing such checks, major identity providers have a strong vested interest in evolving their defenses to block these techniques. At this point, it’s a cat-and-mouse game. 

If you want to know more about this space, then definitely check out Kuba Gretzky’s talk on this at x33fcon.  

Browser-in-the-Middle (BitM) techniques 

Another common approach is known as Browser-in-the-Middle (BitM). Rather than act as a reverse web proxy, this technique tricks a target into directly controlling the attacker’s own browser remotely using desktop screen sharing and control approaches, much like VNC and RDP. This enables the attacker to harvest not just the username and password, but all other associated secrets and tokens that go along with the login. 

In this case, the victim isn’t interacting with a fake website clone or proxy. They are literally remotely controlling the attacker’s browser to log in to the legitimate application without realizing. This is the virtual equivalent of an attacker handing their laptop to their victim, asking them to login to Okta for them, and then taking their laptop back afterwards. Thanks very much!

Practically speaking, the most common approach for implementing this technique is using the open-source project noVNC, which is a JavaScript-based VNC client that allows VNC to be used in the browser. Probably the most well-known example of an offensive tool implementing this is EvilnoVNC, which spins up Docker instances of VNC and proxies access to them, while also logging keystrokes and cookies to facilitate account compromise. Tools like Cuddlephish offer similar functionality using WebRTC. 

The advantage of this approach is that it is incredibly difficult for the target websites to do anything to stop it. From their perspective, all they see is a legitimate browser accessing their website and logging in. None of the JavaScript tricks for checking the origin will work. They aren’t in a position to be able to see that the browser is secretly being controlled remotely by the victim user without their knowledge. 

On the downside, while noVNC can be extremely convincing, the illusion can sometimes be broken due to it not behaving exactly like a real website would due it being a graphical rendering. For example, something as simple as resizing the browser window can introduce render resolution issues. It’s also more difficult to scale for attacking large numbers of users than a reverse proxy technique.

Footnote: BitM is not to be confused with Browser-in-the-Browser (BitB), which is more of a malicious pop-up (think when a login button spawns a new browser window). This article explores a BitB technique that simulates a browser window within the browser to spoof a legitimate domain.

Beyond initial access

So maybe you’re thinking now “OK, sounds kinda bad, but I’m not that worried. Maybe some user accounts get compromised by this method despite all my MFA protections, but at least the attacker only has temporary access, right?” 

In theory, access is temporary as sessions time out. And if spotted, the security team can respond by killing the authenticated sessions and forcing password changes for the compromised users. Then the attacker is back to square one, right? Their session is lost, they still don’t have MFA, and even the password they keylogged has now been changed.

In practice, it’s not this simple. We mentioned earlier how SSO portals are often the most common targets for these attacks. For most modern organizations, this means their core identity provider, which just so happens to be the gateway to accessing many other web applications, whether internal applications or a multitude of SaaS applications. 

Let’s consider the example of an organization using Okta where their Okta login portal has been used as the target for AitM phishing. A smart attacker is going to immediately leverage this access to establish authenticated sessions on every single application that Okta provides the user access to. They are also going to abuse Okta SWA to steal valid credentials for whichever applications support this method. And if that’s not enough, there are a variety of simple methods to achieve persistence on most downstream SaaS applications and sometimes even identity providers themselves.

While the full details of these persistence attacks are outside the scope of this article, more details on some key attacks can be found in a resource we created called the SaaS attacks matrix. Some of the most common techniques that apply here are: 

• SAT1004 - API keys

• SAT1022 - Link sharing

• SAT1017 - Ghost logins

• SAT1027 - OAuth tokens

• SAT1033 - Shadow workflows

Suddenly, containing the breach just got a LOT more complicated.

It’s not just application-level lateral movement and persistence to worry about, though. It’s possible the attacker can start moving laterally across other user accounts. If they have selected their targets well, they might even find they have admin access to some downstream SaaS application that has been configured for SAML logins using Okta. For example, maybe they compromise a finance employee who has admin access to their business expenses SaaS application. Then the attacker might be able to use a new technique like SAMLjacking to start attacking other users in a watering hole attack to achieve lateral movement.

Video demo – chaining it all together

OK, so we’ve just jumped from an account compromise for initial access using an AitM phishing attack to bringing up a huge number of other connected techniques. Let’s look at a quick video demonstration of an AitM phishing attack chained together with post-exploitation steps for persistence and lateral movement so we can see how it all fits together.

In this case, we’ll use EvilnoVNC targeting Okta as the core example for the AitM phishing attack:

We can see here that AitM phishing attacks are not only highly effective even in the presence of MFA, but that post-exploitation steps have become so numerous that effective response and containment for even a low-privileged user account are now a significant challenge.

Post-exploitation automation is coming

There is a saying that attacks only become more effective over time. In the past, toolsets like Metasploit and Cobalt Strike became increasingly focused on post-exploitation and automation to enable much more sophisticated compromises.

As AitM becomes increasingly popular (for example, researchers at Lab539 have reported a significant ramp up in attacker infrastructure linked to AitM campaigns it’s only a matter of time now before we see AitM phishing frameworks moving in the same direction and performing many of the lateral movement and persistence steps we saw above – automatically on every successful account compromise. The threat will increase significantly when this becomes the case.

Impact summary

We’ve covered a lot of ground here, so let’s take a step back and consider the key points of impact:

• AitM phishing techniques are highly effective and increasingly common, and can bypass most common forms of MFA.

• These techniques are being used by real threat actors and red teamers alike, with both criminal and open-source tools available for performing these attacks.

• There are many options for lateral movement and persistence after an account compromise, so simple containment actions like password resets for SSO credentials are not nearly enough to contain a knowledgeable attacker.

What can blue teams do about it?

It’s important that organizations develop their capability to detect and respond to AitM attacks. Possible approaches include:

• Move to FIDO MFA where possible (though, if no more susceptible backup methods are enabled, this does introduce operational challenges if passkeys are lost).

• Detect and block known-bad malicious sites used in phishing campaigns. There are many threat intelligence feeds that can be ingested to achieve this. Usually, a domain has to be used in a malicious campaign before it can be catalogued – meaning there's typically a window of opportunity before the infrastructure is burned. That said, security researchers at Lab539 (yes, another shout out) have developed a way of identifying sites running AitM tooling – even before they are used for the first time. You can sign up to get access to their feed here.

• Introduce controls to detect phishing toolkits and cloned websites. You can never rely on blocking malicious sites via TI feeds alone, so additional layers of defence are required. Push customers benefit from detection of AitM toolkits like Evilginx and EvilNoVNC in the browser (more to come on this soon!), while Thinkst Canary has developed methods of detecting whenever your website or login portal is cloned – very cool.  

• Update IR playbooks to to deal with SSO account compromise, factoring in lateral movement and persistence across cloud apps. This really necessitates that you understand what business apps your organization is using, how they are accessed (e.g. SSO or username and password) and what functionality exists that could be abused by an attacker. 

If you want to know more about how Push detects and blocks phishing tools in the browser, you can check out our article here.

Conclusion

We’ve seen in this article how there are multiple ways to perform AitM phishing attacks and how they can be extremely effective at targeting users even when their accounts are protected by MFA. 

Very few organizations are universally using phishing-resistant MFA, such as FIDO-based methods, and even those that do often have fallback options to handle situations where they cannot be used and/or tokens malfunction or are lost. Therefore, the vast majority of organizations are at risk of AitM phishing attacks.

To make things worse, there are lateral movement and persistence techniques that can be exploited to greatly extend the depth of compromise even for a single low-privilege user account. This makes response and containment a significant challenge.

Phishing attacks are clearly evolving. Phishing attacks are no longer limited to email-based delivery mechanisms or being hosted on custom domains. There are many options now for delivering phishing attacks using Slack or Microsoft Teams, using SAMLjacking attacks to host the initial landing page on legitimate SaaS web domains or even using Okta to keylog credentials on behalf of the attacker. 

Increasingly, we should expect to see AitM toolkits being used as a standard part of phishing campaigns, and featured in Initial Access Broker tooling – AitM will effectively supersede legacy phishing methods in line with MFA adoption. Rather, it already is.

If you're interested in seeing some more AitM tools in action, you can watch our recent webinar on-demand via the link below.