Posted by: Bamric Security Team
In the world of IoT, the MQTT protocol (Message Queuing Telemetry Transport) plays a crucial role in enabling lightweight, real-time communication between IoT devices and apps. But with great connectivity comes great risk.
This blog dives deep into the security testing of MQTT, showing how vulnerabilities in its implementation can be exploited if not properly secured. From misconfigured brokers to sniffed credentials, MQTT can be a soft target in many IoT deployments.
In this guide, we’ll walk through common MQTT attacks — like anonymous access, credential brute-forcing, information leakage, and cleartext sniffing — and demonstrate them in a controlled local lab. Whether you’re a pentester, IoT developer, or security enthusiast, this hands-on blog will help you understand MQTT security weaknesses and how to defend against them.
In the previous blog, we explored the fundamentals of MQTT, its architecture, and how to set up a lab environment. In this blog, we will dive deeper into security by demonstrating how to perform penetration testing on MQTT and execute various attacks within our own lab.
Whenever you’re using a smart IoT device and controlling it through an application, there’s a high chances that the app is using the MQTT protocol for communication
Steps to identify app is using MQTT
A. Captured the app’s traffic in Burp Suite and observed an API call to /MQTT, confirming that the app is using the MQTT protocol.
B. Network traffic analysis
C. The first two methods are the most effective and commonly used for identifying MQTT usage. However, if these don’t yield results, you can try decompiling the app for code analysis, monitoring logs with adb logcat, inspecting the AndroidManifest.xml file, or using runtime hooking with Frida to detect MQTT-related activity.
Once we’ve confirmed that the app is using MQTT, the next step is to capture and analyze the MQTT traffic to understand its behavior and identify potential attack vectors.
A. Capture the traffic in Wireshark
Install Wireshark, launch the application, and select the Wi-Fi interface. Ensure that both your IoT device and the controlling app are connected to the same network.
After selecting the Wi-Fi interface, click on “Start” to begin capturing traffic. Once the traffic is visible in Wireshark, you can use filters like tcp.port == 1883 or mqtt to isolate MQTT-related packets.
B. Capture traffic using the WebSocket tab in Burp Suite
Often, when an app communicates with a remote IoT device — such as controlling your smart home device from another city or country — the application uses WebSocket for MQTT communication. And that’s how it looks like in the websocket tab. When we expand specific request we are able to view commands and everything.
From this point onward, we’ll focus on performing attacks. To avoid repeating command explanations, here’s a quick overview of the key MQTT command options we’ll use:
With these commands explained, we can now focus directly on demonstrating the attacks.
Now that we’ve identified the app is using MQTT and have captured the traffic, we’re ready to perform attacks for real-world penetration testing. We’ll organize the attacks by category, like authentication,authorisation , Integrity, Availability etc.
For testing purposes, we’ll set up a lab environment where MQTT credentials are intentionally included. This will allow us to practice and learn how to harvest them in a controlled and safe setting.
Steps to create MQTT credentials using the Mosquitto broker:
mosquitto_passwd -c passwdfile testuser
3. Update mosquitto.conf
4. Restart Docker Broker
docker stop mqtt-broker
docker rm mqtt-broker
docker run -it — name mqtt-broker -p 1883:1883 \
-v /Users/vaishali/mosquitto.conf:/mosquitto/config/mosquitto.conf \
-v /Users/vaishali/passwdfile:/mosquitto/config/passwdfile \
eclipse-mosquitto
MQTT Credential Harvesting involves capturing and extracting the authentication details — such as usernames and passwords — used by MQTT clients to connect to the broker. By intercepting MQTT traffic or analyzing the application’s data flow, an attacker can obtain these credentials, potentially gaining unauthorized access to the MQTT broker. This vulnerability highlights the importance of securing MQTT communication channels and properly protecting sensitive information to prevent unauthorized control of IoT devices.
a. MQTT Credential Harvesting via Analyzing Wireshark Traffic
As discussed earlier, once the traffic is captured in Wireshark, you can use the filter mqtt.msgtype == 1 to view CONNECT packets. Typically, MQTT credentials — such as the username and password — are transmitted during this connection phase. If the communication is unencrypted, there’s a high chance these credentials will be visible in the packet details.
B. MQTT Credential Harvesting via Analyzing APIs response
Often during MQTT credential harvesting, usernames and passwords may also be exposed in API calls — especially when the application uses WebSocket for MQTT communication. This typically happens during the initial connection or authentication phase between the app and the broker.In one of my projects, I discovered MQTT credentials exposed in an API response. These credentials can also potentially be found in other places, such as JavaScript files or other client-side resources.
Often, even after implementing a username and password, you may still be able to connect without authentication. This usually happens because of a misconfiguration in the config file where allow_anonymous is set to true. It’s important to verify whether this setting is enabled or not.
Steps to perform attack
mosquitto_sub -h localhost -t test/topic
2. Publish a message and watch the subscribed terminal to see the message being displayed.
mosquitto_pub -h localhost -t test/topic -m “Hello MQTT”
Default credentials in MQTT are preset usernames and passwords that come with some brokers or IoT devices by default. If not changed, they can be easily exploited by attackers to gain unauthorized access. Always make sure to update these default MQTT credentials to secure your devices and broker.
Run the below command to provide default credential
mosquitto_sub -h localhost -t “robot/1/move” -u admin -P admin
We will use a simple script to brute-force the credentials. Save it with a .js extension and run it using Node.js.
Run the command below to perform the brute-force attack
node MQTT_Credential_Brute_force.js
Authorization attacks in MQTT involve bypassing or exploiting improper access control configurations to publish to or subscribe from unauthorized topics. These attacks can lead to data leakage, unauthorized device control, or denial of service. Common causes include weak or missing ACLs, misconfigured permissions, or enabled anonymous access. Testing for such flaws helps ensure that only authorized clients can access specific MQTT topics.
The MQTT broker allows clients to subscribe and publish to unauthorized topics due to improper ACL enforcement. An attacker can use a hit-and-trial approach to guess valid topic names and subscribe and publish to them, potentially gaining access to sensitive data or unauthorized control — such as issuing commands to another user’s robot — despite not having the necessary permissions
Lab Setup for Authorization Attacks:
Initially, I planned to set up a lab environment to demonstrate Authorization Attacks by creating an access control list (ACL) file and referencing it in the Mosquitto configuration. Ideally, this setup should have enforced topic-based permissions. However, due to persistent configuration issues, the ACL enforcement did not function as expected. Rather than spending excessive time troubleshooting, I chose to move forward — since the main objective was to understand how to publish and subscribe to topics, which is essential for carrying out and demonstrating the attacks effectively.
This test checks whether the MQTT broker correctly enforces access control by attempting to subscribe to a topic the client is not authorized to access. If the broker is misconfigured or lacks proper ACL enforcement, an unauthorized user may still be able to subscribe and receive sensitive data. This exposes a serious security flaw, as it can lead to data leakage or unauthorized control over IoT devices.
Run the below command
mosquitto_sub -h localhost -t test/topic -u testuser -P 123456
This test checks whether the MQTT broker correctly enforces permissions when a client tries to publish messages to topics it is not authorized to access. If the broker does not properly restrict publishing rights, unauthorized users could send malicious or misleading messages, potentially causing incorrect device behavior or disrupting system operations. This vulnerability risks data integrity and system reliability in the IoT network.
Run the below command
mosquitto_pub -h localhost -t test/topic -m “move_forward” -u testuser -P 123456
This test examines if clients can subscribe to MQTT topics using wildcards — special characters that allow matching multiple topics with a single subscription. The two main wildcards are:
# (multi-level wildcard): matches all topics starting from a specific level downwards.+ (single-level wildcard): matches exactly one topic level.For example, subscribing to home/+/temperature matches topics like home/livingroom/temperature and home/kitchen/temperature, while home/# matches all topics starting with home/.
Improper access control on wildcard subscriptions can allow unauthorized users to access a wide range of topics beyond their permission. This broad access can expose sensitive data and increase the risk of information leakage, making the system vulnerable to privacy breaches and further attacks.
Run the below command
mosquitto_sub -h localhost -t # -u testuser -P 123456
Denial of Service (DoS) attacks on MQTT aim to disrupt the normal operation of the MQTT broker or connected clients by overwhelming them with excessive requests or resource-intensive operations. Attackers may flood the broker with a large number of connection requests, subscribe/unsubscribe messages, or publish messages, exhausting the broker’s CPU, memory, or network capacity. This overload causes legitimate clients to lose access, experience delays, or get disconnected, effectively denying service.
Flooding a topic with PUBLISH messages involves sending a high volume of messages rapidly to overwhelm the MQTT broker or subscribers, potentially causing performance degradation or service disruption.
Save the following script with a .js extension. Make sure to replace the username, password, host, and port with the victim’s credentials and connection details.
node MQTT_Publish_Dos.js
Flooding the broker with CONNECT requests means repeatedly opening new connections to exhaust the broker’s resources, leading to denial of service.
Save the following script with a .js extension. Make sure to replace the username, password, host, and port with the victim’s credentials and connection details.
node MQTT_Connect_Dos.js
In this blog, we explored practical MQTT vulnerabilities across three critical areas: authentication, authorization, and availability. We demonstrated how weak access controls and misconfigurations can lead to serious security issues — from unauthorized topic subscriptions and credential bypasses to denial-of-service conditions via client flooding. These tests highlight the importance of hardening MQTT brokers with proper ACLs, strong authentication, connection limits, and secure configurations. As IoT systems increasingly rely on MQTT, addressing these weaknesses is essential to ensure the confidentiality, integrity, and availability of connected devices and their data.
Bamric Security Solutions, Believes in providing top-notch security. Let’s make cyberspace a safer place together.
