Tracking brute force Attacks

Tracking brute force attacks on your network can be a very time consuming process. It often ends up with you running around the office trying to track down the culprit, which results in a dead end. Using NetFlow/IPFIX, and our incident response solution, we can make tracking down the bad actors fast and easy. Which, in a situation like this, is something you are going to want.

What is a brute force attack?

A brute force attack is a type of attack that tries to exhaust all possible username/password combinations through a series of successive attempts. In theory this is pretty simple, grab a text file that contains common passwords or perhaps the default passwords setup by some services (e.g. MySQL) and try and authenticate with them. Once the attacker has found out that they “guessed” the password, they can remotely log in to the service and do as they please. In the case of it being a database they may have access to customer log information or even worse credit card/Social security numbers. Once the bad actor has this information they can take it and sell it on underground scamming sites for money.

You may think that you require excessive infosec knowledge to pull off an attack like this and while that may help, there are lots of free tools/utilities out there that you can download legally to test on your own database servers (knowledge is power right?).

What does a brute force attack look like?

Typically a brute force attack will look like an excessive amount of connections to the server/service that is being attacked. In our example of MySQL security you can look at the image to the right, which shows a spike in connections from a host who shouldn’t be accessing this server. It is fairly common to see two spikes in traffic. Usually the first is a port scan to see what ports the server has open, so they can see what exploits they can run. The second spike being the brute force attack or other exploit.

In this case we have setup alerts for this type of behavior. The alerts are looking for a few different things to help eliminate false positives:

• Only alert on IPs outside of our allowed list
  • We expect MySQL traffic from certain hosts and don’t need to be alerted on when traffic between them occurs
• Look for half-opened connections
  • Usually when a network scan is kicked off, it creates half-open TCP handshakes, this way they can tell if the port is open since they will get a response back when they do the scan but reset it before the full handshake is completed (hence the name half-open). If we start seeing many of these, that usually leads us to believe that someone is trying to brute force the password (or has forgot their login)

If a behavior matches the above, there is a good chance we want to know about it. If we drill into the last spike in traffic on our report, we can see that some MySQL connections have taken place; since we only see a few, this probably means that they have successfully broken into our server and have access to our database. Luckily, if you are using our incident response system, you have already been alerted on this and have taken the proper measures on hardening your server.

If you have any questions on how to setup your incident response system to alert on brute force attacks, or any other network threats, please feel free to reach out to us so we can help!