Every Solution You Can Imagine – and More
What cybersecurity solution do you need? From Zero Trust to ADR, IAM, risk/privacy, data protection, AppSec and threat, securing digital transformation, to resiliency and remediation, we can build the right program to help solve your challenges.
A Single Partner for Everything You Need
Optiv works with more than 450 world-class security technology partners. By putting you at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can.
We Are Optiv
Greatness is every team working toward a common goal. Winning in spite of cyber threats and overcoming challenges in spite of them. It’s building for a future that only you can create or simply coming home in time for dinner.
However you define greatness, Optiv is in your corner. We manage cyber risk so you can secure your full potential.
Go365: Office 365 Password Spraying Tool
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.
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.
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.
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.
[-] User not found: firstname.lastname@example.org
[-] User not found: email@example.com
[-] Valid user, but invalid password: firstname.lastname@example.org
[!] Account Locked Out: email@example.com
[-] Valid user, but invalid password: firstname.lastname@example.org
[!] Account Locked Out: email@example.com
[!] Account Locked Out: firstname.lastname@example.org
[-] Valid user, but invalid password: email@example.com
[-] Valid user, but invalid password: firstname.lastname@example.org
[!] Account Locked Out: email@example.com
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.
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.
November 05, 2020
A security vulnerability has been found in the Black Duck Hub REST API Python project (“blackduck” in the PyPI repository). Read more.
July 10, 2020
Optiv is releasing REST API Goat, a vulnerable API, to help boost AppSec skills.
February 03, 2021
Even when the hooks are removed, defenders can still leverage other EDR functions, such as host isolation for incident triage or remote.
Let us know what you need, and we will have an Optiv professional contact you shortly.