September 29, 2021
Researchers from the Secureworks Counter Threat Unit (CTU) discovered a flaw in the protocol of the Azure Active Directory Seamless Single Sign-On service.
According to the researchers, this bug allows threat actors to conduct one-factor brute-force attacks against Azure Active Directory without generating login events in the target organization.
Azure AD Seamless SSO service automatically logs users into their corporate devices connected to their workplace network. If Seamless SSO is enabled, users do not need to enter their passwords or even their username to log in to Azure AD.
This is where the vulnerability starts. Autologon attempts to authenticate the user to Azure AD according to the provided credentials. If the username and password match, authentication succeeds and the Autologon service responds with XML output bearing an authentication token, also called DesktopSSOToken. This is then sent to Azure AD. If authentication is unsuccessful, an error message is generated.
These error codes, some of which are not properly logged, are able to help threat actors carry out undetected brute-force attacks.
The CTU researchers explain that successful authentication events generate sign-ins, but Autologon authentication to Azure AD is unlogged. This omission allows threat actors to utilize the username mixed endpoint for undetected brute-force attacks.
The vulnerability 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),” although users without Azure AD passwords are not affected, according to the researchers.
Since the success of a brute-force attack depends heavily on the password strength, Secureworks classifies the error as “medium” in a draft.
Currently, there are no fixes or workarounds to stop the use of the usernamemixed endpoint. Secureworks points out that the use of multi-factor authentication and conditional access cannot prevent exploitation, as these mechanisms only occur after successful authentication.
For more information, read the original story in Ars Technica.
