Amazon Web Services — CraftedSignal Threat Feed

AWS EC2 Role GetCallerIdentity from New Source AS Organization

hello@craftedsignal.io — Fri, 01 May 2026 20:57:28 +0000

This detection identifies when an EC2 instance role session calls the AWS STS GetCallerIdentity API from a source Autonomous System (AS) Organization name that has not been previously observed. The GetCallerIdentity API is often used by adversaries to validate stolen instance role credentials from infrastructure outside the victim’s normal egress points. By baselining the combination of identity and source network, the rule reduces noise associated with stable NAT or AWS-classified egress, focusing on truly novel access patterns. This detection is specifically designed to complement other rules that may detect general GetCallerIdentity calls, by excluding previously seen combinations of user identity and source AS organization.

Attack Chain

An attacker gains unauthorized access to an EC2 instance through methods like exploiting a Server-Side Request Forgery (SSRF) vulnerability, compromising application code or exploiting IMDS abuse.
The attacker leverages the instance’s IAM role to obtain temporary AWS credentials.
The attacker attempts to validate the stolen credentials using the GetCallerIdentity API call.
The GetCallerIdentity API call originates from an IP address associated with a new and unexpected Autonomous System Organization (ASO).
The AWS CloudTrail logs record the GetCallerIdentity event, including the user identity ARN and the source AS organization name.
The detection rule triggers due to the new combination of user identity and source AS organization.
The attacker uses the validated credentials to perform reconnaissance and identify valuable resources within the AWS environment (e.g., S3 buckets, databases).
The attacker attempts to exfiltrate sensitive data or deploy malicious workloads using the stolen credentials.

Impact

A successful attack can lead to unauthorized access to sensitive data stored within the AWS environment. The attacker may be able to escalate privileges, compromise other resources, and disrupt services. The potential impact includes data breaches, financial loss, and reputational damage. The lack of specific victim counts or sectors targeted suggests a broad applicability across various AWS users.

Recommendation

Deploy the Sigma rule “AWS EC2 Role GetCallerIdentity from New Source AS Organization” to your SIEM to detect suspicious activity.
Investigate alerts triggered by the Sigma rule, focusing on the aws.cloudtrail.user_identity.arn and source.as.organization.name fields.
Monitor AWS CloudTrail logs for GetCallerIdentity API calls, particularly those originating from unfamiliar source IP addresses and ASNs.
Revoke compromised IAM role sessions by stopping the affected EC2 instances or removing the role from the instance profile.
Rotate any long-lived secrets accessible by the EC2 instance, based on the aws.cloudtrail.user_identity.access_key_id.

AWS Discovery API Calls from VPN ASN by New Identity

hello@craftedsignal.io — Fri, 01 May 2026 20:57:28 +0000

This detection identifies the first-time occurrence of an IAM principal invoking discovery APIs from a source IP address associated with a known VPN autonomous system number (ASN). The rule focuses on high-signal discovery actions, such as credential checks, account enumeration, bucket inventory, compute inventory, and logging introspection within AWS CloudTrail logs. The goal is to detect potential reconnaissance activities originating from anonymizing networks, which may indicate malicious intent. The rule specifically omits broad List* and Describe* patterns to reduce false positives, focusing instead on a curated list of ASNs commonly associated with VPN providers and hosting services. It’s important to validate ASN data using local intelligence and tailor the event.action list based on your environment’s baseline. Hosting ASNs are dual-use and require careful monitoring.

Attack Chain

An attacker gains unauthorized access to AWS credentials, possibly through compromised credentials or misconfigured IAM roles.
The attacker initiates a VPN connection to mask their origin and evade geographic restrictions or monitoring. The VPN endpoint’s ASN belongs to a known VPN provider.
Using the compromised credentials and VPN connection, the attacker calls the AWS API to execute GetCallerIdentity to validate access.
The attacker enumerates IAM users and roles using ListUsers and ListRoles to map out the AWS environment’s identity landscape.
The attacker inventories S3 buckets using ListBuckets to identify potential targets for data exfiltration or manipulation.
The attacker gathers information about EC2 instances, VPCs, and security groups using DescribeInstances, DescribeVpcs, and DescribeSecurityGroups to understand the network infrastructure.
The attacker lists available Lambda functions using ListFunctions to discover potential code execution opportunities.
The attacker collects logging configurations by calling DescribeTrails to identify logging gaps.

Impact

A successful attack leveraging these discovery techniques can lead to unauthorized access to sensitive data, privilege escalation, and lateral movement within the AWS environment. By mapping out the cloud infrastructure, attackers can identify vulnerabilities and misconfigurations to exploit. Compromised AWS environments can result in data breaches, service disruptions, and financial losses.

Recommendation

Deploy the Sigma rule AWS Discovery API Calls from VPN ASN by New Identity to detect anomalous discovery activity originating from VPN ASNs.
Review the curated list of VPN-oriented ASNs within the rule query and update it with local intelligence from sources like RIPE, BGPView, or PeeringDB.
Enable AWS CloudTrail logs to capture the necessary event data for the Sigma rule to function effectively.
Tune the Sigma rule’s event.action filter to include additional discovery-related API calls relevant to your environment, based on baseline analysis.
Investigate alerts generated by the Sigma rule by examining aws.cloudtrail.user_identity.arn, event.action, event.provider, source.ip, and source.as.organization.name.
Implement automated response actions, such as revoking sessions or rotating keys, when unexpected discovery activity is detected from VPN ASNs.

AWS IAM Customer Managed Policy Version Manipulation for Privilege Escalation

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

This detection identifies potentially malicious activity related to AWS Identity and Access Management (IAM) policies. Specifically, it focuses on the creation of new versions of customer-managed policies (CreatePolicyVersion) and the modification of the default version (SetDefaultPolicyVersion). Attackers who have compromised IAM users or roles with sufficient permissions (iam:CreatePolicyVersion or iam:SetDefaultPolicyVersion) can use these actions to escalate their privileges within the AWS environment. By introducing a more permissive policy version and setting it as the default, attackers can gain unauthorized access to resources and perform actions that would otherwise be restricted. This activity is especially concerning when the modified policies are attached to highly privileged roles or users, such as those used for administrative tasks or break-glass scenarios.

Attack Chain

An attacker compromises an IAM user or role with permissions to modify IAM policies (iam:CreatePolicyVersion or iam:SetDefaultPolicyVersion).
The attacker identifies a customer-managed policy attached to a high-privilege role or user.
The attacker crafts a new policy version with overly permissive rules, such as wildcard actions and resources.
The attacker uses the CreatePolicyVersion API call to upload the malicious policy version to the target policy.
Alternatively, the attacker uses the SetDefaultPolicyVersion API call to set a pre-existing, but less restrictive, policy version as the default.
The compromised IAM user or role assumes the high-privilege role targeted in step 2.
The attacker gains elevated privileges based on the modified IAM policy.
The attacker performs unauthorized actions within the AWS environment, such as accessing sensitive data, modifying infrastructure, or creating new resources.

Impact

Successful exploitation can lead to significant privilege escalation, allowing attackers to gain control over critical AWS resources and data. The number of affected users and roles depends on the scope of the compromised policy and its attachments. The consequences can include data breaches, service disruptions, and financial losses. In environments where IAM policies are not closely monitored, attackers may be able to maintain their elevated access for extended periods, further compounding the damage.

Recommendation

Deploy the Sigma rule “AWS IAM Customer Managed Policy Version Created or Default Version Set” to your SIEM to detect suspicious policy modifications. Tune the rule based on your organization’s baseline activity.
Review aws.cloudtrail.request_parameters logs to identify the policyArn and policyDocument associated with the policy changes detected by the rule.
Implement strong IAM governance practices, including the principle of least privilege and regular reviews of policy permissions, to minimize the impact of policy manipulation.
Monitor CloudTrail logs for AttachUserPolicy, AttachRolePolicy, or CreatePolicyVersion spikes from the same principal as detected policy modifications.
Enable MFA for all IAM users, especially those with permissions to manage IAM policies.