{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/ec2/","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":[],"_cs_severities":["medium"],"_cs_tags":["aws","ec2","ssm","lolbin","execution","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat brief focuses on detecting the execution of Living Off the Land Binaries (LOLBins) or GTFOBins on Amazon EC2 instances via AWS Systems Manager (SSM) \u003ccode\u003eSendCommand\u003c/code\u003e API. The technique involves correlating AWS CloudTrail \u003ccode\u003eSendCommand\u003c/code\u003e events with endpoint process execution by matching SSM command IDs. While AWS redacts command parameters in CloudTrail logs, this correlation technique reveals the actual commands executed on EC2 instances. This is critical because adversaries may abuse SSM to execute malicious commands remotely without requiring SSH or RDP access. They can leverage legitimate system utilities for various malicious purposes, including data exfiltration, establishing reverse shells, or facilitating lateral movement within the cloud environment. The rule was last updated on 2026-04-10.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to AWS via compromised credentials or an exposed IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the AWS CLI or API to initiate an SSM \u003ccode\u003eSendCommand\u003c/code\u003e to a target EC2 instance. The \u003ccode\u003eDocumentName\u003c/code\u003e parameter is set to \u003ccode\u003eAWS-RunShellScript\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe SSM agent on the EC2 instance receives the \u003ccode\u003eSendCommand\u003c/code\u003e request.\u003c/li\u003e\n\u003cli\u003eThe SSM agent executes a shell script (\u003ccode\u003e_script.sh\u003c/code\u003e) within a dedicated directory for orchestration.\u003c/li\u003e\n\u003cli\u003eThe shell script executes a LOLBin, such as \u003ccode\u003ecurl\u003c/code\u003e, \u003ccode\u003ewget\u003c/code\u003e, \u003ccode\u003epython\u003c/code\u003e, or \u003ccode\u003eperl\u003c/code\u003e, to perform malicious actions. The parent process of the LOLBin will be the SSM shell script.\u003c/li\u003e\n\u003cli\u003eThe LOLBin is used to download a malicious payload, establish a reverse shell, or exfiltrate data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the established reverse shell to perform further actions on the EC2 instance.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized access to EC2 instances, data exfiltration, deployment of malware, and lateral movement within the AWS environment. Although a number of impacted organizations is not available, this attack is able to bypass traditional network security controls. Organizations in any sector utilizing AWS EC2 instances and SSM are potentially at risk. The lack of required SSH or RDP access makes this technique particularly stealthy.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable AWS CloudTrail logging to capture \u003ccode\u003eSendCommand\u003c/code\u003e events and monitor for \u003ccode\u003eAWS-RunShellScript\u003c/code\u003e in the \u003ccode\u003erequest_parameters\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect AWS EC2 LOLBin Execution via SSM SendCommand\u0026rdquo; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eMonitor endpoint process execution logs for the execution of LOLBins like \u003ccode\u003ecurl\u003c/code\u003e, \u003ccode\u003ewget\u003c/code\u003e, \u003ccode\u003epython\u003c/code\u003e, \u003ccode\u003eperl\u003c/code\u003e, \u003ccode\u003enc\u003c/code\u003e, etc., with parent processes related to SSM.\u003c/li\u003e\n\u003cli\u003eImplement strict IAM policies to restrict SSM \u003ccode\u003eSendCommand\u003c/code\u003e permissions to only authorized users and roles.\u003c/li\u003e\n\u003cli\u003eReview and audit existing SSM configurations to identify and remediate any overly permissive settings.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-01-03-aws-ec2-lolbin-ssm/","summary":"Detection of Living Off the Land Binaries (LOLBins) or GTFOBins execution on EC2 instances via AWS Systems Manager (SSM) SendCommand API, potentially indicating malicious activity.","title":"AWS EC2 LOLBin Execution via SSM SendCommand","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-ec2-lolbin-ssm/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Compute Cloud (EC2)"],"_cs_severities":["medium"],"_cs_tags":["aws","cloudtrail","ec2","keypair","initial-access","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe unauthorized import of SSH key pairs into Amazon Elastic Compute Cloud (EC2) is a technique that malicious actors can leverage to gain unauthorized access to EC2 instances. By importing their own key pairs, attackers can bypass existing security measures and gain persistent access to compromised systems. This activity is often part of a broader attack campaign aimed at compromising sensitive data, disrupting services, or establishing a foothold within an organization\u0026rsquo;s cloud infrastructure. The initial publication of the detection rule was in December 2024, highlighting the ongoing relevance of this technique in cloud security. Monitoring for this activity can help defenders identify and respond to potential security breaches in a timely manner.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a misconfigured IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate existing EC2 instances to identify potential targets.\u003c/li\u003e\n\u003cli\u003eThe attacker generates or obtains an SSH key pair, which they intend to use for unauthorized access.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eImportKeyPair\u003c/code\u003e API call within the EC2 service to import the generated or obtained SSH key pair.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the EC2 instance\u0026rsquo;s configuration to associate the newly imported key pair with the instance. This might involve stopping and restarting the instance.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the imported SSH key pair to gain SSH access to the EC2 instance.\u003c/li\u003e\n\u003cli\u003eOnce inside the instance, the attacker attempts to escalate privileges and move laterally within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data, deploys malware, or disrupts critical services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful key pair import can lead to complete compromise of the affected EC2 instances, potentially impacting dozens of servers depending on the environment. Sensitive data stored on or accessible from these instances could be exfiltrated, leading to financial loss, reputational damage, and regulatory fines. Furthermore, compromised instances can be used as a launchpad for further attacks within the AWS environment, leading to a wider breach. The financial impact can range from tens of thousands to millions of dollars, depending on the scale of the breach and the sensitivity of the data compromised.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect \u003ccode\u003eImportKeyPair\u003c/code\u003e events in CloudTrail logs (logsource: aws, service: cloudtrail).\u003c/li\u003e\n\u003cli\u003eReview IAM policies to ensure that only authorized users and roles have the necessary permissions to import key pairs (eventSource: \u0026rsquo;ec2.amazonaws.com\u0026rsquo;, eventName: \u0026lsquo;ImportKeyPair\u0026rsquo;).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected \u003ccode\u003eImportKeyPair\u003c/code\u003e events, validating the user identity, user agent, and source IP address to ensure they are expected (detection block).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-12-19T00:00:00Z","date_published":"2024-12-19T00:00:00Z","id":"/briefs/2024-12-aws-key-pair-import/","summary":"The import of SSH key pairs into AWS EC2, as detected by CloudTrail logs, may indicate unauthorized access attempts, persistence establishment, or privilege escalation by an attacker.","title":"Suspicious AWS EC2 Key Pair Import Activity","url":"https://feed.craftedsignal.io/briefs/2024-12-aws-key-pair-import/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Amazon EC2"],"_cs_severities":["medium"],"_cs_tags":["aws","ec2","keypair","persistence","credential_access","lateral_movement"],"_cs_type":"advisory","_cs_vendors":["Amazon","Google","Microsoft"],"content_html":"\u003cp\u003eThis alert identifies suspicious activity related to the creation of EC2 key pairs within an AWS environment. Specifically, it focuses on instances where a new IAM principal (user) creates an EC2 key pair from a network source (IP address) whose autonomous system organization is not commonly associated with major cloud providers like Amazon, Google, or Microsoft. Adversaries often create key pairs for persistence or to enable unauthorized access to EC2 instances, potentially leading to data exfiltration or further malicious activities. The rule uses a new terms approach to baseline user activity, reducing noise from repeated actions while still flagging the initial suspicious key pair creation. This activity is flagged as suspicious due to originating from outside trusted ASNs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, potentially through compromised credentials or a misconfigured IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate existing EC2 instances and associated key pairs.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eCreateKeyPair\u003c/code\u003e API call to generate a new SSH key pair within the AWS account. The request originates from a network with an autonomous system organization not attributed to common cloud providers.\u003c/li\u003e\n\u003cli\u003eThe attacker stores the private key material for later use in accessing EC2 instances.\u003c/li\u003e\n\u003cli\u003eThe attacker may then use the new key pair to launch new EC2 instances or import the key to existing instances. This can be done through \u003ccode\u003eRunInstances\u003c/code\u003e or \u003ccode\u003eImportKeyPair\u003c/code\u003e operations.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the new key pair to SSH into the newly created or compromised EC2 instances.\u003c/li\u003e\n\u003cli\u003eOnce inside the instances, the attacker performs malicious activities, such as data exfiltration, lateral movement, or installing malware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized access to EC2 instances, potentially compromising sensitive data and disrupting services. A compromised AWS account can allow the attacker to steal data, establish persistence, and move laterally within the cloud environment. The lack of expected cloud provider ASN for the source IP of the \u003ccode\u003eCreateKeyPair\u003c/code\u003e event raises the risk profile.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS EC2 CreateKeyPair from Non-Cloud AS Organization\u0026rdquo; to your SIEM and tune the \u003ccode\u003esource.as.organization.name\u003c/code\u003e exclusions based on your environment.\u003c/li\u003e\n\u003cli\u003eReview AWS CloudTrail logs for any \u003ccode\u003eCreateKeyPair\u003c/code\u003e events and correlate with other suspicious activity, as mentioned in the investigation steps in this brief.\u003c/li\u003e\n\u003cli\u003eImplement stricter IAM policies to limit the ability to create key pairs to only authorized users and roles.\u003c/li\u003e\n\u003cli\u003eMonitor for \u003ccode\u003eRunInstances\u003c/code\u003e or \u003ccode\u003eImportKeyPair\u003c/code\u003e events using the newly created key names as identified from \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e / \u003ccode\u003eresponse_elements\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eEnable and review AWS Config rules to detect and remediate misconfigurations related to IAM and EC2 key pair management.\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-ec2-keypair-creation/","summary":"An AWS EC2 CreateKeyPair event triggered by a new principal originating from a network autonomous system (AS) organization not associated with major cloud providers, indicating potential unauthorized access or persistence activity.","title":"Suspicious AWS EC2 Key Pair Creation from Non-Cloud AS","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-ec2-keypair-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["EC2"],"_cs_severities":["high"],"_cs_tags":["aws","ec2","user-data","privilege-escalation","persistence","execution"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection identifies a specific sequence of AWS EC2 API calls suggesting malicious intent. An adversary may update the \u003ccode\u003euserData\u003c/code\u003e attribute of an EC2 instance and then restart the instance to execute malicious scripts with elevated privileges (root on Linux, SYSTEM on Windows). The technique involves modifying instance attributes to inject malicious code or scripts, followed by stopping and starting the instance to trigger execution of the modified user data. This can lead to privilege escalation, persistence, or other malicious activities within the AWS environment. The detection focuses on the correlation of \u003ccode\u003eStopInstances\u003c/code\u003e, \u003ccode\u003eStartInstances\u003c/code\u003e, and \u003ccode\u003eModifyInstanceAttribute\u003c/code\u003e events that reference \u003ccode\u003euserData\u003c/code\u003e within a 5-minute window. The rule groups these events by instance ID, username, account ID, source IP, and user agent, triggering an alert only when all three distinct API calls are observed within the same group. This aims to reduce false positives by requiring the complete sequence of actions associated with this technique.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account with sufficient permissions to manage EC2 instances (e.g., via compromised credentials or an IAM role).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target EC2 instance.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eModifyInstanceAttribute\u003c/code\u003e API call to update the \u003ccode\u003euserData\u003c/code\u003e attribute of the target instance, injecting malicious code or scripts.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eStopInstances\u003c/code\u003e API call to stop the target EC2 instance.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eStartInstances\u003c/code\u003e API call to start the target EC2 instance.\u003c/li\u003e\n\u003cli\u003eUpon instance start, the modified \u003ccode\u003euserData\u003c/code\u003e script executes with elevated privileges, potentially installing malware, establishing persistence, or performing other malicious actions.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the compromised instance to further explore the AWS environment, escalate privileges, or exfiltrate data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized code execution within the AWS environment. Attackers can gain elevated privileges on the compromised EC2 instance, potentially leading to full control of the instance and the ability to access sensitive data or resources within the AWS account. This can result in data breaches, service disruptions, and financial losses. The modification of user data allows for persistent malicious code execution each time the instance restarts.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the following Sigma rules to your SIEM to detect the described attack pattern, and tune them to your environment.\u003c/li\u003e\n\u003cli\u003eReview CloudTrail logs for \u003ccode\u003eModifyInstanceAttribute\u003c/code\u003e events with \u003ccode\u003euserData\u003c/code\u003e to identify potentially malicious modifications.\u003c/li\u003e\n\u003cli\u003eMonitor EC2 instance state transitions (stop/start) in conjunction with user data modifications.\u003c/li\u003e\n\u003cli\u003eImplement least privilege IAM policies to restrict access to EC2 management APIs.\u003c/li\u003e\n\u003cli\u003eUse AWS Secrets Manager or Parameter Store to manage secrets instead of embedding them in \u003ccode\u003euserData\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules and correlate them with other security events.\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-03-aws-ec2-user-data-modification/","summary":"Detection of a sequence of AWS EC2 management API calls indicative of malicious modification of instance user data to execute arbitrary code upon instance restart, potentially leading to privilege escalation and persistence.","title":"AWS EC2 Stop, Start, and User Data Modification Correlation","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-ec2-user-data-modification/"}],"language":"en","title":"CraftedSignal Threat Feed — Ec2","version":"https://jsonfeed.org/version/1.1"}