{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/amazon-web-services/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Amazon Web Services"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","getcalleridentity","ec2","discovery"],"_cs_type":"advisory","_cs_vendors":["Amazon","Google","MongoDB, Inc."],"content_html":"\u003cp\u003eThis 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn 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.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the instance\u0026rsquo;s IAM role to obtain temporary AWS credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to validate the stolen credentials using the \u003ccode\u003eGetCallerIdentity\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eGetCallerIdentity\u003c/code\u003e API call originates from an IP address associated with a new and unexpected Autonomous System Organization (ASO).\u003c/li\u003e\n\u003cli\u003eThe AWS CloudTrail logs record the \u003ccode\u003eGetCallerIdentity\u003c/code\u003e event, including the user identity ARN and the source AS organization name.\u003c/li\u003e\n\u003cli\u003eThe detection rule triggers due to the new combination of user identity and source AS organization.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the validated credentials to perform reconnaissance and identify valuable resources within the AWS environment (e.g., S3 buckets, databases).\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to exfiltrate sensitive data or deploy malicious workloads using the stolen credentials.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS EC2 Role GetCallerIdentity from New Source AS Organization\u0026rdquo; to your SIEM to detect suspicious activity.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts triggered by the Sigma rule, focusing on the \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e and \u003ccode\u003esource.as.organization.name\u003c/code\u003e fields.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for \u003ccode\u003eGetCallerIdentity\u003c/code\u003e API calls, particularly those originating from unfamiliar source IP addresses and ASNs.\u003c/li\u003e\n\u003cli\u003eRevoke compromised IAM role sessions by stopping the affected EC2 instances or removing the role from the instance profile.\u003c/li\u003e\n\u003cli\u003eRotate any long-lived secrets accessible by the EC2 instance, based on the \u003ccode\u003eaws.cloudtrail.user_identity.access_key_id\u003c/code\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T20:57:28Z","date_published":"2026-05-01T20:57:28Z","id":"/briefs/2024-01-02-aws-ec2-role-getcalleridentity/","summary":"The rule detects when an EC2 instance role session calls AWS STS GetCallerIdentity from a new source autonomous system (AS) organization name, indicating potential credential theft and verification from outside expected egress paths.","title":"AWS EC2 Role GetCallerIdentity from New Source AS Organization","url":"https://feed.craftedsignal.io/briefs/2024-01-02-aws-ec2-role-getcalleridentity/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Amazon Web Services"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","discovery","vpn"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis 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 \u003ccode\u003eList*\u003c/code\u003e and \u003ccode\u003eDescribe*\u003c/code\u003e patterns to reduce false positives, focusing instead on a curated list of ASNs commonly associated with VPN providers and hosting services. It\u0026rsquo;s important to validate ASN data using local intelligence and tailor the \u003ccode\u003eevent.action\u003c/code\u003e list based on your environment\u0026rsquo;s baseline. Hosting ASNs are dual-use and require careful monitoring.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to AWS credentials, possibly through compromised credentials or misconfigured IAM roles.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a VPN connection to mask their origin and evade geographic restrictions or monitoring. The VPN endpoint\u0026rsquo;s ASN belongs to a known VPN provider.\u003c/li\u003e\n\u003cli\u003eUsing the compromised credentials and VPN connection, the attacker calls the AWS API to execute \u003ccode\u003eGetCallerIdentity\u003c/code\u003e to validate access.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates IAM users and roles using \u003ccode\u003eListUsers\u003c/code\u003e and \u003ccode\u003eListRoles\u003c/code\u003e to map out the AWS environment\u0026rsquo;s identity landscape.\u003c/li\u003e\n\u003cli\u003eThe attacker inventories S3 buckets using \u003ccode\u003eListBuckets\u003c/code\u003e to identify potential targets for data exfiltration or manipulation.\u003c/li\u003e\n\u003cli\u003eThe attacker gathers information about EC2 instances, VPCs, and security groups using \u003ccode\u003eDescribeInstances\u003c/code\u003e, \u003ccode\u003eDescribeVpcs\u003c/code\u003e, and \u003ccode\u003eDescribeSecurityGroups\u003c/code\u003e to understand the network infrastructure.\u003c/li\u003e\n\u003cli\u003eThe attacker lists available Lambda functions using \u003ccode\u003eListFunctions\u003c/code\u003e to discover potential code execution opportunities.\u003c/li\u003e\n\u003cli\u003eThe attacker collects logging configurations by calling \u003ccode\u003eDescribeTrails\u003c/code\u003e to identify logging gaps.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS Discovery API Calls from VPN ASN by New Identity\u003c/code\u003e to detect anomalous discovery activity originating from VPN ASNs.\u003c/li\u003e\n\u003cli\u003eReview the curated list of VPN-oriented ASNs within the rule query and update it with local intelligence from sources like RIPE, BGPView, or PeeringDB.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logs to capture the necessary event data for the Sigma rule to function effectively.\u003c/li\u003e\n\u003cli\u003eTune the Sigma rule\u0026rsquo;s \u003ccode\u003eevent.action\u003c/code\u003e filter to include additional discovery-related API calls relevant to your environment, based on baseline analysis.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the Sigma rule by examining \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e, \u003ccode\u003eevent.action\u003c/code\u003e, \u003ccode\u003eevent.provider\u003c/code\u003e, \u003ccode\u003esource.ip\u003c/code\u003e, and \u003ccode\u003esource.as.organization.name\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eImplement automated response actions, such as revoking sessions or rotating keys, when unexpected discovery activity is detected from VPN ASNs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T20:57:28Z","date_published":"2026-05-01T20:57:28Z","id":"/briefs/2024-01-aws-vpn-discovery/","summary":"This rule detects the initial use of AWS discovery APIs from VPN-associated ASNs by a previously unseen identity, indicating potential reconnaissance activity.","title":"AWS Discovery API Calls from VPN ASN by New Identity","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-vpn-discovery/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Amazon Web Services"],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","aws","iam"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis 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 (\u003ccode\u003eCreatePolicyVersion\u003c/code\u003e) and the modification of the default version (\u003ccode\u003eSetDefaultPolicyVersion\u003c/code\u003e). 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises an IAM user or role with permissions to modify IAM policies (\u003ccode\u003eiam:CreatePolicyVersion\u003c/code\u003e or \u003ccode\u003eiam:SetDefaultPolicyVersion\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a customer-managed policy attached to a high-privilege role or user.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a new policy version with overly permissive rules, such as wildcard actions and resources.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eCreatePolicyVersion\u003c/code\u003e API call to upload the malicious policy version to the target policy.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker uses the \u003ccode\u003eSetDefaultPolicyVersion\u003c/code\u003e API call to set a pre-existing, but less restrictive, policy version as the default.\u003c/li\u003e\n\u003cli\u003eThe compromised IAM user or role assumes the high-privilege role targeted in step 2.\u003c/li\u003e\n\u003cli\u003eThe attacker gains elevated privileges based on the modified IAM policy.\u003c/li\u003e\n\u003cli\u003eThe attacker performs unauthorized actions within the AWS environment, such as accessing sensitive data, modifying infrastructure, or creating new resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM Customer Managed Policy Version Created or Default Version Set\u0026rdquo; to your SIEM to detect suspicious policy modifications. Tune the rule based on your organization\u0026rsquo;s baseline activity.\u003c/li\u003e\n\u003cli\u003eReview \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e logs to identify the \u003ccode\u003epolicyArn\u003c/code\u003e and \u003ccode\u003epolicyDocument\u003c/code\u003e associated with the policy changes detected by the rule.\u003c/li\u003e\n\u003cli\u003eImplement strong IAM governance practices, including the principle of least privilege and regular reviews of policy permissions, to minimize the impact of policy manipulation.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for \u003ccode\u003eAttachUserPolicy\u003c/code\u003e, \u003ccode\u003eAttachRolePolicy\u003c/code\u003e, or \u003ccode\u003eCreatePolicyVersion\u003c/code\u003e spikes from the same principal as detected policy modifications.\u003c/li\u003e\n\u003cli\u003eEnable MFA for all IAM users, especially those with permissions to manage IAM policies.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-aws-iam-policy-manipulation/","summary":"Successful creation of new or setting default versions of customer-managed IAM policies can indicate privilege escalation attempts by attackers modifying policy permissions.","title":"AWS IAM Customer Managed Policy Version Manipulation for Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-iam-policy-manipulation/"}],"language":"en","title":"CraftedSignal Threat Feed — Amazon Web Services","version":"https://jsonfeed.org/version/1.1"}