How to Cr@ck Passwords with Bruteforce?

Step 9: cracking passwords with bruteforce

Welcome to the 9th post of the 6M Challenge of Bug Bounty edition where you are going to learn about authentication attacks and how to crack passwords with Bruteforce. I am sure you will love this “attacking” post and will bookmark it. I hope that you have finished the tasks given in the previous post, i.e.:

  • Read up and try commands of Nmap on several websites.
  • Try usage of Nikto.
  • Use Burp Suite spider, see what kind of files you can find on your favorite websites.

So you must remember from Part 5, that an email-password login system is one of the most basic forms of security systems. And since it’s a security system, we’re gonna learn how to break it 😉

Let’s suppose you know your friend’s email address, now you go to a website where they have an account, you enter your friend’s email in the email section, and now you start guessing random passwords in the password field. This is exactly what brute force is, “Trying Passwords“… a lot of them. We’ll use our computers to do this thing at a crazy speed.

process of Cracking passwords | Authentication attacks

Open burp suite, and firefox. Go to your favorite website, enter your OWN email address, but enter any random password like this.


Turn Burp suite intercept on, and click on Sign in. Burp will capture the login request, like this:-

I’ve censored the confidential details with blue color. You need to focus on the red-highlighted parameters only.

Let me explain this HTTP request first. As soon as you enter your email and password and click on Login, the browser makes this request and sends it to the server. The server looks for an email in their database and matches the entered password with the password it already had on the server. If it matches, you’re allowed in. And our computer is gonna send these requests a lot of times until it finds the password.

So right-click on the Burp request space, and click on the “Send to intruder” button.

Go to the intruder tab. The intruder is basically a tool to send any kind of request en masse, hence “intruding”. Click on the “Positions” sub-tab. Click on the “Clear” button on the right. Now select the password field like this, and click the “Add” button.

This tells the intruder that this password is the parameter that we want to guess, this is the field which we want to brute-force. Next, go to the “Payloads” options and fill up options as follows:-

This will script our intruder to send passwords from “000000” to “000100”, hence sending 101 login requests with wrong passwords. Next, come back to the browser, enter your actual password, and click on the login button, if you succeed in logging in. You can be almost sure that the login system is vulnerable to Bruteforce. This is our theory, let’s execute the attack by clicking on the “Start attack” button on the top-right.

The attack will start in a window like this:-


The speed of attack will depend on your distance from the server, internet speed, server response time, Burp’s limitations, etc. In my case, the web application is very safe against brute force, because it stops blocking HTTP requests after 30. Basically, an attacker won’t be able to send more than 30 password requests, hence brute force won’t work here.


But here is an example of working Bruteforce vulnerabilities- – This is a very simple case of Bruteforce, but the hacker was able to bruteforce OTP, which is very serious, since this is only 4 digit OTP, so there are no more than 9999 possible combinations of OTP, so an attacker could take over any account in literally a minute or two, depending on the internet speed. The level of threat this bug posed, is the reason it got paid 1000$.

This is how attacking scenarios look like in bruteforce vulnerabilities- I code a script to enter all possible 4 digit OTPs- 0000, 0001, 0002, all the way to 9999, and as soon as I reach the correct at OTP, the website will allow me in. The same could be done with 6-digit OTPs.

how companies protect themselves from such passwords attack?

One way companies protect themselves against brute force is by blocking only one particular IP address, which means I won’t be able to send more than a particular number of requests from one IP, but if I switch my IP with VPN or Proxy, I can send login requests again, which is why such methods of brute force protection are useless.

You should always report if you’re able to send more login requests from some other IP, after being blocked from one IP. Here’s an example of this exact bug-

Then there’s another method of brute force security, which is by keeping a delay between when you’re allowed to send a login request. Such barriers often prove to be useless on OTPs, especially the smaller ones, because even if you keep a 10-second gap between two OTP login requests, a 4-digit OTP can be cracked in about a day. Here’s an example of this bug-

The most popular barrier against brute force is Captcha because our coded scripts cannot crack those.


But make sure to test around the captchas as well. Sometimes you can simply send the HTTP request because Captchas aren’t optimized well with the website. Sometimes you can do the verification yourself, imagine a web application where once you pass the captcha test, it sets your verification-status true on CLIENT-SIDE, and as we remember from the last tutorial, client-side securities are mostly useless.

So, sometimes you can simply change verification from false to true and the server will simply accept it. Therefore, a good login system, free of Bruteforce vulnerabilities is based on the following basic rules:-

  • It should have passwords and OTPs no shorter than 6 digits.
  • Having a limit on the number of password attempts in a day, which can range anywhere from 5 to 100.
  • The limit on OTPs should be even smaller, with nothing above 10.
  • If there’s a time limit on OTPs, they should expire within 30 minutes or so.
  • If HTTP requests are being blocked after a threshold, they should be blocked from everywhere, the attacker shouldn’t be able to just change the IP or device and bypass this block.
  • Website should have a well-optimized captcha system.

This is the set of general rules a login system should follow, there can be exceptions or context-based changes… some websites could require even stricter checks, while others might need more liberal security. Use common sense, over these rules, it’s easy babes 🙂

Tasks to be completed:

  • Read the 3 reports given above.
  • Perform brute force tests on the login systems of at least 5 websites you use in your daily life.

NOTE: I’ll always perform tests on secure websites to show in these articles because we can’t put other companies at risk for our learning. It would be like robbing an actual bank while giving police training. We’ll always test on already-secured websites, and take the case studies of past reports

See ya in the next one 🙂

Leave a Comment

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