Cloud administrator from a single workstation
Cloud SaaS
A company running entirely in the cloud asked us to assume the worst realistic starting point: one developer workstation compromised, and nothing else. The question was how far that single machine reached.
Cloud & Kubernetes security, Cloud SaaS platform, severity CRITICAL, reported 2025
At a glance
- Challenge. A workstation held long-lived cloud keys in plaintext, and the identity behind them could attach a privileged role to new compute.
- Approach. We started from the workstation as a thief would and enumerated the identity's permissions before touching any data.
- Result. Long-lived keys gave way to short-lived credentials, the role-passing path was removed and permissions reduced, then retested.
- Impact. One stolen developer workstation could be escalated to cloud administrator, reaching private storage, the production database and service keys.
- Classification. CWE-269 Improper Privilege Management, MITRE ATT&CK: T1078.004 Valid Accounts: Cloud Accounts. Component: Developer cloud IAM identity.
The challenge
Cloud compromise is rarely an exploit. It is configuration read at face value. The workstation held long-lived access keys in plaintext, and the identity behind those keys carried permissions well beyond the developer’s actual work, including the ability to attach a privileged role to new compute.
That last permission is the one that matters. The ability to pass a role means the difference between the access you were granted and the access you can grant yourself is a single legitimate operation. Nothing has to be broken. The escalation is the platform doing exactly what the policy permits, which is why it survives review: every individual grant has a plausible reason, and no reviewer is looking at the reachable union of all of them.
From administrator, the rest is inventory. Storage that should have been private. Secrets that unlock the production database. Environment values holding keys to payment, messaging and third-party services. Each is a door that a real attacker walks through in order; we mapped them and opened none.
Our approach
We started from the workstation exactly as an attacker who had stolen it would, and enumerated identity before touching data, because the shape of what an identity can reach determines everything that follows.
- Inventory the credentials the machine held, and what each one authenticated to
- Map the identity’s effective permissions, and specifically any route to escalate through role-passing
- Identify storage and secrets reachable at each privilege level, distinguishing intended access from incidental
- Confirm reach into the workload layer without disturbing running services
We documented access rather than extracting data. Counting a table is proof; copying it is harm, and the engagement needed only the first.
From finding to fix
- Assumed one compromised workstation
- Inventoried its cloud credentials
- Escalated to cloud administrator
- Cut long-lived keys, retested
The outcome
Long-lived keys were replaced with short-lived credentials and access reviews, the escalation path through role-passing was removed, and public exposure on the reachable storage was closed at the account level. The permission set was reduced to the developer’s actual function, so a repeat of the starting position no longer reaches administrator.
We retested the escalation path and the storage exposure after the fix. Reported as CRITICAL in 2025. Retest included in the engagement.
Check your own system
- Replace long-lived access keys with short-lived credentials so a stolen key expires on its own.
- Remove the ability to pass a privileged role to new compute unless the identity genuinely needs it.
- Review each identity's effective permissions against its actual function, not grant by grant.
- Close public exposure on storage at the account level, and keep secrets out of plaintext on disk.
Read more case studies, see Cloud & Kubernetes Security, or tell us about your system on the contact page.