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 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 between then and now.
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 many of the methods I dropped since have stopped working. Think of this article as a 2019 edition or 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 have at least a passing familiarity with the concept of password spraying. It is not a new concept and 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 as such I am ecstatic to share my methodology and my way of working.
In the mid-2000’s, brute-forcing was something everybody was doing. They would find a valid account, either on a web service or a remote access service like RDP, and hammer on it using a wordlist such as rockyou.txt. Today, vendors are smarter; 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 were locked out after 3 wrong attempts. Hellmaybe you just mistyped it!
Something else also happened: 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 considering organisations at the time were starting to implement things like password complexity rules, password rotation policies, etc. These are 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?”
Good question. Password spraying is the act of trying a few common passwords on multiple accounts. With spraying, we’re looking for the badly secured accounts rather than the passwords for 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 fairly 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.
Also look at TXT records:
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; check subdomains for things like Jira or any number of other platforms.
Once you’ve got your target you want to spray, let’s proceed.
Email Generation
If you’ve read my previous OSINT articles you’ll already have a feel for how we can do this. Over the years I have perfected my method and have put it into a really nice headless tool I call [EmailGen](https://github.com/navisecdelta/EmailGen) (Original, right?).
The tool is simple; it uses Bing, which was way easier to scrape than Google without messing with API keys, and we 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 to see what comes back. You’re looking for how their LinkedIn page is formatted. Some LinkedIn pages will be simply “Company”, some will be “Company, Inc”, etc.
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/
Once the search returns, hunter generally returns a format we can input into EmailGen, for example: {first}.{last}@{domain}
For Microsoft, we would run the following:
./EmailGen.rb -c "Microsoft" -d "microsoft.com" -f "{first}.{last}@{domain}" -o microsoft-emails.txt
Quick tip, EmailGen can also be used to generate a CSV of names and emails. Just supply the format as `{first},{last},{domain}`.
Now that you’ve got these email addresses 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 one 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 was remotely locked after my iCloud account had been 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 uses Selenium to scrape WeLeaks paid accounts in order to pull plaintext credentials.
As with all good things, it stopped working.
Thankfully, 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.) We then wrote a command-line tool that could query ES. We more or less 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. I may or may not be sharing more information or resources to build your own WikiLeaks in the future. If I do, it will be on my twitter, https://twitter.com/pry0cc/, so follow me for updates.
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.
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 such data, 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 number of security professionals but is rarely put into code.
I wrote another tool that I call [X-Prey](https://github.com/navisecdelta/X-Prey). X-Prey takes the breached password list you created earlier (or generated with Titan) along with the email list (that you generated with EmailGen) and makes a specialised wordlist just for spraying. Once this combined list is generated you’ll have the ability to leverage potential password reuse in your spraying campaigns.
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 your intentions. If you’re trying to spray Lync, OWA, Office365, or anything like that I strongly suggest checking out the [PasswordSprayingToolkit](https://github.com/byt3bl33d3r/SprayingToolkit/), and use Atomizer. If you’re spraying anything else, BurpSuite can be incredibly helpful in this endeavour.
Quick Tip: If you have Burp Pro, 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.
Right click the proxy request and select “Send to 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.
Now load in your username and password lists accordingly, and hit start
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 in this particular example.
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 achieve successful authentication. Other systems may return 200 success for every request, even the failed authentication attempts. If you find this is the case you should start filtering responses by the length, 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, though do be aware that it is not full-proof when attackers employ social engineering methods to extract codes from people. Nevertheless, it is another link the armour of defence you’re building.
Personally, I am still evaluating good ways of developing a working proxycannon (that doesn’t you an arm and a leg), but if attackers are spraying without a proxycannon correlating failed login attempts from the same IPs may also be a great way to defend yourself.
Credit: https://news.ycombinator.com/user?id=joeyrideout
Conclusion
In conclusion, password spraying is a methodology that takes a healthy amount 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 handle this on a day-to-day basis.
If you enjoyed this, please like or upvote wherever you found it, and share it!
Stay snappy Hackers!
Ben Bidmead – Offensive Security Engineer at NaviSec Delta
