The Greatest Options to Beat MFA Fatigue

Lately, a lot has been said about the phenomenon called ‘MFA fatigue’. This method of gaining access to someone’s account (we will focus on (Microsoft 365¹ Work/School accounts) plays on the tendency of people to be ‘done with it’ which will make them press that ‘Approve’ button in their authenticator apps at some point. This is especially the case where the Microsoft Authenticator App ‘push notifications’ (without number matching) feature has been configured. Attackers only have to know the sign-in name, which usually is the same as their email address, to start annoying people. And the target only has to press the Approve button on the MFA prompt. Things are different when:

• number matching has been configured on the authentication method.
• a password is required to login and only as a second step the Authenticator App request is sent. (It is unlikely the attacker knows your password, so the Authenticator App request will never be sent)

Focusing on the ‘Authenticator-only’ approach boasted with Password-less sign-in feature, attackers will know that Microsoft is actively monitoring ‘risky sign-ins’ especially for their commercial offerings like Microsoft 365. This happens without the need to have the appropriate licenses for your tenant (Azure Premium P2 at the time of writing). If you don’t have the licenses, Microsoft will still use the data to make their cloud service safer, except you don’t have the insight in whats happening or have some configurable options.
Knowing this constant monitoring of sign-in traffic is happening, attackers will only ‘probe’ accounts with a couple of requests at a time, and they will spread their total attack time-frame over multiple weeks, making the target lose his/her mind in a progressive manner. “Where are those *beep* *beep* pop-ups coming from!?”

So the attack stays under the radar until the target starts complaining to the service desk or administrators in charge of their tenant. Let us hope they make that effort…

How to mitigate the ‘MFA Fatigue’?

Yawn… Approve!

Not an option…

You might expect that you can change some Azure AD Conditional Access policy to change the behavior, but since these policies only have effect after a successful sign-in, they are of no use mitigating MFA fatigue.

Option 1

The simplest method would be: do not use a Password-less (especially the push notification (without number matching)) sign-in feature as the only authentication method for the targeted account. Instead make use of either the password, certificate or FIDO2/Windows Hello methods as a first factor and use the authenticator app prompt as a second factor only (Read more). This will stop any annoying immediate Authenticator App notifications, because the attacker needs to comply with the first factor in the authentication sequence before the target gets prompted in the App. The suggested first factors are ‘silent’ to the user and the attacker is unlikely to have knowledge or access to this factor
With regards to the first factor ‘password’ option you might say: “Well but that is a terrible experience!”Indeed it is: it makes the login processes lengthy again and weren’t we about to phase out passwords forever?
So requiring the use of FIDO2/Windows Hello or Certificate Based Authentication (CBA) as a first factor is highly recommended here. This option is most definitely the most silent method for the user, but will require additional configuration and maintenance for admins…

Option 2

At least enable ‘number matching’ on the ‘authentication method’ configuration blade. This way even if the Authenticator prompt occurs (still annoying) the target won’t have a clue which number (from 1 to 99) has to be inputted and will most likely deny or ignore the request.

Last week Microsoft introduced additional Authenticator App authentication method policies. Number matching can now be enabled on the ‘push notification’ method, which I highly recommend to enable immediately for everyone, even though the feature is in preview.

Option 3

Now for the elephant in the room. The reason we are all in this ‘MFA Fatigue’-drama all comes down to an architectural decision Microsoft made in the time when the cloud landscape was born (somewhere around 2007-ish, I guess). The company decided it would be a good idea to make the ‘sign-in name’ (aka User Principal Name (UPN)) that everyone would use to gain access to the cloud environment the very same as the ‘email address’ (‘SMTP:’ proxyAddresses or SIP) that the whole world can ‘know’ in an instant and is highly visible. All for the sake of ease-of-use, security-by-design was not a thing back then, clearly (is it now??)…
Technically it would be possible to have these properties have separate values, but even Microsoft says this will have some nasty side-effects and will certainly ruin the Microsoft Cloud experience for users. So that’s really not the way to go, at least at the time of me writing this piece, anyway.

So our only option, for now, is to change both UPN AND the primary SMTP address and make it more difficult for attackers to know the sign-in name, before they eventually track it down. Except of course when the attacker is in close day-to-day contact with the target, they will pick up the new sign-in address immediately. Therefore I will assume that the attackers are using email addresses they found in some online database and are not directly connected to the target.
Furthermore the original email address of the target must still remain operational, so we need to create a ‘good old’ Distribution List for that email address, with the target as its only member AND have the target setup with ‘Send As’ permissions so they can still send emails using their old email address. Be careful NOT to use the ‘old’ email address as an account ‘Alias’, because it is very easy to find the actual UPN of anyone when you know only one account alias. Which is yet another major architectural oversight by Microsoft².

WARNING
One big, possibly disruptive factor is that the account will have its OneDrive address changed because of the UPN change (ie. https://contoso-my.sharepoint.com/:f:/g/personal/bgates_contoso_com/). Content and Shared Links will remain, but the links will have a slightly different URL and ‘old’ links will not be resolvable. This might be a problem if this targeted user has a lot of private Teams Chats and shares a lot of files in this/her OneDrive.

So, in any case make this change after business hours as email flow is disrupted for a short while to the target’s original email address.

The procedure looks like this:

1. Microsoft 365 admin center: Change the targets Primary email address and username (UPN) to something that was not already an Email Alias
2. Microsoft 365 admin center: Remove the previous primary email address as an Email Alias
3. Exchange admin center: Change the targets Alias (found under ‘Manage contact information’) to the UPN minus the ‘@domain’ part.
   1. NOTE: This is NOT in email address format
4. Exchange admin center: Change the SIP address (found under ‘Manage email address types’) to the same value as the new UPN
5. Exchange admin center: make sure there is no trace of the ‘old’ UPN (found under ‘Manage email address types’)
6. Wait 5 minutes!
7. Exchange admin center: Create a new Distribution List, where:
   1. the original (old) email address of the target is configured
   2. target user should be its only Member
   3. both messages from people inside and outside my organization should be accepted
   4. target user should have ‘Send As’ permissions
   5. joining and leaving the group should be set to ‘Closed’

INFO
While existing Authenticator App entries will still work for the account, the wrong (old) UPN is displayed in the App, so the user should enter the Microsoft Account ‘My Sign-ins -> Security’ page and remove any old Authenticator App entry (both on that page and in the Authenticator App) and re-add using the new UPN.

INFO
While configured desktops for the user will automatically adjust all Microsoft 365 Desktop Apps and OneDrive to use the new UPN (Nice!), things are different in the mobile space. Any Mobile App that is configured for/by the user (Outlook, SharePoint, Teams, etc.) might need to the account re-added as well, because the old UPN will linger there. Single exception here is the OneDrive App, I found, which will (after a crash) show the correct UPN.

The user should inform close contacts OUTSIDE of the organization of their email address change. Alternatively the user can also opt to keep sending emails from their original email address, but he/she would probably need instructions how to do that.
The ‘Send As’ function in the Outlook Web App is very easy to use when the ‘From’ field is shown on a new message, but it does require discipline as you can not set the default FROM address to a Distribution List, sadly.
An inventive Exchange Admin could imagine to setup a ‘mail flow rule’ (aka transport rule) to change the ‘Reply-To’ header of each mail sent from this user, but alas, this will not work as well.

Parting words

There you have it! Despite the mentioned repercussions this method of mitigating ‘MFA fatigue’ might be worth it for some and not for others. At least for a time attackers won’t know the sign-in address to spam.

It would be nice if Microsoft at some point acknowledges the underlying fundamental flaw of the current Cloud sign-in scheme and decide to separate the sign-in address from the regular email addresses of users and thus having the option to always, without notification or disturbing ramifications, change the sign-in address of any user on a whim.

1. Microsoft 365, formerly Office 365, is a line of subscription services offered by Microsoft which adds to and includes the Microsoft Office product line. The brand was launched on July 10, 2017, for a superset of Office 365 with Windows 10 Enterprise licenses and other cloud-based security and device management products. ↩

2. Try this out: start Microsoft Teams and enter the ‘Chat’ area. Start a new chat and type in an email address (or alias) of someone you suspect of having a Microsoft 365 account but is not already in your contact list. Select the option of Searching for the contact externally, but do NOT start typing a message. Instead take a look at the contact card of the person you are ‘contacting’ by hovering over the name. This will show the actual UPN under the Contact section. So now you have the Sign-in name without the target knowing… ↩