Skip to content
Threat Feed
high advisory

Suspicious AWS STS AssumeRoot by Rare User and Member Account

Adversaries leveraging compromised user credentials can perform a suspicious AWS STS AssumeRoot action by a rarely observed user and member account combination to escalate privileges and gain unauthorized access to AWS resources, potentially leading to data exfiltration or resource manipulation.

This brief details the detection of suspicious AssumeRoot actions within Amazon Web Services (AWS) environments, a technique adversaries exploit for privilege escalation. When attacker-compromised user credentials are used to invoke the AssumeRoot action, it allows them to temporarily assume the root member account role, granting elevated access to specified AWS resources. This particular detection focuses on identifying instances where this action is performed by a user or principal that rarely assumes this role, or against a member account that is not typically targeted by that principal. Such activity can signify privilege escalation, lateral movement into new accounts, or the abuse of cross-account access paths, posing a significant risk of unauthorized access, data compromise, and resource manipulation within the AWS infrastructure.

Impact

A successful AssumeRoot action by an unauthorized entity grants them temporary but highly privileged access to the targeted AWS member account. This can lead to a wide array of damaging outcomes, including the creation of persistent backdoors via IAM changes (e.g., creating new users, modifying roles), disabling security controls like CloudTrail or GuardDuty to evade detection, or directly manipulating and exfiltrating sensitive data from services like S3, RDS, or DynamoDB. The blast radius can be significant, affecting core infrastructure, intellectual property, and customer data. Without timely detection and response, such an incident can result in severe financial loss, regulatory penalties, and reputational damage for the victim organization.

Recommendation

  • Deploy the Sigma rules in this brief to your SIEM and tune for your environment to detect suspicious AssumeRoot actions.
  • Ensure comprehensive AWS CloudTrail logging is enabled for all sts.amazonaws.com events, which is the log source for this detection.
  • When an alert fires, immediately investigate the aws.cloudtrail.user_identity.arn and aws.cloudtrail.resources.account_id fields to identify the calling principal and the affected member account.
  • Examine source.address, source.geo.*, and user_agent.original fields within the CloudTrail logs to understand the origin of the suspicious AssumeRoot call.
  • Correlate follow-on activity by searching for subsequent events where aws.cloudtrail.user_identity.access_key_id matches the temporary credentials issued by the AssumeRoot event.
  • Restrict sts:AssumeRoot usage by applying stringent IAM conditions, such as aws:PrincipalArn or aws:PrincipalOrgID, to limit which roles and identities can invoke this action.

Detection coverage 1

AWS STS AssumeRoot by Rare User and Member Account

high

Detects when the STS AssumeRoot action is successfully performed by a user that rarely assumes this role against a specific member account, potentially indicating privilege escalation or unauthorized access.

sigma tactics: defense_evasion, persistence, privilege_escalation techniques: T1078.004, T1098.003, T1548.005 sources: cloud, aws.cloudtrail

Detection queries are available on the platform. Get full rules →