This is part 3 of Identity Crisis.

“But we have MFA.”

Multi-Factor Authentication (MFA) is great, but not perfect. It’s way better than only using passwords, because it requires the attacker to control an additional item, such as a OTP (one time password) generator, a special app that receives push messages to confirm the login, a certificate, or hardware token, etc.

But, shockingly, when customers send us their telemetry in parallel to their current SOC, we immediately see suspicious logins despite the deployment of MFA … and usually their current SOC doesn’t alert on these at all!

To put it bluntly: MFA is not stopping compromised logins.

#Real-Time Adversary-In-The-Middle (AITM)

I have been in cybersecurity long enough to remember: A) we used to call it “infosec” (some of the old guard still do), and B) cybersecurity OG (original guru?) Bruce Schneier predicted real-time AITM attacks would be successful against MFA—TWENTY YEARS AGO (!) way back in 2005, with his first real-world observation a year later in 2006.

Here are a few excerpts of what Bruce said, back in 2005:

Two-factor authentication isn’t our savior. It won’t defend against phishing. It’s not going to prevent identity theft. It’s not going to secure online accounts from fraudulent transactions. It solves the security problems we had ten years ago, not the security problems we have today…

Here are two new active attacks we’re starting to see:

– Man-in-the-Middle Attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank’s real website. Done right, the user will never realize that he isn’t at the bank’s website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user’s banking transactions while making his own transactions at the same time.

– Trojan attack. Attacker gets Trojan installed on user’s computer. When user logs into his bank’s website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

See how two-factor authentication doesn’t solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.

The real threat is fraud due to impersonation, and the tactics of impersonation will change in response to the defenses. Two-factor authentication will force criminals to modify their tactics, that’s all.

Two-factor authentication is not useless. It works for local log-in, and it works within some corporate networks. But it won’t work for remote authentication over the Internet. I predict that banks and other financial institutions will spend millions outfitting their users with two-factor authentication tokens. Early adopters of this technology may very well experience a significant drop in fraud for a while as attackers move to easier targets, but in the end there will be a negligible drop in the amount of fraud and identity theft.

The second attack vector that Bruce calls a “Trojan attack” is precisely what InfoStealers are, as mentioned in the previous post in this series.

#Architecture of a Real-Time Adversary-in-the-Middle Attack

While there are many technical approaches to doing real-time AITM against MFA logins, the prevailing method today is to simply host a malicious reverse proxy wrapping a legitimate login page, then scrape the credentials and session tokens out of the proxied requests and responses, to be used elsewhere to commit fraudulent logins.

Originally developed as Red Team tool, Evilginx is a very popular open source AITM toolkit that makes this super easy to setup. As a result, like many “red team tools”, it’s also frequently used by actual bad actors to carry out actual BEC (Business Email Compromise) and Ransomware attacks. Evilginx also recently got an upgrade to a paid “pro” version as well.

Think of the malicious reverse proxy like a picture frame, wrapping the real login page as shown on the left in the diagram below. To the victim, it appears polished and legitimate. But turn it sideways and break it apart and you can see the frame is fake, unnecessary, and all the attack surface needed to steal the credentials. The reverse proxy server has access to plaintext credentials and all session tokens and cookies generated by the authentic login form.

How real-time adversary-in-the-middle attacks work.

An attacker doesn’t need to interactively carry out this attack; simply setup the reverse proxy, build the social engineering lure to get a victim to visit the reverse proxy, and send the phishes. When the victims login, new sessions are created and waiting for the attacker to come back and harvest at their own leisure.

#Why Non-Interactive Access Matters

Coincidentally, in one of our Success Stories, we detailed how an attacker stole an accountant’s Microsoft credentials, but we contained the attack in just 214 seconds, start to finish. Unfortunately in that case, we cannot know for certain how the user’s credentials were stolen, but the attack bears all of the hallmarks of a real-time AITM phish. Because these attacks are not interactive, the fact that Wirespeed MDR is so fast at triaging, confirming with the victim over ChatOps, and containing the access by killing active sessions and guiding the victim to reset their password, this means we’re faster than the attackers can likely get hands-on-keyboard and interactively triage the access from our customers’ stolen credentials. This is huge, especially considering it was an accountant, who is ripe for BEC (Business Email Compromise).

We suspect this was a real-time AITM phish, but we contained it in 214 seconds!

I always like to think of the real-world, day-in-the-life aspects of attacks like this. Just like a fisherman dropping some trolling lines and nets to return to hours later, the attacker in this story likely spun up that infrastructure a few days prior, spent a bunch of time getting the domain reputation and categorization of the domain perfect, so that corporate web filters would allow victims to browse to it, then perfected the phishing lure, sent them out, and came back much later, going one-by-one through the list of “bites” on the lure, only to get to our victim, the accountant, whose credentials were rotated and sessions killed. I like to imagine the frustration the attacker experienced, because all of that work setting up infrastructure is for a short timespan before the domain ends up in block lists and is no longer valuable. Let’s cause those attackers some pain!

#How MFA Actually Muddies the Waters

So, we know MFA isn’t stopping the compromised logins, just as Bruce Schneier warned us 20 years ago.

But, it may actually be even worse: MFA may introduce confusion in detecting suspicious logins. Taking Microsoft 365 as an example, when Microsoft’s ITDR (Identity Threat Detection & Response) products, Azure Protect ID and Defender for Identity, detect something unusual, such as a new geographic location, new IP address or ASN (network block owner of the IP address), Microsoft will trigger a “risk based authentication policy” which prompts for MFA. We suspect but cannot prove for certain (yet) that there are conditions in which Microsoft will detect something is unusual about a real-time AITM attack, require the user passes MFA, and then lets the user successfully complete the login.

In those cases, we’ll see this value on Microsoft’s detection:

RiskState: remediated,
RiskDetail: userPassedMFADrivenByRiskBasedPolicy

So it appears to be a strongly authenticated session, but is it? We’re not alone at second-guessing these. Joe Stroker on X also sees confusion detecting these attacks:

Defender XDR auto remediates any incident when an MFA claim is present in the token. The system is not yet smart enough to differentiate between a stolen token and a valid MFA claim…

Keep in mind, a stolen session token from a real-time AITM attack will have the “MFA claim,” an attribute that basically says treat tis long random password known as a session token as the equivalent of an MFA token, therefore, a real-time AITM attack certainly creates detection challenges, also.

#FIDO2 Passwordless

All of these weaknesses of common MFA solutions are the reason we hold out hope for the FIDO2 family of authentication schemes (e.g. passkeys). The short version of why they work is the same reason why the ssh client has been safe for years: they pin credentials to a specific host domain. Just like ssh will ask you to confirm the fingerprint of the encryption keys of the server on first use—and if that key changes, ssh won’t let you connect, FIDO2 pins passwordless public-key encryption based credentials to a specific domain. When an attacker spins up evil.com to reverse proxy office.com where your corporate credentials log you in, the fake evil.com site won’t work, because your credentials are pinned to the actual office.com domain and your browser isn’t talking to it.

#Back to Reality

But while we wait for everything to adopt FIDO2 (and fully acknowledging there will be other attacks after that completes), find yourself a security partner who knows all of this detail, can make it simple for you, and can quickly triage these cases as fast as we an. This is also why we took an entirely different approach to this problem, leaning into your user community, and democratizing alert verdicts with ChatOps.

Come check it out for yourself.

---

Want to learn more about how Wirespeed can make security painless for you? Contact us to start a FREE TRIAL today.