![]() By speeding things up, the attacker was then able to guess the password faster. 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. Suppression of RDP event 4625 right after the incident. However, it would probably be easier to stop this via the network as I will explain in an upcoming Secplicity post. You can search for these in your Windows Security Event Log using the event ID 4625. IP addresses from around the world were attempting to log into the EC2 instances on frequent intervals. 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. Through various means I was able to determine the date and approximate time the incident occurred. 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. Make sure your systems use a secure NTP solution so all your time stamps align in any type of logs. 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. There are many more things you should do but this is a start. 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. The first problem I faced when trying to determine what happened was that no logs were present in the AWS account. These hosts were easy targets for attackers to try to break into. 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. No rate limiting existed on the instance to prevent brute force attacks. No MFA was present and likely the passwords were easy to guess. The network configuration had the equivalent of no network firewall rules. Once the breach was discovered, the network was locked down to prevent these hosts from spreading malware to other hosts on the Internet. 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. A brute force attack means the attackers simply tried to guess the password for the default Administrator account over and over again. 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. RDP (Remote Desktop Protocol) is the used by Windows machines to allow people to login and view remote desktops. In order to initially gain access to the instances, attackers were performing an RDP brute force attack on these cloud-hosted virtual machines. I’ll also explain what the attackers did on the instances so you can check for infected hosts on your network. In later posts, I’ll provide tips to protect yourself from RDP brute force attacks. This post presents the suspected way in which the attackers got into the hosts. 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. I have been investigating an incident involving two EC2 instances on AWS that were infected with ransomware, cryptocurrency miners, and other types of malware.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |