How to outsmart MFA Proxy Attacks on Microsoft 365

Since the age-old username and password combination met the computer network, we’ve always known that it does not do well from a security perspective. As cloud solutions from big players such as Microsoft and Google began to take a greater share of corporate data in the 2010s, MFA was the go-to solution and did a good job of protecting data. Of course, security is a cat and mouse game. Once the bar is raised and there are fewer businesses not using MFA, more devious methods are employed by those who want to get at your data.

This article will focus specifically on Microsoft 365 and how you can protect that platform, but the general principles apply to other platforms and MFA methods.

Most Microsoft 365 users currently will use Microsoft’s Authenticator app for MFA. When Microsoft released their app with push notifications, it was very convenient. However, push notifications were abused by attackers who would hope that a victim would press “approve”, either accidentally or because they were fed up with the notifications.

This led to the number matching approach we see currently, where a two-digit number must be entered on the device. This led to the development of the “MFA proxy attack” we are seeing now.

What is a MFA Proxy Attack?

The attacker creates a proxy application (or more likely deploys the freely available source code) and would likely send a link to many thousands of potential victims. The link proxies the genuine Microsoft login page, complete with company branding, names and prompts. It looks just like the real thing. The victim trusts the login page and enters their username and password. The phishing page forwards this to Microsoft and displays the genuine two-digit code to the victim who, having just believed they’ve authenticated with Microsoft, supplies the code.

The attacker then has the code and can obtain a session token to log in as the user. To complete the deception, the user is bounced to the genuine login page and, believing that something went wrong with the login, will log in again and probably be none the wiser as to what’s just happened.

The attacker now has a valid session to Microsoft 365 and will want to persist their access to the platform. They will likely now try to add a new authentication method (such as their own authenticator app) and register a device in Intune.

Note that other MFA providers that use the same pattern for Microsoft 365 and other platforms are similarly vulnerable. This isn’t just a Microsoft Authenticator vulnerability.

How to protect against an MFA Proxy attack?

Obviously, we still recommend using MFA, but what are the different ways for you to protect against this form of attack?

• Go passwordless. Passwordless authentication is not vulnerable to this form of attack and, for cloud-first Microsoft 365 deployments, it is very easy to set up. For hybrid deployments, a little more work is required.
• Use a passkey, such as a FIDO2 token like Yubikey.

These are great ways to implement MFA securely. If you can do passwordless authentication, it can be more convenient to your users and provide security benefits.

FIDO2 tokens have a cost and usability impact. We sometimes see organisations taking a mixed approach, using FIDO2 tokens for more critical accounts such as senior leaders and accounts staff.

But what if you can’t implement the above?

Is there another way?

Firstly, spotting the attack is critical. We have a solution to this in the form of our Kascade Support M365 package. Alongside reactive technical support, it include a proactive element. Using a trusted security-as-a-service provider, we collect and store you Microsoft 365 security logs (but not your actual data) for a year. Our service will look for patterns and anomalies in the logs, such as:

• A user logs in on a device that hasn’t been seen before and then, some time later, sets up a mail forwarding rule.
• A user logs in on a new device from a location outside your normal business regions.

These are just two actions that are unusual for a genuine user to perform and are indicators of an attack. With your consent when setting up the service, the platform will immediately revoke the user’s access and will alert your and our service desks.

Finally, as part of a multi-layered approach to security, Conditional Access can be used to prevent an attacker registering a new device in Entra ID without clearing MFA, and also to prevent registration of new authentication methods from anything other than a compliant device or from a known location.