Assume Breach: Securing MFA Registration in Entra ID
One of the most crucial security controls in Microsoft Entra ID, alongside the implementation of Multi-Factor Authentication (MFA), is managing the conditions under which users can initially register or modify their MFA methods. Why is this important? Primarily because it's not realistic to assume that all users will proactively complete their MFA registration especially when organizations introduce various exceptions or conditions that only selectively require MFA (unfortunately a common scenario).
A highly effective approach to deploying MFA within Microsoft 365 environments is through Conditional Access policies, which allow granular control over MFA enforcement under specific conditions. However, a challenge arises when users never encounter conditions that trigger their initial MFA registration due to such policy exceptions. For instance, many companies implement policies requiring MFA only when users access resources from untrusted locations. Practically, this means users who always work from trusted or known locations may never be prompted to register for MFA if additional policies enforcing MFA registration are not implemented.
This situation creates a vulnerability where an attacker who manages to compromise user credentials could potentially register MFA methods on behalf of the legitimate user. Therefore, it's crucial to strictly control MFA registration. One option is creating a Conditional Access policy that requires MFA specifically when accessing the Security Info Registration page.
Control security information registration with Conditional Access | Microsoft Learn
However, this introduces a chicken-and-egg problem: how can a user perform MFA registration if MFA itself is required to access the registration process? A practical solution to this scenario involves the Temporary Access Pass (TAP). TAP provides a temporary password that allows users to bypass MFA requirements temporarily, enabling them to register their MFA method securely even from untrusted locations or devices.
However, the primary focus of this blog is not the initial registration process itself, but rather the potential exploitation of MFA registration policies. Adopting a Zero Trust mindset means embracing the "Assume Breach" principle. With this perspective, let's consider a scenario where an attacker employs an Adversary-in-the-Middle (AiTM) attack to steal session cookies containing MFA tokens.
How does this look in practice? Here's a demonstration showing login attempts through a phishing page. Hint: One login attempt is legitimate, while the other is fraudulent. Can you spot the difference?
The URLs are deliberately obscured to make it impossible to identify which page is legitimate and which is phishing. While there are several methods to stop such attacks, our focus here is on the Assume Breach strategy and specifically on preventing attackers from maintaining persistent access after an initial breach. Typically, after successfully stealing session tokens, attackers aim to secure persistent access. As previously mentioned, the policy designed to protect users in this scenario is a Conditional Access policy requiring MFA for security changes.
But does this policy truly protect us in the described scenario?
As demonstrated, even with this Conditional Access policy in place, the attacker successfully added an additional MFA method. Why? Because the attacker already possessed a session token previously authenticated through MFA.
Personally, I prefer a Conditional Access policy that blocks access to Security Info Registration unless specific conditions, such as trusted devices or trusted locations, are met.
The challenge with this policy is that it does not allow the use of TAP as a bypass option, as mentioned earlier. Whether this limitation is a showstopper is up to you to decide.
Of course, this represents just one potential exploitation scenario among many, and it should never serve as the sole control measure. The goal of this blog was primarily to highlight the importance of adopting an Assume Breach approach, prompting us to consider scenarios from the perspective of what an attacker could potentially achieve in our environment and how we can proactively prevent it.
The phishing demonstration shown in the blog was conducted in a controlled environment using Evilginx, an open-source tool created by Kuba Gretzky.