Dropping Science

Now that I've discussed credential stuffing in theory, I'll show a successful credential stuffing attack in action using a WordPress EC2 instance that I have running in Amazon Web Services (AWS). Figure 4 shows the standard login page (note you need the correct URL for the login page in order to point Hydra directly to it).

Figure 4: A good, old WordPress login page.

Figure 5 shows what happens when you execute the following code:

$ hydra -L users.txt -P passwords.txt -t4 -f XXX.XXXXX.tld https-get /wp-login.php

Figure 5: A successful credential stuffing attack: Hydra has discovered my username and password with ease, shown in light green text.

I'll break down the above command to highlight the new options. The Xs redact one of my domain names used for testing on the WordPress server (that's the hidden part in Figure 5). Per the Hydra manual, the -f option is for exiting when a successful user/password is found. I've also lowered the number of parallel threads to -t4 from the default 16 to stop my laptop stressing out too much. Because I'm targeting a WordPress site running TLS, I use https-get instead of http-get like in the previous example. Also pay attention to /wp-login.php; this is my WordPress login page's URL.

For reference, I've used a couple of the passwords from Listing 1 and appended my known password to the last line. The username file is just populated with chris. For clarity, Hydra will try all the passwords available against each username unless told otherwise. This example doesn't really simulate a real attack, because an attacker will carefully gauge the sensitivity of the online service that they are attacking and work out how many incorrect logins are permitted.

Pay attention to the the lighter-green text shown in Figure 5 (the line beginning with [443]). That's where Hydra has successfully weaved its magic and found a valid account to log in with.

I will leave you to experiment with various URLs and other services that the multi-headed Hydra can attack. There are a lot of other useful Hydra options to try as you become more proficient at using Hydra (see Table 2).

Passwords Everywhere

In the introduction, I mentioned password spraying, which is very similar in nature to credential stuffing and easily confused. According to security firm CrowdStrike [15], the difference is that a password spraying attack uses two steps: "An attacker acquires a list of usernames, then attempts logins across all usernames using the same password. The attacker repeats the process with new passwords until the attack breaches the target authentication system to gain account and systems access."

With password spraying, the key difference is one common password is repeated across multiple users. If default passwords are used or password sharing takes place (something that I haven't come across, admittedly), then password spraying can be a successful route to compromising an account.

You can read more about password spraying as a more subtle form of a brute force attack on the CrowdStrike website [15].

Mitigating Attacks

Now that you know about these types of attacks, there are a few things you should do to prevent them:

• Always use multi-factor authentication (MFA) for logging in to accounts. If you use an online service that doesn't offer MFA, nudge them until they do.
• At the very least, ensure there are secondary defenses in addition to your password, such as a personal identification number (PIN) or a secret word or phrase to complement your password.

Website owners can also add these measures to improve their security posture:

• Check for location, browser version, screen resolution, etc., for each user's typical login profile and insist on extra login steps if they do not match.
• Run CAPTCHA puzzles to add a second layer of authentication.
• Introduce rate-limiting to prevent IP addresses from trying repeated logins.
• Blacklist IP addresses that log into multiple accounts.
• Add usernames that are not immediately guessable (e.g., instead of an email address or first name, use something like chrxbinx0091).

If you run your own Linux servers, then I highly recommend Fail2Ban for sophisticated rate-limiting [16]. An article [17] on the Linux Magazine website offers lots of tips on how to get started with Fail2Ban. One word of advice: Start cautiously to avoid potentially causing yourself access problems.