Out of Sight, Beneath the Surface: Exploring Delegated Admin Risks in AWS Organizations
How Chaining Delegated Admin with a Mis-scoped Managed Policy Allowed Escalation from a Compromised Account to Full AWS Organization Control
EXECUTIVE SUMMARY
This research investigates AWS Organizations cross-account pivoting and compromise by abusing misconfigured delegation mechanisms, uncovering how attackers can abuse legitimate features to persist, move laterally and escalate privileges across all accounts in a multi-account AWS environment. In addition, this research discovered a high-impact policy flaw that, in certain conditions, could enable a full organizational takeover from a compromised member account, including control of the management account. AWS has corrected the managed policy to eliminate the subtle scope issue, and has proactively notified customers whose environments may have been exposed due to a very specific but impactful configuration that made this vector exploitable
Key Findings:
- Despite being a highly recommended best practice, delegation architectures (like any system) can still be vulnerable if misconfigured, allowing adversaries to exploit delegation mechanisms and escalate access across accounts
- Accounts should be classified into appropriate sensitivity tiers based on the privileges granted by their delegated services.
- A previously over-scoped AWS-managed policy could have enabled full organizational compromise from an authenticated foothold under specific conditions. AWS has since released an updated policy to address the issue, organizations should ensure only the corrected version is in use.
These findings highlight a critical and often-overlooked attack surface in AWS Organizations: the risks inherent in delegation configurations and mis-scoped permissions. Even in well-architected environments, these design choices can unintentionally expose escalation paths from existing footholds..
Recommended Actions:
- Audit all delegations: Enumerate delegated admin accounts and map their service access organization-wide. Treat sensitive service delegations as the appropriate tier risk.
- Monitor for delegation events: Track and alert on all RegisterDelegatedAdministrator, EnableOrganizationAdminAccount , and related events via CloudTrail.
- Validate Exposure: Simulating attack scenarios is strongly recommended, specifically by testing delegation configurations, pivoting techniques, and potential organization-wide escalation paths in a controlled environment to ensure visibility and defensive readiness.
- Mitigate vulnerable AWS managed policy: Identify all principals using AmazonGuardDutyFullAccess v1 and, if possible, consider reattaching v2 or applying least-privilege custom policies.
The Cymulate Research Labs has developed an attack simulation that combines delegated-admin misconfiguration abuse for organization-wide privilege escalation with exploitation scenario of the vulnerable AmazonGuardDutyFullAccess (version 1) managed policy. This allows organizations to see exactly how their detection and prevention controls handle such a scenario, so they can optimize their controls if there are gaps in their defenses.
Full technical details, attack flows, PoCs and detection guidance follow below.
Introduction
The AWS Organizations service provides a centralized framework for managing multiple AWS accounts, facilitating governance, policy enforcement, and operational oversight at scale. While this hierarchical, multi-account structure enhances administrative control and scalability, it introduces new attack surfaces and vectors for potential privilege escalation and inter-account lateral movement.
From an adversarial standpoint, the isolation between individual accounts is a hurdle. Yet, cross-account access, often configured for legitimate operational needs, can be weaponized for lateral movement.
A particularly interesting vector lies in the delegated administrator feature. Although designed to offload administrative burden from the management account, it can inadvertently expand the blast radius if misused.
In this article, we delve into:
- AWS Organizations Service: How delegated administrator accounts work within AWS Organizations.
- Delegations from an Attacker's Perspective: Scenarios where this feature can be abused for privilege escalation and lateral movement.
- Configuration: The security implications of trusting these configurations.
- Detecting AWS Delegation-Based Attacks: Practical examples for identifying delegation abuse and implementing hardening measures in AWS Organizations to minimize the attack surface.
- Bonus: Discover how a flaw in an AWS-managed policy unintentionally unlocked complete control over an entire multi-account AWS Organization and provided a hidden backdoor.
By exposing the lesser-known attack paths in what is typically seen as a security best practice, we aim to inform defenders and red teamers on how to evaluate and secure their AWS Organizations more effectively.
AWS Organizations Service
AWS Organizations Service Recap
Already familiar with AWS Organizations? Feel free to skip ahead.
AWS Organizations is a native AWS service that lets you centrally manage and govern a growing fleet of AWS accounts. You can create new accounts from a single management console or API, group them according to different workloads or business units, attach organization-wide policies, integrate security and operations services and receive a consolidated bill for everything you run.
Each organization has a management account, which holds the highest level of administrative privileges and acts as the central authority for managing the entire organizational structure. The management account can be used to create or invite member accounts, arrange them in a hierarchy of organizational units (OUs) and apply organization-wide controls, such as Service Control Policies (SCPs), to define and enforce permission boundaries across accounts and services.
AWS provides the concept of a landing zone to help organizations implement a consistent and secure multi-account structure from the start. This predefined architecture includes baseline configurations for identity management, logging, security controls, and networking. Setting up a landing zone manually can be complex and error-prone, especially at scale. AWS Control Tower service addresses this by offering a managed solution that automates the creation and governance of a landing zone using AWS best practices. It provisions accounts, organizes them within OUs, and enforces guardrails (pre-configured policies) to maintain compliance and operational consistency across the organization.
Overview of AWS Delegated Administrators
AWS Delegated Administrator is a feature of AWS Organizations that allows the management account to assign another account to administer a specific AWS service across the entire organization. As stated in the AWS documentation, the goal is to reduce reliance on the highly-privileged management account by offloading certain service-specific admin tasks to other accounts.
When an account is registered as a delegated administrator for a service, it can perform that service’s admin functions organization-wide. Additionally, it receives read-only access to organization metadata, such as listing all accounts and OUs. This read-only organization access is granted by AWS by default to help the delegated admin account understand the organization’s structure. Thus, a delegated administrator account is still a sensitive account, and access to it should be carefully controlled and monitored. That account is all-powerful with respect to the service that it is has designated to administer across the Organization.
Delegation administrator documentation: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_delegated_admin.html
How Delegation Works
To set up a delegated administrator, the management account must enable trusted access for the AWS service (allowing the service to work with Organizations) and then register a member account as the service’s admin by:
- Enabling trusted access for the target service from the management account
API / CLI: organizations:EnableAWSServiceAccess (or the console equivalent) - Designating a member account as the service’s delegated administrator using two common patterns:
- Service-specific API: guardduty:EnableOrganizationAdminAccount, securityhub:EnableOrganizationAdminAccount
- Organizations API: organizations:RegisterDelegatedAdministrator for services that use the central registration model (e.g., CloudFormation StackSets)
Once delegated, identities within the account can manage that service globally in the organization and its assigned accounts.
To enforce a least privilege concept, AWS recommends minimizing direct use of the management account. Instead, administrative tasks should be performed through delegated administrator accounts. This approach promotes better separation of duties and reduces the risk of relying on a single, highly privileged account.
In addition to the delegated service, AWS documentation states that the target account also gains read-only privileges at the organization level:
Note: A member account cannot list or read the organization’s structure by default. Gaining read access from within a delegated admin account grants visibility into the organization’s structure (from an attacker’s perspective).
Resource-Based Delegation
AWS introduced another feature, allowing the delegation of administrator privileges for the AWS organization. Unlike the service-specific delegation, which grants full admin for that service, this feature uses a fine-grained policy structure on the organization to grant limited org-level capabilities to a member account.
This feature allows sharing some organization management tasks, such as viewing account details and tags and managing SCPs from within other accounts. For example, you could delegate OU-specific SCP management to an account that will serve as a policy management account. This granular approach means multiple accounts can each be given different organization privileges.
Overall, delegated administrators are a powerful mechanism in multi-account AWS environments. While they improve security by enforcing least privilege and isolating the management account, they also introduce new security considerations and potential attack surfaces. In the sections below, we will discuss which services support delegation and examine known abuse paths when delegation is misused or compromised.
Delegations from an Attacker's Perspective
Recon
Understanding the intended design and implementation of account administration delegation in AWS Organizations reveals an additional attack surface and potential attack vectors. It is critical to recognize how these features, if misconfigured or compromised, can be exploited to gain broader access across the organization. As mentioned, controlling a delegated account grants full organization-wide visibility (regardless of which service was delegated), including access to the full account and organizational unit (OU) hierarchy. That alone can allow a much better understanding of the environment structure, increasing situational awareness while defining high value goals and planning paths.
A delegated administrator account possesses organization-wide privileges for specific services. Suppose such an account is compromised, especially when a sensitive service is delegated. In that case, it may allow an attacker to abuse its extensive access across the organization, escalating privileges and moving laterally to every account.
As a red teamer, when assessing the attack surface of an AWS Organization, it's crucial to identify which member accounts have been designated as delegated administrators for specific services. Delegated admin accounts by definition possess additional privileges that, if compromised, could allow an attacker to move laterally across the organization.
Important: Organizations may fail to classify delegated administrator accounts according to their true sensitivity, resulting in insufficient protective controls. For example, a delegated account for AWS IAM Identity Center (formerly AWS SSO) should be treated as a Tier 0 asset. Compromise of such accounts can grant direct access to identity sources or infrastructure automation, potentially enabling privilege escalation across the organization. This feature warrants stricter isolation and monitoring. More on that below.
Exploitation: Persistence and Privilege Escalation
Let’s go over popular examples of sensitive services that can be delegated and show how compromising the delegated account could be abused to gain elevated privileges, lateral movement or persistence:
1. AWS Identity Center (formerly SSO)
The AWS IAM Identity Center enables centralized access management across accounts within an AWS Organization by allowing you to create and manage identities locally:
The AWS IAM Identity Center can also allow you to connect to existing identity sources, such as Active Directory or Entra ID, to replicate identities from other environments. Additionally, it facilitates the creation and management of permission sets across the organization, which can be attached to groups, and identities can be assigned to these groups accordingly:
When the identity center service is delegated to an account, it allows for managing access across the entire organization.
Altering privilege sets and group membership may allow an adversary to alter their own access, effectively escalating privilege across every account within the organization.
2. AWS CloudFormation StackSets
AWS CloudFormation StackSets enable the creation and deployment of organization-wide stacks across all member accounts, excluding the management account. The ability to create, modify, and deploy StackSets in nearly every account introduces subtle yet powerful attack vectors and persistence mechanisms.
3. AWS Service Catalog
Using access to portfolios in use may allow privilege escalation across different accounts by altering the portfolio to create a backdoor.
A complete list is detailed in the following link: AWS services that you can use with AWS Organizations - AWS Organizations
Weaponization Example: Exploitation of Organizations: RegisterDelegatedAdministrator Permission
Suppose an attacker gains access to a role or user within the management account with the organizations:RegisterDelegatedAdministrator permission. In that case, they can register an already compromised account as a delegated administrator for sensitive services.
This action might grant them elevated privileges across the entire organization and, in some cases, facilitate further compromise of the management account.
Here is an example scenario:
- Pre-requirement 1: During the engagement, the attacker compromised a role/user in the management account with the organizations:RegisterDelegatedAdministrator verb attached.
Pre-requirement 2: The attacker has compromised an account within the AWS Organization. Any member account will suffice. For example, compromising a sandbox account may be easier, as these environments are typically isolated from production, contain no sensitive data, and identities within are often granted with broad administrative access for testing purposes.
Note: Delegation will only succeed if the selected service has not already been delegated. In that case, the Identity Center must not already be delegated. If it is, another non-delegated sensitive service should be used. - The attacker exploits the verb to delegate the Identity Center service to the compromised account.
- The attacker can now manage SSO, PrivSets and groups within the organization
- The attacker adds a compromised user to a high privileged group or resets the password of a user with administrator access to the management account.
- The attacker compromised the entire organization.
Persistence
The administrator delegation feature could be abused for persistence in several ways.
For example, adding a delegation to a compromised account may allow re-gaining privileged access to the organization by exploiting the service (as explained above).
Evasion
Performing actions from within a compromised legitimate delegated account can slip through many defense mechanisms.
For example, by exploiting the delegated CloudFormation StackSets service, the attacker can modify an existing StackSet used across the entire organization by adding a subtle action, performing a sensitive operation that seems to originate from a legitimate action that may be excluded from monitoring systems.
Detecting AWS Delegation-Based Attacks
Here are some measures that an organization can take to detect and prevent attacks that exploit AWS delegation mechanisms.
1. Map current accounts with delegated services to make deviations less subtle. The following PowerShell command will use the current AWS CLI context to quickly list and map delegated accounts and services:
aws organizations list-delegated-administrators --query 'DelegatedAdministrators[].Id' --output text | Out-String | ForEach-Object { $_ -split '\s+' } | Where-Object { $_ -ne "" } | ForEach-Object { Write-Host "`nDelegated services for account: $_"; aws organizations list-delegated-services-for-account --account-id $_ --query 'DelegatedServices[*].ServicePrincipal' --outpOutput example:
Accounts with delegated access to sensitive services should be appropriately categorized based on the updated risk model. For instance, an account delegated for Identity Center should be treated as a Tier 0 asset and secured accordingly.
2. Monitor changes to service delegations, as these modifications are infrequent and typically not part of daily operations. Consider implementing alerts to detect and respond to such changes promptly.
Here is a quick PowerShell script to check for activities regarding Delegations (make sure the region is set or add –region at the end of the AWS CloudTrail command):
$delegationEvents = @(
"RegisterDelegatedAdministrator",
"DeregisterDelegatedAdministrator"
)
foreach ($event in $delegationEvents) {
Write-Host "Event: $event"
$events = aws cloudtrail lookup-events `
--lookup-attributes AttributeKey=EventName,AttributeValue=$event `
--max-results 10 `
--query 'Events[*].{Time:EventTime,User:Username,IP:SourceIPAddress}' `
--output json | ConvertFrom-Json
foreach ($e in $events) {
try {
$epoch = [double]$e.Time
$humanTime = [DateTimeOffset]::FromUnixTimeSeconds($epoch).ToLocalTime()
} catch {
$humanTime = "N/A"
}
Write-Host " Time: $humanTime | User: $($e.User) | IP: $($e.IP)"
}
} Output example:
3. Map identities in the management account with sensitive verbs such as organizations: RegisterDelegatedAdministrator. Consider limiting the scope as much as possible, following the least privilege concept.
4. Consider creating administrative delegations for services like Identity Center and StackSets to locked down accounts even if you do not currently use them, or plan to use them. Since they can only be assigned to a single account, this will prevent any undesired delegation should an attacker somehow obtain a foothold in the management account.
The following scripts can be used to quickly enumerate delegated admin accounts (from both red and blue perspectives):
https://github.com/BenZamir/Invoke-EnumDelegations
While exploring delegation-based attacks, I also identified a vulnerability in one of AWS’s managed IAM policies that could lead to unintended privilege escalation at the organization level and, in some situations, full compromise of the management account.
How I Uncovered an AWS-Managed Policy Flaw That Lets Attackers Hijack and Keep Full Control of Your Entire Organization
TL;DR
An improperly scoped verb in the AmazonGuardDutyFullAccess managed policy may pose a security risk to AWS organizations. A compromised user/role in the management account with the version 1 managed policy assigned could allow a complete takeover of every account and resource in the organization. In some cases, even the management account can be fully compromised.
Exploitation is also dependent on the organization’s security practices. It requires a compromised user/role in the management account with the AmazonGuardDutyFullAccess policy attached
Roles and users created for GuardDuty management and operation may be utilized for third-party and external systems (Such as SIEM and SOAR intergarions). Usually, these systems require programmatic access, and a compromised/leaked identity could compromise the whole organization.
It is important to note that while Administering GuardDuty from the management account is technically possible, it is highly unrecommended practice. In fact, GuardDuty was one of the first services to support the delegated admin feature designed to eliminate the use of the management account for this purpose.
Detailed Explanation
The AWS documentation, specifically the Amazon GuardDuty User Guide (AWS managed policies for Amazon GuardDuty - Amazon GuardDuty), refers to an AWS-managed policy intended for GuardDuty management.
The guide outlines the permissions granted by this policy in detail:
The third bullet point explains that the policy allows the designation of a delegated administrator and the management of GuardDuty member accounts within the organization.
However, a closer examination of the policy's structure reveals that it may be significantly more permissive than initially suggested
The verb organizations:RegisterDelegatedAdministrator is granted in the policy with no resource limits (*) or conditions.
The verb allows the user to delegate an allowed service to other accounts within the organization:
So, granting the AmazonGuardDutyAdministrator policy:
- Includes a verb that allows delegating any account in the organization.
- Any delegated, supported service can be chosen (and not only GuardDuty delegation).
- Can only be utilized from the management account.
Services supported for delegation:
AWS services that you can use with AWS Organizations - AWS Organizations
Some of the most interesting ones (in privilege escalation context) are:
- CloudFormation StackSets: Allows creating and running StackSets over all the accounts in the organization.
- AWS Identity and Access Management (formerly SSO): Allows viewing and altering organization-wide SSO and privilege configurations.
Suppose an adversary or an insider threat compromised a user/role in the management account with the AmazonGuardDutyAdministrator policy. In that case, it is possible to delegate any supported service to any account in the organization.
Delegating a sensitive service (such as SSO/CF StackSets) can lead to an account controlled by the attacker, which grants high privileged access to a sensitive service over the entire organization.
Exploitation example
Simulated environment:
- The lab organization has three active accounts:
- The attacker compromised access keys of a user in the management account that only has the AmazonGuardDutyAdministrator policy attached.
- The SSO user “weakuser” has no groups.
- The attacker has administrator access over the Workload1 account. The account has no active delegations and is isolated from the rest of the organization.
- The group Org Admin has a privset with an administrator role over the management account.
Process:
1. The attacker impersonates the compromised Guard Duty user, abuses the AmazonGuardDutyAdministrator and adds SSO delegation to the Workload1 account:
The Workload1 account now has an active SSO delegation:
2. The attacker logs into the Workload1 account using an administrator identity.
3. Using the delegation, the attacker has access to the identity management service at the organization level allowing sensitive actions such as:
Creating permission sets:
Adding users to groups:
An attacker could exploit this situation to obtain administrator-level access to the management account.
Note: Another approach could be exploiting CloudFormation Stacksets by:
- Delegating an attacker-controlled account to the CloudFormation service.
- Creating an organization-wide stack that establishes a backdoor.
- Executing it over every account in the organization (excluding the management account).
Current Status and What To Do Next
After we reported the issue, AWS has issued version 2 of the affected managed policy, tightened its scope and closed the privilege-escalation gap. However, as there may be production workflows that depend on the existing behavior, AWS has not automatically upgraded customers to the new policy. As a result, existing roles and users will not be automatically updated and will continue using version 1 until administrators manually re-attach the updated policy, leaving the organization exposed until the change is made.
Important Note: It is important to test in a non-production environment first to ensure that the newer version 2 does not break the currently required privilege.
| What AWS fixed | Released managed policy v2 with stricter |
| What hasn’t changed | Roles and users already linked to v1 are not upgraded automatically. AWS has proactively notified potentially affected customers. |
| What’s the risk | Any attachment that still references v1 keeps the over-privileged permissions and the full-org takeover risk wide open. |
Summary
A mis-scoped action in the legacy AmazonGuardDutyFullAccess AWS-managed policy allows any principal in the management account holding that policy to register an arbitrary delegated administrator for any Organizations-integrated service. By chaining this to highly privileged services such as IAM Identity Center (SSO) or CloudFormation StackSets an attacker can escalate from a single compromised management-account user or role to full control of every account in the organization, including persistence mechanisms.
Key Points
| Aspect | Detail |
| Root cause | organizations:RegisterDelegatedAdministrator was granted with Resource: * and no conditions in v1 of AmazonGuardDutyFullAccess. |
| Prerequisites | 1. Compromise of a management-account user or role that has the vulnerable policy attached. 2. Control of a member account to accept delegated-admin status for the target service. 3. The target service has not already been delegated to some other account. |
| Attack path | 1. Register attacker-controlled account as delegated admin for sensitive service such as IAM Identity Center or CloudFormation StackSets. 2. Manage org-wide SSO groups / permission sets or push malicious stack sets to every account. 3. Add attacker identity to an Organization Admin group or deploy backdoors across accounts. |
| Impact | Complete compromise of all member accounts and, through SSO privilege sets, the management account itself. |
| Fix | AWS released policy version 2 with scoped resource restrictions. Administrators must detach v1 and attach v2 (or a custom least-privilege policy) for every affected role/user. |
| Current risk | Any attachment that still references v1 retains the full-org takeover vector. |
Recommended Actions
- Inventory every role and user attached to AmazonGuardDutyFullAccess.
- Re-attach the policy with version 2.
- Audit CloudTrail for unexpected RegisterDelegatedAdministrator, EnableOrganizationAdminAccount, or cross-account SSO activity.
- Isolate and tightly control access to delegated administrator accounts. Reclassify these accounts as the relevant Tier, considering their elevated privileges and potential impact across the entire organization.
Statement From AWS
Cymulate's research includes a finding that under a very limited set of circumstances the older AmazonGuardDutyFullAccess managed policy could result in granting permissions to a principal in the Organizations management account to take actions beyond those that might be expected. In response, we have released an updated version of the AmazonGuardDutyFullAccess managed policy called AmazonGuardDutyFullAccess_v2.
This updated policy restricts the organizations:RegisterDelegatedAdministrator permission to allow delegation of only the GuardDuty service to the target account. All customers who have an IAM principal in their Organizations management impacted by this finding have been notified by email and by their Health Dashboard of this enhancement, with instructions on updating those principals to use the AmazonGuardDutyFullAccess_v2 managed policy.
Starting on August 26, 2025, customers will no longer be able to attach the older managed policy (AmazonGuardDutyFullAccess) to any IAM principal. Only the new managed policy (AmazonGuardDutyFullAccess_v2) can be attached. However, any principal with the older policy still associated with it will continue to work as before.
We would like to thank the security researchers from Cymulate for helping us to protect customers by collaborating with us on this research through the coordinated disclosure process.
Featured Resources
Task Scheduler– New Vulnerabilities for schtasks.exe
New vulnerabilities in Windows Task Scheduler allow attackers to bypass UAC, poison logs, and overwrite security event files
EscapeRoute: Breaking the Scope of Anthropic’s Filesystem MCP Server
(CVE-2025-53109 & CVE-2025-53110)
Critical flaws in Anthropic’s MCP Filesystem Server allow attackers to escape the sandbox, access sensitive files, and execute arbitrary code.
Path Traversal Vulnerability in AWS SSM Agent's Plugin ID Validation
A path traversal flaw in AWS SSM Agent lets attackers execute root-level scripts by abusing unsanitized plugin IDs.