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.

What is the blast radius of a leaked key?

It is the set of resources and actions the credential could reach under its current permissions. Possible access is not proof of use: confirm the identity and grants with the issuer, then inspect the activity logs that were available.

34 pages · PDF · EN/KO · Published 2026-09-04 · Web exercise added 2026-10-07

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

Team exercise · No external requests

Can you close this key investigation?

Every record below is fictional. No real key or issuer request is needed. Separate what each observation establishes from what remains unknown.

09:00 UTC · Discovery
A masked AWS key was found at line 12 of example-app/config/example.env. The first commit time and exposure scope have not been investigated.
09:10 UTC · Verification
An issuer authentication check succeeded. The author is known, but the owning team and dependent services are not.
09:30 UTC · Ownership
The owning team assigned a responder and identified dependent services. Current permissions were collected, but permission-change history is missing.
10:00 UTC · Revocation and recheck
The issuer revoked the key and a follow-up authentication check failed. Data-access logs for the relevant period are unavailable.
  1. Can discovery time stand in for the start of exposure?
  2. Does a successful check establish that someone misused the key?
  3. Does revocation close the investigation into access scope and actual use?
Compare your reasoning
  • Discovery is an observation time. Use commit, deployment and sharing records to bound the exposure window, and retain unknown intervals.
  • Verification establishes that authentication worked at that time, not that misuse occurred. Record the author, confirmed owner and issuer identity separately.
  • Revocation and rechecking support that this key can no longer authenticate. They do not establish past use or termination of sessions already issued. Check issuer-specific session and token behavior alongside retained logs.
  • The defensible conclusion is: key revoked and rechecked; historical data access undetermined because evidence is missing. Do not report possible access under current permissions as proven historical impact.
Download the investigation worksheet (.md)

Record masked identifiers and evidence locations instead of raw secrets. Edit the worksheet locally; no upload is required.

This web exercise draws on playbook pages 11–12 (verification and exposure), 25–26 (secret stores and rotation order), and 28–31 (evidence and closure). The exercise is separate from the PDF.

See the response flow in the product

Start here · Page 2

If a key just leaked, start here.

The rest of the playbook is reference material for the investigation. Start these three actions in the first five minutes.

01

Capture the exposure and contain promptly.

Save the exposed location and discovery time in UTC. Collect available logs without delaying deactivation or rotation; those actions do not erase logs already retained by the provider.

02

Identify what the string can establish.

A prefix may identify the provider and credential class. Some structured credentials reveal account context, but the owner, validity and permissions usually need issuer-side records.

03

Treat public exposure as urgent.

Honeypot research observed some planted AWS keys used within minutes; that is not a clock for every credential. “No evidence of use” is not an all-clear. Check which relevant logs were enabled.

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

Monthly NHI research brief

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

We never sell your email. Unsubscribe anytime.

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