[Rule Tuning] AWS SQS Queue Purge

This rule is triggering as expected with moderate telemetry volume (high spikes for what looks like expected cleanup jobs) in specific cluster. No changes needed to the rule query.

- updated description, FP and IG
- reduced execution window
- updated highlighted fields

Author: imays11

rules/integrations/aws/defense_evasion_sqs_purge_queue.toml

@@ -2,19 +2,23 @@
 creation_date = "2025/01/08"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/12/12"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies when an AWS Simple Queue Service (SQS) queue is purged. Adversaries may purge SQS queues to disrupt
-operations, delete messages, or impair monitoring and alerting mechanisms. This action can be used to evade detection
-and cover tracks by removing evidence of malicious activities.
+Identifies when an AWS Simple Queue Service (SQS) queue is purged. Purging an SQS queue permanently deletes all messages
+currently in the queue. Adversaries may use this action to disrupt application workflows, destroy operational data, or
+impair monitoring and alerting by removing messages that contain evidence of malicious activity.
 """
 false_positives = [
-    "Administrators may purge SQS queues for legitimate reasons, such as removing outdated or sensitive data.",
+    """
+    Authorized administrators or automated workflows may purge SQS queues for legitimate operational reasons, such as
+    clearing stale messages, resetting test environments, or performing approved maintenance. Verify that the action
+    aligns with documented procedures and expected operational behavior.
+    """,
 ]
-from = "now-9m"
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
@@ -26,82 +30,47 @@ note = """## Triage and analysis
 
 ### Investigating AWS SQS Queue Purge
 
-AWS Simple Queue Service (SQS) is a managed message queuing service that enables decoupling and scaling of microservices, distributed systems, and serverless applications. Adversaries may exploit SQS by purging queues to erase messages, disrupt operations, or hinder monitoring. The detection rule identifies successful purge actions in AWS CloudTrail logs, signaling potential defense evasion attempts by adversaries.
+AWS SQS is a managed message queuing service commonly used to decouple services and buffer events across distributed and serverless architectures. Purging a queue removes all pending messages and cannot be undone. While this may be required for maintenance or testing, adversaries may abuse this action to disrupt operations, delete forensic evidence, or evade detection by removing queued security or audit events.
 
 ### Possible investigation steps
 
-- Review the AWS CloudTrail logs for the specific event.provider "sqs.amazonaws.com" and event.action "PurgeQueue" to identify the time and source of the purge action.
-- Identify the IAM user or role associated with the purge action by examining the user identity information in the CloudTrail logs to determine if the action was authorized or potentially malicious.
-- Check the event.outcome "success" to confirm that the purge action was completed successfully and assess the impact on the queue's message data.
-- Investigate the context around the purge event by reviewing preceding and subsequent CloudTrail logs to identify any related or suspicious activities, such as unauthorized access attempts or changes to IAM policies.
-- Assess the potential impact on operations and monitoring by determining which messages were purged and if they contained critical or sensitive information.
-- Evaluate the necessity of implementing additional security measures, such as stricter IAM policies or enhanced logging and alerting, to prevent unauthorized queue purges in the future.
+**Identify the actor**
+- Review `aws.cloudtrail.user_identity.arn` and `access_key_id` to determine who initiated the purge. Confirm whether this identity typically manages SQS resources and whether the action aligns with their role.
 
-### False positive analysis
-
-- Routine maintenance activities by administrators may trigger the purge action. To handle this, identify and whitelist known maintenance operations or specific IAM roles used by trusted personnel.
-- Automated scripts or applications that regularly purge queues as part of their normal operation can cause false positives. Review and document these processes, then create exceptions for these specific actions in your monitoring system.
-- Testing environments where queues are frequently purged for development purposes can lead to alerts. Exclude these environments from the rule by filtering based on environment tags or specific queue names.
-- Scheduled tasks that include queue purging as a cleanup mechanism might be misinterpreted as malicious. Ensure these tasks are logged and approved, and adjust the detection rule to ignore these scheduled events.
-- Third-party integrations that manage SQS queues and perform purges as part of their functionality should be assessed. Verify the legitimacy of these integrations and exclude their actions from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected AWS SQS queue to prevent further unauthorized purging or access. This can be done by modifying the queue's access policies to restrict permissions temporarily.
-- Review AWS CloudTrail logs to identify the source of the purge action, including the IAM user or role responsible, and assess whether the action was authorized or part of a larger malicious activity.
-- Revoke or adjust permissions for the identified IAM user or role to prevent further unauthorized actions. Ensure that only necessary permissions are granted following the principle of least privilege.
-- Restore any critical messages or data that were purged, if possible, from backups or other data recovery solutions to minimize operational disruption.
-- Notify the security team and relevant stakeholders about the incident, providing details of the purge action and any identified malicious activity, to ensure coordinated response efforts.
-- Conduct a thorough review of IAM policies and access controls related to SQS to identify and remediate any potential security gaps that could be exploited in the future.
-- Enhance monitoring and alerting mechanisms for AWS SQS by implementing additional logging and anomaly detection to quickly identify and respond to similar threats in the future.
-
-## Triage and Analysis
-
-### Investigating AWS SQS Queue Purge
-
-This rule detects when an AWS SQS queue is purged, an action that adversaries may use to disrupt operations, delete messages, or impair monitoring and alerting mechanisms. Purging an SQS queue removes all messages, which could be used as a tactic to evade detection by deleting evidence of malicious activity or to disrupt legitimate workflows.
-
-#### Possible Investigation Steps
-
-- **Identify the Actor and Resource**:
-  - **User Identity and Permissions**: Review the field `aws.cloudtrail.user_identity.arn` to identify the IAM user or role responsible for the purge. Validate their permissions and determine if this action aligns with their typical responsibilities.
-  - **SQS Queue Details**: Examine `aws.cloudtrail.resources.arn` and `aws.cloudtrail.flattened.request_parameters.queueUrl` to identify the specific SQS queue that was purged. Check its purpose, associated workflows, and whether it handles sensitive or critical messages.
-
-- **Evaluate the Context and Purpose of the Purge**:
-  - **Time and Frequency**: Check the timestamp (`@timestamp`) to determine when the purge occurred and whether similar events have occurred recently. Frequent or repeated purges may indicate a larger issue or ongoing malicious activity.
-  - **Legitimacy of the Action**: Consult with the owner or administrator of the affected queue to verify if the purge was intentional or authorized.
+**Review the affected queue**
+- Identify the purged queue using `aws.cloudtrail.request_parameters` or `aws.cloudtrail.resources.arn`. Determine the purpose of the queue and whether it supports critical workflows, security tooling, or monitoring pipelines.
 
-- **Analyze for Potential Indicators of Malicious Activity**:
-  - **Source IP and Geographic Location**: Review `source.ip` and `source.geo` to identify the origin of the request. Anomalies, such as unexpected locations, may indicate compromise.
-  - **User Agent and Tooling**: Check `user_agent.original` to confirm the tool used to perform the purge. The use of unexpected or automated tooling may raise suspicion.
+**Evaluate the context of the action**
+- Review the `@timestamp` to determine when the purge occurred and whether it aligns with maintenance windows or
+  deployment activity.
+- Examine `source.ip` and `user_agent.original` for anomalies such as unexpected locations, automation tools, or
+  unfamiliar clients.
 
-- **Cross-Reference Related Activity**:
-  - **Recent IAM Events**: Search for related IAM or security-related events tied to the same actor, such as `CreateAccessKey`, `AssumeRole`, or `UpdateRolePolicy`, which could indicate privilege escalation or preparation for malicious actions.
-  - **Other SQS Activity**: Look for additional activity involving the same SQS queue, such as `SendMessage`, `ReceiveMessage`, or `DeleteQueue`, to identify further signs of unauthorized usage.
+**Correlate related activity**
+- Search for other CloudTrail events from the same identity before and after the purge, including IAM changes, credential activity, or additional SQS operations.
+- Look for signs of follow-on behavior such as queue deletion, policy updates, or attempts to suppress logging.
 
-### False Positive Analysis
+**Validate intent**
+- Confirm with the queue owner or application team whether the purge was intentional, approved, and expected. If no clear business justification exists, treat the activity as potentially suspicious.
 
-- **Legitimate Administrative Activity**: Administrators may purge SQS queues as part of maintenance or cleanup processes. Validate whether the action was part of an approved operation.
-- **Automation or Testing**: Automation tools or testing processes may perform queue purges as part of their workflow. Verify if the action aligns with known automated tasks or test scenarios.
-
-### Response and Remediation
-
-- **Immediate Actions**:
-  - **Restrict Access**: If the action appears unauthorized, immediately revoke access for the actor responsible for the purge and investigate potential credential compromise.
-  - **Restore Data**: If the purged queue contained critical or sensitive messages, attempt to restore them from backups if available.
-
-- **Preventative Measures**:
-  - **Enhance Monitoring**: Enable additional monitoring for SQS-related activity to detect unusual patterns, such as frequent purges or changes to queue configurations.
-  - **Audit Permissions**: Review and restrict IAM permissions for SQS to ensure only authorized users or roles can perform sensitive actions like `PurgeQueue`.
+### False positive analysis
 
-- **Policy Updates**:
-  - **Apply Least Privilege**: Adjust IAM policies to enforce the principle of least privilege, ensuring that only necessary permissions are granted. Review the policy assigned to the SQS queue as well to prevent unauthorized purges.
-  - **MFA Enforcement**: Require Multi-Factor Authentication (MFA) for all users with access to sensitive AWS resources.
+- Queue purges performed during routine maintenance, incident recovery, or test resets may be legitimate.
+- Automated jobs or cleanup scripts may regularly purge queues as part of normal operation.
 
-### Additional Information
+### Response and remediation
 
-For further guidance on AWS SQS operations and best practices, refer to:
-- [AWS SQS PurgeQueue API Documentation](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_PurgeQueue.html)
+- If the purge was unauthorized, immediately restrict SQS permissions for the affected identity and investigate for credential compromise.
+- Assess operational impact and determine whether downstream systems were disrupted or lost critical data.
+- Review recent activity to identify any additional attempts to evade detection or disable monitoring.
+- Reinforce least-privilege IAM policies to limit which identities can perform `PurgeQueue`.
+- Enhance monitoring and alerting for destructive SQS actions, especially in production environments.
+- Work with application teams to document approved purge workflows and ensure adequate guardrails are in place.
+
+### Additional information
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)**
 """
 references = [
     "https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_PurgeQueue.html",
@@ -118,16 +87,16 @@ tags = [
     "Use Case: Threat Detection",
     "Use Case: Log Auditing",
     "Tactic: Defense Evasion",
-    "Resources: Investigation Guide"
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset:"aws.cloudtrail"
-    and event.provider:"sqs.amazonaws.com"
-    and event.action:"PurgeQueue"
-    and event.outcome:"success"
+event.dataset: "aws.cloudtrail"
+    and event.provider: "sqs.amazonaws.com"
+    and event.action: "PurgeQueue"
+    and event.outcome: "success"
 '''
 
 
@@ -153,19 +122,17 @@ reference = "https://attack.mitre.org/tactics/TA0005/"
 field_names = [
     "@timestamp",
     "user.name",
+    "user_agent.original",
+    "source.ip",
     "aws.cloudtrail.user_identity.arn",
     "aws.cloudtrail.user_identity.type",
-    "user_agent.original",
-    "aws.cloudtrail.flattened.request_parameters.queueUrl",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "aws.cloudtrail.resources.arn",
+    "aws.cloudtrail.resources.type",
     "event.action",
     "event.outcome",
+    "cloud.account.id",
     "cloud.region",
-    "event.provider",
-    "aws.cloudtrail.request_id",
-    "aws.cloudtrail.resources.arn",
-    "source.ip",
-    "source.geo.city_name",
-    "source.geo.region_name",
-    "source.geo.country_name"
+    "aws.cloudtrail.request_parameters",
 ]