CloudTrail — CraftedSignal Threat Feed

AWS Security Services Impairment via Deletion of Resources

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

This threat brief focuses on the detection of malicious attempts to impair or disable AWS security services through the deletion of critical resources. Attackers target services like GuardDuty, AWS WAF (classic and v2), CloudWatch, Route 53, and CloudWatch Logs to evade detection and remove visibility. The primary objective is to create blind spots within the AWS environment, allowing attackers to operate undetected. The activity is identified through specific API calls logged in CloudTrail, such as “DeleteLogStream” and “DeleteDetector.” This targeted approach significantly reduces the noise and ensures that only security-related deletions are flagged, enhancing the accuracy of the detection. Successful evasion can lead to privilege escalation or data exfiltration without triggering security alerts, severely compromising the AWS environment.

Attack Chain

Initial access to the AWS environment is achieved through compromised credentials or a misconfigured IAM role.
The attacker enumerates existing security services, including GuardDuty, AWS WAF, CloudWatch, Route 53, and CloudWatch Logs, to identify potential targets for impairment.
The attacker uses AWS CLI or API calls to attempt to delete GuardDuty detectors using DeleteDetector against guardduty.amazonaws.com.
The attacker attempts to delete WAF rules, IP sets, or rule groups using DeleteIPSet, DeleteWebACL, DeleteRuleGroup, or DeleteRule API calls targeting wafv2.amazonaws.com or waf.amazonaws.com.
The attacker attempts to delete CloudWatch logging configurations via the DeleteLoggingConfiguration API call from wafv2.amazonaws.com, waf.amazonaws.com, or route53.amazonaws.com.
The attacker might attempt to delete CloudWatch alarms using the DeleteAlarms event.
If successful, the attacker disables critical security monitoring and logging functions, creating blind spots for defenders.
The attacker leverages the compromised environment to escalate privileges, move laterally, exfiltrate data, or deploy persistent backdoors without triggering security alerts.

Impact

Successful execution of this attack can severely compromise the security posture of the AWS environment. By disabling security services like GuardDuty and CloudWatch, attackers can operate undetected, escalate privileges, and exfiltrate sensitive data without triggering security alerts. The scope of the impact depends on the attacker’s objectives, the sensitivity of the data, and the extent of the compromise.

Recommendation

Enable AWS CloudTrail logging across all regions in your AWS environment to capture API calls and events necessary for detection.
Deploy the Sigma rule AWS Defense Evasion via Security Service Deletion to your SIEM and tune for your environment using user_agent and user_arn fields.
Investigate any alerts generated by the Sigma rule, focusing on the user accounts involved and the specific resources being deleted.
Regularly review and validate the configurations of your AWS security services, including GuardDuty detectors, WAF rules, and CloudWatch alarms, to ensure they are properly configured and protected from unauthorized deletion.
Implement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges, to reduce the risk of credential compromise.

AWS CloudTrail Update for Defense Evasion

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

This detection focuses on identifying attempts to evade detection within AWS environments by monitoring UpdateTrail events in AWS CloudTrail logs. Attackers may modify CloudTrail settings with incorrect parameters, such as switching from multi-regional logging to single-region logging, to reduce the scope of logged activities. This tactic allows adversaries to operate undetected in compromised AWS environments, as their actions in other regions are not properly recorded. Detecting these configuration changes is critical for Security Operations Centers (SOCs) to maintain visibility and respond effectively to threats. The lack of comprehensive logging can significantly impede incident response and forensic investigations, allowing malicious activities to persist unnoticed.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or an exposed API key (T1078).
The attacker authenticates to the AWS Management Console or uses the AWS CLI with the compromised credentials.
The attacker issues an UpdateTrail API call to modify the CloudTrail configuration (T1562.008).
The attacker disables multi-region logging, restricting log collection to a single AWS region.
Alternatively, the attacker modifies the S3 bucket used for log storage, potentially directing logs to an attacker-controlled location.
The attacker performs malicious activities within the AWS environment, knowing that these actions will not be comprehensively logged across all regions.
These malicious activities could include lateral movement, data exfiltration, or resource compromise.
The reduced logging scope hinders detection and response efforts, allowing the attacker to maintain persistence and achieve their objectives.

Impact

Successful evasion of CloudTrail logging can lead to significant blind spots in security monitoring. If an attacker successfully modifies CloudTrail settings, their subsequent actions within the AWS environment are less likely to be detected. This can lead to prolonged dwell time, increased data exfiltration, and greater overall damage. Organizations relying on CloudTrail for compliance and security auditing may also face regulatory repercussions due to incomplete logging. The blast radius of a successful attack expands significantly when logging is impaired, affecting potentially all resources within the AWS environment.

Recommendation

Deploy the provided Sigma rule to your SIEM and tune it for your specific AWS environment to detect unauthorized CloudTrail modifications.
Investigate any UpdateTrail events where the actor.user.uid is not a known administrator account (see Sigma rule below).
Monitor CloudTrail logs for changes to multi-region logging settings and S3 bucket destinations (see references to api.operation=UpdateTrail in the search field).
Implement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges to mitigate credential compromise (T1110).
Regularly review and audit CloudTrail configurations to ensure they align with security best practices and organizational policies.

AWS CloudTrail Logging Stopped for Defense Evasion

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

This analytic detects StopLogging events within AWS CloudTrail logs, which is a critical action that adversaries may use to evade detection. By halting the logging of their malicious activities, attackers aim to operate undetected within a compromised AWS environment. This detection is achieved by monitoring for specific CloudTrail log entries that indicate the cessation of logging activities. Identifying such behavior is crucial for a Security Operations Center (SOC), as it signals an attempt to undermine the integrity of logging mechanisms, potentially allowing malicious activities to proceed without observation. The impact of this evasion tactic is significant, as it can severely hamper incident response and forensic investigations by obscuring the attacker’s actions. The detection is based on Amazon Security Lake events.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a vulnerability.
The attacker enumerates existing CloudTrail configurations to identify the target log trails.
The attacker attempts to disable logging by invoking the StopLogging API call on the CloudTrail service.
The AWS CloudTrail service receives the StopLogging API request.
If the attacker has sufficient privileges, the CloudTrail service processes the request, and logging is stopped for the specified trail.
The attacker performs malicious activities within the AWS environment without those actions being logged by CloudTrail.
The attacker attempts to delete or modify existing CloudTrail log files to further cover their tracks (not directly detected by this analytic, but a likely follow-on action).
The attacker achieves their objective, such as data exfiltration or resource compromise, without immediate detection due to the disabled logging.

Impact

Successful evasion of CloudTrail logging can severely impair incident response and forensic investigations. Without logs, identifying the scope and nature of the attack becomes significantly more challenging. Organizations may experience delayed breach detection, increased dwell time for attackers, and difficulty in recovering compromised resources. The impact can extend to compliance violations, as many regulatory frameworks require comprehensive audit logging. This is a high severity incident because it prevents security teams from understanding what an attacker did in the environment.

Recommendation

Deploy the Sigma rule Detect AWS CloudTrail StopLogging Event to your SIEM and tune for your environment to detect instances where CloudTrail logging is stopped.
Investigate any detected StopLogging events (as surfaced by the Sigma rule) to determine whether they are authorized administrative actions or potentially malicious.
Monitor for unusual API calls and activities originating from the source IP addresses and user accounts identified in the ASL AWS Defense Evasion Stop Logging Cloudtrail search results.
Review and enforce strict IAM policies to minimize the potential for unauthorized users to disable CloudTrail logging to prevent future attempts at defense evasion.
Ingest CloudTrail logs from Amazon Security Lake into Splunk, ensuring you are using the latest version of Splunk Add-on for Amazon Web Services to use the ASL AWS Defense Evasion Stop Logging Cloudtrail search.

AWS CloudTrail Logging Stopped for Defense Evasion

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

This alert focuses on detecting the StopLogging event within AWS CloudTrail, a critical indicator of potential defense evasion. Attackers often disable CloudTrail logging to conceal their malicious activities, making it difficult for security teams to detect and respond to breaches effectively. The detection specifically looks for successful StopLogging events (errorCode = success) originating from sources other than the AWS console (userAgent!=console.amazonaws.com). By identifying these instances, security teams can quickly investigate the reasons behind the logging stoppage, determine if it was authorized, and take appropriate action to prevent further unauthorized activities. This is especially critical for maintaining visibility and control over AWS environments, ensuring that malicious actions are not conducted without a trace.

Attack Chain

The attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a misconfiguration.
The attacker assumes a role or escalates privileges to gain sufficient permissions to manage CloudTrail.
The attacker identifies the active CloudTrail trails within the AWS environment.
The attacker executes the StopLogging API call against the identified CloudTrail trail.
CloudTrail logs the StopLogging event, recording the action, user, and source IP.
The attacker proceeds with malicious activities, such as data exfiltration, resource manipulation, or deploying backdoors, without being logged by CloudTrail.
The attacker attempts to remove or modify existing security controls and monitoring configurations.
The attacker persists in the environment, potentially creating new identities or backdoors to maintain access.

Impact

Successful disabling of CloudTrail logging can have severe consequences. It impairs incident response by removing the primary source of audit data. Without CloudTrail logs, security teams lose visibility into attacker activities, making it difficult to determine the scope and impact of the breach. Attackers can operate undetected, exfiltrate sensitive data, modify critical resources, and establish persistent backdoors. The impact can range from data breaches and financial losses to reputational damage and regulatory fines.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect instances of StopLogging events in AWS CloudTrail logs and tune for your environment.
Investigate any detected StopLogging events, focusing on the user (user), source IP (src), and reason for stopping logging.
Enable multi-factor authentication (MFA) for all AWS accounts to prevent credential compromise (TTP: TA0001).
Enforce the principle of least privilege to minimize the impact of compromised credentials (TTP: TA0004).
Regularly review and audit CloudTrail configurations to ensure logging is enabled and properly configured (TTP: TA0005).
Implement alerting for changes to CloudTrail configuration to detect unauthorized modifications (TTP: TA0005).

AWS Bedrock Model Invocation Logging Deletion Attempt

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

This analytic identifies attempts to delete AWS Bedrock model invocation logging configurations. The activity is detected by monitoring AWS CloudTrail logs for calls to the DeleteModelInvocationLogging API. Successful deletion of these logs could allow attackers to interact with AI models hosted on AWS Bedrock without leaving forensic traces. This may be indicative of an adversary who has compromised AWS credentials and is attempting to evade detection of their malicious actions. The impact could range from data exfiltration and prompt injection attacks to other unauthorized activities, all performed without generating audit records. This event should be considered a high-priority alert, as it directly impacts the ability to monitor and respond to potentially malicious use of AI models within the AWS environment. The detection leverages AWS CloudTrail logs and is based on the Splunk ES-CU analytic “AWS Bedrock Delete Model Invocation Logging Configuration”.

Attack Chain

An attacker gains unauthorized access to an AWS account, potentially through credential compromise or other means.
The attacker enumerates the existing AWS Bedrock model invocation logging configurations within the targeted AWS account.
The attacker executes the DeleteModelInvocationLoggingConfiguration API call to disable or remove the logging configuration.
AWS CloudTrail logs the DeleteModelInvocationLoggingConfiguration event, capturing details such as the user, source IP, and timestamp.
The attacker proceeds to interact with AWS Bedrock models, potentially performing data exfiltration or prompt injection attacks.
Because model invocation logging has been disabled, these interactions are not logged, hindering detection and incident response efforts.
The attacker attempts to further cover their tracks by deleting or modifying other relevant CloudTrail logs.

Impact

A successful attack could lead to unauthorized access and manipulation of AI models hosted on AWS Bedrock. The deletion of model invocation logs allows attackers to hide their activities, making it difficult to detect and respond to incidents such as data exfiltration or prompt injection attacks. This can result in significant financial loss, reputational damage, and legal liabilities. The exact number of victims and the extent of the damage depend on the scope and duration of the attacker’s access to the AI models.

Recommendation

Deploy the Sigma rule Detect AWS Bedrock Logging Deletion to your SIEM to detect attempts to delete AWS Bedrock model invocation logging configurations.
Investigate any detected instances of DeleteModelInvocationLoggingConfiguration events, focusing on unexpected users or source IPs, to validate legitimate administrative actions.
Enable AWS CloudTrail logging for all AWS regions and services, including Bedrock, to ensure comprehensive audit coverage.
Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise (T1685.002).
Monitor CloudTrail logs for unusual API calls and access patterns to identify potential insider threats or compromised accounts.
Review and update IAM policies to enforce the principle of least privilege and restrict access to sensitive API actions, such as DeleteModelInvocationLoggingConfiguration.

AWS S3 Bucket Lifecycle Rule Abuse for Log Deletion

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

Attackers may attempt to evade detection by manipulating AWS S3 bucket lifecycle rules to accelerate the deletion of CloudTrail logs. By using the PutBucketLifecycle API to set a short expiration period (less than three days) on an S3 bucket containing CloudTrail logs, adversaries can effectively erase their activity history. This technique is particularly relevant as it directly impacts the ability of security teams to conduct thorough investigations and respond effectively to breaches. The tactic aims to impair forensic investigations by eliminating critical log data, thereby obscuring attacker actions.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a misconfigured IAM role.
The attacker identifies the S3 bucket(s) used to store CloudTrail logs.
The attacker uses the AWS CLI or API to call the PutBucketLifecycle API, configuring a new lifecycle rule.
The lifecycle rule is configured with an Expiration parameter, setting the Days value to a low number (e.g., 1 or 2 days).
The attacker executes malicious activities within the AWS environment, knowing the logs will be quickly deleted.
The S3 lifecycle policy automatically deletes the CloudTrail logs after the specified short expiration period.
Security analysts attempting to investigate the attacker’s activities find that the relevant CloudTrail logs are missing or incomplete, hindering their investigation.

Impact

Successful manipulation of S3 bucket lifecycle rules can severely impede incident response efforts. By rapidly deleting CloudTrail logs, attackers can cover their tracks, making it difficult to trace their actions and understand the scope of the breach. This can lead to prolonged dwell time, increased data exfiltration, and greater overall damage. The impact is significant because it directly targets the visibility security teams rely on for threat detection and response.

Recommendation

Deploy the Sigma rule AWS S3 Bucket Lifecycle with Short Expiration to detect suspicious PutBucketLifecycle API calls with expiration periods under three days.
Enable CloudTrail logging on all AWS accounts and ensure logs are stored in secure S3 buckets, as required for the detection rules to function.
Review and audit existing S3 bucket lifecycle policies to identify any rules with unusually short expiration periods.
Implement multi-factor authentication (MFA) for all IAM users and roles to prevent unauthorized access and manipulation of S3 bucket lifecycle rules.
Use AWS IAM policies to restrict the ability of users and roles to modify S3 bucket lifecycle configurations, limiting the potential for abuse.

AWS Network ACL Created with All Ports Open

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

This detection focuses on identifying misconfigured AWS Network ACLs (NACLs) that permit unrestricted traffic. AWS NACLs act as a firewall for controlling traffic in and out of subnets within a Virtual Private Cloud (VPC). When an NACL is configured to allow all ports and protocols from any IP address (0.0.0.0/0), it effectively bypasses security controls and exposes resources to potential threats. The activity is detected by monitoring AWS CloudTrail events for CreateNetworkAclEntry or ReplaceNetworkAclEntry API calls. This configuration error can be introduced by administrators during initial setup or through misconfiguration during updates. Defenders should ensure that NACLs follow the principle of least privilege to limit the attack surface.

Attack Chain

An attacker identifies a target AWS environment.
The attacker scans for publicly accessible services or resources.
An administrator, either maliciously or accidentally, creates or modifies a Network ACL using the AWS Management Console, CLI, or API with overly permissive rules (allowing all traffic: ruleAction=allow AND egress=false AND aclProtocol=-1 AND cidrBlock=0.0.0.0/0).
The misconfigured NACL is applied to one or more subnets within the VPC.
The attacker exploits the open ports and protocols to gain unauthorized access.
The attacker attempts to move laterally within the AWS environment.
The attacker exfiltrates sensitive data or disrupts services.

Impact

A misconfigured Network ACL that allows all traffic can have severe consequences. It can lead to unauthorized access to sensitive data, potential data breaches, service disruption, and further compromise of the AWS environment. The impact is particularly high if critical resources are located within the affected subnets. This type of misconfiguration violates security best practices and compliance requirements.

Recommendation

Deploy the Sigma rule AWS Network ACL Created with All Ports Open to your SIEM to detect this specific misconfiguration (logsource: ASL AWS CloudTrail, category: network_connection).
Review existing Network ACL configurations to identify and remediate any overly permissive rules (check AWS console or use AWS CLI/API).
Implement automated checks to validate Network ACL configurations against security best practices.
Ensure that NACLs follow the principle of least privilege by only allowing necessary traffic (review NACL ruleAction, egress, aclProtocol, and cidrBlock settings in CloudTrail logs).
Investigate any identified instances of overly permissive NACL configurations to determine the root cause and potential impact (analyze CloudTrail logs for CreateNetworkAclEntry or ReplaceNetworkAclEntry events).

AWS S3 Bucket Lifecycle Rule for Rapid Log Deletion

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

This threat involves the modification of AWS S3 bucket lifecycle policies to expedite the deletion of CloudTrail logs. The technique focuses on configuring a lifecycle rule for an S3 bucket with an expiration period of fewer than three days. By shortening the retention period, attackers aim to quickly eliminate CloudTrail logs, thereby covering their tracks and impeding forensic investigations. This activity is significant because it directly targets security logging, a critical component for threat detection and incident response. This technique can be used by various threat actors seeking to evade detection within AWS environments.

Attack Chain

The attacker gains unauthorized access to an AWS account, potentially through compromised credentials or a vulnerability.
The attacker identifies the S3 bucket used to store CloudTrail logs.
The attacker uses AWS CLI or the AWS Management Console to execute the PutBucketLifecycle API call.
The PutBucketLifecycle call modifies the lifecycle configuration of the S3 bucket.
The new lifecycle rule specifies a short expiration period (less than three days) for objects in the bucket.
CloudTrail logs within the S3 bucket are automatically deleted after the specified expiration period.
The attacker’s actions are no longer recorded in CloudTrail, hindering incident response.

Impact

Successful execution of this attack leads to the rapid and irreversible deletion of CloudTrail logs. This can severely hamper incident response efforts, making it difficult to trace attacker actions, identify the scope of a breach, and conduct thorough forensic analysis. Organizations may be unable to meet compliance requirements related to data retention and audit logging.

Recommendation

Deploy the provided Sigma rule to detect suspicious PutBucketLifecycle events with short expiration periods in your SIEM.
Investigate any detected PutBucketLifecycle events modifying S3 bucket lifecycle policies (logsource: ASL AWS CloudTrail).
Monitor AWS CloudTrail logs for unusual API calls related to S3 bucket lifecycle management (logsource: ASL AWS CloudTrail).

AWS Bedrock GuardRails Deletion Attempt

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

This analytic focuses on detecting the deletion of AWS Bedrock GuardRails. AWS Bedrock is a fully managed service that offers a choice of high-performing foundation models (FMs) from leading AI companies. GuardRails within Bedrock are security controls designed to prevent harmful, biased, or inappropriate AI outputs. The deletion of these guardrails, detected through AWS CloudTrail logs, could indicate a malicious actor attempting to bypass security measures after compromising credentials. This could potentially enable harmful or malicious model outputs, leading to the generation of offensive content, extraction of sensitive information, or circumvention of prompt injection defenses. This activity matters to defenders as it highlights a potential attempt to manipulate AI model behavior for malicious purposes, requiring immediate investigation.

Attack Chain

An attacker gains unauthorized access to an AWS account with sufficient privileges to manage Bedrock resources, possibly through credential compromise.
The attacker authenticates to the AWS environment, establishing a session.
The attacker identifies existing AWS Bedrock GuardRails configurations using AWS APIs or the AWS Management Console.
The attacker uses the DeleteGuardrail API call via the AWS CLI, SDK, or Management Console, specifying the guardrailIdentifier of the targeted GuardRail.
AWS CloudTrail logs the DeleteGuardrail event, including details such as the user identity, source IP address, and GuardRail identifier.
The GuardRail is successfully deleted, removing the configured safety controls for the Bedrock models.
The attacker leverages the now-unprotected Bedrock models to generate harmful content, extract sensitive information, or bypass other security controls.
The attacker exfiltrates sensitive data generated from the unprotected model to an external location.

Impact

Successful deletion of Bedrock GuardRails could allow attackers to manipulate AI models for malicious purposes. This could lead to the generation of offensive or harmful content, extraction of sensitive information, or bypassing prompt injection defenses. Organizations utilizing AWS Bedrock may experience reputational damage, data breaches, and regulatory compliance issues. While specific victim numbers are unavailable, the impact could be significant depending on the sensitivity of the data processed by the models.

Recommendation

Enable AWS CloudTrail logging for all AWS regions, specifically capturing Bedrock service events to ensure the DeleteGuardrail API calls are logged (data_source).
Deploy the provided Sigma rule Detect AWS Bedrock GuardRails Deletion to your SIEM and tune for your environment to detect unauthorized GuardRail deletions.
Investigate any detected DeleteGuardrail events to determine the legitimacy of the action and identify potential credential compromise or malicious intent (Sigma rule).
Implement an allowlist for expected administrators who regularly manage GuardRails configurations to reduce false positives (known_false_positives).
Monitor the src IP addresses from which DeleteGuardrail API calls are made to identify potentially suspicious or unauthorized access points (rule and RBA).
Enforce multi-factor authentication (MFA) for all AWS accounts, especially those with privileges to manage Bedrock resources, to mitigate credential compromise (overview).