AWS CIRT Adds EKS and Organization-Trust Attacks to Its Threat Catalog

AWS has turned several incident-response patterns into new cloud-defense guidance. In a June 29 AWS Security Blog post, the AWS Customer Incident Response Team said the June 2026 update to the Threat Technique Catalog for AWS focuses on container security, organization-level trust, and compute hijacking.

The update is notable because the techniques do not depend on exotic malware. AWS says the common thread is abuse of legitimate cloud and Kubernetes functionality: workload changes, cross-account trust, organization invitations, and compute consumption. That makes the catalog useful as a detection backlog for teams that operate Amazon EKS clusters and AWS Organizations at scale.

What AWS added in June

AWS CIRT says it added five entries to the catalog: EKS workload modification, exploit public-facing application for EKS workloads, AssumeRoot into an organization member account, compute hijacking on EKS, and inviting accounts to an unknown organization. It also refreshed entries for S3 Object Collection, Compute Hijacking on ECS, and Role Assumption and Federated Access.

That mix points to two areas where attackers can hide in normal operations. The EKS entries describe ways to use Kubernetes control-plane access or exposed workloads to change running systems. The organization entries describe ways to exploit trust relationships between AWS accounts after a management account or standalone account has been compromised.

EKS workload changes are the new quiet path

The EKS workload-modification entry matters because it frames a cluster compromise as an integrity problem, not only an access problem. AWS says threat actors with Kubernetes credentials or an IAM role with EKS permissions can alter container images, inject sidecars, or change pod specifications in existing deployments. Because the workload already has network access, service-account permissions, and data access, the malicious change can inherit reach that defenders previously approved.

AWS points to practical controls rather than a single product fix: admission controllers and image verification, least-privilege Kubernetes RBAC, namespace isolation, network policies, and monitoring through Kubernetes audit logs. The separate Amazon GuardDuty EKS Protection documentation says GuardDuty analyzes EKS audit logs to detect potential security threats and can generate findings from that audit-log stream.

Compute hijacking is still about cost and control

The new EKS compute-hijacking entry extends a familiar cloud problem into Kubernetes operations. AWS says threat actors deploy cryptocurrency mining or other compute-intensive workloads inside compromised clusters, and that clusters without resource quotas can let one compromised service account consume broad capacity. The catalog recommends resource quotas, limit ranges, registry restrictions, least-privilege RBAC, GuardDuty EKS Protection, EKS Runtime Monitoring, and EKS control-plane logging.

For platform teams, the lesson is that budget alerts alone are late signals. Kubernetes admission policy, namespace limits, and service-account scoping become security controls because they decide how far an unauthorized pod can scale before a human sees the bill or the performance impact.

AWS Organizations trust is also in scope

The AssumeRoot entry raises a different concern. AWS says threat actors with sufficient access in a management account may use sts:AssumeRoot to escalate into organization member accounts when centralized root access is in place. The AWS blog says root access to a member account can let an attacker disable security controls, delete resources, change billing configuration, and establish persistence that survives remediation focused only on IAM principals.

AWS recommends service control policies that restrict which principals can call sts:AssumeRoot and under what conditions, plus CloudTrail monitoring for those calls. The organization-invitation entry adds another governance risk: an attacker who controls a standalone account, or removes an account from its legitimate organization, can invite it into an organization they control. AWS calls out monitoring for organizations:InviteAccountToOrganization and organizations:AcceptHandshake as part of the response.

The detection bar is context

The most important sentence in the AWS post is that these techniques operate within the boundaries of legitimate functionality. A deployment update, a pod launch, an AssumeRoot call, or an organization handshake can all be normal in the right context. The detection question is who did it, when it happened, what changed next, and whether the sequence matches approved operations.

That makes the catalog useful beyond incident response. Teams can turn the new entries into specific engineering checks: Are EKS audit logs retained long enough for investigation? Are GuardDuty EKS findings routed to responders? Can a workload service account change deployments or launch privileged pods? Which principals can call sts:AssumeRoot? Are unexpected organization invitations treated as high-priority events?

What security teams should do now

The practical next step is to map the five new entries against current controls. EKS operators should review RBAC for workload mutation, admission policy for signed or approved images, namespace quotas, network policy coverage, and public exposure of Kubernetes APIs and ingress paths. AWS Organizations administrators should review management-account hardening, centralized root access, SCP coverage, and CloudTrail alerting for root-assumption and organization-handshake events.

The June update does not say every customer is seeing all five patterns at once. It says AWS CIRT is seeing repeatable patterns across engagements and is publishing them so customers can act before they are in the middle of an incident. That is the useful signal: the threat catalog is becoming a cloud operations checklist, not just a taxonomy.

Sources: AWS Security Blog’s June 29, 2026 post on the Threat Technique Catalog update, the Threat Technique Catalog entries for EKS workload modification, AssumeRoot into an organization member account, EKS compute hijacking, unknown-organization invitations, and the Amazon GuardDuty EKS Protection documentation.

Featured image: Racks Amravati Data Center by PiDatacenters via Wikimedia Commons, licensed under CC BY-SA 4.0; cropped, resized, and converted to WebP.