Through the Attacker’s Eyes: A New Era of NHI Security

This final installment in our blog series brings together everything we’ve uncovered about leaked AWS Access Keys—how attackers exploit them, why traditional security measures fall short, and what organizations can do to protect themselves.

Over the series, we explored real-world scenarios across various platforms: GitHub and GitLab, Package Managers, Code Sharing Platforms, developer forums, and even the Internet Archive breach and RDS credentials. These experiments laid bare the truth: secrets exposed online are a magnet for attackers, and traditional secret rotation is no match for their speed and sophistication.

In this post, we’ll look at the game through the attackers’ eyes, explore the methods and tools they use, and unveil AWSKeyLockdown—a tool we built to help enterprises neutralize these threats.

Addressing a Common Misconception - The Hidden Dangers of Quarantined Keys

It's crucial to address a misconception that could undermine the perceived impact of our research. One might argue that since platforms like GitHub automatically detect exposed AWS access keys and AWS promptly attaches the AWSCompromisedKeyQuarantineV2 policy to these keys, the potential for damage is minimal. After all, if the keys are quickly quarantined, what harm could attackers possibly inflict within such a short window?

This line of thinking, however, dangerously underestimates the capabilities of modern attackers and the residual risks associated with quarantined keys. While it's true that GitHub's secret scanning (freely available for all public repositories) alerts AWS to exposed keys—prompting an automatic quarantine—the reality is that these compromised keys remain far from harmless. Attackers can and do exploit them almost immediately upon exposure, often within minutes or even seconds.

Even with the quarantine policy in place, a significant number of permissions remain accessible to the attacker. These permissions allow for a range of malicious activities, including but not limited to:

  • Reconnaissance Operations: Attackers can list users, roles, policies, and access keys through IAM (iam:List*, iam:Get*), gaining invaluable insights into your AWS environment.
  • Data Exfiltration: They can download objects from S3 buckets (s3:GetObject), retrieve secrets from AWS Secrets Manager (secretsmanager:GetSecretValue), and access sensitive configurations in Lambda functions.
  • Privilege Escalation: Through actions like assuming roles with STS (sts:AssumeRole), attackers can potentially escalate their privileges, gaining broader access than initially permitted.
  • Cost Incurrence and Service Abuse: Invoking high-cost services such as machine learning models on AWS Bedrock (bedrock:InvokeModel) can lead to unexpected charges and service disruptions.
  • Backdoor in EC2 Instances: Attackers can initiate aws ssm start-session to gain access to EC2 instances with SSM enabled, allowing them to establish multiple backdoors for persistent access.
  • Disruption of Infrastructure and Data Loss: Attackers can run aws ec2 terminate-instances to delete active deployments, stored data, and configurations, severely disrupting services. Without a robust backup, this could result in permanent data loss and extended downtime.
  • Persistent Access and Lateral Movement: By modifying configurations or injecting code in services like Lambda and Glue, attackers can establish backdoors for persistent access and pivot to other parts of the infrastructure.

The key takeaway here is clear: Automatic quarantine does not equate to automatic safety. Relying solely on secret rotation and automated detection creates a false sense of security. The speed at which attackers operate far outpaces these reactive measures, necessitating a fundamental shift in existing security paradigms.

As a side note, AWS recently introduced AWSCompromisedKeyQuarantineV3, which we anticipated would include more stringent controls in the policy. However, not only is V2 still the default policy in use, but V3 is also entirely identical to V2.

A Note on AWS Recommendations

AWS Trusted Advisor includes a feature to scan popular platforms (which, based on our findings, appears limited to GitHub and npm) for exposed secrets and notify customers when an exposed access key is detected. When such a secret is found, Trusted Advisor triggers an Exposed Access Keys alert1, with a straightforward recommendation: delete the exposed key immediately.

However, there’s a clear disconnect between this recommendation and what’s actually possible once the AWSCompromisedKeyQuarantineV2 policy is applied to an exposed key. Despite AWS’s suggestion to delete compromised keys, there’s no built-in option to immediately disable these keys upon detection, leaving them potentially vulnerable to quick exploitation. Why doesn’t AWS offer a mechanism that allows customers to automatically disable exposed access keys as soon as they’re detected?

In contrast, throughout all of our testing, GCP service account keys were automatically revoked by Google upon receiving a notification from GitHub. This highlights the major difference between how these two cloud service providers handle exposed credentials. While AWS provides a recommendation to revoke keys—hidden within the obscure documentation of AWS Trusted Advisor, a service not universally adopted by all customers—it ultimately leaves the burden of revocation on the customer. GCP, however, takes a proactive approach by making the judgment call to revoke the key immediately, preventing any opportunity for an attacker to exploit the environment. We strongly advocate for GCP's method, as it better aligns with the realities of modern security operations, where teams are inundated with alerts and tasks, and often lack the expertise or bandwidth to act swiftly. By removing this burden from customers, GCP significantly reduces the risk of exploitation and sets a better standard for security best practices.

The Attacker’s Perspective

The actions we observed paint a picture of methodical, highly organized operations. These attackers didn’t just stumble across exposed keys—they’re part of an ecosystem built to exploit them at scale. Using techniques like privilege escalation, lateral movement, and reconnaissance, the attackers systematically mapped and infiltrated our sandboxed cloud environments. For example, they often started with operations like listing users, secrets, or instances to understand our infrastructure. They even attempted to leverage our infrastructure for resource-intensive operations, such as invoking machine-learning models, driving up costs, and using the environment as a tool for their broader objectives. This isn’t opportunism; it’s automation and intent.

While we cannot attribute these activities to specific threat actors—be they nation-states, financially motivated cybercrime groups, or otherwise—it’s clear from our findings that attackers leverage a wide variety of infrastructure. This includes commodity platforms like Namecheap and OVH, major cloud providers like AWS, Google Cloud, and Azure, and more suspicion-invoking providers such as Alibaba. The geographic distribution of activity spans the globe, with notable concentrations from regions like China, Canada, and the United States. The use of diverse services and platforms shows the adaptability and scale of these operations, making them harder to track and even harder to defend against.

Our research makes one thing clear: the way organizations approach security needs to change. Traditional methods like secret rotation give a false sense of control and fail to keep pace with attackers who exploit exposed secrets within minutes. Whether the threats come from nation-state actors, financially motivated cybercrime groups, independent researchers, or others, the consequences are immediate and severe.

The solution lies in rethinking security strategies to reduce reliance on static secrets entirely. Approaches like Zero Trust and ephemeral identities shift the focus from reactive measures to proactive safeguards. Once a secret is exposed, the priority becomes containment, mapping the blast radius, and neutralizing the threat as quickly as possible. Organizations must accept that the fight begins the moment something leaks and structure their defenses and responses to handle that reality.

Introducing AWSKeyLockdown

The harsh reality is undeniable: the AWSCompromisedKeyQuarantineV2 policy that gets automatically attached to exposed keys doesn’t just fall short in theory—it’s a practical reality that attackers actively leverage and exploit.

Our experiments demonstrated that even when keys are quarantined, attackers can still perform actions like privilege escalation, data exfiltration, and resource abuse, all within minutes of exposure. This isn’t a hypothetical or a theory, it's the reality of modern cloud environments.

That’s why we built AWSKeyLockdown, an open-source solution enabling teams to instantly revoke an AWS access key as soon as the AWSCompromisedKeyQuarantineV2 policy is applied—leaving attackers no time to exploit it. This tool is available in both Terraform and CloudFormation.

Wrapping It Up: A Call to Action

This series has shown, unequivocally, that secret rotation is a security fallacy—a strategy that lulls organizations into a false sense of safety while creating friction between security and development teams. It doesn’t solve the problem; it merely resets the clock.

The time has come to adopt modern, proactive measures like Zero Trust architectures and ephemeral secrets.

If you want to dive into the full research, we invite you to download the full report, with all scenarios we ran, an in-depth look at our methodologies, platform-specific insights, attacker behavior patterns, and the tool we built to neutralize exposed secrets instantly. It’s an essential read for any organization looking to secure its systems against the escalating risks of exposed secrets.

But this is just the beginning. In the next phase of our research, we’ll shift focus to other critical areas: NHIs in the worlds of Code and CI/CD, and SaaS applications, where the challenges of securing credentials are just as urgent.

Our hope is that this series sparks change. If our work prevents even one breach or keeps one attacker at bay, it was worth the effort. Together, we can make the cyber ecosystem more secure.

[1]https://docs.aws.amazon.com/awssupport/latest/user/security-checks.html#exposed-access-keys