Unmasking a slow and steady password spray attack(petrasecurity.substack.com)
petrasecurity.substack.com
Unmasking a slow and steady password spray attack
https://petrasecurity.substack.com/p/unmasking-a-slow-and-steady-password
33 comments
From a non cybersec background, I'm surprised that attackers even bother trying these attacks where each account only gets 2 attempts. To me, the probability of getting a hit feels incredibly, unworkably low, unless there are lots of common passwords being used.
I guess it's like most/all attacks under this category - the high potential payoff on success and near-zero cost to execute keep the EV positive.
I guess it's like most/all attacks under this category - the high potential payoff on success and near-zero cost to execute keep the EV positive.
I'm a former red teamer - Credential spraying attacks are incredibly successful on a business that has at least a few hundred employees. Many employees not only aren't aware of why cybersecurity is important, but often go out of their way to avoid learning or implementing security best practices because they see it as an annoyance and a hindrance.
One of our most standard and most successful playbooks to find a foothold:
1. Pull employee names from linkedin
2. Find an example email for format ([email protected])
3. Setup password spraying for a password like: Spring2025!
4. Leverage a tool like https://github.com/ustayready/CredKing to avoid IP blocking.
5. Get credentials and go from there...
One of our most standard and most successful playbooks to find a foothold:
1. Pull employee names from linkedin
2. Find an example email for format ([email protected])
3. Setup password spraying for a password like: Spring2025!
4. Leverage a tool like https://github.com/ustayready/CredKing to avoid IP blocking.
5. Get credentials and go from there...
It seems like all the corporations that still ignore NIST best practices and require password changes ever 60 days make this kind of attack much more likely to succeed.
I agree that this recommendation is in general counter productive, but the correct solution here is for the corporation to require 2FA for all logins on the internet. There will always be users who choose bad passwords.
I havent been in a single company that does not force the rotation of passwords. I worked in 4 different F500 companies.
The company I _used_ to work at, I implemented exactly that policy and only required rotation after a password reset (like initial account assignment), and should it have ever happened, after any sign of account or credential breach.
I was so happy when NIST finally recognized that people aren't machines and can't perfectly remember a new strong password with high frequency.
I was so happy when NIST finally recognized that people aren't machines and can't perfectly remember a new strong password with high frequency.
Yes, that is nice. Sadly some people will say things like "HIPAA compliance requires password rotation", which is I'm pretty sure wrong, but it happens. Still, we're pushing the above NIST line as we're really keen on improving actual security, and it's nice that it has the force of NIST behind it now.
Glad to hear you guys are making progress. Password rotation is definitely more of a hindrance than a help and is a big reason that you end up with Spring2025! style passwords for sure.
I think the industry is realizing that less is more when it comes to passwords and we're starting to see far more adoption of password managers and a bigger focus on getting SAML/SSO login options for SaaS tools, even if they are often gated behind paywalls or "enterprise" plan options.
Now that I'm in a more "defensive" position my primary focus on the credential front has been pushing password manager adoption across the org and looking for good opportunities to showcase that password managers are both significantly faster and easier to use if people are willing to change their workflow.
I think the industry is realizing that less is more when it comes to passwords and we're starting to see far more adoption of password managers and a bigger focus on getting SAML/SSO login options for SaaS tools, even if they are often gated behind paywalls or "enterprise" plan options.
Now that I'm in a more "defensive" position my primary focus on the credential front has been pushing password manager adoption across the org and looking for good opportunities to showcase that password managers are both significantly faster and easier to use if people are willing to change their workflow.
LOL Spring2025! is basically my password for an agency that requires rotation every 42 days and doesn't allow any repeats of the last 24 password. Further irony is the pattern of SeasonYear! is something that I only started doing when IT had to reset my password and they used that pattern. (when the account automatically locked out because I didn't update before their 42 days)... I am completely convinced that mandatory password rotation is counter productive
The company my wife uses for annual PCI-DSS recertification (a computer security / CC handling certification) requires that the password be changed every year. So that's once per login.
I personally don't find password counting detrimental. What's detrimental is SSO system that conflates local access password with remote access password and then often asks this password. Or has some kind of a dumb rule like "lock the machine after 10 minutes of inactivity and ask the remote password to be typed right on keyboard".
Yep! The quickest way to get your users to use incredibly weak passwords and make it so they must physically type it all the time. I can have a 32 character password is unmemorizable, untypable by mortals, and even having a screenshot of it revealed would be a challenge to decipher password for services exposed to the internet. But I need something I can memorize, type with just alphanumerics, and enter quickly for my lock screen.
If that's really the case it seems less bad to have the company provide unchangeable passwords... (if they're unable to switch to safer solutions)
Usually they're trying username/password combinations that they got from some other breach. They figure people often re-use passwords, so using the same username & password on multiple sites to try to log in often works. That's what a "password spraying" attack is. Even if a breach forces people to change a password they've used on one site they'll often not change it on other sites, so this still tends to work.
What you're describing is typically called credential stuffing.
Password spraying is a distinct form of brute-forcing, where there is no link between the password and the user, and the yield is coming from the password being common.
Password spraying is a distinct form of brute-forcing, where there is no link between the password and the user, and the yield is coming from the password being common.
Right, I swapped them in my head. Thanks for the correction!
Think about it this way: you are going to do N amount of work (password trials) either each against a different account, or all against the same account. Which is more likely to result in a break?
If you try against the same account, for each trial you gain a (very small) piece of information (that the account does not use that password) which you can use in later trials, which seems like an advantage over trials against different accounts, where you don't gain this information.
But we also know that there are a significant number of accounts using weak passwords. If you keep trying against the same account, you will try the weak (high probability) passwords first, but if they don't break the account then you will run out of those and have to try low probability ones. But if you try against different accounts, you can keep retesting the high probability passwords. So trying against a different account each time is almost certainly more efficient - as long as you don't care about which account you break.
If you try against the same account, for each trial you gain a (very small) piece of information (that the account does not use that password) which you can use in later trials, which seems like an advantage over trials against different accounts, where you don't gain this information.
But we also know that there are a significant number of accounts using weak passwords. If you keep trying against the same account, you will try the weak (high probability) passwords first, but if they don't break the account then you will run out of those and have to try low probability ones. But if you try against different accounts, you can keep retesting the high probability passwords. So trying against a different account each time is almost certainly more efficient - as long as you don't care about which account you break.
> trials against different accounts, where you don't gain this information (that the account does not use that password)
I would think that you do gain this info, the question is whether you record it for later use, which seems possible. But the extra effort to do that is a downside.
The upside is of course that 1000 failed login attempts on 1 account is more likely to trigger alarms than 2 attempts on each of 500 accounts.
I would think that you do gain this info, the question is whether you record it for later use, which seems possible. But the extra effort to do that is a downside.
The upside is of course that 1000 failed login attempts on 1 account is more likely to trigger alarms than 2 attempts on each of 500 accounts.
The success rate is also likely pretty high. You're not necessarily restricted to just the entropy of a single password, but depending on the attack vector it can be conditioned on also knowing the account owner's identity or username/email. Combine that property with the insane payoff of uncappable Azure access, and this starts to look more attractive.
You are right, lots of people are under impression that there is a “dedicated attacker”.
The reality is there are loads of “opportunistic attackers”.
Then you also have to realize all is automated so there is no one hand picking stuff so basically harvesters running over those easy credentials. Successful ones are notified to the attackers. So running those harvesters is low effort and low investment - but even single one lucky hit can be a big payoff.
Then imagine big payoff for someone in 3rd world countries is $100.
The reality is there are loads of “opportunistic attackers”.
Then you also have to realize all is automated so there is no one hand picking stuff so basically harvesters running over those easy credentials. Successful ones are notified to the attackers. So running those harvesters is low effort and low investment - but even single one lucky hit can be a big payoff.
Then imagine big payoff for someone in 3rd world countries is $100.
I put up a bare metal server with a public IP for the first time in a long time and I was stunned by how many automated opportunistic attempts it got.
Makes sense, like you say.
Makes sense, like you say.
Interesting but from the article I haven't understood how they actually managed to group together the 24 Users Targeted in 1 Week and understood this was a malicious attack.
Yeah agreed that there wasn’t much information there.
Having investigated similar password spray attacks, I’m guessing they just looked at the entire set of failed Azure CLI logins from the same ASN (AS6939). Then that activity was distinct enough from usual activity in the tenant to suspect it’s part of the same campaign (no prior logins from AS6939, little to no legitimate use of Azure CLI, or the job profile of the targeted users doesn’t align with usage of Azure CLI).
Having investigated similar password spray attacks, I’m guessing they just looked at the entire set of failed Azure CLI logins from the same ASN (AS6939). Then that activity was distinct enough from usual activity in the tenant to suspect it’s part of the same campaign (no prior logins from AS6939, little to no legitimate use of Azure CLI, or the job profile of the targeted users doesn’t align with usage of Azure CLI).
It seems like marketing blogspam.
Anyone can come up with multiple hypothetical scenarios and fixes, share it, and as we see reach hn front page.
Anyone can come up with multiple hypothetical scenarios and fixes, share it, and as we see reach hn front page.
Probably look for other attacks from the same AS, geo-ip, or some other proxy of being from that one datacenter.
In the context of security, IPv6 has no meaningful granularity below /64. Seconds of research will also show how cheap it is to get a /48 as well. Everytime I see full IPv6 addresses as if they were meaningful at that resolution, I die just a little bit on the inside. Policy issues with filtering by country of origin aside; ASN would be a better filter here over country of origin.
It's also unclear why using a /48 helps evade their indicators of compromise detection?
> Takeaway: Looking at User Activity Timelines Isn’t Enough
I mean, obviously? You'd only look at a users timeline if a user was compromised. Looking at users timeline looking for infra attacks is like studying the rings on a tree you just cut down, as a means to determine if the forest is on fire.
As a whole this intro to security detection doesn't fill me with a ton of confidence... Everything here is exclusively superficial.
It's also unclear why using a /48 helps evade their indicators of compromise detection?
> Takeaway: Looking at User Activity Timelines Isn’t Enough
I mean, obviously? You'd only look at a users timeline if a user was compromised. Looking at users timeline looking for infra attacks is like studying the rings on a tree you just cut down, as a means to determine if the forest is on fire.
As a whole this intro to security detection doesn't fill me with a ton of confidence... Everything here is exclusively superficial.
That's great but why didn't you enable two factor authentication?
The general solution against this attack is to generate random passwords for users, not force them into 2FA (for more annoying).
Isn't this a normal thing for service exposed to the internet?
How do you differentiate attack campaign from your everyday-business-as-usual hacking attempts?
How do you differentiate attack campaign from your everyday-business-as-usual hacking attempts?
"Out of my 24 user accounts, all of whose names are known to attackers somehow, one got hacked after two attempts. So I think the best course of action is to write a blog about how clever I am with 'log slicing'."
> Password spraying is a type of brute force attack. In this attack, an attacker will brute force logins based on list of usernames with default passwords on the application. For example, an attacker will use one password (say, Secure@123) against many different accounts on the application to avoid account lockouts that would normally occur when brute forcing a single account with many passwords.
> This attack can be found commonly where the application or admin sets a default password for the new users.