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:
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_managementThe 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:
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 wordlistHashcat mode 1420 implements sha256($salt.$pass), which matches RabbitMQ’s default salted SHA-256 construction after the conversion above.[5]
Shodan
port:15672 http