
A Pentester's Guide: Osint, Breach Dumps, and Password Spraying - tuxloper
https://delta.navisec.io/osint-for-pentesters-part-3-password-spraying-methodology/
======
mpettitt
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.

------
nubb
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>

~~~
EnFinlay
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.

~~~
nubb
I cant disagree with you there :)

~~~
bashwizard
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.

------
joeyrideout
Not discussed is the antidote for blue teams:

\- 2FA

\- Password blacklists

\- Application Firewall that detects this hijinx (haven't explored this yet -
anyone know of a good one?)

~~~
tptacek
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.

You should have some kind of SSO set up, early.

~~~
mc32
What do you about providers who while they support SAML keep the front door
open after setting up trusts?

~~~
Kalium
You feed your strong preference for SSO into procurement, which can really
help cut down on the number of such vendors.

------
technion
Since they mention Office 365, it's worth noting Microsoft's Smart Lockout
tooling has been pretty efficient here imo.

[https://www.microsoft.com/en-
us/microsoft-365/blog/2018/03/0...](https://www.microsoft.com/en-
us/microsoft-365/blog/2018/03/05/azure-ad-and-adfs-best-practices-defending-
against-password-spray-attacks/)

There are also some great capabilities like forcing a password reset after
multiple "correct password but failed MFA" logons.

------
mkagenius
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.

