Lateral Movement From Compromised SaaS Service Accounts

A compromised SaaS service account almost never marks the end of an incident. It marks the beginning of one, because service accounts carry OAuth tokens and API keys that keep working long after the initial break-in, letting an attacker move from app to app without ever sending a single packet across a network a firewall would notice. That distinction, network movement versus API movement, is the whole story. Everything below traces how it happens, where it's happened already, and why most security stacks never see it coming.

Why SaaS service accounts are structurally different from user accounts in a way attackers exploit

Service accounts aren't people. They're automation identities: CI/CD runners, reporting bots, data pipeline connectors, webhook handlers, the agents that let one SaaS product talk to another. That sounds like a small technical distinction. That distinction is not small, though it sounds that way.

A human account has a password, a login screen, and usually an MFA prompt standing between a credential and actual access. A service account has none of that friction built in. Present the token, get in, no challenge asked. There's also no such thing as "normal" behavior for a bot that runs 24/7, so the behavioral baselines security teams lean on for humans simply don't exist here. The account doesn't sleep, doesn't take vacation, doesn't have a manager who notices it's acting strange.

Add to that the way most of these accounts come into existence. A team needs to launch something fast, spins up a service account with broad access because nobody had time to figure out the minimum scope required, and that access never gets revisited. No owner, no review cycle, no complaint from a user when the permissions are too wide, because there's no user to complain. Access reviews are built around people; service accounts fall through the gap by design, not by accident.

Scale that pattern across an organization and the numbers get uncomfortable. It's a structural flaw baked into how the system was designed. It's a structural feature of how SaaS environments get built, and it needs a different way of thinking about identity, not a new scanner. The research finds that NHIs outnumber human identities by 25–50x in modern enterprises, and that ratio is accelerating as AI agent deployment scales in 2026 cyberdefensemagazine.com.

The Integration Graph as a Map of the Entire SaaS Estate from One Compromised Account

The scale of the problem is already large before an attacker even shows up. The average enterprise now runs 342 SaaS applications, and every one of those connections mints its own OAuth tokens, API keys, service accounts, and webhooks. Integrations grew 123% year over year as companies wired up more automation and AI tooling, and each new connection extends a circle of trust that traditional security controls were never built to watch Obsidian network data.

Once an attacker lands inside a single app, the next move is discovery: which other apps does this one talk to, what scopes do those connections carry, which API endpoints can be reached from here. The unsettling part is how this looks from the outside. It's all done through legitimate API calls, the same calls an admin would make, so nothing about it reads as an intrusion.

OAuth tokens make this worse because they function as bearer tokens. Whoever holds the token gets the access. No extra login, no MFA check, no re-authentication step. The token is the identity. That single design choice, made for convenience across almost every SaaS product on the market, is what turns one stolen credential into a passport for an entire integration graph.

Call it the hidden layer: everything happens at the API level between trusted SaaS applications, a space where EDR watches no endpoints, firewalls see no traffic, and SIEM has no behavioral context for what "normal" even means. Organizations know they have a problem here. 46% say they struggle to monitor non-human identities like service accounts and APIs, and 56% are worried specifically about over-privileged API access. Those two numbers together describe the blind spot precisely.

Shadow SaaS piles on top of all this. Employees connect third-party tools without asking IT, those tools inherit access to company data on the spot, and nobody's kept an inventory of what trust relationships now exist. The cruelest part of the whole setup: the attacker doesn't have to build a map of the environment. The organization already built it, documented it in OAuth consent records, and left it sitting there for anyone holding the right token to read.

The step-by-step mechanics of SaaS lateral movement, from first token to full breach

Break the attack into five stages and the mechanics stop feeling mysterious.

Stage one is initial access. In practice this means a phishing campaign that harvests OAuth consent or session tokens, infostealer malware planted on an employee's personal device capturing session tokens (the mechanism behind the Nikkei Slack breach, detected September 2025 and disclosed November 2025), or a help desk social engineering call that convinces a support agent to reset MFA on a high-value account, bypassing the authentication layer entirely cyberdefensemagazine.com.

Stage two is discovery. The attacker enumerates which downstream apps the compromised account holds OAuth tokens for, what scope those tokens carry (read, write, delete, admin), and whether any of the connected apps tie back to an identity provider like Okta, Azure AD, or Google Workspace.

Stage three is pivoting, and this is where bearer tokens presented without further verification really bite. Present the token, get access. No password prompt, no MFA, and critically, no new login event appears in the target application's own logs. From the target app's point of view, nothing happened.

Stage four is escalation, and it hinges entirely on which integrations happen to be over-permissioned. A marketing automation tool with read/write access into the CRM turns into a direct path to customer records. A reporting tool with admin rights spanning several SaaS platforms becomes a one-step privilege escalation. If any connected app has federated trust into an identity provider, compromising the IdP opens every downstream application tied to it at once.

Stage five is persistence, the part built to survive whatever incident response tries next. Attackers create new OAuth app authorizations that operate independently of the original compromised credential, so revoking that first credential doesn't actually close the door. Research from Obsidian found dwell time increases by as much as 80% when sessions aren't explicitly revoked during response, a gap that turns minutes into hours when the attacker already has a plan waiting obsidiansecurity.com.

And speed matters more than most response plans account for. CrowdStrike's 2026 Global Threat Report clocks the average interval between initial compromise and lateral movement at 29 minutes CrowdStrike 2026 Global Threat Report. Most security teams haven't finished reading the first alert by the time the pivot is already done.

Three real breach chains that show how this plays out at scale

Microsoft's Midnight Blizzard incident, running from late November 2023 through detection in January 2024, started with a password spray attack against a legacy test account tied to an OAuth application nobody had bothered to decommission. That test app carried permissions far broader than it needed, left over from a development phase and never scoped back down. Attackers used that access to spin up additional malicious OAuth applications, which they then used to reach production executive mailboxes. No malware. No network intrusion. No zero-day exploit anywhere in the chain. Just a forgotten account and tokens nobody was watching.

The Salesloft-Drift breach, running August 8 through 18, 2025, worked at a different scale entirely https://www.finra.org/rules-guidance/guidance/salesloft-drift-AI-supply-chain-attack. Google's Threat Intelligence Group identified widespread data theft against Salesforce customer instances, all routed through compromised OAuth tokens tied to the Salesloft-Drift integration. Attackers pivoted from Drift into more than 700 separate Salesforce instances using those stolen tokens obsidiansecurity.com cyberdefensemagazine.com.

The ShinyHunters campaign, running from around mid-2025 into mid-2026, combined two intrusion paths that both arrived through trust rather than brute force. Microsoft reports that the group used vishing to manipulate OAuth consent, alongside supply chain compromise through integrations including Salesloft and Gainsight. Targets again included Salesforce instances, with goals covering unauthorized access, data exfiltration, and persistence built on abused OAuth relationships. What stands out is that neither path involved stealing a password directly. Both rode in on relationships the target organization had already extended and trusted.

The "Payroll Pirates" campaign against Workday ran March through October 2025 cyberdefensemagazine.com. Phishing harvested credentials, attackers created inbox rules to hide the resulting notifications, then redirected payroll payments. Eleven compromised accounts across three universities sent phishing emails to nearly 6,000 accounts spanning 25 institutions cyberdefensemagazine.com. A tiny number of compromised accounts, propagated into an institution-wide problem. Obsidian research found the blast radius was 10x greater than previous incidents where attackers had infiltrated Salesforce directly, because the supply chain entry point bypassed all per-instance controls.

Why traditional security tools generate no signal for attacks that stay inside the API layer

Every layer of the standard security stack has a blind spot here, and it's the same blind spot repeated five different ways.

EDR watches endpoints and processes. SaaS lateral movement doesn't touch an endpoint at all, since the attacker is working through a browser or making direct API calls from cloud infrastructure. Network monitoring and NDR watch traffic patterns, but SaaS-to-SaaS connections ride ordinary HTTPS to vendor-managed clouds, so there's no unusual signature to catch. SIEM correlates authentication logs, but the attacker authenticated successfully. The log shows an authorized session, not an intrusion. CASB tools track cloud application usage at the traffic level, so they see that Salesforce got accessed, but not that the token used to get in belongs to a compromised integration.

MFA, the control everyone leans on hardest, does not stop an attacker once a session token is already in play. Obsidian's research found 65% of breached accounts in account takeover incidents already had MFA enabled at the time of compromise CrowdStrike 2026 Global Threat Report. Tokens don't ask for a second factor. They simply function without asking for a second factor.

The underlying issue is that IAM tooling was built to model users, subnets, and endpoint activity. None of that maps onto the relationships between connected applications, so the attack surface these tools were designed to watch simply isn't the attack surface being used. Midnight Blizzard makes the point better than any explanation could: no malware, no network intrusion, no login that looked unusual. Just tokens and trust, operating entirely within the boundaries every tool in the stack had been configured to accept as fine.

The volume behind all this isn't small. 83% of organizations report experiencing account takeover in the past year, with 26% facing attempts on a weekly basis obsidiansecurity.com. It's a routine, everyday event. It's a constant pressure against a spot nobody's watching.

Blast Radius of a Single Compromised Service Account

Modern SaaS platforms are, by design, concentrated stores of exactly the data an attacker wants. Salesforce holds customer records and revenue forecasts. Google Workspace holds internal strategic communication. Snowflake holds years of analytical business intelligence in one place. A single token with the right scope reaches all of it, through API calls that look completely ordinary.

The shape of the integration graph around the account that got popped first determines the size of the blast radius. It's the shape of the integration graph around it. A low-privilege marketing automation account might hold an OAuth token into a CRM with full admin write access, so the first account was just the doorway and the CRM token was the actual weapon.

A compromised service account can reach customer records and personal data through CRM and support platforms, financial data through ERP, billing, and payroll systems (the exact mechanism Payroll Pirates used against Workday), internal communications through email and Slack (as in the Nikkei breach), source code and deployment infrastructure if a CI/CD service account sits anywhere in the graph, and identity provider administration itself, if any connected app carries federated trust into Okta, Azure AD, or Google Workspace, at which point every downstream application tied to that provider becomes reachable in one move.

Salesloft-Drift remains the clearest proof that blast radius doesn't stop at an organization's own perimeter. Permission sprawl compounds all of it: most service accounts hold more access than their actual job requires, so the real blast radius of any given compromise tends to run well past whatever an access review would have predicted on paper. The Salesloft-Drift breach is the clearest evidence that blast radius is not bounded by organizational perimeter: 700+ downstream customer Salesforce instances were reached from one compromised integration, with Obsidian noting the blast radius was 10x greater than direct Salesforce compromises obsidiansecurity.com cyberdefensemagazine.com.

The specific vulnerability classes that enable or amplify SaaS service account compromise

Broken access control causes most of this, and it now ranks as the top category in the OWASP Top 10 for 2025. In multi-tenant SaaS specifically, a failure of tenant isolation means a compromised service account in one customer's environment can reach data belonging to a neighboring tenant, purely because the API authorization logic didn't check hard enough. Some applications compound the problem further by letting authenticated users escalate their own privileges through the API itself, no admin approval required.

Hardcoded secrets remain the single most common way a service account gets popped. API keys and OAuth client secrets get committed to code repositories, CI/CD configs, or internal documentation, and once they're in a repo's history, fixing it means revocation, rotation, and cleaning the commit history, all of it avoidable if the secret had never been committed at all. Attackers don't stumble onto these by luck. Scanning public and leaked repositories for exposed keys is a standard, systematic step in reconnaissance, not an opportunistic afterthought.

SSRF deserves a specific mention here too. Formerly its own category under OWASP A10:2021, it's now been folded into Broken Access Control in the 2025 revision, but the mechanism hasn't gotten any less dangerous. An attacker-controlled server-side request that reaches a cloud metadata service, AWS IMDSv1, GCP's metadata endpoint, or Azure IMDS, can return live instance credentials. Those credentials then become the pivot point into the surrounding cloud infrastructure. In a SaaS or cloud context, SSRF is a credential-harvesting mechanism that turns a routine application bug into a full identity compromise. It's a credential-harvesting mechanism that turns a routine application bug into a full identity compromise. BOLA / IDOR are APIs that trust the caller's claimed object ID without verifying ownership. An attacker with a valid service account token can enumerate and access records belonging to other tenants or users.