Your organisation runs 130+ SaaS applications. Most are connected to each other via OAuth tokens. Compromise one, and an attacker can pivot to all of them without ever touching your network.
Traditional security monitoring was built around the assumption that lateral movement leaves a network trace. If an attacker moves from one system to another, they must traverse the network, and the network is where you catch them.
That assumption is broken in 2026.
Cloud-native lateral movement via SaaS-to-SaaS OAuth token abuse lets attackers pivot from application to application using legitimate, pre-authorised access grants, with no corporate network traffic to monitor, no endpoint telemetry to capture, and no signature to match. A compromised GitHub service account can pivot to your cloud provider credentials. A weaponised Slack app can reach your cloud storage. A poisoned CI/CD bot can access your container registry and beyond.
And 97% of organisations reported at least one cloud-native security incident in the past 12 months.
This post maps the SaaS-to-SaaS attack chain, explains why traditional SIEM misses it entirely, and gives cloud security and SOC teams the specific detection and hardening controls that work.
What Is SaaS-to-SaaS OAuth Lateral Movement?
SaaS-to-SaaS OAuth lateral movement is an attack technique in which an adversary compromises one SaaS application’s service account or OAuth token, then uses the existing authorised OAuth grant relationships between that application and other connected SaaS platforms to access additional systems and data without new authentication steps.
OAuth (Open Authorisation) is the protocol that allows SaaS applications to act on behalf of users and other services. When your GitHub Actions CI/CD pipeline is authorised to push containers to your cloud provider registry, it holds an OAuth token representing that permission. If an attacker compromises the GitHub Actions service account, they inherit that OAuth permission and can act as the CI/CD pipeline across every connected system.
Why Your SaaS Estate Is a Lateral Movement Highway
The Scale of the OAuth Grant Problem
The average enterprise runs over 130 SaaS applications, each potentially connected to others via OAuth grants. These connections are often set up by individual teams for workflow automation and are not centrally inventoried by IT or security teams. Approximately 31% of cloud storage buckets remain publicly accessible, often connected to SaaS applications via OAuth, creating an exfiltration path that bypasses network-level monitoring entirely.
Shadow SaaS and Unapproved OAuth Grants
Shadow SaaS, applications approved and connected by employees without IT sanction, creates OAuth grant exposure that security teams cannot audit because they do not know the applications exist. A marketing team member connecting an unapproved analytics tool to Salesforce via OAuth creates a grant relationship that persists long after the employee has forgotten about it, and that an attacker can exploit.
Why Traditional SIEM Misses the Pivot
SIEM tools monitor network traffic, system logs, and endpoint events. A SaaS-to-SaaS OAuth pivot generates none of these signals on the corporate network. The attacker is using legitimate tokens to make legitimate API calls between cloud services. From the network’s perspective, nothing unusual is happening. From the SIEM’s perspective, there is nothing to alert on.
Google Cloud Threat Horizons H1 2026 documents this precisely: threat actors exploit misconfigured applications and use OAuth grants to move laterally across cloud services, deploying payloads in cloud compute instances within one hour of gaining initial access.
What Happens When Cloud Security Teams Don’t Address This
- Invisible data exfiltration: An attacker with access to one SaaS application via OAuth can access and exfiltrate data from every connected application without generating any endpoint or network alert
- CI/CD pipeline compromise: A compromised CI/CD service account with cloud provider OAuth grants can deploy malicious code to production infrastructure at the next automated pipeline run
- Persistent access through orphaned grants: OAuth grants for applications that have been deprovisioned often persist, providing continued access long after the legitimate application is gone
- Full SaaS estate exposure from a single initial compromise: The multiplier effect of OAuth grant chains means that a single compromised service account can provide access to dozens of connected applications
The SaaS-to-SaaS Attack Chain Mapped
| Step | What Happens | Why Traditional Security Misses It |
|---|---|---|
| 1. Initial compromise | Developer GitHub account compromised via credential stuffing | No network anomaly; login from known geographic area |
| 2. OAuth inventory | Attacker enumerates OAuth grants from GitHub account | Legitimate API calls; no signature to match |
| 3. Cloud provider pivot | CI/CD OAuth token used to access cloud provider registry | Looks like routine pipeline activity |
| 4. Storage access | Cloud provider OAuth grants used to access connected S3 buckets | Legitimate service-to-service access pattern |
| 5. Salesforce exfiltration | Storage OAuth grant provides Salesforce connection; CRM data accessed | No network traversal; no endpoint telemetry |
How Peris.ai Detects and Stops SaaS-to-SaaS Attacks
BimaRed: Mapping and Monitoring Your Entire OAuth Grant Exposure
You cannot defend what you cannot see. Peris.ai’s BimaRed performs continuous attack surface management across your entire SaaS estate, discovering connected applications, cataloguing OAuth grant relationships, and identifying shadow SaaS connections that are not in your approved application inventory.
BimaRed provides the OAuth grant visibility that security teams need before an attacker maps it for them. When a service account holds OAuth grants to ten connected applications, BimaRed surfaces that exposure, enabling the security team to review, restrict, and revoke grants that exceed least-privilege principles.
XDR: Cross-Layer Behavioural Detection Spanning Identity and Cloud
Peris.ai’s XDR correlates identity signals across cloud, SaaS, and endpoint layers to detect the behavioural patterns that OAuth pivot attacks create. While the pivot itself generates no network traffic, the downstream access it enables creates anomalous patterns: a CI/CD service account accessing production data at an unusual hour, a GitHub bot making Salesforce API calls it has never made before, or a cloud storage service account downloading data at 50 times its normal volume.
XDR cross-layer correlation is the detection mechanism that bridges the gap between the OAuth pivot (invisible to the network layer) and its operational consequences (visible as behavioural anomalies in identity and application telemetry).
BrahmaFusion: Automated OAuth Revocation and Containment
When BimaRed or XDR surfaces a suspicious OAuth usage pattern, Peris.ai’s BrahmaFusion agentic AI platform executes automated response playbooks: revoking suspicious OAuth grants, suspending compromised service accounts, triggering SaaS security audits, and alerting the cloud security team with full context for investigation. The automation layer ensures that an OAuth pivot detected at 2:00 AM is contained before the business day begins, without requiring an on-call analyst to manually revoke tokens across 130 connected applications.
Scenario: A CI/CD Compromise That Became a SaaS Estate Breach
A software company’s DevOps engineer is targeted by a credential stuffing attack against their GitHub account. The attacker gains access and immediately enumerates the OAuth grants held by the company’s GitHub Actions CI/CD pipeline: cloud provider registry access, cloud storage bucket read/write, and a Salesforce integration for automated deployment notifications.
Using these OAuth grants, the attacker copies 15,000 customer records from Salesforce via the automated integration, downloads production deployment artefacts from cloud storage, and pushes a malicious container image to the registry, all within two hours and without any corporate network traffic that the company’s SIEM would detect.
With BimaRed continuously auditing OAuth grants, the CI/CD pipeline’s Salesforce integration had already been flagged as exceeding least privilege (write access to customer records is not needed for deployment notifications). With XDR monitoring, the anomalous Salesforce API call volume triggers a cross-layer alert within minutes. BrahmaFusion revokes the suspicious OAuth grants before the malicious container image is pulled into production.
SaaS Security Benefits at a Glance
| Benefit | Outcome |
|---|---|
| BimaRed OAuth grant discovery | Full visibility of SaaS connections including shadow apps |
| XDR cross-layer behavioural detection | OAuth pivot patterns caught via identity and application anomalies |
| BrahmaFusion automated revocation | Suspicious grants revoked at machine speed, not analyst speed |
| Continuous attack surface monitoring | New OAuth grants reviewed before they become exploitable exposure |
Conclusion
The SaaS-to-SaaS attack surface is the security blind spot that most organisations have not fully mapped. With 130+ connected applications and OAuth grants established by individual teams without central oversight, the modern enterprise’s SaaS estate is a lateral movement highway that bypasses every network-centric security control you have.
Defending it requires a different approach: continuous OAuth grant visibility to know what is connected and what access is authorised, cross-layer behavioural detection to catch pivot patterns that network monitoring cannot see, and automated response to revoke access at the speed the threat moves.
Peris.ai’s platform, combining BimaRed attack surface management, XDR cross-layer detection, and BrahmaFusion automated response, is built for exactly the threat landscape that cloud-native organisations face in 2026.
Frequently Asked Questions
What is SaaS-to-SaaS OAuth lateral movement?
It is an attack technique where an adversary compromises one SaaS application’s service account or OAuth token, then uses existing OAuth grant relationships to pivot to connected SaaS platforms without new authentication, generating no corporate network traffic in the process.
Why can’t traditional SIEM detect SaaS-to-SaaS pivoting?
SIEM tools monitor network traffic and system logs. SaaS-to-SaaS OAuth pivoting happens via legitimate API calls between cloud services, with no corporate network traversal and no signature to match. The attack is invisible to network-centric monitoring.
What is shadow SaaS and why is it a security risk?
Shadow SaaS refers to applications connected by employees without IT approval. These unapproved applications create OAuth grant relationships that security teams cannot inventory or monitor, providing attackers with hidden pivot points.
How many SaaS applications does the average enterprise run?
The average enterprise runs over 130 SaaS applications, according to Productiv’s 2025 SaaS Trends Report, most of them connected to other applications via OAuth grants.
How does Peris.ai detect SaaS-to-SaaS OAuth attacks?
BimaRed maps the full OAuth grant landscape including shadow SaaS. XDR correlates identity and application telemetry to detect anomalous pivot patterns. BrahmaFusion automates OAuth revocation and service account suspension when suspicious activity is detected.
Leave a Reply