Cloud Token Theft: How Attackers Steal SaaS and Cloud Access Without Stealing Passwords

Google Cloud’s H1 2026 Threat Horizons Report found identity compromise underpinned 83% of the cloud incidents it analyzed — and a growing share of that compromise isn’t password theft at all. It’s token theft: attackers stealing the credential that proves an already-authenticated session, bypassing the login step entirely.

What is a cloud access token?

A token is a credential that proves “this request is already authorized” without requiring the password or login flow to happen again. Several distinct types matter here:

• OAuth tokens — granted when a user authorizes a third-party app to act on their behalf (connecting a calendar app to your email, for instance), often with a defined scope and a longer lifetime than a typical session.
• Session tokens — issued after a successful login, proving to the service “this browser is already authenticated,” for as long as the session remains valid.
• Refresh tokens — longer-lived credentials used to silently obtain new session tokens without requiring the user to log in again.
• API keys — static credentials, often used for service-to-service or automated access, sometimes with no built-in expiry at all.

Password vs token: why this distinction matters

A stolen password requires an attacker to actually use it to log in — an event that, with MFA in place, the legitimate user or the organization has a real chance of noticing or blocking. A stolen token is different: it’s already past that checkpoint. Using it doesn’t trigger a login event, doesn’t prompt an MFA challenge, and in many systems looks identical to the legitimate user’s own normal activity.

How tokens get stolen

• From compromised endpoints. Malware or an attacker with device access can extract tokens stored in browser session data, application configuration, or memory — no credential-guessing required.
• Malicious OAuth applications. An attacker creates an app that requests OAuth access with a plausible-sounding permission request; a user who approves it (sometimes via a convincing phishing page mimicking a real authorization prompt) has effectively handed over scoped, often long-lived access without ever typing a password anywhere the attacker could intercept it.
• Cloud storage and CI/CD exposure. Tokens and API keys accidentally committed to repositories, logged in plaintext, or left in misconfigured storage are a persistent, low-sophistication source of theft. Google Cloud’s 2026 reporting specifically documents attackers using LLM tooling to automate credential harvesting and pivot from a compromised developer environment to full cloud administration access — in one documented case, by abusing the OpenID Connect trust relationship between a CI/CD provider and a cloud platform, achieving that escalation in under 72 hours.
• Vishing and social engineering. Google Cloud’s reporting also highlights a shift toward voice-based social engineering specifically to harvest credentials and tokens from third-party SaaS connections, enabling large-scale, often silent data exfiltration once obtained.

Detection: what to actually look for

• Session or token activity from unfamiliar locations or devices inconsistent with the user’s normal pattern — a stolen token used from somewhere the legitimate user has never connected from is a meaningful signal even without any password event to flag.
• OAuth applications granted broad or unusual scopes, especially ones approved outside a formal review process.
• API keys or tokens with no expiry, or expiry set far longer than the use case requires.
• Anomalous CI/CD pipeline activity, particularly around identity federation (OIDC) trust relationships — the escalation path Google Cloud documents specifically.

Defensive controls

• Token revocation capability, tested and ready to actually use, not just theoretically available — know in advance how to revoke a specific session or OAuth grant quickly.
• Conditional access policies, restricting where and under what device/location conditions a token can be used, so a stolen token used from an unexpected context is blocked even with valid credentials.
• MFA, still essential for the login event itself, even though it doesn’t directly address post-login token theft — the two controls address different stages of the same attack chain.
• Least-privilege token scoping, so any single token’s blast radius if stolen is bounded by what it actually needs, not broad standing access granted for convenience.
• Monitoring OAuth app approvals and CI/CD identity trust relationships specifically, given both are documented, current real-world escalation paths, not theoretical ones.

Key takeaways

Cloud token theft bypasses the login event entirely, which means defenses built purely around password strength and MFA at login — while still necessary — don’t address this specific, now-dominant pattern of cloud compromise. With identity compromise underlying the large majority of cloud incidents Google Cloud analyzed in 2026, conditional access, aggressive token scoping, and real (not theoretical) revocation capability matter as much as anything at the login screen.

Shahid Security’s Network & Cloud Security assessments include identity and token-scope review as a standard part of cloud security evaluation.

Know what OAuth apps and API tokens actually have access to your cloud environment right now? Book a free consultation if you’re not certain.

---

Sources: Google Cloud Threat Horizons Report, H1 2026.