Successful AMQP Multi-Queue Purge Burst

  1[metadata]
  2creation_date = "2026/07/30"
  3integration = ["network_traffic"]
  4maturity = "production"
  5updated_date = "2026/07/30"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies multiple successful AMQP queue purge operations issued by the same client to the same broker within a short
 11period. The AMQP queue.purge method removes all messages from a queue that are not awaiting acknowledgment. Purging
 12several distinct queues can indicate deliberate message destruction or disruption after broker credentials are
 13compromised.
 14"""
 15false_positives = [
 16    """
 17    Authorized administrators or automation may purge multiple queues during maintenance, testing, disaster recovery, or
 18    application resets. Confirm the client, authenticated RabbitMQ user, affected queues, and change window before
 19    escalating. Add exceptions for verified administrative sources rather than reducing the queue-cardinality threshold.
 20    """,
 21]
 22from = "now-9m"
 23language = "esql"
 24license = "Elastic License v2"
 25name = "Successful AMQP Multi-Queue Purge Burst"
 26note = """## Triage and analysis
 27
 28### Investigating Successful AMQP Multi-Queue Purge Burst
 29
 30The AMQP `queue.purge` method removes every ready message from the selected queue. This rule requires successful purge responses for at least three distinct queues from one client-to-broker pair, reducing noise from isolated administrative operations while identifying activity capable of causing broad message loss and application disruption.
 31
 32### Possible investigation steps
 33
 34- Review `client.ip`, `server.ip`, `Esql.purge_count`, `Esql.queue_count`, `Esql.queues`, `Esql.first_purge`, and `Esql.last_purge` to determine the scope and timing of the activity.
 35- Search the underlying `logs-network_traffic.amqp-*` events and confirm that each transaction has `network_traffic.amqp.method: "queue.purge"`, `network_traffic.amqp.no-wait: false`, and `network_traffic.status: "OK"`. Together, these values indicate that Packetbeat observed the broker's `queue.purge-ok` response.
 36- Use RabbitMQ audit and application logs to identify the authenticated user associated with the client connection. AMQP message properties are not authoritative authentication identities.
 37- Determine whether the source is approved administration or maintenance automation and whether a documented change authorized purging all affected queues.
 38- Assess message loss and application impact. Review queue-depth metrics, dead-letter queues, publisher errors, consumer lag, and service availability around the alert.
 39- Correlate the client and account with `queue.delete`, `exchange.delete`, binding changes, unusual consumers, authentication anomalies, and endpoint alerts.
 40
 41### False positive analysis
 42
 43- Queue maintenance, integration testing, disaster-recovery exercises, and application reset workflows may intentionally purge several queues.
 44- Treat confirmed recurring activity as a benign true positive and scope exceptions to approved client-to-broker pairs or queue names. Broadly excluding `queue.purge` would conceal the destructive behavior this rule is intended to detect.
 45
 46### Response and remediation
 47
 48- Revoke or restrict unauthorized RabbitMQ credentials and block the client if the purge was not approved.
 49- Preserve broker, network, and application evidence before restarting affected services.
 50- Restore or replay messages from upstream systems, backups, or dead-letter infrastructure where possible.
 51- Review RabbitMQ permissions and remove unnecessary queue-configuration rights from application accounts.
 52- Investigate the client host and associated account for credential theft and additional destructive activity.
 53"""
 54references = [
 55    "https://www.rabbitmq.com/amqp-0-9-1-reference",
 56    "https://attack.mitre.org/techniques/T1485/",
 57]
 58risk_score = 73
 59rule_id = "286614ee-8b72-4ea5-a22d-e0d2ae59d0a9"
 60setup = """## Setup
 61
 62This rule requires the Elastic Network Packet Capture integration with the AMQP protocol analyzer enabled and cleartext
 63AMQP 0.9.1 visibility. AMQP header and method-argument parsing must remain enabled so the method, queue, and transaction
 64status are populated. AMQP over TLS is opaque to passive capture. RabbitMQ audit logs are required to map the observed
 65client connection to an authenticated broker identity.
 66"""
 67severity = "high"
 68tags = [
 69    "Domain: Network",
 70    "Use Case: Network Security Monitoring",
 71    "Use Case: Threat Detection",
 72    "Tactic: Impact",
 73    "Data Source: Network Packet Capture",
 74    "Resources: Investigation Guide",
 75]
 76timestamp_override = "event.ingested"
 77type = "esql"
 78
 79query = '''
 80FROM logs-network_traffic.amqp-*
 81| WHERE
 82    data_stream.dataset == "network_traffic.amqp" AND
 83    network_traffic.amqp.method == "queue.purge" AND
 84    network_traffic.amqp.`no-wait` == false AND
 85    network_traffic.status == "OK" AND
 86    client.ip IS NOT NULL AND
 87    server.ip IS NOT NULL AND
 88    network_traffic.amqp.queue IS NOT NULL
 89| STATS
 90    Esql.purge_count = COUNT(*),
 91    Esql.queue_count = COUNT_DISTINCT(network_traffic.amqp.queue),
 92    Esql.queues = VALUES(network_traffic.amqp.queue),
 93    Esql.first_purge = MIN(@timestamp),
 94    Esql.last_purge = MAX(@timestamp)
 95  BY client.ip, server.ip
 96| WHERE Esql.purge_count >= 3 AND Esql.queue_count >= 3
 97| SORT Esql.queue_count DESC, Esql.purge_count DESC
 98| KEEP client.ip, server.ip, Esql.purge_count, Esql.queue_count, Esql.queues, Esql.first_purge, Esql.last_purge
 99'''
100
101
102[[rule.threat]]
103framework = "MITRE ATT&CK"
104[[rule.threat.technique]]
105id = "T1485"
106name = "Data Destruction"
107reference = "https://attack.mitre.org/techniques/T1485/"
108
109
110[rule.threat.tactic]
111id = "TA0040"
112name = "Impact"
113reference = "https://attack.mitre.org/tactics/TA0040/"