{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/aws-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":["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","AWS EC2"],"_cs_severities":["low"],"_cs_tags":["attack.defense-impairment","attack.t1686.001","cloud"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe creation of new Network Access Control List (ACL) entries in Amazon Web Services (AWS) environments can be a sign of malicious activity. While legitimate use cases exist, adversaries can leverage these ACL changes to impair existing defenses, create new pathways for lateral movement, or establish persistence mechanisms. This activity is logged by CloudTrail and can be monitored to identify unauthorized or suspicious modifications to network security configurations. Attackers could create overly permissive rules that allow unauthorized access to critical resources or restrictive rules that disrupt legitimate traffic. Monitoring the creation of Network ACL entries is important for maintaining the integrity and security of AWS environments.\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 exploited vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the existing Network ACLs within the target Virtual Private Cloud (VPC).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the AWS Management Console, CLI, or API to create a new Network ACL entry. The \u003ccode\u003eCreateNetworkAclEntry\u003c/code\u003e event is logged in CloudTrail.\u003c/li\u003e\n\u003cli\u003eThe new ACL entry may be configured to allow specific inbound or outbound traffic that was previously blocked, effectively opening a new attack vector.\u003c/li\u003e\n\u003cli\u003eAlternatively, the new ACL entry may be configured to deny legitimate traffic, causing a denial-of-service condition for specific services or resources.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly created ACL entry to move laterally within the AWS environment, accessing previously inaccessible resources.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions, such as data exfiltration or resource compromise, using the newly opened network pathways.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe creation of unauthorized Network ACL entries can have significant consequences. It can lead to the opening of new attack vectors, allowing unauthorized access to sensitive data and critical resources. In some scenarios, it can result in a denial-of-service condition, disrupting legitimate business operations. Depending on the scope of the compromised resources and data, the impact can range from minor inconvenience to significant financial loss and reputational damage. Early detection of this activity is crucial to mitigating potential risks.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;New Network ACL Entry Added\u0026rdquo; to your SIEM to detect suspicious ACL modifications (logsource: aws, service: cloudtrail).\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eCreateNetworkAclEntry\u003c/code\u003e events that deviate from established baseline configurations or involve unexpected source/destination IP ranges.\u003c/li\u003e\n\u003cli\u003eReview and audit existing Network ACL configurations regularly to identify and remediate any overly permissive or restrictive rules.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise and unauthorized access.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for other related events, such as \u003ccode\u003eDeleteNetworkAclEntry\u003c/code\u003e or \u003ccode\u003eReplaceNetworkAclEntry\u003c/code\u003e, which may indicate further tampering with network security configurations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-10-26T14:27:00Z","date_published":"2024-10-26T14:27:00Z","id":"/briefs/2024-10-aws-network-acl-created/","summary":"Detection of new Network ACL entries in AWS CloudTrail logs can indicate potential defense impairment or the opening of new attack vectors within an AWS account by an adversary.","title":"New AWS Network ACL Entry Creation Detected","url":"https://feed.craftedsignal.io/briefs/2024-10-aws-network-acl-created/"},{"_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":["AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["defense-impairment","cloud"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. By recording API calls, CloudTrail provides a history of AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command line tools, and other AWS services. Attackers may attempt to disable or modify CloudTrail logging to remove traces of their malicious activity, hindering incident response and forensic investigations. This brief focuses on detecting actions that stop logging, update the trail configuration, or delete the trail altogether. These actions directly impact an organization\u0026rsquo;s ability to detect and respond to security incidents within their 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 with sufficient privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS environment using compromised credentials or an exploited IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eStopLogging\u003c/code\u003e API call against the CloudTrail service, effectively halting the recording of events.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker may execute the \u003ccode\u003eUpdateTrail\u003c/code\u003e API call to modify the CloudTrail configuration. This could involve changing the S3 bucket destination, disabling log file validation, or altering event selectors to exclude specific events.\u003c/li\u003e\n\u003cli\u003eAs another option, the attacker may execute the \u003ccode\u003eDeleteTrail\u003c/code\u003e API call, completely removing the CloudTrail configuration from the AWS account.\u003c/li\u003e\n\u003cli\u003eAfter disabling, modifying, or deleting the trail, the attacker proceeds with their malicious activities, knowing that their actions are less likely to be recorded and detected.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt to further obfuscate their activities by deleting or modifying any remaining log data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling or modifying CloudTrail logging can have severe consequences. It impairs an organization\u0026rsquo;s ability to detect and respond to security incidents in their AWS environment. Without proper logging, incident responders may struggle to determine the scope and impact of a breach, leading to delayed or ineffective remediation efforts. The inability to audit user activity can also hinder compliance efforts and potentially lead to regulatory penalties.\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\u003eStopLogging\u003c/code\u003e, \u003ccode\u003eUpdateTrail\u003c/code\u003e, and \u003ccode\u003eDeleteTrail\u003c/code\u003e events in CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges, to reduce the risk of unauthorized access.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for unexpected changes to IAM policies, which could grant excessive permissions to attackers.\u003c/li\u003e\n\u003cli\u003eEnable log file validation to ensure the integrity of CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eUse AWS Config to monitor CloudTrail configuration and alert on any deviations from the desired state.\u003c/li\u003e\n\u003cli\u003eReview AWS documentation on security best practices for AWS CloudTrail to ensure proper configuration and monitoring.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-aws-cloudtrail-disable-logging/","summary":"Detection of AWS CloudTrail being disabled, deleted, or updated by an adversary to impair defenses and evade detection.","title":"AWS CloudTrail Logging Disabled or Modified","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-cloudtrail-disable-logging/"},{"_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 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":["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":["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":["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 CloudTrail","version":"https://jsonfeed.org/version/1.1"}