Ensure Burp and the OWASP BWA VM are running and that Burp is configured in the Firefox browser used to view the OWASP BWA applications.

1. From the OWASP BWA Landing page, click the link to the OWASP Mutillidae II application.
2. Open the Firefox browser to the login screen of OWASP Mutillidae II. From the top menu, click Login.
3. At the login screen, attempt to login five times with username admin and the wrong password of aaaaaa. Notice the application does not react any differently during the five attempts. The application does not change the error message shown, and the admin account is not locked out. This means the login is probably susceptible to brute-force password-guessing attacks:

Let's continue the testing, to brute-force the login page and gain unauthorized access to the application.

4. Go to the Proxy | HTTP history tab, and look for the failed login attempts. Right-click one of the five requests and send it to Intruder:

5. Go to Burp's Intruder tab, and leave the Intruder | Target tab settings as it is. Continue to the Intruder | Positions tab and notice how Burp places payload markers around each parameter value found. However, we only need a payload marker around the password's value. Click the Clear § button to remove the payload markers placed by Burp:

6. Then, highlight the password value of aaaaaa and click the Add § button.
7. Continue to the Intruder | Payloads tab.  Many testers use word lists to brute-force commonly used passwords within the payload marker placeholder. For this recipe, we will type in some common passwords to create our own unique list of payloads.
8. In the Payload Options [Simple list] section, type the string admin123 and click the Add button: 

9. Add a few more strings, such as adminpass, welcome1, and, finally, admin to the payload-listing box:

10. Go to the Intruder | Options tab and scroll down to the Grep – Extract section:

11. Click the checkbox Extract the following items from responses and then click the Add button. A pop-up box appears, displaying the response of the unsuccessful login attempt you made with the admin/aaaaaa request.
12. In the search box at the bottom, search for the words Not Logged In. After finding the match, you must highlight the words Not Logged In, to assign the grep match correctly:

13. If you do not highlight the words properly, after you click OK, you will see [INVALID] inside the Grep – Extract box. If this happens, remove the entry by clicking the Remove button and try again by clicking the Add button, perform the search, and highlight the words.
14. If you highlight the words properly, you should see the following in the Grep – Extract box:

15. Now, click the Start attack button at the top right-hand side of the Options page.
16. A pop-up attack results table appears, displaying the request with the payloads you defined placed into the payload marker positions. Notice the attack table produced shows an extra column entitled ReflectedXSSExecution. This column is a result of the Grep – Extract Option set previously. 
17. From this attack table, viewing the additional column, a tester can easily identify which request number successfully brute-forced the login screen. In this case, Request 4, using credentials of the username admin and the password admin logged us into the application:

18. Select Request 4 within the attack table, and view the Response | Render tab. You should see the message Logged In Admin: admin (g0t r00t?) on the top right-hand side:

19. Close the attack table by clicking the X in the top right-hand corner.

You successfully brute-forced the password of a valid account on the system, due to the application having a weak lock-out mechanism.