# RabbitMQ Management Port Discovery

- **URL:** https://hackindex.io/services/amqp/enumeration/rabbitmq-management-port-discovery
- **Path:** AMQP > Enumeration
- **Up:** [Enumeration](https://hackindex.io/services/amqp/enumeration.md)
- **Published:** 2026-02-07
- **Updated:** 2026-02-07

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](https://hackindex.io/services/amqp/vulnerability-discovery/rabbitmq-default-credentials) 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

```bash
nmap -sV -p 15672,15671 $TARGET_IP
# 15672/tcp open  http    Cowboy httpd
# 15671/tcp open  ssl/http Cowboy httpd
```

```bash
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.

```bash
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.

```bash
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.

```bash
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.

```bash
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](https://hackindex.io/services/amqp/exploitation/rabbitmq-management-api-exploitation) for queue message reading.

## References

- [RabbitMQ Management Plugin](https://www.rabbitmq.com/docs/management) - API reference, port configuration, and authentication