Sts — CraftedSignal Threat Feed

AWS STS GetCallerIdentity API Called for the First Time

hello@craftedsignal.io — Fri, 10 Apr 2026 16:48:32 +0000

The AWS Security Token Service (STS) GetCallerIdentity API allows a user to retrieve information about the IAM user or role associated with the credentials being used. While a legitimate user should already know the account they are operating in, an attacker with compromised credentials may use this API to verify the validity of the credentials and enumerate account details. This activity, especially when observed for the first time from a particular user identity, can indicate malicious reconnaissance. This detection focuses on identifying the initial use of the GetCallerIdentity API, excluding instances where an assumed role is involved due to the common practice of using GetCallerIdentity after assuming a role. This event is flagged as anomalous, potentially signaling unauthorized access or credential misuse within an AWS environment.

Attack Chain

An attacker gains unauthorized access to AWS credentials, either through phishing, credential stuffing, or compromised systems.
The attacker uses the compromised credentials to authenticate to the AWS environment.
The attacker executes the sts:GetCallerIdentity API call to identify the associated AWS account ID, IAM user, or role.
The AWS STS service processes the request and returns the identity information to the attacker.
The attacker analyzes the returned identity information to understand the scope and privileges of the compromised credentials.
The attacker uses the gathered information to perform further reconnaissance activities, such as identifying accessible resources and services.
Based on the discovered information, the attacker may attempt to escalate privileges or move laterally within the AWS environment.
The final objective could include data exfiltration, deployment of malicious workloads, or disruption of services.

Impact

Successful exploitation and undetected reconnaissance can lead to significant damage, including unauthorized access to sensitive data, compromised workloads, and disruption of critical services. The impact can range from data breaches and financial losses to reputational damage and regulatory fines. Depending on the scope of the compromised credentials, the attacker may be able to access and control a large portion of the AWS environment. In the event of a breach, the organization may incur costs related to incident response, data recovery, and legal settlements.

Recommendation

Deploy the Sigma rule “AWS STS GetCallerIdentity API Called for the First Time by New Identity” to your SIEM and tune for your environment to detect anomalous usage of the GetCallerIdentity API.
Investigate any alerts generated by the Sigma rule, focusing on identifying the source IP address, user agent, and the user identity associated with the API call.
Review IAM permission policies for the user identity associated with the GetCallerIdentity API call to ensure the least privilege principle is followed.
Enable AWS CloudTrail logging for all AWS regions in your account to ensure comprehensive event logging, as required by the detection rule.
Consider adding exceptions based on user.id or aws.cloudtrail.user_identity.arn values for automation workflows that legitimately rely on the GetCallerIdentity API, as mentioned in the overview.
Implement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise, as suggested in the documentation.

Suspicious AWS STS GetSessionToken Usage

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

The AWS Security Token Service (STS) GetSessionToken API allows IAM users to create temporary security credentials. Attackers can abuse this functionality by generating tokens with elevated privileges or for lateral movement within an AWS environment if an IAM user’s credentials have been compromised. This activity can be difficult to detect as GetSessionToken is a legitimate function, but unusual patterns or IAM users generating tokens where it is not expected should be investigated. This activity is of particular concern because it bypasses normal IAM role assumption logging and creates a separate credential for an attacker to abuse, making access more difficult to track. The impact is significant, allowing attackers to perform actions as the compromised IAM user or escalate privileges.

Attack Chain

An attacker gains initial access to an AWS environment, potentially through compromised IAM user credentials.
The attacker authenticates to AWS using the compromised IAM user credentials.
The attacker calls the STS GetSessionToken API, specifying desired permissions or roles (if permitted by the IAM user’s policies).
AWS STS generates a new set of temporary credentials (access key ID, secret access key, and session token).
The attacker configures their AWS CLI or SDK to use the newly acquired temporary credentials.
The attacker leverages these temporary credentials to perform actions within the AWS environment, potentially escalating privileges or moving laterally.
The attacker covers their tracks by deleting the CloudTrail logs.
The attacker exfiltrates sensitive data, deploys malware, or causes disruption within the AWS environment using the acquired privileges.

Impact

Compromised AWS environments can lead to data breaches, service disruptions, and financial losses. Successful exploitation via GetSessionToken misuse allows attackers to move laterally, escalate privileges, and perform unauthorized actions within the AWS infrastructure. The number of affected organizations is currently unknown, but any organization relying on AWS is potentially at risk. If successful, attackers can steal sensitive data, compromise critical systems, and disrupt business operations.

Recommendation

Deploy the Sigma rule “AWS STS GetSessionToken Misuse” to your SIEM to detect suspicious GetSessionToken API calls (see rules section).
Investigate GetSessionToken calls where userIdentity.type is IAMUser to determine if the request is legitimate.
Monitor CloudTrail logs for unusual patterns of GetSessionToken usage, particularly from unfamiliar user agents or hosts.
Implement strong IAM policies and MFA to minimize the risk of compromised IAM user credentials.
Review the false positives section of the Sigma rule to tune the rule for your specific environment.

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).