A Pentesters Guide – Part 3 (OSINT, Breach Dumps, & Password Spraying)

Author: No Comments Share:

Hey hackers! I noticed that a lot of people enjoyed my older OSINT articles (on our old company website, we were formerly Sequoia Cyber Solutions).

Even to the point that the article got Reddit Gold on /r/netsec 🙂

If you’ve not read those, check them out Part 1 and Part 2 respectively!

After both of these articles blew up, even months after I released them, I wanted to do another article going over some of the techniques I demonstrated that have changed.

What I am going to cover today has already been touched on in previous articles, but I did not feel that it was comprehensive enough and a lot of the methods I dropped since have stopped working.

Think of this as a 2019 edition / version 2 of the last article “LinkedIn isn’t just for Jobs”. If I’ve done my job properly, you should walk away with a good idea of how password spraying works, and how you can leverage little-known tricks of the trade to increase your chances of popping a user.

In this article

  • Identifying services used by companies
  • Generating emails
  • Indexing breach data like a hacker
  • Generating password spraying wordlists
  • Password Spraying with BurpSuite

Without further ado, let’s get started!

If you’re a red teamer, a pentester living in 2019, or anybody deeply involved in the security industry, you should be pretty familiar with the concept of password spraying.

It is not a new concept, it has likely been written about thousands of times before this. However, as with everything, I often have a unique (some call it weird), way of doing things, and so I am ecstatic to share my methodology and my way of working.

In the mid-2000’s, brute-forcing was something everybody was doing. Find a valid account, either on a web service or an remote access service like RDP, and hammer on it using a wordlist such as rockyou.txt.

Today, vendors are smarter and so they detect failed login attempts, log them, and lock accounts when they receive too many.

We did notice something though: vendors generally allow 4-5 wrong passwords before locking an account. It would be super annoying if as a user, whenever you forgot your password, you got locked out after 3 wrong attempts. Hell – maybe you just mistyped it!

The other thing that happened was that people started thinking up more secure passwords. Being network based, even if the vendor doesn’t lock accounts, a successful brute force could take weeks to complete!

This was far from ideal, especially since organisations at this time were starting to implement things like password complexity rules, password rotation policies, all things that add to security, right?

Well, sorta. If you’re brute forcing, it might make your life more difficult (this is why we have hashcat rules), but if you’re spraying, you will be very grateful for these rules.

“Whats password spraying?”

I hear you ask. Good question.

Password spraying is the act of trying a few common passwords on multiple accounts. We’re looking for the badly secured accounts rather than looking for the passwords on a single account.

What do we need to password spray?

  • Knowledge of the target’s services (Email is a good one)
  • A list, (the bigger the better), of email addresses valid at the target service
  • Knowledge of password complexity rules (we can guess these)
  • Knowledge of common passwords
  • Optional: Passwords from breaches relating to user accounts (this is invaluable in increasing your chances)

If you’ve endured my writing up until this point, you have my total respect. I have a funny feeling you’re going to love this bit.

As the transition between theory to practice, I’d like to be a bit cheeky and take this as an opportunity to ask if you’re liking this article, please share this!

Passive service reconaissance

Finding out what services a company uses is pretty easy, and you can do it all passively.

For this, I like to break out my little friend DNSDumpster. Put in your targets domain name and check for MX records.

MX Records for Microsoft.com

Also look at TXT records:

TXT records for Microsoft.com

If you’re dealing with a company that uses Office 365 for email, you’ll see things like microsoft-com.mail.protection.outlook.com and TXT records to allow sending email through Microsoft.

The same is also true for corporations that use Gmail. (If you look closely it’s usually pretty easy to determine.)

Password spraying isn’t just limited to email services, either, check subdomains for things like Jira, or any number of platforms and use BurpSuitePro Intruder to spray those.

Got your target to spray? Great.

Email Generation

If you read my previous OSINT articles, then you’ll already have a feel for how we can do it. Over the year I have perfected my method and have put it into a really nice headless tool I call EmailGen (I know original right!).

EmailGen Help Menu

It’s a pretty simple tool, it uses Bing, which was way easier to scrape than Google was without messing with API keys. We also don’t sacrifice much on accuracy either, which is nice.

The first thing I like to do before running this tool is Google linkedin.com your target company and see what comes back. You’re looking for how their LinkedIn page is formatted. Some company’s LinkedIn page will be just “Company”, some are “Company, Inc” etc

Googling LinkedIn Company Page

In this case, we can see that for Microsoft the name used on their LinkedIn is simply, “Microsoft”.

Now, you need to figure out the format that the company uses to structure email addresses. We can do this manually or break out our trusty friend: https://hunter.io/

Searching Microsoft.com for Hunter.io

Once the search returns, hunter generally returns a format we can input into EmailGen, for example: {first}.{last}@{domain}

Hunter.io result for Microsoft.com search

For Microsoft, we would run the following:

./EmailGen.rb -c "Microsoft" -d "microsoft.com" -f "{first}.{last}@{domain}" -o microsoft-emails.txt
Running EmailGen
Quick tip, EmailGen can also be used to generate a CSV of names and emails. Just supply the format as `{first},{last},{domain}`.

Now you’ve got these emails, you can begin the next stage.

Indexing breaches like a hacker

In my last article, I spoke about using the WeLeaks API to cycle through emails and get domains. Since then, the WeLeaks API has been deprecated due to abuse.

For the uninitiated, WeLeaks is a service that gathers breaches and indexes them. Services such as Dropbox, AdultFriendFinder, MySpace, LinkedIn, have all been hacked at once point and user information has been dumped. WeLeaks takes this information and makes it searchable.

Real criminals generally preform a technique known as ‘password stuffing’ taking breach data and trying user accounts with the breached passwords hoping they have reused a password.

I was actually personally affected by this in 2014 when my MacBook Pro got remotely locked after my iCloud account got breached due to a password stuffing campaign.

Anyway, back to the article.

In response to WeLeaks closing off their API, I came up with a tool called CredCatch, it used selenium to scrape WeLeaks paid accounts in order to pull plaintext credentials.

As with all good things, it stopped working. 

Luckily, I have Irish heritage, so I’m stubborn. I started grinding away with my partner in crime @DevinStokes on a project to index password breaches, such as BreachCompilation, in an ELK stack. That’s Elasticsearch, Logstash & Kibana.

Then, we wrote a command-line tool that could query ES. We basically built our own WeLeakInfo. I wish I could share more information on this project, but I’m afraid I might be limited with regards to the legality of handling breach data.

Titan in action

If you ever get around to building your own WeLeakInfo, I may or may not be sharing more information or resources to build your own in the future. If I do, it will be on my twitter, https://twitter.com/pry0cc/, so follow me for updates.

It’s possible to get breach data through either WeLeakInfo or via BreachCompilation manually. Once you have these, put the emails and passwords into a file like this:

alice@example.org:breachedPass123
alice@example.org:breachedPass33
bob@example.org:mysupersecretleakedpass

We’re going to be using this file later.

Generating Password Spraying Wordlists

This method is something that is informally referred to by a lot   of security professionals but is rarely put into code.

I wrote another tool that I call X-Prey. X-Prey takes the breached password list you made up earlier (or generated with Titan), the email list (that you generated with EmailGen), and makes a specialised wordlist just for spraying.

Once generated, you’ll have the ability to leverage the facet of password reuse in your spraying campaigns.

Using X-Prey to generate a wordlist

Password spraying

Now this is the fun part. So far we’ve:

  • Generated a list of Emails
  • Found breached passwords
  • Generated a unique wordlist for spraying

If you’ve not hit any snags, your wordlist should look something like the following:

wordlist.txt

(Truncated)
alice@example.org:NaviSec2019!
alice@example.org:Pa$$w0rd!
sean@example.org:12345
sean@example.org:Spring2019
sean@example.org:Spring2019!
sean@example.org:Pa$$w0rd!
dcuthbert@example.org:DontCallMeDanny
dcuthbert@example.org:NaviSec2019
dcuthbert@example.org:Pa$$w0rd!

Let’s split this wordlist into two pieces so we can feed this into BurpSuite

cat wordlist.txt | sed 's/:/ /g' | awk '{ print $1 }' >> wordlist_users.txt && cat demo_wordlist.txt | sed 's/:/ /g' | awk '{ print $2 }' >> wordlist_passes.txt

At this point, what you use to spray is going to largely depend on what you intend to spray. If you’re trying to spray Lync or OWA, Office365, or anything like that, then I strongly suggest checking out the PasswordSprayingToolkit, and use Atomizer.

However, if you’re spraying anything else, BurpSuite can be incredibly helpful in this endeavour.

If you have Burp Pro, then this is going to be a lot easier as the community version is limited with regards to the Intruder feature.

BurpSuite Intruder

Open your Burpsuite and ensure that the proxy is configured correctly and that your browser has a root SSL certificate installed.

Once ready, visit your target site and attempt to login. I generally go with admin:password so later when I’m picking through it is completely clear.

Burpsuite Proxy

Right click the proxy request and select “Send to Intruder”

Sending to Burp Suite Intruder

Once in Intruder, select “Positions” on the navigation menu at the top. Set Attack type to “Pitchfork”. And ensure that the positions are correctly set.

Selecting postions

Now load in your username list and password list accordingly, and hit start!

Position 1
Position 2

And voila! We should have all the results from our spray. Since this is a server I used purely for demonstration purposes, there was no authentication on this particular example.

The running attack

Real authentication systems will vary from system to system, some will be helpful and respond with 403 forbidden when authentication fails and 200 success when you get a successful authentication.

In others, it may return 200 success for every request, even the bad-authentication attempts. If you find this is the case, you should start filtering responses by the length, and then by the response content. All of this is quite straightforward in Burp.

Reading a comment on this article, I realised immediately that I missed an opportunity to speak about how you can defend against this.

If you’re a blue team and you’re trying to protect against password spraying, implementing password blacklists to stop the cliche “Summer2018” passwords can be a great first step.

Enforcing 2FA goes without saying also, although do know that this is not full-proof when you employ social engineering methods to extract codes from people. Of course, this is another link the armour of defence you’ll be building.

I am still evaluating good ways of developing a working proxycannon (that doesn’t cost you an arm and a leg), but if you’re spraying without a proxycannon, then correlating failed login attempts from the same IP’s would also be a great way to stop attackers doing this.

Credit: https://news.ycombinator.com/user?id=joeyrideout

Conclusion

In conclusion, password spraying is a methodology that takes a lot of preparation, using past-breached credentials is a technique I have not seen anybody else use before so I hope you enjoyed having a little peek into how I do handle this on a day-to-day.

If you enjoyed this, please like or upvote wherever you found it, and share it!

Stay snappy Hackers!

[Ben Bidmead](https://twitter.com/pry0cc/) – Offensive Security Engineer at NaviSec Delta

Previous Article

A Pentesters Guide – Part 3 (OSINT, Breach Dumps, & Password Spraying)

Next Article

A Pentesters Guide – Part 3 (OSINT, Breach Dumps, & Password Spraying)

You may also like

Leave a Reply

Your email address will not be published. Required fields are marked *