AWS IAM OIDC Provider Created by Rare User
Description
Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes.
Query · kuery
data_stream.dataset: "aws.cloudtrail"
and event.provider: "iam.amazonaws.com"
and event.action: "CreateOpenIDConnectProvider"
and event.outcome: "success"
and not user_agent.original: (*Terraform* or *eksctl*)
Investigation fields
Pivot points the source recommends for triage.
@timestampuser.nameuser_agent.originalsource.ipaws.cloudtrail.user_identity.arnaws.cloudtrail.user_identity.typeaws.cloudtrail.user_identity.access_key_idevent.actionevent.outcomecloud.account.idcloud.regionaws.cloudtrail.request_parametersaws.cloudtrail.response_elements
Known false positives
- OIDC providers may be created during legitimate CI/CD integration (e.g., GitHub Actions, GitLab CI), Kubernetes service account federation, or other web identity use cases. Verify whether the user identity and timing align with approved change management processes. If this is expected administrative activity, it can be exempted from the rule.
Analyst notes
Investigating AWS IAM OIDC Provider Created by Rare User
OpenID Connect (OIDC) providers in AWS IAM enable web identity federation, allowing external identity providers to authenticate users who then assume IAM roles. Common legitimate use cases include GitHub Actions accessing AWS resources, Kubernetes pods authenticating to AWS, and web applications using social login.
This rule detects the first time a specific user or role creates an OIDC provider within an account. While OIDC provider creation is common in some environments, a new user creating one for the first time warrants validation to ensure it's authorized.
Possible investigation steps
- Identify the actor
- Review
aws.cloudtrail.user_identity.arnto determine who created the OIDC provider. -
Check if this user has created OIDC providers before in other accounts.
-
Review the OIDC provider details
- Examine
aws.cloudtrail.request_parametersfor the provider URL and client IDs. -
Identify the external IdP (e.g., GitHub, Google, custom provider).
-
Validate business justification
- Confirm with DevOps or platform teams whether this aligns with CI/CD pipeline setup.
-
Check for related change tickets or infrastructure-as-code deployments.
-
Check for follow-on activity
- Search for
CreateRoleorUpdateAssumeRolePolicycalls that trust the new OIDC provider. -
Look for
AssumeRoleWithWebIdentitycalls using the newly created provider. -
Correlate with other suspicious activity
- Check for preceding privilege escalation or credential access events.
- Look for other persistence mechanisms being established concurrently.
False positive analysis
- CI/CD pipeline integration
- GitHub Actions, GitLab CI, and other CI/CD systems commonly use OIDC for AWS authentication.
-
Validate against known DevOps workflows.
-
Kubernetes federation
- EKS and self-managed Kubernetes clusters may use OIDC providers for pod identity.
-
Confirm with platform engineering teams.
-
Infrastructure-as-code deployments
- Terraform, CloudFormation, or other IaC tools may create OIDC providers.
- Verify via CI/CD logs.
Response and remediation
- Immediate containment
- If unauthorized, delete the OIDC provider using
DeleteOpenIDConnectProvider. -
Review and remove any IAM roles that trust the rogue provider.
-
Investigation
- Audit CloudTrail for any
AssumeRoleWithWebIdentitycalls using this provider. -
Review all IAM roles with web identity trust relationships.
-
Hardening
- Restrict
iam:CreateOpenIDConnectProviderpermissions to authorized roles. - Implement SCPs to control OIDC provider creation in member accounts.
- Enable AWS Config rules to monitor identity provider configurations.