How the password spray attack works
I’m sure you've all heard about this technique at least once before – let me give you a brief architecture diagram.
In a nutshell, password-spraying is a type of brute force attack (T1110 by MITRE) that occurs when someone is trying to guess the password by attempting it many times. Of course, nowadays in the Active Directory world, this is not very effective as after a certain number of unsuccessful logins the corresponding account is going to be locked. This is annoying, creates additional work for the Helpdesk team, but efficient enough against such attempts.
To bypass the account lockout, adversaries are using password-spraying. So, instead of trying to check all possible password combinations for a specific known user, they are creating a dictionary of well thought password combinations with high probability of success for the target victim and are trying these combinations against as many known users as possible.
This way, a particular user is probed only once in several minutes, which keeps their account unlocked.
Let’s say you have an organization of 50,000 users and most of them are located in Boston. If an adversary knows this, they may have good chances with “Patriots2019”, aren’t they? Let’s be honest – they’ll most likely succeed, because chances are at least couple of users from your 50,000 AD accounts have such a password.
That is why this technique is so powerful and dangerous.
Example
Here is the example of analysts using this technique against Exchange OWA server
https://www.blackhillsinfosec.com/attacking-exchange-with-mailsniper/
I want to remind you that if you have Quest InTrust, all of the above will be logged by PowerShell auditing and could be blocked by PowerShell suspicious activity rule.
It’s important to note that even if MFA is enabled for such services as web mail, password-spraying still works. This is because adversaries do not need to access the service – they just need to know if the password is correct. See the difference?
Application access vs correct credentials, and MFA responds with additional questions when the password is correct. When you have correct credentials you do not need to access applications that are protected by MFA, because chances are – there will be an application or a service without such a protection.
Real-world adversary example
Fireeye published a great analysis of APT33 where, among many detailed stages of the attack, they used password-spraying.
“Starting approximately three weeks later, the actor reestablished access through a successful password spray…”
After previous unsuccessful attacks, the actor learned the organization’s infrastructure, weak and strong points and about their defense systems, then applied the password spraying technique. Interestingly enough – no one picked-up on password spraying in the environment until the actor started implementing persistence methods.
Mitigation
If you check the attack technique page from MITRE, you’ll see that there is nothing in the Mitigation section about password spraying, because there is no good mitigation besides educating users to use better passwords or using well-known bad password protection solutions.
Although, again, let’s be honest – when your home team wins a trophy, the likelihood that some of your colleagues use their name in the password is not zero.
Detection
There are ways to detect password spraying, although it could be difficult, as it’s not a brute force – not the same account is under attack. You could try to monitor all login attempts and their volume, sure – but who can say if it’s an attack or just a spike in login attempts? Also, because it is for different user accounts, it’s hard to draw any direct conclusions.
To help with detection and to reduce noise, we’ve developed a dedicated-password spraying rule in InTrust.
InTrust analyzes 4625 and 4771 as per MITRE recommendation, but we also do additional analysis to reduce the noise.
The rule works when we see multiple account logins (5 by default) from the same computer for many different and valid users, logged within 1 minute. InTrust is also capable of extracting the particular user accounts and displaying them in the alert text.
