What does a brute force attack look like?

Ever wondered if your server is being targeted for a brute force attack? What does it look like? How to prevent it?

What is a brute force attack?

A brute force attack is different from other attacks because it’s relying purely on a numbers game to gain access to the system. Unlike social engineering attacks they aren’t targeted at any particular machine or person. They simply scan a network trying common port numbers to see if they are open and then try to access the application using the open port. For example it is well know that SQL server uses 1433 as the default port and there will always be a login called “sa”. Since SQL can be access using the IP too. They already have the server name, port and username all that is missing is the Password. Here they count on the laziness of the DBA/ Developers (who chooses a password that is easy to remember and hence not complex). Then they simple try a random list of common passwords to see which one gets accepted. Another common example is FTP ports and RDP ports

What does a brute force attack look like?

Below is the screenshot from a client’s dev environment hosted on Azure. As you can see the IP addresses mentioned below are trying to login to the machine using common username and passwords. Typically every 2 minutes we can see an attempt being made to gain access.

What can you do to stop it?

Fact is you can’t really stop it. You can make it extremely difficult however. Here are some things you should be doing if you aren’t already

  • Use a very strong passphrase with special characters, numbers the works. As a rule of thumb it cannot be complex enough
  • Ensure your firewall is configured properly and blocking access to traffic outside your network
  • Disable SQL Authentication if you can
  • Rename the sa Account or better yet don’t use it
  • Do not create usernames that are easy to guess
  • Change the default port of SQL Server (most companies forget to do this post install and the application changes later add so much inertia it never gets done later).
  • Create a honeypot environment to identify IPs from which attacks originate and block them proactively
  • Use HTTPS wherever possible
  • Enable auditing to help track who accessed the system and when

Even doing just the first 2 will make a world of difference to your attack surface and save you from the most lazy/ casual of attackers.

Here are some examples from the event log

  • Login failed for user ‘sa’. Reason: An error occurred while evaluating the password. [CLIENT: 112.85.179.26]
  • Login failed. The login is from an untrusted domain and cannot be used with integrated authentication.
  • The login packet used to open the connection is structurally invalid; the connection has been closed. Please contact the vendor of the client library.
  • Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’. Reason: Could not find a login matching the name provided. [CLIENT: 187.143.111.177]

Some common usernames they will use to try and gain entry include sa, ps , su, dbhelp, sysdba, mssqla,admin, etc.

https://www.enabledbusinesssolutions.com/blogs/part-2-securing-azure-database-security-best-practices-call-to-get-your-azure-audited/
How to audit the security features being used in your Azure Account
How to setup a audit in SQL Server