The Entra ID Endpoint That Sprays Passwords Without Filling the Sign-In Log

Varonis has documented a legacy Entra ID authentication path, kept alive for Office 2013 clients, that lets attackers spray passwords without tripping Smart Lockout and confirm valid credentials on accounts protected by multifactor authentication ^[16][7]. The requests also stay out of the standard sign-in logs, which makes this a detection problem and not only an authentication one ^[7].

Microsoft added Smart Lockout to Azure AD, now Entra ID, in 2018 to slow password spraying ^[1]. It counts failed attempts per account, keeps separate counters for familiar and unfamiliar locations, and locks an account temporarily once a threshold is crossed, extending the lockout after further failures ^[2]. The intended arrangement is that defenders watch the pattern in sign-in logs while MFA or Conditional Access blocks access if a password is guessed ^[3].

The bypass runs through the WS-Trust autologon endpoint that Entra Seamless SSO uses to sign domain-joined machines into Microsoft 365 in the background ^[4]. It is built on WS-Trust, an old SOAP-based protocol designed for username and password authentication against federation services ^[5], and Microsoft exposes it at autologon.microsoftazuread-sso.com under a per-tenant usernamemixed path ^[6]. The endpoint is reachable directly, and a request carries the credentials in the UsernameToken element of a SOAP security header ^[8].

The response is where the design leaks. A correct password returns a DesktopSsoToken ^[9]; a wrong username or password returns a SOAP fault carrying AADSTS50126 ^[10]. The endpoint also returns distinct codes for accounts where the password was accepted but a later control stopped the flow: AADSTS53003 for a Conditional Access block, along with AADSTS50055 and AADSTS50076 ^[11][12]. In a normal MFA-protected sign-in a blocked attempt looks like a generic failure and tells an attacker little; here the response separates a wrong password from a correct one stopped later ^[13]. That turns a failed login into confirmation that the credential is valid, MFA notwithstanding ^[12].

The lockout side held up no better in testing. Varonis reports that a spray against usernamemixed produced more than 1,000 failed attempts against a single account from one unfamiliar IP with no AADSTS50053 locked-account response ^[14]. There was no obvious exponential backoff or response-time throttling, and a legitimate sign-in to the same account afterward succeeded immediately ^[15].

The consequence for defenders is straightforward. Because this traffic does not land in the interactive sign-in logs, an empty failed-sign-in view is not evidence that nobody is testing credentials ^[7]. The open questions for any tenant are whether the autologon path is reachable and whether Seamless SSO is enabled at all ^[4][6], and whether the sign-in log is being treated as a complete record of authentication attempts when it is not ^[7].