Data & research · 5 MIN READ · AARON WALTON AND BEN NAHORNEY · APR 25, 2025 · TAGS: Get technical / Guidance
TL;DR
- This is part four of four of our Quarterly Threat Report blog series for Q1 2025
- You can find parts one, two, and three here post-publication
- Part four covers trends and insights for cloud infrastructure trends
Our new Quarterly Threat Report (QTR) blog series for Q1 covers a lot of ground. So far, we gave you our top takeaways up front with Q1 by the numbers (volume 1), looked at how attackers are leveraging cloud-based services (volume II), and then talked about the endpoint attack surface (volume III).
The third attack surface we’re covering is cloud infrastructure. This front presents its own unique threats. We’ve also encountered more red team activity here than on any other attack surface. The attack surface appears to be the smallest of the three we’ve covered, with a relatively low amount of cyber attacks against it. However, those we’ve seen—such as those resulting from secret key exposure, server side vulnerabilities, and misconfigurations—are areas worthy of attention from a defensive front.
Many organizations don’t have physical servers, and much of their business may run out of Kubernetes clusters or Docker containers. These systems have unique threats, and make up a much smaller number of incidents overall.
As we monitor the landscape ourselves and read what others are seeing, attacks against cloud infrastructure are lower in volume in comparison to attacks against cloud-based services and against endpoints. This appears to be for two reasons:
- Monetization opportunities are limited. For the last few years, attackers most frequently use compromised instances for cryptomining, and even in Q1 2025, the attacks progressing furthest (before being stopped) still primarily result in cryptominers being deployed. (In fact, if you spin up an insecure cloud instance, attacker automation is likely to compromise the instance and run a cryptominer within 15 minutes of the instance being exposed to the internet.) Cryptominers are one of the most straightforward ways for attackers to monetize access, and there aren’t many other options. Other options require attackers to have a familiarity with abusing either the data or control planes, but not many attackers have those skills…yet.
- Less tools exist to facilitate targeting this attack surface. The most popular tools being used right now were built with the intention of enabling defenders to audit their own security. However, the availability of tools lowers the barrier to entry for cybercriminals too, and what we see is most threat actors are leveraging these existing security auditing tools for malicious activity.
This actually helps defenders in a few ways. First, the same tools attackers use are often the same ones used in red team testing. Using these tools within these tests—or on our own—allows defenders to find weaknesses in their systems before attackers do by searching for the same types of weaknesses. Second, lessons can be learned and applied from how these tools work. Understanding how these tools carry out parts of the attack life-cycle—such as enumeration—allows our organizations to build broader detections looking for those behaviors.
Other methods of monetization
Another way attackers have monetized this attack surface is ransomware. At the beginning of this quarter, Halycon observed an actor encrypting AWS S3 buckets and holding them for ransom. While not a completely new attack,it was a variation of a proof of concept developed in early 2024. The attack tactic is now being seen with increasing frequency. The attack leverages built-in AWS functionality and security lapses within the environment, such as secret key exposure.
To carry out the attack, access to AWS secret keys is required. These secret keys are often accidentally leaked through continuous integration and continuous delivery (CI/CD) pipelines, such as GitHub or GitLab. If exposed, an attacker can leverage the privileges given to the key. In the ransomware scenario, they use the key to turn native AWS functionality against the victim by generating their own encryption key and ransoming the data.
Attackers find exposed keys with tools like Trufflehog. Trufflehog works by scanning public repositories for keys, matching them against expected patterns. Once found, it’s simply up to the attacker to explore what access they have and use it.
We recommend organizations protect their environment from this type of attack by:
- Proactively scanning source code for secret keys (for AWS and other platforms) to prevent the keys from ever being exposed. Some tools, like GitHub’s Push Protection, can block a code commit if it contains secrets.
- Secrets should NOT be hardcoded in source code—it’s like storing a text file of passwords. It’s functional, but if the wrong person finds it, the access that the passwords grant can be abused.
- Scanning existing public and private repositories for exposed secrets. Using automation to scan for secret exposure can enable defenders to find and mitigate the problem before attackers can leverage it.
- Using short-term credentials and the principle of least privilege for access keys used by applications. This limits how long an exposed key can be abused—and even how it can be abused.
- Ensuring adequate monitoring and logging is enabled for the cloud environment. This allows security teams to identify and respond efficiently when anomalous activity occurs.
Not all security teams may be familiar with securing cloud infrastructure, we’ve previously created other guides to help. Check out our mind maps (for AWS, Google Cloud, Microsoft Azure, and Kubernetes), or this blog series on cloud security.
That’s a wrap on Q1 2025
This Quarterly Threat Report took a different approach to our data analysis, and we hope it was useful to think about things in a new light. We’ve focused on attack surface categories to help you better understand how to protect related areas of your tech stack, but also to illustrate how different attack surfaces require different approaches to achieve true resilience.
It’s our hope that by organizing this report to align with attack surfaces—and not just telemetry volume—it’s easier to apply our resilience recommendations across your tech stack, instead of focusing on specific threat types and working backwards.
Cloud-based services are constantly threatened in identity and email compromise incidents, as well as through the use of compromised credentials. Identifying and filtering out phishing attacks is critical here, as is the use of MFA to help shore up accounts. The key thing to remember is bad actors will take advantage of credentials once they have them, so strengthening your defenses will help prevent their illicit use.
Endpoint threats are mainly focused around malware and hands-on attacks attempting to compromise a network. Two-thirds of attacks on this surface category are non-targeted malware incidents. One of the best defensive strategies to combat this is limiting the permissions available and the system applications that end users can execute on their devices. If an attacker can’t execute their malicious payloads, they can’t advance their attacks.
Cloud infrastructure is the newest of these attack surface categories, and attackers and defenders are learning at the same time. Right now, this category sees a lot of red team and pen testing activity, but exposed secrets and misconfigurations still pose a huge threat here. Ensuring your cloud infrastructure isn’t susceptible to attacks of opportunity, caused by accidental configuration errors, will help to mitigate the risk.
Stay tuned for expanded conversations on topics from this report, and as we continue to track data, identify patterns, and share insights to help you and your org stay protected.
Questions about this series or just want to chat? Give us a shout.
