AWS CloudTrail — CraftedSignal Threat Feed

Rapid Enumeration of AWS S3 Buckets

hello@craftedsignal.io — Fri, 01 May 2026 19:43:38 +0000

This 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 aws.cloudtrail.resources.arn values within a 10-second window.

Attack Chain

An attacker gains initial access to an AWS environment using compromised credentials or through an exposed IAM role. (T1530)
The attacker authenticates to AWS using the obtained credentials, creating a programmatic session.
The attacker issues a series of GetBucketAcl, GetBucketPublicAccessBlock, GetBucketPolicy, GetBucketPolicyStatus, and GetBucketVersioning API calls to S3.
These API calls are directed towards multiple distinct S3 buckets within a short timeframe (10 seconds).
The attacker collects information about the bucket’s access control lists (ACLs), public access blocks, policies, versioning status, and other metadata. (T1526, T1580, T1619)
The collected information is analyzed to identify publicly accessible buckets, misconfigurations, or sensitive data storage locations.
The attacker uses identified vulnerabilities to exfiltrate data.
The attacker attempts lateral movement within the AWS environment, leveraging the discovered information to compromise other resources.

Impact

Successful 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.

Recommendation

Deploy 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.
Investigate any alerts generated by the Sigma rule, focusing on the source IP address (source.ip), AWS principal ARN (aws.cloudtrail.user_identity.arn), and the list of accessed buckets (aws.cloudtrail.resources.arn).
Review IAM policies associated with the identified principal to ensure least privilege for S3 read APIs.
Monitor CloudTrail logs for related events, such as ListBuckets, GetObject, PutBucketPolicy, AssumeRole, or IAM changes, occurring within ±30 minutes of the detected enumeration activity.
Implement network-level restrictions on the source IP address if it is not authorized to perform S3 enumeration.
Document approved scanning accounts and add user agent filters to the provided Sigma rule to reduce noise from those identities.

Detect AWS Route Table Modification via CloudTrail

hello@craftedsignal.io — Fri, 01 Nov 2024 12:00:00 +0000

The 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.

Attack Chain

An attacker gains unauthorized access to an AWS account, potentially through compromised credentials or an exploited vulnerability.
The attacker uses the AWS CLI or the AWS Management Console to interact with the EC2 service.
The attacker identifies the target route table to modify.
The attacker executes the CreateRoute API call, specifying the destination CIDR block and target (e.g., an internet gateway, virtual private gateway, or network interface).
CloudTrail logs the CreateRoute event, capturing details of the action, including the user identity, source IP address, and the route table modification.
Network traffic matching the new route’s destination CIDR block is now redirected to the attacker-controlled target.
The attacker monitors and potentially modifies the redirected traffic for reconnaissance or data exfiltration purposes.

Impact

Successful 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’s objectives.

Recommendation

Deploy the “Detect AWS Route Table Modification via CloudTrail” Sigma rule to your SIEM and tune for your environment to detect suspicious route creation events in AWS CloudTrail logs.
Investigate any CreateRoute events where the user identity is unexpected or the destination CIDR block and target are suspicious.
Monitor AWS CloudTrail logs for CreateRoute events and correlate them with other suspicious activities.
Implement strict IAM policies to limit who can modify route tables (reference the eventSource and eventName fields in the rule below).

New AWS Network ACL Entry Creation Detected

hello@craftedsignal.io — Sat, 26 Oct 2024 14:27:00 +0000

The 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.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or an exploited vulnerability.
The attacker identifies the existing Network ACLs within the target Virtual Private Cloud (VPC).
The attacker uses the AWS Management Console, CLI, or API to create a new Network ACL entry. The CreateNetworkAclEntry event is logged in CloudTrail.
The new ACL entry may be configured to allow specific inbound or outbound traffic that was previously blocked, effectively opening a new attack vector.
Alternatively, the new ACL entry may be configured to deny legitimate traffic, causing a denial-of-service condition for specific services or resources.
The attacker leverages the newly created ACL entry to move laterally within the AWS environment, accessing previously inaccessible resources.
The attacker performs malicious actions, such as data exfiltration or resource compromise, using the newly opened network pathways.

Impact

The 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.

Recommendation

Deploy the Sigma rule “New Network ACL Entry Added” to your SIEM to detect suspicious ACL modifications (logsource: aws, service: cloudtrail).
Investigate any CreateNetworkAclEntry events that deviate from established baseline configurations or involve unexpected source/destination IP ranges.
Review and audit existing Network ACL configurations regularly to identify and remediate any overly permissive or restrictive rules.
Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise and unauthorized access.
Monitor CloudTrail logs for other related events, such as DeleteNetworkAclEntry or ReplaceNetworkAclEntry, which may indicate further tampering with network security configurations.

Potential Abuse of AWS Console GetSigninToken

hello@craftedsignal.io — Mon, 29 Apr 2024 12:00:00 +0000

The 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 aws_consoler, 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 aws_consoler is specifically designed to automate this process, creating a streamlined path for malicious actors to leverage compromised credentials for further exploitation.

Attack Chain

An attacker gains initial access to AWS environment using compromised credentials (access key, secret key).
The attacker uses the compromised credentials with the AWS CLI or SDK to call the GetSigninToken API.
AWS CloudTrail logs the GetSigninToken event with the event source signin.amazonaws.com and event name GetSigninToken.
The GetSigninToken API returns a temporary sign-in token.
The attacker uses the temporary token along with the AWS account ID to construct a sign-in URL.
The attacker accesses the AWS Management Console via the crafted URL, bypassing MFA if the original compromised credentials required it.
Once in the console, the attacker performs reconnaissance, identifies valuable resources, and escalates privileges as needed.
The attacker moves laterally within the AWS environment, accessing and potentially exfiltrating sensitive data, or disrupting services.

Impact

Successful abuse of the GetSigninToken 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.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect suspicious GetSigninToken events in AWS CloudTrail logs.
Investigate any GetSigninToken events originating from outside of expected AWS SSO user agents or other known legitimate sources.
Monitor AWS CloudTrail logs for GetSigninToken events where the requesting user identity does not match expected patterns.
Implement and enforce MFA for all AWS IAM users, even though this attack bypasses it for console access using the temporary tokens.
Review and restrict IAM policies to adhere to the principle of least privilege, minimizing the potential impact of compromised credentials.

AWS CloudTrail Logging Disabled or Modified

hello@craftedsignal.io — Tue, 23 Jan 2024 12:00:00 +0000

AWS 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’s ability to detect and respond to security incidents within their AWS environment.

Attack Chain

An attacker gains unauthorized access to an AWS account with sufficient privileges.
The attacker authenticates to the AWS environment using compromised credentials or an exploited IAM role.
The attacker executes the StopLogging API call against the CloudTrail service, effectively halting the recording of events.
Alternatively, the attacker may execute the UpdateTrail 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.
As another option, the attacker may execute the DeleteTrail API call, completely removing the CloudTrail configuration from the AWS account.
After 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.
The attacker may then attempt to further obfuscate their activities by deleting or modifying any remaining log data.

Impact

Disabling or modifying CloudTrail logging can have severe consequences. It impairs an organization’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.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect StopLogging, UpdateTrail, and DeleteTrail events in CloudTrail logs.
Implement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges, to reduce the risk of unauthorized access.
Monitor AWS CloudTrail logs for unexpected changes to IAM policies, which could grant excessive permissions to attackers.
Enable log file validation to ensure the integrity of CloudTrail logs.
Use AWS Config to monitor CloudTrail configuration and alert on any deviations from the desired state.
Review AWS documentation on security best practices for AWS CloudTrail to ensure proper configuration and monitoring.

AWS Lateral Movement from Kubernetes Service Account via AssumeRoleWithWebIdentity

hello@craftedsignal.io — Wed, 03 Jan 2024 15:00:00 +0000

This detection rule identifies lateral movement in AWS environments stemming from Kubernetes service accounts utilizing AssumeRoleWithWebIdentity. 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.

Attack Chain

A Kubernetes service account projects a token.
The service account uses AssumeRoleWithWebIdentity to exchange the token for short-lived IAM credentials.
The attacker leverages the assumed role to perform reconnaissance activities such as ListUsers, ListRoles, and DescribeInstances.
The attacker attempts to access secrets using actions like GetSecretValue and ListSecrets.
The attacker escalates privileges by modifying IAM policies with actions like AttachRolePolicy and PutRolePolicy.
The attacker attempts to create new users or roles within the AWS environment using actions like CreateUser and CreateRole.
The attacker performs lateral movement using actions like SendCommand and StartSession.
The attacker attempts to evade detection by stopping logging with the StopLogging action.

Impact

Successful 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.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect potentially malicious activity related to AssumeRoleWithWebIdentity and tune for your environment.
Review and harden IAM role trust policies associated with Kubernetes service accounts, specifically focusing on OIDC trust conditions, as referenced in the IAM OIDC identity provider documentation.
Implement strict least privilege principles for Kubernetes service accounts, limiting their access to only the necessary AWS resources, as covered in EKS IAM roles for service accounts.
Monitor CloudTrail logs for AssumeRoleWithWebIdentity events followed by suspicious API calls, focusing on the actions listed in the Sigma rule detection patterns.

Suspicious AWS STS GetSessionToken Usage

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The 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’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.

Attack Chain

An attacker gains initial access to an AWS environment, potentially through compromised IAM user credentials.
The attacker authenticates to AWS using the compromised IAM user credentials.
The attacker calls the STS GetSessionToken API, specifying desired permissions or roles (if permitted by the IAM user’s policies).
AWS STS generates a new set of temporary credentials (access key ID, secret access key, and session token).
The attacker configures their AWS CLI or SDK to use the newly acquired temporary credentials.
The attacker leverages these temporary credentials to perform actions within the AWS environment, potentially escalating privileges or moving laterally.
The attacker covers their tracks by deleting the CloudTrail logs.
The attacker exfiltrates sensitive data, deploys malware, or causes disruption within the AWS environment using the acquired privileges.

Impact

Compromised 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.

Recommendation

Deploy the Sigma rule “AWS STS GetSessionToken Misuse” to your SIEM to detect suspicious GetSessionToken API calls (see rules section).
Investigate GetSessionToken calls where userIdentity.type is IAMUser to determine if the request is legitimate.
Monitor CloudTrail logs for unusual patterns of GetSessionToken usage, particularly from unfamiliar user agents or hosts.
Implement strong IAM policies and MFA to minimize the risk of compromised IAM user credentials.
Review the false positives section of the Sigma rule to tune the rule for your specific environment.

AWS EC2 Instance Profile Associated with Running Instance

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This 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 (ec2:AssociateIamInstanceProfile or ec2:ReplaceIamInstanceProfile and typically iam:PassRole) 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.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or a vulnerable application.
The attacker identifies a running EC2 instance with limited privileges.
The attacker identifies or creates a more privileged IAM role that grants broader access to AWS resources.
The attacker uses the AssociateIamInstanceProfile or ReplaceIamInstanceProfile API calls to associate the privileged IAM role with the target EC2 instance. This requires appropriate IAM permissions.
The EC2 instance’s metadata service now provides credentials for the newly associated IAM role.
The attacker leverages the elevated privileges to access sensitive data or resources, potentially including other EC2 instances, databases, or storage buckets.
The attacker moves laterally within the AWS environment, compromising additional resources and escalating their access.
The attacker achieves their objective, such as exfiltrating data, deploying malicious code, or disrupting services.

Impact

Successful 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.

Recommendation

Deploy the Sigma rule “AWS EC2 Instance Profile Associated with Running Instance” to your SIEM using AWS CloudTrail logs to detect suspicious activity.
Review and harden IAM permissions related to ec2:AssociateIamInstanceProfile and ec2:ReplaceIamInstanceProfile to limit who can modify instance profiles.
Enable CloudTrail logging for all regions in your AWS account to ensure comprehensive audit coverage.
Implement least privilege principles for IAM roles assigned to EC2 instances to minimize the impact of potential privilege escalation.
Investigate any alerts generated by the Sigma rule, focusing on the source IP address, user identity, and the IAM role associated with the instance profile.

AWS Root Account Usage Detected

hello@craftedsignal.io — Tue, 02 Jan 2024 14:30:00 +0000

The 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.

Attack Chain

An attacker gains access to the AWS root account credentials through credential theft or other means.
The attacker authenticates to the AWS Management Console or uses the AWS CLI with the root account credentials.
The attacker enumerates AWS resources to identify potential targets for privilege escalation.
The attacker creates or modifies IAM policies to grant themselves additional permissions.
The attacker may create new IAM users or roles with elevated privileges.
The attacker uses the elevated privileges to access sensitive data stored in S3 buckets or other AWS services.
The attacker modifies security configurations, such as network access control lists or security groups, to facilitate lateral movement or data exfiltration.
The attacker could disable logging features to cover tracks.

Impact

Compromise 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.

Recommendation

Deploy the Sigma rule “AWS Root Credentials” to your SIEM to detect root account usage based on CloudTrail logs.
Investigate all instances of root account usage identified by the “AWS Root Credentials” Sigma rule to determine legitimacy.
Enforce multi-factor authentication (MFA) on all AWS accounts, including the root account, as documented in AWS documentation.
Implement the principle of least privilege by granting IAM users and roles only the permissions they need to perform their tasks.
Regularly audit IAM policies and user permissions to identify and remove unnecessary privileges.
Disable or restrict root account access wherever possible, delegating tasks to IAM users/roles.

AWS Config Service Disabling Detection

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This 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.

Attack Chain

An attacker gains unauthorized access to an AWS account, potentially through compromised credentials or exploiting a vulnerability.
The attacker enumerates existing AWS Config resources to identify the delivery channel and configuration recorder.
The attacker executes the DeleteDeliveryChannel API call to stop the delivery of configuration changes to the designated S3 bucket or SNS topic.
The attacker executes the StopConfigurationRecorder API call to halt the recording of configuration changes for AWS resources.
The attacker performs malicious actions within the AWS environment without the activity being recorded by AWS Config.
The attacker may attempt to delete CloudTrail logs, if they have sufficient permissions, to further cover their tracks.
The attacker achieves their objective, such as deploying malicious infrastructure, exfiltrating data, or disrupting services, without immediate detection.

Impact

Successful 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’s objectives and the duration of the undetected activity.

Recommendation

Deploy the Sigma rule “AWS Config Disabling Channel/Recorder” to your SIEM and tune for your environment to detect unauthorized disabling of AWS Config resources.
Review AWS IAM policies to ensure that only authorized personnel have the necessary permissions to modify or disable AWS Config settings.
Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise.
Monitor CloudTrail logs for any attempts to disable or modify AWS Config resources, referencing the eventSource and eventName fields in the provided Sigma rule.