.svg)
On January 19, 2024 Microsoft released a statement regarding the threat actor group named “”—this state-sponsored actor was observed by Microsoft as performing password spraying against a legacy tenant, from which the threat actor was able to gain a foothold and jump to other environments.
That a security behemoth such as Microsoft fell victim to the password spraying technique should pique the interest of those charged with defending Microsoft 365 (M365) environments.
The ĢTV platform protects M365 identities at scale, looking for aspects such as session hijacking, credential theft, as well as general business email compromise tactics, techniques, and procedures. As part of this protection, the ĢTV Threat Hunting team is constantly on the lookout for additional M365 attack vectors. As such, this blog aims to highlight how the team thinks about and unpackages the password spraying techniques in use by threat actors today, whether they target an environment as large as Microsoft, or a small business.
Not a Brute Force
Looking at the matrix, password spraying falls under the “Brute Force (T1110)” technique. This organization makes complete sense from an ATT&CK matrix and logical grouping standpoint.
However, when looking at Brute Forcing (T1110) versus Password Spraying (T1110.003) through a threat-hunting lens, the dichotomy between these two techniques comes into sharp focus.
Let’s unpack this dynamic a little bit through a visual representation of what a threat-hunting thought pattern for a brute force attack would look like:
Because a brute force attack generates multiple failed authentications that target a particular account, our hunting hypotheses or questions will revolve around the aspects covered in the above graphic.
Generally, we’re looking for an above-average amount of failed authentication attempts that either stem from a single IP address or target a particular user. Through the lens of a threat actor, there is indeed a common goal between brute force and password spray attacks: valid credentials. However, if we look at the thought pattern for a password spray hunt, we can see a drastic difference between it and a brute force attack, particularly when viewed from a hunting point of view.
Let’s take a look at a visual thought pattern for hunting password spraying and contrast this to the previous thought pattern regarding hunting brute force attacks:
Although we’re most likely dealing with the same type of telemetry—authentication events—and are broadly looking for authentication anomalies, the hunting techniques and thought patterns used differ drastically when looking for brute force attacks as compared to password spray attacks.
A key aspect in hunting for password spray attacks is understanding what “normal” looks like for an organization because you likely will not see 500 failed authentication attempts for a singular user account during a password spray attack as you would during a brute force attack. In addition, bubbling up failed login attempts alone may not provide much value in detecting password spray attacks, as users are human and often forget their passwords or get locked out of their accounts fairly regularly.
Another interesting dynamic here is that both brute force and password spray hunting strategies differ quite drastically from hunting that looks for session hijacking. In a session hijacking scenario, we assume that the victim user has a valid session to the M365 environment, so we can look at aspects such as multiple User Agents, Operating Systems, or IP organizations/ASNs in use by a singular session ID.
However, a user who’s been idle within an M365 environment can still be a victim of a successful password spray attack. In these scenarios, you may see a successful authentication event for an M365 identity on its own, in isolation. This dynamic further highlights why password spray attacks lend themselves well to proactive hunting efforts, with a real-life human looking at and analyzing the results. Indeed, with these types of attacks, nuance matters.
Getting the Jitters
A common theme between brute force and password spray hunting is the temporal element. That is, we’re looking for an abnormal number of events within a certain time period. With a brute force attack, we expect that the majority of the attack will take place in a “burst” type fashion.
However, to evade these types of detections, authors of popular password spray tools have built in “Jitter” capabilities to randomize authentication attempts. “Jitters” seek to add randomized time intervals between login attempts
Tools such as have built-in jitter and delay capabilities to avoid temporal-based detections as well as any lockout policies:
Other tools like CredMaster take this dynamic a step further and introduce modules that specifically spray accounts during working hours so as not to trigger any “outside of working hours” type alerts, as seen in Figure 4:
These evasive techniques complicate password spray hunting efforts and also create further distance between hunting for standard brute force-type attacks.
Enter the Cloud
As we’ve seen, the tradecraft surrounding password spraying has kept pace with the hunting and detection strategies employed by defensive teams.
As brute force-type detections became table stakes, threat actors proceeded to employ password spray strategies instead. As defenders built detections around this dynamic, a different approach was required to make password spraying more stealthy.
With the cloud becoming ever-present in our computing realities, password spraying tools began to take advantage of various cloud services to evade password spray detections that looked for multiple authentication events from a single IP address.
These newer password spraying tactics now involve the use of cloud services such as the Amazon Web Services (AWS) API gateway or GitHub actions to rotate IP addresses upon every authentication attempt.
For example, tools such as use AWS to rotate IP addresses:
Similarly, newer tools like use GitHub actions to mimic this dynamic:
Luckily for defenders, both AWS and GitHub publish their IP ranges, making it easy to find which particular cloud service an IP belongs to.
We can ascertain the IP range for GitHub actions using the following command:
Similarly, we can get the IP range used for the AWS API gateway:
We can then cross-reference the IPs found through the above commands with the telemetry that’s available to us so that we can see if any of the authentication anomalies in our environments match up with services known to be abused for password spraying purposes.
What’s interesting regarding this dynamic, from an investigative standpoint, is that typically when looking at M365 sign-in telemetry, those of us on the defensive end are often quick to dismiss ASN values that match up with legitimate cloud services. After all, why should a login from a Microsoft-owned ASN block be considered suspicious?
The proliferation of spraying tools that utilize legitimate and trusted cloud services should prompt us all in the defensive space to challenge our detection and hunting assumptions and to look deeper into the telemetry that is before us.
Getting Results
Thus far, we’ve been discussing password spraying at a high, tactical level. Let’s switch gears a bit and look at the meat and potatoes of password spraying.
We can start with the following query in syntax:
This query is used by the threat-hunting team at ĢTV to bubble up any M365 identities that are connected to their environments with suspicious characteristics:
- More than 1 ASN value in use
- More than 1 OS in use
- More than 1 browser in use
- Multiple geographic locations
All these conditions are grouped by both the user name and session ID values. The results below contain a redacted screenshot of a compromised identity discovered through proactive hunting efforts.
We can see that a VPN was used to perform authentication, the suspicious programmatic user agent sticks out a bit, and we see authentications from two states. Of course, on its own and without further investigation, it’s impossible to determine if this singular event is malicious or benign. However, when comparing these authentication parameters to the users’ normal activity, credential theft was confirmed.
In another executed threat hunt, ĢTV analysts looked for user authentications stemming from an IP space belonging to the AWS API Gateway service.
The search for this type of dynamic is relatively straightforward:
The results here are interesting, and it may be easy to dismiss these logins as stemming from a legitimate cloud service and moving on with your day. However, if we use a tool like to take a closer look at the IPs generating the M365 events, we can see that these logins originate from the AWS API Gateway service:
Upon further review of the identities above, it was determined that some type of credential theft did indeed occur, and the customers were notified immediately, as seen in Figure 8:
Staying Protected
Although we at ĢTV love threat hunting adventures, we would strongly prefer to find zero compromises when pursuing the aspects we've outlined thus far.
Given this, what can you do today to protect yourself from the password spraying techniques outlined above?
From what the ĢTV SOC and hunt teams observe, many of these successful password spray attempts are most likely a result of threat actors finding breached passwords for their targeted user accounts. In addition, these accounts often contain weak passwords or passwords that are potentially found in other data breaches.
Consider the implementation of which prevents users from setting known-weak or previously compromised passwords. Licensing and cost constraints may prevent you from implementing these technical controls, but we’d strongly advise that users be educated on setting a unique and strong password for their M365/Entra accounts.
In addition to password protection, all effort should be made to block legacy authentication protocols within the tenant if possible. The following walks you through the steps required.
Identities within M365 environments should also be protected with the strongest multi-factor authentication methods as business conditions allow. The following outlines how to implement phishing-resistant authentication in M365 environments.
We fully understand that in small and mid-sized business (SMB) environments, not all of the above controls would be feasible to implement. Despite this, ĢTV partners and customers can rest assured that ĢTV analysts are constantly on the lookout for any threat actor tradecraft that can be utilized in order to compromise M365 identities and environments.
Conclusion
As threat actor tradecraft and methods of operation evolve, it’s important for us on the defensive end of the cybersecurity spectrum to keep up with these methods and constantly evolve our own detection and hunting tradecraft.
Want to dive into even more threat actor tradecraft? Join us at Tradecraft Tuesday! No products, no pitches—just tradecraft.
.webp){kind=logo}
.webp)
.webp)
Sign Up for Blog Updates
Subscribe today and you’ll be the first to know when new content hits the blog.
