Loading story…
AWS IAM Roles Anywhere enables on-premises servers, containers, and other workloads outside AWS to assume IAM roles and obtain temporary AWS Security Token Service credentials without storing long-term AWS access keys. Workloads authenticate with an X.509 certificate issued by a configured trust-anchor certificate authority and prove possession of the associated private key; AWS then validates the request and creates an IAM role session according to the configured role trust and permission policies.
Administrators must configure trust anchors, Roles Anywhere profiles, and IAM roles, while workload owners provision certificates and use aws_signing_helper as a credential process. CloudTrail records CreateSession activity and API calls made through assumed roles. Organizations can disable a trust anchor to stop new sessions and can use imported certificate revocation lists, although the service does not retrieve revocation status through CRL Distribution Points or OCSP callbacks.
See affected versions and whether adversaries are exploiting it.
1 event from the most recent confirmed update back to the earliest known activity.
AWS introduced IAM Roles Anywhere, enabling workloads outside AWS to use X.509 certificate-based authentication to assume IAM roles and obtain temporary AWS credentials instead of long-term access keys.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Datadog Security Labs disclosed **CVE-2024-28056**, an AWS Amplify flaw that left Cognito-linked IAM roles vulnerable to takeover when trust policies omitted the required Cognito identity pool audience restriction. The issue affected two Amplify variants: older CLI-created projects with insecure default trust policies and projects where the authentication component was later removed, leaving overly permissive roles behind. Researchers identified more than **8,000** public IAM role ARNs with recognizable Amplify naming patterns such as `authRole` and `unauthRole`, and showed that attackers could use Cognito Basic authflow together with STS to obtain short-lived credentials through ```text AssumeRoleWithWebIdentity ``` without additional authorization.
Jun 29, 2026
Wiz documented **Console Conceal**, a technique in which an attacker with stolen IAM-user credentials and permission to call `AssumeRole` selects an arbitrary role-session name and creates a federated AWS Management Console session. CloudTrail records subsequent console activity under a derived temporary access key rather than the access key issued in the initiating `AssumeRole` event, frustrating direct access-key correlation between the activity and the compromised IAM principal. AWS organizations should require and monitor **SourceIdentity** on role assumptions, as it propagates an administrator-controlled, immutable identity into subsequent CloudTrail events. For historical sessions without SourceIdentity, investigators can correlate suspicious console events to role assumptions using the role name, role-session name, and session-creation timing, while reviewing CloudTrail `userIdentity` fields and tightening IAM permissions that permit role assumption and custom identity-broker console access.
Sep 3, 2026Researchers and cloud security vendors documented a recurring AWS IAM trust policy flaw in OIDC integrations for **Terraform Cloud** and **GitHub Actions** that can let unauthorized external workloads assume customer roles. In both cases, the issue stems from missing or overly broad `sub` conditions in resource-based trust policies: older AWS-created Terraform Cloud policies could omit `app.terraform.io:sub`, and GitHub Actions deployments often lacked the repository-specific `sub` restriction. That weakness meant any valid identity token from the trusted OIDC provider could potentially satisfy the role trust and gain access to the victim AWS account. Public writeups showed how attackers could exploit broad Terraform Cloud patterns by creating a matching organization, project, and workspace, then using Terraform to provision a backdoored IAM role with **`AdministratorAccess`**. The GitHub Actions variant was amplified by copied example code and Terraform JSON duplicate-key behavior, prompting coordinated disclosures by researchers, Wiz, Datadog, AWS, and HashiCorp. AWS updated its console behavior, notified affected customers, blocked creation of some new misconfigured policies, and set enforcement deadlines, while defenders were urged to audit OIDC trust relationships, require precise subject claims, and use controls such as **Resource Control Policies** and detection rules to prevent arbitrary role assumption.
Sep 3, 2026