WS-Trust Autologon Endpoint: Password Spray Without Smart Lockout Blocking

What Happened

A researcher found that an old Microsoft sign-in feature, kept around to support very old versions of Office, lets attackers guess passwords against Microsoft 365 accounts without triggering the automatic account lockout that is supposed to stop this kind of attack. It also does not show up in the logs that security teams normally check. Worse, the responses from this feature tell an attacker whether a guessed password was actually correct, even if extra protections like multi-factor authentication would have blocked the sign-in anyway. This affects any organization using Microsoft Entra ID (Microsoft's cloud identity service) that has not specifically disabled this legacy feature or blocked older authentication methods. Organizations should check whether this endpoint is enabled in their environment, consider disabling it or blocking legacy authentication through Conditional Access, and review their Unified Audit Log for signs of this activity.

Key Takeaways

• A legacy WS-Trust autologon endpoint used by Entra Seamless SSO accepts direct username and password requests from the internet and bypasses Smart Lockout entirely.
• Failed authentication attempts against this endpoint do not appear in standard Entra ID sign-in logs, leaving a visibility gap for defenders who rely on those logs to detect password spraying.
• The endpoint returns distinct AADSTS error codes that let an attacker distinguish a wrong password from a correct password blocked by MFA, Conditional Access, or password expiration, which confirms valid credentials even on MFA-protected accounts.
• Testing showed over 1,000 failed attempts against a single account from one unfamiliar IP with no lockout response and no throttling, and a subsequent legitimate sign-in succeeded immediately afterward.
• Microsoft has classified this behavior as by design; the practical mitigations are disabling the usernamemixed endpoint, blocking legacy authentication via Conditional Access, enabling Unified Audit Log alerting, and moving to passwordless authentication.

Affected Systems

• Microsoft Entra ID tenants with Entra Seamless SSO enabled
• Organizations that have not blocked legacy authentication via Conditional Access
• Accounts protected by MFA or Conditional Access policies that rely on Smart Lockout for spray protection
• Legacy Office 2013 clients (pre-May 2015 update) that require the WS-Trust usernamemixed endpoint

Vulnerabilities (CVEs)

None identified.

Attack Chain

1. Enumeration: Attacker queries the GetCredentialType API, or the autologon endpoint itself as a fallback, to determine which email addresses correspond to existing tenant accounts.
2. Filtering: Attacker discards non-existent accounts to reduce noise and avoid rate-limiting.
3. Spraying: Attacker submits a common or company-themed password against each remaining account via the WS-Trust usernamemixed endpoint; Smart Lockout does not trigger and standard sign-in logs do not record the attempts.
4. Response Triage: Attacker classifies each SOAP response by AADSTS code to identify accounts with valid passwords, including those blocked by MFA, Conditional Access, or password expiration.
5. Post-Exploitation: Attacker gains direct access to accounts without MFA via OAuth2 or Microsoft Graph, or targets MFA-protected accounts with confirmed passwords using adversary-in-the-middle phishing, device code flow abuse, or primary refresh token theft.

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: No

The article does not provide any YARA, Sigma, Snort/Suricata, KQL, SPL, or EQL detection logic. It recommends enabling Unified Audit Log alerting for requests to the autologon endpoint as a compensating visibility measure, but no specific query or rule syntax is included.

Detection Engineering Assessment

Required Log Sources

• Entra ID Unified Audit Log (UAL)
• Entra ID Conditional Access logs
• Network/proxy logs showing outbound requests to autologon.microsoftazuread-sso.com
• Entra ID sign-in logs (for comparison/gap analysis)

Hunting Hypotheses

Control Gaps

• Smart Lockout does not apply to authentication attempts submitted through the WS-Trust autologon endpoint.
• Standard Entra ID sign-in logs do not capture failed authentication attempts against this endpoint, creating a blind spot for teams relying solely on those logs.
• MFA and Conditional Access can still block the final sign-in but do not prevent the endpoint from confirming password validity to the attacker.

Key Behavioral Indicators

• Unusually high volume of authentication attempts from a single external source directed at Microsoft identity infrastructure over a short period
• Presence of specific AADSTS error codes (correct-password-but-blocked types) associated with the same source across multiple distinct accounts
• Discrepancy between authentication attempt volume in non-standard logs versus absence of corresponding entries in standard sign-in logs
• Legacy authentication traffic present despite an organization believing legacy authentication is fully blocked

False Positive Assessment

Recommendations

Immediate Mitigation

Infrastructure Hardening

• Consider applying Microsoft's standard Conditional Access template to block legacy authentication protocols, which covers WS-Trust, ROPC, and ActiveSync together.
• Evaluate whether your organization can fully disable the WS-Trust usernamemixed endpoint at the tenant level if no legacy Office clients depend on it.
• Consider auditing which non-interactive/legacy authentication paths remain enabled across your Entra ID tenant configuration.

User Protection

• Consider accelerating rollout of passwordless authentication methods such as FIDO2 security keys or Windows Hello for Business where feasible, prioritizing privileged or high-risk accounts first.
• Evaluate whether accounts flagged as having valid-but-MFA-blocked passwords should be prompted for a password reset as a precaution.
• Consider monitoring for downstream abuse of confirmed valid credentials, such as adversary-in-the-middle phishing or device code flow abuse, on accounts identified as at-risk.

Security Awareness

• Consider briefing identity and security operations teams that Entra ID sign-in logs alone may not reflect all authentication attempts against a tenant, particularly for legacy protocols.
• Consider incorporating this legacy-endpoint gap into existing threat modeling and tabletop exercises around credential-based attacks.
• Consider reviewing awareness materials to clarify that MFA does not eliminate the value of a compromised or guessed password to an attacker.

MITRE ATT&CK Mapping

Additional IOCs

• Domains:
  • autologon[.]microsoftazuread-sso[.]com - Legacy WS-Trust autologon endpoint hostname abused to perform password spraying that bypasses Smart Lockout and standard sign-in logging; defenders should monitor Unified Audit Log entries referencing this host.
• Urls:
  • hxxps://autologon[.]microsoftazuread-sso[.]com/{tenant}/winauth/trust/2005/usernamemixed - WS-Trust usernamemixed endpoint used to submit direct SOAP username/password authentication requests, the primary vector for the spray technique described.
  • hxxp://login[.]microsoftonline[.]com/common/GetCredentialType - Microsoft API used by attackers to enumerate whether an email address corresponds to a valid tenant user prior to spraying, reducing wasted attempts against non-existent accounts.
• Other:
  • AADSTS50055 / AADSTS50076 / AADSTS53003 - SOAP Fault error codes returned by the autologon endpoint that confirm a submitted password is valid even though MFA, Conditional Access, or password expiration blocked the final sign-in, allowing credential validation without full authentication.