Detecting Brute Force Attack - Wireshark

 

There are a variety of network attacks that are visible over the network.  From DOS, MiTM, Network Scans, Spoofing and then to what we are discussing today, Brute Force Attacks.

Brute Froce(BF) can also be referred to as a dictionary attack.  How a BF attack works is that a piece of software, perhaps hydra, cycles through a wordlist containing thousands of potential user/passwords.  For each attempt to login a connection is established and authentication is attempted.  If the authentication fails then the software will keep going till it finds the correct combination.

BF attacks are noisy and create a lot of network traffic.  As far as network attacks go they are the equivalent of bashing a baseball bat against a door until the door gives way.  If that were happening at your house, you would likely notice. 

These are my steps to discovering BF attack in your network.

1. "Drive-By"

I always start here.  I have never heard anyone else do it.  But it is so useful because there are patterns of colours that give us a clue as to what is happening.  Picture 1 is of the scroll bar.  Picture two is of SYN and RST packets which is a clear sign of a scan occurring.  We know a scan is occurring because SYN packets are being sent to the same destination machine, the destination port is changing and the source port is staying the same.

 2. Identify Attacker

Now there are a few ways to do this.

For us, we have already identified the scanning machine.  Naturally we should put a big red flag on this machine.

Another technique is to check the statistics>endpoints and see who is making the most noise. 192.168.0.10 is our attacking machine

Without even applying any filters we have also identified our target.  Looking at the scan traffic we can see that 192.168.0.10 is conducting a port scan of machine 37.59.174.225

3. Isolate Communication

My capture has a total of 174,985 packets.  That is a lot.

I only want to see traffic from attacker > target

so I apply this filter

ip.src==192.168.0.10 and ip.dst==37.59.174.225

This shrinks the list windows down to 52% displayed.  We have cropped out 48% of traffic we don't need to look at. Awesome!

4. Observe Behaviour

Of these packets the first 10 are ICMP requests.  Basically the attacker saying "Hey you there?"  After this the attacker starts bumping around on the web server that is hosted.  Nothing really weird about the web traffic. At packet 1010 the scan begins.

We see further evidence of a scan occurring.  packets 1071-1076 are showing SYN packets being sent to port 3389 (RDP) and 8080 (proxy)? 

5. Finding the Connecting Port

We know when the scan starts, but there are over 93000 packets to search through.  If we can find the connecting port from attacker>target we can narrow down the search further.

ip.src==37.59.174.225 and ip.dst==192.168.0.10 and tcp.flags=0x12

Using this filter will show us packets where the target responded to the attacker with a SYN-ACK which is a sign that a connection was potentially established.

Our results are very helpful because we can see that the target responded to the attacker with a SYN-ACK on port 80 (we knew this already) port 53 (TCP), port 22 (SSH) and another port 2XXXX(random TCP port and very high)  There were a bunch of SYN-ACKs from 2XXXX.

We need to dig into this high level port.

6. Nitty Gritty on Specific Port

We know our suspect port. so we change our filter to show us the details on this port as it relates to attacker and target

ip.addr==192.168.0.10 and ip.dst==37.59.174.225 and tcp.port==2XXXX

[port # witheld]

Things look a bit different now.

We can actually see ACK traffic and PSH-ACK traffic between attacker>target.  Which means that data was transferred. When we "follow the TCP stream" of the ACK packets we are presented with a client-server conversation showing us a whole TON of failed user and password attempts.

The passwords smell like a "rockyou" wordlist

Learnings

Well the admin here put their FTP port up really really high.  There was an attempt at security through obfuscation.  However with a scan that iterates through all ports it is only a matter of time until the port would be found.  

A FTP connection cap would be critical here.  Meaning after 3 failed attempts the attacker would be locked out.  Better yet added to a list, or IDS would pick up this strange behaviour and alert the admin.