Identity Federation & Trust-Root Compromise

After this chapter you will be able to read a cloud trust policy the way an attacker does, recognise the four ways a federation relationship can be abused across AWS, Azure and GCP, and explain why a flaw at a trust root becomes a skeleton key that crosses every boundary the federation was built to span.

The problem

Identity and Access Management — IAM — is the part of a cloud that decides, on every single API call, who you are and what you are allowed to do. It is the gatekeeper of the entire control plane, the subsystem that turns a request into either an action or an AccessDenied. The first half of that question — who you are — is rarely answered by the cloud alone. It is answered by federation.

Federation is the arrangement by which a cloud agrees to trust identities minted somewhere else: your corporate directory, a CI/CD system like GitHub Actions, a partner's tenant, or even another product from the same vendor. The cloud does not run the directory or issue the login; it merely accepts a signed token and treats whoever the token names as one of its own. That arrangement is configured as data — an identity-provider object plus a rule — and data can be misconfigured, or forged.

What goes wrong is rarely a broken cryptographic primitive or a buffer overflow. It is something subtler. A federation relationship reduces, underneath all the protocol grammar, to a single trust equation: a token signed by key K, satisfying condition C, is granted role R. Every federation flaw is a defect in one of those three terms — the condition C is missing or too loose, the key K is forgeable or stealable, or the validator that checks the equation is itself buggy. The trust the equation expresses is the whole attack surface.

And federation is built to cross boundaries. Its entire purpose is to collapse several identity systems into one trust root so a user signs in once and reaches everything. Compromise that root and you inherit the same property in reverse: one forged token crosses every boundary the federation was built to bridge. That is why this chapter treats trust roots, not in-tenant permission lists, as the centre of gravity.

Why this differs from a traditional pentest

A traditional pentest — and a single-tenant cloud pentest — escalates inside one account, and the blast radius is that one account. A federation flaw is a different kind of bug: it does not climb a privilege ladder, it hands you a valid identity at the trust root, and that identity is honoured by every system the federation bridges — every account, tenant and product downstream. It crosses boundaries by design; the forged token authenticates through the front door, so there is little to alert on; and when the flaw is in the IAM platform's own validator rather than a customer's configuration, no customer can be blamed and every tenant is exposed at once. Single-tenant pentesting never reaches that class.

You arrive holding Chapter 2's map: you have enumerated identities, roles and trust relationships in the target. Before the climb, one skill has to be in your bones — reading a trust policy.

Reading a trust policy as an attacker

A cloud expresses "who is allowed to become or use this thing" in a trust policy (AWS calls it a resource policy; on an IAM role it is a separate document, the AssumeRolePolicyDocument). Unlike a permission policy, a trust policy grants no actions at all — it answers only the identity question. But before reading one, you need a concrete picture of where it lives and who writes it — because that picture is exactly what the rest of the chapter exploits.

Take an ordinary situation. A company owns an AWS account and runs its CI/CD on GitHub Actions. It wants that pipeline to deploy into the account — but it does not want a long-lived AWS access key stored in GitHub, where a single leak would be catastrophic. So it sets up federation, and it does the entire setup on its own side, inside its own AWS account:

1. It registers GitHub as an OIDC identity provider — an IAM identity-provider object that records "tokens issued by token.actions.githubusercontent.com come from an issuer we recognise."
2. It creates an IAM role holding the permissions the pipeline needs, and attaches a trust policy to that role saying which GitHub tokens are allowed to assume it.

Notice who does what. The AWS account owner — the company — performs every step above and writes the trust policy; the external party never "logs in to AWS" and configures nothing on the AWS side. The external party (here GitHub) does exactly one thing: when a workflow runs, it mints and signs a short-lived token naming the repository that ran. That external party is often a third-party vendor like GitHub, but it can equally be the company's own corporate directory (ADFS, Okta, Entra) or another cloud — anything that issues identities the cloud's own IAM did not. The trust policy is the company's standing instruction for which of those externally-minted tokens to honour. Here is a correctly written, fully scoped trust policy for that role — the standard the rest of this chapter will show attackers departing from:

Hover (or tap) each numbered marker for a line-by-line explanation.

Read it against the story. The document is attached to the company's role — that role is the equation's R. Principal names the external party: in arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com, account 111122223333 is the company's own account, and the rest identifies the GitHub OIDC-provider object it registered in step 1 — this is the key K, the issuer whose signature will be trusted. Condition is term C, the scope — and here it does its job: the sub line pins the trust to one repository on one branch, so only the company's own pipeline qualifies. And the attacker is a fourth party: someone at neither the company nor GitHub, who either holds a GitHub-signed token from their own repository, or — far more commonly — finds a copy of this policy where that scoping sub line was never written. The whole of this chapter is what happens when this document is wrong.

So three fields carry the weight. Effect is Allow or Deny. The keyword "Federated" inside Principal is the tell that the trusted party is an external identity provider rather than an AWS account. And the Condition is where the security actually lives. An OIDC token carries claims — among them aud (the audience: which service the token was minted for) and sub (the subject: which repository or workload the token represents). The policy above is correctly scoped: it checks aud and, decisively, sub — the claim that pins the trust to one specific repository. A federation flaw is what you get when this document is written wrong; the most common mistake is a Condition that omits the sub line and so accepts any validly signed token. T1 takes exactly that mistake apart.

The methods at a glance

Every technique in this chapter is an attack on one of the three terms of the trust equation. There are four to learn; they are transferable across AWS, Azure and GCP, and a federation feature launched next year will fall into one of them.

The next four sections take one technique each — what it is, how it works, and a real-world illustration.

T1 — Missing-condition federation: GitHub OIDC any-repo assumption

What it is. The most common federation flaw in modern cloud estates is a trust policy that omits its Condition — or whose condition checks only a value every token already carries. The relationship is genuine; it is simply scoped to everyone.

How it works. The textbook case is GitHub-Actions-to-AWS OIDC, the keyless way for a CI pipeline to obtain AWS credentials. You saw a correctly written version in the previous section — its Condition pinned the sub claim to one repository. The vulnerable version is almost identical; here is the Condition as attackers routinely find it:

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  }
}

Set this side by side with the correct policy and the entire vulnerability is one missing line — the sub condition is simply gone. What remains, aud, only proves the token was minted for AWS STS, and every GitHub repository's OIDC token carries that same audience. So the trust policy now says, in effect, "any validly signed GitHub OIDC token is welcome" — meaning any GitHub repository on the internet can assume the role. Term C of the trust equation has collapsed to "true."

Real-world illustration. The same shape recurs wherever a cloud trusts an external IdP and the operator forgets to scope it: an Azure workload-identity federation that names an issuer but no subject, a SAML role whose only condition is the IdP name. Whenever you see a Federated principal, your first move is to read the Condition — and an absent one is an open door.

T2 — Forgeable-key federation: Golden SAML

What it is. A deeper failure than a missing condition is a compromised key K. If an attacker can sign tokens with the identity provider's own key, no condition saves the relationship — every token they mint is, by definition, valid. The validator is doing its job perfectly; it is just being shown genuine forgeries.

How it works. A SAML service provider — AWS, vSphere, an Azure app — trusts any assertion bearing a valid signature from the IdP's token-signing private key. Steal that key and you can author assertions naming any user with any role.

Real-world illustration. Golden SAML is a control-plane intrusion technique, not a one-account trick: a single stolen ADFS key signs assertions for every service provider that trusts that IdP — AWS, Microsoft 365, internal apps — so one key compromise crosses the entire federation in one move. It was a documented component of large supply-chain intrusions where attackers forged their way into cloud tenants without ever touching a password.

T3 — Federation backdooring: adding your own trust root

What it is. T2 steals an existing key. T3 is subtler and quieter: rather than steal key K, the attacker adds a new one — a fresh credential on a trusted identity, or an entirely new federated domain — so the tenant now trusts something the attacker controls. It is failure mode 2 achieved without breaking any cryptography, just by writing configuration.

How it works. In Entra, a service principal with the right Microsoft Graph permission can do two backdoor moves. First, add a keyCredential (a client secret or certificate) to a privileged service principal and then authenticate as that application. Second — more powerful — add a brand-new federated domain to the tenant: its own trust root, its own signing certificate, after which the attacker can forge SAML tokens for any synced user, including Global Admins.

Real-world illustration. The rogue-federated-domain variant is a favourite for durable persistence: once the attacker's own signing certificate is registered as a trusted domain, they can forge a token for any user at will, indefinitely, with nothing stored in the victim's normal credential surface to rotate away. It is the federation equivalent of the cross-account backdoor — access that survives password resets and key rotations because the trust itself was rewritten.

T4 — Cross-product federation abuse: Workspace domain-wide delegation

What it is. Federation does not only bridge an external directory to a cloud — it can bridge one product to another inside the same vendor. When it does, a modest permission in product A becomes an enormous capability in product B, and the two are governed and logged separately.

How it works. The delegation links a GCP-plane object (the service account) to a Workspace-plane capability (impersonate any user). So anyone who can act as that service account inherits the delegation — and acting as a GCP service account is a routine GCP-plane operation, governed by ordinary GCP IAM.

Real-world illustration. This is the cross-product pattern in general: a CI system federated into a cloud, a cloud service account delegated into a SaaS suite, one tenant's app trusted by another tenant's directory. The lesson is the same each time — trace where a federation grant is honoured, not just where it is configured, because the impact lands wherever the trust is consumed.

Attacker's checklist

Defender's mirror

A federation flaw rarely appears in a permission report, but the surrounding intrusion still leaves fingerprints. Datadog's "unwanted visitor" case is the canonical example: an attacker with a stolen AKIA key called sts:GetFederationToken with an inline {"Action":"*","Resource":"*"} policy to pivot from CLI to console, then created an IAM role named SupportAWS whose trust policy was "Principal": {"AWS": "713521355166"} — the attacker's own AWS account, with an empty Condition — and attached AdministratorAccess to it.^[6]#158 That is a cross-account backdoor role: a trust relationship rewritten to point at the attacker, durable access with no stored credential in the victim account, and a legitimate-sounding name. It is T3 in miniature — the defender's job is to notice the trust policy changed.