Unable to repair new Azure Energetic Listing password brute forcing error


Imagine having unlimited attempts to guess someone’s username and password without getting caught. This would be an ideal scenario for a clandestine threat actor – server administrators would have little to no insight into the attacker’s actions, let alone the ability to block them.

A newly discovered flaw in Microsoft Azure’s Active Directory (AD) implementation enables just that: one-factor brute forcing of a user’s AD credentials. And these attempts are not logged on to the server.

Invalid password, please try again …

In June of this year, researchers at the Secureworks Counter Threat Unit (CTU) discovered a flaw in the protocol used by Azure Active Directory’s seamless single sign-on service.

“This flaw allows threat actors to carry out single-factor brute force attacks against Azure Active Directory without generating logon events in the target company’s tenant,” the researchers explain.

That same month, Secureworks reported the bug to Microsoft, who then confirmed that this behavior existed until July, but determined that it was “on purpose”.

This month, Secureworks is making its customers aware of the bug, according to a release reported to Ars by a source.

Secureworks notifies its customers of the Azure Active Directory error by email.Enlarge / Secureworks notifies its customers of the Azure Active Directory error by email.

Ax sharma

The Azure AD Seamless SSO service automatically logs users into their corporate devices that are connected to their workplace network. With Seamless SSO enabled, users do not need to enter their passwords, or usually even their usernames, to sign in to Azure AD. “This feature gives your users easy access to your cloud-based applications without the need for additional local components,” explains Microsoft.


But like many Windows services, the Seamless SSO service relies on the Kerberos protocol for authentication. “During Seamless SSO configuration, a computer object named AZUREADSSOACC is created in the local Active Directory (AD) domain and assigned the service principal name (SPN),” explains CTU researchers. “This name and the password hash of the AZUREADSSOACC computer object will be sent to Azure AD.”

The following Autologon endpoint named “windowstransport” receives Kerberos tickets. And seamless SSO happens automatically without user interaction:

The authentication workflow was demonstrated with the following figure:

Demonstration of the Kerberos protocol.Enlarge / Demonstration of the Kerberos protocol.


In addition, under … / winauth / trust / 2005 / usernamemixed there is a usernamemixed endpoint that accepts the username and password for one-factor authentication. To authenticate a user, an XML file with their username and password is sent to this mixed username endpoint.

XML file with username and password.Enlarge / XML file with username and password.


The authentication workflow for this endpoint is much simpler:

Autologon username / password login process.Enlarge / Autologon username / password login process.


And this is where the mistake creeps in. Autologon tries to authenticate the user to Azure AD using the credentials provided. If the username and password match, authentication is successful and the Autologon service responds with XML output containing an authentication token, known as the DesktopSSOToken, that is sent to Azure AD. However, if the authentication fails, an error message is generated.

It is these error codes, some of which are not properly logged, that could help an attacker conduct undetected brute force attacks.


Error codes that are generated when the autologon authentication fails.Enlarge / Error codes that are generated when the autologon authentication fails.


“Successful authentication events generate login logs … The authentication of the automatic login [step] in Azure AD is not logged. This omission allows threat actors to use the username-mixed endpoint for undetected brute force attacks, “said CTU researchers in their report.

The AADSTS error codes used during the Azure AD authentication workflow are listed below:

AADSTS50034 The user does not exist AADSTS50053 The user exists and the correct username and password have been entered but the account is locked AADSTS50056 The user exists but has no password in Azure AD AADSTS50126 The user exists but the wrong password has been entered AADSTS80014 The user exists, but the maximum pass-through authentication time has been exceeded

Secureworks researchers state that most security tools and countermeasures used to detect brute force or password spray attacks rely on login event logs and look for specific error codes. Because of this, it is a problem not to have any insight into the failed login attempts.

“[Our] Analysis shows that the Autologon service is implemented with Azure Active Directory Federation Services (AD FS), ”explain the CTU researchers. The Microsoft AD FS documentation recommends disabling Internet access to the Windows transport endpoint. However, this access is required for Seamless SSO. Microsoft states that the usernamemixed endpoint is only required for older Office clients older than the Office 2013 May 2015 Update. “

Use not limited to organizations using SSO

The bug is not limited to organizations using seamless SSO. “Threat actors can take advantage of the username auto-sign-in endpoint in any Azure AD or Microsoft 365 organization, including organizations that use pass-through authentication (PTA),” the researchers explain. However, it does not affect users without an Azure AD password.

Since the success of a brute force attack largely depends on the strength of the password, Secureworks has classified the error as “medium” in its description.

At the time of writing, there are no known fixes or workarounds to block use of the usernamemixed endpoint. Secureworks states that the use of Multi-Factor Authentication (MFA) and Conditional Access (CA) does not prevent the exploitation, as these mechanisms only occur after successful authentication.

Ars contacted both Microsoft and Secureworks long before the release. Microsoft did not respond to our request for comment. Strangely enough, Secureworks responded by inviting them to a future online event, but did not comment.

As mentioned above, Microsoft seems to view this as a design decision rather than a vulnerability. As a result, it remains unclear if or when the bug will be fixed and businesses could remain vulnerable to covert brute force attacks.