mosquitto
The reference MQTT broker, shipped with the mosquitto_sub / mosquitto_pub CLI clients that are the standard way to test and attack a broker.
Mosquitto is the reference open-source MQTT broker, and it ships with two command-line clients, mosquitto_sub and mosquitto_pub, that are the standard way to test, audit, and attack an MQTT deployment. The broker itself (mosquitto) is what you run to stand up a target; the clients are what you point at any broker, yours or someone else's.
What it is
MQTT is a lightweight publish/subscribe protocol built for constrained IoT devices. Clients never talk to each other directly: they connect to a central broker, publish messages to hierarchical topics (home/livingroom/lock), and subscribe to the topics they care about. Mosquitto is the most widely deployed broker and the de-facto teaching implementation. The two CLI clients are thin, scriptable wrappers over the protocol: mosquitto_sub opens a subscription and prints what arrives, mosquitto_pub sends one message and exits.
Why it matters
A large share of real deployments run the broker with anonymous access allowed and no TLS. That single misconfiguration collapses the whole security model. Because any client may subscribe to any topic, you can attach to # and read every message flowing through the system: live telemetry, device state, session tokens, and sometimes plaintext credentials. Worse, publish is symmetric: if a lock, relay, or PLC gateway acts on a command topic, you can publish that command yourself and the device will obey. MQTT has no built-in notion of who is allowed to write what, so an open broker is often a direct actuation primitive.
How to use it
mosquitto_sub -h 192.168.1.100 -t '#' -v # subscribe to every topic
mosquitto_sub -h 192.168.1.100 -t '$SYS/#' -v # broker stats, client list, counters
mosquitto_pub -h 192.168.1.100 -t home/lock -m UNLOCKED # inject a command
mosquitto_sub -h 192.168.1.100 -u user -P pass -t '#' # authenticated read
mosquitto_pub -h 192.168.1.100 -t home/lock -m OPEN -r # publish a retained message
The # wildcard matches every level of the topic tree; + matches exactly one level (home/+/state). The -v flag prints the topic next to each payload, which is essential when mapping an unknown broker. The reserved $SYS/# branch reports broker internals: connected clients, subscription counts, and uptime, a fast way to gauge how busy and how old a target is. A retained message (-r) is stored by the broker and delivered to every future subscriber, so it persists after you disconnect.
Pitfalls
- A published command only does something if a device is subscribed to that topic and acts on it. Reading
#first tells you which topics are live and what payload shape a device expects; blind publishing rarely works. - Wildcards are subscribe-only. You cannot publish to
home/#; you publish to one concrete topic at a time. - Retained messages linger. Publishing with
-rduring a test can leave state on the broker that confuses later observers or the device itself. Clear one by publishing an empty retained payload to the same topic. - QoS and
clean sessionchange delivery. If you miss messages, re-subscribe with-q 1and check whether a persistent session is queueing them elsewhere.
What it pairs with
Use nmap to find brokers first (-p 1883,8883), then Mosquitto to work them. Point a proxy such as mitmproxy or Wireshark at port 1883 to see the raw CONNECT/PUBLISH frames when a client misbehaves. Once you understand the topic map, scripting the same publish/subscribe logic in Python (paho-mqtt) lets you fuzz payloads or automate a replay.