The Search for the Silver Bullet

Having Multifactor Authentication is a great piece to a multi-layered security approach, but it’s not the silver bullet solution many people believe it to be. Equally as important as having it turned on is configuring it correctly.

Note: This document focuses on MFA for Office365. Pileum also recommends enforcing MFA for server management, critical Information System Admin Access, and all remote access to your environment (VPN).

Enforcing MFA

There are 3 primary ways to enforce MFA:

1. Conditional Access – (Recommended) The most robust method of enforcing MFA. This requires Entra AD Premium P1 licenses for each user. With conditional access, you can create separate policies to address different groups of users. You can also exclude users based on their location. Pileum recommends enforcing MFA using Conditional Access Rules.

2. Security Defaults – (not recommended) Microsoft created Security Defaults as a baseline set of security controls for customers who do not have the appropriate licensing to enforce them otherwise. This is also not recommended since Microsoft’s algorithm determines whether or not to enforce MFA. Pileum has observed multiple compromises where MFA was enforced, but malicious sign ins were allowed because the threat actor signed in 10 times in a row and created a “trusted location or device”.

3. Per User Enforcement – This method (not recommended) allows you to change the status for each user in your tenant from disabled to enabled and then enforced. This is the least robust way to enforce MFA and relies on constant reviews to ensure existing and new users have MFA enforced. Note: Enabled is not recommended because it does not require the user to authenticate with MFA.

Aligning with Best Practices

Not all MFA methods are equal:

“My organization has MFA, but we continue to have accounts compromised by threat actors.”

Best practice for configuring MFA has shifted in recent years as attack methods have become more sophisticated.

Phone Call: (Not Recommended) Users receive a phone call. An automated voice asks them to press the # key to authenticate the request. This is commonly used in MFA Spamming, where a threat actor will initiate MFA prompts repeatedly until the user presses # to “get it to stop”.

SMS Code: (Not Recommended) This used to be best practice, but is commonly involved in incidents. The user receives a 6 digit code via text message and is asked to input that code on the login screen. Pileum has witnessed spoofed login pages created to capture this code. We’ve seen everything from pages that mimic Microsoft OneDrive sign ins to login pages with the target organizations logo.

Push Notification to the MSFT Authenticator App: (Not Recommended) The user receives a push notification to the MSFT Authenticator App with options to press the green or red buttons to allow or deny the MFA request. This method makes it too easy for users to “rubber stamp” approve requests.

App Passwords: (Not Recommended) On by default, users can create App passwords to authenticate to various applications. This is not recommended because App Passwords do not expire, circumvent the need for MFA, and are not affected when a user’s credentials are reset. If your organization does not have a need for App Passwords, Pileum recommends disabling the ability for users to create them. Pileum has observed threat actors creating App passwords to establish persistence in an account.

MSFT Authenticator App with the 2 Digit Writeback Method: (Recommended) When logging in to a legitimate O365 sign in screen, the user will be provided a 2 digit code and prompted to enter that code into their MSFT Authenticator App. This is backwards from the SMS method that asks the user to go to their phone and enter the code back on the sign in screen. This makes it much more difficult to circumvent. This method also allows for a map of the location of the originating request to be displayed to the user in their MSFT Authenticator App. Microsoft has started rolling this requirement out to users who are Global Administrators.

Migrating MFA Policies

Currently, MFA enforcement policies (the legacy policies) are found in 2 locations: Legacy Multifactor Authentication Policy and Self-Service Password Reset Policy.? Microsoft is deprecating these 2 policies and migrating organizations to the Modern MFA policy.? This is simply where you set the policy.? Microsoft has pushed many tenants to “Migration in Progress” and if not migrated by September 30, 2025, they will force the change.

This migration can be made on a 1-to-1 basis, meaning the allowed methods will not change and end users will not be affected.? Pileum recommends all organizations migrate to the Modern MFA Policy as part of their MFA Configuration review prior to September 30, 2025. Note: Check the status of your migration in the Entra Admin Center under Protection -> Authentication Methods -> Manage Migration.

How Threat Actors Circumvent MFA

This list is not comprehensive, but represents the methods most commonly observed by Pileum.

MFA Prompt Bombing: This technique involves sending multiple MFA requests to a user causing alert fatigue and increasing the likelihood that the user will accept the authentication request to stop the alerts.

Login Site Spoofing: The threat actor generates a spoofed sign in website created to capture the user’s username, password, and MFA code.

Session Reuse: Threat actors compromise a system that already has an authenticated session, eliminating the need to reauthenticate. This can be done by exploiting vulnerabilities in the authentication process or by using stolen credentials.

MFA Bypass: This technique is most prevalent in successful phishing attacks. A user clicks on a link or attachment and attempts to authenticate to access a “secure document”. The threat actor harvests those credentials and immediately signs in to the legitimate O365 service, generating a real MFA prompt. The user believes they have attempted to sign in, so they approve the MFA prompt, allowing the threat actor into the account. This is commonly followed by multiple sign ins within that short window after approval to establish a “trusted location or device” within the Microsoft algorithm. Sign in logs typically show a pattern of Failure, Interrupted, Success for this attack.

Additional Security Layers Around MFA

If Multifactor Authentication is one piece of a multi-layered security approach, what else should be in place?

Extended Detection and Response (XDR): An XDR solution ingests data from endpoints, servers, firewalls, and cloud solutions (Office365) to provide visibility into actions taken across an organization’s environment. True XDR solutions will monitor and alert on malicious activity like atypical sign in locations, impossible travel, malicious inbox rules, etc.

Security Awareness Training: User actions lead to 70% of all compromises. You can place as many doors and locks between threat actors and your data as you want, but as long as people have the ability to hand over the keys, they will. Users should be trained to handle sensitive information, recognize social engineering attacks, and identify potential security incidents.

Advanced Email Protection: This solution goes beyond the traditional email security gateways that looks for malicious files and serves as a SPAM filter. Consider a solution that has independent monitoring and alerting for malicious sign ins, has the ability to scan internal emails at the mailbox level to identify impersonation attempts and compromised accounts, and includes incident response capabilities like identifying actions taken by users and removing malicious emails from user inboxes in a matter of seconds / clicks.