{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/cloudtrail/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_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":["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":[],"_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":["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":["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/"}],"language":"en","title":"CraftedSignal Threat Feed — Cloudtrail","version":"https://jsonfeed.org/version/1.1"}