No keys, no scanners: Black-Box Hacking of AWS Environments

No keys, no scanners: Black-Box Hacking of AWS Environments

Speakers: Eduard Agavriloae, AWS Offensive Security Expert, Offensi

Conference: DefCamp

YouTube: https://www.youtube.com/watch?v=tLqLsqaC7AY

Overview

In the realm of cloud security, the vast majority of penetration testing and auditing engagements are conducted with some level of prior access and information, often termed "white-box" assessments. While invaluable, this approach leaves a critical blind spot: the ability of an attacker to compromise an AWS environment from a completely unprivileged, external, or "black-box" perspective. This talk, delivered by Eduard Agavriloae, a seasoned AWS Offensive Security Expert and co-founder of Offensi, addresses this exact challenge, presenting a methodology for identifying and potentially exploiting AWS resources without any initial keys, scanners, or internal access.

Agavriloae’s presentation delves into innovative black-box techniques that allow attackers to reverse-engineer AWS account IDs and then enumerate publicly exposed resources associated with those accounts. This methodology highlights a significant gap in conventional security postures, as the reconnaissance activities often occur entirely outside the target's observable AWS environment, thus generating no CloudTrail logs for detection. The talk not only demonstrates the feasibility of such attacks but also offers crucial defensive implications for organizations operating in AWS, urging them to reconsider fundamental security assumptions, such as the sensitivity of their AWS Account IDs.

Background

▶ Watch: Introduction to Black-Box AWS Hacking (0:00)

The prevailing approach to cloud security engagements often assumes a "white-box" scenario, where security professionals are provided with explicit permissions, access keys, or internal network access to the target AWS environment. While this allows for comprehensive auditing of configurations and internal vulnerabilities, it fails to address the initial attack surface exposed to the public internet. The critical question, as Agavriloae poses, is: "How can you get that access, and what exactly can you compromise from a black-box perspective on your target environment?"

Traditional entry points for attackers include supply chain attacks, social engineering or phishing campaigns targeting employees with cloud access, or compromising runtime resources like EC2 instances, Lambda functions, or Kubernetes clusters to extract credentials. Another common vector involves discovering exposed access keys on public repositories or within pre-signed URLs. However, Agavriloae's methodology focuses on a more fundamental reconnaissance technique: identifying the target's AWS Account ID and subsequently enumerating their public resources without any prior authentication or direct interaction that would trigger alerts within the target's logs. This approach targets a blind spot where organizations might not even realize they are being probed, let alone have the means to detect it. The core problem this talk addresses is the lack of a standardized, black-box methodology for initial AWS reconnaissance, which leaves many organizations vulnerable to stealthy external enumeration.

Key Findings

▶ Watch: Live Demo: Finding Account ID from S3 bucket (4:05)

Eduard Agavriloae's research and methodology unveil several critical findings regarding black-box hacking of AWS environments:

1. AWS Account IDs are not secrets in practice: While AWS officially states that the Account ID is not a secret, the talk strongly advocates for treating it as such. Agavriloae demonstrates that the AWS Account ID can be reliably identified from various external sources, including an Access Key ID (even a temporary one), the name of a public S3 bucket, or other publicly exposed resources like AMIs (Amazon Machine Images).
2. Stealthy Enumeration: A significant finding is that the black-box reconnaissance techniques demonstrated, particularly those involving querying AWS APIs from an attacker's own AWS account or public sources, generally do not generate CloudTrail logs in the target AWS account. This lack of logging creates a critical blind spot for defenders, making it nearly impossible to detect that an attacker is actively mapping their public AWS footprint.
3. Public Resource Discovery is Feasible: Once an AWS Account ID is identified, an attacker can enumerate a range of publicly accessible resources owned by that account across all AWS regions. These include public AMIs, EBS snapshots, RDS snapshots, and SSM documents. Such resources, even if seemingly innocuous, can often contain sensitive information, configuration details, or even credentials, serving as stepping stones for deeper compromise.
4. Challenges in Large-Scale Automated Discovery: Despite the theoretical feasibility, Agavriloae's attempt to apply the methodology at scale against a broad range of targets (bug bounty programs, Greyhat Warfare S3 bucket lists) yielded a surprisingly low number of easily identifiable or exploitable public resources. This suggests that while individual misconfigurations exist, widespread, easily discoverable vulnerabilities might be less prevalent, or that companies are improving their security posture, at least for well-known public buckets.
5. Pre-signed URLs are a double-edged sword: While useful for controlled access to private S3 buckets, pre-signed URLs inherently contain an Access Key ID, which can then be used to reverse-engineer the associated AWS Account ID, inadvertently exposing this identifier.

These findings collectively underscore the importance of shifting defensive strategies to account for an attacker's ability to operate effectively from a completely external vantage point, often without leaving a trace in the target's logs.

Technical Deep Dive

▶ Watch: Scaling the attack: Bug bounty programs & S3 scanning (6:30)

The core of Agavriloae's methodology revolves around two primary phases: identifying the target's AWS Account ID and then enumerating publicly exposed resources associated with that ID. This is achieved through a combination of open-source intelligence (OSINT) and clever utilization of AWS's own API behaviors.

Initial Entry Points and Account ID Identification:

The talk outlines several pathways an attacker might use to gain initial traction or directly identify an AWS Account ID:

1. Compromising Runtime Resources: Attackers might first compromise EC2 instances, Lambda functions, or Kubernetes clusters to obtain temporary or persistent AWS credentials. These credentials, in turn, contain an Access Key ID, which is a crucial piece of information.
2. Exposed Access Keys: Finding access keys in public repositories (e.g., GitHub), or embedded within pre-signed URLs for services like S3, directly provides an Access Key ID. Agavriloae explicitly notes seeing this with pre-signed S3 URLs.
3. Abusing AWS Cognito Credentials: AWS Cognito is a service for user authentication and authorization. Misconfigurations or exploits related to Cognito can yield credentials that, similar to other access keys, contain an Access Key ID.

Once an Access Key ID (either persistent or temporary) is obtained, Agavriloae highlights a "small script" (available as an article he shared) that can reverse-engineer the AWS Account ID from it. This script leverages the structure or behavior of AWS APIs to derive the owning account, even without having the full access key secret.

A second, equally powerful technique for identifying the AWS Account ID, especially relevant for black-box scenarios, is through public S3 buckets. The speaker demonstrates using an open-source tool called S3 account search. This tool takes an S3 bucket name (e.g., company-test-bucket) and, by interacting with AWS APIs, can determine the AWS Account ID that owns it. While this operation can be time-consuming (initially noted as ~4 minutes in the demo, later optimized to ~1 minute per bucket through parallelization), it's a reliable method for an attacker with no prior access.

Finally, other publicly exposed AWS resources can reveal an Account ID. If a company publishes public AMIs (Amazon Machine Images) or makes EBS snapshots, RDS snapshots, or SSM documents publicly available, an attacker can query AWS APIs (from their own AWS account) to find these resources and, crucially, identify the owning AWS Account ID embedded within their Amazon Resource Names (ARNs) or metadata.

Enumeration Post-Account ID Discovery:

With the AWS Account ID in hand, the attacker shifts to a more targeted reconnaissance phase:

1. Querying AWS APIs for Public Resources: From their own AWS account, an attacker can use AWS CLI or SDKs to query for publicly shared resources belonging to the identified AWS Account ID. This includes searching for public AMIs, EBS snapshots, RDS snapshots, and SSM documents. To be comprehensive, this enumeration needs to be performed across all AWS regions, as by default, only 14 regions might be enabled in an attacker's AWS account.
2. OSINT with ARNs: Agavriloae mentions using public sources like Sourcegraph and GitHub to search for patterns matching AWS ARNs that include the target's AWS Account ID. This can sometimes reveal additional internal resource names or configurations that might not be directly queryable via public AWS APIs.
3. Bruteforcing User/Role Names: While not directly yielding access, having the Account ID allows an attacker to build a wordlist of common user and role names and attempt to brute-force assume-role operations. As shown in the demo, this often fails if the target has strong security (e.g., roles aren't easily guessable or don't allow external assumption), but it's a logical next step for an attacker.

Scaling the Methodology:

Agavriloae attempted to apply this methodology at scale, demonstrating the practical challenges and potential for automation:

1. Bug Bounty Program Analysis:

• BBscope: Used to aggregate and download URLs and programs from various bug bounty platforms (e.g., HackerOne).
• Subfinder: Extracted subdomains for the identified bug bounty programs, yielding 1.1 million subdomains from 38,000 initial URLs.
• Katana: Used to identify S3 buckets mentioned within the websites hosted on these subdomains.
• Result: This extensive process, after 4 days of scanning, only identified 20 S3 buckets, a surprisingly low number, which Agavriloae attributed to companies taking security seriously or prior remediation efforts.

1. Mass S3 Bucket Enumeration:

• Utilized the Greyhat Warfare API to download a list of 350,000 public S3 buckets.
• Developed a custom script with multiple modules to perform the Account ID identification and subsequent public resource enumeration on these buckets.
• Parallelization: Improved the S3 account search time from 4 minutes to approximately 1 minute per bucket by running operations in parallel.
• Results: Over another 4 days of non-stop scanning, only about 4,000 S3 buckets were processed. These were owned by 2,800 distinct AWS accounts, indicating some accounts had multiple public buckets. Crucially, no public resources were identified for any of these scanned buckets. This led the speaker to stop the scan, suggesting that targeting more specific, less "out there" targets might yield better results, or that many of these widely exposed buckets are already well-secured or non-sensitive.
• Scalability Improvement: Agavriloae noted that a more robust scaling approach would involve using AWS's own services, such as loading all buckets into an SQS queue and employing 50-100 Lambda functions to process messages concurrently and save results to a database. This would significantly increase throughput but also incur substantial cost.

The technical deep dive reveals a sophisticated approach to black-box AWS reconnaissance, leveraging subtle API behaviors and OSINT to map a target's cloud infrastructure without leaving a trace in their logs.

Demo / Proof of Concept

▶ Watch: Q&A: Why enumeration does not generate CloudTrail logs (14:50)

Eduard Agavriloae presented a compelling live demonstration that walked through the core tenets of his black-box AWS reconnaissance methodology, using a hypothetical "generic company" as the target.

The demo began by simulating an attacker's initial step: identifying potential S3 buckets associated with a target. Agavriloae used the Greyhat Warfare API to search for S3 buckets containing the company's name, specifically selecting company-test as an example. This quickly yielded a target S3 bucket.

The next crucial step was to determine the AWS Account ID behind this identified S3 bucket. For this, the speaker employed the open-source tool S3 account search. The demo showed this process in action, noting that it typically takes a few minutes (around 4 minutes in this specific instance) to complete. Upon successful execution, the tool returned the exact AWS Account ID owning the company-test S3 bucket. This marked a significant milestone, as the attacker now possessed a foundational identifier for the target's AWS presence without any prior authentication.

With the AWS Account ID in hand, the demonstration proceeded to the enumeration phase. Agavriloae then queried AWS APIs (presumably from his own AWS account, as is the methodology's premise) to search for publicly accessible resources owned by the newly discovered Account ID. The types of resources targeted included:

• Public AMIs (Amazon Machine Images)
• EBS snapshots (Elastic Block Store snapshots)
• RDS snapshots (Relational Database Service snapshots)
• SSM documents (Systems Manager documents)

The demo successfully identified several such resources, including the initial S3 bucket that was used for the Account ID discovery. This illustrated how a single exposed resource could lead to a broader mapping of an organization's public cloud assets.

Finally, Agavriloae attempted to assume a role using a guessed or commonly named role for the identified AWS Account ID. This step, however, failed, which the speaker highlighted as a positive sign of good security practices by the target organization. This failure emphasized the importance of not using easy-to-guess or conventional names for roles and users, as well as restricting cross-account role assumption.

A key point reiterated during the demo was the necessity for the attacker to enable all available AWS regions in their own AWS account to ensure a comprehensive enumeration of resources, as AWS services and resources are region-specific. The demo effectively showcased the entire black-box reconnaissance chain, from initial bucket discovery to Account ID identification and subsequent public resource enumeration, all without requiring any pre-existing credentials or direct network access to the target's environment.

Defensive Implications

▶ Watch: Q&A: Pre-signed URLs expose Account IDs (20:45)

The insights from Eduard Agavriloae's talk carry profound defensive implications for any organization operating within AWS. The core message is a call to fundamentally re-evaluate how AWS Account IDs and publicly exposed resources are perceived and protected.

1. Treat AWS Account ID as a Secret: This is perhaps the most critical takeaway. Despite AWS's official stance that the Account ID is not a secret, Agavriloae emphatically states that it should be treated as one within the security community. Exposing the Account ID provides attackers with a direct identifier to begin enumerating an organization's public cloud footprint. Defenders must recognize that the Account ID is the entry point for black-box reconnaissance.
2. Shield S3 Buckets with CloudFront: Direct exposure of S3 buckets is a significant risk vector. Organizations should avoid making S3 buckets directly public. Instead, they should front them with an Amazon CloudFront distribution. CloudFront acts as a content delivery network (CDN) and can conceal the underlying S3 bucket's name and, by extension, prevent its direct use for Account ID discovery via tools like S3 account search. While incurring additional costs, this measure significantly enhances security.
3. Avoid Easy-to-Guess or Conventional Naming: Developers and administrators should be educated against using predictable, conventional, or personal names for AWS resources, users, roles, and buckets. Easy-to-guess names (e.g., dev-bucket-companyname, admin-role) simplify an attacker's efforts to enumerate and potentially brute-force access, as demonstrated by the failed assume-role attempt in the demo.
4. Minimize All Exposure: The talk underscores that "any exposure brings the attackers closer to your environment." This applies not only to S3 buckets but to any publicly accessible AWS resource, including AMIs, EBS snapshots, RDS snapshots, and SSM documents. Organizations must rigorously review what information is made public and ensure that no sensitive data or configuration details are inadvertently exposed.
5. Understand the Lack of CloudTrail Logging: A chilling defensive implication is that most of the black-box enumeration techniques discussed do not generate CloudTrail logs in the target AWS account. This means organizations cannot rely on their standard logging and monitoring solutions to detect these initial reconnaissance activities. Defenders must be aware that attackers can map their public AWS environment without leaving a trace on their side.
6. Implement Honeypots and Canary Tokens for Post-Compromise Detection: Since direct black-box reconnaissance is hard to detect, the focus shifts to detecting post-compromise activity. Agavriloae suggests deploying honeypots (e.g., non-sensitive resources designed to be accessed only by attackers) and canary tokens (e.g., fake AWS access keys that, if used, trigger an alert). If an attacker gains initial access and attempts to use these deceptive resources or credentials, it immediately signals a compromise, even if the initial reconnaissance was stealthy.
7. Segregate AWS Accounts for Public Resources: To limit the blast radius of a potential compromise, it's a good practice to use dedicated AWS accounts for public-facing resources, such as static websites or S3 buckets. If these accounts are compromised, the impact on core production environments or sensitive data stored in other, segregated accounts is minimized.
8. Be Wary of Pre-signed URLs: While useful for controlled access, pre-signed URLs inherently expose an Access Key ID, which can then be used to derive the AWS Account ID. Organizations must weigh the convenience against the risk of inadvertently exposing this identifier, especially if the pre-signed URLs are widely distributed or persist for extended periods.

In essence, defenders must adopt a proactive, adversarial mindset, assuming that their AWS Account ID can be discovered and that their publicly exposed resources will be enumerated. The emphasis must be on preventing the exposure of sensitive information and ensuring that even if reconnaissance occurs, no actionable vulnerabilities are readily available.

Key Takeaways

• AWS Account IDs are discoverable: Despite AWS's official stance, an AWS Account ID should be treated as a secret, as it can be reliably identified from external sources like Access Key IDs, public S3 bucket names, or other publicly exposed resource metadata.
• Black-box reconnaissance is stealthy: Initial enumeration of AWS Account IDs and public resources often does not generate CloudTrail logs in the target account, creating a significant blind spot for defenders and making detection extremely difficult.
• Publicly exposed resources are attack vectors: S3 buckets, public AMIs, EBS snapshots, RDS snapshots, and SSM documents, even if seemingly innocuous, can reveal critical information or serve as stepping stones for deeper compromise if not properly secured and monitored.
• Shield public S3 buckets: To prevent Account ID discovery and direct access, S3 buckets should always be fronted by an Amazon CloudFront distribution, adding a layer of abstraction and security.
• Avoid predictable naming: Using easy-to-guess or conventional names for AWS resources, users, and roles significantly aids attackers in their enumeration and brute-force attempts. Strong, unpredictable naming conventions are crucial.
• Implement post-compromise detection: Since black-box reconnaissance is hard to detect, organizations should focus on honeypots and canary tokens (e.g., fake AWS access keys) to identify attackers after they gain initial access, providing a crucial alert mechanism.

About the Speaker(s)

Eduard Agavriloae is a prominent figure in cloud security, serving as a co-founder and Director of Research and Development at Offensi. He is recognized as a security researcher, ethical hacker, international speaker, and trainer, with a specialized focus on cloud security, particularly within the Amazon Web Services (AWS) ecosystem. His work centers on offensive security techniques and methodologies to uncover vulnerabilities and improve the security posture of cloud environments.