Leverage Writable S3 Bucket to Steal Admin Cookie

What this lab covers

You enumerate a web application, identify where its assets are served from, establish that the storage behind it accepts writes, and use that to reach a privileged user's session.

The chain crosses two disciplines deliberately. Cloud permissions decide whether you can write, and web application behavior decides what happens when you do, and neither team typically reviews the combination.

It suits web testers moving into cloud and cloud engineers who do not think of buckets as part of the application's trust boundary. No prior AWS experience is assumed.

How writable asset storage becomes session theft

Modern applications commonly serve static assets from object storage rather than the application server. The browser loads scripts and stylesheets from that origin and executes them with the same authority as anything else the page loads, because as far as the browser is concerned it is part of the site.

If the bucket permits writes from an unintended principal, an attacker can modify or add an asset the application references. The next visitor loads it normally, and the attacker's code runs in the context of their authenticated session.

Session cookies are the usual objective. A cookie accessible to JavaScript can be read and sent elsewhere, at which point the attacker can replay the session as that user without ever seeing their password or encountering multi-factor authentication, because the session already satisfies both.

How to detect this in your own environment

Alert on writes to asset buckets by anything other than your deployment pipeline. Asset storage has a very predictable write pattern, so an unexpected principal writing there is a clean, low-noise signal, but it requires S3 data events which are not on by default.

Monitor asset integrity. Comparing served assets against the artifacts your pipeline published detects modification regardless of how it happened, and it catches the case where the write itself was not logged.

On the application side, watch for authenticated sessions appearing from new addresses or user agents mid-session. Session replay is difficult to spot in a single request but visible as a discontinuity across a session's history.

How to prevent it

Separate read and write paths. The identity that serves assets to users needs read only, and only the deployment pipeline should hold write access. This one change removes most of the exposure and costs nothing operationally.

Set cookies as HttpOnly and Secure, with an appropriate SameSite value. HttpOnly means injected script cannot read the session cookie at all, which breaks this chain at the final step even if everything earlier succeeds.

Add subresource integrity for scripts where practical, and a content security policy that constrains which origins may supply executable content. Both turn a modified asset into a failed load rather than a compromise.

Real-world context

Compromise of asset delivery is a recurring pattern in web skimming, where attackers modify scripts loaded by e-commerce checkout pages to capture payment details. The mechanism is the same regardless of whether the modified asset lives in object storage or on a third-party service.

The broader lesson concerns implicit trust. Applications trust the origins they load code from, and those origins are frequently managed by different people, under different controls, from the application itself.

The pattern maps to MITRE ATT&CK T1539 Steal Web Session Cookie, T1185 Browser Session Hijacking and T1195.002 Compromise Software Supply Chain.

Applying this at work

• Identify every bucket that serves content loaded by your applications, and confirm write access is limited to your deployment pipeline.
• Check that session cookies carry HttpOnly, Secure and a sensible SameSite value.
• Enable S3 data events on asset buckets so writes are attributable.
• Add a content security policy limiting which origins can supply scripts.
• Consider integrity checking on assets served from storage your application does not directly control.

Frequently asked questions

Why is a writable asset bucket so serious?

Because the browser executes what it loads from that origin with the same authority as the application's own code. Write access to asset storage is effectively the ability to run script in every visitor's authenticated session.

Does HttpOnly actually stop cookie theft?

It stops JavaScript from reading the cookie, which breaks the most common theft path. It does not protect against attacks that use the session in the browser rather than exfiltrating the cookie, so it is a strong control rather than a complete one.

How do I detect modification of assets in S3?

Enable S3 data events so writes are recorded and attributable, and compare served assets against the artifacts your deployment pipeline published. The comparison catches modification even where the write itself was not captured.

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 attack paths from web exposure through to cloud compromise, and is assessed hands-on in a live AWS account.