Magnets to Adversaries—An Analysis of the Attacks on Public Cloud Servers

Abstract

Security adversaries are always constantly looking for targets to exploit. The mechanism of exploitation used by security adversaries varies significantly. Many focus on easy compromises as mere pivots to extend their attacks from these exploited systems to continue accomplishing their original goals. The cloud environment is a highly susceptible target for adversaries and provides a solid mechanism for observing adversary behavior. The sheer volume of attacks on the cloud provides insights into the attacker’s objectives and attack patterns, which can be leveraged for protecting infrastructure. This work deep dives into the practices used by adversaries on the commonly exposed protocols in the Amazon Web Services (AWS), Microsoft Azure (Azure), Google Cloud Platform (GCP), and Oracle Cloud Infrastructure (OCI) platforms. A robust honeypot model is documented that compares attacker behavior across various ports and protocols running in multiple cloud environments. This work illustrates that adversary activity is highly versatile in the public cloud environment, with an average of 700 new and unique IP addresses found attacking honeypot infrastructure daily. Further, this article illustrates the security safeguards a typical organization can leverage to mitigate the threats from these adversaries constantly probing insecure targets on the cloud platform.

1. Introduction

The cloud service market is intensely competitive, with top providers offering discounts, economies of scale benefits, promises towards security, and low costs to lure customers. As a result, many organizations have found the cloud very attractive for IT implementations and have successfully migrated their data center workloads. Based on the research performed by organizations such as Gartner and Grand View Research, the cloud computing market is expected to grow at a staggering 18.1% over the next eight years [1]. In addition, the revenues for Infrastructure-as-a-Service (IaaS) categories have risen by the same amount across the major cloud service providers over the past three years. The critical aspect driving cloud adoption is the economies of scale derived from managing and securing the cloud platform.

Depending on the type of cloud workload used, namely Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), or Software-as-a-Service (SaaS), the security responsibility of the customer and cloud varies significantly [2]. Specifically, as the cloud workload changes from IaaS to PaaS to SaaS, the security responsibility of the cloud service provider increases while the security responsibility of the organization decreases. This model is good in theory; however, this notion comes up with the following practical challenges:

• First, the companies leveraging the cloud do not have the same security expertise as the cloud service provider to protect the IaaS, PaaS, and SaaS components. Frequent and independent third-party audits vet the cloud service provider’s security controls, making its security responsibility trustworthy, which is not affordable to many companies leveraging the cloud. The security gap between both implies that the IaaS components implemented by an average cloud customer are less secure than the IaaS components implemented by the cloud service provider;
• Second, there is always a risk of cloud customers assuming a false sense of security regarding their workloads on the cloud platform, believing that their servers are automatically protected by the security controls and the compliance obligations of the cloud provider;
• Third, the security of data center applications significantly differs from how cloud workloads need to be secured. Most organizations move their workloads to the cloud as a cost-saving tactic. As a result, there is a risk that cloud customers may oversimplify the security of these applications moving to the cloud and assume that the same strategies that had previously worked in the data center would continue to be effective in the cloud platform as well. However, such an assumption is far from the truth;
• The fourth and most impactful is the agility of the cloud platform. In a typical enterprise network with DMZ and perimeter firewalls, opening a port to the internet is an arduous process that requires multiple signoffs and implementations from various departments within an organization. In a typical cloud platform, this process would take seconds by a single person. A small oversight in the cloud configuration could expose ports in an IaaS virtual machine or even allow data to be readable by anyone on the internet. The chance of security mistakes is thus significantly higher in the cloud, especially for those organizations that treat the cloud as an extension of the data center security model.

Data breach incidents in the cloud frequently occur, and cloud misconfigurations are one of the leading causes of the breaches [3]. Based on the research performed by Rapid7 in 2021, there were, on average, 10 misconfiguration-related high-profile breaches identified for each month in the year 2020. Further, in the same research, it was identified that most of these misconfigurations are caused by deliberate choices to make it easier to access a given resource or a lack of understanding of cloud security principles. The research performed by Thales Group also associates human error as the leading cause of cloud data breaches [4]. In the research performed by the group across 2889 respondents in the months of November and December 2022, 55% of the breaches identified attributed to human error as the cause for the cloud breaches. About 39% of the respondents surveyed in the same study have experienced a data breach in the past year, which is up four percentage points from the year before.

1.1. Hypothesis Statement

The fundamental hypothesis of this article is that the majority of cloud breaches stem from intentional human errors driven by factors such as the false assumption that cloud environments are inherently secure, leading to complacency or intentional misconfigurations to remove hindrances to developer productivity. It is this single trait in the cloud platform that attracts adversaries from the internet.

To put this hypothesis through a preliminary test, we investigated the number of open SSH ports in each cloud provider on 24 October 2023. Each of the four major cloud providers, namely, Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), and Oracle Cloud Infrastructure (OCI), have independently published security guides to prevent exposure to one of the most common vulnerable ports, i.e., port 22 (SSH), to protect the compute instances against malicious attacks [5,6,7,8]. If the security guidelines for the respective cloud providers have been followed, the number of open SSH port (port 22) instances in each cloud service provider would be minimal.

Table 1. Shodan preliminary research—the number of SSH server endpoints exposed in the cloud.

#	Cloud Platform	Estimated SSH Endpoints Exposed
1	Amazon Web Services (AWS)	2.7 million
2	Microsoft Azure	350 thousand
3	Google Cloud Platform (GCP)	1.6 million
4	Oracle Cloud Infrastructure (OCI)	413 thousand

highlights the number of wide-open SSH hosts on each cloud platform based on the analysis performed on Shodan (https://www.shodan.io) on 24 October 2023. Based on the analysis, it can be ascertained that millions of compute instances across all the cloud platforms expose SSH service through port 22, contrary to the security guidelines published within each cloud service provider. These endpoints demonstrate the ease and prevalence of human-induced configuration errors exposing the attack surface on the cloud.

1.2. Research Objectives

The bottom line is that due to the varying list of factors, cloud customers sometimes fail to keep the security of their workloads in line with the best practices expected from such a system. Thus, adversaries constantly scan the cloud infrastructure for vulnerabilities to identify the intrusion points. This work focuses on identifying the attack patterns of adversaries on the cloud by launching inherently insecure virtual machines within the Amazon Web Services (AWS), Microsoft Azure (Azure), Google Cloud Platform (GCP), and Oracle Cloud Infrastructure (OCI) cloud service providers. In essence, the present study focuses on three key objectives:

• Architect a robust honeypot model that efficiently captures characteristics of a typical adversary attacking the cloud infrastructure;
• Derive the adversary characteristics by utilizing the honeypot model on multiple cloud service providers;
• Establish a risk-based control framework based on the identified findings that organizations can use to mitigate the underlying risk from these adversaries.

This paper presents a novel approach to cloud security by focusing on practical, real-world assessments of adversary behavior across multiple cloud platforms. This unique perspective fills a critical gap in the existing literature, which often focuses on theoretical or technical aspects of cloud security. For a more detailed discussion of the novelty of our research, please refer to Section 2.1 of the manuscript.

2. Related Work

Considerable security research has already been performed looking into securing the application or infrastructure against vulnerabilities. Most of these studies portray how organizations must organize their infrastructure to prevent attacks from malicious adversaries. However, very little research has been conducted to understand the adversary mindset and then design the security controls to mitigate the specific adversary intents.

Research from Ketabdar et al. emphasizes understanding the attackers’ behavioral parameters [9]. The results from the behavioral analysis pave the way for performing network security research analysis. The attackers’ underlying motive directly influences the attack path of the adversaries. Therefore, understanding the attacker’s motivation is crucial in predicting the attacker’s behavior and enforcing the organization’s defenses. This research identified four groups of attackers:

• Attackers with the intention of damaging the network;
• Attackers with restricted available resources and time;
• Attackers whose goal is to discover useful information;
• Attackers with no well-known support.

Depending on the characteristics of the attackers, the attack paths in the Bayesian attack graph would be different. If the underlying motivations are understood well, a specific attack path or attack category can be reasonably blocked, preventing these adversaries from accomplishing their goals.

Research from Devi et al. identifies possible security attacks on cloud computing, such as wrapping, data stealing, malware injection, virtualization, and flooding [10]. The paper illustrates a high-level architecture for a honeypot design in the cloud. When an attack is detected, the adversary traffic can be redirected to the honeypot to identify the type and extent of the damage the adversary can perform. This paper also defines a rudimentary methodology to deploy a honeypot in the cloud. Honeypots shape the way for better cloud defenses, given the scale and speed at which these can be deployed on the cloud platform.

Research from Katkam underscores the importance of honeypots with intentional vulnerabilities to lure attackers to a given infrastructure [11]. The paper explores the mechanism of using a honeypot to capture intruder attack patterns and techniques and leverage the same to prevent attacks from happening in the first place.

Research from Majumdar et al. emphasizes the difficulty of collecting runtime events in the cloud [12]. The data within the cloud is collected over various formats across multiple log locations. Since many events happen in the cloud simultaneously, it would be challenging to ascertain the exact user-level activities unless the events from various systems are correlated. The paper proposes a unique approach to performing runtime event auditing within the cloud, which must contain three essential components—Data Collection and Processing Module, Compliance Verification Module, and Dashboard and Reporting Module. Once these modules are in place, multiple engines would be able to process and analyze the data to perform the security auditing at scale. This paper provides a mechanism to deploy the logging across various honeypots for the current research study.

Research from Negi et al. identifies mechanisms to divert malicious traffic away from the cloud systems using a honeypot [13]. The security benefit that honeypots provide is that they enable a clear view of and track attacker behavior on compromised systems. Hence, each honeypot configured on the cloud must be unique and attenuate the existing environmental settings. In addition, the honeypot characteristics determine the depth of the data collected to analyze the attacks. Moreover, the research discusses the effectiveness of using the data from the honeypot to enable a clear view of adversary characteristics and uses this data to secure the cloud.

Research from Lihet and Dadarlat provides a high-level guide to building honeypots in the cloud using the Kippo application suite [14]. The study illustrates the capabilities of low-interaction, medium-interaction, and high-interaction honeypots. Each of the three categories differs based on the adversary interaction capabilities they allow and the required hardware setup to allow for such interactions. For example, Kippo software is a medium-interaction honeypot that only allows a high-level analysis. However, a high-interaction honeypot provides a complete environment for the attackers to attack any internal component. The research from this paper establishes the foundation of the honeypot framework used for the current study.

Further research from Lihet and Dadarlat provides more insights into the Kippo honeypot [15]. Deploying the honeypot for five years, the authors observed the activities of various intruders in the cloud. The authors, for instance, describe a scenario where an adversary tried to attack the honeypot and, for six hours, failed to realize that no commands would work on the server. More promising research is possible in this area, especially to contrast the attacker’s behavior across multiple environments and understand their motivations for attacking insecurely configured virtual machines on the cloud.

Research from Barth et al. contrasts reactive security with proactive defenses [16]. Proactive security is the security paradigm where organizations pre-emptively deploy the defenses by analyzing the threat vectors of the target architecture even before the attacks happen. Organizations mostly prefer proactive security compared to reactive security. However, the key learnings from an attack come from the reactive side of things. The research focuses on the defender strategy implemented within an organization and evaluates the attacker’s cumulative return on investment/attack.

Research from Priya and Chakkaravarthy illustrates the importance of using containers for honeypot deployments [17]. The containerized honeypot deployments are portable, durable, and simple to deploy and administer. Containerization bundles the honeypot program and prerequisites into a single package. Containers offer a lightweight solution to expose vulnerable services, leading to more flexible and extensible honeypot systems, allowing researchers to scale based on the attack patterns identified.

2.1. Novelty of Current Research

This article presents a novel approach to cloud security by comparing and contrasting attacks across multiple cloud platforms. This approach allows us to delve into the intricate mechanics of adversary behavior in the cloud environment and identify the subtle nuances and distinctions in the strategies, tactics, and motivations of attackers on various prominent cloud service providers. By providing a cross-platform analysis of adversarial behavior, this research offers a fresh and invaluable perspective on the security landscape of the cloud, shedding light on the extent to which attackers adapt their methods based on the distinct characteristics of each platform.

In addition to the comparative analysis of attacks across multiple cloud platforms, the research highlights the critical issue of human-induced configuration errors on cloud platforms and their costly implications. Misconfigurations stemming from factors like complacency, mistrust, and lack of expertise provide adversaries with opportunities to exploit vulnerabilities within cloud customer environments. This aspect of the research uncovers the relationship between the cloud’s inherent flexibility and the increased susceptibility to human errors. This connection has often been overlooked during enterprise cloud migrations, leading to a significant number of cloud security breaches each year.

By providing empirical evidence and real-world examples of how adversaries leverage these human-induced vulnerabilities to breach cloud customer systems, the research adds a layer of practical understanding crucial for organizations seeking to fortify their cloud security strategies. The research’s approach combines the comparative analysis of observed and real-world adversarial behavior on human-induced security vulnerabilities, culminating in a significant contribution to the cloud security landscape. Ultimately, this research equips organizations with a holistic understanding of the complex and evolving threats they face in the cloud environment.

3. Materials and Methods

The current research focuses on determining the susceptibility of a given architecture deployed across various cloud platforms to adversaries worldwide. This work attempts to define a model that deploys honeypots across the public cloud platforms, enabling anyone from the internet to connect to them and abuse the underlying services. The following are the main goals identified for such a honeypot design:

• Multiple Protocols: A honeypot deployed on a single port fails to study and contrast the adversary behavior across different protocols and their corresponding mechanisms of attack. The current study implements a honeypot design that allows adversary interaction on five protocols: SSH, FTP, Telnet, HTTP, and SMB (see

  Table 2. Illustrated ports exposed and versions.

  #	Port	Honeypot Type	Service	Open-Source Honeypot	Honeypot Configuration
  1	21/ftp	High-interaction	Linux FTPd	Meltingpot 1	Accepts anonymous FTP access. Provides the FTP prompt and listens to the user’s actions. Provides attacker access to certificate files, GitHub configuration scripts, and initialization data.
  2	22/ssh	High-interaction	OpenSSH 7.9p1	Wetland SSH 2	Since it is a high-interaction honeypot, accepting the password on the first malicious attempt raises suspicion of an adversary. Hence, the honeypot is configured to accept any password only after a random two or three wrong password retries. Offers full SSH shell within a Docker container with scripting capabilities. The user’s commands are logged outside the container in real time.
  3	23/telnet	Medium-interaction	Linux Telnetd	Cowrie 3	Mimics SSH honeypot; however, the random tries are increased to six to eight attempts. The honeypot is based on Cowrie, a medium-interaction honeypot with a fake filesystem.
  4	80/http 8080/http 8983/http 9200/http	Medium-interaction	Elastic Search	Log4pot 4	Hosts a website that mimics Elastic Search, which was vulnerable to Log4j vulnerability [20]. The honeypot listens to the requests coming to the HTTP service and identifies and logs the attacks specifically targeting the Log4j vulnerability.
  5	445/smb	High-interaction	Microsoft Windows SP2 SMB	Dionaea 5	Emulates Windows XP-hosted SMB service. Provides access to an empty directory. The honeypot logs any SMB packet sent to it and identifies different types of SMB attack payloads.
  6	55293/ssh	NA	NA	NA	Management port for honeypot server maintenance. This port also serves as the control port to contrast the traffic between known ports of a protocol and an obscure/hidden port.

  ¹ Source code for Meltingpot honeypot is located at https://github.com/cryptax/meltingpot (accessed on 24 October 2023). ² Source code for Wetland SSH is located at https://github.com/ohmyadd/wetland (accessed on 24 October 2023). ³ Source code for Cowrie is located at https://github.com/cowrie/cowrie (accessed on 24 October 2023). ⁴ Source code for Log4pot is located at https://github.com/thomaspatzke/Log4Pot (accessed on 24 October 2023). ⁵ Source code for Dionaea is located at https://github.com/DinoTools/dionaea (accessed on 24 October 2023).

  );
• Extensions to Opensource Honeypots: The starting point for each honeypot implemented is an open-source repository. However, honeypots are fragile services. Therefore, extensions were implemented to the available source code to increase the redundancy and improve the availability of the honeypots. The changes to the existing code focused on three main areas: (1) enabling auto-repair in the event of failures, (2) enabling consistent logging across honeypots for ease of contrasting attack data, and (3) enabling code optimizations to prevent resource leakages;
• Multicloud Contrasting: This work focuses on contrasting adversary activity between four top cloud providers in the US, namely Amazon Web Services (AWS), Microsoft Azure (Azure), Google Cloud Platform (GCP), and Oracle Cloud Infrastructure (OCI). The contrast between the four top cloud providers would be possible if the same honeypot infrastructure is deployed across the platforms. Based on the magic quadrant from Gartner from July 2021, three of the cloud platforms selected for this study are established leaders, while OCI is a niche player in the cloud market [18];
• Unrestricted Implementation: Only medium- and high-interaction honeypots are selected for current research. The honeypots and their underlying configuration allow the adversaries to log in using any username and password and exploit the system in any manner they can;
• Redundant Logging: Honeypots are configured to comprehensively log all the attacks from various adversaries, including the client information and metadata. The logging infrastructure is set up in a redundant environment, and logs are collected in real time. In addition, there are several anti-honeypot tools available on the internet [19]. Hence, even if the honeypot servers are compromised, the currently configured design does not allow any availability and integrity impacts on the previously collected logs;
• Extended Execution: All the honeypots across cloud platforms are configured to have high availability and run for the same amount of time between 4 February 2022 and 15 April 2022. A redundant design with automated failovers is configured to ensure all the honeypots’ availability is more than 99.5% across all the cloud platforms over the time duration above;
• Hiding from Adversaries: The public IP addresses of the honeypots were selected from a random pool of IP addresses from the cloud platform. Custom scripting was in place for automated rotation of the public IP every day for the honeypots deployed on the AWS cloud and an ad hoc basis for other cloud platforms. No efforts were made to disclose the IP addresses and the vulnerable services to the adversaries.

The subsections below articulate how these goals have been accomplished in designing the honeypots.

3.1. Cloud Architecture

Figure 1 depicts the high-level architecture of the proposed honeypot that aligns with the design objectives above. The honeypot framework is designed to capture the attacks in real-time from the top four cloud service providers (AWS, Azure, GCP, and OCI). Each cloud service provider hosts a combination of a virtual machine and a network firewall. The firewall configuration allowed all internet traffic on ports 21/ftp, 22/ssh, 23/telnet, 80/http, 8080/http, 8983/http, 9200/http, 445/smb, and 55293/ssh. The underlying operating system used to configure the honeypot is Ubuntu 20.04 (Focal Fossa) LTS.

Elastic Cloud is configured as the primary log platform. In real-time, the logs in JSON format from multiple honeypots across cloud platforms directly write the adversary activity to the Elastic Search. AWS service S3 is configured as a redundant log repository that allows honeypots from across the cloud platforms to send their logs from multiple log sources along with the Elastic Cloud. A custom script is written to ensure that Elastic Cloud logs correlate with the AWS S3 bucket. Having multiple redundant logging platforms ensures that no records from honeypots are lost due to the lack of availability of different cloud platforms.

3.2. Virtual Machine Setup

The list of ports and protocols that have been configured is represented in Table 2. Each underlying honeypot has been deployed as an individual Docker container ecosystem. The vulnerable services configured as honeypots run within a pool of docker containers and wait for the adversary traffic. Each container in the docker deployment allows an adversary to have an independent execution environment for the attack packets sent.

In addition, each virtual machine is configured to use Elastic Cloud and AWS credentials of an IAM user to facilitate the data transfer to the Elastic Cloud and S3 bucket, respectively. Finally, the logs from each port are collected centrally within the host and are shipped off in real-time to the Elastic Cloud and Amazon S3 bucket using a Fluentd agent.

3.3. Availability and Monitoring Setup

The elaborate availability measures for honeypots across cloud platforms were baked into the honeypot design with the following:

• Each honeypot implementation was set up as a separate docker-compose file. Each docker infrastructure supporting a honeypot over a given port was independent of other containers running on the host;
• Upper limits on maximum CPU and memory are defined for each Docker container executing within the virtual machine;
• The docker-compose file automatically triggers new instances of the honeypot containers in case of any error/failure of the underlying code. Further, each adversary attack consumes a unique container instance among the managed pool created by the docker-compose architecture;
• The custom code and docker architecture refresh each honeypot container within the pool at least once an hour at a random time when the external connections to the container do not exist.

End-to-end monitoring was set up as part of the project to ensure consistent availability of the honeypot infrastructure across the cloud platforms and calculate availability metrics. The monitoring was architected as an external solution connecting each honeypot across cloud platforms and validating their availability. The availability of each honeypot between 4 February and 15 April 2022 was observed to be more than 99.7%.

4. Results

Architected honeypots were left open for the attacks for seventy days, continuously collecting data from various sources. Apart from routine maintenance of log rotation and service uptime monitoring, no other changes were made to the honeypot platform or the services.

4.1. Adversary Attack Metrics

Figure 2 represents the distribution of attacks and originating unique IP addresses across 24 h. The graph shows that the attack spread of the connections from various adversary IP addresses is statistically distributed over the day across all the cloud platforms. Figure 3 depicts the total cumulative activity from adversaries across 24 h. The disparity of the attacks between cloud platforms can be derived by contrasting these two graphs. Based on the collected data, the Azure, Amazon, and GCP platforms appear to be heavily targeted, whereas the OCI cloud is the least targeted. Therefore, it is possible to infer that the adversarial incidence is higher on the cloud platforms that are established leaders as per the Gartner magic quadrant [18]. This higher incidence is because more customers and large organizations deploy their infrastructure on the leading cloud platforms than the niche players. Therefore, the adversaries can obtain higher Return on Attack (ROA) metrics by attacking the established cloud platforms.

Looking closer into the metrics on individual honeypots, Figure 4 illustrates the average number of unique adversary IP addresses observed each day across all the honeypots deployed. The highest concentration for unique IP addresses is on the ports that provide shell access to the adversary, namely port 22/ssh, which recorded average attacks from 244 new and unique IP addresses each day, and port 23/telnet, which recorded average attacks from 184 new and unique IP addresses during the same period. Port 445/smb does not offer direct shell access to the adversary. Instead, the vulnerabilities within the SMB protocol enable the remote shell capabilities. The SMB port recorded an average of around 135 new and unique IP addresses each day. The ports related to 80, 8080, 8983, and 9200/http provide Log4j vulnerability-based information disclosure. The honeypot related to 21/ftp does not offer any remote code execution capabilities and does not expose a known vulnerable version of the service. Hence, both ports have shown lower adversary interest than those that provide direct remote code execution.

4.2. Adversary Profiling

Around 32% of the traffic to honeypots is identified to have come from known IP masking services, such as VPN, Proxy, and Tor. The distribution of the IP address space across the cloud platforms is depicted in Figure 5. There is less proliferation of Tor and Proxy endpoints than VPN observed within the data because these masking services typically support only HTTP-based traffic, with lower adversary interest than other ports. Analysis of the top Autonomous System Numbers (ASNs) for the adversary IP addresses identified across the cloud platforms has yielded that the top seven out of ten ASNs used by adversaries are cloud providers. Therefore, it can be inferred that adversaries typically use cloud platforms and VPNs to mask their attacks while probing for security misconfigurations in the cloud. Further, no difference was observed in the traffic patterns when the public IP addresses of the virtual machines running honeypots changed over the course of this study across the cloud platforms.

Figure 6, Figure 7, Figure 8 and Figure 9 represent the total geographic distribution of the adversaries across the cloud platform. Even though the unique number of IP addresses and the persistence of the adversaries from a single IP address are different across the cloud platforms, the high-level geographic distribution remains the same. The attackers appear to be spread globally without any specific region showing a higher concentration of the IP addresses for a given cloud platform.

4.3. Common Adversary Strategies

The analysis of the adversary attacks on SSH port and telnet port depict brute force of authentication credentials as the primary mechanism for intrusion. The honeypot was designed to grant access to any adversary randomly after 1 to 3 wrong attempts for a password; therefore, it is impossible to determine a complete wordlist used for brute force. Based on the inspection of the credentials used, it can be inferred that most adversaries have started the password brute force using the same passwords as the starting point to attack. These passwords are already part of common password lists such as rockyou.txt [21]. The most common passwords observed across the cloud platforms are represented in Figure 10.

The adversaries opened 11,193 unique SSH sessions over seventy days. Each SSH session would span multiple activities from the adversaries looking to exploit the remote shell connection. A total of 411,172 individual activities were identified in the SSH honeypot. The most prevalent of these activities are represented in Figure 11a. Upon inspection of these activities, it can be inferred that downloading malicious packages from external sources (42,227 activities) and transferring files (40,516 activities) through various protocols is the most prevalent strategy of the adversaries. The external binaries, in this case, appear to deploy malicious botnet binaries into the compromised host that attempt to compromise other cloud infrastructure. Further, various adversaries also attempted to establish persistence by tampering with user profiles, modifying SSH keys (17,326 activities), mining cryptocurrency (3107 activities) within the virtual machine, and querying for GPU capabilities. It is interesting to note that port 55293, also running SSH service for management of the honeypot server, did not record a single malicious activity over seventy days across the cloud platforms.

An analysis of Telnet sessions revealed something similar to the observations for SSH connections. A total of 13,164 successful telnet sessions were identified. However, the telnet honeypot was an interaction honeypot that did not give an adversary mechanism to run any arbitrary command in the remote shell. The adversary activities within the remote telnet shell were sparse compared to SSH, with only 172,075 activities recorded. The most prevalent of these activities are represented in Figure 11b. However, similar to SSH, the focus of the attacks in the current use case was to download malicious packages from external sources to deploy botnet software into the compromised host.

The analysis further revealed that the SMB port had been the highest targeted port compared to other honeypot ports exposed in the virtual machine. Figure 12 shows the total number of active SMB connections made across various cloud platforms from a unique IP address. Correlating this analysis with the research from Gartner [18], it can be inferred that the leaders of cloud platforms (AWS, Azure, and GCP) have more active SMB protocol probing than the niche player, the OCI platform. Further, the activity for the SMB port for the OCI cloud platform accounted for only 2% of the total SMB port activity.

A total of 8,140,821 records of SMB activity have been recorded across all the cloud platforms, making it the most sought-after port by all IP addresses. One explanation for this extensive exploration is that the Dionaea honeypot design indicates through versioning that the underlying Operating System is Windows XP and supports the payloads for exploitation. However, these exploits fail in the honeypot. The noncommittal response from the Dionaea honeypot has resulted in several adversaries trying to attack the port using various exploit strings.

DoublePulsar is a backdoor implant used to inject and run malicious code on a vulnerable Windows system [22]. The DoublePulsar was used alongside EternalBlue and Wannacry ransomware exploits that infected exposed SMB ports worldwide. A total of 2,533,498 DoublePulsar messages have been recorded by the SMB honeypot across all the cloud platforms, and at least 191,475 SMB messages contained previously unidentified shellcodes.

A total of 74,587 individual HTTP requests were observed across all the cloud platforms. Out of the total requests, only 1645 (around 2%) requests contained a payload to perform Java Naming and Directory Interface (JNDI) data exfiltration. All the patterns for JNDI attempt to access a remote domain or URL to download a malicious executable and trigger it. The reason for lesser adversary interest in the HTTP honeypot compared to other honeypots is that the Log4j vulnerability only impacts a minor subsection of HTTP endpoints using the Log4j framework for logging. Also, the RCE from a Log4j exposure is not straightforward and might be constrained by the medium interaction honeypot preventing outbound internet connections [20].

The FTP honeypot received 17,385 attempts from adversaries across the cloud platform, out of which 482 were malicious downloads from the FTP directory shared. Most of the connections to the FTP service were anonymous; however, analysis reveals that adversaries used around 2089 passwords for authentication across all the cloud platforms. Apart from routine service probing, this study did not observe any malicious payloads in the FTP honeypot.

5. Discussion

5.1. Overall Summary

The following observations summarize the findings identified by analyzing the honeypot attacks from the adversaries:

• Cloud service providers are a magnet for adversaries looking for low-hanging fruits. Adversaries are always on a constant lookout for cloud IP addresses through password-based attacks and attacks that would result in a remote shell;
• Configuration mistakes in cloud platforms are often easy to make due to the complexity of cloud services, the evolving nature of technology, and the potential for human error;
• The focus of the attacks is to minimize the efforts to obtain a remote shell, given the port and protocol;
• Once the shell access is obtained, the adversaries’ next step is to either deploy a botnet through the shell that attacks other cloud components or perform cryptocurrency mining;
• Adversaries come from different countries and geographies. They use cloud platforms and other IP masking techniques to hide their activity while attacking cloud infrastructure;
• The adversaries are attracted to the underlying issues of the infrastructure in the cloud. Improper security configuration, lack of authentication security, and poor vulnerability management yield the best results for the adversaries exploiting cloud platforms;
• If a virtual machine exposes the common port on the cloud platform, it is attacked within minutes and several times a day. From an adversary perspective, out of millions of attacks happening across virtual machines hosted in the cloud, a successful response from a single virtual machine expands the adversary attack network.

5.2. Overall Security Control Structure for Mitigation

This work shows that adversaries are constantly looking for effortlessly exploitable vulnerabilities in the cloud. Hence, to thwart the attackers’ attempts, organizations must implement security discipline through rigorous security controls.

Table 3. Illustrated security controls to thwart ongoing attacks in the cloud.

Control Domain	Sample Security Controls
Network Security	NS-1: The attack surface of the infrastructure in the cloud must be kept to a minimum. Every port and protocol open to the internet must have a valid business justification for such exposure.
	NS-2: The management services such as SSH and Telnet services must not be exposed to the internet. If these services are required to be exposed, they must use non-standard ports that are randomly determined.
Access Control	AC-1: The access must be restricted using multifactor authentication instead of a single-factor mechanism. Service-based access to cloud services must occur over mutual TLS authentication.
	AC-2: The services exposed to the internet must authorize all the entities and validate for access privileges before allowing remote access.
	AC-3: The passwords within services implemented in the cloud must adhere to the most stringent password complexity settings. At a minimum, the password must require a length of 12 characters, with a combination of uppercase, lowercase, digits, and symbols.
	AC-4: Weak passwords identified in the vulnerable password lists must not be accepted as passwords for any system deployed on the cloud.
Logging and Monitoring	LM-1: Each service exposed to the internet must log events related to all the successful and failed login attempts. Thresholds must be established on maximum failed login attempts. The attempts exceeding the threshold count must temporarily lock out the underlying user.
	LM-2: Protocol errors related to the service must be logged and monitored to identify any signs of compromise. Such alerts must be treated as security incidents and promptly remediated by patching the service or restricting access.
Vulnerability Management	VM-1: The IaaS services on the cloud must be patched regularly. Critical security patches that result in remote code execution must be implemented within 24 h of their release.
	VM-2: The vulnerability scans must be performed daily to identify any system with pending critical security patches. The findings from such a scan must be treated as an incident and resolved quickly.

identifies the list of security controls that would help protect organizations against attacks on the cloud. Each security control specified in the table defends the underlying service against a specific attacker behavior. These controls and requirements are not new. Each major cloud service provider has re-iterated these in their documentation, advising customers to adopt security best practices [23,24,25,26]. However, human-induced misconfigurations against these best practices have resulted in systemic exposures being exploited in general. Therefore, implementing all the security controls adds the necessary defense-in-depth protection against attackers. As part of the current research, we have cherry-picked the most impactful list of security controls that would provide the biggest benefit in thwarting attacks on the public cloud platform.

The first step in implementing a disciplined security program within the cloud is reducing the security scope and compliance boundary. Reducing the amount of attack surface to as minimum as possible automatically reduces the attack susceptibility (security control NS-1). Further, an adversary cannot reach the internally exposed network services and thus need not be protected with such rigor as an external service.

Running services in a non-standard port in a data center configuration would not yield any security benefit. However, things are different on the cloud. Since the attackers do not have time and resources to scan for every port exposed on every IP address on the cloud, non-standard ports are often protected by the mechanism of security by obscurity (security control NS-2). This security control would not protect the organization against targeted attacks but would yield practical benefits from unsophisticated hackers on the cloud.

Access controls make it difficult for an adversary to target the service and login without the necessary identification and verification required by these security measures. Just relying on the password would not offer sufficient protection against adversaries (security controls AC-1, AC-2, and AC-3). The password lists used by the adversaries are not static—the list of passwords changes based on the other services compromised on the internet and the passwords retrieved from the service. Therefore, leveraging multifactor authentication and passwordless mechanisms for restricting access would protect against these adversaries on the cloud. Also, we have noticed that the starting point of attackers for password compromise is the most common password found on the internet. Ensuring that the passwords selected are not one of the popular wordlists would bolster the security of the service (security controls AC-4).

On the detection side, all the failed login attempts to a service exposed to the internet from the cloud platform must be logged and monitored. Sufficient thresholds must be established for cumulative failed login attempts over a fixed time. Organizations can define a failed login counter for each user or the connecting IP address. Once the counter exceeds the established threshold, the organizations must automatically take suitable action (security control LM-1). Further, especially for services such as SMB, protocol-related errors must be carefully logged and monitored. Any deviation from the expected usage of the cloud service must be followed up as a security incident (security control LM-2).

Appropriately patching the services exposed in the cloud would prevent known exploits from adversaries from executing. Therefore, the vulnerability management process must ensure that the servers are patched in time as soon as they are released (security controls VM-1 and VM-2). However, this would not prevent any unpatched service from inadvertently getting exposed on the cloud. Hence, a vulnerability scanning system that routinely scans the exposed services against known vulnerabilities must be implemented as a stopgap. Any deviation identified in the scan must be remediated as soon as possible.

6. Conclusions

A robust honeypot model has been designed to provide a contrasting solution for deriving adversary behavior across multiple cloud platforms, ports, and protocols. The implemented honeypot was backed up with redundant logging and monitoring mechanisms to increase the availability and maximize the time the vulnerable services are exposed to adversaries. The attacker traffic across the cloud platforms was analyzed to explore different techniques adversaries used across insecurely configured services. The contrast of adversary behavior across cloud platforms allows one to understand their motives and help shape the organization’s defenses comprehensively.

It is possible to draw the following conclusions by leveraging the research in this article:

• This work focuses on leveraging the honeypot design to contrast the adversaries’ Tactics, Techniques, and Procedures (TTP) across cloud platforms;
• The security architecture of an application in the data center is different from that in the cloud. Due to increased agility, it is easy to make security mistakes in the cloud. Adversaries want to exploit this aspect and target organizations for quick wins on the cloud platform;
• The more popular the cloud platform is, the more adversary traffic to the exposed infrastructure will be;
• Misconfigurations in cloud platforms frequently occur owing to the intricate nature of cloud services, continuous technological evolution, and the susceptibility to human error, validating our hypothesis at the beginning of the article. These misconfigurations can result in security vulnerabilities and operational disturbances if not promptly identified and rectified;
• The usual behavior of the adversaries is to look for quick wins and target the most impactful vulnerabilities to obtain shell access to the cloud systems. Their main motive is to improve the Return on Attack (ROA) metric by actively scanning vulnerable hosts;
• It is possible to implement simple security controls that make it incrementally difficult for these attackers to compromise the cloud workloads. The proposed control structure would give ample defense in depth in this direction.

Many organizations are looking to use a multi-cloud approach for deploying their infrastructure. Such organizations would benefit from the proposed honeypot model, and the results from the honeypot would provide first warning alerts for the organization’s security. Even organizations looking to deploy services in a single cloud platform can benefit from the multi-cloud research. Usually, cost and contractual relationships with the cloud providers drive cloud platform adoption in these companies. Leveraging further research on multi-cloud honeypot architecture, organizations can use security and adversary interest as additional factors to select their cloud provider. More research and analysis would help document these adversaries’ Tactics, Techniques, and Procedures (TTP). Maintaining a centralized repository of these TTPs would help public cloud customers defend against the attacks.

Further, this work only looks at the exposure of the services for a limited time window of seventy days. Therefore, normalizing research over all four cloud providers, as suggested within this study over a more extended time, is necessary to capture the data and analyze how the services in the cloud are attacked.