Loading story…
Elastic Security Labs detailed how AWS Security Token Service (STS) AssumeRoot can be abused when an IAM principal has overly broad permissions in an AWS Organization. The API issues temporary, task-policy-scoped credentials for the root user of a member account; in the demonstrated white-box scenario, an attacker used the IAMCreateRootUserPassword task policy to create a root login profile and prepare persistent console access. Completing the takeover would also require access to the member account’s root-email inbox to reset or establish the root password. Elastic reported no publicly known in-the-wild abuse at the time of publication.
Organizations should restrict AssumeRoot permissions and approved task policies to narrowly defined administrative roles, review delegation across member accounts, and enforce MFA and root-account credential guardrails. Security teams should retain organization-wide CloudTrail visibility and alert on unusual or rare AssumeRoot calls, especially when followed by root CreateLoginProfile activity, as these events may indicate an attempt to establish root-level persistence in a member account.
Map this exposure pattern across your cloud, code, and identities.
2 events from the most recent confirmed update back to the earliest known activity.
Elastic Security Labs demonstrated that overly permissive IAM-user credentials could invoke AssumeRoot with the IAMCreateRootUserPassword task policy and create a root login profile. Persistent console access would additionally require access to the member account root email inbox to complete password recovery.
AWS introduced the STS AssumeRoot API operation, which provides temporary, task-policy-scoped credentials for the root user of a member account in an AWS Organization.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See where this exposure pattern shows up across your cloud, code, supply chain, and non-human identities.
3 references tracked. Mallory keeps watching after this page renders.
docs.aws.amazon.com
Open sourceelastic.co
Open sourcedocs.aws.amazon.com
Open sourceMap 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 Research identified a password-spraying campaign that made repeated failed AWS ConsoleLogin attempts against root accounts at more than 150 organizations between July 24 and August 23. Victims typically received only a few attempts—median two and as many as eight—with no observed successful authentications or confirmed account compromises. The actors used outdated Chrome/Edge 85 and Firefox 120 user-agent strings and geographically distributed proxy infrastructure spanning multiple countries and autonomous systems. Because failed root-console authentication requires the email address associated with the AWS root user, the activity indicates the attackers likely obtained root-email addresses or successfully enumerated likely account-email candidates. Organizations should review AWS CloudTrail for root `ConsoleLogin` events, alert on all root-account activity, eliminate persistent root credentials where possible, and apply distinct protections to management-account root users. Mandatory AWS root-user MFA, enforced since June 2025, can prevent takeover even if a root password is compromised.
Sep 5, 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
Amazon EKS access management and Pod Identity add IAM-native controls for granting cluster access and workload AWS permissions, but security research found they can create lateral-movement and privilege-escalation paths. An attacker who compromises an IAM principal with `CreateAccessEntry` and `AssociateAccessPolicy` permissions can create or alter an EKS access entry and potentially obtain Kubernetes `cluster-admin` access. EKS access policies combine cumulatively with legacy `aws-auth` ConfigMap mappings and Kubernetes RBAC bindings, complicating effective-permission reviews; even `AmazonEKSEditPolicy`, and in some cases `AmazonEKSViewPolicy`, may expose escalation or sensitive-data-disclosure opportunities. Pod Identity introduces a node-local agent that supplies temporary AWS credentials to workloads, expanding the impact of node or pod compromise. A compromised `hostNetwork` pod may intercept plaintext traffic to the local agent endpoint and capture credentials issued to other pods on the same worker node. Organizations should audit both EKS API and Kubernetes RBAC authorization paths, limit access-entry administration, apply namespace-scoped and least-privilege permissions, protect kubelet pod-file access, and segregate untrusted workloads. IAM Roles for Service Accounts (IRSA), which uses projected service-account OIDC tokens to obtain role-specific STS credentials, remains an alternative where preventing node-local credential interception is a priority.
Sep 3, 2026