Skip to main content
NEW · Blast Radius: a field playbook for leaked API keys on AWS, GCP and Azure

Cremit Research · Incident Response Series

Blast Radius

A field playbook for investigating leaked API keys and cloud credentials across AWS, GCP, Azure and the secret stores behind them, and for proving how far they could reach.

34 pages · PDF · EN/KO · 2026-09-04

01
One key
02
One identity
03
Every role it can assume
04
Everything those roles reach: the blast radius

AudienceIncident responders, DevSecOps, platform & cloud security teams

Start here · Page 2

If a key just leaked, this page is the only one that matters.

Everything past this page is reference material you consult during and after the incident. This page is what you act on in the first five minutes.

01

Preserve evidence before you contain.

Screenshot or export the exposure and record the exact discovery time in UTC. Revocation destroys the evidence that tells you what the key could reach and whether anyone used it.

02

Establish the owning principal without authenticating.

The prefix and structure already tell you the provider, the credential class, and often the owning account, all of it offline.

03

Assume it was used.

A key exposed on the public internet can be exploited within one to five minutes. “We found no evidence of use” is an unfinished investigation, not an all-clear. In two of the three major clouds, secret reads are not even logged by default.

Reporting deadlines run from awareness

Most compliance regimes require notification within a fixed time of the moment you become aware, not the moment you understand. Under NIS2 the first filing is due in 24 hours.

The six phases this playbook is organised around

Every chapter maps to one phase. The running header tells you where you are.

  1. 01
    Identify
    What kind of credential is this, and whose is it?
  2. 02
    Scope exposure
    Where did it leak, and for exactly how long?
  3. 03
    Map blast radius
    Everything this credential could reach or become.
  4. 04
    Investigate use
    Did anyone use it, and what did they do?
  5. 05
    Contain & rotate
    Revoke in an order that does not break production.
  6. 06
    Prove closure
    Evidence that it is actually over.

Our own analysis, not a vendor statement

Three pages where we computed the answer instead of quoting one

Page 16

The quarantine policy protects AWS’s invoice, not your data.

When AWS finds your key in public it attaches AWSCompromisedKeyQuarantineV3. Diffing the three versions since 2020 shows the deny list growing from 28 to 99 actions, no action ever removed, and beyond S3 reads, not one of the twenty-one data-access actions we checked has ever been denied. sts:AssumeRole and secretsmanager:GetSecretValue still work.

Page 4

“Assume it was found” is arithmetic, not caution.

Model discovery as a Poisson process with rate λ; the chance of at least one discovery in a window W is 1 − e^(−λW). Four rates spanning four orders of magnitude disagree sharply for the first hour and agree completely after a month. Toyota was exposed for five years, Microsoft AI for three, Mercedes-Benz for three and a half months, xAI for two. Every one of them sits where all four rates return the same answer.

Pages 17, 25 and 33

On GCP the default answer to “was the secret read?” is unknown.

GCP splits audit logging into two classes with opposite defaults. Admin Activity is always on, free, 400 days. Data Access is off, billable, 30 days. Reading a secret is DATA_READ. Whether GCP Data Access logging is on, whether Key Vault has a diagnostic setting, whether your CloudTrail captures data events: no tool retroactively creates the evidence.

Contents

Every factual claim is listed against its primary source in Appendix C, page 32.

  1. 03The clock: exploitation speed and the regulatory deadline
  2. 04The arithmetic behind “assume it was found”
  3. 05Fifteen incidents that define it
  4. 06Six laws of leaked-credential response
  5. 07Provider comparison: same questions, three answers
  6. 08Master triage decision tree
  7. 09Key atlas: reading a credential offline
  8. 10Offline forensics: what the string alone tells you
  9. 11Attribution, validity testing, exposure window
  10. 12Exposure forensics: git, images, CI
  11. 13–16AWS: evidence, blast radius, hunting, containment
  12. 17–19GCP: the logging gap, impersonation chains, the 60-minute problem
  13. 20–22Azure: service principal logs, RBAC and Graph, the SAS problem
  14. 23The chain we actually see: GitHub to data exfiltration
  15. 24Secret sprawl: why the cleanup outgrows the intrusion
  16. 25–26Secret stores: second-order blast radius, rotation order
  17. 27SaaS keys: what each provider will and will not tell you
  18. 28–29Appendix A: evidence acquisition and collection runbook
  19. 30Appendix B: field reference, per provider
  20. 31Proving closure, and what to report
  21. 32Appendix C: primary sources, claim by claim
  22. 33From playbook to program
Newsletter

Monthly NHI research brief

Security engineers and CISOs read our monthly brief on Non-Human Identity attacks, controls, and field research.

We never share your email. Unsubscribe in one click.

From playbook to program

What the platform carries, and what stays yours

The incidents in this report are almost all failures of sustaining, not of knowing. Nothing in the previous thirty-two pages requires a vendor: an inventory, an owner, provider-accurate containment, and a ledger. Cremit Platform exists because those four are difficult to sustain by hand across every repository, bucket and workspace an engineering organisation touches.

Page 33 lists, phase by phase, what the platform does and what stays with your team.

On internal distribution

Use this as an internal runbook or as training material, unchanged. Keep the attribution when you lift a table or a figure. If you plan to adapt it, tell us and we will send you an editable original. ben@cremit.io