security_content
security_content copied to clipboard
[BUG] Azure MFA failure detections logic flaw
There are a number of Azure MFA failure based detections utilizing properties.status.errorCode=500121
as a means of detecting one or more MFA auth failures. There's nothing wrong with this in of itself, however upon noticing a greater number of notables than anticipated with these detections enabled and performing some testing and research I have found the following from here:
Multifactor authentication: When a user signs in with MFA, several separate MFA events are actually taking place. For example, if a user enters the wrong validation code or doesn't respond in time, more MFA events are sent to reflect the latest status of the sign-in attempt. These sign-in events appear as one line item in the Microsoft Entra sign-in logs. That same sign-in event in Azure Monitor, however, appears as multiple line items. These events all have the same correlationId.
Note the last sentence.
Testing confirms that failed MFA does indeed result in more than one event for a single ocurrence of MFA auth. In addition to the above statement, it turns out that the correlationId
can span multiple MFA auth attempts, however the originalRequestId
field is unique for each attempt.
As an example of what this should look like, using Azure AD Authentication Failed During MFA Challenge
as a basis for an updated search:
`azure_monitor_aad` category=SignInLogs properties.status.errorCode=500121
| rename properties.* as *
| stats count, min(_time) as firstTime, max(_time) as lastTime, values(user) as user, values(src_ip) as src_ip, values(mfaDetail.authMethod) as mfa_method, values(status.additionalDetails) as status.additionalDetails, values(reason) as reason, values(appDisplayName) as appDisplayName, values(user_agent) as user_agent by correlationId, originalRequestId
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `security_content_ctime(times)`
| `azure_ad_authentication_failed_during_mfa_challenge_filter`
correlationId
can be thought of as the login session, and originalRequestId
the MFA attempt. count
is effectively useless above, but is left in to hightlight the fact that multiple events are produced for each failed attempt.
It's also worth noting that there is inconsistent data returned by Azure AD. Multiple MFA failures .e.g. MFA denied; user declined the authentication
can yield inconsistent/missing values in status.additionalDetails
between attempts, and either the objectid or actual username (or both!) for the user field.
App Version:
- ESCU: 4.40.0