Hunting SaaS SSO Token Abuse

Hunting SaaS SSO Token Abuse

Overview

Adversaries increasingly bypass MFA not by defeating it but by stealing the artifacts issued after a successful authentication — session cookies, OAuth access/refresh tokens, and Primary Refresh Tokens (PRTs). With a stolen token an attacker replays the existing session ("pass-the-cookie" / token replay), inheriting the victim's authenticated state across federated SaaS without ever prompting for credentials or MFA. Mandiant's M-Trends reporting and Microsoft/Okta incident data both highlight token theft as a dominant cloud lateral-movement technique, mapped to MITRE ATT&CK T1550.001 Use Alternate Authentication Material: Application Access Token.

Detection relies on correlating identity telemetry rather than watching for failed logins. In Microsoft Entra ID the key tables are SigninLogs (interactive), AADNonInteractiveUserSignInLogs (where replayed cookies/refresh tokens commonly surface), and AADServicePrincipalSignInLogs. Entra now exposes linkable identifiers — SessionId and UniqueTokenIdentifier — that let a hunter stitch every artifact derived from one root authentication event together and spot a single session being used from multiple IPs, ASNs, or device fingerprints. In Okta the System Log carries authentication.sso, policy.evaluate_sign_on, and user.session.start events with a deviceToken/session context; the same session token appearing from divergent IPs/user-agents is the tell. Okta Identity Threat Protection (ITP) can natively flag "suspected session hijacking."

This skill provides a hypothesis-driven hunt: baseline normal session behavior, then look for impossible travel within a single session, refresh-token reuse, token use from anomalous infrastructure (hosting/VPS ASNs), and SaaS access patterns inconsistent with the user's device. Source: MITRE ATT&CK T1550.001; Microsoft Entra ID sign-in log documentation; Okta System Log reference; Mandiant M-Trends.

When to Use

• Threat hunting for MFA-bypass via stolen tokens/cookies across Entra ID and SaaS
• Investigating an alert for impossible travel, anomalous OAuth grant, or token reuse
• Validating detection coverage for T1550.001 after a phishing/AiTM incident
• Building Sentinel/Splunk/Okta detections for session-token replay
• Post-incident hunting to scope SaaS lateral movement from a compromised identity

Prerequisites

• Entra ID sign-in logs flowing to a queryable store (Microsoft Sentinel / Log Analytics):

  # Confirm the diagnostic settings export SigninLogs + non-interactive logs to a workspace
  az monitor diagnostic-settings list --resource \
    /providers/Microsoft.aadiam/diagnosticSettings -o table
  

• Okta System Log access via API or SIEM ingestion:

  curl -s -H "Authorization: SSWS $OKTA_API_TOKEN" \
    "https://<org>.okta.com/api/v1/logs?filter=eventType eq \"user.session.start\"&since=2026-06-01T00:00:00Z"
  

• An IP enrichment source (GeoIP + ASN/hosting-provider classification)
• Read access to the SIEM (KQL for Sentinel, SPL for Splunk)
• Python 3.9+ for the helper script (requests for the Okta API)

Objectives

• Baseline normal per-user session behavior (IPs, ASNs, devices, SaaS apps)
• Correlate Entra sign-in artifacts by SessionId / UniqueTokenIdentifier
• Detect a single session used from multiple IPs/ASNs (token replay)