How it works
Long-lived secrets are copied somewhere they should not be and then used through legitimate APIs; access policies or inherited permissions expose stored records; or seemingly limited rights allow attaching roles, editing policies, passing identities or minting new credentials.
There is no perimeter to breach
Cloud compromise rarely involves exploiting anything. The control plane is a public API that accepts valid credentials from anywhere, so an attacker holding a key is not breaking in — they are signing in, and the requests are indistinguishable from legitimate ones except by context.
This reframes the whole problem. Network controls are largely irrelevant to an API call made from the attacker's own machine. What matters is which identities exist, what they can do, how long their credentials live, and whether anyone would notice them being used from somewhere new.
It also explains why cloud incidents escalate so quickly. On-premises, an attacker with one credential still has to move laterally; in cloud, a single sufficiently-permissioned identity may already reach everything, with no movement required.
Where keys leak
Long-lived access keys are the recurring root cause, and they leak through ordinary developer workflow rather than through attack.
- Committed to source control — including private repositories, which become public on a permission change or a fork.
- Baked into container images, where they persist in layers even after being removed in a later one.
- Written into CI configuration, logs or build output that is retained and widely readable.
- Pasted into support tickets, chat channels and documentation.
- Left in environment files on developer machines, where an infostealer finds them.
- Retrieved from instance metadata through an SSRF vulnerability in an application.
Why rotation is the wrong control
Scheduled key rotation is widely mandated and does very little against this. A key leaked on Monday is used within minutes; rotating it ninety days later closes a door the attacker walked through and no longer needs.
The controls that work are eliminating long-lived keys where possible — workload identity issues short-lived credentials automatically and there is nothing durable to leak — and detecting leaks continuously so revocation happens in minutes rather than at the next rotation window.
Where a long-lived key is unavoidable, scope it hard and constrain it: least privilege, and where supported, restrict the networks it may be used from so a leaked key is unusable off-estate.
Storage exposure is a default, not an accident
Public storage exposure is usually described as misconfiguration, which implies someone made an unusual mistake. In practice it results from ordinary decisions: a bucket made readable to make an integration work, an inherited policy nobody re-read, or a permission granted for a migration and never withdrawn.
The reliable control is organisational rather than per-resource. Blocking public access at the account or organisation level means an individual bucket cannot be exposed even if someone sets a permissive policy on it — the guardrail holds regardless of who is right about the individual case.
Beyond that, classification is what makes the exposure survivable: knowing which stores hold personal or regulated data determines whether an exposure is an inconvenience or a notifiable breach, and that is a question best answered before it is asked urgently.
Escalation through permissions that look harmless
The subtlest cloud risk is that permissions compose. Individually reasonable grants combine into paths that grant far more than any one of them suggests.
The recurring patterns: the ability to attach a policy to a principal you control, to pass a more privileged role to a service you can invoke, to create credentials for another identity, or to update the code of a function that already runs as something powerful. None reads as administrative; each is a route to becoming administrative.
Reviewing intended permissions will not find these, because each grant was intended. What finds them is analysing the effective graph — what every identity can ultimately reach through any sequence of permitted actions — and explicitly denying the combinations that close an escalation loop.
Also known as
What defenders may observe
- API calls from new networks, regions or user agents
- Secret scanning finds committed keys
- Resources created outside deployment workflows
- Anonymous reads or bucket listing activity
- Policy changes making storage public
- Role or policy edits, new access keys, or identity impersonation outside pipelines
Prevention and mitigation
- Use short-lived workload identity instead of long-lived keys
- Scan for committed secrets continuously and revoke on detection, not on rotation schedule
- Block public access at the organisation level so a per-bucket mistake cannot expose data
- Deny the permission combinations that permit self-escalation
- Grant privileged access just in time rather than standing
- Review the effective permission graph, not the intended one
Initial response priorities
- Freeze unauthorized control-plane changes and rotate credentials.
- Trace the affected artifact, pipeline or trust relationship.
- Rebuild from verified sources and review downstream exposure.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.