[HN Gopher] Unmasking a slow and steady password spray attack
___________________________________________________________________
Unmasking a slow and steady password spray attack
Author : noleary
Score : 55 points
Date : 2025-03-29 05:13 UTC (2 days ago)
(HTM) web link (petrasecurity.substack.com)
(TXT) w3m dump (petrasecurity.substack.com)
| giorgioz wrote:
| 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.
| petergs wrote:
| 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).
| 4gotunameagain wrote:
| 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.
| advisedwang wrote:
| Probably look for other attacks from the same AS, geo-ip, or
| some other proxy of being from that one datacenter.
| Liftyee wrote:
| 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.
| hansvm wrote:
| 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.
| SAI_Peregrinus wrote:
| 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.
| jsnell wrote:
| 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.
| ajb wrote:
| 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.
| SideburnsOfDoom wrote:
| > 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.
| InitialBP wrote:
| 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 (first.last@company.com)
|
| 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...
| arcbyte wrote:
| 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.
| ptsneves wrote:
| I havent been in a single company that does not force the
| rotation of passwords. I worked in 4 different F500
| companies.
| mjevans wrote:
| 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.
| robertlagrant wrote:
| 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.
| InitialBP wrote:
| 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.
| icameron wrote:
| 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
| rwmj wrote:
| 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.
| GoblinSlayer wrote:
| 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".
| Spivak wrote:
| 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.
| mr_mitm wrote:
| 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.
| g-b-r wrote:
| 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)
| ozim wrote:
| 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.
| yellow_lead wrote:
| That's great but why didn't you enable two factor authentication?
| hombre_fatal wrote:
| The general solution against this attack is to generate random
| passwords for users, not force them into 2FA (for more
| annoying).
| kazinator wrote:
| "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'."
| grayhatter wrote:
| 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.
| barbazoo wrote:
| https://owasp.org/www-community/attacks/Password_Spraying_At...
|
| > 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.
| jsnell wrote:
| I'm not convinced. Password spraying attacks have a very low
| yield, and need high volume to compensate. 24 attempts per week
| is just not viable.
| Damogran6 wrote:
| You just need one.
___________________________________________________________________
(page generated 2025-03-31 23:01 UTC)