Access Secrets with S3 Bucket Versioning

What this lab covers

You enumerate a web application, identify storage behind it, and discover that the current contents are not the whole picture. Retrieving an earlier version of an object turns a dead end into access.

The lesson generalises well beyond this lab. Versioning is a data protection feature that is often mandated for resilience or compliance, and enabling it quietly changes what deletion means. Teams enable it for backup reasons without considering the disclosure consequence.

No prior AWS experience is needed. If you have ever fixed a leaked secret by committing a corrected file or uploading a cleaned version, this lab explains why that was not enough.

How S3 versioning preserves deleted data

When versioning is enabled on a bucket, S3 never overwrites an object in place. Each write creates a new version with its own identifier, and the previous versions remain stored and retrievable. Deleting an object adds a delete marker rather than removing the data.

This means the ordinary view of a bucket shows only the current version of each object. Listing versions is a different operation, and it exposes the full history, including objects that appear deleted. An identity permitted to list and read versions sees considerably more than one permitted only to list objects.

The security consequence is that remediation by overwrite does not work. If a configuration file containing a credential is uploaded, then replaced with a sanitised copy, the original remains a first-class object with its own version identifier and is served on request.

How to detect this in your own environment

Treat version listing as a distinct signal. Requests that enumerate object versions rather than current objects are unusual for most applications, and an identity performing them without precedent is worth investigating.

This requires S3 data events to be enabled, which they are not by default. Without them you will see bucket-level management activity but not the object reads themselves, which is the same visibility gap that undermines most S3 investigations.

Where a bucket is public or broadly readable, server access logging or data events are the only way to know whether historical versions have been retrieved. Absence of evidence here is genuinely absence of evidence, not evidence of absence.

How to prevent it

Separate the permission to read current objects from the permission to read versions. Most applications need the former and almost none need the latter, yet policies frequently grant both because they are written at the bucket level with broad actions.

Rotate rather than overwrite. Any secret that has been stored in object storage should be treated as exposed for as long as any version of it exists, so rotation is the remediation and version cleanup is housekeeping.

Use lifecycle rules to expire non-current versions after a defined period. Versioning is valuable for recovery from accidental deletion, which is a short-horizon need, while indefinite retention mainly serves attackers.

Real-world context

The broader pattern of sensitive data in object storage is one of the most consistently reported cloud exposure categories, and versioning is a recurring aggravating factor because it defeats the intuitive fix. Teams who believe they have removed a file have often only added a delete marker.

The same behavior appears in incident response from the other side. Versioning is genuinely useful during ransomware recovery, because non-current versions may survive an attacker's encryption pass. It is a control with real defensive value that carries a disclosure cost if permissions are not scoped.

It maps to MITRE ATT&CK T1530 Data from Cloud Storage Object, and to T1552.001 Credentials In Files where the recovered version contains a secret.

Applying this at work

• Check which of your buckets have versioning enabled, then check whether any policy grants version-level read to identities that do not need it.
• Search your own buckets for non-current versions of configuration files, environment files and similar, and treat anything found as needing rotation.
• Add lifecycle rules to expire non-current versions on a defined schedule.
• Enable S3 data events on buckets holding sensitive data so version reads are visible at all.
• Update your leaked-secret runbook so that rotation, not file replacement, is the first step.

Frequently asked questions

Does deleting a file from a versioned S3 bucket remove it?

No. Deletion adds a delete marker and the previous versions remain stored and retrievable by anyone permitted to list and read versions. Permanent removal requires deleting the specific versions.

Is listing object versions different from listing a bucket?

Yes, it is a separate operation governed by a separate permission. An identity can be able to list current objects while being unable to enumerate their version history, and scoping these separately is the main control here.

Should I turn versioning off to avoid this?

Usually not. Versioning provides real protection against accidental deletion and ransomware. The safer approach is to scope version-level read permissions tightly and expire non-current versions with lifecycle rules.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS data exposure and privilege escalation paths in full, and is assessed hands-on in a live AWS account.