# AMQP (RabbitMQ) - Port 5671/5672

{% tabs %}
{% tab title="Support VeryLazyTech 🎉" %}

* Become VeryLazyTech [**member**](https://whop.com/verylazytech/)**! 🎁**
* **Follow** us on:
  * **✖ Twitter** [**@VeryLazyTech**](https://x.com/verylazytech)**.**
  * **👾 Github** [**@VeryLazyTech**](https://github.com/verylazytech)**.**
  * **📜 Medium** [**@VeryLazyTech**](https://medium.com/@verylazytech)**.**
  * **📺 YouTube** [**@VeryLazyTech**](https://www.youtube.com/@VeryLazyTechOfficial)**.**
  * **📩 Telegram** [**@VeryLazyTech**](https://t.me/+mSGyb008VL40MmVk)**.**
  * **🕵️‍♂️ My Site** [**@VeryLazyTech**](https://www.verylazytech.com/)**.**
* Visit our [**shop** ](https://whop.com/verylazytech/)for e-books and courses.  📚
  {% endtab %}
  {% endtabs %}

### Basic info

RabbitMQ is a message broker implementing AMQP (0‑9‑1 and 1.0), used to decouple services. Queues hold messages until consumers pull them. Attackers who can connect and authenticate can: read queued messages, publish malicious messages, create queues/exchanges, and abuse management APIs.

* **Default ports:** `5672/tcp` (AMQP plain), `5671/tcp` (AMQPS/TLS).
* **Why it matters:** Brokers hold messages, secrets, and can be an attacker pivot to internal workloads. Default credentials (`guest:guest`) or exposed management plugins lead to full compromise.
* **Quick wins for defenders:** block `5672/5671` from the internet, require TLS + strong auth, disable guest accounts, and limit virtual hosts.

***

### Enumeration

**Nmap**:

```
# service discovery
nmap -sV -Pn -n -p5672,5671 --script amqp-info <IP>

# management UI check (if management plugin enabled)
nmap -sV -Pn -p15672 --script http-title <IP>
```

Example `amqp-info` output shows capabilities, product/version and supported mechanisms (PLAIN, AMQPLAIN, etc.).

### Manual Enumeration (Python)

```
import amqpconn = amqp.connection.Connection(host="<IP>", port=5672, virtual_host="/")
conn.connect()print(conn.server_properties)
```

* The client handshake often reveals server properties and available authentication mechanisms. If `guest:guest` is allowed and the broker hasn’t restricted guest to localhost, easy takeover is possible.

### Automated Checks

```
# amqp-info via nmap (fast)
nmap -sV -Pn -n -T4 -p5672 --script amqp-info <IP>
```

Look for `mechanisms: PLAIN AMQPLAIN` and `locales`, plus `product/version`. Versions <3.x may have known weaknesses; always check vendor advisories.

***

### Brute Force & Auth Testing

* Typical default creds: `guest:guest` (default), or credentials leaked in repos. Test with a targeted credential list and respect rate limits.
* Protocols to test: [AMQP (5672)](https://www.verylazytech.com/amqp-rabbitmq-port-5671-5672), AMQPS (5671), STOMP (61613/61614), [MQTT (1883/8883)](https://www.verylazytech.com/mqtt-message-queuing-telemetry-transport-port-1883) if plugins enabled.

**Brute force:**

```
legba amqp --target localhost:5672 --username admin --password data/passwords.txt [--amql-ssl]

legba stomp --target localhost:61613 --username admin --password data/passwords.txt
```

***

### Management API & Web UI

If the management plugin is enabled (default port `15672`), it exposes an HTTP API to list vhosts, users, queues, bindings and more. If misconfigured or reachable from the internet, full control is trivial.

Enumeration with curl (basic auth required):

```
curl -s -u 'user:pass' http://<host>:15672/api/overview | jq '.'
curl -s -u 'user:pass' http://<host>:15672/api/queues | jq '.'
```

If the management UI accepts weak creds, you can: purge queues, consume messages, create policies, and configure federation or shovel plugins to exfiltrate data.

***

### Post‑Compromise Scenarios

* **Message theft:** read messages containing secrets (API keys, PII, internal tokens).
* **Message injection:** publish payloads that trigger actions in downstream consumers.
* **Persistence:** create users with admin rights, create long-lived virtual hosts, enable shovel/federation to mirror queues to an attacker-controlled broker.
* **Lateral movement:** use credentials to access management UI, then use cluster-level ports (25672/35672 range) for node-to-node communication or CLI tools.

***

### Hardening & Defender Playbook

**Network & Access**

* Do **not** expose 5672/5671 or management port 15672 to the public internet. Use VPN or dedicated management network.
* Block inter-node Erlang ports (25672 and 35672-35682 ranges) externally.

**Authentication & TLS**

* Disable `guest` remote access: ensure `guest` only works on `localhost`.
* Enforce TLS (AMQPS 5671) for client connections and management UI. Use strong ciphers and cert pinning where possible.
* Use per-application accounts with least privilege and fine-grained vhost separation.

**Plugins & Config**

* Disable unnecessary plugins (federation/shovel/management) unless required. If used, restrict via network ACLs.
* Limit vhosts and bindings; use permissions to restrict which users can `read`/`write` on which resources.

**Monitoring & Detection**

* Alert on new user creation, new shovels/federations, high dequeue rates, or sudden queue purges.
* Monitor management API for unexpected requests, and SIEM alerts for large `GET /api/queues` responses.
* File integrity monitoring on config (`rabbitmq.conf`, `enabled_plugins`), and watch for suspicious changes.

**Operational hygiene**

* Rotate credentials, remove default accounts, and audit config files for hardcoded creds. Use a secrets manager for app credentials.

Quick firewall commands:

```
# block public AMQP
ufw deny proto tcp from any to any port 5672
ufw deny proto tcp from any to any port 5671

# restrict management UI to admin subnet
ufw allow proto tcp from 10.0.0.0/24 to any port 15672
```

***

### Shodan / Internet Exposure

Search Shodan for `amqp` or `port:5672` to find publicly exposed brokers. Prioritize remediation for internet-exposed nodes and those with management UI reachable.

```
port:5672 product:RabbitMQ
amqp
```

{% hint style="success" %}
Learn & practice [**For the Bug Bounty**](https://whop.com/verylazytech/)

<details>

<summary>Support VeryLazyTech 🎉</summary>

* Become VeryLazyTech [**member**](https://whop.com/verylazytech/)**! 🎁**
* **Follow** us on:
  * **✖ Twitter** [**@VeryLazyTech**](https://x.com/verylazytech)**.**
  * **👾 Github** [**@VeryLazyTech**](https://github.com/verylazytech)**.**
  * **📜 Medium** [**@VeryLazyTech**](https://medium.com/@verylazytech)**.**
  * **📺 YouTube** [**@VeryLazyTech**](https://www.youtube.com/@VeryLazyTechOfficial)**.**
  * **📩 Telegram** [**@VeryLazyTech**](https://t.me/+mSGyb008VL40MmVk)**.**
  * **🕵️‍♂️ My Site** [**@VeryLazyTech**](https://www.verylazytech.com/)**.**
* Visit our [**shop** ](https://whop.com/verylazytech/)for e-books and courses.  📚

</details>
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.verylazytech.com/amqp-rabbitmq-port-5671-5672.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.