In-Depth

Why Your MFA Isn't Good Enough

• 10/11/2024

For years the cybersecurity industry has been banging the Multi-Factor Authentication (MFA) drum. "Identity is the new perimeter" and "just username and password aren't secure" and "they were compromised due to lack of MFA enforcement" are common refrains, and thus many businesses and organizations have adopted some form of MFA.

Most start with administrative accounts -- after all they have the keys to the kingdom and are the most attractive targets for attackers -- but then hopefully move on to deploying MFA to everyone. In the Microsoft world the easiest option has been the free Authenticator app, with push notifications, which indeed has been the default and only option if you use Security Defaults in a Microsoft 365 tenant. These push notifications used to be "approve" or "deny" only, but now prompt you to enter the two-digit code on the screen (to add some cognitive load to stop people just pressing approve out of habit), as well as show you which app the MFA prompt is for, and the general geographical location where it's coming from.

However, it turns out that MFA still isn't deployed broadly enough, and even more crucially, the above method isn't "phishing resistant" and will still get your user accounts compromised, given the right attack flavor.

There's also a huge increase in identity attacks, driven in part by the rise of Single Sign On (SSO), where users sign into Okta or Entra ID once, and then access SaaS (and other) apps they have been granted access to, without having to login to each of them. That also means, however, that if an attacker compromises that SSO sign-in, they have access to all the apps the user has access to, and can set up various persistence mechanisms, even if they're kicked out of the SSO account. Plus, many apps don't support SSO, or it costs extra, so in most businesses the "sanctioned" apps that IT manages are just the tip of the iceberg of all the other apps that users use, where they have separate (more vulnerable) logins.

Many businesses think that having rolled out MFA broadly and adopted SSO protects them against phishing attacks, but the reality is that while it's vastly superior to passwords alone, criminals have adapted and it's not as efficient a control against phishing as they may believe.

In this article I'll look at the different types of MFA available, how you can use them in a Microsoft context, and the pros and cons of each. I'll then deep dive on the attack type that criminals are adapting to bypass MFA called Attacker in the Middle (AitM), it's cousin Browser in the Middle (BitM), and I'll cover the details of a successful breach at one of my clients by just such an attack.

Authentication Strength -- Loki or Hulk?
Proving who you are to a computer system is something we've been dealing with since the first mainframe computers started their invasion of businesses. The familiar username and password dance has one huge benefit: Everyone knows how to do it. The problem, however, is threefold -- users routinely use poor, easily guessable passwords and they reuse them for multiple sites / services / systems so that when one is breached, the attackers will try the same combination on other sites. Finally, the password (or a hashed version of it) is stored in the service, so that when breached, thousands or millions of credentials are leaked for attackers to get their grubby mitts on. Popular attacks against passwords are credential stuffing, taking leaked credentials from other sites and trying them on another service, and password spray, trying very common passwords infrequently (so as not to trigger lockouts and other defenses) against many accounts -- sooner or later you'll find someone who's using "starwars", "qwerty" or "Password1."

Adding a second factor raises the game considerably and is always better than just username and password by itself. A common one is SMS text messages sent to your phone (or more rarely, an automated phone call). The problem here is that you're now outsourcing your second factor (something you have, rather than something you know) to your telco. And they don't really take that responsibility seriously, routinely allowing / falling for SIM swapping -- where someone else takes over your phone number, and thus receive the text messages destined for you. The overall telco infrastructure was also not designed with security as the highest priority, opening many avenues for attack.

Which brings us to authenticator apps. All the major ones are interchangeable, so that you can use Microsoft's authenticator to manage your Google sign-in and vice-versa. These remove a lot of the dependency on the telco, as they're tied the security chip in your phone and only require internet connectivity for exchange authentication prompts. The one problem as mentioned, however, is that when you add a service, for example Microsoft 365, it's not bound to only work on that site. This is commonly referred to as phishing resistant, and authenticator apps aren't. And if an attacker can trick a user into entering their username and password on a site that looks like the real one, as well as accept the MFA prompt they can grab the relevant artefacts (see below).

Finally, the Hulk of authentication strengths uses WebAuthn which is part of FIDO2 (Fast IDentity Online), which manifests in hardware USB keys such as YubiKeys, Windows Hello for Business and Passkeys. These authentication methods are "locked" to the authentication site that they're registered for and thus won't work if the user is tricked into visiting a site that looks authentic but isn't.

The challenge here is twofold. Windows Hello for Business requires specialized hardware and deployment, whereas FIDO keys aren't cheap, and you'll likely need to issue two to each user to make sure they can still login when they've left a key at home or lost it. Passkeys, which uses your smartphone to do the same thing as a FIDO key does, side steps the cost of the hardware keys, but is new tech and not all identity providers and services support them yet. Long term, passkeys will be the best solution, but that's a few years off yet.

And remember, it's not just implementing phishing resistant authentication, it's also having strong processes for registering the methods in the first place, and secure approaches for resetting when users lose their FIDO key or smartphone. Plus, most organizations leave a "downgraded" method available for users for the situation where the strong one isn't available, something attackers incorporate in their frameworks, so you'll need to not only demand phishing resistant identities, but that needs to be the only option.

Attacker in the Middle
The adoption rate of MFA has forced attackers to adapt, which has given rise to phishing kits or frameworks such as the open-source flavors EvilGinx, Modlishka and Muraena and many "proprietary" (what's the name for software that's only sold to criminals?) packages such as Naked Pages.

These all work as a reverse proxy, standing up a site that you register with a URL and certificate, which is the phishing link you need to trick users into clicking. Most kits help with this bit as well, creating believable phishing lures that present a plausible reason for users to click that link. Once they visit the site, it's proxying between the fake site and the real one, so when the user inputs their username and password, that's sent on to the real login site (which the victim doesn't see), and thus when the MFA prompt is raised the user can enter their six-digit code or approve the prompt. This is why this is called Attacker in the Middle, as the criminal is sitting in-between the user and the legitimate site. And once the user has successfully signed in, the attacker has the session token and can do everything a user can, establishing various other methods for persistence, depending on the compromised service.

Traditional defenses aren't useful here. Endpoint Detection and Response (EDR) on the endpoint isn't going to see any malware or suspicious processes, as it's all happening in the browser. And while a Threat Intelligence (TI) feed will give you domains and IP addresses to block, modern phishing kits automate a lot of their creation and do it very quickly, making it hard for TI to provide protection in a timely manner. Teaching your users to check if the URL is legitimate is a popular recommendation, but honestly, URLs were never designed to be validated by humans, and this is a huge burden to place on busy end users.

AitM kits have some benefits, they're easy to get started with, and they scale well, you can spin up VMs with multiple sites and accommodate hundreds of simultaneous visitors victims. They're not infallible, and the large identity providers are continuously adding code to their sign-in flows to spot when a sign-in request is coming from a fake site, rather than an end user, which the kit developers in turn attempt to work around. For some real-world statistics on AitM see this blog post by Lab539.

Browser in the Middle
A cousin of AitM kits is Browser in the Middle, such as EvilnoVNC, which creates a remote desktop connection from the attacker's browser, into the victim's browser. To the end user it looks like they're signing into the legitimate site, because they are -- it's just happening on the attacker's system, not on theirs. This is much harder to protect against from the identity providers side, as it's a legitimate sign-in, coming directly from the end user and it's not being proxied through a fake site. One reason these are (so far) less popular than AitM kits is that they don't scale well. The criminals need to maintain fleets of VMs or docker containers that victims connect to. As an end user you might also spot these if you happen to resize the browser window, for example, as this might reveal the artefacts / tearing that often happens with remote desktop tech. I do think however as phishing resistant MFA (passkeys in particular) become more prevalent BitM attacks will increase as AitM decreases in importance as they can't defeat it.

Luke Jennings, vice president R & D over at Push Security, recently wrote an excellent blog post on how modern AitM kits (in this case Naked Pages) evade detection. It's an illuminating read, but in essence it uses Cloudflare workers (small pieces of serverless code running at the edge) as the first point of contact, which gives them a reputable domain, not one that was recently registered. Next, they use Cloudflare Turnstile (like Captcha's but better) to weed out bots, including security software looking for malicious activity. And after that, the request reaches the suspicious domain, but it's looking for specific URL parameters and custom headers, again blocking security agents who don't deliver the right ones. This also requires JavaScript execution, meaning a scanner that uses HTTPS requests and inspects the replies isn't enough. A full dynamic sandbox is required to spot the malicious activity. If you are a phishing victim who clicked a link, you'll supply all the right values, but anyone else will simply be redirected to example.com to obfuscate the phishing site.

Next the kit uses a HTTP referrer masking service (href.li) to make sure an eagle-eyed end user isn't seeing any "weird" domains as they're being redirected. Next, the kit uses a set of gateway servers that'll redirect to a new URL, along with an authentication parameter, so that when sites are identified as malicious the attackers can simply delete these and add new ones, without having to change the links sent in the phishing lures. A random HTML title is added (so that defensive solutions can't filter on specific titles), and once all of this happened (within a very short amount of time), if the users uses a personal Microsoft account, they're redirected to the legitimate page, and only if they attempt to login with a business M365 account is the AitM described above invoked.

In short, the bad guys are using the same tech building blocks we all use for modern cloud computing, just in a malicious way.

A Successful Phish
A few weeks ago, a user at one of my clients texted, then called me. She was locked out of everything and asked (a bit sheepishly) if it had anything to do with a link she'd clicked earlier. I immediately killed all her sessions, reset her password and checked if any new MFA methods had been added to her account, or any email forwarding rules created (no on both accounts). Here's the actual email she was sent:

A part of this lady's tasks is signing these types of contracts, so this wasn't an unusual process for her, which is probably why she fell for this lure.

The reason her account was locked was due to Automatic attack disruption, a feature of Microsoft Defender XDR, which had correlated the signals from the phishing link click (and another user receiving the same email and flagging it as phishing) and the subsequent activity to automatically disable her account. It's the first time I've seen the feature in action for real, which was cool, but I was a little disappointed in the speed. From the initial click to her account being disabled was about 75 minutes, which is a bit too long.

This client is using Microsoft Authenticator push notifications as their MFA method (not phishing resistant, a meeting is booked to discuss adopting YubiKeys for everyone). After she created a new password, I made sure she had access, and then I investigated email and file access / downloads during the time period with no suspicious activity found, leading me to conclude that we dodged a bullet.

Conclusion
There's a lot of money to be made stealing credentials, and as we improve our defenses, the criminals will be improving their attacks to continue succeeding. Having strong authentication methods is half the battle (I've purchased YubiKeys for the admin accounts for all my clients), but there's also user training, and processes for account recovery to consider. Don't be complacent. Just like username and password weren't secure enough a decade ago, most methods of MFA aren't secure enough today, and you need to adapt to remain secure.