Federation is built on trust, which makes trust settings a high value target. T1484.002, Trust Modification, covers adding or changing trust relationships between domains and tenants to evade defenses or escalate privileges. It applies to Windows and identity providers.
How attackers use it
Trust details, such as whether identities are federated, allow authentication and authorization to apply between domains or tenants. If an adversary changes those details to include objects they control, they can sign in or forge credentials in ways that look legitimate.
MITRE gives several examples:
- In Active Directory, forging SAML tokens without compromising the existing signing certificate, by adding the adversary's own signing certificate to the trust.
- Converting an AD domain to a federated domain using AD FS, and altering claim issuance rules so any valid set of credentials logs in as a specified user.
- Adding a new federated identity provider to a tenant such as Okta or AWS IAM Identity Center, which may let the adversary authenticate as any user of the tenant.
- In AWS, creating a new identity provider for an organization to federate into all member accounts.
MITRE lists procedure examples that match: converting a domain to federated so any tenant user can authenticate, adding a federated identity provider to a victim's SSO tenant with automatic account linking turned on, and creating a federated domain in a victim's Entra tenant as a persistent backdoor.
How to detect it
MITRE describes two analytics.
For Active Directory, flag trust changes made with netdom, nltest or PowerShell. Relevant attributes include trust direction, trust type and trust attributes.
For cloud identity, flag the addition of a federated identity provider and the switch of a tenant domain from managed to federated authentication. Look for events from the API, PowerShell or admin portal, such as authentication settings changes on a domain, new federated identity provider entries, and use of the Update-MsolFederatedDomain cmdlet.
MITRE does not name log sources or event IDs. Make sure your identity provider's admin audit log is exported, and that new identity providers and domain federation changes raise alerts that someone must acknowledge.
How to reduce the risk
MITRE lists two mitigations.
- Privileged account management. Apply least privilege and protect administrative access to domain trusts and identity tenants.
- User account management. In cloud environments, limit permission to create new identity providers to accounts that need it. In AWS, consider service control policies to limit API calls such as CreateSAMLProvider and CreateOpenIDConnectProvider.
Click through it at your own pace, or open it full screen.
Check your own environment
- List federated domains and identity providers in each tenant and confirm an owner for each.
- List who holds the permission to add an identity provider. Cut it back.
- Check that your identity provider audit logs are retained and monitored.
- Review AWS organization policies for the identity provider API calls above.
Quick check
Why is a new federated identity provider dangerous?
It can let an adversary authenticate as any user managed by the tenant.
What AWS control does MITRE suggest?
Service control policies that limit API calls like CreateSAMLProvider and CreateOpenIDConnectProvider.
