AWS Security Token Service - CraftedSignal Threat Feed

AWS STS AssumeRoot by Rare User and Member Account

hello@craftedsignal.io — Sun, 24 Nov 2024 00:00:00 +0000

This detection identifies when the AWS STS AssumeRoot action is performed by a rare user in AWS. The AssumeRoot action allows users to assume the root member account role, granting elevated permissions based on the task policy specified. This is a New Terms rule that identifies when the STS AssumeRoot action is performed by a user that rarely assumes this role against a specific member account. An adversary with compromised user credentials can abuse this action to escalate privileges and gain unauthorized access to AWS resources within an organization. This activity may indicate privilege escalation, lateral movement into a new account, abuse of cross-account access paths, or misuse of administrative workflows. The rule focuses on successful AssumeRoot events to minimize false positives.

Attack Chain

An attacker compromises AWS credentials of a user or role through phishing, credential stuffing, or other means.
The attacker uses the compromised credentials to authenticate to the AWS environment.
The attacker attempts to perform the sts:AssumeRoot action, targeting a specific member account within the AWS organization.
The attacker specifies a taskPolicyArn in the AssumeRoot request, defining the permissions they wish to assume in the target account.
AWS validates the request and, if successful, issues temporary credentials, including an access key ID, secret access key, and session token.
The attacker uses the temporary credentials to authenticate to the target member account.
The attacker performs actions within the target account, leveraging the elevated permissions granted by the assumed role, such as modifying IAM policies, accessing sensitive data, or disabling security controls.
The attacker maintains persistence by creating additional cloud roles (T1098.003)

Impact

A successful AssumeRoot attack can lead to full compromise of the targeted AWS account. This can allow the attacker to modify or delete resources, steal sensitive data, and disrupt business operations. The severity of the impact depends on the permissions granted by the task policy used during the AssumeRoot call and the resources present in the compromised account. This can affect a single member account or have organization-wide implications if the attacker is able to pivot to other accounts.

Recommendation

Deploy the Sigma rule AWS STS AssumeRoot by Rare User to detect unusual AssumeRoot activity in your AWS environment (see rules).
Investigate any alerts generated by the AWS STS AssumeRoot by Rare User rule, focusing on identifying the actor, target account, and actions performed after assuming the role (see rule documentation).
Restrict which IAM roles and identities can call sts:AssumeRoot, using IAM conditions (e.g., aws:PrincipalArn, aws:PrincipalOrgID, aws:RequestedRegion) as mentioned in the overview section.
Ensure AssumeRoot activity is included in your SIEM dashboards and investigation playbooks as described in the overview section.
Enable AWS CloudTrail logging and ensure the logs are being ingested into your SIEM (see index in rule).

AWS STS GetFederationToken Request for Defense Evasion and Persistence

hello@craftedsignal.io — Sat, 26 Oct 2024 12:00:00 +0000

The AWS Security Token Service (STS) GetFederationToken API allows users to request temporary security credentials with a maximum expiration of 36 hours. These tokens can be used to create console sign-in tokens, even for identities that don't already have one. Attackers may exploit this API to gain persistent access to AWS resources, even after the initial compromised identity is revoked. This technique can also bypass IAM API call limitations, allowing adversaries to perform sensitive actions with temporary credentials. The detection of the first occurrence of this API call by a user can help identify potential misuse and unauthorized access attempts within AWS environments. Identifying anomalous GetFederationToken requests is crucial for detecting and responding to potential defense evasion and persistence tactics used by attackers.

Attack Chain

Initial compromise of an AWS user identity or service account through credential theft or misconfiguration.
The attacker leverages the compromised identity to call the GetFederationToken API.
The STS service issues temporary security credentials, including an access key, secret key, and session token.
The attacker configures their tools or scripts to use these temporary credentials for subsequent AWS API calls.
The attacker utilizes the temporary credentials to access AWS resources and perform actions that may be restricted by IAM policies on the original compromised identity.
The attacker may also create a console sign-in token using the temporary credentials for console-based access to AWS resources.
Even if the initial compromised identity is revoked or deleted, the temporary credentials remain valid for up to 36 hours, allowing the attacker to maintain access.
The attacker uses the persistent access to perform actions such as data exfiltration, resource modification, or further lateral movement within the AWS environment.

Impact

Successful exploitation can lead to unauthorized access to sensitive AWS resources, data breaches, and potential disruption of services. The impact can be significant, as attackers can maintain access for up to 36 hours even after the initial compromised identity is revoked. This persistence allows attackers to perform a wide range of malicious activities, potentially affecting critical business operations and resulting in financial losses and reputational damage. Organizations in all sectors utilizing AWS are potentially vulnerable.

Recommendation

Deploy the Sigma rule "AWS First Occurrence of STS GetFederationToken Request by User" to your SIEM to detect suspicious GetFederationToken requests.
Investigate any alerts generated by the Sigma rule, focusing on unusual user behavior and unexpected request origins.
Review the CloudTrail logs for the requesting user (aws.cloudtrail.user_identity.arn) to verify if the GetFederationToken request was legitimate.
Implement additional monitoring and alerting for GetFederationToken requests, as mentioned in the overview.
Attach a policy that denies all actions, such as the AWSDenyAll policy, to revoke privileges of compromised users.

AWS STS AssumeRole with New MFA Device

hello@craftedsignal.io — Sat, 26 Oct 2024 12:00:00 +0000

This detection rule identifies instances of AWS Security Token Service (STS) AssumeRole calls where a new Multi-Factor Authentication (MFA) device is used. While legitimate administrative tasks may involve assuming roles with new MFA devices, adversaries can leverage this technique to establish persistence, escalate privileges, or move laterally within an AWS environment. The rule focuses on successful AssumeRole, AssumeRoleWithSAML, and AssumeRoleWithWebIdentity events, specifically looking for the presence of a serial number associated with the MFA device in the request parameters, indicating a new MFA device was used. This activity warrants investigation to determine if it is authorized or indicative of malicious behavior. The rule uses a 10-day history window to define "new" MFA devices.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials (T1078.004).
The attacker registers a new MFA device within the compromised AWS account (T1556.006).
The attacker uses the AWS STS AssumeRole API to request temporary credentials for a different IAM role (T1550).
The request includes the serial number of the newly registered MFA device in the request_parameters (part of the AssumeRole call).
AWS STS validates the MFA and, if successful, issues temporary credentials associated with the assumed role (T1550.001).
The attacker uses these temporary credentials to access resources and perform actions authorized by the assumed role (T1078).
This may involve escalating privileges, accessing sensitive data, or moving laterally to other AWS resources (TA0004, TA0008).

Impact

A successful attack using a new MFA device to assume a role can lead to unauthorized access to sensitive AWS resources. The attacker can escalate privileges, move laterally to other resources, or establish persistent access within the environment. This can result in data breaches, service disruption, or other malicious activities, impacting the confidentiality, integrity, and availability of the organization's cloud infrastructure. The risk score is 21, indicating a potential but not immediately critical threat.

Recommendation

Deploy the following Sigma rules to your SIEM to detect the use of new MFA devices in AssumeRole calls and tune for your environment.
Enable AWS CloudTrail logging and ensure proper configuration of the AWS Fleet integration or Filebeat module to capture relevant STS events.
Review AWS CloudTrail logs for unusual patterns of MFA device registrations and role assumptions, focusing on privilege escalation or lateral movement attempts.
Implement additional monitoring and alerting for unusual MFA device registrations and role assumptions to enhance detection of similar threats in the future.
Create exceptions for known onboarding activities or routine device replacements by correlating with HR records or IT support tickets as described in the rule's false positives section.

AWS STS Role Chaining for Privilege Escalation and Persistence

hello@craftedsignal.io — Fri, 25 Oct 2024 12:00:00 +0000

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

An attacker gains initial access to an AWS account, possibly through compromised credentials or an exposed access key.
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.
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.
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.
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.
Each AssumeRole action generates new temporary credentials, effectively refreshing the attacker's session.
The attacker maintains persistence within the AWS environment by repeatedly chaining roles to refresh temporary credentials.
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.