Observing Attacks Against Hundreds of Exposed Services in Public Clouds

This post is also available in: 日本語 (Japanese)

Executive Summary

An insecurely exposed service is one of the most commonly seen misconfigurations in cloud environments. These services are discoverable on the internet and can pose a significant risk to cloud workloads in the same infrastructure. Notorious ransomware groups such as REvil and Mespinoza are known to exploit exposed services to gain initial access to victims' environments. Using a honeypot infrastructure of 320 nodes deployed globally, researchers aim to better understand the attacks against exposed services in public clouds.

Unit 42 researchers deployed multiple instances of remote desktop protocol (RDP), secure shell protocol (SSH), server message block (SMB) and Postgres database in the honeypot infrastructure. Researchers found that 80% of the 320 honeypots were compromised within 24 hours and all of the honeypots were compromised within a week. Some findings that stand out are:

• SSH was the most attacked application. The number of attackers and compromising events was much higher than for the other three applications.
• The most attacked SSH honeypot was compromised 169 times in a single day.
• On average, each SSH honeypot was compromised 26 times daily.
• One threat actor compromised 96% of our 80 Postgres honeypots globally within 30 seconds.
• 85% of the attacker IPs were observed only on a single day. This number indicates that Layer 3 IP-based firewalls are ineffective as attackers rarely reuse the same IPs to launch attacks. A list of malicious IPs created today will likely become outdated tomorrow.

The speed of vulnerability management is usually measured in days or months. The fact that attackers could find and compromise our honeypots in minutes was shocking. This research demonstrates the risk of insecurely exposed services. The outcome reiterates the importance of mitigating and patching security issues quickly. When a misconfigured or vulnerable service is exposed to the internet, it takes attackers just a few minutes to discover and compromise the service. There is no margin of error when it comes to the timing of security fixes.

Prisma Cloud can identify and prevent vulnerabilities and misconfigurations across the entire application lifecycle while prioritizing risk for your cloud native environments. VM-Series firewalls can help detect and defend against malicious activities in virtualized environments.

Methodology

Between July 2021 and August 2021, Unit 42 researchers deployed 320 honeypots across North America (NA), Asia Pacific (APAC) and Europe (EU). The research analyzed the time, frequency and origins of the attacks observed in our honeypot infrastructure.

Four types of applications, SSH, Samba, Postgres and RDP, were evenly deployed across the honeypot infrastructure. We intentionally configured a few accounts with weak credentials such as admin:admin, guest:guest, administrator:password. These accounts grant limited access to the application in a sandboxed environment. A honeypot will be reset and redeployed when a compromising event is detected, i.e., when a threat actor successfully authenticates via one of the credentials and gains access to the application.

To analyze the effectiveness of blocking network scanning traffic, we blocked a list of known scanner IPs on a subset of honeypots. The firewall policies were updated once a day based on the observed network scanning traffic. Depending on the applications and days, each firewall policy might block 600-3,000 known scanner IP addresses.

The logs from all the honeypots were aggregated on an Elasticsearch cluster. A controller server continuously monitored the logs and checked the health of each honeypot. If a compromising event was detected or a virtual machine became unresponsive, the controller redeployed the virtual machine and application. Figure 1 illustrates the architecture of the honeypot infrastructure.

Attack Patterns

Figures 2-5 analyze the timing, frequency and origins of the attacks. We define time-to-first-compromise as the time that an application stays intact until being compromised the first time. Figure 2 shows the mean time-to-first-compromise of all 320 honeypots. Time-to-first-compromise is the time that attackers take to discover and compromise a new service on the internet. It also resembles the time IT administrators have to respond to a security alert on exposed services before being attacked.

Time-to-first-compromise varies with applications. In general, it is inversely proportional to the number of attackers targeting the application (Figure 4). When the number of attackers increases, the time-to-first compromise of this application decreases.

The mean time-between-compromise is the average time between two consecutive compromising events of a targeted application. Figure 3 shows the mean time-between-compromise of each honeypot application during the 30 days.

A vulnerable service on the internet is usually compromised multiple times by multiple different attackers. To compete for the victim’s resources, attackers commonly attempt to remove malware or backdoors left by other cybercriminal groups (e.g., Rocke, TeamTNT). Mean time-between-compromise resembles an attacker’s time on a compromised system before the next attacker shows up. Similar to time-to-first-compromise, the mean time-between-compromise of an application is also inversely proportional to the number of attackers targeting the application.

Figure 4 shows the average number of unique attacker IP addresses observed on each honeypot during the 30 days. The number also indicates the number of times that each honeypot was compromised. Note that this is not the number of attacker IPs observed globally. As most attacker IPs reach only a small subset of our honeypots, the number of globally observed attacker IPs is much higher. In our experiment, only 18% of the attacker IPs reached more than one honeypot.

Figure 5 shows the percentage of attacker IP addresses repeatedly observed on different days. During the 30 days covered in this research, 85% of the attacker IPs were observed only on a single day. The number indicates that the Layer 3 IP-based firewall is ineffective as attackers rarely reuse the same IPs to launch attacks. A list of malicious IPs created today will likely become outdated tomorrow.

Firewall Effectiveness

The network scanning activity project identified over 700,000 scanner IPs daily. We were curious whether proactively blocking the network scanning traffic could prevent attackers from discovering the honeypots and reduce the number of attacks. To test the hypothesis, we created an experimental group of 48 honeypots and applied firewall policies to block IPs from known network scanners. The firewall policy blocks the IPs that have been scanning a specific application daily in the past 30 days. Figure 6 compares the number of attacks observed on each honeypot between the control group (no firewall) and the experimental group (with firewall). We could not see a significant difference between the two groups, meaning blocking known scanner IPs is ineffective in mitigating attacks.

Regional Effects

We are also curious if services deployed in different geolocations are attacked differently. Figure 7 compares the number of attacks observed on each honeypot in different regions. There is no significant difference for the Samba, Postgres and RDP honeypots deployed in different regions. However, we see a very different attack intensity on SSH honeypots in different regions. The number of SSH attacks against APAC-based honeypots is 50% higher than those in NA and 263% higher than those in EU. These numbers are also interestingly correlated to the origins of the attacks, as shown in Figure 8. 50% of the attacker IP addresses originate from APAC, 20% from NA and less than 10% from EU. The result indicates that SSH services deployed in the APAC region are more likely to be attacked than those in other regions.

Conclusion

The problem of insecurely exposed services is not new to public cloud, but the agility of cloud infrastructure management makes the creation and replication of such misconfigurations faster. The research highlights the risk and severity of such misconfigurations. When a vulnerable service is exposed to the internet, opportunistic attackers can find and attack it in just a few minutes. As most of these internet-facing services are connected to some other cloud workloads, any breached service can potentially lead to the compromise of the entire cloud environment.

This type of misconfiguration, however, is not difficult to prevent and remediate with cloud-native approaches. Some strategies that system administrators can take are:

• Create a guardrail to prevent privileged ports from being open. For example, use AWS Service Control Policies or Azure Firewall Management.
• Create audit rules to monitor all the open ports and exposed services. For example, use AWS Config, Checkov, or Cloud Security Posture Management tools
• Create automated response and remediation rules to fix misconfigurations automatically. For example, consider AWS Security Hub or Prisma Cloud Automated Remediation.
• Deploy next-generation firewalls in front of the applications, such as VM-Series or WAF to block malicious traffic.