Use Case: Identity
Identity federation tampering
A new OIDC provider was added to the Azure Entra ID federation config at 11:23 PM. The provider domain was 3 days old. ManySignal had a P0 alert open before anyone used it for authentication.
The backdoor you can't remove by rotating credentials
Federation tampering is a persistence technique that survives password resets, MFA re-enrollment, and even account takeover remediation. Once an attacker adds a trust relationship pointing to their controlled identity provider, they can generate valid authentication tokens for any identity in your organization — indefinitely — until the federation configuration itself is revoked. This is what made the SolarWinds breach particularly persistent: removing the malware didn't remove the federation backdoor.
rule: federation_config_tampering
type: config_change + change_management
sources:
- microsoft_entra_audit_log
- okta_system_log
- aws_cloudtrail (CreateSAMLProvider, UpdateSAMLProvider)
- google_workspace_admin
trigger:
- event: [AddFederatedIdentityCredential, UpdateFederationSettings,
CreateSAMLProvider, PutRoleTrustPolicy (with external OIDC)]
- condition: actor NOT IN [known_idp_admins] OR change_time == after_hours
enrichments:
- itsm_correlation: jira, servicenow change_request
- new_idp_domain: domain_age, reputation, registration_country
- iac_attribution: terraform_run_id
- prior_federation_state: current_vs_previous_config_diff
mitre: T1484.002 (Domain Trust Modification), T1606.002 (SAML Tokens) MITRE ATT&CK mapping
Federation tampering FAQ
What is identity federation tampering?
Federation tampering is the modification of OIDC, SAML, or OAuth federation configurations to add a backdoor identity provider. An attacker who has admin access to an IdP configuration can add an external OIDC provider or SAML trust that they control, allowing any identity from their external IdP to authenticate as any user in your organization.
Has this technique been seen in real attacks?
Yes. The 2020 SolarWinds breach included manipulation of federation trusts. CISA issued guidance (AA21-008A) specifically about detecting federation tampering. In cloud environments, adding a federated identity to an IAM role trust policy is a form of this attack — the role trusts external identities as if they were internal.
How does ManySignal detect federation changes that appear legitimate?
ManySignal validates federation changes against a change management workflow: is there a ticket in ServiceNow or Jira that requested this federation change? Did an authorized admin make it during business hours from a known device? Was this part of an IaC terraform apply? Changes that fail all three checks are flagged regardless of the actor's apparent authorization.
What's the response time requirement for federation tampering?
Federation tampering is immediately exploitable — the attacker can start authenticating via the backdoor IdP as soon as the configuration is saved. ManySignal treats federation change detection as P0 (highest priority) with a target triage-to-action time of under 5 minutes.
Monitor federation configuration changes in real time
Any unauthorized trust relationship addition triggers a P0 alert with full change attribution.