Go365 is a tool designed to perform automated user enumeration and password-guessing attacks on organizations that use Office 365 (now/soon Microsoft365). Go365 utilizes a unique SOAP API endpoint (login.microsoftonline.com) that most other tools currently do not. When queried with an email address and password, the endpoint responds with an Azure Active Directory (AD) authentication and authorization code. This code is processed by Go365 and the result is printed on-screen or to an output file. Go365 was written in GoLang in order to provide cross-platform functionality and the code is organized/structured so that it can be easily modified to keep up with changes to the endpoint or how responses are delivered and handled.

Go365 leverages the endpoint URL https://login.microsoftonline.com/rst2.srf and accepts an HTTP POST request with an XML (SOAP API) formatted body that includes fields for login credentials. Microsoft configured this endpoint to authenticate users to SharePoint Online, which is backed by Azure AD to process the request and reply with a response. Most corporate Office 365 accounts include SharePoint access, making this a great endpoint to conduct password spraying attacks against.

Image

Figure 1: HTTP Request Including Username and Password Payload

The XML response includes the Azure AD authentication and authorization code, starting with “AADSTS” (Azure Active Directory Security Token Service) and combined with a number to indicate the code associated with the response. Go365 checks the AADSTS code and prints the result to screen. There are several AADSTS codes that can be returned, but Go365 only processes the most common codes associated with authentication requests. For a complete list of AADSTS codes, visit Microsoft’s documentation here: https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-aadsts-error-codes.

Image

Figure 2: HTTP Response with AADSTS Code

In the example request and response above, the domain “company.com” did not exist in the Azure/Office 365 directory and the code AADSTS50059 was returned. If Go365 sees this response, it will halt the rest of the tests since there is no reason to continue.

For obvious reasons, examples of valid domains, usernames or passwords will not be included in this blog post.

Account Locked Out

After a number of queries against a target domain, the results may begin reporting the code AADSTS50053 (Account Locked Out). Tests show that this is most likely a defensive mechanism put in place by Microsoft to prevent the type of activity this tool is designed to execute. None of the tests actually locked out any accounts when developing and testing Go365. In fact, dummy accounts (accounts known to not even exist) would be reported as being locked out after a certain threshold of requests/time was met.

Note: It is still possible to lock out accounts with too many failed attempts against valid accounts.

Example:

Tests show that multiple requests from the same IP address within a certain time will trigger this behavior. There is no way of telling whether an account is truly locked out or if the activity is just being throttled.

In a test case of approximately 80 users, a wait time of 15 seconds could be added to help mitigate this preventative behavior from occurring. If testing a greater number of potential users, an Amazon API Gateway would be recommended to rotate your source IP address or use a series of SSH SOCKS5 proxies. Go365 supports both methods, but the Amazon API Gateway option works the best. Go365 should also be compatible with external tools such as cloud-proxy (https://github.com/tomsteele/cloud-proxy).

Go365 can be found on Optiv’s GitHub page located here: https://github.com/optiv/Go365

Compiled binaries are available, or you can “go build” the source from the repository. The README goes into detail about the options (you can also use ./Go365 -h ). Adding features and modifying the code is encouraged. Submit a pull request to the GitHub repository and it will be reviewed then pushed.

Password Guessing Defense Best Practices

Defending against password spraying attacks is an exercise in the security principle of “defense in depth” (DiD). Publicly exposed login portals are inherently at risk since the attack vector is available to any malicious actor connected to the internet. As such, security administrators should build their defenses under the assumption that an attacker, as a function of time, will eventually guess a user password. Here are a few things to consider when establishing a defensive posture to combat password spraying attacks:

Multi-Factor Authentication (MFA) – Office 365 supports a wide array of MFA solutions. This is the primary layer of defense between an attacker successfully identifying a valid password and unauthorized access to the user’s Office 365 account (and possibly other accounts exposed to the public internet, such as remote access VPNs). See: https://docs.microsoft.com/en-us/microsoft-365/admin/security-and-compliance/multi-factor-authentication-microsoft-365?view=o365-worldwide

Password Blacklists – Microsoft provides tools to enable password blacklists that prohibit users from including commonly used base words when configuring their password. Advanced features are available that allow administrators to customize the prohibited password list with contextual words such as “companyname” or “companyaddress.” See: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad

User Security Awareness – This is the first line of defense; unfortunately, it cannot be enforced with technical controls. Users will continue to set passwords that include common base words (season, month, company name, year, etc.). Even with technical controls in place that block the use of these base words, users will bypass them with character substitution (e.g., “Winter2020!” → “W!inter202O”). Combat this with a strong security awareness and training program that demonstrates the risks involved with using common base words.

References

https://github.com/optiv/Go365