This post will detail what can occur if your network is compromised by a Brute Force attack targeting RDP. It also quickly shows ways of determining if you have been a victim of a Brute Force and recommends some extra steps you can take to prevent being a target of an attack of this type. Screenshots used are from a test environment where I simulated a brute force attack but look identical to what I see in the real world with these attacks.
I have assisted multiple different clients who have had their server’s data files encrypted by file encrypting ransomware. The one question they always ask is, “Why did my antivirus not catch this?” Typically, I will find that the installed antivirus has basically been crippled by disabled settings or by exclusions of the entire system drive. But there is one scenario which stands out. After identifying what antivirus is installed, I will attempt to go open the GUI interface for that AV. This is when I find that the antivirus is not installed. When checking event viewer logs, I can find that the antivirus was uninstalled on the same day which all data files were maliciously encrypted. Further proof that their antivirus was installed at one point can typically be found in %ProgramData%. It’s in this folder where antivirus logs and quarantine are typically stored. This is where we begin to investigate exactly what happened to their server.
Although I have dealt with this scenario multiple times. I am going to list the process I take when a client has had some kind of malicious attack on their server.
- Find out what antivirus they are using.
- Check what the installed antivirus has recently flagged.
If no antivirus is present, verify if it was ever installed by checking:
- Event Viewer (eventvwr.msc) Application log and filter for about 3 days before and after issue occurred and Event Source “MsiInstaller”
- Check %ProgramData% to see if any folders for an antivirus exist
- Check if HKLM\Software, HKLM\Wow6432Node registry keys contain any antivirus registry keys (also check HKCU paths as well)
Perform a quick port scan of the public IP Address of the server using nmap and look for any ports which might not be needed to be opened to the outside world:
- nmap -F <IPAddress>
For the issue of the server having its data files encrypted and files besides those hosted on network shares are encrypted, I always see port 3389 open to the world. Once I see this, I head back to Event Viewer and start filtering the Security log. You will want to filter for the following EVENT IDs
- 4624 (successful logins)
- 4625 (failed logins)
- 4776 (successful credential validation)
It’s also a good idea to filter for the day reported as when the issue occurred or to filter 2 to 3 days before and after the day the issue occurred. Sometimes you might want to start by filtering by just the failed logins, ID 4625. This can easily show you if you had an extreme number of failed logins on a specific date. It’s not uncommon for a brute force attack to last multiple days, all depending on how the attack was planned. Here is an example of a filtered log from a simulated brute force attack:
The key giveaway is that there are multiple failed logins in a very short period of time. In the example, there are tons of failed logins all with the same timestamp. Next, we have a successful Credential Validation. All this tells us is that the brute forcing method was simply trying to validate credentials without fully logging in. Some brute force attacks will not use Credential Validation and simply try to log in repeatedly. Also from the screen shot above, if we could scroll up in the log, you would see that the failed logins stopped. That means either the brute force attack ended and the attack failed, or one of your passwords is now compromised. The simplest way to see if it succeeded or not is to check some of the last few failed logins properties and see which “Account Name” was being used when the attack ended. Once you identify the Account Name, you can then check the successful logins properties to match up the username and then find the successful login with an IP Address.
From the above failed login, you can find the Username which was used and the and the name of the computer which did the attacking. Since I recreated the brute force attack in a test environment, you can see that the name of the computer was “kali” for Kali Linux. In a real-world scenario, this name could be anything. Even something mocking like “pwnage” or something which seems potentially believable to some “cisosecured” or “passwordcheck”. But now that we have the likely used username, we can check the next few successful logins and eventually find the public IP Address which did the attacking. I have changed this IP Address to a fake random IP Address. I have also blurred out any identifiable information about my test environment. I would then next take the IP Address and uses an IP geo-location website to find the relative location of the machine. I then supply this info to the client to investigate if this is one of his User’s IPs or if it is an unknown IP address.
I also discuss with the client the username which was likely brute forced and how the password needs to be changed. I also explain what has happened. The explanation of what occurred to them is as follows:
- An administrative account was brute forced via RDP (aka Terminal Services) and a malicious entity logged in to their server with this administrative account.
- The installed antivirus was uninstalled.
- A malicious file encrypting piece of malware was then used to encrypt all data files on the server and sometimes to encrypt files on any machines located on the network using the C$ of each machine to encrypt.
My recommendations for clients are to force a mandatory password reset to all accounts. Audit and disable any unused accounts (especially administrative accounts). To restore from backups (if these weren’t deleted in the breach) then to put in place a password lockout system and ensure password complexity is enforced. I also recommend to restrict RDP access via IP Address (https://support.managed.com/kb/a2499/restrict-rdp-access-by-ip-address.aspx ) and to change the default port for RDP away from 3389 (https://support.microsoft.com/en-us/help/306759/how-to-change-the-listening-port-for-remote-desktop ). Here are the advantages you get from applying these:
- Password lockout after failed consecutive attempts – This can stop a brute force attack from every getting close to guessing your passwords for accounts. It can even lead to a user contacting you multiple times a day about being locked out, which can be a clue that a brute force attack is occurring.
- Enforcing password complexity – Passwords should be more than 10 characters long and should be made up of uppercase, lowercase, numbers, and symbols. Dictionary words should be avoided. Use phrases instead. Users and Administrators should be forced to change passwords periodically every 60 to 90 days. Doing this can help prevent a password on your network from ever existing in a premade password list which are commonly used in brute force attacks.
- Restricting IP Addresses for RDP – Gives you control of where people can connect from. Yes, you will have to add allowed IP Addresses from time to time, but this is better than finding out all of your data files have been maliciously encrypted and random security software uninstalled.
- Changing the default port for RDP – A lot of scripted attacks blindly search thousands of public IP addresses specifically looking for common ports to attack. Changing away from port 3389 can cause the scripted attacks to not notice you, thus greatly lessening the odds of becoming a victim of a brute force attack.