AWS STS — CraftedSignal Threat Feed

Suspicious AWS SAML Activity Detection

hello@craftedsignal.io — Wed, 03 Jan 2024 18:22:30 +0000

This detection identifies potentially malicious Security Assertion Markup Language (SAML) activity within Amazon Web Services (AWS). The activity includes monitoring for AssumeRoleWithSAML and UpdateSAMLProvider events. An adversary might exploit SAML to gain unauthorized access, escalate privileges, move laterally within the AWS environment, or establish persistent backdoor access. The focus is on detecting unusual or unauthorized modifications to SAML configurations and role assumptions, which could indicate a compromised identity provider or malicious actor leveraging SAML for illicit purposes. Defenders should prioritize monitoring SAML-related API calls to identify and mitigate potential threats early in the attack chain.

Attack Chain

The attacker compromises or creates a malicious SAML identity provider.
The attacker configures the AWS environment to trust the malicious SAML provider using UpdateSAMLProvider.
The attacker crafts a SAML assertion to assume a specific role within the AWS environment.
The attacker uses the AssumeRoleWithSAML API call to authenticate with AWS using the crafted SAML assertion.
AWS STS validates the SAML assertion and, if valid, provides temporary credentials for the assumed role.
The attacker uses the temporary credentials to perform actions within AWS, potentially escalating privileges.
The attacker moves laterally within the AWS environment, accessing resources and services authorized for the assumed role.
The attacker establishes persistent access by creating backdoors or modifying existing IAM policies, leveraging the initially gained access.

Impact

Successful exploitation via SAML manipulation can lead to a complete compromise of the AWS environment. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and deploy malicious infrastructure. The impact includes potential data breaches, financial losses, and reputational damage. The number of affected resources depends on the permissions associated with the roles assumed by the attacker.

Recommendation

Deploy the Sigma rule for AssumeRoleWithSAML events to detect suspicious role assumptions (see “AssumeRoleWithSAML Detection Rule”).
Deploy the Sigma rule for UpdateSAMLProvider events to detect unauthorized SAML provider modifications (see “UpdateSAMLProvider Detection Rule”).
Investigate any AssumeRoleWithSAML events originating from unfamiliar user agents or IP addresses by reviewing CloudTrail logs.
Monitor UpdateSAMLProvider events for unexpected changes to SAML provider configurations. Review associated CloudTrail logs for user identity, user agent, and hostname to ensure authorized access.
Tune the provided Sigma rules for your environment, addressing false positives by exempting known, legitimate behavior.

AWS STS GetFederationToken with AdministratorAccess in Request

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The AWS Security Token Service (STS) GetFederationToken API allows for the creation of temporary security credentials for federated users. These credentials inherit permissions from the calling IAM user and any session policy included in the request. This detection focuses on instances where the request parameters of GetFederationToken reference AdministratorAccess, either directly or through an equivalent string. The inclusion of AdministratorAccess within the session policy grants overly broad privileges to the temporary credentials, potentially leading to privilege escalation or abuse. This scenario is often indicative of legacy systems, misconfigured tooling, or malicious intent, posing a significant risk to the security posture of AWS environments. Defenders should prioritize identifying and mitigating instances of this behavior to enforce least privilege principles and prevent unauthorized access.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised IAM user credentials or an exploited vulnerability.
The attacker identifies an IAM user with the necessary permissions to call the STS GetFederationToken API.
The attacker crafts a GetFederationToken API request, including a session policy that directly references “AdministratorAccess” or includes a policy ARN that grants administrator privileges.
The GetFederationToken API call is successfully executed, generating temporary security credentials with broad administrator permissions.
The attacker uses the temporary credentials to perform privileged actions within the AWS environment, such as modifying IAM policies, accessing sensitive data, or deploying malicious resources.
The attacker may attempt to laterally move within the AWS environment by leveraging the newly acquired administrator privileges to compromise other resources or accounts.
The attacker could establish persistence by creating new IAM users or roles with elevated permissions, ensuring continued access even after the temporary credentials expire.
The attacker achieves their final objective, which could include data exfiltration, service disruption, or financial gain.

Impact

Successful exploitation can lead to complete compromise of the AWS environment. An attacker with temporary administrator credentials can modify security configurations, access sensitive data, and disrupt critical services. While no specific victim counts or sectors are mentioned, the broad permissions granted by AdministratorAccess make any AWS environment vulnerable to significant damage. The risk score of 73 highlights the potential for severe impact.

Recommendation

Deploy the Sigma rule “AWS STS GetFederationToken with AdministratorAccess in Request” to your SIEM to detect instances of this activity (rule title).
Investigate any alerts generated by the Sigma rule, focusing on the aws.cloudtrail.request_parameters to identify the specific policy being used (rule title).
Revoke or rotate the IAM user access keys involved in the GetFederationToken call and enforce least privilege on the user (rule description).
Monitor CloudTrail logs for subsequent events using response_elements.credentials.accessKeyId from the same response to identify actions taken with the temporary credentials (rule description).
Review and update IAM policies to ensure that session policies used with GetFederationToken adhere to the principle of least privilege (rule description).
Implement automated checks to prevent the creation or modification of IAM policies that grant AdministratorAccess except in explicitly approved scenarios (rule description).

AWS STS AssumeRole Misuse for Lateral Movement and Privilege Escalation

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The AWS Security Token Service (STS) AssumeRole function allows users or applications to assume a different IAM role, granting temporary access to resources and permissions associated with that role. Attackers who gain initial access to an AWS account can misuse AssumeRole to move laterally to other roles and escalate their privileges. This can occur if the initial role has overly permissive trust relationships or if an attacker can manipulate the role assumption process. This activity is detected through CloudTrail logs that record the AssumeRole event. The impact of this activity can be significant, depending on the permissions associated with the roles assumed.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or an exploited vulnerability.
The attacker identifies IAM roles within the AWS environment that they may be able to assume.
The attacker attempts to use the AssumeRole API call to assume a different role. This call includes parameters specifying the target role ARN and a session name.
AWS STS validates the request. Successful validation depends on the trust policy of the target role and the permissions of the initial user or role.
If the validation is successful, AWS STS returns temporary security credentials (access key ID, secret access key, and session token) to the attacker.
The attacker uses these temporary credentials to access AWS resources and perform actions authorized by the assumed role.
The attacker continues to move laterally and escalate privileges by assuming additional roles.
The attacker achieves their objective, such as accessing sensitive data, modifying configurations, or disrupting services.

Impact

Successful exploitation can lead to a wide range of impacts, including unauthorized access to sensitive data stored in S3 buckets or databases, modification or deletion of critical infrastructure configurations, and disruption of AWS services. The scope of the impact depends on the permissions associated with the roles that the attacker is able to assume. This can affect any organization using AWS, and the consequences can range from data breaches and financial losses to reputational damage and regulatory penalties.

Recommendation

Deploy the provided Sigma rule to your SIEM and tune for your environment to detect suspicious AssumeRole activity based on userIdentity.type and userIdentity.sessionContext.sessionIssuer.type.
Review and harden IAM role trust policies to ensure that only authorized entities can assume roles.
Monitor CloudTrail logs for unusual patterns of AssumeRole API calls, especially those originating from unfamiliar user identities or locations.
Implement multi-factor authentication (MFA) for all IAM users to reduce the risk of credential compromise.