AWS STS Role Chaining for Privilege Escalation and Persistence

This threat brief addresses the potential abuse of AWS STS role chaining. Role chaining is a legitimate AWS feature where an assumed role is used to assume another role through the AWS CLI or API. However, malicious actors can exploit this functionality to escalate privileges if the second assumed role has broader permissions than the initial role. The chaining can also be used as a persistence mechanism since each AssumeRole action results in a refreshed session token with a maximum duration of one hour. This activity is detected by monitoring CloudTrail logs for the first occurrence of a role (identified by aws.cloudtrail.user_identity.session_context.session_issuer.arn) assuming another role (aws.cloudtrail.resources.arn). Detection focuses on identifying novel role-chaining relationships to highlight potentially unauthorized activity.

Attack Chain

1. An attacker gains initial access to an AWS account, possibly through compromised credentials or an exposed access key.
2. The attacker uses the compromised credentials to assume an initial IAM role using sts:AssumeRole. This action is logged in CloudTrail with the AssumeRole event.
3. The attacker then uses the temporary credentials obtained from the first role to assume a second IAM role, again using sts:AssumeRole. The aws.cloudtrail.user_identity.session_context.session_issuer.arn field identifies the first role, and the aws.cloudtrail.resources.arn field identifies the second role.
4. If the second role has more permissions than the first, the attacker can use the second role's credentials to perform actions they couldn't do before (privilege escalation). This could involve actions related to IAM, EC2, S3 or other AWS services.
5. The attacker leverages the increased permissions to access sensitive data stored in S3 buckets, modify IAM policies to grant themselves further access, or launch EC2 instances for malicious purposes.
6. Each AssumeRole action generates new temporary credentials, effectively refreshing the attacker's session.
7. The attacker maintains persistence within the AWS environment by repeatedly chaining roles to refresh temporary credentials.
8. The attacker achieves their objective, such as exfiltrating sensitive data, deploying malware, or disrupting services.

Impact

Successful exploitation via role chaining can lead to significant privilege escalation within an AWS environment. This can enable attackers to gain unauthorized access to sensitive data, modify critical infrastructure configurations, and potentially disrupt business operations. The persistence aspect of role chaining can allow attackers to maintain a foothold in the environment for extended periods, making detection and remediation more challenging. The blast radius can extend across multiple AWS accounts if cross-account role chaining is involved.

Recommendation

• Deploy the Sigma rule Detect AWS STS Role Chaining to identify instances of role chaining in AWS CloudTrail logs. Tune the rule to exclude expected role-chaining patterns based on your environment (aws.cloudtrail.user_identity.session_context.session_issuer.arn, aws.cloudtrail.resources.arn).
• Monitor CloudTrail logs for AssumeRole events where aws.cloudtrail.user_identity.type is AssumedRole, focusing on unusual or unexpected role combinations.
• Implement least privilege policies for all IAM roles, limiting trust policies to only required principals. Periodically review role chaining patterns to validate necessity.
• Use the AWS STS Role Chaining Sigma rule to identify potential role chaining attempts and investigate accordingly.
• Correlate CloudTrail logs with other security events (e.g., GuardDuty alerts) to identify potential privilege escalation or data exfiltration activities following role chaining.
• Enable MFA where possible on AssumeRole operations.