The state of cloud security is a dynamic and ever-evolving landscape, as both attackers and defenders continuously adapt their tactics and measures. With more and more sensitive information and critical systems residing in the cloud, it is essential for organizations to implement robust security measures to safeguard their cloud assets. However, to do this in an effective manner, it is essential to understand what attackers are looking for and how they operate.
To this end, Orca Security released the 2023 Honeypotting in the Cloud Report, which offers important insights into what attracts potential attackers as well as the tactics and techniques they use. For the research project we deployed ‘honeypots’ on 9 different environments that simulated misconfigured resources in the cloud, acting as bait for bad actors. Honeypots were placed on AWS S3 Buckets, GitHub, DockerHub, Elastic Container Registry, Elasticsearch, HTTP, Elastic Block Storage, Redis, and SSH.
Each honeypot included a secret, in this case an AWS secret access key. The report lists in detail what actions the attackers took on each of our honeypot resources, and provides recommendations on how to thwart these bad actors to better secure your organization’s cloud assets.
Key Findings
At a high level, these are the five key takeaways from our research:
- Vulnerable assets are discovered rapidly: Misconfigured and vulnerable assets are literally discovered within minutes (GitHub – 2 minutes, HTTP – 3 minutes, SSH – 4 minutes, S3 Buckets – 1 hour).
- Time to key usage varies significantly per asset type: We saw key usage on GitHub within 2 minutes, which means that exposed keys are basically compromised instantly. For S3 Buckets it took 8 hours, and for Elastic Container Registry 4 months.
- Not all assets are treated equally: The more popular the resource, the easier it is to access, and the more likely it is to contain sensitive information, the more attackers are inclined to do reconnaissance. Certain assets, such as SSH, are highly targeted for malware and cryptomining.
- Defenders shouldn’t rely on automated key protection: Apart from GitHub, where the exposed AWS key permissions were immediately locked down, we did not detect any automated protection for the other resources that we tested.
- No region is safe: Although we saw 50% of exposed AWS key usage in the US region, usage occurred in almost every other region as well, including Canada, APAC, Europe, and South America.
To provide further background on the research results and what this means for defenders, Bar Kaduri and Tohar Braun will be presenting their findings in our webinar on July 12th, ‘Exposing Attacker Tactics Using Cloud Honeypots’.
Research Methodology
Our research was conducted between January and May 2023. To set up our ‘honeypots’ and simulate misconfigured resources, we basically broke all security best practices (don’t try this at home!):
- We created a number of repositories in different environments and configured them to allow public or easy access.
- Next, we placed a secret – in this case AWS keys – in our honeypots.
- Then we waited for the attackers to take the bait..
The goal of our honeypot research was to find out the following:
- Which of the popular cloud services are most frequently targeted by attackers?
- How long does it take for attackers to access public or easily accessible resources?
- How long does it take for attackers to find and use leaked secrets?
- What are common attack routes and methods?
- How can we leverage this information to increase defenses?
Research Results
In some ways, our study confirmed what is already widely known: attackers are constantly scanning the Internet for lucrative opportunities. What did surprise us however was how fast this was happening in some cases. Depending on the resource, attackers sometimes just needed a few hours or even minutes to find and use the exposed keys in our honeypots.
In addition, we found that the more breadcrumbs exist for S3 Buckets, the faster the access and key usage. While we had to leave additional breadcrumbs to our (fake) buckets before we saw access, we would expect legitimate buckets to have many more breadcrumbs, such as references to bucket names, IDs, and links. Therefore accidentally exposed legitimate buckets are likely to be accessed even faster by attackers, meaning discovery would be expected in under one hour.
Why Are Some Resources Targeted More?
The ‘attractiveness’ of a resource depends on a combination of factors:
- Cost/benefit ratio: The easier the discoverability of the resource, the more attractive the resource will be for attackers:
- For instance, on GitHub it is easy to discover public repos and new commits in those repos.
- If the asset is exposed to the Internet via a TCP port, such as HTTP, Elasticsearch, Redis, SSH, and Postgres, these systems can be found efficiently via a resource like Shodan.
- However, for S3 buckets, there is no way to query all S3 buckets in existence and there is no unauthenticated way to query all of a particular account’s S3 buckets; instead, a dictionary attack approach is required, cycling through a space of potential bucket names to find publicly accessible ones, something which takes more effort, even though it can also be done in an automated way.
- How much the resource is used: The more users of a resource, the more chance of finding potentially useful data.
- How prone it is to contain secrets: For instance GitHub is very prone to contain secrets since it contains all the source code of a project, sometimes even of an entire organization. Other resources are less prone to this.
Key Recommendations for Defenders
Since there are major differences in attacker tactics per resource, defenders must tailor their defense strategy for each resource. For instance, because GitHub is monitored so heavily by attackers and secrets are discovered so quickly, the risk justifies the overhead of ensuring that any secret leakage is prevented before committing code. Another example is systems that require exposing SSH to the Internet where additional mitigations are recommended to detect and prevent the execution of malware such as cryptominers.
The report includes 8 key recommendations for defenders to stay ahead of the attackers, including advice on secrets management, authentication, malicious process monitoring, and more.
About the Orca Research Pod
The Orca Research Pod is a group of cloud security researchers that discovers and analyzes cloud risks and vulnerabilities to strengthen the Orca platform and promote cloud security best practices. To date, the Orca research team has discovered and helped resolve 15+ vulnerabilities in cloud provider platforms to help support a safe and secure cloud infrastructure.
The Orca Cloud Security Platform
Orca’s agentless Cloud Security Platform connects to your environment in minutes and provides 100% visibility of all your assets on AWS, Azure, Google Cloud, Kubernetes, and more. Orca detects, prioritizes, and helps remediate cloud risks across every layer of your cloud estate, including vulnerabilities, malware, misconfigurations, lateral movement risk, API risks, sensitive data at risk, weak and leaked passwords, and overly permissive identities.
