AWS SQS Queue Purge
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.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/01/08"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2025/12/12"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies when an AWS Simple Queue Service (SQS) queue is purged. Purging an SQS queue permanently deletes all messages
11currently in the queue. Adversaries may use this action to disrupt application workflows, destroy operational data, or
12impair monitoring and alerting by removing messages that contain evidence of malicious activity.
13"""
14false_positives = [
15 """
16 Authorized administrators or automated workflows may purge SQS queues for legitimate operational reasons, such as
17 clearing stale messages, resetting test environments, or performing approved maintenance. Verify that the action
18 aligns with documented procedures and expected operational behavior.
19 """,
20]
21from = "now-6m"
22index = ["filebeat-*", "logs-aws.cloudtrail-*"]
23language = "kuery"
24license = "Elastic License v2"
25name = "AWS SQS Queue Purge"
26note = """## Triage and analysis
27
28> **Disclaimer**:
29> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
30
31### Investigating AWS SQS Queue Purge
32
33AWS 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.
34
35### Possible investigation steps
36
37**Identify the actor**
38- 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.
39
40**Review the affected queue**
41- 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.
42
43**Evaluate the context of the action**
44- Review the `@timestamp` to determine when the purge occurred and whether it aligns with maintenance windows or
45 deployment activity.
46- Examine `source.ip` and `user_agent.original` for anomalies such as unexpected locations, automation tools, or
47 unfamiliar clients.
48
49**Correlate related activity**
50- Search for other CloudTrail events from the same identity before and after the purge, including IAM changes, credential activity, or additional SQS operations.
51- Look for signs of follow-on behavior such as queue deletion, policy updates, or attempts to suppress logging.
52
53**Validate intent**
54- 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.
55
56### False positive analysis
57
58- Queue purges performed during routine maintenance, incident recovery, or test resets may be legitimate.
59- Automated jobs or cleanup scripts may regularly purge queues as part of normal operation.
60
61### Response and remediation
62
63- If the purge was unauthorized, immediately restrict SQS permissions for the affected identity and investigate for credential compromise.
64- Assess operational impact and determine whether downstream systems were disrupted or lost critical data.
65- Review recent activity to identify any additional attempts to evade detection or disable monitoring.
66- Reinforce least-privilege IAM policies to limit which identities can perform `PurgeQueue`.
67- Enhance monitoring and alerting for destructive SQS actions, especially in production environments.
68- Work with application teams to document approved purge workflows and ensure adequate guardrails are in place.
69
70### Additional information
71- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**
72- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)**
73- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)**
74"""
75references = [
76 "https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_PurgeQueue.html",
77 "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/",
78]
79risk_score = 47
80rule_id = "bab88bb8-cdd9-11ef-bd9a-f661ea17fbcd"
81severity = "medium"
82tags = [
83 "Domain: Cloud",
84 "Data Source: AWS",
85 "Data Source: Amazon Web Services",
86 "Data Source: AWS SQS",
87 "Use Case: Threat Detection",
88 "Use Case: Log Auditing",
89 "Tactic: Defense Evasion",
90 "Resources: Investigation Guide",
91]
92timestamp_override = "event.ingested"
93type = "query"
94
95query = '''
96event.dataset: "aws.cloudtrail"
97 and event.provider: "sqs.amazonaws.com"
98 and event.action: "PurgeQueue"
99 and event.outcome: "success"
100'''
101
102
103[[rule.threat]]
104framework = "MITRE ATT&CK"
105[[rule.threat.technique]]
106id = "T1562"
107name = "Impair Defenses"
108reference = "https://attack.mitre.org/techniques/T1562/"
109[[rule.threat.technique.subtechnique]]
110id = "T1562.008"
111name = "Disable or Modify Cloud Logs"
112reference = "https://attack.mitre.org/techniques/T1562/008/"
113
114
115
116[rule.threat.tactic]
117id = "TA0005"
118name = "Defense Evasion"
119reference = "https://attack.mitre.org/tactics/TA0005/"
120
121[rule.investigation_fields]
122field_names = [
123 "@timestamp",
124 "user.name",
125 "user_agent.original",
126 "source.ip",
127 "aws.cloudtrail.user_identity.arn",
128 "aws.cloudtrail.user_identity.type",
129 "aws.cloudtrail.user_identity.access_key_id",
130 "aws.cloudtrail.resources.arn",
131 "aws.cloudtrail.resources.type",
132 "event.action",
133 "event.outcome",
134 "cloud.account.id",
135 "cloud.region",
136 "aws.cloudtrail.request_parameters",
137]
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating AWS SQS Queue Purge
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
Identify the actor
- Review
aws.cloudtrail.user_identity.arnandaccess_key_idto determine who initiated the purge. Confirm whether this identity typically manages SQS resources and whether the action aligns with their role.
Review the affected queue
- Identify the purged queue using
aws.cloudtrail.request_parametersoraws.cloudtrail.resources.arn. Determine the purpose of the queue and whether it supports critical workflows, security tooling, or monitoring pipelines.
Evaluate the context of the action
- Review the
@timestampto determine when the purge occurred and whether it aligns with maintenance windows or deployment activity. - Examine
source.ipanduser_agent.originalfor anomalies such as unexpected locations, automation tools, or unfamiliar clients.
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.
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.
False positive analysis
- 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.
Response and remediation
- 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
References
Related rules
- AWS Route 53 Resolver Query Log Configuration Deleted
- AWS RDS DB Instance Made Public
- AWS RDS DB Instance or Cluster Password Modified
- AWS CloudWatch Log Group Deletion
- AWS CloudWatch Log Stream Deletion