AWS STS Role Assumption by User

This detection rule identifies when an IAM user assumes a role in AWS Security Token Service (STS) within an AWS environment. The AWS Security Token Service (STS) allows users to request temporary, limited-privilege credentials for accessing AWS resources. While legitimate role assumption is common for authorized access, adversaries can abuse this mechanism to escalate privileges or move laterally within a compromised AWS account. This behavior is detected by monitoring AWS CloudTrail logs for AssumeRole events from IAM users. The rule focuses on identifying potentially malicious role assumptions by correlating the user identity, assumed role, and source information.

Attack Chain

1. An attacker gains initial access to an AWS account as an IAM user, potentially through compromised credentials or an exposed access key.
2. The attacker enumerates available IAM roles within the AWS environment to identify roles with elevated privileges or access to sensitive resources.
3. The attacker calls the AssumeRole API in AWS STS, requesting temporary credentials for the target role, using a roleSessionName for context.
4. The STS service validates the request and, if authorized, issues temporary credentials consisting of an accessKeyId, secretAccessKey, and sessionToken.
5. The attacker configures their AWS CLI or SDK with the temporary credentials obtained from the STS service.
6. The attacker uses the temporary credentials to access AWS resources and perform actions permitted by the assumed role, such as modifying security groups, accessing S3 buckets, or launching EC2 instances.
7. The attacker may attempt to further escalate privileges by assuming additional roles or creating new IAM users with administrative privileges.

Impact

A successful role assumption can grant an attacker access to sensitive data, allow them to disrupt critical services, or provide a foothold for further attacks within the AWS environment. While this rule has a low severity, a high volume of alerts should be reviewed as it could indicate ongoing lateral movement and privilege escalation. The impact of a successful attack can range from data breaches and service disruptions to complete compromise of the AWS environment.

Recommendation

• Deploy the Sigma rule provided below to your SIEM and tune for your environment to detect suspicious role assumptions.
• Investigate any alerts generated by the rule by reviewing the associated CloudTrail logs, specifically the aws.cloudtrail.user_identity.arn and aws.cloudtrail.resources.arn fields.
• Implement additional monitoring for high-risk roles with elevated permissions, and create exceptions for trusted patterns.
• Regularly review IAM policies and roles to minimize the risk of privilege escalation.
• Refer to the AWS STS documentation for more details on managing and securing AWS STS in your environment.