Cloud Identity Federation Attacks: SAML Forgery, OAuth Abuse & Cross-Tenant Pivoting¶

Identity federation was designed to simplify access across organizational boundaries — SSO, B2B collaboration, cross-cloud workload authentication. But in 2026, federation trust relationships have become one of the most exploitable attack surfaces in cloud environments. A single compromised signing certificate can mint tokens for every federated application. A misconfigured OAuth consent flow grants persistent access that survives password resets. And cross-tenant trust turns one breach into many.

This post dissects four federation attack vectors through the lens of a fictional intrusion by the PHANTOM TRUST threat actor group, provides detection queries in KQL and SPL, and delivers a hardening checklist your team can implement immediately.

Why Identity Federation Is the New Attack Surface¶

Federation protocols — SAML 2.0, OAuth 2.0, OpenID Connect, and workload identity — are the invisible plumbing connecting every modern enterprise. A typical environment has 50+ federated SaaS apps, B2B guest access across tenants, multi-cloud workloads authenticating via federation, and CI/CD pipelines exchanging tokens with cloud providers. Each trust relationship is an implicit security boundary that endpoint and network controls cannot see.

For foundational cloud security concepts, see Chapter 20: Cloud Attack & Defense and Chapter 33: Identity & Access Security.

Attack Chain: Operation PHANTOM TRUST vs. GlobalReach Pharmaceuticals¶

The following fictional scenario illustrates how the PHANTOM TRUST threat actor compromised GlobalReach Pharmaceuticals (globalreach-pharma.example.com) by chaining multiple federation attack vectors.

Target environment:

Attack Vector 1: SAML Token Forgery (Golden SAML)¶

Golden SAML is the federation equivalent of a Golden Ticket. If an attacker obtains the token-signing certificate from an organization's IdP (typically AD FS), they can forge SAML assertions for any federated user — including privileged accounts — without ever authenticating.

How PHANTOM TRUST Executed It¶

PHANTOM TRUST compromised the AD FS server (adfs.globalreach-pharma.example.com, 10.50.10.15) via a vulnerable web application on the same network segment, establishing a reverse shell to 198.51.100.77. From there, the operator exported the token-signing certificate:

# Synthetic — attacker extracts AD FS DKM key from Active Directory
$key = (Get-ADObject -Filter 'ObjectClass -eq "contact"' `
    -SearchBase "CN=ADFS,CN=Microsoft,CN=Program Data,DC=globalreach-pharma,DC=example,DC=com" `
    -Properties thumbnailPhoto).thumbnailPhoto

With the signing certificate, PHANTOM TRUST forged SAML assertions for svc-cloudadmin@globalreach-pharma.example.com with the Global Administrator role — without triggering MFA or any IdP authentication event:

<!-- Synthetic SAML assertion fragment -->
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_SYNTH-a1b2c3d4-dead-beef-cafe-123456789abc" IssueInstant="2026-07-15T08:30:00Z">
  <saml:Issuer>http://adfs.globalreach-pharma.example.com/adfs/services/trust</saml:Issuer>
  <saml:Subject>
    <saml:NameID>svc-cloudadmin@globalreach-pharma.example.com</saml:NameID>
  </saml:Subject>
  <saml:AttributeStatement>
    <saml:Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role">
      <saml:AttributeValue>GlobalAdmin</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

SAML Forgery Detection¶

Golden SAML is difficult to detect because the forged token is cryptographically valid. Focus on:

• SAML assertions with no corresponding AD FS authentication event
• Token claims with unusual role assignments not present in legitimate IdP configurations
• Service account sign-ins from unexpected IP ranges

Attack Vector 2: OAuth Token Abuse¶

OAuth 2.0 flows are pervasive in cloud environments — application registrations, service principals, consent grants, and refresh tokens create an attack surface that persists well beyond initial compromise.

Technique A: Client Credential Theft¶

PHANTOM TRUST found an application secret for app-datapipeline (ID 11112222-3333-4444-5555-666677778888) hardcoded in a CI/CD pipeline config committed to an internal Git repository.

# Synthetic — attacker uses stolen client credentials
curl -X POST "https://login.microsoftonline.example.com/a1b2c3d4-e5f6-7890-abcd-ef1234567890/oauth2/v2.0/token" \
  -d "client_id=11112222-3333-4444-5555-666677778888" \
  -d "client_secret=REDACTED" \
  -d "scope=https://graph.microsoft.example.com/.default" \
  -d "grant_type=client_credentials"

The application had Mail.ReadWrite and Files.ReadWrite.All permissions — access to every mailbox and OneDrive without user interaction.

Technique B: Consent Phishing¶

PHANTOM TRUST registered a malicious app (GlobalReach-DocSync) in an attacker-controlled tenant and sent phishing emails with a consent URL requesting offline_access, Mail.Read, and User.Read.All.

Technique C: Refresh Token Replay¶

PHANTOM TRUST exfiltrated refresh tokens from browser stores on compromised workstations and replayed them from 203.0.113.42 to maintain persistent access — refresh tokens remain valid until explicitly revoked.

OAuth Abuse Detection¶

• Application consent events from non-admin users for high-privilege permissions
• Service principal sign-ins from unexpected IP addresses
• Refresh token usage with geographic or device anomalies

Attack Vector 3: Cross-Tenant Pivoting¶

GlobalReach maintained a B2B relationship with Meridian Research (meridian-research.example.com), granting guest users access to specific SharePoint sites. PHANTOM TRUST exploited this trust to pivot across tenant boundaries.

The Attack¶

1. Compromised a Meridian guest account (r.chen@meridian-research.example.com) with guest access to GlobalReach.
2. Enumerated resources via Graph API — discovering a SharePoint site with clinical trial data and overly permissive sharing.
3. Escalated by exploiting a Conditional Access policy that exempted guest users from device compliance.
4. Persisted by registering a backdoor application in GlobalReach's tenant using the compromised Global Admin token from the Golden SAML attack.

Cross-Tenant Detection¶

• Guest sign-ins from IPs not associated with the partner organization
• Guest users accessing resources outside their expected scope
• Application registrations initiated by guest accounts

Attack Vector 4: Workload Identity Federation Abuse¶

Modern multi-cloud architectures use workload identity federation to eliminate stored credentials. PHANTOM TRUST exploited these trust chains to pivot across GlobalReach's three cloud environments.

The Chain¶

Azure AD (compromised via Golden SAML)
    ↓ Federated trust
AWS IAM Role: arn:aws:iam::123456789012:role/AzureAD-DataLake-Access
    ↓ Cross-cloud workload identity
GCP Service Account: ml-pipeline@globalreach-ml.iam.gserviceaccount.example.com

Step 1: Using the forged Azure AD token, PHANTOM TRUST assumed the AWS IAM role AzureAD-DataLake-Access via sts:AssumeRoleWithWebIdentity. The role's trust policy accepted any token from GlobalReach's Azure AD tenant — it did not restrict by application ID or subject claim.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::123456789012:oidc-provider/sts.windows.example.com/a1b2c3d4-e5f6-7890-abcd-ef1234567890/"},
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {"StringEquals": {
      "sts.windows.example.com/a1b2c3d4-e5f6-7890-abcd-ef1234567890/:aud": "api://AzureAD-DataLake"
    }}
  }]
}

Note the missing sub condition — any identity in the tenant can assume this role.

Step 2: From AWS, PHANTOM TRUST leveraged GCP workload identity federation to obtain a GCP access token for the ML pipeline service account, accessing training data and model artifacts stored in Cloud Storage.

Workload Identity Detection¶

• AWS CloudTrail AssumeRoleWithWebIdentity events from unexpected token issuers or subjects
• GCP audit logs showing ExchangeToken operations from unfamiliar AWS accounts

For hands-on practice with cloud IAM exploitation chains, see Lab 17: Cloud IAM Escalation.

Detection & Hunting Queries¶

KQL — Golden SAML Detection¶

// SAML tokens with no corresponding AD FS authentication event
let saml_signins = SigninLogs
| where TimeGenerated > ago(24h)
| where AuthenticationProtocol == "samlV2" and ResultType == 0
| project CorrelationId, UserPrincipalName, IPAddress, TimeGenerated, AppDisplayName;
let adfs_events = ADFSSignInLogs
| where TimeGenerated > ago(24h) | project CorrelationId;
saml_signins
| join kind=leftanti adfs_events on CorrelationId
| where IPAddress !in ("10.50.10.0/24", "10.50.11.0/24")

KQL — Illicit OAuth Consent Grant¶

// Detect consent grants for high-privilege permissions by non-admin users
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Consent to application"
| extend InitiatedBy = tostring(InitiatedBy.user.userPrincipalName)
| extend PermissionsGranted = tostring(TargetResources[0].modifiedProperties)
| where PermissionsGranted has_any ("Mail.ReadWrite", "Files.ReadWrite.All",
    "User.ReadWrite.All", "Directory.ReadWrite.All", "RoleManagement.ReadWrite.Directory")
| where InitiatedBy !in ("admin@globalreach-pharma.example.com")
| project TimeGenerated, InitiatedBy, PermissionsGranted, CorrelationId

KQL — Cross-Tenant Guest Anomaly¶

SigninLogs
| where TimeGenerated > ago(24h) and UserType == "Guest" and ResultType == 0
| summarize DistinctIPs = dcount(IPAddress), IPs = make_set(IPAddress) by UserPrincipalName
| where DistinctIPs > 3

SPL — AWS Federated Role Assumption¶

index=aws_cloudtrail eventName=AssumeRoleWithWebIdentity
| stats count by sourceIPAddress, requestParameters.roleArn, userIdentity.principalId
| where NOT cidrmatch("10.0.0.0/8", sourceIPAddress) | sort -count

SPL — GCP Workload Identity Token Exchange¶

index=gcp_audit protoPayload.methodName="sts.googleapis.com.ExchangeToken"
| spath output=caller protoPayload.authenticationInfo.principalEmail
| spath output=src_ip protoPayload.requestMetadata.callerIp
| stats count by caller, src_ip | sort -count

For more detection queries mapped to MITRE ATT&CK, see the ATT&CK Technique Reference.

Hardening Checklist¶

SAML & Federation Infrastructure¶

• [ ] Store AD FS token-signing certificates in an HSM — never in software-based DPAPI storage
• [ ] Rotate token-signing certificates annually and after any suspected compromise
• [ ] Migrate to Managed Identities to eliminate AD FS dependency where possible
• [ ] Enable AD FS advanced auditing (Event IDs 501, 1007, 1200) and forward to SIEM
• [ ] Restrict AD FS server access to Tier 0 administrators only

OAuth & Application Security¶

• [ ] Disable user consent for applications — require admin approval for all consent grants
• [ ] Audit all application registrations and remove unnecessary permissions (least-privilege)
• [ ] Enforce credential expiration on app secrets (max 90 days), prefer certificate credentials
• [ ] Implement Continuous Access Evaluation (CAE) for near-real-time token revocation

Cross-Tenant & B2B Trust¶

• [ ] Restrict cross-tenant access policies to specific organizations and resources
• [ ] Apply Conditional Access to guest users — require MFA, compliant devices, named locations
• [ ] Audit guest accounts on a 90-day cycle and remove stale external identities

Workload Identity Federation¶

• [ ] Restrict IAM role trust policies to specific sub and aud claims — never trust an entire tenant
• [ ] Monitor cross-cloud authentication patterns and alert on deviations from baseline
• [ ] Use short-lived tokens (1 hour maximum) for all cross-cloud workload authentication

For comprehensive zero trust implementation guidance, see Chapter 39: Zero Trust Implementation.

Conclusion¶

The PHANTOM TRUST scenario demonstrates how a single compromise of federation infrastructure cascades across tenants, cloud providers, and organizational boundaries. Treat federation as Tier 0. Design detection for forged tokens, not just stolen credentials. Validate specific claims (sub, aud, azp) in every trust policy. Build federation-aware threat models into your SOC workflows — the queries and checklist above are your starting point.

Related Nexus SecOps Content:

• Chapter 20: Cloud Attack & Defense
• Chapter 33: Identity & Access Security
• Chapter 46: Cloud & Container Red Teaming
• Chapter 39: Zero Trust Implementation
• Lab 17: Cloud IAM Escalation
• ATT&CK Technique Reference