Assume Root into Organization Member Account
AWS Specific Technique
AWS Specific Content
A prerequisite for this technique is that a threat actor has already gained control of exposed credentials from an AWS Organizations management account with permissions to perform AWS Security Token Service (STS) actions. Threat actors may use compromised credentials to assume the root user role in member accounts of the compromised Organization and may subsequently disable security controls protecting the account root user.
After obtaining initial access, threat actors may leverage the
sts:AssumeRoot API call to escalate privileges to root-level access within member accounts of an AWS Organization. Note that centralized root access must be in place to assume the root user in member accounts.Once root access is obtained, threat actors may attempt to disable multi-factor authentication (MFA) on the root user using the
iam:DeactivateMFADevice API call, removing a critical authentication barrier. Additionally, threat actors may disable the root login profile to prevent legitimate administrators from accessing the account through the AWS Management Console, locking out authorized users from console access.Detection
AWS Specific Content
You can use the Event history page in the AWS CloudTrail console to view the last 90 days of management events in the affected account and AWS Region for actions pertaining to root such as
sts:AssumeRoot, iam:DeactivateMFADevice, and iam:DeleteLoginProfile. A separate CloudTrail trail will provide an ongoing record of events in your AWS account for the past 90 days and can be configured to log events in multiple regions.It is also possible to create CloudWatch metric filters to monitor specific STS and IAM API calls related to root account access and configure alerts when suspicious patterns are detected. See Monitor and Notify on AWS Account Root User Activity.
Key indicators of compromise include
sts:AssumeRoot API calls from unfamiliar source IP addresses or user agents, iam:DeactivateMFADevice calls targeting root user MFA devices, and iam:DeleteLoginProfile calls removing root user console access.You can track this activity in AWS CloudTrail logs to determine the actions taken during a session. Under
userIdentity sessionContext, the value assumedRoot will be set to true for actions performed by an assumed root session. See example here.Mitigation
AWS Specific Content
You can restrict assume root permissions to only a designated break-glass role using SCPs from the Organization management account:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "sts:AssumeRoot",
"Resource": "*",
"Condition": {
"StringNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/AuthorizedBreakGlassRole"
]
}
}
}
]
}
You can also use IAM Access Analyzer to regularly review and verify access and manage permissions across your AWS environment, which will highlight AWS identities with excessive permissions and the actions performed by those identities. Limit use of the root user to tasks that specifically require root credentials.