Hydra the logon cracker, a brute-forcing how-to user guide

In our research against the iKettle, we noted that the telnet administrative interface was protected by a 6 digit PIN. In its default state this PIN was 000000 which obviously took no time to find, however when configuring the iKettle from an apple device, the PIN was updated to something a little more random, but still following the 6 numeric character pattern.

Whilst a step forward, we wanted to highlight how ineffective a 6 digit password was.

Brute forcing this PIN was obviously the way forward as the service didn’t enforce any lockouts or timeouts on unsuccessful logins. For this we’ll be using good old Hydra, a tool that every pen tester will have used at one time or another.

So, where to start? We need a ‘wordlist’ of 6 digit PINs. Whilst this would almost certainly be found on the internet somewhere, we created our own using the ‘crunch’ tool which takes the length and character set required and dumps all possibilities out to a file:

So, over to Hyrda.

Hydra supports multiple protocols. The version bundled with Kali for instance has support for the following:

…a good mix of old and new protocols in there (Does ICQ even exist anymore?)

Running Hydra against a telnet service is normally trivial, using the following syntax:

In this case the passwords in ‘password_file’ would be tested against the known user ‘username’.

We had one slight issue with the kettle however as a username is not required, and there is no option in hydra to omit the username and just use the password.

However all is not lost. Hydra also supports ‘cisco’. Back in the day, Cisco devices were administered via telnet, however they should all now be using SSH (should).

By default, Cisco devices asked for a password without specifying a username which is exactly in line with the behaviour of the kettle.

We could therefore brute force the kettle using the following syntax:

With the default pin of 000000 being the first entry in 6digits.txt obviously this succeeded on the first try, but we wanted to know how fast we could brute force.

We therefore removed ‘000000’ from the password file, just to get an idea of the throughput possible over the kettle’s wireless network.

Some basic maths indicated that a brute force of the entire wordlist would take around 4 hours, so easily achievable in a working day.

Obviously the amount of time taken to crack a password is going to depend on multiple factors, such as the complexity of the password, the speed of the network, the speed the protocol can parse login requests and whether or not any account locking or delays are introduced on incorrect logins.

Almost all domains we’ve ever tested have account lockout policies in place to prevent this type of attack against user accounts, however embedded devices and other forgotten-about systems may not be as stringent.

It’s always worth breaking out a good old brute force attack on an engagement where applicable, but do make sure you’re not going to lock out anything important.