Undetected Azure Active Directory Brute-Force Attacks

Summary

In late June 2021, Secureworks® Counter Threat Unit™ (CTU) researchers discovered a flaw in the protocol used by the Azure Active Directory Seamless Single Sign-On feature. This flaw allows threat actors to perform single-factor brute-force attacks against Azure Active Directory (Azure AD) without generating sign-in events in the targeted organization’s tenant.

CTU™ researchers reported the flaw to Microsoft on June 29. Microsoft confirmed the behavior on July 21 but ruled that it was “by design.” As a result, it is unclear if or when the flaw will be fixed. In the meantime, organizations are vulnerable to stealthy brute-force attacks.

Azure AD Seamless Single Sign-On

The Azure AD Seamless Single Sign-On (SSO) improves the user experience of services using the Azure AD identity platform, such as Microsoft 365. When Seamless SSO is configured, users logged in to their domain-joined computer are automatically logged into Azure AD.

The Seamless SSO feature uses the Kerberos protocol, which is the standard authentication method of Windows networks. 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”. That name and the password hash of the AZUREADSSOACC computer object are sent to Azure AD. The following autologon windowstransport endpoint accepts Kerberos tickets:

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

The Seamless SSO occurs automatically without any user interaction (see Figure 1).

Figure 1. Typical Seamless SSO process. (Source: Secureworks)

1. A user tries to access Azure AD.
2. Azure AD recognizes that user’s tenant is configured to use Seamless SSO and redirects the user’s browser to autologon.
3. The user’s browser tries to access Azure AD.
4. Autologon sends a Kerberos authentication challenge.
5. The user’s browser tries to authenticate as the logged-in user and requests a Ticket Granting Ticket (TGT).
6. The on-premises AD sends a TGT to the user’s browser.
7. The user’s browser requests autologon access from the on-premises AD and provides the TGT as proof of identity.
8. The on-premises AD locates a corresponding computer object and creates a service ticket (ST), which is encrypted using the AZUREADSSOACC computer account’s password hash.
9. The user’s browser makes another request to autologon and provides the ST in the request’s Authorization header.
10. Autologon decrypts the ST using the AZUREADSSOACC computer account’s password hash, issues a DesktopSSOToken access token for the user, and sends this token to user’s browser via a redirect request to Azure AD. DesktopSSOToken is an opaque blob encrypted by Microsoft, so the actual content is unknown.
11. The user’s browser makes another request to Azure AD using the DesktopSSOToken as the Security Assertion Markup Language (SAML) assertion.

Flaw in the protocol

In addition to the windowstransport authentication endpoint, there is an usernamemixed endpoint for username and password authentication:

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

Figure 2 shows the username and password login process.

Figure 2. Autologon username and password login process. (Source: Secureworks)

1. An XML file containing the username and password are sent to the usernamemixed endpoint (see Figure 3).


Figure 3. XML file containing username and password. (Source: Secureworks)

2. Autologon tries to authenticate to Azure AD with the provided credentials.
3. If authentication is successful, autologon issues an XML file containing a DesktopSSOToken access token (see Figure 4). If authentication is unsuccessful, autologon generates an error (see Figure 5).


Figure 4. XML file containing the DesktopSSOToken. (Source: Secureworks)


Figure 5. Authentication error message. (Source: Secureworks)

4. If authentication is successful, the DesktopSSOToken access token is sent to Azure AD.

Table 1 lists the possible returned error codes. Not all error codes indicate brute-force attempts. For instance, error AADSTS50053 indicates that the username and password were correct, but the account was locked.

Table 1. Autologon error codes.

CTU researchers observed that successful authentication events generate sign-ins logs in step 4. However, autologon’s authentication to Azure AD (step 2) is not logged. This omission allows threat actors to utilize the usernamemixed endpoint for undetected brute-force attacks.

Conclusion

Threat actors can exploit the autologon usernamemixed endpoint to perform brute-force attacks. This activity is not logged in Azure AD sign-ins logs, enabling it to remain undetected. As of this publication, tools and countermeasures to detect brute-force or password spray attacks are based on sign-ins log events.

CTU analysis indicates that the autologon service is implemented with Azure Active Directory Federation Services (AD FS). 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.

The exploitation 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). Users without an Azure AD password are not affected.

As of this publication, there are no known mitigation techniques to block use of the autologon usernamemixed endpoint. Multi-factor authentication (MFA) and conditional access (CA) do not prevent exploitation because they are applied after successful authentication.