How to bruteforce development, CI/CD, and other apps with Hydra and the Password Auditor

The Bitbucket login form usually sits on the /login endpoint.

Use the Network tab in Web Developer Tools to identify the parameters.

After one invalid attempt, the following message is returned:

After two failed attempts, the CAPTCHA is activated.

We used the following commands to bruteforce Bitbucket with Hydra with one pair of valid credentials and one pair of invalid ones:

As shown in the output, Hydra correctly identified both invalid and valid credentials.

For the second scenario with multiple usernames and passwords, we used the following command:

Hydra identified the valid credentials when testing 2 users and 13 passwords.

For the first scenario, these are the parameters we adjusted to perform a more focused scan:

• Target: http://bitbucket.pentest-ground.com:7990/login

• Ports: Use port from target URL

• Services: HTTP

• Wordlists: pa-benchmark

Because the pa-benchmark wordlist includes the valid credentials, the tool will make 4 attempts against the target - 3 with invalid credentials and one with valid credentials.

As the screenshot below shows, the Password Auditor successfully identified the valid credentials.

It also delivered a screenshot of the logged-in session to confirm the provided credentials are valid.

For the second scenario, we modified the wordlist to include 2 users (1 invalid and 1 valid) and 12 passwords (11 invalid and 1 valid).

The Password Auditor reports that the Bitbucket server activated its CAPTCHA protection. In the Details section, we recommend using the Password Spray attack type or splitting the scan into multiple scans with smaller wordlists.

The Jenkins login form is usually found on the /login endpoint.

Use the Network tab in Web Developer Tools to identify the parameters.

After one invalid attempt, Jenkins returns the following message:

In the first scenario, we used the following Hydra commands to bruteforce Jenkins:

As shown in the output, Hydra failed to identify the invalid and valid credentials, marking both as invalid.

For the second, multi-credentials scenario, we used the following Hydra command:

When testing 2 users and 13 passwords, Hydra failed to identify the invalid and valid credentials, marking all as invalid.

For the first scenario, these are the parameters we adjusted to perform a more focused scan:

• Target: https://jenkins.pentest-ground.com/login

• Ports: Use port from target URL

• Services: HTTP

• Wordlists: pa-benchmark

The pa-benchmark wordlist includes valid credentials, so the process involves making four attempts to the target: 3 with invalid credentials and 1 with valid credentials.

The screenshots below show that Password Auditor successfully identified the valid credentials.

The Password Auditor provides a screenshot of the logged-in session to verify the validity of the provided credentials.

For the second scenario, we modified the wordlist to include 2 users (1 invalid and 1 valid) and 12 passwords (11 invalid and 1 valid).

The Password Auditor identified the valid credentials when testing 2 users and 12 passwords.

Most often, the Gitlab CE login form sits on the /users/sign_in endpoint on port 80 or port 443.

Use the Network tab in Web Developer Tools to identify the parameters.

Note that GitLab CE uses authenticity_token as a CSRF token.

After one invalid attempt, Gitlab Community Edition returns the following message:

The login form seems to shadow ban your IP after multiple failed login attempts. You still get the Login failed message in the browser even if you use the correct credentials.

In the first 1 set of valid and 1 set of invalid credentials scenario, we used the following Hydra commands:

GitLab uses authenticity_token as a CSRF token, which is different for each request. Since Hydra requires this parameter to be configured as static, it cannot generate these tokens. Consequently, Hydra marked both attempts as valid credentials.

Since the first scenario didn't work, we did not proceed with testing the second one.

For the first scenario, these are the parameters we adjusted to perform a more focused scan:

• Target: http://gitlab.pentest-ground.com/users/sign_in

• Ports: Use port from target URL

• Services: HTTP

• Wordlists: pa-benchmark

The pa-benchmark wordlist includes valid credentials, so the process involves making four attempts to the target: 3 with invalid credentials and 1 with valid credentials.

The screenshots below show that the Pentest-Tools.com Password Auditor successfully identified the valid credentials.

The Password Auditor also provides a screenshot of the logged-in session to verify the validity of the provided credentials.

For the second scenario, we modified the wordlist to include 2 users (1 invalid and 1 valid) and 12 passwords (11 invalid and 1 valid). 

As mentioned in the Identify error messages and protection mechanisms section, it seems that the target shadow bans the source IP of the attack. Therefore, the Password Auditor didn’t identify the valid credentials, when testing the target app with 2 users and 13 passwords.

The default admin login page for JetBrains TeamCity is typically located on the /login.html endpoint on port 8111.

Use the Network tab in Web Developer Tools to identify the parameters.

In JetBrains TeamCity, the login page uses the publicKey and encryptedPassword parameters as part of the authentication process to enhance security. 

Here's a brief explanation of each concept:

• publicKey: This is the public portion of a key pair (public/private key) used for RSA encryption. JetBrains TeamCity provides this public key to the client (browser) during the login process. The public key is used to encrypt sensitive information, specifically the password, before it gets sent to the server. This helps protect the password during transmission, even if the data is intercepted.

• encryptedPassword: This is the user's password, encrypted using the RSA public key provided by TeamCity. When a user enters their password, it is encrypted client-side using JavaScript with the public key. The resulting encryptedPassword value is then sent to the server instead of the plain text password. On the server side, TeamCity uses the corresponding private key to decrypt the password and authenticate the user.

This mechanism prevents the plain text password from being exposed during transmission, adding an extra layer of security against potential interception or eavesdropping attacks.

After one invalid attempt, JetBrains TeamCity returns the following message:

After 5 failed login attempts, the user gets locked out for 1 minute.

Since Hydra can’t use the Javascript that encrypts the password using the public key, we considered that the scenarios cannot be tested.

For the first scenario, these are the parameters we adjusted to perform a more focused scan:

• Target: http://teamcity.pentest-ground.com:8111/login.html

• Ports: Use port from target URL

• Services: HTTP

• Wordlists: pa-benchmark

The pa-benchmark wordlist includes valid credentials, so the process involves making four attempts to the target: 3 with invalid credentials and 1 with valid credentials.

As shown in the screenshots below, the Password Auditor on Pentest-Tools.com successfully identified the valid credentials.

The Password Auditor also provides a screenshot of the logged-in session to verify the validity of the provided credentials.

For the second scenario, we adjusted the wordlist to contain 2 users (1 invalid and 1 valid) and 13 passwords (12 invalid and 1 valid). 

JetBrains TeamCity temporarily locks the account/source IP and the Password Auditor can’t identify the valid credentials.