Cross-Account Access to an Account in an AWS Organization

ACM.158 Testing the ability to assume the default AWS Organizations role

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Cloud Governance | IAM | AWS Security

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post I created an organization root user in a new AWS account. This is the user that help us establish a root of trust in our AWS account structure. I explained the functions this user will perform in the last post.

In a post prior to that we created a new organization in our AWS account and a new AWS account. We looked at the role AWS created in that account. Now I’ll show you how to access another account in the organization using the OrgRoot user we created with the default role created by AWS Organizations when you created the account.

Obtaining temporary credentials for a role using the AWS CLI

If you’re following along, login to AWS as the OrgRoot user AWS management account.

Open CloudShell as I explained how to do in prior posts.

Run this command, but replace the XXX’s with the account number with the AWS Organizations role you are trying to assume.

[Note: Because Medium does not properly wrap text you’ll have to edit this to put this command on one line without the line breaks or add the appropriate line continuation characters]

aws sts assume-role --role-arn 
"arn:aws:iam::xxxxxxxxxx:role/OrganizationAccountAccessRole" 
--role-session-name OrgRootSession

As you can see, my execution of the command in CloudShell was successful.

Once we have the temporary credentials we can set environment variables to use that session as explained in this documentation, if using the AWS CLI. We may also have better long term solutions for automation but for our initial scripts this would work.

What we want to do is automate entire process of setting up a new account so we are not manually configuring things. We’ll take a look at that in an upcoming post.

Configuring an AWS CLI profile to assume a role

You can also configure a role profile using the AWS CLI as I’ve explained in prior posts. That’s the method we have been using to assume all the roles we’ve been using.

I explained how to configure the KMS administrator role in this post , for example. You could use the same method for the AWS Organizatons Role. However, the trust policy for this role does not currently require MFA so we would not need to add MFA to the configuration initially.

If we have to manually configure each role for each new account that also could take some time. Perhaps we can further automate this process.

Switching to the new account from the AWS Console

There’s another way I can switch to the role in the other account. From the AWS console in the top right menu click on your account and use name. It will look like this: OrgRoot @ [Your account name or number].

Choose Switch Role from the drop down menu.

Click Switch Role again.

Next enter your account number or alias, the organizations role, and a display name. Choose a color if you want.

If you see something like this it’s because the URL from where you switch roles contains the old account number. Just click the AWS logo at the top of the screen.

Now you can use this account just as if you had logged in directly.

Note that using the above process, you don’t get a list of accounts to log into like you do with AWS SSO which makes it a bit less user (and attacker) friendly. However, all someone needs to know is the account number or alias and the role they want to assume.

If you are using the default AWS Organizations role name that’s pretty easy for an attacker to guess. If the attacker gets access to the management account, they can list all the account numbers from the Organizations dashboard or query them with appropriate permissions. Either way, I think this approach is a bit risky.

Take a look at the default organizations role in the linked account

Navigate to the IAM Dashboard and you can see the roles in the account you just switched over to above.

If you take a look at the OrganizationAccountAccessRole we assumed, you can see there’s a link at the top to switch roles as well. You could use that link in the future to navigate to this account when you’re logged in as the OrgRoot user.

Now that we have confirmed that we can use an administrative user (or role) in the AWS management account to access a new AWS account, we need to consider who we want to create new AWS accounts and who we want to assume the role initially. We probably don’t want to have this all-powerful use in our management account in use at all times. It has total administrative access to any account in our organization with no conditions or restrictions.

We’ll fix that in an upcoming posts. We can change the role and we can also add a permission boundary to the administrative user we’re using to administer accounts.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab