Backdoor OIDC provider audience
Can add an attacker audience to a trusted OIDC provider.
Grants escalation on its own.
iam:AddClientIDToOpenIDConnectProviderOn its own, iam:AddClientIDToOpenIDConnectProvider can add an attacker audience to a trusted OIDC provider. On a wide resource scope that alone reaches a standing way back in.
Why it is dangerous
A principal can call iam:AddClientIDToOpenIDConnectProvider to register an attacker-controlled audience on a trusted OIDC provider, then mint a matching token and call sts:AssumeRoleWithWebIdentity into the role that trusts that provider.
In MITRE ATT&CK terms this maps to T1556, Modify Authentication Process, under the persistence tactic. AWS records it in CloudTrail as AddClientIDToOpenIDConnectProvider. The call is quiet against normal activity, so it is easy to miss without a rule for it. It also gives an attacker a way to keep access after the first foothold is closed, so it is worth watching even when it looks like routine administration.
Detection
AddClientIDToOpenIDConnectProviderPrerequisites
A role whose trust policy accepts the added audience for the provider.
MITRE ATT&CK
T1556 · Modify Authentication ProcessTactic
Persistence
A control that would remove it: Restrict iam:AddClientIDToOpenIDConnectProvider to a break-glass role; alarm on changes to OIDC providers.
Whether to apply it depends on how the permission is used in your environment, so it is a business decision rather than an automatic fix. The same permission can be load-bearing in one account and pure risk in another.
Pathbreak confirms whether this path resolves in your account, ranks it against the others by how much it opens up, and uses your threat model and business context to show which paths are worth cutting.
Questions
What does iam:AddClientIDToOpenIDConnectProvider allow?
Can add an attacker audience to a trusted OIDC provider.
Can iam:AddClientIDToOpenIDConnectProvider escalate privileges on its own?
Yes. Held on a broad enough resource it reaches a standing way back in with no other permission.
How is backdoor OIDC provider audience detected?
Watch for AddClientIDToOpenIDConnectProvider in CloudTrail. The call is quiet against normal activity, so it is easy to miss without a rule for it.
How do you break this path?
A control that would remove it is: Restrict iam:AddClientIDToOpenIDConnectProvider to a break-glass role; alarm on changes to OIDC providers. Whether to apply it depends on how the permission is used in your account, so it is a business decision rather than an automatic fix.
Which MITRE ATT&CK technique is this?
T1556, Modify Authentication Process, under the persistence tactic.
Related paths
References
Find this in your own account
We run a read-only scan of one AWS account and show you which of these paths exist, ranked by blast radius, with the change that breaks each one. First validated paths within the hour.