AWS Organizations

AWS Organizations work differently than Azure Tenants, or other hierarchical common IT-structures, due to AWS accounts being per default more of a standalone kind of thing. Every AWS account in an AWS Organization can be or become standalone, even if it was initially created via an organization. It is better to think of organizations more like an agreement between adult accounts, where they agree on the manager who can make the rules and the other accounts are allowed to join.

This has some consequences for attackers and defenders of organizations. A compromised member account is hard to recover already, however, if an organization does not employ the right polices it can be next to impossible. In this post I will explain why that is, where the issue lays, what the attack vectors look like and how organizations can be made more robust with SCPs.
So stay a while and listen.

Quote from the AWS documentation:
AWS Organizations is an account management service that enables you to consolidate multiple AWS accounts into an organization that you create and centrally manage. AWS Organizations includes account management and consolidated billing capabilities that enable you to better meet the budgetary, security, and compliance needs of your business. As an administrator of an organization, you can create accounts in your organization and invite existing accounts to join the organization. (see)

Because nothing in AWS is ever confusing, just take a quick look at this structure diagram, which should answer all questions

Usually, one account gets created first for a company, let’s call it managment@arasaka.corp, this can then be the designated management account. From there new AWS accounts can be generated via the organization or existing ones can join. Because this gets confusing very fast, let’s just focus on accounts that get created from the organization and let’s ignore org-joins to keep it more understandable for meow.

The one role to rule them all

When you have an organization, you can create new AWS accounts for them which are part of the organization. For this an email and a name is all that is required, as billing is now taken care of by the organization, or to be more precise by the management account of the org.

When you create an AWS account like this, as you can see in the screenshot, a role is created with it.

This role, by default called OrganizationAccountAccessRole is also created within the new account of Hanako. The idea here is, that a user with sufficient privileges within the management account can assume this role inside Hanakos - or other member - accounts of the Arasaka org to gain access to their member accounts. More on this role -> here

-> So, basically this role is there for admins of an organization to access and administrate member accounts. <-

So you just got Phished

Okay, you are the admin of Arasakas AWS managment account and now Saburo calls you, cause he recieved an email urging him to log into his AWS root account to confirm something and now he lost control of his account. This is the third time he has done this.

So you use your own admin account inside the managment account of the Arasaka org, to assume the OrganizationAccountAccessRole and with it access the AWS account of Saburo. There you try to recover his account, delete the crypto miners and so on.

Now, lets talk little more real here. If you loose an IAM account, you can recover, but if you loose your root account that is on another level. Some organizations therefore do not allow the login for a root account, only IAM login, so they can recover better. If you do not know these terms read -> here

A common scenario from the phishing is to backdoor the account, or to take it over, to either use it for lateral movement, steal data or deploy crypto miners.

SIDE NOTE Sometimes I read tips on how to disable that member accounts can leave an organization, and policy examples for it. To be honest this is kinda funny, because if you ever tried to close multiple AWS accounts or an organization, you know what is involved here. A member account can only leave an organization if it fullfilles the requirements of a non-org account, which means it needs at least:

Support plan
Provide and verify the required contact information
Provide a current payment method

So an attacker that would want to leave the AWS Organization of the compromised member account, would need to fill in personal information, verify a phone number and verify a credit card. But billing is already done via the organization, so if you deploy a crypto miner it makes less than zero sense to leave the organization to pay for it yourself, even if that would work easily. So in short, unless in freak scenarios, this is not the main attack scenario to worry about. SIDE NOTE END

Oh boi here I go killin again

As an attacker, who has just compromised an account of an organization, you want to be left in peace, fly under the radar, and then do your thing. So, if you already have control you want to keep it! Now, remember the admin of the Arasaka management account and the OrganizationAccountAccessRole?

So, this role is not only present in the management account, the way AWS works it also must be present in each member account that gets created in the way shown above. You can see this role, just like any role in the IAM role overview. For example here in Hanakos account:

Well, you can just delete that.

Specifically how that goes depends on the org setup, permissions, polices etc. and can be trivial or it might require some AWS cli deep feymagic from the old woods, but it is not immortal, it can be killed, felled, and beaten.

So back to the simple phishing example of Saburo. In this case what happens if the attacker deletes the OrganizationAccountAccessRole?

Well, that means, the Arasaka management account can no longer assume this role in the member account since it no longer exists, and therefore not access it. At the same time the account is still billed via the organization. Meaning if control is lost by the member and it cannot be accessed from the management account, while a crypto miner is accumulating cost, you are pretty much down to call it a day and open a support case for AWS.

This is actually kind of the best scenario, because you know it happened. If the whole thing is done stealthier control of an account can be held for a long time. When the costs have risen one then tries to log in and it does not work and the head scratching begins. It is not as if you get a notification in AWS org view or something that the role is missing. You do not know what is going on.

Item #: SCP-426

An organization can define polices that get inherited and used by all members. These are called SCP and sadly have nothing to do with the SCP-Foundation, although I suspect they knew what they were doing when they were naming them - cause they too can be reality shattering :)

These SCPs must be enabled for an organization and can be found under the policy section inside AWS org area. The default SCP basically is an allow all. From here policies can be created, attached combined etc.

So, in the case described here how could an SCP help? Well, by adding a policy to prevent a member account from deleting the OrganizationAccountAccessRole.

Let’s take a look on how this could be done, specific implementation will depend on your setup, but to have something to talk about:

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "NoDeleteExample",
			"Effect": "Deny",
			"Action": [
				"iam:DeleteRole"
			],
			"Resource": [
				"arn:aws:iam::*:role/OrganizationAccountAccessRole"
			]
		}
	]
}

The above SCP sets a deny on the Action iam:DeleteRole. But because not allowing any role deletion is useless overkill it only operates on the resource of the OrganizationAccountAccessRole. In general, it is not the best idea to work with wildcards * in policies, however, besides hardcoding an account id here, if have not yet identified a better way to roll this out over multiple accounts and have it work for not yet created ones. But then again, I am no admin, just a very smol cloud hacker dude, you might find a better solution.

If the name of the role is something else, of course one would have to change it here also. But be aware from an attacker’s perspective I do not care what it is called, you can generally find it.

Well, in this case its no longer pawsible to just simply delete the role from the portal or with the cli, that is a good thing.

But, I was playing around with it and one still has options, for example by manipulating policies and working with guardrails one can try and severely limit the role, of course completely dependent on the setup of the accounts. Then again its more about damage control and not making it super easy for attackers, purrfect safety does not exist.

What does AWS have to say?

So yeah, their answer to me after explaining it to them was pretty clear. They see this as the customers responsibility. Which, I thought a little let’s say cheap, because I have not seen this discussed and admins working in AWS, whom I have talked to, did not know at all about this issue.

To be honest I am not completely sure if the person resolving this issue thoroughly understood it. I say this because the answer was a little lackluster and had sentences like this one: “The security concern you have reported cannot be resolved by AWS but must be addressed by the customer, who may not be aware of or be following our recommended security best practices.” It’s kinda funny because there is no recommended practice to protect this role at the writing of this blogpost and AWS does not tell them, but thanks to the shared responsibility model it’s in the customer domain, classic.

You made it

Okay, I hope I could somewhat explain an issue in AWS Organizations, stemming from the way AWS works and by having this role not protected, however, there are reasons not to, so I can kinda understand why this is not the default policy, maybe this will change tho.

With this knowledge and some idea on how to protect this role via SCPs you can take steps to make your AWS org a little more secure, or you can spend the next days reading texts from the SCP-Foundation, you do you.

Until next time friendows.