Detecting Federation Trust and Added IdP Abuse

Federation lets a tenant accept sign-ins vouched for by an external identity provider. An attacker with sufficient privilege can register a domain they control as federated, or add an identity provider to Okta, and then sign in as any user in that domain. The change is rare and consequential, and both Entra and Okta log it clearly.

Signals at a Glance

Entra: Domains and Federation

The classic backdoor adds a domain, verifies it and converts it to federated authentication against an attacker-controlled IdP; AADInternals automates this. Look at the domain lifecycle operations together:

// Microsoft Sentinel (KQL) - domain and federation configuration changes
AuditLogs
| where OperationName in ("Set domain authentication", "Set federation settings on domain",
                          "Add unverified domain", "Verify domain", "Add verified domain",
                          "Remove verified domain", "Set DirSyncEnabled flag")
| extend Domain = tostring(TargetResources[0].displayName),
         Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)),
         ActorIp = tostring(InitiatedBy.user.ipAddress),
         Detail = tostring(TargetResources[0].modifiedProperties)
| project TimeGenerated, OperationName, Result, Domain, Actor, ActorIp, Detail
| order by TimeGenerated desc
// tune/validate: confirm operation names in your tenant; any result for an unexpected domain deserves review

• Maintain an inventory of federated domains and alert on any difference between it and the tenant’s actual configuration.
• A sign-in whose issuer is a newly federated domain, shortly after the change, is a near-certain compromise indicator.
• Review changes to cross-tenant access settings for inbound trust and automatic redemption, since these widen who can authenticate.

A periodic inventory catches changes that logging missed or that predate your retention window:

# PowerShell (Microsoft Graph) - list federated domains and their issuers for baseline comparison
Connect-MgGraph -Scopes "Domain.Read.All"
Get-MgDomain | Where-Object { $_.AuthenticationType -eq "Federated" } |
  ForEach-Object {
    $cfg = Get-MgDomainFederationConfiguration -DomainId $_.Id
    [pscustomobject]@{ Domain = $_.Id; Issuer = $cfg.IssuerUri; SigningCertificate = $cfg.SigningCertificate.Substring(0, 24) }
  }
# tune/validate: compare output to your approved list on a schedule and alert on any new row

Okta: Added Identity Providers

In Okta, the equivalent is an added inbound identity provider or a modified routing rule that lets an external IdP assert any user. Okta has documented attackers using this approach after gaining super administrator access. Query the lifecycle events for identity providers and routing rules:

# Splunk SPL - Okta identity provider and routing rule changes (validate event types in your System Log)
index=okta sourcetype="OktaIM2:log"
  (eventType="system.idp.lifecycle.create" OR eventType="system.idp.lifecycle.activate"
   OR eventType="system.idp.lifecycle.update" OR eventType="policy.rule.update")
| table _time eventType actor.alternateId client.ipAddress target{}.displayName outcome.result
| sort - _time

• Treat any new inbound IdP as a P1 until proven to be a planned integration.
• Alert on Okta administrator sign-ins that precede the change from a new device or network.