There are a few companies which are onto password spraying in this way, and use failed login attempts from a single source (e.g. IP address, ipv6 addresses within the same allocation block, etc) as a trigger state for additional monitoring or verification. That can just mean that the soc gets a notification, or can enable captcha for suspicious sources while the attack is going on.
This does of course fail when an attacker starts using multiple sources for attack traffic. That seems to be the next step in the cat and mouse game though.
Assuming the external app is using AD auth. What product do you use to blacklist? Currently I just audit the passwords by dumping the hashes from the DC and running them against HIBP NTLM database.
To prevent disappointment for others that are interested: note that this is commercial and to get any sort of preview, you need to sign up and they emphasize that they want your corporate contact info...
@nextgens: are you affiliated with them, or did you just have a good experience with their product and wanted to share it?
Let me know how it goes; if our sales droids don't come up with something acceptable on their own, I am keen to understand why and will work something out for you.
Last I saw black hills had a filter as well - but this is a problem. If companies have adopted Azure AD I believe they have some new options (sorry fuzzy on the details)
It's also a reason we generally push everyone to centralize authentication on an SSO provider like Okta or Google Cloud Identity, both because those platforms allow you to easily set policy requiring 2FA, which breaks the attack, and because OIDC and SAML let you log into lots of services without exposing each of them to account takeover independently.
There are other good reasons to do this, too.
At Black Hat last year, I cornered a bunch of CSO-types at big startups and asked for what their first 3 initiatives would be, and this was something I heard a bunch.
That, too! Especially if you have support personnel interacting with in-house applications, though putting those behind a VPN also goes a long way towards preventing account takeover on those applications.
But in general, the idea is that you want an SSO early so all the random SAAS applications you subscribe to can have a coherent security policy.
From my experience, anything SSO-related has a steep learning curve in wrapping your head around IDP, SP, metadata, IDP-initiated vs. SP-initiated... there's a whole lexicon that isn't very intuitive. Ask me to set it up a year ago and I would have described it as "a ton of work and very complicated". Eventually it stuck, though :)
Okta client here btw, and we use SAML (2.0) for many of our SSO integrations. Okta has pretty clear support for SAML 2.0. Maybe your colleague's app is a special case?
Nope, not at all. He knew all those words and more (he is basically an oauth expert)
He said the biggest problem is how okta handles user information, roles, rights and how it is stored. He said, that they have there own idea about it. (which can be good or bad...) didn't dig deeper though :)
At first glance I thought you were describing a more traditional network firewall, but with the data from application logs (failed logins, presumably) this becomes a very elegant entry WAF. Very cool!
This is a fun read for novices who are interested in infosec stuff.
<rant> I wish infosec tutorials/articles pushed writing custom tools. I've always considered password spraying to really be just taking super common passwords and flipping them around a bit. <season><year><special char> or <month><year><special char>. Instead of pushing some existing tools, I wish this article encouraged writing custom wordlist generators using common knowledge/sense. </rant>
On one hand I agree with you, on the other hand I don't think the space is short on people writing their own tools. The number of DNS enumerators I've seen shared over the past month alone speaks to this.
While custom tools are nice and all I don't really see the point of reinventing the wheel all the time.
If there is a tool/script/exploit/etc out there doing most of what I want, you can be sure that I'm going to use it and modify it to my needs instead of writing my own.
I'd say that's usually the case in 80% of the cases when doing pentests. Besides, time is money.
That sounds like guesswork, don't we already know which passwords are in common use from the various large-scale breaches? You could even use that data to train a character sequence model (e.g RNN), but really just randomly selecting from the 1000 most common passwords should be superior?
What you say is the article lacks depth of what you find important.
You could easily make such with a few UNIX tools such as date and seq plus a few variables in your favorite language. So that is covered in Linux, Bash, and Python courses.
Burp also has support to prepend or append characters. They could've covered that as it is rather powerful. They could've also covered grabbing pastes from dark web to use as input.
I need a tool which tells where have I registered using the breached passwords. Often, the problem is not knowing which services you signed up for in the first place.
The easiest way would be for the said services to do this for their users whenever a new password dump surfaces.
Or even a way to test my username and password on top 5000 sites in an automated way should help.
40 comments
[ 3.2 ms ] story [ 94.1 ms ] threadThis does of course fail when an attacker starts using multiple sources for attack traffic. That seems to be the next step in the cat and mouse game though.
- 2FA
- Password blacklists
- Application Firewall that detects this hijinx (haven't explored this yet - anyone know of a good one?)
We are open to hiring somebody for firewall management (specifically Fortinet firewalls) as part of our Sentry offering.
https://navisec.io/services/sentry/
Assuming the external app is using AD auth. What product do you use to blacklist? Currently I just audit the passwords by dumping the hashes from the DC and running them against HIBP NTLM database.
@nextgens: are you affiliated with them, or did you just have a good experience with their product and wanted to share it?
We have a video that shows how to set it up and basic operation: https://safepass.me/demo-video
We have a free "home-use" license: if your PC isn't hooked onto AD, it will just work. https://safepass.me/get-the-documentation https://safepass.me/download (the MSI)
There are other good reasons to do this, too.
At Black Hat last year, I cornered a bunch of CSO-types at big startups and asked for what their first 3 initiatives would be, and this was something I heard a bunch.
You should have some kind of SSO set up, early.
That is are you talking about integrating your product with SSO or integrating your IT systems?
But in general, the idea is that you want an SSO early so all the random SAAS applications you subscribe to can have a coherent security policy.
As far as I heard it is a ton of work and very complicated. (they can't use saml, they use oauth)
Okta client here btw, and we use SAML (2.0) for many of our SSO integrations. Okta has pretty clear support for SAML 2.0. Maybe your colleague's app is a special case?
He said the biggest problem is how okta handles user information, roles, rights and how it is stored. He said, that they have there own idea about it. (which can be good or bad...) didn't dig deeper though :)
Happy Okta client here.
1. Make sure your app requests are logged with the source IP and configure fail2ban to block the really bad offenders.
2. Set up `actionban` and `actionunban` commands in a custom fail2ban banaction.conf file.
3. Use ipset (an iptables extension) for O(log n) lookup against banned IPs in iptables (which affects all input/forward/output network requests).
4. Tadaa!
<rant> I wish infosec tutorials/articles pushed writing custom tools. I've always considered password spraying to really be just taking super common passwords and flipping them around a bit. <season><year><special char> or <month><year><special char>. Instead of pushing some existing tools, I wish this article encouraged writing custom wordlist generators using common knowledge/sense. </rant>
If there is a tool/script/exploit/etc out there doing most of what I want, you can be sure that I'm going to use it and modify it to my needs instead of writing my own.
I'd say that's usually the case in 80% of the cases when doing pentests. Besides, time is money.
You could easily make such with a few UNIX tools such as date and seq plus a few variables in your favorite language. So that is covered in Linux, Bash, and Python courses.
Burp also has support to prepend or append characters. They could've covered that as it is rather powerful. They could've also covered grabbing pastes from dark web to use as input.
https://www.microsoft.com/en-us/microsoft-365/blog/2018/03/0...
There are also some great capabilities like forcing a password reset after multiple "correct password but failed MFA" logons.
The easiest way would be for the said services to do this for their users whenever a new password dump surfaces.
Or even a way to test my username and password on top 5000 sites in an automated way should help.