Added UserEmailMFA Inspector

[NegativeNine]

Added a module to check for users with Email as a registered MFA method.

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1206640223435709

[NegativeNine]

Hello @paulihme and @ThoughtContagion, this is Evan from Arrow Team. Looking to start contributing to this project, I have read your Contributing Guidelines and think this pull is in compliance.

The finding might need to have the severity adjusted to Medium. I set it at High since having an MFA registered implies the user intends to have a second factor and it arguable that Email does not qualify since the email may only have single factor.

[ThoughtContagion]

Hi there!

Thank you for contributing to 365Inspect! Currently Email MFA authentication is used strictly for the Self Service Password Reset (SSPR) functionality and is a required authentication form.

Supported MFA methods can be found at What authentication and verification methods are available in Microsoft Entra ID?

In verifying this we registered an account with email and Authenticator MFA methods

When querying that user, you can see that the user is capable of MFA and SSPR

We then removed all methods other than email

Querying that user again, we see that they are no longer MFA or SSPR capable

Any subsequent login is then directed to register an MFA method

We would recommend, based on the functionality of the various authentication methods, changing this function to look for users that only have email as MFA methods. This scenario should not be a normal finding, as any other methods would need to have been removed by either the user or an administrator. At that point, any successful login will be prompted to register an MFA method and attackers may abuse this to add attacker-controlled MFA methods to the target account.

$Users = Get-MgReportAuthenticationMethodUserRegistrationDetail | Where-Object {$_.MethodsRegistered -eq "email" -and ($_.MethodsRegistered).Count -eq 1} 

$results = @()

Foreach ($user in $users){
    $results += "User: $($user.UserDisplayName), UserPrincipalName: $($user.UserPrincipalName), IsAdmin $($user.IsAdmin)"
}

Return $results

[NegativeNine]

Hey, thank you for the feedback!

I see some older documentation that suggests Email OTP is required for SSPR, but I believe that this is not longer the case. Neither documentation you linked states Email OTP is required for SSPR.

I ran the following tests to confirm:

Scenario 1: MFA policies: Email OTP Policy is enabled

Registered Methods: App, SMS - No Email MFA configured SSPR Response: Allowed using non-email MFA.

Scenario 2: MFA policies: Email OTP Policy is enabled

Registered Methods: App, SMS + Email SSPR Response: Allowed to use Email as a MFA method

Scenario 3: MFA Policies: Email TOP is disabled

Registered Methods: App, SMS + Email. Note that Email OTP is disabled by policy. SSPR Response: User is allowed to SSPR using App or SMS, but not email.

I think there are two Inspectors here. One that detects that SSPR is accessible using email MFA, and another that detects if any accounts are at risk due to the attack you described. I ran a few tests with your code and found a case where the user only had Email OTP registered but was unable to use SSPR due to the error below. This is due to Email OTP being disabled in policy. I think these inspectors can be improved further by only trigger when Email OTP is not disabled by policy.

Let me know your thoughts.

[ThoughtContagion]

We have continued testing this scenario and have come to conclusion that it is not possible to leverage only email as a multifactor authentication method. While users may register email, there is no method for selecting email as the primary/default/preferred method. Any attempted login when email is the only registered method prompts a user for additional information and registration of another method.

While it does appear that Microsoft may have removed some specific language surrounding this, there is a current list of supported methods here

[NegativeNine]

You are correct that Email is not a valid MFA option for regular authentication. SSPR had previously required Email to function, which has since been removed as a requirement. SSPR uses the users configured MFA as well as Email (If configured and allowed by tenant config). Normal authentication (Non-SSPR, used to actually get a access token) uses MFA and does not allow Email even if it is configured for the user and allowed by the tenant.

The check at a minimum should be retooled to "SSPR Allows Email Authentication" but at this point this check is probably more noise than useful. Let me know if you want me to rework this to an SSPR check, otherwise feel free to close this and I'll create the check for accounts that only have Email enabled and are SSPR eligible.

[ThoughtContagion]

We do believe there is some value to understanding what is and is not enabled/allowed on a tenant. If you also believe that this information could be useful, even in a purely informational scenario, please feel free to adjust your Inspector to reference SSPR and Email MFA. Additionally, as per our earlier conversation, we do believe that there is a secondary Inspector that came from this PR and that will be added in a future feature update push.

Thank you for being a supportive member of the community and participating in the development of this tool!