New Azure Active Directory password brute force flaw has no solution

New Azure Active Directory password brute force flaw has no solution

Imagine having unlimited attempts to guess someone’s username and password without getting caught. That would be an ideal scenario for a stealthy threat actor, leaving server administrators with little or no visibility into the attacker’s actions, let alone the ability to block them.

A recently discovered bug in Microsoft Azure’s Active Directory (AD) implementation enables just that: single-factor brute force of a user’s AD credentials. And these attempts are not logged on the server.

Invalid password, try again and again …

In June of this year, researchers at the Secureworks Counter Threat Unit (CTU) discovered a flaw in the protocol used by the Azure Active Directory Seamless Single Sign-On service.

“This flaw allows threat actors to perform single-factor brute force attacks against Azure Active Directory without generating login events on the target organization’s tenant,” the researchers explain.

The same month, Secureworks reported the flaw to Microsoft, which later confirmed that this behavior existed in July, but decided it was “by design.”

This month, Secureworks is alerting its clients to the flaw, according to a communication shared with Ars by a source.

Secureworks emails customers about Azure Active Directory failure.
Enlarge / Secureworks emails customers about Azure Active Directory failure.

Sharma ax

The Azure AD Seamless SSO service automatically registers users on their corporate devices, connected to their workplace network. With transparent SSO enabled, users will not have to enter their passwords, or usually not even their user names, to sign in to Azure AD. “This feature gives your users easy access to their cloud-based applications without the need for additional local components.” Explain Microsoft.

But, like many Windows services, the seamless SSO service relies on the Kerberos authentication protocol. “During transparent SSO setup, a computer object named AZUREADSSOACC is created in the local Active Directory (AD) domain and assigned the service principal name (SPN)“Explain the CTU researchers.” That name and the password hash of the AZUREADSSOACC team objects are sent to Azure AD. “

The next automatic logon endpoint named “windowstransport” receives Kerberos tickets. And, seamless SSO occurs automatically without user interaction:

The authentication workflow has been demonstrated with the following illustration:

Kerberos protocol demonstration.
Enlarge / Kerberos protocol demonstration.


In addition, there is a usernamemixed end point in … / winauth / trust / 2005 / usernamemixed which accepts username and password for one-factor authentication. To authenticate a user, an XML file containing their username and password is sent to the user usernamemixed final point.

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


The authentication workflow for this endpoint is much simpler:

Login process with automatic login username / password.
Enlarge / Login process with automatic login username / password.


And this is where the fault appears. Autologon tries to authenticate the user to Azure AD based on the provided credentials. If the username and password match, the authentication succeeds and the Autologon service responds with an XML output that contains an authentication token, known as DesktopSSOToken, which is sent to Azure AD. However, if authentication fails, an error message is generated.

It is these error codes, some of which are not logged correctly, that can help an attacker perform undetected brute force attacks.

Error codes generated when Autologon authentication fails.
Enlarge / Error codes generated when Autologon authentication fails.


“Successful authentication events generate login records … However, automatic login authentication [step] Azure AD is not registering. This omission allows threat actors to use the usernamemixed end point for undetected brute force attacks, “the CTU researchers explain in their article.

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

AADSTS50034 The user does not exist
AADSTS50053 The user exists and the correct username and password were entered, but the account is locked
AADSTS50056 The user exists but does not have a password in Azure AD
AADSTS50126 The user exists, but the wrong password was entered
AADSTS80014 The user exists, but the maximum Pass-through Authentication time was exceeded

Researchers at Secureworks state that most security tools and countermeasures aimed at detecting brute-force or password-spraying attacks rely on log-in event logs and look for specific error codes. So not having visibility into failed login attempts is a problem.

“[Our] The analysis indicates that the automatic sign-in service is implemented with Azure Active Directory Federation Services (AD FS), “CTU researchers explain.” Microsoft AD FS documentation recommends disable Internet access to windowstransport final point. However, that access is required for transparent SSO. Microsoft indicates that he usernamemixed the endpoint is only required for legacy Office clients that are older than the Office 2013 May 2015 update. “

Exploitation not limited to organizations using SSO

The flaw is not limited to organizations using seamless SSO. “Threat actors can take advantage of automatic login usernamemixed endpoint in any Azure AD or Microsoft 365 organization, including organizations using Pass-through Authentication (PTA), “the researchers explain. However, users without an Azure AD password are not affected.

Because the success of a brute force attack is highly dependent on password security, Secureworks has rated the flaw as “Medium” severity in its writing.

At the time of writing this report, there are no known solutions or solutions to block the use of the usernamemixed final point. Secureworks claims that using multi-factor authentication (MFA) and conditional access (CA) will not prevent exploitation because these mechanisms occur only after successful authentication.

Ars contacted Microsoft and Secureworks long before publication. Microsoft did not respond to our request for comment. Secureworks responded strangely with an invitation to a future online event, but did not comment on the matter.

As stated above, Microsoft seems to view this as a design option, rather than a vulnerability. As such, it’s unclear if or when the flaw will be fixed, and organizations could remain vulnerable to sneaky brute-force attacks.

Leave a Reply

Your email address will not be published. Required fields are marked *