Five new attack techniques landed in the AWS Threat Technique Catalog this June, and every single one exploits functionality you probably consider normal – workload modification, root trust assumption, and organization invitations.
EKS Workload Modification: The Silent Pivot
Threat actors who have stolen Kubernetes credentials or an IAM role with EKS permissions are modifying running workloads in place. They alter container images, inject sidecar containers, or change pod specs – inheriting all the network access, service account permissions, and data access the legitimate workload already had. The modification leaves nothing new to detect. Without admission controllers enforcing image signing, or Kubernetes RBAC restricting workload changes, these pivots fly under radar until the downstream damage surfaces. Amazon GuardDuty EKS Protection can flag anomalous cluster activity, but by then the attacker is already inside production.
Assume Root: When Management Account Trust Becomes a Weapon
Compromise a management account (or gain sufficient privilege inside one) and you can call sts:AssumeRoot into any member account. Because the trust is baked into the AWS Organization structure, the member account administrator's own SCPs and access controls are bypassed. Once inside as root, the threat actor can disable security controls, delete resources, change billing, and establish persistence that IAM-level remediation won't touch. AWS CIRT recommends SCPs that restrict which principals can call sts:AssumeRoot and under what conditions, plus monitoring every sts:AssumeRoot call in CloudTrail.
Compute Hijacking at Scale
Containerized compute hijacking keeps accelerating. Inside an EKS cluster without resource quotas, a single compromised service account can consume all node capacity for cryptocurrency mining. The attackers use legitimate-looking images from public registries, so image scanning alone is useless. Resource quotas, limit ranges, registry restrictions, and GuardDuty EKS Protection for mining behavior are the minimum viable detection stack.
Invite Accounts to Unknown Organization – The Governance End Run
Here's a nasty one: an attacker gains access to a standalone AWS account (or removes one from its legitimate org) and invites it into their own organization. Once the account accepts, the attacker's organization SCPs can lock the legitimate owner out of their own governance, gain visibility into resources through organizational services, and access consolidated billing data. The owner loses control. Monitoring organizations:InviteAccountToOrganization and organizations:AcceptHandshake, plus SCPs that prevent accounts from leaving their legitimate organization, are your only defenses.
Updated Entries and the Common Thread
Three existing entries got refreshed: S3 Object Collection now covers additional bulk staging APIs with newer S3 security features; Compute Hijacking - ECS adds methods for abusing overly permissive task execution roles; Role Assumption and Federated Access expands with cross-account role assumption variations and identity provider manipulation. Every one of these techniques operates within boundaries of legitimate functionality. Detection depends entirely on context – the principal, the timing, the sequence of events.
The catalog will keep evolving as AWS CIRT sees these patterns repeat. Time to audit your controls before a threat actor does.
Source: What the June 2026 Threat Technique Catalog update means for your AWS environment
Domain: aws.amazon.com
Comments load interactively on the live page.