New Metasploit Module: Azure AD Login Scanner

Written by

raxis-sys-admin

in

,
Summary

In June of 2021, Secureworks Counter Threat Unit (CTU) discovered that the protocol used by Azure Active Directory (AD) Seamless Single Sign-On (SSO) allows for brute-forcing usernames and passwords without generating log events on the targeted tenant. In addition to brute-forcing credential pairs, the Azure endpoint returns error codes that allow for username enumeration. This post details the vulnerable endpoint, and how it can be exploited to brute-force usernames and passwords in a succinct Metasploit module.

Vulnerability Description

In addition to the normal Azure AD authentication workflow for SSO, which utilizes Kerberos, the usernamemixed endpoint of Autologon accepts single-factor authentication. Authentication attempts to this endpoint are in XML, as shown here:

Example XML Authentication Request

The Autologon endpoint takes these credentials and sends them to Azure AD to authenticate the user. If the credentials are valid, the authentication is successful, and the Autologon endpoint responds with XML containing a DesktopSsoToken, which is used to further connect and authenticate with Azure AD. When a successful logon occurs, Azure AD properly logs the event.

However, on authentication attempts that are unsuccessful, the authentication attempt does not get logged by the tenant. If the credentials are invalid, the Autologon endpoint responds with XML containing a specific error code for the authentication attempt, as shown here:

Detailed Error Code in XML Response

The error code provided in this response can be further used to determine valid usernames, whether MFA is needed, if the user has no password in Azure AD, and more. The error codes used in the Metasploit module I developed are shown below:

Error Codes
Metasploit Module

The Metasploit module (auxiliary/scanner/http/azure_ad_login) can enumerate usernames or brute-force username/password pairs based on the responses from the Autologon endpoint described above. If you have a target tenant using Azure AD SSO and usernames/passwords to validate, you can use this module by setting the following variables:

  • DOMAIN – The target tenant’s domain (e.g., bionicle.dev)
  • USERNAME or USER_FILE – A single username to test or a file containing usernames (one per line)
  • PASSWORD or PASS_FILE – A single password or a file containing passwords (one per line)

When you run the module, every username/password pair is tested using the authentication XML request shown above to validate the pairing. When a valid username/password pairing is found, the DesktopSsoToken is also displayed to the user, as shown here:

Example Azure AD Login Module Usage
Remediation and Protection

As of the writing of this post, there is no direct remediation to this vulnerability if your organization is using Azure AD with Single Sign-On. Microsoft has deemed this part of the normal workflow, and thus there are no known plans to remediate the endpoint. From a defender’s point of view, this vulnerability is particularly difficult to defend against due to the lack of logs from invalid login attempts. Raxis recommends the following to help defend against this vulnerability:

  • Ensure users set strong passwords in Active Directory by having a strong password policy.
  • Enable Multi-Factor Authentication on all services that may use AD credentials in case a valid username/password pair is discovered.
  • Consider setting a Smart Lockout policy in Azure that will lock out accounts targeted by brute-force attacks. This won’t help with password spraying, but will for single user brute-forcing.
  • Monitor for unusual successful logins from users (e.g. unusual locations).
  • Educate users about password hygiene so that they can learn to set strong passwords that won’t be caught by password spraying attacks.
Metasploit Module Details
References

 

More posts