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 to no visibility into the attacker’s actions, let alone the ability to block them.
A newly discovered bug in Microsoft Azure’s Active Directory (AD) implementation enables just that: single-factor brute-forcing of a user’s AD credentials. And these attempts are not logged on 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 Azure Active Directory Seamless Single Sign-On service.
“This flaw allows threat actors to perform single-factor brute-force attacks on Azure Active Directory without generating login events in the target organization’s tenant,” the researchers explain.
That same month, Secureworks reported the flaw to Microsoft, who then confirmed in July that this behavior existed, but decided it was “by design.”
This month, Secureworks is warning its customers about the flaw, according to a post shared with Ars by a source.
ax Sharma
Azure AD seamless SSO service automatically signs users in to their corporate devices, connected to their workplace network. With Seamless SSO enabled, users don’t 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 on-premises components,” explains Microsoft.
But, like many other Windows services, the 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 domain (AD) and is assigned the service principal name (SPN) https://autologon.microsoftazuread-sso.comCTU researchers explain. “That name and the password hash of the AZUREADSSOACC computer object are sent to Azure AD.”
The next autologon endpoint named “windowstransport” will receive Kerberos tickets. And seamless SSO happens automatically without any user interaction:
https://autologon.microsoftazuread-sso.com//winauth/trust/2005/windowstransport
The authentication workflow is demonstrated with the following image:
Secureworks
In addition, there is a usernamemixed endpoint at …/winauth/trust/2005/usernamemixed that accepts username and password for single-factor authentication. To authenticate a user, an XML file with their username and password is sent here usernamemixed end point.
Secureworks
The authentication workflow for this endpoint is much simpler:
Secureworks
And this is where the error sneaks in. Autologon attempts to authenticate the user to Azure AD based on the credentials provided. If the username and password match, the authentication is successful and the Autologon service responds with XML output that contains an authentication token, also 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 captured correctly, that can help an attacker perform undetected brute-force attacks.
Secureworks
“Successful authentication events generate logon logs… However, the authentication of autologon [step] to Azure AD is not committed. This omission allows threat actors to use the usernamemixed endpoint for undetected brute-force attacks,” CTU researchers explain in their description.
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 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 spray attacks rely on log-in event logs and looking for specific error codes. This is why it is a problem not to have visibility of the failed login attempts.
†[Our] analysis indicates that the autologon service is deployed with Azure Active Directory Federation Services (AD FS),” the CTU researchers explain. “Microsoft AD FS documentation recommends that Internet access to the windowstransport end point. However, that access is required for seamless SSO. Microsoft indicates that the usernamemixed endpoint is only required for older Office clients 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 abuse the autologon usernamemixed endpoint in any Azure AD or Microsoft 365 organization, including organizations that use Pass-through Authentication (PTA),” the researchers explain. Although users without an Azure AD password remain unaffected.
Because the success of a brute-force attack depends largely on the strength of the password, Secureworks has rated the error in its description as “average.”
At the time of writing, there are no known workarounds or workarounds for using the usernamemixed end point. Secureworks states that using Multi-Factor Authentication (MFA) and Conditional Access (CA) will not prevent exploitation, as these mechanisms only occur after successful authentication.
Ars contacted both Microsoft and Secureworks well in advance of publication. Microsoft has not responded to our request for comment. Strangely, Secureworks responded with an invitation to a future online event, but did not comment on the matter.
As mentioned above, Microsoft seems to consider this a design choice rather than a vulnerability. As such, it remains unclear if and when the flaw would be fixed, and organizations could remain vulnerable to stealthy brute-force attacks.