Indicators of RDP Brute Force Attacks

I have been investigating an incident involving two EC2 instances on AWS that were infected with ransomware, cryptocurrency miners, and other types of malware. Sounds scary, right?! Well actually, the approaches that the attackers took to get onto the hosts do not appear to be that sophisticated, and this type of attack could occur in any environment, not just in the cloud. This post presents the suspected way in which the attackers got into the hosts. In later posts, I’ll provide tips to protect yourself from RDP brute force attacks. I’ll also explain what the attackers did on the instances so you can check for infected hosts on your network. In order to initially gain access to the instances, attackers were performing an RDP brute force attack on these cloud-hosted virtual machines. RDP (Remote Desktop Protocol) is the used by Windows machines to allow people to login and view remote desktops. For example, you might log into a Windows server hosted in the cloud, or you might log into your computer at the office from home using RDP. A brute force attack means the attackers simply tried to guess the password for the default Administrator account over and over again. These instances existed in an account used by an individual for testing some third-party software and was not connected to any critical or corporate networks or data. Once the breach was discovered, the network was locked down to prevent these hosts from spreading malware to other hosts on the Internet. The network configuration had the equivalent of no network firewall rules. No MFA was present and likely the passwords were easy to guess. No rate limiting existed on the instance to prevent brute force attacks. No network security appliance, such as a WatchGuard Firebox Cloud, was present to help spot the malware delivered to the instances via network traffic flows. These hosts were easy targets for attackers to try to break into. The first problem I faced when trying to determine what happened was that no logs were present in the AWS account. If you have not done so already, please stop what you are doing right now and go into your AWS account and enable CloudTrail and VPC FlowLogs. Everywhere. There are many more things you should do but this is a start. If you are operating in an on-premise data center, enable network logs and access logs that tell you who accessed what systems over the network and what they did. Make sure your systems use a secure NTP solution so all your time stamps align in any type of logs. I turned on the logs I just mentioned in the account, but I could not rely on them for past data, so next I investigated the Windows EC2 instances (virtual machines on AWS cloud) to see what I could find. Through various means I was able to determine the date and approximate time the incident occurred. Looking at the logs on both the infected instances I could see that most of the logs during that time period were wiped out, but a some indicators of what may have happened remained before and after the time period that was missing. Here’s what I noticed. IP addresses from around the world were attempting to log into the EC2 instances on frequent intervals. You can search for these in your Windows Security Event Log using the event ID 4625. However, it would probably be easier to stop this via the network as I will explain in an upcoming Secplicity post.  

Suppression of RDP event 4625 right after the incident. This indicates that possibly the attacker increased the speed of brute forcing the password after he or she suspected no one was paying attention to the logs. By speeding things up, the attacker was then able to guess the password faster. This is a bit of speculation without having the full logs and knowing exactly what actions the attacker took, but seems like a reasonable guess.  

Domain controller password changed at time of incident. Right after the incident, the domain controller password changed. Additionally, both the instances in this account sharing the same password were infected at about the same time so possibly the attacker brute forced the password on one instance and then tried it on others in the account. If the attacker did not brute force the password and only accessed a vulnerability in some other way then it’s somewhat odd that both instances were infected at almost the same time.  

Windows event logs were deleted. It seems that the attacker was immediately able to perform a lot of actions only an administrator could do right after the attack. Critical logs were deleted up to the time of the events on both machines.   

A successful login with IP address would have been in the RDP logs. Here’s an example of the RdpCoreTS Windows logs with an IP that attempted an RDP login to this instance. Unfortunately, all the logs around the time of the attack were gone.  

Without the missing logs, we can’t know for sure what happened, but based on what happened leading up to and after the incident, we can make some pretty good guesses. This information shows you what a brute force RDP attack looks like in your logs, and hopefully this example illustrates the importance of enabling and securely storing all logs! Check out my upcoming blog posts with more information about how you can protect yourself from RDP brute force and other types of attacks that could have infected these instances. Additionally, find out what the malware looked like so you can spot it if it has infected your Windows hosts. -- Teri Radichel (@teriradichel)