Intercepting MQTT Traffic with InterceptSuite

MQTT is the dominant protocol for IoT messaging - used in smart home devices, industrial sensors, vehicle telematics, and cloud-connected embedded systems. It runs over TCP, typically on port 1883 (plaintext) or 8883 (TLS).

Burp Suite and other HTTP proxies cannot intercept MQTT. InterceptSuite intercepts raw TCP and TLS connections, making it the right tool for MQTT security testing.

What You Can See in Intercepted MQTT Traffic

MQTT uses a binary framing protocol with a small fixed header followed by variable-length payloads. Once intercepted, you can read:

CONNECT packets - client ID, username, password, clean session flag, keep-alive interval
SUBSCRIBE / UNSUBSCRIBE packets - topic filters and QoS levels
PUBLISH packets - topic name, payload, QoS, retain flag
CONNACK responses - broker return codes (including authentication failures)
PINGREQ / PINGRESP - keep-alive heartbeats

Credentials are often in plaintext in the CONNECT packet even on TLS-secured connections, since TLS only protects the transport - the MQTT payload may still carry hardcoded credentials that never rotate.

Setup: Intercepting MQTT with InterceptSuite

Prerequisites

InterceptSuite installed (SOCKS5 proxy on 127.0.0.1:4444 by default)
ProxyBridge for transparent routing

Step 1 - Start InterceptSuite

Open InterceptSuite and verify the SOCKS5 proxy listener shows Listening in the Proxy tab.

Step 2 - Configure ProxyBridge

Open ProxyBridge and go to Proxy → Proxy Settings
Set Proxy Type to SOCKS5
Set Host to 127.0.0.1, Port to 4444
Click Save Changes

Step 3 - Add Proxy Rules

Rule 1: InterceptSuite goes direct (prevents routing loop)

Field	Value
Applications	`InterceptSuite.exe`
Target Ports	`*`
Action	DIRECT

Rule 2: MQTT traffic through proxy

Field	Value
Applications	`*`
Target Ports	`1883; 8883`
Protocol	TCP
Action	PROXY

For custom broker ports, add them to the Target Ports list separated by semicolons.

Step 4 - Install the CA Certificate

For TLS-secured MQTT (port 8883), install the InterceptSuite CA certificate so the MQTT client accepts the MITM certificate:

Step 5 - Run the MQTT Client

Connect your MQTT client to the broker as normal. With Python's paho-mqtt:

import paho.mqtt.client as mqtt

client = mqtt.Client()
client.username_pw_set("user", "password")
client.tls_set()  # uses system CA store - InterceptSuite CA must be installed
client.connect("192.168.1.20", 8883, 60)
client.subscribe("sensors/#")
client.loop_forever()

ProxyBridge intercepts the connection transparently before it leaves your machine.

Step 6 - Inspect in Proxy History

Open the Proxy History tab in InterceptSuite. The MQTT connection appears as a decrypted TCP session. Click to expand it and see all MQTT packets in the exchange - including the CONNECT packet with credentials.

Parsing MQTT Packets with Extensions

MQTT's binary format is well-documented. An InterceptSuite extension can parse the packet type and display key fields:

from InterceptSuite.Extensions.APIs.Logging import ExtensionLogger

PACKET_TYPES = {
    1: 'CONNECT', 2: 'CONNACK', 3: 'PUBLISH', 4: 'PUBACK',
    8: 'SUBSCRIBE', 9: 'SUBACK', 12: 'PINGREQ', 13: 'PINGRESP',
    14: 'DISCONNECT',
}

class MQTTTab:
    def should_show_tab(self, data):
        raw = data.get("data", "")
        return len(raw) >= 2

    def fetchdata(self, data):
        raw = data.get("data", "")
        try:
            b = raw.encode('latin-1') if isinstance(raw, str) else raw
            pkt_type = (b[0] >> 4) & 0xF
            label = PACKET_TYPES.get(pkt_type, f"Type {pkt_type}")
            ExtensionLogger.Log(f"MQTT packet: {label}")
            return f"[{label}]\n{raw}"
        except Exception as e:
            return f"Parse error: {e}"

    def updatedata(self, data):
        return None

class InterceptSuiteExtension:
    def register_interceptor_api(self, interceptor):
        interceptor.set_extension_name("MQTT Viewer")
        interceptor.set_extension_version("1.0.0")
        interceptor.AddDataViewerTab("MQTT", MQTTTab())
        ExtensionLogger.Log("MQTT Viewer loaded.")

See the Extension API reference for the full interface.

Common MQTT Security Findings

When testing MQTT brokers and clients, common vulnerabilities include:

Plaintext credentials in CONNECT - username/password sent before TLS or without it
No authentication required - broker accepts anonymous connections
Wildcard subscriptions - clients can subscribe to # and receive all messages
Hardcoded credentials - same password across all devices in a product line
No TLS - port 1883 used in production with sensitive telemetry payloads
Insecure retained messages - sensitive data stored on the broker indefinitely