{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/aws/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Systems Manager Session Manager"],"_cs_severities":["medium"],"_cs_tags":["aws","ssm","session-manager","execution","cloud"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAWS Systems Manager (SSM) Session Manager provides interactive shell access to EC2 instances and hybrid nodes without the need for bastion hosts or open inbound ports. Attackers can abuse this functionality by leveraging compromised AWS credentials or IAM roles with \u003ccode\u003essm:StartSession\u003c/code\u003e permissions to gain unauthorized access to target systems. This allows for remote execution of commands and lateral movement within the AWS environment. The technique involves spawning child processes from the SSM session worker process to perform malicious activities. Defenders should monitor for unusual process execution patterns originating from SSM sessions to identify potential abuse.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains access to valid AWS credentials or IAM role with \u003ccode\u003essm:StartSession\u003c/code\u003e permissions.\u003c/li\u003e\n\u003cli\u003eAttacker initiates an SSM session to a target EC2 instance or hybrid node using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003essm-session-worker\u003c/code\u003e process is started on the target instance to manage the interactive session.\u003c/li\u003e\n\u003cli\u003eAttacker executes commands within the session, spawning child processes from the \u003ccode\u003essm-session-worker\u003c/code\u003e process.\u003c/li\u003e\n\u003cli\u003eAttacker may use scripting languages such as PowerShell or Bash to execute malicious code (e.g., using \u003ccode\u003eawsrunPowerShellScript\u003c/code\u003e or \u003ccode\u003eawsrunShellScript\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThese scripts perform reconnaissance, download additional tools, or attempt credential access.\u003c/li\u003e\n\u003cli\u003eAttacker moves laterally to other instances or resources within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe ultimate objective is often data exfiltration, privilege escalation, or maintaining persistent access.\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 sensitive data, compromise of critical systems, and lateral movement within the AWS environment. The impact can range from data breaches to complete control of the compromised infrastructure. The number of affected systems depends on the scope of the compromised credentials and the attacker\u0026rsquo;s ability to move laterally. Organizations using AWS SSM are at risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rules in this brief to your SIEM and tune for your environment to detect suspicious child processes spawned by \u003ccode\u003essm-session-worker\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eCorrelate process activity with AWS CloudTrail logs for \u003ccode\u003eStartSession\u003c/code\u003e and related API calls to identify the IAM principal initiating the session (see the overview section for API names).\u003c/li\u003e\n\u003cli\u003eImplement strict IAM policies and regularly review AWS credentials to minimize the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003eprocess.command_line\u003c/code\u003e, \u003ccode\u003eprocess.executable\u003c/code\u003e, \u003ccode\u003eprocess.user.name\u003c/code\u003e for unusual activity within SSM sessions.\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-ssm-session-manager-abuse/","summary":"Adversaries abuse AWS Systems Manager (SSM) Session Manager to gain remote execution and lateral movement within AWS environments by spawning malicious child processes from the SSM session worker, leveraging legitimate AWS credentials and IAM permissions.","title":"AWS SSM Session Manager Child Process Execution Abuse","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-ssm-session-manager-abuse/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM","AWS Lambda"],"_cs_severities":["high"],"_cs_tags":["aws","iam","lambda","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis threat focuses on the abuse of AWS Lambda execution roles to perform sensitive IAM operations. Lambda functions, often running with over-permissioned roles, can be exploited by adversaries to escalate privileges and establish persistence within an AWS environment. An attacker gaining control of a Lambda function can leverage its execution role to make IAM API calls that would normally require elevated permissions. This includes creating new IAM users or roles, attaching policies to existing IAM entities, and modifying EC2 instance profiles. The scope of this threat includes any AWS environment utilizing Lambda functions with IAM permissions.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a Lambda function, either through code injection, vulnerable dependencies, or misconfiguration.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the Lambda function\u0026rsquo;s execution role, which has excessive IAM permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker executes IAM API calls, such as \u003ccode\u003eCreateUser\u003c/code\u003e, \u003ccode\u003eCreateRole\u003c/code\u003e, or \u003ccode\u003eCreateAccessKey\u003c/code\u003e, to create new IAM identities.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003eAttachUserPolicy\u003c/code\u003e, \u003ccode\u003ePutUserPolicy\u003c/code\u003e, \u003ccode\u003eAttachRolePolicy\u003c/code\u003e, or \u003ccode\u003ePutRolePolicy\u003c/code\u003e to grant elevated permissions to the newly created or existing IAM identities.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies instance profiles using \u003ccode\u003eCreateInstanceProfile\u003c/code\u003e and \u003ccode\u003eAddRoleToInstanceProfile\u003c/code\u003e to prepare EC2 instances for lateral movement.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created or modified IAM identities to assume roles and access resources they were not previously authorized to access via \u003ccode\u003ests:AssumeRole\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves privilege escalation, gaining control over sensitive AWS resources and services.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating rogue IAM users, roles, or access keys.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to full compromise of the AWS environment. An attacker could create highly privileged IAM users and roles, granting them the ability to access and control all AWS resources. This can result in data breaches, service disruptions, and financial losses. The impact is magnified in environments where Lambda functions are heavily relied upon for critical business operations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM Sensitive Operations via Lambda Execution Role\u0026rdquo; to your SIEM and tune for your environment to detect the described IAM API calls originating from Lambda execution roles.\u003c/li\u003e\n\u003cli\u003eReview and restrict the permissions granted to Lambda execution roles, following the principle of least privilege, to minimize the potential impact of a compromised function.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e to identify the Lambda function and associated deployment path responsible for the IAM API calls.\u003c/li\u003e\n\u003cli\u003eInvestigate \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e for targets such as \u003ccode\u003euserName\u003c/code\u003e, \u003ccode\u003egroupName\u003c/code\u003e, \u003ccode\u003eroleName\u003c/code\u003e, \u003ccode\u003epolicyArn\u003c/code\u003e, or \u003ccode\u003einstanceProfileName\u003c/code\u003e to understand the scope of the IAM operations.\u003c/li\u003e\n\u003cli\u003eRevoke or rotate the credentials of any compromised Lambda execution roles to prevent further unauthorized access.\u003c/li\u003e\n\u003cli\u003eRemediate any rogue IAM users, roles, or access keys created by the attacker to eliminate persistence mechanisms.\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-09-aws-lambda-iam-privilege-escalation/","summary":"Detection of IAM API calls that create or empower IAM users and roles, attach policies, or configure instance profiles when the caller is an assumed role session associated with AWS Lambda, potentially indicating privilege escalation or persistence.","title":"AWS IAM Privilege Operations via Lambda Execution Role","url":"https://feed.craftedsignal.io/briefs/2024-01-09-aws-lambda-iam-privilege-escalation/"},{"_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":["AWS S3","AWS CloudTrail"],"_cs_severities":["low"],"_cs_tags":["aws","s3","cloudtrail","discovery","enumeration","reconnaissance"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis threat brief covers suspicious activity related to the rapid enumeration of AWS S3 buckets. The activity is characterized by an AWS principal invoking read-only S3 control-plane APIs from the same source IP address within a short timeframe. This pattern is often associated with reconnaissance efforts, security scanning tools, or post-compromise enumeration activities. The behavior is similar to that observed with CSPM tools and by threat actors like Team PCP. The detection specifically excludes AWS service principals and requires programmatic-style sessions (i.e., not Management Console credentials). It focuses on scenarios where resource and identity fields are populated to avoid skewed results from null values. The detection threshold is set to greater than 15 distinct \u003ccode\u003eaws.cloudtrail.resources.arn\u003c/code\u003e values within a 10-second window.\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 environment using compromised credentials or through an exposed IAM role. (T1530)\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to AWS using the obtained credentials, creating a programmatic session.\u003c/li\u003e\n\u003cli\u003eThe attacker issues a series of \u003ccode\u003eGetBucketAcl\u003c/code\u003e, \u003ccode\u003eGetBucketPublicAccessBlock\u003c/code\u003e, \u003ccode\u003eGetBucketPolicy\u003c/code\u003e, \u003ccode\u003eGetBucketPolicyStatus\u003c/code\u003e, and \u003ccode\u003eGetBucketVersioning\u003c/code\u003e API calls to S3.\u003c/li\u003e\n\u003cli\u003eThese API calls are directed towards multiple distinct S3 buckets within a short timeframe (10 seconds).\u003c/li\u003e\n\u003cli\u003eThe attacker collects information about the bucket\u0026rsquo;s access control lists (ACLs), public access blocks, policies, versioning status, and other metadata. (T1526, T1580, T1619)\u003c/li\u003e\n\u003cli\u003eThe collected information is analyzed to identify publicly accessible buckets, misconfigurations, or sensitive data storage locations.\u003c/li\u003e\n\u003cli\u003eThe attacker uses identified vulnerabilities to exfiltrate data.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts lateral movement within the AWS environment, leveraging the discovered information to compromise other resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful enumeration of S3 buckets can lead to the discovery of sensitive data, misconfigurations, and publicly accessible resources. This can result in data breaches, unauthorized access, and further compromise of the AWS environment. The enumeration allows an attacker to map out the S3 storage landscape, identifying targets for data exfiltration or privilege escalation. The rapid nature of the enumeration suggests automated scanning or reconnaissance, potentially indicating a larger attack campaign.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the following Sigma rule to detect rapid S3 bucket enumeration activity based on AWS CloudTrail logs, adjusting the threshold of 15 distinct buckets to suit your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the source IP address (\u003ccode\u003esource.ip\u003c/code\u003e), AWS principal ARN (\u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e), and the list of accessed buckets (\u003ccode\u003eaws.cloudtrail.resources.arn\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eReview IAM policies associated with the identified principal to ensure least privilege for S3 read APIs.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for related events, such as \u003ccode\u003eListBuckets\u003c/code\u003e, \u003ccode\u003eGetObject\u003c/code\u003e, \u003ccode\u003ePutBucketPolicy\u003c/code\u003e, \u003ccode\u003eAssumeRole\u003c/code\u003e, or IAM changes, occurring within ±30 minutes of the detected enumeration activity.\u003c/li\u003e\n\u003cli\u003eImplement network-level restrictions on the source IP address if it is not authorized to perform S3 enumeration.\u003c/li\u003e\n\u003cli\u003eDocument approved scanning accounts and add user agent filters to the provided Sigma rule to reduce noise from those identities.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T19:43:38Z","date_published":"2026-05-01T19:43:38Z","id":"/briefs/2024-01-aws-s3-bucket-discovery/","summary":"An AWS principal rapidly enumerates S3 bucket posture using read-only APIs, indicative of reconnaissance, scanning, or post-compromise activity.","title":"Rapid Enumeration of AWS S3 Buckets","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-s3-bucket-discovery/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["cloud","aws","cloudtrail","discovery"],"_cs_type":"advisory","_cs_vendors":["AWS"],"content_html":"\u003cp\u003eThis detection rule identifies suspicious AWS reconnaissance activity originating from the AWS CLI. It triggers when a single AWS identity (IAM user, role, or service principal) makes more than five unique discovery-related API calls (such as \u003ccode\u003eDescribe*\u003c/code\u003e, \u003ccode\u003eList*\u003c/code\u003e, \u003ccode\u003eGet*\u003c/code\u003e, or \u003ccode\u003eGenerate*\u003c/code\u003e) within a 10-second window. The rule is designed to detect adversaries attempting to map out an AWS environment after gaining unauthorized access through compromised credentials or a compromised EC2 instance. The tool focuses on API calls related to key AWS services like EC2, IAM, S3, and KMS. This rule helps defenders identify and respond to early-stage reconnaissance activity, preventing further exploitation or data exfiltration. The rule excludes activity from AWS service accounts and the AWS Management Console, and it requires a minimum stack version of 9.2.0 with AWS integration version 4.6.0.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker gains access to an AWS environment, potentially through compromised credentials or by compromising an EC2 instance.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Usage:\u003c/strong\u003e The attacker leverages the AWS CLI to interact with the AWS environment using the compromised credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReconnaissance:\u003c/strong\u003e The attacker initiates a series of discovery API calls to gather information about the AWS infrastructure. This includes using \u003ccode\u003eDescribe*\u003c/code\u003e, \u003ccode\u003eList*\u003c/code\u003e, \u003ccode\u003eGet*\u003c/code\u003e, and \u003ccode\u003eGenerate*\u003c/code\u003e commands.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eResource Enumeration:\u003c/strong\u003e The attacker enumerates various AWS resources, including EC2 instances, IAM roles, S3 buckets, and KMS keys, by querying their respective APIs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTarget Identification:\u003c/strong\u003e The attacker analyzes the gathered information to identify potential targets for further exploitation, such as vulnerable EC2 instances or misconfigured S3 buckets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Optional):\u003c/strong\u003e If the compromised credentials have limited permissions, the attacker might attempt to escalate privileges to gain broader access to the AWS environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement (Optional):\u003c/strong\u003e The attacker might attempt to move laterally to other AWS accounts or services to expand their reach and impact.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Impact:\u003c/strong\u003e Based on the attacker\u0026rsquo;s goals, they may attempt to exfiltrate sensitive data or cause disruption by modifying or deleting resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation could lead to unauthorized access to sensitive data, such as customer information, intellectual property, or financial records. The attacker could also disrupt business operations by modifying or deleting critical resources. Identifying and responding to such activity in a timely manner can help prevent significant damage and maintain the security and integrity of the AWS environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the following Sigma rule to your SIEM and tune for your environment to detect the described reconnaissance activity.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging for all AWS regions and accounts in your organization to ensure the required logs are available for detection.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on identifying the affected AWS identity, the source IP address, and the specific API calls made (as captured by the Sigma rule).\u003c/li\u003e\n\u003cli\u003eIf suspicious activity is confirmed, follow AWS\u0026rsquo;s incident-handling guidance, including disabling or rotating the access key used and restricting outbound connectivity from the source (reference the AWS Security Incident Response Guide).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T19:43:38Z","date_published":"2026-05-01T19:43:38Z","id":"/briefs/2024-11-aws-discovery-api-calls/","summary":"This rule detects when a single AWS identity executes more than five unique discovery-related API calls (Describe*, List*, Get*, or Generate*) within a 10-second window using the AWS CLI, potentially indicating reconnaissance activity following credential compromise or compromised EC2 instance access.","title":"AWS Discovery API Calls via CLI from a Single Resource","url":"https://feed.craftedsignal.io/briefs/2024-11-aws-discovery-api-calls/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM","GitHub Actions"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","github","credential-theft","initial-access","lateral-movement"],"_cs_type":"advisory","_cs_vendors":["Amazon","Microsoft","Google"],"content_html":"\u003cp\u003eThis threat involves the unauthorized use of AWS credentials stolen from GitHub Actions secrets. Attackers exfiltrate these credentials and use them from their own infrastructure, bypassing the intended CI/CD environment. The activity is detected by observing AWS access keys appearing in CloudTrail logs originating from both legitimate GitHub Actions runners (identified by Microsoft ASN or the \u003ccode\u003egithub-actions\u003c/code\u003e user agent string) and suspicious infrastructure outside the expected CI/CD provider ASNs (Amazon, Google, Microsoft). This indicates a breach of GitHub repository or organization secrets, leading to potential unauthorized access and control over AWS resources. This activity can begin with compromised Github accounts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a GitHub repository or organization with AWS credentials stored as secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the AWS access key ID and secret access key, either manually or through automated means, such as modifying a GitHub Action workflow to expose the secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the stolen AWS credentials on their own infrastructure, using tools like the AWS CLI or boto3.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to authenticate to AWS using the stolen credentials. This generates CloudTrail logs with the attacker\u0026rsquo;s source IP address and ASN.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance activities, such as calling \u003ccode\u003ests:GetCallerIdentity\u003c/code\u003e, \u003ccode\u003eListBuckets\u003c/code\u003e, \u003ccode\u003eDescribeInstances\u003c/code\u003e, or \u003ccode\u003eListUsers\u003c/code\u003e, to understand the AWS environment and identify potential targets.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges or move laterally within the AWS environment by exploiting the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker may create, modify, or delete AWS resources, such as EC2 instances, S3 buckets, or IAM roles, depending on the permissions associated with the stolen credentials.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation leads to unauthorized access to AWS resources, potentially resulting in data breaches, service disruptions, or financial losses. The impact depends on the permissions associated with the stolen AWS credentials. A single compromised credential could expose sensitive data, disrupt critical services, or allow attackers to deploy malicious infrastructure within the victim\u0026rsquo;s AWS environment. Identifying and responding to this threat quickly is vital to minimize damages.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure\u0026rdquo; to your SIEM and tune for your environment to detect suspicious usage patterns.\u003c/li\u003e\n\u003cli\u003eRotate the compromised AWS access key in IAM immediately and update the corresponding GitHub repository/organization secret as described in the rule documentation.\u003c/li\u003e\n\u003cli\u003eImplement OIDC-based authentication (\u003ccode\u003eaws-actions/configure-aws-credentials\u003c/code\u003e with \u003ccode\u003erole-to-assume\u003c/code\u003e) instead of long-lived access keys as mentioned in the rule documentation.\u003c/li\u003e\n\u003cli\u003eIf using OIDC, add IP condition policies to the IAM role trust policy to restrict \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e to known GitHub runner IP ranges, based on the information in the rule documentation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T17:45:55Z","date_published":"2026-04-22T17:45:55Z","id":"/briefs/2024-01-aws-github-actions-credential-theft/","summary":"Attackers are stealing AWS credentials configured as GitHub Actions secrets and using them from non-CI/CD infrastructure, indicating potential credential theft and unauthorized access to AWS resources.","title":"AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-github-actions-credential-theft/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["cloud","aws","s3","reconnaissance"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat brief details detection of rapid enumeration of AWS S3 bucket configurations. The activity is characterized by an AWS principal invoking read-only S3 control-plane APIs across numerous buckets within a short timeframe. This pattern is consistent with automated reconnaissance, security scanning, or post-compromise enumeration. The activity is detected by monitoring AWS CloudTrail logs for specific API calls such as \u003ccode\u003eGetBucketAcl\u003c/code\u003e, \u003ccode\u003eGetBucketPublicAccessBlock\u003c/code\u003e, \u003ccode\u003eGetBucketPolicy\u003c/code\u003e, \u003ccode\u003eGetBucketPolicyStatus\u003c/code\u003e, and \u003ccode\u003eGetBucketVersioning\u003c/code\u003e. The detection logic excludes AWS service principals and sessions using Management Console credentials to reduce false positives. This activity is relevant for defenders as it can signal early-stage reconnaissance by threat actors like Team PCP, or unauthorized data discovery within the AWS environment. The rule uses a threshold of 15 distinct buckets accessed within 10 seconds to identify suspicious behavior.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to AWS credentials, possibly through compromised credentials or misconfigured IAM roles.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the acquired credentials to authenticate to the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a script or tool that calls multiple S3 APIs (e.g., \u003ccode\u003eGetBucketAcl\u003c/code\u003e, \u003ccode\u003eGetBucketPolicy\u003c/code\u003e) to gather information about S3 buckets.\u003c/li\u003e\n\u003cli\u003eThe tool iterates through a list of buckets, querying the configuration of each.\u003c/li\u003e\n\u003cli\u003eThe attacker collects the responses from the S3 API calls, mapping out bucket names, permissions, and access control lists.\u003c/li\u003e\n\u003cli\u003eThe attacker analyzes the collected data to identify potentially sensitive data or misconfigured buckets.\u003c/li\u003e\n\u003cli\u003eBased on the findings, the attacker may proceed to exfiltrate data from accessible buckets (T1530).\u003c/li\u003e\n\u003cli\u003eThe attacker may also attempt to modify bucket policies or access controls to gain further access or persistence.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful reconnaissance of S3 bucket configurations allows attackers to identify vulnerable buckets, potentially leading to data breaches or unauthorized access to sensitive information. The source material does not provide specific victim counts or sectors. However, the impact can range from exposure of confidential data to full compromise of the AWS environment, depending on the level of access gained and the sensitivity of the data stored in the targeted buckets. Identifying the activity early can prevent further exploitation.\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 rapid S3 bucket posture API calls (see: \u0026ldquo;AWS S3 Rapid Bucket Enumeration\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eReview IAM policies and enforce least privilege on S3 read APIs to limit the scope of potential reconnaissance activities.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for the same \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e and \u003ccode\u003esource.ip\u003c/code\u003e within approximately ±30 minutes for follow-on patterns such as \u003ccode\u003eListBuckets\u003c/code\u003e, \u003ccode\u003eGetObject\u003c/code\u003e, \u003ccode\u003ePutBucketPolicy\u003c/code\u003e, or \u003ccode\u003eAssumeRole\u003c/code\u003e activities (see Overview).\u003c/li\u003e\n\u003cli\u003eRotate or disable keys for the affected identity, revoke active role sessions where possible, and restrict the source IP at the network layer if it is not authorized (see Overview).\u003c/li\u003e\n\u003cli\u003eWhitelist approved scanning accounts and tune the Sigma rule to reduce noise from those identities (see Overview).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-11T12:00:00Z","date_published":"2026-04-11T12:00:00Z","id":"/briefs/2026-04-aws-s3-reconnaissance/","summary":"An AWS principal rapidly enumerates S3 bucket configurations using read-only APIs, potentially indicating reconnaissance activity by security scanners, CSPM tools, or malicious actors performing post-compromise enumeration.","title":"AWS S3 Rapid Bucket Posture API Calls Indicate Reconnaissance","url":"https://feed.craftedsignal.io/briefs/2026-04-aws-s3-reconnaissance/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","sts","discovery"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe 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.\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, either through phishing, credential stuffing, or compromised systems.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to authenticate to the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003ests:GetCallerIdentity\u003c/code\u003e API call to identify the associated AWS account ID, IAM user, or role.\u003c/li\u003e\n\u003cli\u003eThe AWS STS service processes the request and returns the identity information to the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker analyzes the returned identity information to understand the scope and privileges of the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the gathered information to perform further reconnaissance activities, such as identifying accessible resources and services.\u003c/li\u003e\n\u003cli\u003eBased on the discovered information, the attacker may attempt to escalate privileges or move laterally within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe final objective could include data exfiltration, deployment of malicious workloads, or disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS STS GetCallerIdentity API Called for the First Time by New Identity\u0026rdquo; to your SIEM and tune for your environment to detect anomalous usage of the GetCallerIdentity API.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003cli\u003eReview IAM permission policies for the user identity associated with the GetCallerIdentity API call to ensure the least privilege principle is followed.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging for all AWS regions in your account to ensure comprehensive event logging, as required by the detection rule.\u003c/li\u003e\n\u003cli\u003eConsider adding exceptions based on \u003ccode\u003euser.id\u003c/code\u003e or \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e values for automation workflows that legitimately rely on the GetCallerIdentity API, as mentioned in the overview.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise, as suggested in the documentation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:48:32Z","date_published":"2026-04-10T16:48:32Z","id":"/briefs/2024-10-aws-sts-getcalleridentity/","summary":"An adversary with access to compromised AWS credentials may attempt to verify their validity and determine the account they are using by calling the STS GetCallerIdentity API, potentially indicating credential compromise and unauthorized discovery activity.","title":"AWS STS GetCallerIdentity API Called for the First Time","url":"https://feed.craftedsignal.io/briefs/2024-10-aws-sts-getcalleridentity/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["cloud","aws","ssm","execution"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis rule identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. The rule focuses on detecting anomalous creation of SSM command documents. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, and data exfiltration. The rule utilizes AWS CloudTrail logs to monitor the \u003ccode\u003eCreateDocument\u003c/code\u003e API call within the SSM service. This activity is flagged when the user or role creating the document deviates from established patterns, indicating a potential security risk. This detection is relevant for organizations using AWS SSM for managing their infrastructure and aims to prevent unauthorized command execution on managed instances.\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 an exposed IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create a new SSM Command document using the \u003ccode\u003eCreateDocument\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eCreateDocument\u003c/code\u003e API call is logged by AWS CloudTrail with details about the user identity, request parameters, and document description.\u003c/li\u003e\n\u003cli\u003eThe detection rule analyzes CloudTrail logs, specifically looking for the \u003ccode\u003eCreateDocument\u003c/code\u003e event with a document type of \u003ccode\u003eCommand\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe rule identifies the user or role associated with the \u003ccode\u003eCreateDocument\u003c/code\u003e API call by inspecting the \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eIf the user or role is considered rare or unusual for creating SSM Command documents within the organization, the rule triggers an alert.\u003c/li\u003e\n\u003cli\u003eThe attacker could then use the created document to execute arbitrary commands on managed instances.\u003c/li\u003e\n\u003cli\u003eSuccessful execution of these commands leads to various impacts, including unauthorized access, command and control, data exfiltration, or disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe successful exploitation of this technique can lead to unauthorized access to AWS resources, potentially affecting all systems managed by AWS SSM in the targeted environment. The creation of malicious SSM command documents can lead to data exfiltration, system compromise, or denial of service. If successful, this can impact hundreds or thousands of systems depending on the scope of AWS SSM usage in the organization.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS SSM Command Document Created by Rare User\u0026rdquo; to your SIEM, ensuring proper indexing of CloudTrail logs (index = [\u0026ldquo;filebeat-*\u0026rdquo;, \u0026ldquo;logs-aws.cloudtrail-*\u0026rdquo;]).\u003c/li\u003e\n\u003cli\u003eReview the \u003ccode\u003eaws.cloudtrail.request_parameters.content\u003c/code\u003e field in the CloudTrail logs for any suspicious commands within the created SSM document.\u003c/li\u003e\n\u003cli\u003eRestrict SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation as mentioned in the overview.\u003c/li\u003e\n\u003cli\u003eMonitor the \u003ccode\u003eSendCommand\u003c/code\u003e API call related to the created SSM document to see if it is used to execute commands on managed instances, as described in the triage section.\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-11-aws-ssm-rare-user/","summary":"An AWS Systems Manager (SSM) command document creation by a user or role who does not typically perform this action, which can lead to unauthorized access, command and control, or data exfiltration.","title":"AWS SSM Command Document Created by Rare User","url":"https://feed.craftedsignal.io/briefs/2024-11-aws-ssm-rare-user/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis rule detects the creation of a console login profile for the AWS account root user, a highly privileged account. While \u003ccode\u003eCreateLoginProfile\u003c/code\u003e is normally applied to IAM users, when executed from a temporary root session (e.g., via \u003ccode\u003eAssumeRoot\u003c/code\u003e) without specifying a \u003ccode\u003euserName\u003c/code\u003e, the profile is created for the root principal. This activity is especially concerning because it provides persistent access. An attacker gaining temporary root access via STS or credential compromise might exploit this to set a root password. The attacker can then use this new password to log in through the console. This method circumvents traditional access key rotation or disabling and can be employed even after the initial vulnerability is patched. This activity started being tracked on 2024-12-02, defenders need to be aware of this persistence mechanism and promptly investigate any such incidents.\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 privileges, possibly through compromised credentials or an STS session.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eAssumeRoot\u003c/code\u003e API call to assume the privileges of the root user.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eCreateLoginProfile\u003c/code\u003e API call without specifying a \u003ccode\u003euserName\u003c/code\u003e. This action creates a console login profile directly for the root account instead of an IAM user. The \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e will not contain \u003ccode\u003euserName=\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker sets a password for the root account using the \u003ccode\u003eCreateLoginProfile\u003c/code\u003e API. \u003ccode\u003epasswordResetRequired\u003c/code\u003e might be set to \u003ccode\u003etrue\u003c/code\u003e or omitted, with omission potentially indicating an attacker-controlled password.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created root account password to log in to the AWS Management Console. The event will be logged as a \u003ccode\u003eConsoleLogin\u003c/code\u003e event.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the root account\u0026rsquo;s privileges to create or modify resources, escalate privileges, or exfiltrate data.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by using the console login, even if the initially compromised credentials or temporary session tokens are revoked.\u003c/li\u003e\n\u003cli\u003eThe attacker may also create new IAM users or roles with elevated permissions to further solidify their presence.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to complete control over the AWS environment. The attacker can create, modify, or delete resources; access sensitive data; and disrupt services. Because the root user has unrestricted privileges, the impact is extremely high. There have been no reported victim counts. However, any successful exploitation can have severe impacts including data breaches, financial loss, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM Login Profile Added for Root\u0026rdquo; to detect unauthorized creation of login profiles for the root account and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eCreateLoginProfile\u003c/code\u003e events where \u003ccode\u003eaws.cloudtrail.user_identity.type\u003c/code\u003e is \u003ccode\u003eRoot\u003c/code\u003e and \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e does not contain \u003ccode\u003euserName=\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eEnable CloudTrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity to improve overall visibility.\u003c/li\u003e\n\u003cli\u003eReview IAM policies for least-privilege adherence, focusing on \u003ccode\u003eiam:CreateLoginProfile\u003c/code\u003e, \u003ccode\u003eiam:UpdateLoginProfile\u003c/code\u003e, and \u003ccode\u003eiam:CreateAccessKey\u003c/code\u003e permissions.\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-12-aws-root-login-profile/","summary":"An adversary with temporary root access in AWS may create a login profile for the root account to establish persistent console access, even if the original access keys are rotated or disabled.","title":"AWS IAM Login Profile Added for Root","url":"https://feed.craftedsignal.io/briefs/2024-12-aws-root-login-profile/"},{"_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":[{"cvss":8.8,"id":"CVE-2026-5707"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["cve","command-injection","aws","res"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-5707 is an OS command injection vulnerability affecting AWS Research and Engineering Studio (RES) versions 2025.03 through 2025.12.01. The vulnerability resides in the virtual desktop session name handling, where user-supplied input is not properly sanitized before being used in an OS command. A remote, authenticated attacker can exploit this flaw by providing a specially crafted session name, leading to arbitrary command execution as root on the virtual desktop host. Successful exploitation allows the attacker to gain full control over the affected host, potentially compromising sensitive data and disrupting services. Users are advised to upgrade to RES version 2026.03 or apply the corresponding mitigation patch to their existing environment. The vulnerability was reported on April 6, 2026.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker authenticates to the AWS RES environment with valid credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a request to create a new virtual desktop session.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious session name containing OS command injection payload.\u003c/li\u003e\n\u003cli\u003eThe malicious session name is passed to the vulnerable function in AWS RES without proper sanitization.\u003c/li\u003e\n\u003cli\u003eThe vulnerable function executes an OS command, incorporating the unsanitized session name.\u003c/li\u003e\n\u003cli\u003eThe injected command within the session name is executed with root privileges on the virtual desktop host.\u003c/li\u003e\n\u003cli\u003eThe attacker gains arbitrary command execution, allowing them to install malware, create new users, or modify system configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves complete control of the virtual desktop host.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-5707 allows a remote attacker to execute arbitrary commands with root privileges on the virtual desktop host. This can lead to a complete compromise of the system, potentially affecting all users and data within the AWS RES environment. The attacker can steal sensitive information, install persistent backdoors, or disrupt critical services. The exact number of potential victims is unknown, but any organization utilizing vulnerable versions of AWS RES is at risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately upgrade AWS Research and Engineering Studio (RES) to version 2026.03 or apply the recommended mitigation patch to address CVE-2026-5707.\u003c/li\u003e\n\u003cli\u003eImplement input validation and sanitization for all user-supplied data, especially session names, to prevent OS command injection vulnerabilities.\u003c/li\u003e\n\u003cli\u003eMonitor AWS RES logs for suspicious activity related to session creation and command execution on the virtual desktop hosts.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Suspicious Session Names with OS Command Injection Characters\u0026rdquo; to identify potential exploitation attempts.\u003c/li\u003e\n\u003cli\u003eReview and harden the security configurations of the virtual desktop hosts to limit the impact of potential command execution.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T22:16:25Z","date_published":"2026-04-06T22:16:25Z","id":"/briefs/2026-04-aws-res-cmd-injection/","summary":"A remote authenticated attacker can execute arbitrary commands as root on the virtual desktop host by crafting a malicious session name in AWS Research and Engineering Studio (RES) versions 2025.03 through 2025.12.01 due to unsanitized input, leading to complete system compromise.","title":"AWS Research and Engineering Studio OS Command Injection Vulnerability (CVE-2026-5707)","url":"https://feed.craftedsignal.io/briefs/2026-04-aws-res-cmd-injection/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.8,"id":"CVE-2026-5709"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["cve-2026-5709","rce","aws","res"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-5709 affects AWS Research and Engineering Studio (RES), a cloud-based platform for research and engineering workflows. The vulnerability resides in the FileBrowser API and is present in versions 2024.10 through 2025.12.01. An authenticated attacker can exploit this vulnerability by sending crafted input to the FileBrowser functionality, leading to arbitrary command execution on the underlying cluster-manager EC2 instance. This could allow attackers to gain complete control over the RES environment, potentially compromising sensitive data and disrupting critical research activities. AWS recommends that users upgrade to RES version 2026.03 or apply a mitigation patch.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains valid credentials for an AWS Research and Engineering Studio (RES) account.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the RES environment.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts malicious input designed to exploit the unsanitized input vulnerability in the FileBrowser API.\u003c/li\u003e\n\u003cli\u003eThe attacker sends the crafted input to the FileBrowser API endpoint.\u003c/li\u003e\n\u003cli\u003eThe FileBrowser API processes the input without proper sanitization.\u003c/li\u003e\n\u003cli\u003eThe unsanitized input is executed as an operating system command on the cluster-manager EC2 instance.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves arbitrary command execution, potentially installing malware, exfiltrating data, or creating new administrative accounts.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-5709 grants the attacker the ability to execute arbitrary commands on the cluster-manager EC2 instance within the AWS Research and Engineering Studio (RES) environment. This can lead to complete compromise of the RES environment, data theft, denial of service, and potential lateral movement to other AWS resources. Due to the nature of research environments, this vulnerability could expose highly sensitive data, intellectual property, and research findings. The impact is significant due to the potential for widespread damage and disruption of critical research activities.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately upgrade AWS Research and Engineering Studio (RES) to version 2026.03 or apply the recommended mitigation patch provided by AWS to remediate CVE-2026-5709.\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;Detect Suspicious FileBrowser API Requests\u0026rdquo; to identify potential exploitation attempts targeting the FileBrowser API.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for suspicious activity related to the FileBrowser API endpoint, looking for unusual characters or command injection attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T22:16:25Z","date_published":"2026-04-06T22:16:25Z","id":"/briefs/2026-04-aws-res-rce/","summary":"CVE-2026-5709 is a critical vulnerability in AWS Research and Engineering Studio (RES) versions 2024.10 through 2025.12.01, allowing remote authenticated attackers to execute arbitrary commands on the cluster-manager EC2 instance through the FileBrowser API.","title":"AWS Research and Engineering Studio (RES) RCE via FileBrowser API Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-04-aws-res-rce/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","credential-access","initial-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule, published by Elastic, is designed to correlate AWS security alerts and prioritize investigations related to potentially compromised IAM access keys. Specifically, it focuses on scenarios where a long-term IAM access key is observed originating from a new source IP address (detected by the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule, rule ID 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) and is also associated with other open alerts of medium, high, or critical severity. This correlation aims to surface instances where a newly exposed or compromised access key is actively being used for malicious activities, enabling security teams to respond more effectively to potential credential access incidents and initial access attempts. The rule is a higher-order rule that analyzes existing security alerts within an Elastic Security deployment and leverages the \u003ccode\u003ekibana.alert\u003c/code\u003e fields to identify related events.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to a valid AWS IAM Long-Term Access Key. This could be through phishing, credential stuffing, or exposed credentials in source code.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised access key to interact with AWS services from a new and previously unseen IP address. This triggers the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule (rule ID: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised credentials to perform reconnaissance activities within the AWS environment, such as listing resources or querying IAM configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges by exploiting misconfigurations or vulnerabilities in IAM policies.\u003c/li\u003e\n\u003cli\u003eThe attacker performs actions indicating lateral movement within the AWS environment, such as accessing or modifying resources in different AWS accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker compromises additional AWS resources or services, such as EC2 instances or S3 buckets. These activities trigger medium, high, or critical severity alerts.\u003c/li\u003e\n\u003cli\u003eThe correlation rule identifies the co-occurrence of the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; alert and other elevated severity alerts associated with the same access key ID.\u003c/li\u003e\n\u003cli\u003eThe security team investigates the correlated alerts and takes appropriate remediation steps, such as rotating the compromised access key and reviewing IAM policies.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack leveraging compromised AWS IAM credentials can lead to significant data breaches, service disruption, and financial losses. Attackers can gain unauthorized access to sensitive data stored in S3 buckets, compromise EC2 instances, and disrupt critical AWS services. The correlation rule aims to reduce the dwell time of attackers by prioritizing the investigation of compromised credentials associated with ongoing malicious activity. This can prevent attackers from further escalating their attacks and minimizing the overall impact of the breach. Failure to detect and respond to these attacks can result in regulatory fines, reputational damage, and loss of customer trust.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts\u0026rdquo; rule (rule ID 98cfaa44-83f0-4aba-90c4-363fb9d51a75) in your Elastic Security environment to identify potentially compromised IAM access keys.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts triggered by the rule by pivoting on the \u003ccode\u003eaws.cloudtrail.user_identity.access_key_id\u003c/code\u003e in CloudTrail and IAM to understand the context of the access key usage.\u003c/li\u003e\n\u003cli\u003eReview the sibling alerts identified by the rule using \u003ccode\u003eEsql.kibana_alert_rule_name_values\u003c/code\u003e and \u003ccode\u003eEsql.kibana_alert_rule_id_values\u003c/code\u003e to understand the scope and impact of the potential compromise.\u003c/li\u003e\n\u003cli\u003eConfigure your Elastic Security deployment to properly map risk scores to severity levels, ensuring that \u003ccode\u003ekibana.alert.risk_score \u0026gt;= 47\u003c/code\u003e corresponds to medium or higher severity alerts.\u003c/li\u003e\n\u003cli\u003eRotate or disable any IAM access keys identified as compromised by the rule to prevent further unauthorized access.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging to capture detailed information about API calls made within your AWS environment, providing valuable context for investigating security alerts.\u003c/li\u003e\n\u003cli\u003eImplement the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule (rule_id: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) if not already enabled, as it is a pre-requisite for this correlation rule.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T14:37:37Z","date_published":"2026-04-06T14:37:37Z","id":"/briefs/2026-06-aws-iam-access-key-correlation/","summary":"This rule correlates AWS Long-Term Access Key First Seen from Source IP alerts with other open alerts of medium or higher severity that share the same IAM access key ID to prioritize investigation of potentially compromised accounts, helping identify post-compromise activity.","title":"AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts","url":"https://feed.craftedsignal.io/briefs/2026-06-aws-iam-access-key-correlation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["aws","cloudfront","injection","security"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA vulnerability exists in the CloudFront signing utilities within the AWS SDK for PHP, specifically impacting versions 3.11.7 through 3.371.3. These utilities are responsible for generating Amazon CloudFront signed URLs and signed cookies, which control access to content. The vulnerability arises from the improper handling of special characters, such as double quotes and backslashes, within input values used to construct policy documents. If an application passes unsanitized input containing these characters to the signing utilities, the resulting policy document may deviate from the application\u0026rsquo;s intended access restrictions. An enhancement was made to the AWS SDK for PHP version 3.371.4 to address this issue. This vulnerability impacts applications that do not properly sanitize inputs passed to the CloudFront signing utilities.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies an application using a vulnerable version of the AWS SDK for PHP (3.11.7 - 3.371.3) that utilizes CloudFront signed URLs or cookies.\u003c/li\u003e\n\u003cli\u003eThe attacker locates an input field within the application that is used to generate CloudFront policy documents.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious input string containing special characters (e.g., double quotes, backslashes) designed to manipulate the resulting policy document.\u003c/li\u003e\n\u003cli\u003eThe application passes the attacker-controlled input to the CloudFront signing utilities without proper sanitization or validation.\u003c/li\u003e\n\u003cli\u003eThe CloudFront signing utilities generate a signed URL or cookie with a flawed policy document due to the injected special characters.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the crafted signed URL or cookie to bypass intended access restrictions and potentially gain unauthorized access to protected content.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses restricted resources on CloudFront that should have been protected by the intended policy.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability could lead to unauthorized access to content protected by Amazon CloudFront. If an attacker can manipulate the policy document, they might bypass intended access restrictions, potentially exposing sensitive data or allowing unauthorized actions. The number of affected applications is unknown, but any application using the vulnerable versions of the AWS SDK for PHP and failing to sanitize input is at risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to AWS SDK for PHP version 3.371.4 or later to incorporate the fix that addresses special character handling (reference: Patches section).\u003c/li\u003e\n\u003cli\u003eImplement robust input validation in application code to sanitize or escape special characters before passing values to CloudFront signing utilities (reference: Workarounds section).\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for unusual patterns of URL requests containing special characters that might indicate exploitation attempts (reference: webserver log source).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-27T19:54:58Z","date_published":"2026-03-27T19:54:58Z","id":"/briefs/2024-01-aws-sdk-cloudfront-injection/","summary":"A vulnerability exists in the AWS SDK for PHP CloudFront signing utilities where special characters in input values are not properly handled when creating policy documents, potentially leading to unintended access restrictions, affecting versions 3.11.7 through 3.371.3.","title":"AWS SDK for PHP CloudFront Policy Document Injection via Special Characters","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-sdk-cloudfront-injection/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["aws","privilege-escalation","lateral-movement"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies when an IAM user assumes a role in AWS Security Token Service (STS) within an AWS environment. The AWS Security Token Service (STS) allows users to request temporary, limited-privilege credentials for accessing AWS resources. While legitimate role assumption is common for authorized access, adversaries can abuse this mechanism to escalate privileges or move laterally within a compromised AWS account. This behavior is detected by monitoring AWS CloudTrail logs for \u003ccode\u003eAssumeRole\u003c/code\u003e events from IAM users. The rule focuses on identifying potentially malicious role assumptions by correlating the user identity, assumed role, and source information.\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 as an IAM user, potentially through compromised credentials or an exposed access key.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates available IAM roles within the AWS environment to identify roles with elevated privileges or access to sensitive resources.\u003c/li\u003e\n\u003cli\u003eThe attacker calls the \u003ccode\u003eAssumeRole\u003c/code\u003e API in AWS STS, requesting temporary credentials for the target role, using a \u003ccode\u003eroleSessionName\u003c/code\u003e for context.\u003c/li\u003e\n\u003cli\u003eThe STS service validates the request and, if authorized, issues temporary credentials consisting of an \u003ccode\u003eaccessKeyId\u003c/code\u003e, \u003ccode\u003esecretAccessKey\u003c/code\u003e, and \u003ccode\u003esessionToken\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker configures their AWS CLI or SDK with the temporary credentials obtained from the STS service.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the temporary credentials to access AWS resources and perform actions permitted by the assumed role, such as modifying security groups, accessing S3 buckets, or launching EC2 instances.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to further escalate privileges by assuming additional roles or creating new IAM users with administrative privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful role assumption can grant an attacker access to sensitive data, allow them to disrupt critical services, or provide a foothold for further attacks within the AWS environment. While this rule has a low severity, a high volume of alerts should be reviewed as it could indicate ongoing lateral movement and privilege escalation. The impact of a successful attack can range from data breaches and service disruptions to complete compromise of the AWS environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule provided below to your SIEM and tune for your environment to detect suspicious role assumptions.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the rule by reviewing the associated CloudTrail logs, specifically the \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e and \u003ccode\u003eaws.cloudtrail.resources.arn\u003c/code\u003e fields.\u003c/li\u003e\n\u003cli\u003eImplement additional monitoring for high-risk roles with elevated permissions, and create exceptions for trusted patterns.\u003c/li\u003e\n\u003cli\u003eRegularly review IAM policies and roles to minimize the risk of privilege escalation.\u003c/li\u003e\n\u003cli\u003eRefer to the AWS STS documentation for more details on managing and securing AWS STS in your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-04T18:01:49Z","date_published":"2026-03-04T18:01:49Z","id":"/briefs/2026-03-aws-sts-role-assumption/","summary":"Detection of a user assuming a role in AWS Security Token Service (STS) to obtain temporary credentials, which can indicate privilege escalation or lateral movement.","title":"AWS STS Role Assumption by User","url":"https://feed.craftedsignal.io/briefs/2026-03-aws-sts-role-assumption/"},{"_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":[],"_cs_severities":["medium"],"_cs_tags":["aws","cloudtrail","saml","iam","deletion","impact"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe deletion of a SAML provider in AWS can be a significant indicator of malicious activity. An attacker who has gained initial access to an AWS environment may attempt to remove the SAML provider used by the information security team or system administrators. This action can severely impede the team\u0026rsquo;s ability to investigate and respond to ongoing attacks. By disrupting access, the attacker gains a window of opportunity to further escalate privileges, move laterally within the environment, and achieve their objectives without immediate detection or intervention. This activity directly impacts the availability and integrity of resources within the AWS cloud environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access is gained to an AWS account through compromised credentials or other means (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing IAM resources, including SAML providers, using AWS CLI or API calls.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the SAML provider used by administrative or security teams.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eDeleteSAMLProvider\u003c/code\u003e API call via the AWS CLI, API, or AWS Management Console (T1531).\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eDeleteSAMLProvider\u003c/code\u003e event is logged in AWS CloudTrail with a \u0026ldquo;success\u0026rdquo; status.\u003c/li\u003e\n\u003cli\u003eAdministrative and security teams lose access to AWS resources that require SAML authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised account to escalate privileges, create new IAM users, or modify existing policies.\u003c/li\u003e\n\u003cli\u003eThe attacker persists in the environment, potentially exfiltrating data or deploying malicious workloads (T1485).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe deletion of an AWS SAML provider can have serious consequences. It disrupts access for administrators and security personnel, delaying incident response and potentially allowing attackers to further compromise the environment. This can lead to data breaches, service disruptions, and financial losses. The severity of the impact depends on the criticality of the affected AWS resources and the speed of detection and recovery.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS SAML Provider Deletion Activity\u0026rdquo; to your SIEM and tune for your environment to detect this specific event.\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eDeleteSAMLProvider\u003c/code\u003e events in AWS CloudTrail, focusing on the user identity, user agent, and source IP address (logsource: aws/cloudtrail).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users, especially those with administrative privileges, to reduce the risk of credential compromise (T1110).\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for all IAM roles and users to limit the impact of compromised credentials.\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-19-aws-saml-provider-deletion/","summary":"An adversary may delete an AWS SAML provider to disrupt administrative access, hindering incident response and potentially escalating privileges within the AWS environment.","title":"AWS SAML Provider Deletion Activity","url":"https://feed.craftedsignal.io/briefs/2024-12-19-aws-saml-provider-deletion/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS EC2","AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","network-routing"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe addition of a new route to an AWS route table can be a sign of malicious activity, especially if the route redirects traffic to an unexpected or unauthorized destination. This activity is typically logged in AWS CloudTrail. Attackers might add routes to intercept network traffic, conduct man-in-the-middle attacks, or impair defenses by routing traffic away from security appliances. Understanding who is performing this action and the destination of the new route is critical for identifying potential threats within an AWS environment.\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 AWS account, potentially through compromised credentials or an exploited vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the AWS CLI or the AWS Management Console to interact with the EC2 service.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the target route table to modify.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eCreateRoute\u003c/code\u003e API call, specifying the destination CIDR block and target (e.g., an internet gateway, virtual private gateway, or network interface).\u003c/li\u003e\n\u003cli\u003eCloudTrail logs the \u003ccode\u003eCreateRoute\u003c/code\u003e event, capturing details of the action, including the user identity, source IP address, and the route table modification.\u003c/li\u003e\n\u003cli\u003eNetwork traffic matching the new route\u0026rsquo;s destination CIDR block is now redirected to the attacker-controlled target.\u003c/li\u003e\n\u003cli\u003eThe attacker monitors and potentially modifies the redirected traffic for reconnaissance or data exfiltration purposes.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of AWS route tables can lead to significant security breaches. An attacker could redirect critical network traffic to a malicious endpoint, enabling them to intercept sensitive data or disrupt services. This could lead to data breaches, financial loss, and reputational damage. The scope of the impact depends on the criticality of the redirected traffic and the attacker\u0026rsquo;s objectives.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Detect AWS Route Table Modification via CloudTrail\u0026rdquo; Sigma rule to your SIEM and tune for your environment to detect suspicious route creation events in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eCreateRoute\u003c/code\u003e events where the user identity is unexpected or the destination CIDR block and target are suspicious.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for \u003ccode\u003eCreateRoute\u003c/code\u003e events and correlate them with other suspicious activities.\u003c/li\u003e\n\u003cli\u003eImplement strict IAM policies to limit who can modify route tables (reference the \u003ccode\u003eeventSource\u003c/code\u003e and \u003ccode\u003eeventName\u003c/code\u003e fields in the rule below).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-01T12:00:00Z","date_published":"2024-11-01T12:00:00Z","id":"/briefs/2024-11-aws-route-added/","summary":"An attacker may add a new route to an AWS route table, potentially redirecting network traffic for malicious purposes such as defense impairment or data exfiltration.","title":"Detect AWS Route Table Modification via CloudTrail","url":"https://feed.craftedsignal.io/briefs/2024-11-aws-route-added/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["aws","cloud","lateral-movement","credential-access"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe AWS GetSigninToken API, typically used for legitimate console access, can be abused by attackers to generate temporary, federated credentials. This technique, often facilitated by tools like \u003ccode\u003eaws_consoler\u003c/code\u003e, allows attackers to obfuscate the compromised access keys used to generate the tokens. By pivoting from the AWS CLI to console sessions with these temporary credentials, adversaries bypass MFA requirements and complicate forensic investigations. This activity is crucial for defenders to monitor, especially in environments not configured for AWS SSO, as it can indicate unauthorized access and lateral movement within the AWS infrastructure. The tool \u003ccode\u003eaws_consoler\u003c/code\u003e is specifically designed to automate this process, creating a streamlined path for malicious actors to leverage compromised credentials for further exploitation.\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 environment using compromised credentials (access key, secret key).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials with the AWS CLI or SDK to call the \u003ccode\u003eGetSigninToken\u003c/code\u003e API.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the \u003ccode\u003eGetSigninToken\u003c/code\u003e event with the event source \u003ccode\u003esignin.amazonaws.com\u003c/code\u003e and event name \u003ccode\u003eGetSigninToken\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eGetSigninToken\u003c/code\u003e API returns a temporary sign-in token.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the temporary token along with the AWS account ID to construct a sign-in URL.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the AWS Management Console via the crafted URL, bypassing MFA if the original compromised credentials required it.\u003c/li\u003e\n\u003cli\u003eOnce in the console, the attacker performs reconnaissance, identifies valuable resources, and escalates privileges as needed.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the AWS environment, accessing and potentially exfiltrating sensitive data, or disrupting services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful abuse of the \u003ccode\u003eGetSigninToken\u003c/code\u003e API can lead to unauthorized access to the AWS Management Console, enabling lateral movement and data exfiltration.  The obfuscation of the original compromised credentials makes incident response more difficult. While the exact number of victims is unknown, this technique has been observed in intrusions targeting telecom and BPO companies.  The impact includes potential data breaches, service disruptions, and reputational damage.\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 suspicious \u003ccode\u003eGetSigninToken\u003c/code\u003e events in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eGetSigninToken\u003c/code\u003e events originating from outside of expected AWS SSO user agents or other known legitimate sources.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for \u003ccode\u003eGetSigninToken\u003c/code\u003e events where the requesting user identity does not match expected patterns.\u003c/li\u003e\n\u003cli\u003eImplement and enforce MFA for all AWS IAM users, even though this attack bypasses it for console access using the temporary tokens.\u003c/li\u003e\n\u003cli\u003eReview and restrict IAM policies to adhere to the principle of least privilege, minimizing the potential impact of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-04-29T12:00:00Z","date_published":"2024-04-29T12:00:00Z","id":"/briefs/2024-04-aws-get-signin-token-abuse/","summary":"Adversaries may abuse the AWS GetSigninToken API to create temporary federated credentials for obfuscating compromised AWS access keys and pivoting to console sessions without MFA, potentially leading to lateral movement within the AWS environment.","title":"Potential Abuse of AWS Console GetSigninToken","url":"https://feed.craftedsignal.io/briefs/2024-04-aws-get-signin-token-abuse/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["aws","cloudtrail","initial-access","credential-access"],"_cs_type":"advisory","_cs_vendors":["Amazon","Google","Microsoft","MongoDB"],"content_html":"\u003cp\u003eThis detection identifies AWS identities that primarily use API traffic originating from well-known cloud providers (e.g., Amazon, Google, Microsoft), but also exhibit a small amount of traffic from less common Autonomous System (AS) organizations. This pattern can indicate that automation or CI credentials are being reused or pivoted outside of their usual hosted cloud environment. The detection focuses on successful API calls and looks for a combination of high volume from trusted cloud providers and at least one sensitive action originating from an uncommon network. This behavior could be indicative of credential compromise and lateral movement. This rule was published by Elastic on 2026-04-22.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to valid AWS credentials, potentially through phishing, credential stuffing, or exposed secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to make API calls from their own infrastructure, which is associated with a rare AS organization.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance, such as \u003ccode\u003eGetCallerIdentity\u003c/code\u003e, \u003ccode\u003eListBuckets\u003c/code\u003e, or \u003ccode\u003eListSecrets\u003c/code\u003e, to understand the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges by calling \u003ccode\u003eAssumeRole\u003c/code\u003e, \u003ccode\u003eAttachUserPolicy\u003c/code\u003e, or \u003ccode\u003eCreateAccessKey\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access sensitive data using actions such as \u003ccode\u003eGetObject\u003c/code\u003e or \u003ccode\u003eGetSecretValue\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create new users or modify existing user profiles using actions such as \u003ccode\u003eCreateUser\u003c/code\u003e, \u003ccode\u003eUpdateLoginProfile\u003c/code\u003e, or \u003ccode\u003eAddUserToGroup\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to invoke cloud ML models using \u003ccode\u003eInvokeModel\u003c/code\u003e or \u003ccode\u003eConverse\u003c/code\u003e to further their objectives.\u003c/li\u003e\n\u003cli\u003eThe attacker persists in the environment by creating new IAM users, roles, or policies, or by modifying existing ones.\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 in S3 buckets, Secrets Manager, or other AWS services. It can also allow the attacker to escalate privileges, create new users, and modify existing configurations, leading to long-term control of the AWS environment. The severity of the impact depends on the level of access granted to the compromised credentials. This can lead to exfiltration of sensitive data, denial of service, or complete compromise of the AWS account.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable AWS CloudTrail logging in all regions and send logs to a centralized SIEM or logging platform to enable detection capabilities (\u003ca href=\"https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html\"\u003ereferences\u003c/a\u003e).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS Rare Source AS Organization Activity\u0026rdquo; translated from the provided ESQL query to detect unusual source ASNs for AWS API calls.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the rule, focusing on the \u003ccode\u003euser.name\u003c/code\u003e, \u003ccode\u003eaws.cloudtrail.user_identity.type\u003c/code\u003e, \u003ccode\u003eEsql.src_asn_values\u003c/code\u003e, and \u003ccode\u003eEsql.untrusted_suspicious_actions\u003c/code\u003e to understand the context of the activity.\u003c/li\u003e\n\u003cli\u003eRotate credentials for the affected principal if abuse is suspected and enforce OIDC or short-lived keys for automation.\u003c/li\u003e\n\u003cli\u003eTighten IAM and data-plane permissions to limit the impact of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"/briefs/2024-01-29-aws-rare-asn/","summary":"This rule detects AWS identities with API traffic dominated by cloud-provider source AS organization labels, but also exhibit traffic from other AS organizations, potentially indicating credential reuse or pivoting.","title":"AWS Identity API Access from Rare ASN Organizations","url":"https://feed.craftedsignal.io/briefs/2024-01-29-aws-rare-asn/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM","AWS S3"],"_cs_severities":["high"],"_cs_tags":["aws","iam","s3browser","s3","policy","cloudtrail"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe S3Browser utility is being used to create Inline IAM policies within AWS. This activity is flagged as suspicious when the policy includes the default S3 bucket name placeholder value of \u003ccode\u003e\u0026lt;YOUR-BUCKET-NAME\u0026gt;\u003c/code\u003e. This could indicate that the user has not properly configured the policy or is unaware of the implications of using a generic placeholder, potentially granting unintended access to S3 resources. This behavior was observed being used by the threat actor Guivil. The use of S3Browser in this manner poses a risk of privilege escalation, persistence, and unauthorized access to sensitive data stored in S3 buckets.\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, possibly through compromised credentials or misconfigured IAM roles (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker utilizes the S3Browser utility to interact with AWS S3 buckets.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create an Inline IAM policy using S3Browser.\u003c/li\u003e\n\u003cli\u003eThe attacker fails to replace the default bucket name placeholder \u003ccode\u003e\u0026lt;YOUR-BUCKET-NAME\u0026gt;\u003c/code\u003e with a specific bucket ARN.\u003c/li\u003e\n\u003cli\u003eThe attacker saves the IAM policy with the default bucket name placeholder, leading to a broad or unintended scope of permissions.\u003c/li\u003e\n\u003cli\u003eThe poorly configured policy is applied to a user, role, or group.\u003c/li\u003e\n\u003cli\u003eThe attacker potentially escalates privileges or gains unauthorized access to S3 resources.\u003c/li\u003e\n\u003cli\u003eThe attacker persists in the environment with the newly created or modified IAM policy.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCreation of an IAM policy with the default bucket name placeholder leaves S3 buckets open to potential unauthorized access. A successful attack could lead to data exfiltration, data modification, or denial of service. The scope of the impact depends on the specific permissions granted within the policy and the resources accessible through the affected IAM user, role, or group.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM S3Browser Templated S3 Bucket Policy Creation\u0026rdquo; to your SIEM and tune for your environment to detect this specific activity.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances where \u003ccode\u003ePutUserPolicy\u003c/code\u003e events are associated with the S3Browser user agent (logsource: aws/cloudtrail).\u003c/li\u003e\n\u003cli\u003eReview existing IAM policies for the presence of the default bucket name placeholder \u003ccode\u003earn:aws:s3:::\u0026lt;YOUR-BUCKET-NAME\u0026gt;/*\u003c/code\u003e (logsource: aws/cloudtrail).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T12:00:00Z","date_published":"2024-01-26T12:00:00Z","id":"/briefs/2024-01-26-s3browser-iam-policy/","summary":"An AWS IAM policy is created by the S3Browser utility with the default S3 bucket name placeholder, potentially indicating unauthorized access or misconfiguration.","title":"S3Browser IAM Policy Creation with Default Bucket Name","url":"https://feed.craftedsignal.io/briefs/2024-01-26-s3browser-iam-policy/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["KMS"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","kms","privilege-escalation","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis rule detects the successful execution of the \u003ccode\u003ePutKeyPolicy\u003c/code\u003e API call within Amazon Web Services Key Management Service (AWS KMS). The \u003ccode\u003ePutKeyPolicy\u003c/code\u003e action replaces the entire key policy associated with a KMS key, potentially granting new or expanded permissions to principals. An adversary who gains the ability to modify KMS key policies (\u003ccode\u003ekms:PutKeyPolicy\u003c/code\u003e) can escalate privileges by adding external accounts or roles, allowing them to decrypt data protected by the key or maintain persistent access even after credential rotation. This activity is crucial to monitor, as it can lead to significant data breaches and unauthorized access to sensitive information. The rule focuses on identifying deviations from expected KMS key policy management practices to detect potentially malicious activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises an AWS account or obtains IAM credentials with sufficient permissions, including \u003ccode\u003ekms:PutKeyPolicy\u003c/code\u003e on a target KMS key.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to call the \u003ccode\u003ePutKeyPolicy\u003c/code\u003e API, replacing the existing key policy with a modified version.\u003c/li\u003e\n\u003cli\u003eThe modified key policy grants the attacker\u0026rsquo;s AWS account, or an external account, permissions to perform cryptographic operations on the key, such as \u003ccode\u003ekms:Decrypt\u003c/code\u003e or \u003ccode\u003ekms:GenerateDataKey\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker utilizes the newly granted permissions to decrypt data encrypted with the KMS key, such as data stored in S3 buckets or EBS volumes.\u003c/li\u003e\n\u003cli\u003eThe attacker may also grant administrative actions to new identities.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the decrypted data to an external location.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to cover their tracks by deleting CloudTrail logs or modifying other security configurations.\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 sensitive data encrypted with the KMS key, potentially resulting in data breaches, financial loss, and reputational damage. The severity depends on the sensitivity of the data protected by the key and the scope of access granted to the attacker. This can impact organizations across various sectors that rely on AWS KMS for data encryption, potentially affecting millions of records and causing significant operational disruption.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS KMS Key Policy Updated via PutKeyPolicy\u0026rdquo; to your SIEM and tune for your environment to detect unauthorized modifications to KMS key policies.\u003c/li\u003e\n\u003cli\u003eReview the policy document diff in \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e and \u003ccode\u003eaws.cloudtrail.response_elements\u003c/code\u003e to identify unauthorized changes to principals.\u003c/li\u003e\n\u003cli\u003eRestrict the \u003ccode\u003ekms:PutKeyPolicy\u003c/code\u003e permission to break-glass roles only, limiting the potential for unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003eiam:AttachRolePolicy\u003c/code\u003e and \u003ccode\u003ests:AssumeRole\u003c/code\u003e events to correlate with potential privilege escalation attempts related to KMS key access.\u003c/li\u003e\n\u003cli\u003eRestore a known-good KMS policy from backup or IAM/KMS change history to remediate unauthorized modifications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-22T18:23:00Z","date_published":"2024-01-22T18:23:00Z","id":"/briefs/2024-01-aws-kms-key-policy-put/","summary":"Detection of successful PutKeyPolicy calls on AWS KMS keys to identify potential privilege escalation or unauthorized access by adversaries modifying key policies to decrypt or exfiltrate data.","title":"AWS KMS Key Policy Updated via PutKeyPolicy","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-kms-key-policy-put/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Management Console"],"_cs_severities":["medium"],"_cs_tags":["aws","cloudtrail","mfa","initial-access"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe absence of multi-factor authentication (MFA) during AWS console logins presents a significant security risk. Threat actors often target AWS environments due to the high value of data and services hosted within. An attacker gaining initial access through compromised credentials can move laterally, escalate privileges, and potentially exfiltrate sensitive data, deploy malicious workloads, or disrupt critical services. This activity can go unnoticed for extended periods, increasing the potential for damage. Detecting successful console logins without MFA is crucial for identifying potential breaches and ensuring the enforcement of security best practices. This brief focuses on detecting these logins to mitigate the risk of unauthorized access and potential data breaches.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker obtains valid AWS credentials, possibly through phishing, credential stuffing, or by exploiting a vulnerable service.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to attempt to log in to the AWS Management Console.\u003c/li\u003e\n\u003cli\u003eThe attacker successfully authenticates without providing an MFA code, indicating MFA is not enabled or is bypassed for the compromised user.\u003c/li\u003e\n\u003cli\u003eAfter successful login, the attacker enumerates existing AWS resources, including EC2 instances, S3 buckets, and IAM roles, using the AWS CLI or Console.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges by exploiting IAM misconfigurations or vulnerabilities to gain access to more sensitive resources.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies security configurations, such as disabling CloudTrail logging or creating new IAM users with elevated permissions, to establish persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses sensitive data stored in S3 buckets or databases, potentially exfiltrating it to an external location.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful AWS console login without MFA can lead to a full compromise of the AWS environment. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and deploy malicious workloads. The lack of MFA increases the likelihood of successful credential-based attacks, potentially affecting a large number of organizations hosting data and applications in AWS. Consequences include data breaches, financial losses, reputational damage, and legal liabilities.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;AWS Successful Console Login Without MFA\u0026rdquo; Sigma rule to your SIEM to detect logins without MFA (rule).\u003c/li\u003e\n\u003cli\u003eEnforce MFA for all AWS IAM users, especially those with administrative privileges to prevent initial access (reference: \u003ca href=\"https://securitylabs.datadoghq.com/cloud-security-atlas/vulnerabilities/iam-user-without-mfa/)\"\u003ehttps://securitylabs.datadoghq.com/cloud-security-atlas/vulnerabilities/iam-user-without-mfa/)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eRegularly audit IAM configurations to identify and remediate misconfigurations that could allow privilege escalation.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for suspicious activity following a console login, such as resource enumeration or IAM policy changes (logsource).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T15:00:00Z","date_published":"2024-01-09T15:00:00Z","id":"/briefs/2024-01-09-aws-console-login-no-mfa/","summary":"Successful AWS console logins without multi-factor authentication can indicate compromised credentials, misconfigured security settings, or unauthorized access attempts.","title":"Successful AWS Console Login Without MFA","url":"https://feed.craftedsignal.io/briefs/2024-01-09-aws-console-login-no-mfa/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM","AWS STS"],"_cs_severities":["medium"],"_cs_tags":["aws","saml","cloudtrail","initial-access","lateral-movement","persistence","privilege-escalation","stealth"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection identifies potentially malicious Security Assertion Markup Language (SAML) activity within Amazon Web Services (AWS). The activity includes monitoring for \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e and \u003ccode\u003eUpdateSAMLProvider\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises or creates a malicious SAML identity provider.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the AWS environment to trust the malicious SAML provider using \u003ccode\u003eUpdateSAMLProvider\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a SAML assertion to assume a specific role within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e API call to authenticate with AWS using the crafted SAML assertion.\u003c/li\u003e\n\u003cli\u003eAWS STS validates the SAML assertion and, if valid, provides temporary credentials for the assumed role.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the temporary credentials to perform actions within AWS, potentially escalating privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the AWS environment, accessing resources and services authorized for the assumed role.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistent access by creating backdoors or modifying existing IAM policies, leveraging the initially gained access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule for \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e events to detect suspicious role assumptions (see \u0026ldquo;AssumeRoleWithSAML Detection Rule\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule for \u003ccode\u003eUpdateSAMLProvider\u003c/code\u003e events to detect unauthorized SAML provider modifications (see \u0026ldquo;UpdateSAMLProvider Detection Rule\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e events originating from unfamiliar user agents or IP addresses by reviewing CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003eUpdateSAMLProvider\u003c/code\u003e events for unexpected changes to SAML provider configurations. Review associated CloudTrail logs for user identity, user agent, and hostname to ensure authorized access.\u003c/li\u003e\n\u003cli\u003eTune the provided Sigma rules for your environment, addressing false positives by exempting known, legitimate behavior.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:22:30Z","date_published":"2024-01-03T18:22:30Z","id":"/briefs/2024-01-03-aws-suspicious-saml/","summary":"This rule identifies suspicious SAML activity in AWS, such as AssumeRoleWithSAML and UpdateSAMLProvider events, which could indicate an attacker gaining backdoor access, escalating privileges, or establishing persistence.","title":"Suspicious AWS SAML Activity Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-suspicious-saml/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GuardDuty"],"_cs_severities":["high"],"_cs_tags":["defense-impairment","aws","cloudtrail"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAttackers with sufficient AWS privileges may attempt to disable or delete AWS GuardDuty detectors to evade detection. GuardDuty is a threat detection service that monitors AWS accounts for malicious activity. Disabling it allows attackers to operate with less chance of being detected. This activity may occur post-compromise as part of a broader defense evasion strategy, or as a precursor to malicious activities. The deletion or disabling of GuardDuty detectors should be considered a critical event, warranting immediate investigation to verify legitimacy. The references suggest that this behavior has been observed in the wild and is documented across multiple security vendors.\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 through compromised credentials or other means (T1078).\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing GuardDuty detectors to identify the target for disabling or deletion (T1068).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS API using stolen credentials or an assumed role with sufficient permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker calls the \u003ccode\u003eDeleteDetector\u003c/code\u003e API to remove the GuardDuty detector entirely, erasing all existing findings (T1685.002).\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker calls the \u003ccode\u003eUpdateDetector\u003c/code\u003e API to disable the detector by setting the \u003ccode\u003eenable\u003c/code\u003e parameter to \u003ccode\u003efalse\u003c/code\u003e (T1685.002).\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the \u003ccode\u003eDeleteDetector\u003c/code\u003e or \u003ccode\u003eUpdateDetector\u003c/code\u003e event with a \u003ccode\u003eSuccess\u003c/code\u003e or \u003ccode\u003enull\u003c/code\u003e error code.\u003c/li\u003e\n\u003cli\u003eWith GuardDuty disabled, the attacker performs malicious actions such as lateral movement, data exfiltration, or resource compromise without immediate detection.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to remove CloudTrail logs to further impair defenses (T1562.008).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to the complete loss of threat detection capabilities within the AWS environment. With GuardDuty disabled, malicious activities can go unnoticed, potentially leading to data breaches, unauthorized access, or resource compromise. The impact is significant because GuardDuty is a primary security control for many organizations using AWS. Depending on the attacker\u0026rsquo;s objectives, this could result in financial loss, reputational damage, or compliance violations. The references suggest that this is a known technique used by attackers to evade detection in AWS environments.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS GuardDuty Detector Deleted Or Updated\u0026rdquo; to your SIEM using AWS CloudTrail logs to detect attempts to disable or delete GuardDuty (logsource: aws, service: cloudtrail).\u003c/li\u003e\n\u003cli\u003eInvestigate all instances of \u003ccode\u003eDeleteDetector\u003c/code\u003e and \u003ccode\u003eUpdateDetector\u003c/code\u003e events in CloudTrail, especially if initiated from unusual locations or IAM roles.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users to reduce the risk of credential compromise (T1110).\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege by granting only necessary permissions to IAM roles (T1078).\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for anomalies that could indicate malicious activity following a GuardDuty disablement.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T17:38:00Z","date_published":"2024-01-03T17:38:00Z","id":"/briefs/2024-01-03-aws-guardduty-disable/","summary":"Attackers may delete or disable AWS GuardDuty detectors to impair defenses and evade detection of malicious activities within the AWS environment.","title":"AWS GuardDuty Detector Deletion or Disablement","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-guardduty-disable/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail","EKS IAM Roles for Service Accounts"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","kubernetes","lateral-movement","credential-access","discovery"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection rule identifies lateral movement in AWS environments stemming from Kubernetes service accounts utilizing \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e. It focuses on detecting instances where credentials obtained via this method are subsequently used to perform several distinct AWS control-plane actions within a single session. This behavior deviates from typical pod traffic and could signify unauthorized access or privilege escalation. The rule prioritizes the detection of sensitive API usage, including reconnaissance activities, access to secrets, IAM modifications, and compute creation events, while strategically excluding high-volume S3 data-plane operations to minimize false positives. The targeted environments are those leveraging EKS IAM Roles for Service Accounts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA Kubernetes service account projects a token.\u003c/li\u003e\n\u003cli\u003eThe service account uses \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e to exchange the token for short-lived IAM credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the assumed role to perform reconnaissance activities such as \u003ccode\u003eListUsers\u003c/code\u003e, \u003ccode\u003eListRoles\u003c/code\u003e, and \u003ccode\u003eDescribeInstances\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access secrets using actions like \u003ccode\u003eGetSecretValue\u003c/code\u003e and \u003ccode\u003eListSecrets\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges by modifying IAM policies with actions like \u003ccode\u003eAttachRolePolicy\u003c/code\u003e and \u003ccode\u003ePutRolePolicy\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create new users or roles within the AWS environment using actions like \u003ccode\u003eCreateUser\u003c/code\u003e and \u003ccode\u003eCreateRole\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker performs lateral movement using actions like \u003ccode\u003eSendCommand\u003c/code\u003e and \u003ccode\u003eStartSession\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to evade detection by stopping logging with the \u003ccode\u003eStopLogging\u003c/code\u003e action.\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 sensitive data, privilege escalation, and the potential compromise of the entire AWS environment. Lateral movement within the AWS infrastructure allows attackers to gain access to critical systems and data, potentially leading to data breaches, service disruptions, or other malicious activities.\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 potentially malicious activity related to \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e and tune for your environment.\u003c/li\u003e\n\u003cli\u003eReview and harden IAM role trust policies associated with Kubernetes service accounts, specifically focusing on OIDC trust conditions, as referenced in the \u003ca href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html\"\u003eIAM OIDC identity provider\u003c/a\u003e documentation.\u003c/li\u003e\n\u003cli\u003eImplement strict least privilege principles for Kubernetes service accounts, limiting their access to only the necessary AWS resources, as covered in \u003ca href=\"https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html\"\u003eEKS IAM roles for service accounts\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e events followed by suspicious API calls, focusing on the actions listed in the Sigma rule detection patterns.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-aws-k8s-lateral-movement/","summary":"This rule detects lateral movement in AWS environments originating from Kubernetes service accounts by identifying instances where credentials obtained for a service account are used for multiple distinct AWS control-plane actions, potentially indicating unauthorized access.","title":"AWS Lateral Movement from Kubernetes Service Account via AssumeRoleWithWebIdentity","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-k8s-lateral-movement/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Security Hub"],"_cs_severities":["high"],"_cs_tags":["aws","cloud","securityhub","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAttackers with sufficient AWS privileges can manipulate SecurityHub findings to evade detection and maintain persistence within a compromised environment. This involves using SecurityHub\u0026rsquo;s API to either modify existing findings, delete insights altogether, or update insights to mask malicious activity. This activity is conducted via API calls to \u003ccode\u003esecurityhub.amazonaws.com\u003c/code\u003e, specifically targeting the \u003ccode\u003eBatchUpdateFindings\u003c/code\u003e, \u003ccode\u003eDeleteInsight\u003c/code\u003e, \u003ccode\u003eUpdateFindings\u003c/code\u003e, and \u003ccode\u003eUpdateInsight\u003c/code\u003e actions. Successful evasion allows malicious actors to operate without triggering alarms or attracting attention from security personnel, leading to prolonged compromise and potentially greater damage. This is especially critical in production environments where SecurityHub findings are actively monitored.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a misconfigured IAM role (T1078).\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing SecurityHub findings and insights to identify potential targets for modification or deletion.\u003c/li\u003e\n\u003cli\u003eThe attacker calls the \u003ccode\u003eBatchUpdateFindings\u003c/code\u003e API to modify the severity, confidence, or resolution status of specific findings, effectively silencing alerts (T1562.003).\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker calls the \u003ccode\u003eUpdateFindings\u003c/code\u003e API to modify individual findings.\u003c/li\u003e\n\u003cli\u003eThe attacker calls the \u003ccode\u003eDeleteInsight\u003c/code\u003e API to remove custom insights that could reveal their activities (T1562).\u003c/li\u003e\n\u003cli\u003eAs another option, the attacker calls the \u003ccode\u003eUpdateInsight\u003c/code\u003e API to modify the criteria of existing insights, causing them to miss malicious activities.\u003c/li\u003e\n\u003cli\u003eThe attacker validates the changes by querying SecurityHub to confirm that the targeted findings and insights have been successfully altered or removed.\u003c/li\u003e\n\u003cli\u003eThe attacker continues malicious activities, such as data exfiltration or lateral movement, with a reduced risk of detection due to the modified SecurityHub state (TA0005).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful evasion of SecurityHub findings can lead to delayed incident response, prolonged attacker presence within the AWS environment, and increased data exfiltration or system compromise. The impact is particularly severe in production environments where SecurityHub is relied upon for real-time threat detection and alerting. By modifying or deleting findings, attackers can effectively blind security teams, enabling them to operate undetected for extended periods. The number of potential victims is directly proportional to the scale of AWS deployments relying on SecurityHub.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS SecurityHub Findings Evasion\u0026rdquo; to your SIEM and tune for your environment to detect suspicious API calls related to findings manipulation (logsource: aws, service: cloudtrail).\u003c/li\u003e\n\u003cli\u003eReview and harden IAM policies to restrict access to SecurityHub API actions such as \u003ccode\u003eBatchUpdateFindings\u003c/code\u003e, \u003ccode\u003eDeleteInsight\u003c/code\u003e, \u003ccode\u003eUpdateFindings\u003c/code\u003e, and \u003ccode\u003eUpdateInsight\u003c/code\u003e to only authorized users and roles.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts and roles, especially those with permissions to modify SecurityHub configurations.\u003c/li\u003e\n\u003cli\u003eRegularly audit CloudTrail logs for suspicious activity related to SecurityHub configuration changes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-aws-securityhub-evasion/","summary":"Attackers can impair defenses by modifying or deleting findings and insights within AWS SecurityHub using API calls such as BatchUpdateFindings, DeleteInsight, UpdateFindings, and UpdateInsight.","title":"AWS SecurityHub Findings Evasion via API Calls","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-securityhub-evasion/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Identity Center"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","identity","persistence","credential-access","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAWS Identity Center (formerly AWS SSO) enables centralized management of access to AWS accounts and applications. Attackers can manipulate the configured identity provider to gain unauthorized access. The modification of the configured Identity Provider (IdP) within AWS Identity Center can lead to a full compromise of the AWS environment. By associating a malicious directory or disabling/disassociating legitimate directories, attackers can potentially establish persistent access, escalate privileges, and impersonate legitimate users. This can be achieved by utilizing compromised AWS credentials or exploiting vulnerabilities in the AWS environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access is gained via compromised AWS credentials or by exploiting an AWS vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates the current AWS Identity Center configuration to identify the currently associated directory.\u003c/li\u003e\n\u003cli\u003eThe attacker disassociates the existing, legitimate directory using \u003ccode\u003eDisassociateDirectory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker associates a malicious directory they control using \u003ccode\u003eAssociateDirectory\u003c/code\u003e. This malicious directory is configured to impersonate legitimate users.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker disables external IdP configuration for the directory using \u003ccode\u003eDisableExternalIdPConfigurationForDirectory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker enables external IdP configuration for the directory, pointing to an attacker-controlled IdP, using \u003ccode\u003eEnableExternalIdPConfigurationForDirectory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the malicious or attacker-controlled IdP to authenticate as legitimate users, gaining access to AWS resources.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions within the AWS environment, such as data exfiltration or resource destruction.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of the AWS Identity Center identity provider can lead to complete compromise of an AWS environment. Attackers can gain persistent access, escalate privileges, and impersonate legitimate users. This can result in data breaches, service disruption, financial loss, and reputational damage. The impact can extend to all AWS accounts and applications managed by the compromised Identity Center instance.\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 unauthorized changes to the AWS Identity Center identity provider.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected events related to \u003ccode\u003eAssociateDirectory\u003c/code\u003e, \u003ccode\u003eDisableExternalIdPConfigurationForDirectory\u003c/code\u003e, \u003ccode\u003eDisassociateDirectory\u003c/code\u003e, or \u003ccode\u003eEnableExternalIdPConfigurationForDirectory\u003c/code\u003e in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts and users to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and restrict IAM permissions to minimize the blast radius of compromised credentials.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for unusual activity patterns that might indicate malicious directory association attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-aws-idp-change/","summary":"An adversary modifies the AWS Identity Center identity provider configuration, potentially leading to persistent access and privilege escalation through user impersonation.","title":"AWS Identity Center Identity Provider Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-idp-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe S3 Browser utility, a Windows-based client for managing Amazon S3 storage and other cloud services, can be abused by threat actors to create new IAM users or access keys within compromised AWS environments. This activity, if unauthorized, can lead to privilege escalation, persistence, or even initial access, depending on the context of the compromise. The use of S3 Browser is identifiable via the userAgent string in AWS CloudTrail logs. While legitimate use of S3 Browser for administrative tasks exists, its unexpected appearance in user activity, particularly in sensitive accounts, should be investigated. This activity is particularly concerning because it can allow attackers to establish a foothold in the cloud environment and move laterally.\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 environment, potentially through compromised credentials or an exploited vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker installs and configures S3 Browser on a compromised host or uses an existing installation.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates S3 Browser to the AWS environment using existing compromised credentials or an assumed role.\u003c/li\u003e\n\u003cli\u003eThe attacker uses S3 Browser to execute the \u003ccode\u003eCreateUser\u003c/code\u003e API call within AWS IAM.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the new IAM user with elevated privileges, potentially granting administrator access.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker uses S3 Browser to execute the \u003ccode\u003eCreateAccessKey\u003c/code\u003e API call for an existing IAM user.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created access key to perform actions within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the new user or access key for persistence, lateral movement, and data exfiltration within the AWS environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation and IAM creation can lead to complete compromise of the AWS environment. An attacker with escalated privileges can access sensitive data, modify configurations, disrupt services, and deploy malicious infrastructure. Depending on the permissions granted to the created user or access key, the attacker could potentially pivot to other AWS accounts or services, leading to widespread damage. This can result in significant financial losses, reputational damage, and regulatory penalties.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM S3Browser User or AccessKey Creation\u0026rdquo; to your SIEM and tune for your environment to detect anomalous IAM activity originating from S3 Browser.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of \u003ccode\u003eCreateUser\u003c/code\u003e or \u003ccode\u003eCreateAccessKey\u003c/code\u003e events in AWS CloudTrail logs where the \u003ccode\u003euserAgent\u003c/code\u003e contains \u0026ldquo;S3 Browser\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for all IAM users and roles to limit the impact of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-s3browser-iam/","summary":"The use of S3 Browser to create IAM users or access keys in AWS environments indicates a potential privilege escalation, persistence, or initial access attempt by threat actors leveraging a known cloud administration tool.","title":"AWS IAM User or Access Key Creation via S3 Browser","url":"https://feed.craftedsignal.io/briefs/2024-01-03-s3browser-iam/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["aws","cloud","lateral-movement","privilege-escalation","sts","GetSessionToken"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe 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\u0026rsquo;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.\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 environment, potentially through compromised IAM user credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to AWS using the compromised IAM user credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker calls the STS GetSessionToken API, specifying desired permissions or roles (if permitted by the IAM user\u0026rsquo;s policies).\u003c/li\u003e\n\u003cli\u003eAWS STS generates a new set of temporary credentials (access key ID, secret access key, and session token).\u003c/li\u003e\n\u003cli\u003eThe attacker configures their AWS CLI or SDK to use the newly acquired temporary credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages these temporary credentials to perform actions within the AWS environment, potentially escalating privileges or moving laterally.\u003c/li\u003e\n\u003cli\u003eThe attacker covers their tracks by deleting the CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data, deploys malware, or causes disruption within the AWS environment using the acquired privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS STS GetSessionToken Misuse\u0026rdquo; to your SIEM to detect suspicious GetSessionToken API calls (see rules section).\u003c/li\u003e\n\u003cli\u003eInvestigate GetSessionToken calls where \u003ccode\u003euserIdentity.type\u003c/code\u003e is \u003ccode\u003eIAMUser\u003c/code\u003e to determine if the request is legitimate.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for unusual patterns of GetSessionToken usage, particularly from unfamiliar user agents or hosts.\u003c/li\u003e\n\u003cli\u003eImplement strong IAM policies and MFA to minimize the risk of compromised IAM user credentials.\u003c/li\u003e\n\u003cli\u003eReview the false positives section of the Sigma rule to tune the rule for your specific environment.\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-sts-getsessiontoken-misuse/","summary":"The AWS STS GetSessionToken API is being misused to create temporary tokens for lateral movement and privilege escalation within AWS environments by potentially compromised IAM users.","title":"Suspicious AWS STS GetSessionToken Usage","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-sts-getsessiontoken-misuse/"},{"_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":["Elastic Compute Cloud (EC2)"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","defense-evasion","vpc","flow-logs"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAn adversary with sufficient privileges within an AWS environment may attempt to delete VPC Flow Logs. These logs are crucial for monitoring network traffic within a VPC, and their removal can significantly impede incident response and forensic investigations. The deletion is accomplished by making a \u003ccode\u003eDeleteFlowLogs\u003c/code\u003e API call. This action is often taken to remove evidence of malicious activity, such as lateral movement, command and control communication, or data exfiltration. The impact of this activity can be severe, potentially allowing attackers to operate undetected for extended periods.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the AWS environment through compromised credentials or an exploited vulnerability (not detailed in source).\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges within the AWS environment to gain the necessary permissions to delete VPC Flow Logs (not detailed in source).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the AWS CLI or AWS Management Console to execute the \u003ccode\u003eDeleteFlowLogs\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the specific Flow Log IDs that need to be deleted.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS API using stolen or generated credentials.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eDeleteFlowLogs\u003c/code\u003e API call is made, specifying the Flow Log IDs to be deleted.\u003c/li\u003e\n\u003cli\u003eAWS processes the request and deletes the specified VPC Flow Logs.\u003c/li\u003e\n\u003cli\u003eThe attacker verifies the deletion of the Flow Logs to ensure that their actions are no longer being logged.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful deletion of VPC Flow Logs prevents security teams from detecting malicious activity within the AWS environment. Without these logs, it becomes significantly more difficult to investigate security incidents, track attacker movements, and understand the scope of a compromise. This can lead to delayed incident response, increased dwell time for attackers, and greater overall damage. The absence of flow logs severely limits network visibility, hindering any attempt to reconstruct events or identify compromised assets.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;AWS VPC Flow Logs Deleted\u0026rdquo; to detect instances of \u003ccode\u003eDeleteFlowLogs\u003c/code\u003e API calls (reference: rules section).\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for \u003ccode\u003eDeleteFlowLogs\u003c/code\u003e events and investigate any unexpected occurrences (reference: logsource).\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege to restrict IAM users and roles from having the \u003ccode\u003eec2:DeleteFlowLogs\u003c/code\u003e permission unless absolutely necessary.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit IAM policies to ensure that permissions are appropriately scoped and not overly permissive.\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-vpc-flow-logs-deleted/","summary":"An adversary may delete VPC Flow Logs in AWS EC2 by calling the DeleteFlowLogs API to evade detection and hinder forensic investigations.","title":"AWS VPC Flow Logs Deletion for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-vpc-flow-logs-deleted/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS STS"],"_cs_severities":["high"],"_cs_tags":["aws","privilege-escalation","lateral-movement","sts","getfederationtoken"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe 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.\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 IAM user credentials or an exploited vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies an IAM user with the necessary permissions to call the STS GetFederationToken API.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a GetFederationToken API request, including a session policy that directly references \u0026ldquo;AdministratorAccess\u0026rdquo; or includes a policy ARN that grants administrator privileges.\u003c/li\u003e\n\u003cli\u003eThe GetFederationToken API call is successfully executed, generating temporary security credentials with broad administrator permissions.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to laterally move within the AWS environment by leveraging the newly acquired administrator privileges to compromise other resources or accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker could establish persistence by creating new IAM users or roles with elevated permissions, ensuring continued access even after the temporary credentials expire.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, which could include data exfiltration, service disruption, or financial gain.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS STS GetFederationToken with AdministratorAccess in Request\u0026rdquo; to your SIEM to detect instances of this activity (rule title).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e to identify the specific policy being used (rule title).\u003c/li\u003e\n\u003cli\u003eRevoke or rotate the IAM user access keys involved in the GetFederationToken call and enforce least privilege on the user (rule description).\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for subsequent events using \u003ccode\u003eresponse_elements.credentials.accessKeyId\u003c/code\u003e from the same response to identify actions taken with the temporary credentials (rule description).\u003c/li\u003e\n\u003cli\u003eReview and update IAM policies to ensure that session policies used with GetFederationToken adhere to the principle of least privilege (rule description).\u003c/li\u003e\n\u003cli\u003eImplement automated checks to prevent the creation or modification of IAM policies that grant AdministratorAccess except in explicitly approved scenarios (rule description).\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-sts-admin-access/","summary":"Detection of AWS STS GetFederationToken calls with AdministratorAccess in the request parameters, indicating potential privilege escalation or dangerous automation via broadly privileged temporary credentials.","title":"AWS STS GetFederationToken with AdministratorAccess in Request","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-sts-admin-access/"},{"_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/"},{"_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/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["EC2","AWS CloudTrail"],"_cs_severities":["high"],"_cs_tags":["aws","privilege-escalation","lateral-movement"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis threat brief focuses on the potential for privilege escalation and lateral movement within Amazon Web Services (AWS) environments by abusing the ability to associate or replace IAM instance profiles on running EC2 instances. An attacker with the necessary permissions (\u003ccode\u003eec2:AssociateIamInstanceProfile\u003c/code\u003e or \u003ccode\u003eec2:ReplaceIamInstanceProfile\u003c/code\u003e and typically \u003ccode\u003eiam:PassRole\u003c/code\u003e) can elevate the privileges of a compromised EC2 instance. This is achieved by attaching a more privileged IAM role to the instance, granting the attacker access to resources and permissions beyond their initial scope. The event is logged in AWS CloudTrail, providing a critical detection opportunity for security teams.\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 vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a running EC2 instance with limited privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies or creates a more privileged IAM role that grants broader access to AWS resources.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eAssociateIamInstanceProfile\u003c/code\u003e or \u003ccode\u003eReplaceIamInstanceProfile\u003c/code\u003e API calls to associate the privileged IAM role with the target EC2 instance. This requires appropriate IAM permissions.\u003c/li\u003e\n\u003cli\u003eThe EC2 instance\u0026rsquo;s metadata service now provides credentials for the newly associated IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to access sensitive data or resources, potentially including other EC2 instances, databases, or storage buckets.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the AWS environment, compromising additional resources and escalating their access.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as exfiltrating data, deploying malicious code, or disrupting services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to elevate privileges within the AWS environment, potentially leading to unauthorized access to sensitive data, lateral movement to other systems, and disruption of critical services. The impact could range from data breaches and financial losses to reputational damage and regulatory fines. Identifying and responding to these events quickly is crucial to minimizing potential damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS EC2 Instance Profile Associated with Running Instance\u0026rdquo; to your SIEM using AWS CloudTrail logs to detect suspicious activity.\u003c/li\u003e\n\u003cli\u003eReview and harden IAM permissions related to \u003ccode\u003eec2:AssociateIamInstanceProfile\u003c/code\u003e and \u003ccode\u003eec2:ReplaceIamInstanceProfile\u003c/code\u003e to limit who can modify instance profiles.\u003c/li\u003e\n\u003cli\u003eEnable CloudTrail logging for all regions in your AWS account to ensure comprehensive audit coverage.\u003c/li\u003e\n\u003cli\u003eImplement least privilege principles for IAM roles assigned to EC2 instances to minimize the impact of potential privilege escalation.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the source IP address, user identity, and the IAM role associated with the instance profile.\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-instance-profile-association/","summary":"An attacker may escalate privileges by associating a compromised EC2 instance with a more privileged IAM instance profile.","title":"AWS EC2 Instance Profile Associated with Running Instance","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-ec2-instance-profile-association/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["EKS","STS"],"_cs_severities":["high"],"_cs_tags":["aws","cloudtrail","iam","kubernetes","initial-access","web-identity"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection rule identifies instances of successful AWS \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e calls originating from a Kubernetes service account but not from an Amazon-managed Autonomous System Number (ASN). The primary concern is the potential compromise or misuse of projected service account tokens. Kubernetes service accounts can be mapped to IAM roles through OIDC using IRSA (IAM Roles for Service Accounts). Typically, these credential requests originate from within AWS-managed or associated networks. However, if a request with a Kubernetes service account identity originates from an external ASN (i.e., not \u003ccode\u003eAmazon.com, Inc.\u003c/code\u003e), it raises suspicion that the token might have been exfiltrated and is being used from an unauthorized location. This rule is designed to highlight such anomalies, prompting further investigation into possible token theft or misconfiguration.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains unauthorized access to a Kubernetes service account token within a compromised pod or through other means.\u003c/li\u003e\n\u003cli\u003eAttacker exfiltrates the service account token from the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the exfiltrated token to call the AWS STS \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e API.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e call is made from a network with an ASN organization name that is not \u003ccode\u003eAmazon.com, Inc.\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the successful \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e event, including details about the user, source IP, and ASN organization.\u003c/li\u003e\n\u003cli\u003eThe compromised IAM role is used to perform unauthorized actions within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThese actions could include data exfiltration, resource modification, or further lateral movement within the cloud infrastructure.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack of this nature can lead to significant security breaches within an AWS environment. An attacker leveraging stolen service account tokens can gain unauthorized access to sensitive resources, leading to data breaches, service disruption, or financial loss. This is especially concerning for organizations heavily reliant on Kubernetes and AWS, as it can undermine the security of their cloud-native applications and infrastructure. While the number of affected organizations is unknown, the potential impact on those targeted can be severe, leading to substantial remediation costs and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by following the investigation steps in the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eExpand the \u003ccode\u003esource.as.organization.name\u003c/code\u003e exclusions in the Sigma rule for known and trusted egress paths if needed.\u003c/li\u003e\n\u003cli\u003eEnable geolocation/ASN enrichment for your AWS CloudTrail logs to accurately identify the source of \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e calls.\u003c/li\u003e\n\u003cli\u003eRegularly review and rotate IRSA trust relationships to minimize the impact of compromised service account tokens.\u003c/li\u003e\n\u003cli\u003eRevoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce service account and role permissions if unauthorized access is suspected.\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-assume-role-external-asn/","summary":"Detects successful AWS `AssumeRoleWithWebIdentity` calls where the caller identity is a Kubernetes service account and the source autonomous system organization is not `Amazon.com, Inc.`, which may indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster.","title":"AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-assume-role-external-asn/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","privilege-escalation","initial-access","persistence","stealth"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe use of the AWS root account should be strictly limited to specific tasks that cannot be performed with IAM users or roles. This alert indicates that the root account was used, which could signify various security concerns. An attacker with access to the root account can perform any action within the AWS environment, including creating new users, modifying security policies, accessing sensitive data, and deleting resources. Defenders should investigate each instance of root account usage to determine legitimacy. This activity may also indicate a misconfiguration where IAM roles should be used.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to the AWS root account credentials through credential theft or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS Management Console or uses the AWS CLI with the root account credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates AWS resources to identify potential targets for privilege escalation.\u003c/li\u003e\n\u003cli\u003eThe attacker creates or modifies IAM policies to grant themselves additional permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker may create new IAM users or roles with elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the elevated privileges to access sensitive data stored in S3 buckets or other AWS services.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies security configurations, such as network access control lists or security groups, to facilitate lateral movement or data exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker could disable logging features to cover tracks.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromise of the AWS root account can lead to a complete breach of the AWS environment, resulting in unauthorized access to sensitive data, data loss, service disruption, and potential financial losses. Attackers can leverage root privileges to perform nearly any action within the AWS account, affecting all services and resources. The number of affected victims depends on the scope and criticality of the AWS environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS Root Credentials\u0026rdquo; to your SIEM to detect root account usage based on CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate all instances of root account usage identified by the \u0026ldquo;AWS Root Credentials\u0026rdquo; Sigma rule to determine legitimacy.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) on all AWS accounts, including the root account, as documented in \u003ca href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html\"\u003eAWS documentation\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement the principle of least privilege by granting IAM users and roles only the permissions they need to perform their tasks.\u003c/li\u003e\n\u003cli\u003eRegularly audit IAM policies and user permissions to identify and remove unnecessary privileges.\u003c/li\u003e\n\u003cli\u003eDisable or restrict root account access wherever possible, delegating tasks to IAM users/roles.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T14:30:00Z","date_published":"2024-01-02T14:30:00Z","id":"/briefs/2024-01-02-aws-root-usage/","summary":"The AWS root account, which grants unrestricted access to all resources within an AWS account, was used, potentially indicating unauthorized activity, privilege escalation, or a breach of security best practices.","title":"AWS Root Account Usage Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-02-aws-root-usage/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["S3"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","s3","data_loss"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe deletion of S3 buckets is a critical event to monitor in AWS environments. While legitimate administrative actions may involve bucket deletion, unauthorized or accidental removal of buckets can lead to significant data loss and business disruption. This brief focuses on detecting such events through AWS CloudTrail logs, which record API calls made within the AWS infrastructure. Monitoring for \u003ccode\u003eDeleteBucket\u003c/code\u003e events helps identify potential malicious activity or unintentional misconfigurations that could compromise data availability and integrity. This detection focuses on identifying DeleteBucket API calls, successful or otherwise, within CloudTrail logs to provide early warning of potential data compromise.\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 AWS account through compromised credentials or a privilege escalation exploit.\u003c/li\u003e\n\u003cli\u003eThe attacker lists existing S3 buckets to identify potential targets using the \u003ccode\u003eListBuckets\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target S3 bucket containing sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to delete the target S3 bucket by issuing a \u003ccode\u003eDeleteBucket\u003c/code\u003e API call using the AWS CLI or SDK.\u003c/li\u003e\n\u003cli\u003eCloudTrail logs the \u003ccode\u003eDeleteBucket\u003c/code\u003e event, including the user identity, timestamp, and bucket name.\u003c/li\u003e\n\u003cli\u003eIf successful, the S3 bucket and its contents are permanently deleted.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to remove CloudTrail logs to cover their tracks, using the \u003ccode\u003eDeleteTrail\u003c/code\u003e API call.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe deletion of an S3 bucket results in the permanent loss of all data stored within that bucket. This can lead to service disruption, data breaches, and financial losses, especially if the bucket contained critical business data or backups. The impact can range from temporary inconvenience to complete business failure depending on the criticality of the data lost and the organization\u0026rsquo;s backup and recovery capabilities. Without proper monitoring and alerting, an S3 bucket deletion can go unnoticed for extended periods, hindering incident response efforts and potentially exacerbating the damage.\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 S3 bucket deletion events in CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected \u003ccode\u003eDeleteBucket\u003c/code\u003e events to verify their legitimacy and ensure they were authorized by appropriate personnel.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts to prevent unauthorized access and reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eEnforce strict IAM policies and regularly review user permissions to minimize the blast radius of compromised accounts.\u003c/li\u003e\n\u003cli\u003eEnable versioning on S3 buckets to allow for the recovery of accidentally deleted objects, mitigating the impact of data loss.\u003c/li\u003e\n\u003cli\u003eImplement data backup and disaster recovery plans to ensure business continuity in the event of a successful bucket deletion attack.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T14:27:00Z","date_published":"2024-01-02T14:27:00Z","id":"/briefs/2024-01-aws-bucket-deletion/","summary":"An AWS S3 bucket deletion event was detected via CloudTrail logs, potentially indicating data loss or unauthorized access attempts.","title":"AWS S3 Bucket Deletion Detected via CloudTrail","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-bucket-deletion/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM"],"_cs_severities":["high"],"_cs_tags":["aws","cloud","iam","s3browser","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe threat involves the use of the S3 Browser utility, a Windows application, to interact with Amazon Web Services (AWS) Identity and Access Management (IAM). Attackers are leveraging S3 Browser to perform reconnaissance, specifically targeting IAM users that do not have a login profile configured. Upon identifying such users, the attacker proceeds to create a login profile for them. This tactic may be indicative of an attempt to gain unauthorized access or maintain persistence within the AWS environment. The activity is detectable via AWS CloudTrail logs and was first publicly reported in May 2023 in connection with the threat actor GUIVIL.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a system with AWS CLI tools installed or uses a compromised IAM user with sufficient permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker configures S3 Browser with valid AWS credentials, enabling interaction with the AWS environment.\u003c/li\u003e\n\u003cli\u003eS3 Browser initiates a \u003ccode\u003eGetLoginProfile\u003c/code\u003e API call in AWS CloudTrail, to enumerate IAM users and identify those without existing login profiles.\u003c/li\u003e\n\u003cli\u003eS3 Browser, upon finding an IAM user without a login profile, initiates a \u003ccode\u003eCreateLoginProfile\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe attacker sets a password for the newly created login profile, gaining console access to the targeted IAM user account.\u003c/li\u003e\n\u003cli\u003eThe attacker logs into the AWS console using the newly created credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the IAM user\u0026rsquo;s permissions to perform further reconnaissance, lateral movement, or data exfiltration within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by maintaining access through the created login profile, even if other access methods are revoked.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to gain unauthorized console access to previously unprotected IAM user accounts. This can lead to privilege escalation, data breaches, and disruption of cloud services. The lack of multi-factor authentication on newly created login profiles increases the risk of account compromise. The impact can range from reconnaissance to full-scale control of the AWS environment, depending on the permissions associated with the compromised IAM users.\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\u003eGetLoginProfile\u003c/code\u003e and \u003ccode\u003eCreateLoginProfile\u003c/code\u003e events originating from the S3 Browser user agent in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of IAM LoginProfile creation originating from unusual user agents or IP addresses.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users, including those with console access to mitigate the impact of compromised credentials.\u003c/li\u003e\n\u003cli\u003eReview IAM policies to ensure least privilege and restrict the ability to create or modify LoginProfiles to authorized personnel only.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-02-s3browser-iam-loginprofile/","summary":"The S3 Browser utility is being used to enumerate IAM users lacking login profiles and subsequently create them, potentially for reconnaissance, persistence, and privilege escalation within AWS environments.","title":"S3 Browser Used to Create IAM Login Profiles","url":"https://feed.craftedsignal.io/briefs/2024-01-02-s3browser-iam-loginprofile/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS GuardDuty"],"_cs_severities":["high"],"_cs_tags":["defense-impairment","aws"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAn adversary may attempt to impair an organization\u0026rsquo;s defenses by manipulating the IP sets within AWS GuardDuty. GuardDuty IP sets are used to whitelist trusted IPs or blacklist known malicious IPs. By modifying these lists, an attacker can effectively disable alerts for their malicious activity, allowing them to operate undetected within the AWS environment. This activity is typically performed after initial access and lateral movement, as the attacker seeks to maintain persistence and evade detection. The changes could be made via the AWS Management Console, CLI, or programmatically through the AWS API, making it difficult to immediately recognize the change as malicious.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the AWS environment through compromised credentials or an exposed IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing GuardDuty IP sets using the \u003ccode\u003eListIPSets\u003c/code\u003e API call to identify potential targets for modification.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new IP set using \u003ccode\u003eCreateIPSet\u003c/code\u003e API call, which contains malicious IPs they intend to whitelist, or the legitimate IPs of internal scanners they wish to mimic.\u003c/li\u003e\n\u003cli\u003eGuardDuty validates the uploaded IP set list.\u003c/li\u003e\n\u003cli\u003eThe attacker activates the newly created IP set within GuardDuty, making it the active trusted or threat list.\u003c/li\u003e\n\u003cli\u003eThe attacker conducts malicious activity, such as lateral movement, data exfiltration, or resource exploitation, from the whitelisted IPs.\u003c/li\u003e\n\u003cli\u003eGuardDuty, configured with the modified IP sets, does not generate alerts for activity originating from the whitelisted IPs.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence and achieves their objective (e.g., data theft, denial of service) without detection.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to significant data breaches, resource compromise, and prolonged unauthorized access. The modification of IP sets within GuardDuty directly impairs the ability of security teams to detect and respond to ongoing threats. By whitelisting malicious IPs, attackers can bypass security controls and operate freely within the AWS environment. The number of affected organizations depends on the scope of the compromised AWS accounts and the extent to which GuardDuty is relied upon for threat detection.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS GuardDuty IP Set Creation\u0026rdquo; to your SIEM to detect suspicious creation of IP sets in GuardDuty (logsource: aws, service: cloudtrail).\u003c/li\u003e\n\u003cli\u003eInvestigate any changes to GuardDuty configurations, particularly the creation or modification of IP sets, using CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts and IAM roles to prevent unauthorized access (related to initial access).\u003c/li\u003e\n\u003cli\u003eRegularly review and audit IAM roles and permissions to minimize the blast radius of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-aws-guardduty-ipset/","summary":"An attacker modifies AWS GuardDuty IP sets, potentially whitelisting malicious IPs to disable security alerts and impair defenses.","title":"AWS GuardDuty IP Set Manipulation for Defense Impairment","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-guardduty-ipset/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Config","AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["attack.defense-impairment","attack.t1562.008","aws"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting the disabling of AWS Config, a service that continuously monitors and records AWS resource configurations. An attacker might disable AWS Config to evade detection and prevent auditing of their malicious activities within the AWS environment. By deleting delivery channels or stopping the configuration recorder, an attacker can effectively blind the security team to changes made to AWS resources. This activity, if unauthorized, signifies a significant attempt to impair defenses. This brief provides detections based on AWS CloudTrail logs.\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 AWS account, potentially through compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing AWS Config resources to identify the delivery channel and configuration recorder.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eDeleteDeliveryChannel\u003c/code\u003e API call to stop the delivery of configuration changes to the designated S3 bucket or SNS topic.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eStopConfigurationRecorder\u003c/code\u003e API call to halt the recording of configuration changes for AWS resources.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions within the AWS environment without the activity being recorded by AWS Config.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to delete CloudTrail logs, if they have sufficient permissions, to further cover their tracks.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as deploying malicious infrastructure, exfiltrating data, or disrupting services, without immediate detection.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful disabling of AWS Config allows attackers to operate undetected within an AWS environment. This can lead to a delayed response to security incidents, resulting in more significant data breaches, financial losses, or reputational damage. The number of affected AWS accounts and the scope of the damage depend on the attacker\u0026rsquo;s objectives and the duration of the undetected activity.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS Config Disabling Channel/Recorder\u0026rdquo; to your SIEM and tune for your environment to detect unauthorized disabling of AWS Config resources.\u003c/li\u003e\n\u003cli\u003eReview AWS IAM policies to ensure that only authorized personnel have the necessary permissions to modify or disable AWS Config settings.\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\u003cli\u003eMonitor CloudTrail logs for any attempts to disable or modify AWS Config resources, referencing the \u003ccode\u003eeventSource\u003c/code\u003e and \u003ccode\u003eeventName\u003c/code\u003e fields in the provided Sigma rule.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-aws-config-disable/","summary":"Detection of AWS Config Service disabling, potentially indicating an attempt to impair defenses by stopping configuration recording and delivery.","title":"AWS Config Service Disabling Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-config-disable/"}],"language":"en","title":"CraftedSignal Threat Feed — Aws","version":"https://jsonfeed.org/version/1.1"}