Stage 1: Enumeration

You've found an open bucket, and the first move is to enumerate it. Every major provider's object storage returns a full directory manifest when the bucket is publicly listable: AWS S3 and S3-compatible stores respond to ?list-type=2; Azure Blob responds to ?restype=container&comp=list when the container's anonymous access level is set to container (a blob-level setting allows direct object reads but not listing); GCS responds to the XML or JSON list API. The response is structured XML or JSON with every object's name, size, content type, and last-modified timestamp.

The manifest is loot on its own. Object names reveal:

  • Internal naming conventions: directory structures, environment names (prod, staging, dr), and project codenames that aid follow-on targeting.
  • What's there without downloading it: a file named db-backup-prod-2025-03-01.tar.gz tells an attacker there's a database backup and when it was made, before a single byte of the file is transferred.
  • Historical depth: buckets used for backups or logs often contain years of files. A long manifest shows what exists today and what data the organization has retained over time.

No authentication is required. The requests look identical to normal application traffic, and the whole listing completes in seconds, even for buckets holding hundreds of thousands of objects.

Stage 2: Credential and sensitive data extraction

With the manifest in hand, the attacker triages for high-value targets rather than downloading blindly. These patterns get pulled first:

  • Database backups: .sql, .dump, .bak, .tar.gz, .zip files with names referencing db, database, backup, or export. These contain customer data along with the schema, stored procedures, and hashed (or plaintext) credential records for every application user.
  • Configuration and environment files: .env, config.json, settings.yaml, appsettings.json, secrets.json. These files frequently contain hardcoded database connection strings, API keys for third-party services (payment processors, email providers, identity services), and cloud provider credentials.
  • Infrastructure-as-code and deploy artifacts: Terraform state files, CloudFormation templates, and Ansible playbooks often embed resource identifiers, role ARNs, and sometimes credentials that were interpolated at deploy time.
  • Log files: application logs, access logs, and audit trails can contain session tokens, internal IP ranges, user activity timelines, and error messages that expose internal system architecture.

Retrieval is fast and cheap: one unauthenticated GET per object, looped over the manifest. A few lines of script empties the bucket.

Stage 3: Lateral movement

Cloud credentials pulled from a bucket are immediately actionable. An AWS access key and secret sitting in an .env file grant authenticated API access to whatever that key can do. The blast radius is whatever the key's permissions allow:

  • An IAM key scoped to S3 allows access to other buckets that the application user can reach (potentially many more than the one that was publicly open).
  • An admin key allows enumeration of the entire AWS account: EC2 instances, RDS databases, Secrets Manager entries, Lambda functions, and more.
  • Credentials for a service account (GCS, Azure) follow the same pattern. The service identity's permissions define the blast radius.

Container misconfigurations also enable lateral movement through the application layer. Database credentials found in a backup allow direct database access, hardcoded JWT signing secrets allow forging authentication tokens, and internal API keys can reach endpoints that are not exposed publicly but are callable from anywhere once the key is known.

Anonymous write: a separate and underappreciated risk

Most discussion of open buckets stops at read exposure. Anonymous write access (when a bucket's ACL or policy allows unauthenticated PUT or POST) opens attack surfaces that have nothing to do with exfiltration:

Malware hosting. An attacker who can write to a trusted-looking hostname (e.g., assets.example.com, backed by an open bucket) can upload executable files or malicious scripts at a path that appears to originate from the legitimate domain. This can be used to bypass reputation-based security filters or phishing detection that trusts the parent domain.

Defacement and content injection. For buckets serving static websites or application assets, an attacker with write access can overwrite existing files. A JavaScript file replaced with a malicious variant affects every user who loads the page after the change.

Storage cost attacks. An attacker who uploads large volumes of data to a publicly-writable bucket does so at the bucket owner's expense. Cloud storage pricing is based on stored volume and egress; a coordinated write campaign can generate significant unexpected charges.

Deletion and ransomware-style disruption. If the anonymous write permission includes delete, an attacker can destroy data outright, or demand payment to reveal which objects were deleted.

Why "no logs" is not "no access"

The reflex after finding an open bucket is to check the logs and exhale: "Nothing unauthorized in here." That exhale is unearned. Absence of logs is not absence of access.

Access logging may not be enabled. Cloud storage access logging is typically opt-in. S3 server access logging, Azure Blob diagnostic logs, and GCS data access audit logs must each be explicitly configured. Buckets created before logging was established, including those spun up by automated tooling that skips the logging step, may have no log data at all for the period they were open.

Log retention is finite. Even when logging is enabled, logs are typically retained for a fixed period (often 30 to 90 days by default). A bucket that was open for two years but was discovered today will have at most 90 days of log coverage. Access during the rest of that window is invisible.

Unauthenticated requests look like authenticated ones. An anonymous GET request to an open bucket appears in server access logs with the same HTTP method and path as any other request. Without the authentication field populated, there's no obvious flag. Analysts scanning for "unusual" traffic may miss a steady trickle of anonymous enumeration that blends with application traffic.

Attackers may have obtained access without obvious volume. A targeted attacker looking for specific file patterns only downloads what they want. A 2 GB backup file disappearing into the public internet looks identical to a legitimate download in a server access log: the same GET request, the same 200 response, the same byte count. Unless the requester's IP is flagged by a threat intelligence feed, the event is invisible.

The posture is simple: if the bucket was open, assume the data is gone. Rotate every credential it held, notify whoever needs to know, and don't wait for a log line that was never written.

For a full index of publicly exposed AWS S3 buckets found by this service, see the AWS S3 exposure index. For Azure Blob Storage exposures, see the Azure Blob exposure index. To probe a specific bucket URL right now, use the open-bucket viewer.