- Phishing with AWS Account Management
- Delegated Policies – New Features, New Security Risks
- Enumeration Tool for AWS Organizations
- Defense
- Final Thoughts & Conclusion
Phishing with AWS Account Management
AWS Account Management is an organization-integrated feature that offers a few simple APIs for updating or retrieving an AWS account’s contact information. This presents an interesting phishing vector.
Assuming we have compromised Account A, enable trusted access for Account Management via the CLI. Note Account Management supports delegated administration as well but we are focusing on trusted access for this portion.
With trusted access now enabled, update the contact information for Account B changing items like address or full name to assist in a future social engineering attack. Note: I have not attempted social engineering with AWS by calling the AWS help desk or other contacts, nor am I sanctioning that. This would be more from the perspective of trying to trick an engineer or another representative who manages an AWS account at the company to get access.
Delegated Policies – New Features, New Security Risks
AWS Organizations recently announced a new delegated administrator feature on November 27, 2022. To summarize this release, AWS Organizations now gives you the ability to grant your delegated administrators more API privileges on top of the read-only access they previously gained by default. Only a subset of the Organization APIs dealing primarily with policy manipulation can be allow-listed for delegated administrators, and the allow-list implementation happens in the management account itself.
In the image below, we used Account A to attach a Service Control Policy (SCP) to Account C that specifically denies S3 actions. A SCP can be thought of as an Identity and Access Management (IAM) policy filter. SCPs can be attached to accounts (like below) or organization accounts (OUs) and propagate downwards in terms of the overall organization hierarchy. They override any IAM privileges at the user/role level for their associated attached accounts. So even if users or roles in Account C have policies normally granting them S3 actions, they would still be blocked from calling S3 actions as the SCP at the organization-level takes precedence.
Given this setup and the newly released feature, if a management account grants delegated administrators overly permissive rights in terms of policy access/manipulation, delegated administrators could remove restrictive SCPs from their own account or other accounts they control.
To enable the newer feature, navigate to the Settings tab in Account A and click “Delegate” in the “Delegated administrator for AWS Organizations” panel. In the delegation policy’s “Action” key, add organization APIs from the subset provided in the AWS user guide.
Note that the actions added include the API calls for attaching and detaching any policy (AttachPolicy/DetachPolicy). Once the actions have been chosen, they are only granted to the member account if the delegation policy lists the member account number as a Principal (Account C in this scenario).
With this setup complete, we can switch to the attacker’s perspective. Assume that we have compromised credentials for Account C and already noted through reconnaissance that the compromised account is a delegated administrator. At this point in our assessment, we want to get access to S3 data but keep getting denied as seen below in Figure 4.
This makes sense as there is an SCP attached to Account C preventing S3 actions. But wait... with the new AWS Organization feature we as delegated admins might have additional privileges related to policy management that are not immediately evident. So, while still in Account C’s AWS Organization service, try to remove the SCP policy created by Account A from Account C.
Since the management account delegated us the rights to detach policy, the operation is successful, and we can now call S3 APIs as seen below in Figure 6.
Rather than a trial-and-error method, you could also call the “describe-resource-policy” API as Account C and pull down the policy that exists in Account A. Remember that delegated administrators have read-only access by default so this should be possible unless otherwise restricted.
Enumeration Tool for AWS Organizations
A lot of what I covered is based off AWS Organization enumeration. If you compromise an AWS account, you will want to list all organization-related entities to understand the landscape for delegation and the general organization structure (assuming your account is even in an organization).
To better assist in pentesting AWS Organizations, I added AWS Organizations support to the open-source AWS pentesting tool Pacu. I also wrote an additional Pacu enumeration module for AWS Organizations (organizations__enum). These changes were recently accepted into the Pacu GitHub project and are also available in the traditional pip3 installation procedure detailed in the repository's README. The two relevant forks are located here:
- https://github.com/RhinoSecurityLabs/pacu/pull/326
- https://github.com/RhinoSecurityLabs/pacu/pull/335
Note that the GitHub Pacu project contains all APIs discussed thus far, but as you might note in the screenshots below, the pip installation just does not include 1 read-only API (describe-resource-policy) along with 1-2 bug fixes at this time.
I won’t cover how Pacu works as there is plenty of documentation for the tool, but I will run my module from the perspective of a management account and a normal (not a delegated administrator) member account.
Let’s first run Pacu with respect to Account A. Note that the module collects many associated attributes ranging from a general organization description to delegation data. To see the collected data after running “organizations__enum,” you need to execute “data organizations.” My module also tries to build a visual graph at the end of the enumeration using the account.
At the other extreme, what if the account in question is a member account with no associated delegation? In this case, the module will still pick up the general description of the organization but will not dump all the organization data since your credentials do not have the necessary API permissions. At the very least, this would help tell you at a glance if the account in question is part of an organization.
Defense
The content discussed above is not any novel zero-days or represents an inherent flaw in AWS itself. The root cause of most of these problems is exposed cleartext credentials and lack of least privilege. The cleartext credentials give an attacker access to the AWS account, with the trusted access and delegated administration allowing for easy pivoting.
As mentioned in part one, consider a layered defense. Ensure that IAM users/roles adhere to a least privilege methodology, and that organization-integrated features are also monitored and not enabled if not needed. In all cases, protect AWS credentials to avoid access to the AWS environment allowing someone to enumerate the existing resources using a module like the Pacu one above, and subsequently exploit any pivoting vectors. To get a complete picture of the organization’s actions, ensure proper logging is in place as well.
The following AWS articles provide guidance pertaining to the points discussed above. Or connect with NetSPI to learn how an AWS penetration test can help you uncover areas of misconfiguration or weakness in your AWS environment.
- https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html
- https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_
member-acct.html - https://docs.aws.amazon.com/organizations/latest/userguide/orgs_delegate_
policies.html - https://docs.aws.amazon.com/cli/latest/reference/organizations/describe-resource-policy.html
- https://docs.aws.amazon.com/organizations/latest/userguide/orgs_security_
incident-response.html - https://docs.aws.amazon.com/accounts/latest/reference/monitoring-cloudtrail.html
Final Thoughts & Conclusion
The architecture and considerable number of enabled/delegated service possibilities in AWS Organizations presents a serious vector for lateral movement within corporate environments. This could easily turn a single AWS account takeover into a multiple account takeover that might cross accepted software deployment boundaries (i.e. pre-production & production). More importantly, a lot of examples given above assume you have compromised a single user or role that allowed for complete control over a given AWS account. In reality, you might find yourself in a situation where permissions are more granular so maybe one compromised user/role has the permissions to enable a service, while another user/role has the permissions to call the enabled service on the organization, and so on.
We covered a lot in this two-part series on pivoting clouds in AWS Organizations. To summarize the key learnings and assist in your own replication, here’s a procedural checklist to follow:
- Compromise a set of AWS credentials for a user or role in the compromised AWS Account.
- Try to determine if you are the management account, a delegated administrator account, a default member account, or an account not part of an organization. If possible, try to run the Pacu “organizations__enum” module to gather all necessary details in one command.
- If you are the management account, go through each member account and try to assume the default role. Consider a wordlist with OrganizationAccountAccessRole included. You can also try to leverage any existing enabled services with IAM Identity Center being the desired service. If necessary, you can also check if there are any delegated administrators you have control over that might assist in pivoting.
- If you are a delegated administrator, check for associated delegated services to exploit similar to enabled services or try to alter existing SCPs to grant yourself or other accounts more permissions. If necessary, you can also check if there are any other delegated administrators you have control over that might assist in pivoting.
Amazon Web Services (AWS) is a cloud solution that is used by a large variety of consumers from the single developer to the large corporate hierarchies that make up much of our day-to-day lives. While AWS certainly offers many developer solutions, its roughly 33% cloud share, combined with its vertical customer spread, makes it an attractive target for hackers. This has resulted in numerous presentations/articles regarding privilege escalation within a single AWS account.
While this is certainly instructional for smaller scale models or informal groupings of AWS accounts, a singular mindset with regard to AWS account takeovers might result in missed opportunities for larger corporate environments that specifically leverage AWS Organizations for account management and centralization. Identifying and exploiting a single misconfiguration or credential leak in the context of AWS Organizations could result in a blast radius that encompasses several, if not all, of the remaining AWS company assets.
This article uses an organization I built from my AWS penetration testing experience to both describe several key points of AWS Organizations theory and demonstrate exploitable opportunities in existing AWS solutions.
In part one of this two-part blog series, we’ll provide an “easy win” scenario and subsequently cover more involved pivoting opportunities with organization-integrated services. In part two, explore today’s AWS security features and tools for enumeration – including a Pacu module I built to assist in data collection.
Table of Contents
- AWS Accounts as a Security Boundary
- AWS Organizations Vocabulary
- Easy Win with Account Creation
- Trusted Access and Delegated Administration Review
- Leveraging IAM Access Analyzer Through Trusted Access
- Leveraging IAM Access Analyzer Through Delegated Administration
- IAM Identity Center (Successor to SSO) – Complete Control/Movement over
Member Account - Defense
- Conslusion
- Appendix: CLI Commands
AWS Accounts as a Security Boundary
To differentiate one AWS account from another, AWS assigns each account a unique 12-digit value called an “AWS Account Number” (ex. 000000000001). For notation’s sake (and my own sanity), I will be swapping out 12-digit numbers with letters after initial account introductions below. These AWS accounts present a container or security boundary from an information security standpoint.
Entities created by a service for an individual developer’s AWS account would not be accessible to other AWS accounts. While both Account A and Account B have the S3 service, making a “bucket” in the S3 service in Account A means that bucket entity exists only in Account A, and not Account B.
Of course, you can configure resources to be shared cross-account, but for this generalization we are focusing on the existence and core ownership of the resource. Since AWS Organizations groups a lot of accounts together in one central service, it presents several opportunities to tunnel through these security boundaries and get the associated account’s resources/data.
AWS Organizations Vocabulary
Before we dive into organizations, let’s run through some quick vocabulary. AWS Organizations is an AWS service where customers can create “organizations.” An organization is composed of one or more individual AWS accounts. In Figure 2 below, Account A is the account that created the organization and, as such, is called the management account.
The management account has administrator-like privileges over the entire organization. It can invite other AWS accounts, remove AWS accounts, delete an organization, attach policies, and more. In Figure 2, Account A invited Account B and Account C to join its organization. Accounts B and C are still separate AWS accounts, but by accepting Account A’s invitation their references appear in Account A’s organization entity. Once the invite is accepted, Accounts B and C become member accounts and, by default, have significantly less privileges than the management account.
A default member account can only view a few pieces of info associated with the management account. It cannot read other organization info, nor can it make changes in the organization. Default member accounts are so isolated that they do not have visibility into what other member accounts exist within the organization, only seeing themselves and the management account number.
Organizational Units (OUs) can be thought of as customer-created “folders” that you can use for arranging account resources. Root is a special entity that appears in every AWS Organization and can be thought of as functionally equivalent to an OU under which all accounts exist.
A diagram of our sample organization is given in Figure 2. Account ***********0 (Account A) is the account in charge of managing the overall organization, Account ***********9 (Account B) is a member account holding pre-production data, and Account ***********6 (Account C) is a member account holding production data. Account B has a highlighted overly permissive role with a trust access policy set to *. For steps to set up an organization, refer to the AWS user guide.
Finally, note that navigating to AWS Organizations in a management account like Account A provides a different UI layout than AWS Organizations in a member account like Account C (Figure 3 versus Figure 4). Noticeably the lefthand navigation bar is different. Because member accounts have significantly less permissions with regard to the organization, navigating to “AWS Accounts” or “Policies” in a default member account returns permission errors as expected. These differences can aid testers in determining if they have access to a management or member account during AWS pentesting.
Easy Win with Account Creation
In Figure 2, along with most of this 2-part series, we will assume the member accounts in the organization were all pre-existing accounts that were added through individual invites. However, we will take a quick detour from this assumption to look at the AWS account creation feature as this can return an easy early win. This is shown in Figure 5.
Account A can choose to create an AWS account when adding it to the organization (as opposed to inviting a pre-existing AWS account like Accounts B and C). When this is done, AWS creates a specific role with a default name of OrganizationAccount AccessRole in the newly created member account. We will denote this newly created member account as Account D.
If we were to view the newly created OrganizationAccountAccessRole role in Account D, we would see that the role has AdministratorAccess attached to it and trusts the management account, Account A.
Thus, if we compromise credentials for a user/role with the necessary privileges in Account A, we could go through each member account in the AWS Organization and try to assume this default role name. A successful attempt will return credentials as seen below (Figure 8) allowing one to pivot from, in this case, Account A to Account D essentially as an administrator.
Again, this is the “easy win” scenario where you can go from relative control in a management account to administrator control in a member account. However, this might not be as feasible if a default role is not present in member accounts, or you are lacking permissions, or the member account was invited instead of created. In these cases, trusted access and delegated administration would be the next two features to consider.
Trusted Access and Delegated Administration Review
A handful of AWS services have set up specific features or API subsets that integrate with AWS Organizations (ex. IAM Access Analyzer) allowing their functionality to expand from a single AWS account to the entire organization. These organization-integrated features are in what we might consider an “off” state by default.
Per AWS, trusted access is when you “enable a compatible AWS service to perform operations across all of the AWS accounts in your organization.” In other words, you can think of trusted access as the "on” switch for these feature integrations. You “trust” the specific integrated feature thereby giving it “trusted access” to the organization data and associated accounts. The exact mechanism by which the feature operations are then carried out might involve service-linked roles created in each relevant account, but we will not examine this too closely for the purpose of this article. Just know trusted access generally grants the feature access to the entire organization.
Figure 9 demonstrates an expected trusted access workflow. Account A “enables” trusted access for one of the predefined organization-supported features which can then access the necessary management/member account resources. From this point onwards, the ability to influence/access/change the associated member accounts is feature specific with Access Analyzer, for example, choosing to access and scan each member account in the organization for trust violations. Enabling a feature like IAM Access Analyzer from the management account means it is an enabled service.
Delegated administration is a status applied to member accounts and gives the targeted member account “read-only access to AWS Organizations service data.” This would allow a member to perform actions like listing AWS organization accounts which was previously blocked per the UI errors in Figure 4. Additionally, the management account is “delegating” permissions to the member account with regards to a specific organization-integrated feature, such that the member account now has the permissions to run the specific feature within their own account on the entire organization.
Delegated administration is illustrated by the blue lines in the diagram above (Figure 9). Account A would make Account C a delegated administrator specifically for IAM Access Analyzer, and Account C could now run IAM Access analyzer on the entire organization. Making a member account a delegated administrator for certain services like IAM Access Analyzer means Access Analyzer is a delegated service in Account C.
Trusted access and delegated administration are extremely feature-specific concepts and not every organization-integrated feature supports both trusted access and delegated administrators. Learn more about the services you can use with AWS Organizations here.
Leveraging IAM Access Analyzer through Trusted Access
Let’s assume we have compromised credentials for Account A. We could end this attack here but looking in AWS Organizations we would see the additional AWS Accounts B and C listed as member accounts. While we have no credentials or visibility into either member account, we can use our organization permissions from Account A to enable trusted access for a service (or use an already-enabled service). This will allow us to gather data on the member accounts.
IAM Access Analyzer reviews the roles in an AWS account and tells you if any role trust relationships reach outside a “trust zone.” For example, if you have a role in an AWS account that allows any other AWS account to assume it, that role would get flagged as violating the trust zone since “any AWS account” is a much larger scope than a single AWS account.
When integrated with AWS Organizations, the Access Analyzer associated trust zone (and as a byproduct, scan range) expands to the entire organization. By giving IAM Access Analyzer trusted access in Account A, we can let the Analyzer scan each member account in the organization and return a report that would include Account B’s vulnerable role.
Before we begin, let’s review each account’s IAM roles. Note we only have access to Account A info, but both role lists are provided here for transparency. Account B has the role with the trusted entity of * that we want to both discover and exploit as Account A.
Figures 10: Account A & Account B Starting IAM Roles Before Exploitation
As the attacker in Account A, navigate to “Services” in AWS Organizations and observe that the IAM Access Analyzer is disabled by default. While we could use the UI controls to enable the organization-integrated feature, we could also make use of the AWS Command Line Interface (CLI) using the leaked credentials.
Next, navigate to the IAM Access Analyzer feature within the IAM service and create an analyzer. Since Access Analyzer is now an enabled service, we can set the “Zone of trust” to the entire organization.
Figures 12: Creating an Access Analyzer
After a few minutes refresh the page and observe that the overly trusting role from Account B is listed as an active finding demonstrating an indirect avenue for collecting Account B data as an Account A entity.
To complete the POC, observe how the attacker in Account A can take the knowledge from the vulnerability scan (specifically the role ARN), and assume the role in Account B thus pivoting within the general organization.
While not critical to know for the attacker steps listed above, we can review both accounts again and note that a new service-created role was created and used in each member account per the organization-integrated feature: AWSServiceRoleForAccessAnalyzer.
Figures 15: Account A & Account B IAM Roles After Exploitation
Leveraging IAM Access Analyzer Through Delegated Administration
To demonstrate delegated administrator exploitation regarding Access Analyzer, we need to enable delegated administration in our current organization environment. To do so from Account A, navigate to Account A’s Access Analyzer feature, choose to add a delegated administrator, and enter Account C’s account number.
Assume that we have compromised credentials for Account C (as opposed to Account A). Also assume we have no starting knowledge regarding the organization. As Account C, we can navigate to the AWS Organizations service, and can conclude that we are probably a member account since the management account number does not match our compromised account number (under the Dashboard tab), and the general UI layout is not that of a management account.
However, unlike a default member account, the “AWS Accounts” tab now returns all AWS accounts in the organization instead of permission denied errors. Remember that one of the first things a delegated administrator gets is read-only rights to the organization. Thus, we can further hypothesize that we are not just a default member account, but a delegated administrator.
But delegated administrator for what? Since there is no centralized UI component in a member account that lists all the delegated services, we would need to browse to each organization-integrated feature in Account C (IAM Access Analyzer, S3 Storage Lens, etc.) where the UI will hopefully tell us if we are the delegated administrator for that feature.
This is very cumbersome, and we can leverage the CLI in the Appendix of this blog with our delegated administrator read-only rights to speed along the identification process as seen below. First, we call “list-delegated-administrators” to reconfirm our previous hypothesis that Account C is a delegated administrator. We can then list out all the delegated services in relation to ourselves by passing in our own account number to “list-delegated-services-for-account.” In this case, we can see that Access Analyzer is listed (access-analyzer.amazonaws.com) as the delegated service.
From here, finding the overly trusting role in Account B plays out much the same way as the trusted access example. We create an analyzer in Account C (now having the option to choose the entire organization due to the delegated administrator status), wait for the results, and identify the overly trusting role in Account B. Note that during setup, my first analyzer did not pick up the role immediately so deleting the old analyzer and making a new one seems to be a good debugging step.
While the previous example started from the perspective of a compromised management account, delegated administrations show how a member account can still leverage organization-integrated features to access/analyze/change member accounts in the overall organization.
IAM Identity Center (Successor to SSO) – Complete Control/Movement over Member Account
IAM Identity Center can be thought of as another “easy win” where one can authenticate to any select member account allowing for full account takeover. While this does support delegated administration, we will just focus on trusted access. Once again, we will assume that you, as an attacker, have compromised credentials for Account A and are now in complete control of the management account.
Navigate to the IAM Identity Center service and choose to “Enable” it. This is the equivalent of enabling trusted access, and listing enabled services now returns IAM Identity Center as “sso.amazonaws.com”.