Detecting Unauthenticated AWS OSINT: Catching Adversaries Before They're Inside

With our starter edition, we introduced a token type that's poorly understood for the visibility it offers: S3 honey buckets. They let you know when someone's running OSINT against your organization - traditionally a zero-risk operation for attackers.

At the start of most Red Team engagements, we perform OSINT against the target. Public S3 buckets, exposed resources, anything that helps build an initial picture. Finding misconfigurations early is the goal. Unauthenticated cloud enumeration has always been low-risk, there's no question about it - there's no authentication, more often than not no logs we'd typically see, nothing to alert on.

That changes with honey buckets as tokens. Deploy them matching your organization's naming patterns, and you'll know when someone's looking - perhaps the earliest detection point in the kill chain.

Cloud Enumeration Tooling

When it comes to performing unauthenticated enumeration of the cloud, there are a few great options.

For Azure AD/Entra ID, AADInternals is a tremendous tool that provides a wealth of information about a tenant through autodiscovery. For user identification, onedrive_user_enum is another great option. Both are excellent at building actionable information that can later be leveraged.

For AWS, enumeration is murkier. One of the more popular tools we'd sometimes use - rarely lucky - would be GrayHatWarfare, a purpose-built tool to raise awareness of the risks around public buckets.

Alongside the aforementioned tooling, we would more often than not - if not always - run cloud_enum, which enumerates candidate resources within AWS. The idea being that organizations likely name resources predictably. An organization named deceptiq would name their S3 buckets as permutations of the organization name - e.g., deceptiq-shared, deceptiq-backup, deceptiq-dev. Cloud Enum automates this enumeration - a lightweight but effective tool.

AWS Apps Enumeration

AWS Apps (AWS IAM Identity Centre Single Sign-On Portals) present another enumeration target. The default is normally d-[identity-centre-identifier].awsapps.com, but organizations can and will likely change this to match their organization name - e.g., deceptiq.awsapps.com.

Knowing the Identity Centre login URL for an organization opens the door to device code phishing. Phish the engineers, get a session token as the phished principal with their assigned permission sets. Detecting this, however, is hard - if not currently impossible. cloud_enum uses DNS enumeration to check for AWS Apps, and DNS subdomain enumeration doesn't leave traces you can monitor.

Why S3 Enumeration Is Different

Unfortunately for adversaries, fortunately for defenders - DNS subdomain enumeration for S3 isn't possible. AWS's S3 namespace is global and doesn't resolve via DNS in the same way.

As a result, cloud_enum performs HTTP requests against the base FQDN of each candidate bucket to check for existence. AWS will rate limit you after 1-2 minutes and start serving false replies to prevent enumeration. As seen in this Pull Request, the workaround is to pass a URL path (an existent or non-existent object, regardless) to avoid rate limiting.

1def check_s3_buckets(names, threads):
2    candidates = []
3
4    for name in names:
5        candidates.append(f'{name}.{S3_URL}')
6
7    utils.get_url_batch(candidates, use_ssl=False,
8                        callback=print_s3_response,
9                        threads=threads)
10# ...
11def print_s3_response(reply):
12    if reply.status_code == 404:
13        pass
14    elif 'Bad Request' in reply.reason:
15        pass
16    elif reply.status_code == 200:
17        data['msg'] = 'OPEN S3 BUCKET'
18        data['target'] = reply.url
19        data['access'] = 'public'
20        utils.fmt_output(data)
21        utils.list_bucket_contents(reply.url)
22    elif reply.status_code == 403:
23        data['msg'] = 'Protected S3 Bucket'
24        data['target'] = reply.url
25        data['access'] = 'protected'
26        utils.fmt_output(data)

The key insight: this HTTP-based enumeration behavior - traditionally impossible to detect - is now something we can instrument. And we do.

Deploying S3 Honey Buckets

You can deploy an S3 bucket honey token in the starter tier (limited to two buckets) that matches your organization's naming conventions. For example, deceptiq becomes deceptiq2025.

When someone performs OSINT against your public assets and environment, you'll know within seconds. We handle end-to-end monitoring through to alerting.

Detection in Action

Here's what happens when cloud_enum runs against an organization with a DeceptIQ S3 honey bucket deployed:

The tool finds what it's looking for - Protected S3 Bucket: http://deceptiq2025.s3.amazonaws.com/. From the adversary's perspective, this looks like a valid target worth investigating further. From your perspective, you just got an alert that someone is enumerating your infrastructure.

The alert arrives immediately:

Notice the details captured:

• Source IP: 185.195.232.135 - tagged as hosting/VPN infrastructure
• User Agent: python-requests/2.32.5 - the signature of automated tooling
• Event: ListObjects against s3.amazonaws.com
• Identity Type: AWSAccount with anonymous account ID (as expected)

This is unauthenticated enumeration. No credentials used. No authentication bypass. Just OSINT tooling doing what OSINT tooling does, and it's what every adversary is running - except now it's visible, and from having ate our own dog food for several months - surprisingly low noise as far as external alerts go, and certainly high signal to be in the know this early on.

Incident Details

Within 6 seconds of the enumeration attempt, the incident was created. The timeline captures source IP with geolocation and ASN, VPN/hosting classification, the exact AWS resources accessed, and user agent fingerprinting.

Deploy 2 buckets matching your naming patterns - if they're hit sequentially, you know exactly what's happening. Someone's running enumeration tooling against your organization.

For a Red Teamer running cloud_enum as part of routine OSINT, this would be their first interaction with your infrastructure - and you'd already know about it.

Detection at the earliest point in the kill chain - before initial access, before credential theft, before any authenticated activity. Someone is looking at your AWS footprint, and now you know.

The traditional response to unauthenticated S3 bruteforce enumeration was "there's nothing we can do about that." Unauthenticated OSINT was accepted as undetectable background noise.

Deploy S3 honey buckets matching your organization's naming patterns. When adversaries or Red Teams run their standard enumeration playbooks, you'll know.

Do it for free now on starter.deceptiq.com - 2 free buckets, try it out.