A Pentester's Guide: Osint, Breach Dumps, and Password Spraying | Hacker News Reader

A Pentester's Guide: Osint, Breach Dumps, and Password Spraying

delta.navisec.io

164 pointstuxloper39 comments

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.

I cant disagree with you there :)

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.

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.

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?)

Thanks, man! I've updated the article to reflect that.

You guys hiring?

We are unofficially, however not Offensive Security roles.

We are open to hiring somebody for firewall management (specifically Fortinet firewalls) as part of our Sentry offering.

https://navisec.io/services/sentry/

curious on the choice of Fortinet over other vendors like Palo Alto Networks or Checkpoint?

A lot of MSP's sold fortinet into small/med businesses due to costs and preferable licensing terms / commissions. They're everywhere in the market.

Thank you for the great piece! I always love to see Burp used in a way I haven't seen before.

>Password blacklists

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.

Check https://safepass.me out (an active directory password filter)

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?

Aren't most people looking for something like this going to be BigCo employees?

I am affiliated and no, you don't need to sign-up to get a preview:

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)

Sweet. I'm going to get a demo from them. I've demoed Specops and nFront products but they were a tad out of my organization's price range.

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.

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

Do you mean that your application you 'write' should support SSO early or that the applications you 'use' should?

That is are you talking about integrating your product with SSO or integrating your IT systems?

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.

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

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

Front door accounts should be vaulted away for when SSO is broken only.

A colleague is currently implementing okta.

As far as I heard it is a ton of work and very complicated. (they can't use saml, they use oauth)

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 :)

100% agree. Fewer auth providers (ideally, one) greatly reduces the work involved with mitigating this attack (and maintaining permissions, auditing, passthrough... everything gets easier, really).

Happy Okta client here.

additionally for passwords that are already stored, it's not too costly to check the hashes against the blacklist and revoke those existing passwords.

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

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!

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!

He mentions this at the end

AWS WAF is great - up and running same day, heck even same hour depending on architecture.

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

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

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.

Reply on news.ycombinator.com