New Azure Active Directory brute force password flaw has no solution

Imagine having unlimited attempts to guess someone’s username and password without getting caught. This would be an ideal scenario for a stealthy threat actor, leaving server admins with little to 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 allows just that: one-way hard forcing of a user’s AD credentials. And, these attempts are not connected to the server.

Invalid password, try again and again …

In June of this year, researchers at 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 in the targeted organization’s tenant,” the researchers explain.

That same month, Secureworks reported the flaw to Microsoft who then confirmed this behavior existed in July, but decided it was “by design.”

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

Azure AD Seamless SSO service automatically connects users to their corporate devices, connected to their workplace network. With Seamless SSO enabled, users won’t have to enter their passwords, or even usually their usernames, to sign in to Azure AD. “This feature allows your users to easily access your cloud-based applications without the need for additional on-premises components.” Explain Microsoft.

But, like many Windows services, the Seamless SSO service relies on the Kerberos authentication protocol. “When configuring Seamless SSO, a computer object named AZUREADSSOACC is created in the on-premises Active Directory (AD) domain and receives the Service Principal Name (SPN) https://autologon.microsoftazuread-sso.com“, explain the researchers of the CTU.” This name and the hash of the password of the AZUREADSSOACC computer object are sent to Azure AD. “

The next automatic logon endpoint called “windowstransport” receives Kerberos tickets. And, Seamless SSO happens automatically without any user interaction:

https://autologon.microsoftazuread-sso.com//winauth/trust/2005/windowstransport

The authentication workflow has been demonstrated with the following illustration:

In addition, there is a usernamemixed end point at … / winauth / trust / 2005 / usernamemixed that accepts username and password for one-factor authentication. To authenticate a user, an XML file containing his user name and password is sent to this usernamemixed period.

The authentication workflow for this endpoint is much simpler:

And that’s where the loophole creeps in. Auto-login attempts to authenticate the user to Azure AD based on the credentials provided. If the username and password match, authentication succeeds and the autologon service responds with XML output containing an authentication token, called DesktopSSOToken, which is sent to Azure AD. If, however, authentication fails, an error message is generated.

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

“Successful authentication events generate connection logs … However, automatic connection authentication [step] to Azure AD is not registered. This omission allows threat actors to use the usernamemixed endpoint 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

Secureworks researchers say that most security tools and countermeasures aimed at detecting brute force or password spray attacks rely on connection event logs and look for specific error codes. This is why having no visibility into unsuccessful login attempts is a problem.

“[Our] the analysis indicates that the autologon service is implemented with Azure Active Directory Federation Services (AD FS), â€the CTU researchers explain. “Microsoft AD FS Documentation recommended deactivate Internet access to windowstransport period. However, this access is required for Seamless SSO. Microsoft indicated that the usernamemixed the endpoint is only required for legacy Office clients prior to the May 2015 Office 2013 update. “

Exploitation is not limited to organizations using single sign-on

The flaw is not limited to organizations using Seamless SSO. “Threatening actors can exploit automatic login usernamemixed endpoint in any Azure AD or Microsoft 365 organization, including organizations that use pass-through authentication (PTA), â€the researchers explain. However, users without an Azure AD password are not affected.

Since the success of a brute force attack largely depends on the strength of the password, Secureworks rated the vulnerability as “medium” severity in its writing.

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

Ars contacted Microsoft and Secureworks well in advance of the release. Microsoft did not respond to our request for comment. Secureworks oddly responded with an invitation to a future online event but did not comment on the matter.

As noted above, Microsoft seems to view this as a design choice rather than a vulnerability. As such, it remains unclear whether or when the flaw will be fixed, and organizations could remain vulnerable to brute force stealth attacks.