Skip to content
HackIndex.io

RabbitMQ Management Port Discovery

5 min read Created Feb 7, 2026 Last updated Feb 7, 2026

The RabbitMQ management plugin exposes an HTTP API and web UI on port 15672 (HTTP) and 15671 (HTTPS). When accessible it provides complete broker visibility: all vhosts, users and their permission sets, exchanges, queues, bindings, and live message rates. This is significantly more informative than AMQP protocol enumeration alone: even a read-only credential against the management API gives full infrastructure mapping. The plugin is enabled by default on many RabbitMQ deployments and is rarely restricted to internal interfaces. Port 15672 is frequently reachable in cloud environments where AMQP port 5672 is firewall-filtered. Check both ports regardless of AMQP access. Move to default credential testing once the management port is confirmed accessible.

  • Confirm Management Port
  • API Overview Without Credentials
  • List Vhosts via API
  • List Users
  • List Queues Per Vhost

Confirm Management Port

┌──(kali㉿kali)-[~]
└─$ nmap -sV -p 15672,15671 $TARGET_IP 
15672/tcp open  http    Cowboy httpd
15671/tcp open  ssl/http Cowboy httpd
┌──(kali㉿kali)-[~]
└─$ curl -sI http://$TARGET_IP:15672/ | grep -iE 'HTTP|location|server|www-authenticate' 
HTTP/1.1 301 Moved Permanently
Location: http://10.10.10.50:15672/#/

A redirect to /#/ confirms the full management UI is accessible without authentication checks at the URL level. A 401 with WWW-Authenticate means the API requires credentials but is reachable. Either response confirms the management plugin is active and externally exposed. A connection refused or timeout means the port is closed or filtered. Check 15671 for TLS if 15672 is unavailable. Some deployments bind only to 127.0.0.1 and require SSH tunneling or a web proxy to reach the API. If nmap shows the port open but curl returns nothing, the service may sit behind a path-based reverse proxy.

API Overview Without Credentials

The overview endpoint sometimes responds without authentication depending on configuration. When it does, you get the RabbitMQ version, Erlang version, node name, and cluster name before attempting any credential testing. The RabbitMQ version pinpoints known CVEs. The Erlang version affects which deserialization vulnerabilities apply. The node name often contains the hostname, which is useful for lateral movement planning. A cluster name that differs from the node name confirms the broker is part of a larger cluster with additional nodes to enumerate.

┌──(kali㉿kali)-[~]
└─$ curl -sk http://$TARGET_IP:15672/api/overview | python3 -m json.tool 2>/dev/null | grep -iE 'version|product|node|cluster' 
"rabbitmq_version": "3.11.4",
"erlang_version": "25.1",
"node": "rabbit@mq-server",
"cluster_name": "rabbit@mq-server"

List Vhosts via API

With valid credentials, enumerate all virtual hosts. Each vhost is a separate isolated messaging namespace with its own queues, exchanges, and bindings. Users have per-vhost permissions: a credential that can read one vhost may be blocked from another. Always enumerate which vhosts your current credential can access before assuming full broker visibility. Use the /api/permissions endpoint to map each user account to its allowed vhosts and operation types.

┌──(kali㉿kali)-[~]
└─$ curl -sk -u "$USER:$PASSWORD" http://$TARGET_IP:15672/api/vhosts | python3 -m json.tool | grep '"name"' 
"name": "/",
"name": "production",
"name": "staging",
"name": "payments"

Vhost names like payments and production are immediate targets: queues in these vhosts likely contain sensitive application messages. A staging vhost often reuses credentials copied from production. The default / vhost exists on every RabbitMQ installation. If your credential reaches non-default vhosts, the deployment has application-specific configuration that warrants deeper enumeration. Enumerate queues in each vhost separately using the vhost name URL-encoded in the path, for example /api/queues/%2F for the default vhost.

List Users

The users endpoint returns all RabbitMQ accounts and their management tags. Tags control access to the management API: administrator grants full management access including policy changes, monitoring allows read-only stats, and policymaker allows queue policy changes without full admin rights. An account with empty tags can still authenticate to AMQP even without management access. The guest account is the default RabbitMQ credential. Newer versions restrict it to localhost connections only. If guest appears with the administrator tag and the API is externally reachable, the broker is running a vulnerable default configuration. Note every account for later credential testing against AMQP directly.

┌──(kali㉿kali)-[~]
└─$ curl -sk -u "$USER:$PASSWORD" http://$TARGET_IP:15672/api/users | python3 -m json.tool | grep -iE '"name"|"tags"' 
"name": "guest",
"tags": "administrator",
"name": "admin",
"tags": "administrator",
"name": "app_user",
"tags": ""

List Queues Per Vhost

Queue enumeration reveals which message streams are active. The messages field shows how many messages are queued at poll time. High counts indicate an active workload. Queue names tied to domain processes such as payments, orders, auth, or events are the highest-value targets. Check the consumers count: zero consumers on an active queue may indicate a stalled consumer or messages accumulating unread. The durable field confirms whether the queue survives a broker restart. Durable queues with nonzero message counts are the most reliable targets for harvesting.

┌──(kali㉿kali)-[~]
└─$ curl -sk -u "$USER:$PASSWORD" http://$TARGET_IP:15672/api/queues | python3 -m json.tool | grep -iE '"name"|"vhost"|"messages"' 
"name": "task_queue",
"vhost": "/",
"messages": 142,
"name": "payment_events",
"vhost": "payments",
"messages": 8,

payment_events with 8 messages is an immediate target for message harvesting. Any queue with a nonzero message count is readable if your credential has the read permission on that vhost. A zero-message queue is not necessarily empty: messages may be consumed faster than the API polling interval. Re-check active queues after a short delay to confirm. Move to management API exploitation for queue message reading.

References