ACM.153 Logging into a new account created for an organization and adding MFA
Part of my series on Automating Cybersecurity Metrics. The Code.
In my last post I showed you how you can automate the creation of an AWS organization.
Automated AWS Organization Creation
I’ll add that to my GitHub repository in a bit and add to it. But first let’s reset the user name and password for the root user we created in our new AWS organizations account and add MFA. The root user of an account is all powerful in that account until you take steps to restrict it.
One step we’ll want to take immediately in a new account and organization is to add MFA to the root user created when we added the governance account to our organization. We want to create our SCPs in that governance account but haven’t created the resources in that account to do that yet. To be safe in the meantime we’ll go ahead and take steps to lock down the account a bit more.
Considerations for new AWS Organizations Accounts
Here are a few tips when creating new AWS accounts:
As mentioned in my first post create an email alias for your AWS account root users, not someone’s personal email. I explained why here:
re:Boot ~ Creating an AWS Account
In a large company, consider a naming convention like this, prefixed with aws, so you can find all the email aliases associated with your AWS accounts easily in your list of email addresses and aliases at your company.
>>> aws-[account_name]@[your_domain].com
Always test the email address to make sure it works! You might not notice a typo or you have a problem with your email and then you won’t be able to get into that new account to reset the password.Be sure you double check the domain spelling because if you do not own that domain you will have a hard time getting control of the account root even though the account is registered to your organization. I wrote about my struggles trying to delete an account from my organization when I had a typo in the domain in the past — and I couldn’t get into the email. AWS makes this very, very difficult to resolve. I contacted AWS support and went around in circles with them and finally gave up. Others have written about this as well (see below). I am going to try to move my resources to a new AWS account and completely delete the account and organization to see if that works eventually. You can also pay for an register a domain you don’t need — if it is available. So many problems with this and I wish AWS would make this easier to fix. If you create the initiation of an AWS account *from your Organization* you should also be able to delete it and specify that the organization will pay any outstanding bill. #awswishlisthttps://medium.com/media/b3d3a89258d7c022eeead5e3100a3434/hrefWe can create an Service Control Policy to restrict the root user on new accounts. We’ll take a look at that later, because first, I want to be able to get into the governance account and create SCPs from there.AWS Service Control PoliciesLetting Governance Teams Govern
Log into the root account for your new AWS organizations account
How do you log into a new account as the root user? We didn’t get a password along the way (which could be a good thing if you consider my prior posts on setting up new users and the password complications.) To log into as the root user for a new AWS account, you have to reset the password.
Log out of any other AWS accounts you are logged into. If it is an AWS SSO account that you are logged into you need to return to the master AWS SSO dashboard and logout from that screen. The logout link from within an account does not work.
You may also need to clear your cookies and cache in your browser if you continue to have problems logging into the new account.
Alternatively, use an incognito browser window to log into two different accounts at the same time.
Head over to https://aws.amazon.com (the AWS Portal).
Click Sign in:
Here’s where I have an issue because I was previously logged in as an SSO user. Even though that user was logged out and the session has expired, I get redirected to the AWS SSO login screen. I need to get to the screen where I can login as a root user of an AWS account via IAM instead.
I noticed that hitting the back button takes me to the screen I need:
With the Root user radio button selected, enter the account email alias you used when you set up your second AWS Organizations account named Governance in the last post. Perhaps you used:
Enter that email and click next.
Click Forgot password?
You may need to fill out a captcha along the way.
Go to your email and click the link to reset the password.
Enter a new password and save it.
What’s the risk associated with the root account for new accounts in an AWS Organization?
It is at this point you may want to consider your process for how you track and save root passwords for all your AWS accounts. Alternatively we can restrict the root user as mentioned above with an SCP which we’ll take a look at later.
Remember how I told you access to domains and email is critical for the security of your cloud accounts? Anyone with access to the email address for a new account can reset the root password — before you have added MFA — and gain access. At that point, the attacker would have administrative access to that account.
What could an attacker do with that access? Create cloud resources using your money for things like nefarious infrastructure used in attacks and cryptominers.
One method of locking down this access is to immediately add MFA to these AWS Organizations root accounts for new accounts you create. Define your process for creating new accounts and have a mechanism to test that this step has been properly completed. A separate person should test the step other than the person who completed the step.
Consider who can access the MFA device in the future, under what circumstances, and how access will be granted. As mentioned in a prior post you want to consider creating a root of trust. Consider separate MFA device(s) for root access to your AWS Organizations accounts and lock them away in a safe, vault, or your organization’s password management system, if you have one. People will require special permission to use those MFA devices and the credentials for these particular accounts.
You should probably have different devices for different types of accounts, or even all accounts, depending on your organization’s risk management strategy. I would highly recommend a separate device for the root or management account in an AWS Organization. You may have different people manage the safe that contains the MFA devices and the vault or password manager that contains the passwords.
Alternatively, or in addition to the above, you restrict the admin user via policies in AWS and consider carefully who can change those policies and how.
Login to your new AWS Organizations account and add MFA
Next, login to your AWS Organizations account and add MFA the same way we did in the post where we set up our new AWS account.
re:Boot ~ Creating an AWS Account
Note that I noticed some odd behavior when I initially logged into this new account. First I got redirected to the AWS management console. When I tried to click the link to the management console at the top of the screen, I was redirected to the login screen again. I logged in and the first captcha which I’m pretty sure I entered correctly did not work. The second attempt worked. Then I entered the password again and I was able to login. The moral of this paragraph is: If you don’t succeed, try, try again.
Remember that if you’re following along with me here you want to go to IAM, not IAM Identity Center, for reasons I have written about in prior posts.
Same as before you’ll see a warning stating that you need to add MFA to the root user, and the second warning is not applicable to this new account.
Click Add MFA and follow the same procedure we used for the new AWS account created in the above post to add MFA to your root user.
You can also create an account alias as I explained that prior post.
Notice that if someone gains access they can also change the account email name and password here:
Refer to my warning above about not being able to remove or delete accounts (easily) from AWS Organizations if you do not have access to the email and billable resources already exist in that account. You’ll want to make sure that you restrict who can crate accounts and who can change these settings for your accounts by logging in as the root account user.
In the next post we’ll consider the roles used to access AWS Organizations accounts.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
If you liked this story ~ use the links below to show your support. Thanks!
Support:
Clap for this story or refer others to follow me.
Follow on Medium: Teri Radichel
Sign up for Email List: Teri Radichel
Follow on Twitter: @teriradichel
Follow on Mastodon: @[email protected]
Follow on Post: @teriradichel
Like on Facebook: 2nd Sight Lab
Buy a Book: Teri Radichel on Amazon
Buy me a coffee: Teri Radichel
Request services via LinkedIn: Teri Radichel or through IANS ResearchAbout:
Slideshare: Presentations by Teri Radichel
Speakerdeck: Presentations by Teri Radichel
Recognition: SANS Difference Makers Award, AWS Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Sofware Engineering, Master of Infosec
How I got into security: Woman in tech
Company (Penetration Tests, Assessments, Training): 2nd Sight Lab
Cybersecurity for Executives in the Age of Cloud on Amazon
Cloud Security Training (virtual now available):
2nd Sight Lab Cloud Security Training
Is your cloud secure?
Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question?
Ask Teri Radichel by scheduling a call with IANS Research.
More by Teri Radichel:
Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
Risk Associated with the Root User for a New AWS Organizations Account was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
