Stolen Cloud Credentials - How to Limit the Damage (2026)

If a stolen cloud credential is being abused right now, disable it first, kill what it already issued, then look for any access the attacker left in place. This article's reasoning is that once an attacker holds a credential, its permissions and spend access set the limits of what it can do. Recent incident reports show what that means for your data and your bill.

The Bottom Line

• Annual reports rank exploits first as the way in. Our narrower reasoning is that a held credential's permissions and spend access set the limits of what it can do.
• Todyl counted 27 organizations reached in an ongoing Entra campaign, and it calls its counts a floor.
• Wiz's list-price estimate for two Amazon Bedrock abuse cases tops $100,000 combined.
• If abuse is live, disable the credential first and accept the outage.
• AWS and Google billing controls lag real usage, so keep a faster way to stop a credential.

How far the Entra and LiteLLM credentials traveled

A credential here means any key, token, secret or certificate that lets a person or a workload act in your cloud. A workload is an application, pipeline or service running without a person at the keyboard.

The Entra campaign. Todyl's report, published November 3 and updated November 4, covers activity from November 1 to 3, 2026, UTC, from first access to last successful action. About 45 app registrations at roughly 18 organizations were targeted. An app registration is the identity an application uses to sign in to Microsoft Entra ID.

More than 33 of those registrations authenticated. Todyl counts 27 organizations reached, a higher number than the 18 targeted because reached includes downstream clients of managed service providers (MSPs).

Todyl found no Microsoft vulnerability involved in this campaign. The source of the credentials is unknown and the activity is unattributed. As of November 6, 2026, the investigation is ongoing, Todyl calls its numbers a floor, and the counts may change.

The LiteLLM key. LiteLLM's root cause report shows how long a credential can outlive its exposure. An admin key was committed on May 27, 2026 and removed about three hours later, yet it was still valid on October 10. That key exposed an organization owner's GitHub token, and a malicious release followed on October 21. Removing a key from code doesn't revoke it. Preventing secret leaks in repositories lowers the odds of that commit, but any key that does leak still needs revoking.

Rotate credentials before you have proof

Chainstack treated credentials as exposed without evidence they were read, and that precaution is worth copying. Its statement describes entry through an unnamed third-party component, so this isn't a stolen-credential case.

The statement places the attacker in a development environment on October 26 and in parts of production on October 29. It gives no mechanism for that move and no credential link, so we draw no lesson from the path. The precaution is the useful part: Chainstack has asked customers to rotate node credentials.

What the evidence does not show

Annual reports rank exploits first as the way in. Verizon's 2026 Data Breach Investigations Report says 31% of breaches start with vulnerability exploitation, ahead of stolen credentials for the first time in 19 years. M-Trends 2026 reports exploits at 32%, voice phishing at 11%, prior compromise at 10% and email phishing at 6%. This article doesn't quote a stolen-credential share.

Google's Threat Horizons report for the second half of 2025 compares two other categories. It puts software vulnerabilities at 44.5% of initial access and weak credentials at 27.2%. Weak credentials are a different category from stolen ones, so that figure isn't a theft rate. All of these reports study different populations, and their percentages can't be merged or ranked against each other.

The argument here is narrower, and it is our reasoning. Once an attacker holds a credential, its permissions and spend access set the limits of what it can do. AWS says policies determine whether each request is allowed or denied, and it recommends least privilege. AWS doesn't discuss attackers on those pages, so the link to a stolen key is ours.

Every aggregate figure in this article predates these incidents, so none of them measures those events. These cases come from security vendors and the affected companies. They show what can happen, but they can't tell you how often it happens.

Data exposure follows what the credential can reach

A credential's permissions create the first exposure, which is data. The 27 organizations in the Entra campaign include MSP downstream clients, so reach can cross company lines. LiteLLM's admin key exposed another credential, the GitHub token, so one key's reach can include the next key.

CrowdStrike's 2026 Global Threat Report puts average eCrime breakout time at 29 minutes in 2025. eCrime means financially motivated crime, and breakout time measures how long an intruder takes to move beyond the first foothold. The same report says cloud-conscious intrusions, meaning attacks aimed deliberately at cloud environments, rose 37%. Neither figure comes from the cases in this article.

Bill exposure follows what the credential can spend

Spend access creates the second exposure. A credential for a metered service can run up charges even if it never reads a customer record. Wiz's report, dated October 30, describes two cases of abuse on Amazon Bedrock, AWS's managed service for AI models.

Wiz estimates more than $100,000 for both cases combined at list price. It's only an estimate, and it doesn't show what either victim paid.

Case B's key was restricted to us.* profiles, meaning Bedrock's US-region routing options. Scoping a key limits where it works and sets no cap on spend.

Low-volume testing is the warning window. Wiz reports first validation within 30 minutes of the reported credential access. Case A then stayed quiet until bulk traffic began 22 seconds after quota enumeration, the step where an attacker checks how much capacity an account allows. Case B took seven days to reach a reseller pool, where access is sold on. Alert on unexplained calls from a quiet key through your real-time monitoring and alerting.

What to do in the first hour

Size the credential, stop it, then clean up in a fixed order. The sequence below is our synthesis of AWS, Microsoft, Google and NIST guidance. No vendor publishes this exact list, vendor advice differs, and the later steps will run past the first hour.

1. Size it in minutes. Work out what the credential can reach, as AWS advises for exposed keys. For Entra, Microsoft's playbook says to determine early which kind of app you have. A single-tenant app works only in your own directory, and a multitenant app can work in other organizations' directories too.
2. Stop the credential.
   • AWS: disable the key instead of deleting it, so you can restore it if an app breaks.
   • Entra: disable sign-ins to the app after weighing the business impact, per Microsoft's playbook.
   • Google: if abuse is live, disable now and accept the outage. Otherwise, Google's order for a compromised key is to create and deploy a new key, disable the old one to verify, then delete it. If a key was committed to a source repository, delete it in identity and access management (IAM) immediately.
3. Kill what it already minted.
   • AWS roles: revoke active sessions.
   • AWS users: rotating a user's key doesn't invalidate temporary credentials already issued, and those can stay valid from 900 seconds to 36 hours, with a 12-hour default. Attach a deny policy, a rule that blocks actions regardless of other grants, to stop credentials issued before a chosen time. It uses the aws:TokenIssueTime condition key, which appears only on requests signed with temporary credentials, so long-term credentials aren't affected. To block everything, attach AWSDenyAll, an AWS managed policy that denies all actions. Policy updates can take a few minutes.
   • AWS root: permissions can't be changed on temporary credentials created as root with GetSessionToken or GetFederationToken, the API calls that issue them. Our reading: treat everything they could reach as exposed until they expire, and rotate those secrets now.
   • Google: disable the service account or apply a deny policy, then wait at least 60 minutes. You can't revoke service account access tokens directly. For federated tokens, disable the pool or provider.
   • Entra: disable the service principal, an app's identity inside a directory, and watch for use until the token window closes. Our reading is that you should assume issued tokens keep working until expiry unless continuous access evaluation applies. Microsoft's playbook and remediation guidance cover disabling sign-in and removing credentials, but they don't say what to do about issued tokens. Default access token lifetime is random, 60 to 90 minutes and 75 on average, for registered APIs.
   • Entra with continuous access evaluation: check whether this feature, which lets services end access on set events, applies. For workload identities, tokens last up to 24 hours, and the revocation events are service principal disable, delete and high risk. It covers Microsoft Graph only and single-tenant service principals.
4. Hunt for persistence. Persistence is access an attacker sets up to survive losing the first credential. Look for new users, keys, roles and policies in AWS CloudTrail. On Google, look for new service account keys. In Entra audit logs, look for credential changes on application and service principal objects.
5. Rotate everything it could read. Microsoft's order starts with secrets directly read, then the rest of the exposed vaults, then secrets across exposed subscriptions. Treat reachable secrets as exposed, as Chainstack did with node credentials.
6. Remove or isolate attacker resources. Google's guidance covers this step. Look for new compute, keys, users and roles, because anything the attacker created can keep running after the credential dies.
7. Restore with a better credential. Move to roles or federation where you can. When an Entra credential must remain, Microsoft recommends x509 certificates, which prove identity with a private key instead of a shared secret.
8. Notify and close out. Use NIST SP 800-61 Rev. 3 as framing for the review. Todyl advises MSPs to check Partner Center and GDAP, Microsoft's delegated admin access for partners, and to notify customers.

Where the vendors disagree on order

Google says to deploy the new credential first and then revoke the old one, which avoids an outage. AWS and Microsoft disable first.

If abuse is live, our editorial line is to disable first and accept the outage. Wiz's Case B (about 13 hours, roughly 1.7 million calls) averaged roughly 130,000 calls an hour by simple division, so a slow, careful swap has a price. If you see no sign of live abuse, Google's order is a reasonable way to protect production. Let evidence of current use make that call.

How to limit the blast radius before it happens

Blast radius means how far one credential can reach, and you set it before any incident.

• Use short-lived credentials. AWS recommends temporary credentials for humans and workloads, including workloads outside AWS. Service control policies (SCPs) and resource control policies (RCPs) limit permissions, but they grant none.
• Federate workloads. Federation lets a workload prove its identity to a trusted provider instead of storing a long-lived secret. See the docs for Entra, Google and GitHub Actions, which issues tokens per job. Restrict those OpenID Connect (OIDC) trust relationships as part of your CI/CD pipeline security. Todyl saw a federated identity abused too, so federation moves trust without removing it.
• Lock down Google service account keys. Google advises disabling key creation by organization policy and setting the exposure response to DISABLE_KEY. Detection isn't guaranteed, so that setting can't be your only control.
• Govern Bedrock API keys. AWS gives an SCP approach for these keys. It also says short-term key creation isn't logged in CloudTrail, so a CloudTrail search won't show you every key.
• Check Entra Conditional Access scope. Workload policies need a Workload Identities Premium license and cover only single-tenant service principals. Multitenant apps, SaaS apps and managed identities are out of scope.
• Centralize secrets. CISA's April 2025 guidance, issued after a potential legacy Oracle Cloud compromise, says to replace embedded credentials with centralized secret management. It also says to monitor service and federated accounts.

Why bill controls act late

Billing tools report spend after it happens, so they can't stop fast abuse on their own. AWS Budgets updates up to three times a day, typically 8 to 12 hours apart. AWS warns that costs can pass your threshold before you get a notification.

Our own reading is that Wiz's Case B (about 13 hours, roughly 1.7 million calls) could fit inside one or two refresh cycles. Budget actions can apply an IAM policy or an SCP, but they inherit the same lag.

Google's spend caps have similar limits. They cover the Gemini API, Gemini Enterprise Agent Platform and Cloud Run. They work per project and per month, they aren't instant, and overages are still billed.

Keep these controls, because a late alarm beats none. Set them up with our AWS Budgets guide, then treat them as the backstop. We recommend a faster signal as well: usage, such as call counts per credential, watched by someone who can disable that credential.

What a CTO should decide this quarter

If permissions and spend access set a held credential's limits, as this article reasons, you can decide those limits before an incident. The questions below are our recommendations.

• Who can cause an outage to stop live abuse? Name the person and a deputy now.
• Which long-lived credentials stay? List them with an owner, a reason and a retirement date.
• What can each credential reach? Review permissions against least privilege, starting with admin keys and anything that can read other credentials.
• What can each credential spend? Rank credentials by the metered services they can call, and agree who gets the alert.
• Which vendors hold your keys? Inventory those keys, plus what each can reach and spend. Verizon says the third-party share of breaches rose 60%, to 48%, which supports the concern.
• What counts as exposed? Adopt one rule, that a reachable credential is an exposed credential, and write it into your runbook.

If you can only finish one item, start with the outage decision, because it needs no new tooling.

Talk through your credential exposure

If you'd like a second opinion on what your credentials can reach and spend, book a 30-minute call with a cloud architect.

The EaseCloud Team writes about cloud reliability, cost and security for technical and business leaders. See the team page and about EaseCloud. Sources were retrieved on November 6, 2026, and analysis of ours is labeled as such.