Bivens Security Consulting

Deconstructing SaaS Exploit Patterns and Lateral Movement

5 min read

Hypothesis & Introduction

As Endpoint Detection and Response (EDR) platforms mature, the barrier to entry for host-based exploitation continues to rise. In response, adversaries are shifting their focus away from traditional endpoint intrusion toward SaaS ecosystems.

Our hypothesis is simple: the complex web of implicit trust relationships, OAuth integrations, and API permissions in modern SaaS environments provides a path of least resistance for persistent access and lateral movement. Allowing attackers to compromise enterprise data without ever touching a managed endpoint or triggering traditional network alarms.

Technical Foundation

To understand SaaS exploitation, one must understand the foundation of modern cloud authorization: OAuth 2.0 and API-driven integrations.

In a SaaS-first enterprise, applications do not communicate using passwords. Instead, they leverage delegated authorization. When a SaaS application integrates with a core identity provider (like Entra ID or Okta) or another SaaS service, it is granted an Access Token and a Refresh Token.

sequenceDiagram
    autonumber
    actor A as Attacker
    actor V as Victim
    participant IdP as Identity Provider
    participant SaaS as Target SaaS
    
    A->>V: Send phishing link
    V->>IdP: Auth & approve consent
    IdP->>A: Deliver Auth Code
    A->>IdP: Request tokens
    A->>SaaS: Access API with Token

These tokens represent a cryptographically signed proof of authorization. Once issued, the application can query resources on behalf of the user or organization. If an attacker can intercept these tokens, trick a user into granting them, or compromise the API secrets of an integrated service, they bypass the traditional authentication boundary entirely—including Multi-Factor Authentication (MFA).

Theoretical Attack Vectors & Defenses

Instead of stealing credentials, the attacker registers a malicious enterprise application in a multi-tenant cloud tenant (e.g., Azure/Entra ID). The application requests broad permissions, such as Mail.Read, Notes.Read.All, or Files.ReadWrite.

  1. Delivery: The attacker sends a phishing email with a link prompting the victim to authorize a seemingly benign utility (e.g., a “Meeting Scheduler” or “Document Viewer”).
  2. Consent: The victim clicks the link, authenticates to their legitimate corporate portal, and is presented with a standard OAuth consent dialog.
  3. Execution: Once the victim clicks “Accept,” the identity provider redirects the authorization code to the attacker’s infrastructure.
  4. Impact: The attacker exchanges this code for access/refresh tokens. Even if the victim changes their password or has MFA enabled, the attacker maintains persistent API-level access to the victim’s inbox or files until the OAuth application registration is explicitly revoked.
  • Defensive Countermeasure: Disable user consent for applications requesting high-risk permissions. Implement an Admin Consent Workflow, requiring security or IT administrators to review and approve all third-party application requests.

Attack Path B: SaaS-to-SaaS Lateral Pivot

In an enterprise, a low-security SaaS application (e.g., a marketing email tool or a project management whiteboard) is frequently integrated with a high-security SaaS application (e.g., Salesforce, GitHub, or AWS).

  1. Compromise: The attacker compromises the low-tier SaaS application via credential stuffing, exploiting a vulnerability, or locating a exposed API key.
  2. Pivoting: Using the pre-established integration (which often possesses write permissions to sync customer records or push code), the attacker requests data from the high-security system.
  3. Exfiltration: The attacker exfiltrates proprietary code, customer lists, or financial data directly through the API, completely bypassing the victim’s endpoint security controls.
  • Defensive Countermeasure: Apply strict least-privilege scoping to all integrations. Treat every SaaS integration as an untrusted third party. Enforce API throttling, and monitor for anomalous data volumes originating from service principal accounts.

Deep Dive Analysis: Device Code Flow Phishing

Let us examine the mechanics of abusing the OAuth 2.0 Device Authorization Grant (RFC 8628), commonly known as the Device Code Flow. This flow is designed for input-constrained devices (like smart TVs or CLI tools) to authenticate.

An attacker can weaponize this flow by initiating an authentication request targeting a corporate tenant:

# Attacker requests a device and user code from the Identity Provider
curl -X POST https://login.microsoftonline.com/common/oauth2/v2.0/devicecode \
     -d "client_id=[Target_CLI_Client_ID]&scope=https://graph.microsoft.com/Mail.Read"

The server returns a payload:

{
  "user_code": "D3F5-G7H9",
  "device_code": "AQABAAEAAAD--DJKH9...",
  "verification_uri": "https://microsoft.com/devicelogin",
  "expires_in": 900,
  "interval": 5
}

The attacker presents the user_code and verification_uri to the victim via a targeted phish, claiming they need to authorize a device registration. Meanwhile, the attacker’s script polls the token endpoint:

# Attacker script polls for the authorization token
curl -X POST https://login.microsoftonline.com/common/oauth2/v2.0/token \
     -d "grant_type=urn:ietf:params:oauth:grant-type:device_code" \
     -d "client_id=[Target_CLI_Client_ID]" \
     -d "device_code=AQABAAEAAAD--DJKH9..."

As long as the victim has not completed the login, the endpoint returns authorization_pending. The instant the victim navigates to the URI, inputs the code, and completes MFA, the next poll request returns the access and refresh tokens:

{
  "token_type": "Bearer",
  "scope": "https://graph.microsoft.com/Mail.Read",
  "expires_in": 3599,
  "access_token": "eyJ0eXAiOiJKV1Qi...",
  "refresh_token": "MCw0N2RhNDY..."
}

The attacker now has full read access to the victim’s email. No malware was deployed, no credentials were typed into an attacker-controlled page, and no host security alerts were generated.

Implications & Future Research

SaaS exploit patterns highlight a critical gap in traditional security architectures. Organizations focusing all detection engineering efforts on host endpoints and internal network traffic are blind to API-driven lateral movement.

For offensive operators and red teams, SaaS-centric testing represents the frontier of adversary simulation. Future research must focus on:

  • Identifying undocumented trust pathways between enterprise platforms.
  • Automating the discovery of over-permissive OAuth tokens.
  • Evasion techniques that mimic legitimate, high-frequency SaaS API activity.

As enterprises continue their migration to the cloud, the battlefield moves with them. Securing the modern enterprise requires defending the APIs that stitch our virtual offices together.

Want to learn more about improving the security of your SaaS environment? Book a call.

Link back to the Blog and the Homepage.

Graph View