One Key to Rule Them All: How a Single Leaked Secret Unlocks Your Entire Multi-Cloud

In October 2022, Toyota disclosed that a credential exposed on GitHub had been available for anyone to find — since 2017. Five years, five months, one access key. By the time it was rotated, the company estimated up to 296,000 customer records were potentially accessible. Nobody “hacked” Toyota in the cinematic sense: no zero-day, no memory-corruption exploit, no precision phishing kit. A contractor pushed source code containing a hard-coded key to a public GitHub repository, and the internet did the rest.

The uncomfortable truth from two decades of breach forensics: the cloud was a multiplier for that mistake. A leaked database password usually leaked one database. A leaked cloud credential unlocks an identity — and identities in the cloud can assume other identities, mint new ones, and hop across tenancy boundaries. One key, wielded patiently, becomes the whole kingdom.

This article walks the full chain the way an attacker does: where secrets actually leak, how a found key becomes a foothold, the IAM misconfigurations that turn footholds into root, the cross-cloud pivots that make “multi-cloud” a liability multiplier — and the architecture that survives. It’s the composite of the three failure-modes we keep finding in cloud security assessments: the exposed secret, the pivot-happy IAM design, and the multi-cloud blast radius that nobody mapped until the incident.

Where Cloud Secrets Actually Leak

Threat-intel teams that track credential exposure see the same channels, year after year:

1. Source control and its history

The classic. A developer hard-codes a key to unblock a deadline, commits, notices the mistake an hour later, and “removes” it with a force-push or a cleanup commit. It doesn’t matter: Git history is append-only, and the secret lives on in every clone and fork made in between. Toyota’s five-year exposure is the canonical case; GitGuardian’s annual monitoring has counted tens of millions of secrets in public commits, most still active after detection.

Forked or abandoned internal repos are equally dangerous — the “private” repo that went public when a company restructuring changed its plan, the mirror on a personal account, the mirrors picked up by code-search engines that index deeper than GitHub’s own search.

2. CI/CD pipeline logs and build artifacts

The modern workhorse of accidental disclosure. Pipelines that echo environment variables, print SDK exception stack traces (which happily include the resolved credential chain), or upload .env files as build artifacts. Unlike a public commit, a CI log is indexed by the company’s own log platform — readable by every developer, exfiltratable by anyone who compromises a single laptop.

3. Container images and IaC state

A Docker image is a stack of layers; a secret COPY’d into an intermediate layer is there forever, even if a later layer deletes the file — layers add, never subtract. TruffleHog-class scanners sweep public registries continuously, validating anything matching provider prefixes (AKIA…, GOOG…, plus PEM private keys) against live endpoints within minutes.

terraform.tfstate is the IaC twin: it stores secrets in plaintext by default. State backends — routinely S3 buckets with lax permissions — become a curated inventory of an organisation’s credentials, one terraform state pull away from ownership.

4. Endpoints, laptops, and dotfiles

Secrets scanning isn’t only about repos. Public storage buckets, debug endpoints, and developer laptops with ~/.aws/credentials and shell-history files are all in the attacker’s search pattern. Infostealer log markets make the contractor’s unmanaged laptop a first-class leak channel; the 2022 Uber breach began exactly this way — contractor credentials harvested from an infected device, then used against an internal system that lacked MFA.

From Found Key to Foothold: the Attacker’s First Hou

The minute a secret hits a public surface, the clock starts. The first hour follows a pattern consistent across incident reports:

Step 0 — Validation (minutes). Automated tooling validates the credential against the provider’s API without tripping MFA — sts get-caller-identity on AWS, token introspection on Azure and GCP. A 200 response with an account ID is the green light; the key is now inventory on someone’s list.

Step 1 — Low-and-slow recon. The attacker maps what the identity is and what it can do: which account, which permissions, which groups, which tags. CloudTrail and its equivalents record these calls — but only if you’re looking, and only if the identity’s activity has a baseline to deviate from.

Step 2 — Privilege escalation. The classic Rhino Security Labs research on AWS privilege escalation catalogued twenty-plus escalation paths requiring nothing exotic: iam:CreateAccessKey on another user, iam:PassRole plus ec2:RunInstances, lambda:UpdateFunctionCode on an existing function. A single over-assigned permission plus one API call turns a reader into an administrator.

Step 3 — Persistence. New access keys for a dormant user. A backdoor role whose trust policy accepts an external account. An EC2 instance profile reused on a brand-new instance. The original key matters less now; the attacker has minted better ones.

Insecure IAM: the Root of Cloud Security Failures

The exposed secret is the spark; insecure IAM is the gasoline. Three patterns cause most of the damage:

1. Wildcard permissions (“* on *“)

Still the single most common critical finding in cloud assessments. Developer convenience plus vague requirements equals Action: "*" on Resource: "*". Every escalation path in the previous section becomes a one-liner. Permission boundaries, session policies, and SCPs exist precisely to cap this — and are still rare on the estates we assess.

2. Trust relationships that assume too much

AssumeRole trust policies written with Principal: "*" and a single condition — or worse, none — convert every credential on the internet into a potential tenant. Cross-account trust “for the migration”, left in place for years, is a favorite pivot because cross-account API calls often land in a separate CloudTrail the victim never reviews.

3. No separation between human and machine identities

The contractor’s key that started the Toyota incident walked into production because nothing distinguished “credential a person typed” from “credential a workload uses”. When the same long-lived key works from any IP, any region, any SDK — you don’t have an identity model; you have a password with extra steps. Machine identities need their own isolated role-per-service design, and human access needs to be SSO-federated, phishing-resistant, and short-lived.

The unified fix for all three is the same discipline we preach for AI systems (see Prompt Injection Attacks Explained): assume the credential will leak, and design so the leak is survivable. Least privilege narrows what the attacker can do; short lifetimes shrink the window; isolation caps the blast radius.

The Cross-Cloud Pivot: Where Multi-Cloud Becomes a Liability

Here’s where “we use AWS and Azure and GCP” turns from resilience story into attack path. The pivots that actually work in the wild:

AWS → cross-account. Role trust chains (account A assumes role in B assumes role in C) that nobody has graphed since the migration project in 2021. Attackers enumerate these with the same IAM-read APIs defenders use; the difference is they read thetrust graph as a map.

AWS/Azure/GCP → the other clouds. Federation is the bridge. The OAuth app registration in Entra ID granted Directory.Read.All by a tired admin; the GCP workload-identity pool that trusts an AWS role ARN. Each federation link is a door between kingdoms, and most were installed for a project, not reviewed as a boundary.

Cloud → SaaS → Cloud. The pivot that bypasses your whole cloud IAM model: a leaked Slack token reaches a CI integration, which holds deployment credentials, which deploy code holding cloud keys. Identity sprawl doesn’t stop at the cloud perimeter; for the attacker, it’s one graph.

The defensive mirror of each pivot is boringly consistent:

How Do You Defend in Practice? (Numbered, Ruthlessly Prioritized)

1. Kill static keys first

You cannot leak what doesn’t exist. Workloads get OIDC-federated identity (GitHub Actions → AWS via sts:AssumeRoleWithWebIdentity, no stored secret at all). Humans get SSO + short-lived tokens via aws sso login / az login with PAM brokered access. Set an org policy alarms on any IAM user with an active access key older than 90 days — then drive that number to zero.

2. Scan everywhere, on a schedule

Pre-commit hooks for the fast feedback, but the real work is retrospective: full history scans of every repo (including forks and mirrors), registry image layer scans, CI log scanning, and secret-mapping of terraform.tfstate backends. Anything found gets rotated, not deleted — deleting a public secret doesn’t un-leak it.

3. Least privilege is a graph exercise, not a checkbox

Run IAM Access Analyzer (or equivalent) to find unused permissions and public/private cross-account trust; enforce permission boundaries that cap even administrator roles; and treat every trust relationship as an edge you must be able to explain. If your answer to “who can assume into prod?” is a shrug, the attacker will answer it for you.

4. Human ≠ machine, always

Machine identities: one role per service per environment, no sharing, credentials 100% brokered. Human identities: SSO-federated, phishing-resistant MFA, session lifetimes measured in hours, privileged access via PAM with justification. The Toyota key and the Uber contractor credential both lived in the gap this control closes.

5. Centralize cloud audit logs and alert on the boring anomalies

CloudTrail, Azure Activity, GCP Admin Activity — all to one SIEM, all with retention ≥ 1 year. The high-signal alerts for this attack class: API calls from new ASNs/regions for an identity, IAM recon bursts (ListRoles/GetPolicy at volume), creation of keys or roles for dormant entities, and Consistent-with-malware patterns like UpdateAssumeRolePolicy on a business-critical role.

6. Break the cross-cloud graph

Inventory every federation: OIDC apps, workload-identity pools, SAML trusts, service principals with cross-tenant permissions. Each one gets an owner, a review date, and scoped-down permissions. Default answer to “can we federate cloud A to cloud B for this tool?” is “not without a boundary policy”.

7. Rehearse the rotation

When a secret leaks, you don’t want to be drafting the runbook. Every secret class (workload, human, SaaS integration) needs a tested rotation path, and the largest estates rehearse quarterly. Rotation speed is the difference between incident and catastrophe: Toyota’s exposure window was measured in years because nobody had ever rehearsed this.

8. Make the pivot visible

Detection on identity sprawl: inventory of all identities (cloud + SaaS) refreshed continuously, alert on new OAuth grants, alert on federation config changes in any cloud. This is your only warning when Step 2 above starts, because it’s the last step that still uses the original key.

FAQ: One Leaked Secret

How fast do attackers find a newly exposed cloud key?

Independent measurements and vendor telemetry agree: single-digit minutes. GitHub-bound secrets get scanned within minutes of a push; autominers validate against provider APIs immediately. There is no such thing as “it was only public for an hour” — assume exposure equals compromise.

Is key rotation enough after a leak?

No. Rotation closes the original key’s window, but does nothing about persistence the attacker may have installed (new keys, backdoor roles, OAuth grants) or about the IAM weaknesses that allowed escalation. Treat a leaked key as an incident: rotate, audit what the key did in CloudTrail (and neighbors), hunt for persistence, and fix the permission gap.

What’s the single most dangerous IAM misconfiguration?

Wildcard permissions on wildcard resources, followed closely by permissive trust policies (Principal: "*" with weak or missing conditions). Either one converts a low-privilege leak into root-equivalent access with one API call.

How do I check if my organisation has leaked secrets?

Start with your source-control platform’s secret-scanning alerts (GitHub/GitLab have them built in), then run a full-history scan with gitleaks/trufflehog across all repos and mirrors, scan container registries, and check public buckets for statefiles and backups. Then check whether the found secrets are still valid — most are.

Does multi-cloud increase secret-exposure risk?

It multiplies the pivots. Each cloud has its own credential format, trust model, and audit log — while attackers treat the whole estate as one graph. Unless you deliberately federate with boundaries and centralize audit, three clouds means three uncorrelated blind spots.

Are short-lived credentials really worth the migration pain?

They’re the only control that’s survived contact with modern attack tooling. Static keys leak and are replayed; OIDC-federated workload identity and SSO-brokered human access remove the replayable artifact entirely. Every estate I’ve migrated called the pain a bargain in hindsight.

Key Takeaways

1. Assume every long-lived secret is already leaked. Toyota’s was public for five years; scanners find keys in minutes. Design for compromise, not for secrecy.
2. A cloud key is an identity, not a password. Identities escalate, pivot, and federate. Blast radius is set by IAM architecture, not by the secret’s strength.
3. Insecure IAM is the root cause; the leak is just the spark. Wildcard permissions and permissive trust turn every minor exposure into a root-equivalent compromise path.
4. Multi-cloud multiplies pivots. Federation links are doors between kingdoms — inventory them, scope them, and log both sides.
5. Short-lived credentials + least privilege + centralized audit logs is the control triad that consistently contains this attack class — everything else is garnish.

References

• Toyota access-key exposure disclosure coverage (GitHub, October 2022) — BleepingCompute
• Rhino Security Labs — AWS IAM Privilege Escalation: Methods and Mitigation (21 paths)
• GitGuardian — State of Secrets Sprawl report series (annual, public-commit monitoring)
• Uber 2022 incident reporting — contractor credential compromise; MFA gaps on internal systems
• AWS documentation — IAM Access Analyzer, permission boundaries, service control policies
• Spencer Gietzen / Rhino Security Labs — Pacu (AWS post-exploitation framework) documentation