How to Check Office365 Accounts for MFA

By Kevin Keathley

Recently there was a case reported where an organization (Hamilton, a city located in Ontario, Canada) was denied insurance claims for a cyber attack due to lack on proper MFA. You can read about it here (https://globalnews.ca/news/11313018/hamilton-cyberattack-cost/). This is only the beginning of such denials, and it has become even more important for organizations to alert on improper MFA configurations.

At Fluency, we focus on detecting configuration changes in real time through audit events, rather than relying on annual or periodic reviews. This approach allows security teams to address problems immediately before attackers can exploit them.

Method 1

One method to detect changes is through EntraID audit logging. EntraID is the rebranded name for Azure Active Directory. If you had one, then you most likely have the other. There is a Sigma rule available if that is your option (microsoft3656_disabling_mfa), but for everyone else, here are the details:

Service: Audit M365 (Azure AD)
Select on Operation: contains “Disable Strong Authentication” or field “Disable Strong Authentication.” (don’t forget the period if you are using an exact match.

What this alert does is warns whenever an admin disables MFA. This should never be done when the organization’s policy is to require MFA. 

Method 2

Another method, which is more likely, is when the user deletes all of their MFA methods without specifying a backup. While a correctly policied organization should not allow this, it could slip through during unexpected changes or updates, for example. For this method, you will also want to look at the EntraID/AzureActiveDirectory audit logs. Technically, this is a holdover from pre-EntraID, but it still exists for the time being. Just note that eventually it will be changed as EntraID is moving away from Type numbers to Type names.

Select on Operation: contains “Update user” or field “Update user.”  (again, don’t forget the period if you are using an exact match.
Select on ModifiedProperties.Name:  contains “StrongAuthenticationMethod
ModifiedProperties.NewValue must not contain true

A typical change looks like this:

"ModifiedProperties": [
      {
        "Name": "StrongAuthenticationMethod",
        "NewValue": "[]",
        "OldValue": "[\r\n  {\r\n    \"MethodType\": 6,\r\n    \"Default\": true\r\n  },\r\n  {\r\n    \"MethodType\": 7,\r\n    \"Default\": false\r\n  }\r\n]"
      },

You could also check to see if NewValue is empty depending on how your SIEM passes it through. If there are MFA methods chosen then one of them will be a default and contain “true”. Therefore, having no “true” value in there means no default MFA method, allowing the user to login without any. 

Please remember how important having MFA enabled and required is to your organization. It may not just be an inconvenience or lead to a compromise. It may lead to your insurance provider refusing payment. If you need a powerful AI-backed SIEM to help you with this and other issues, you can also count on Fluency.