Loading story…
Researchers found that the legacy AmazonGuardDutyFullAccess AWS-managed policy (version 1) granted unrestricted organizations:RegisterDelegatedAdministrator access. If a principal in an AWS Organizations management account is compromised, the permission could let an attacker register a controlled member account as delegated administrator for services beyond Amazon GuardDuty, exploiting the broad set of AWS services integrated with Organizations.
The delegated account could then be used for organization-wide reconnaissance, persistence, lateral movement, and privilege escalation. Delegation of AWS IAM Identity Center or CloudFormation StackSets could enable compromise across member accounts and potentially the management account through Identity Center permission assignments. AWS released AmazonGuardDutyFullAccess_v2, which limits delegation to GuardDuty, and stopped new attachments of the legacy policy on August 26, 2025; existing attachments remain risky until replaced. Organizations should inventory delegated administrators and principals using the legacy policy, restrict access to high-impact delegated accounts, and alert on delegation-related CloudTrail events.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
AWS stopped allowing customers to attach the older AmazonGuardDutyFullAccess policy to IAM principals. Existing attachments remained in place and required administrator action to replace with version 2 or a least-privilege custom policy.
AWS released AmazonGuardDutyFullAccess_v2, restricting delegated-administrator registration to GuardDuty, and notified customers with impacted IAM principals through email and the AWS Health Dashboard. Existing principals were not automatically migrated and retained the legacy policy's permissions until manually updated.
Research found that version 1 of the AWS-managed AmazonGuardDutyFullAccess policy granted unrestricted organizations:RegisterDelegatedAdministrator permission. A compromised management-account principal with this policy could register an attacker-controlled member account to administer other eligible services, including IAM Identity Center or CloudFormation StackSets.
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.
AWS automatically attaches the managed `AWSCompromisedKeyQuarantine` policy to an IAM user after detecting that the user’s long-term access key and secret were publicly exposed. A controlled GitHub exposure test showed the `AWSCompromisedKeyQuarantineV3` policy applied within 10 seconds, followed by a GitHub notification, AWS Health alert, email notification, and AWS Support case. The policy uses explicit deny statements to block high-risk activity while retaining much of the user’s ordinary access. The quarantine policy has expanded from 28 denied actions across five services in 2020 to restrictions spanning resource creation and services including Amazon S3, EC2, IAM, and Bedrock, reflecting evolving cloud-abuse tactics. Organizations should investigate CloudTrail `AttachUserPolicy` events involving this policy and GitHub secret-validation `GetCallerIdentity` requests, then rotate exposed credentials, assess activity performed before containment, and enforce least-privilege IAM controls; permissions not explicitly denied may remain available to an attacker.
Sep 21, 2026
AWS disclosed two critical vulnerabilities in **AWS Ops Wheel v2** that could let attackers seize full administrative control of customer deployments. **CVE-2026-6911** stems from missing cryptographic verification of JWT signatures in the v2 API, allowing an unauthenticated attacker with network access to the API Gateway endpoint to forge tokens with arbitrary tenant and administrator claims. The flaw could expose all application data across tenants and permit management of Amazon Cognito user accounts; it affects deployments built from **PR #147 through PR #163**, while v1 is not affected. GitHub advisory **`GHSA-v5vr-8w3c-37x2`** says the issue was fixed in **PR #164**, and temporary mitigations include restricting API Gateway access with **AWS WAF** or **VPC** controls. A second issue, **CVE-2026-6912**, allowed any authenticated user to escalate privileges by modifying self-writable security-sensitive Cognito attributes such as `custom:deployment_admin` through the Cognito `UpdateUserAttributes` API. An attacker could promote their own account to deployment administrator, then read, modify, or delete cross-tenant data and manage all users in the deployment’s Cognito User Pool. That flaw affects the same **PR #147-#163** range and was fixed in **PR #165** by tightening Cognito `WriteAttributes` and adding server-side email verification tied to `DEPLOYMENT_ADMIN_EMAILS`. Because Ops Wheel is deployed into customer AWS accounts through CloudFormation, each affected deployment and any forks or derivative code must be individually updated.
Jun 29, 2026
AWS guidance highlights **Resource Control Policies (RCPs)** as organization-level guardrails that constrain resource policies, including access granted to principals outside an AWS Organization. RCPs complement Service Control Policies by applying to external principals, helping prevent attacker-controlled accounts from bypassing internal SCP restrictions. They can enforce data-perimeter standards for cross-account access, IAM role assumption, OIDC federation, and transport security, alongside controls such as VPC Block Public Access and centrally managed root access. For Amazon S3, AWS supports bucket and access-point policies using `s3:TlsVersion` and `aws:SecureTransport` to require stronger encryption in transit, including TLS 1.3 where needed; AWS service API endpoints require TLS 1.2 or later by default. Organizations should use IAM Access Analyzer and access logs to identify dependencies, test RCPs in sandbox accounts, and roll them out progressively because RCPs lack an audit-only mode and can generate generic `AccessDenied` errors. Legacy TLS clients can be isolated behind CloudFront, while S3 Access Points allow stricter TLS requirements for selected access paths to the same data.
Sep 3, 2026