New Azure Active Directory password brute-forcing flaw has no fix
Imagine having unlimited attempts to guess someone’s username and password without getting caught. That would make an ideal scenario for a stealthy threat actor—leaving server admins with little to no visibility into the attacker’s actions, let alone the possibility of blocking them.
A newly discovered bug in Microsoft Azure’s Active Directory (AD) implementation allows just that: single-factor brute-forcing of a user’s AD credentials. And, these attempts aren’t logged on to the server.
Invalid password, try again, and again…
In June this year, researchers at Secureworks Counter Threat Unit (CTU) discovered a flaw in the protocol used by 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 sign-in events in the targeted organization’s tenant,” explain the researchers.
The same month, Secureworks reported the flaw to Microsoft that then confirmed this behavior existed by 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 signs users in to their corporate devices, connected to their workplace network. With Seamless SSO enabled, users won’t have to type in their passwords, or typically even their usernames, to sign in to Azure AD. “This feature provides your users easy access to your cloud-based applications without needing any additional on-premises components,” explains Microsoft.
But, like many Windows services, Seamless SSO service relies on the Kerberos protocol for authentication. “During the Seamless SSO configuration, a computer object named AZUREADSSOACC is created in the on-premises Active Directory (AD) domain and is assigned the service principal name (SPN) https://autologon.microsoftazuread-sso.com,” explain CTU researchers. “That name and the password hash of the AZUREADSSOACC computer object are sent to Azure AD.”
The following autologon endpoint called “windowstransport” receives Kerberos tickets. And, Seamless SSO occurs automatically without any user interaction:
https://autologon.microsoftazuread-sso.com//winauth/trust/2005/windowstransport
The authentication workflow has been demonstrated with the following illustration:
Additionally, there’s a usernamemixed endpoint at …/winauth/trust/2005/usernamemixed that accepts username and password for single-factor authentication. To authenticate a user, an XML file containing their username and password is sent to this usernamemixed endpoint.
The authentication workflow for this endpoint is much simpler:
And this is where the flaw creeps in. Autologon attempts to authenticate the user to Azure AD based on the provided credentials. If the username and password are a match, authentication succeeds, and the Autologon service responds with XML output containing an authentication token, known as DesktopSSOToken, which is sent to Azure AD. If, however, the authentication fails, an error message is generated.
It is these error codes, some of which are not properly logged, that can aid an attacker in performing undetected brute-force attacks.
“Successful authentication events generate sign-ins logs… However, autologon’s authentication [step] to Azure AD is not logged. This omission allows threat actors to utilize the usernamemixed endpoint for undetected brute-force attacks,” explain CTU researchers in their writeup.
The AADSTS error codes used during 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 state that most security tools and countermeasures aimed at detecting brute-force or password spraying attacks rely on sign-in event logs and look for specific error codes. This is why having no visibility into the failed sign-in attempts is a problem.
“[Our] analysis indicates that the autologon service is implemented with Azure Active Directory Federation Services (AD FS),” explain the CTU researchers. “Microsoft AD FS documentation recommends disabling internet access to the windowstransport endpoint. However, that access is required for Seamless SSO. Microsoft indicates that the usernamemixed endpoint is only required for legacy Office clients that predate 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 exploit the autologon usernamemixed endpoint in any Azure AD or Microsoft 365 organization, including organizations that use Pass-through Authentication (PTA),” explain the researchers. Although, users without an Azure AD password remain unaffected.
Because the success of a brute-force attack is largely dependent on password strength, Secureworks has rated the flaw as “Medium” severity in its writeup.
At the time of writing, there are no known fixes or workarounds to block the use of the usernamemixed endpoint. Secureworks states that using Multi-factor authentication (MFA) and conditional access (CA) won’t prevent exploitation because these mechanisms occur only after successful authentication.
Ars reached out to both Microsoft and Secureworks well in advance of publishing. Microsoft did not reply to our request for comment. Secureworks strangely responded with an invite to a future online event but did not comment on the matter.
As stated above, Microsoft seems to consider this a design choice, rather than a vulnerability. As such, it remains unclear if or when the flaw would be fixed, and organizations could remain vulnerable to stealthy brute-force attacks.