Protocolli Publish/Subscribe: Publish/Subscribe Protocols (T1071.005)

Dal punto di vista offensivo, il valore di un canale pub/sub sta nel riutilizzo di infrastruttura percepita come benigna. In un esercizio red team lab-safe l'obiettivo è dimostrare che un broker MQTT o XMPP può veicolare comandi senza allertare i controlli perimetrali orientati a HTTP/HTTPS.

Un punto di partenza realistico è allestire un broker di test come Eclipse Mosquitto (open source), il riferimento de facto per MQTT. Il traffico C2 si simula con due topic dedicati: uno per i comandi verso l'implant, uno per i risultati verso l'operatore. Sul sistema controllato dall'operatore la pubblicazione avviene con i client ufficiali:

mosquitto_pub -h -p 8883 --cafile ca.crt -t ops/cmd -m 'whoami'

Mentre l'implant resta in ascolto sul topic dei comandi:

mosquitto_sub -h -p 8883 --cafile ca.crt -t ops/cmd

Usare la porta 8883 con TLS rende il payload opaco all'ispezione superficiale. Per prototipare rapidamente un beacon si può ricorrere alla libreria paho-mqtt (open source) in Python, che permette di gestire callback su ricezione messaggio e di scandire l'intervallo di beaconing con jitter, riducendo la regolarità temporale.

Sul fronte XMPP, il precedente storico è GLOOXMAIL (S0026), malware che sfruttava il protocollo Jabber/XMPP verso server Google per il C2: un esempio concreto di come un servizio di messaggistica pubblica possa diventare vettore. In laboratorio si può replicare il concetto con un server Prosody (open source) e un client basato su librerie XMPP, incapsulando comandi nel corpo dei messaggi.

La catena d'attacco tipica prevede: accesso iniziale ed esecuzione dell'implant, registrazione al broker con credenziali rubate o account creati ad hoc, poi loop di sottoscrizione/pubblicazione. Su Windows l'implant può essere avviato da processi anomali come powershell.exe o rundll32.exe; su Linux tramite script Python o direttamente mosquitto_pub; su macOS con binari custom o curl verso endpoint broker.

Per la fase di test e analisi del traffico è utile MQTT Explorer (freemium) per visualizzare i topic attivi, e Wireshark (open source) con i dissector MQTT/XMPP per verificare cosa resta visibile in chiaro. L'esercizio dimostra ai difensori quanto conti profilare processi e destinazioni, non solo le porte.

La detection efficace di questa tecnica è comportamentale, non basata su firme statiche, perché il traffico pub/sub legittimo è indistinguibile dal malevolo a livello di protocollo. Il fulcro è correlare quale processo parla, verso quale broker e con quale cadenza.

Su Windows l'indicatore chiave è un processo non-browser — tipicamente powershell.exe, python.exe o rundll32.exe — che apre connessioni in uscita su canali cifrati verso broker di messaggistica. Le fonti primarie sono Sysmon (EventCode 1 per la creazione processo e EventCode 3 per le connessioni di rete) correlati con i flussi NSM. Il segnale forte è il beaconing: connessioni ripetute a intervalli regolari verso lo stesso endpoint, da profilare con una finestra temporale definita.

Su Linux l'attenzione si sposta su tool CLI come mosquitto_pub, nc o script Python che interagiscono con broker usando nomi di topic insoliti, tassi di pubblicazione elevati o payload offuscati. La telemetria arriva da auditd (SYSCALL, in particolare execve e connect) unita ai flussi di rete. Un buon scoring anomalo pesa lunghezza del payload, entropia e pattern del nome topic.

Su macOS i candidati sono osascript, curl o binari custom che raggiungono broker XMPP/MQTT non approvati, con payload cifrati o richieste frequenti simili a POST verso URI del broker. Le fonti sono lo unified log e osquery.

A livello di network device si osserva traffico pub/sub su porte inconsuete, pubblicazioni ad alta frequenza e connessioni verso broker dinamici o già noti come malevoli, correlando i flussi NSM con feed di reputazione.

Alcune leve di tuning ricorrenti nei dati di detection:

• UnusualProcessList — processi non attesi che avviano connessioni pub/sub
• ProtocolPortList — uso di porte MQTT/XMPP fuori standard (1883, 5222, 5672, oltre a 8883)
• BrokerAllowList — broker legittimi usati da applicazioni e daemon approvati
• BrokerReputationList — blocklist dinamica o threat intel per broker C2
• PayloadLengthThreshold — messaggi lunghi da esfiltrazione contro telemetria breve

I falsi positivi sono la sfida principale: ambienti IoT, industriali e pipeline di monitoraggio usano MQTT/AMQP in modo massiccio e legittimo. La costruzione di una allowlist per broker e applicazioni note è quindi prerequisito. Sul fronte preventivo, le mitigazioni M1031 (Network Intrusion Prevention) e M1037 (Filter Network Traffic) suggeriscono firme IDS/IPS mirate e filtraggio delle richieste pub/sub verso risorse non fidate su porte irregolari.

L'analisi forense di un C2 su protocolli pub/sub richiede di ricostruire tre elementi: il processo che ha stabilito il canale, la destinazione (broker e topic) e la cronologia delle comunicazioni. Poiché il traffico spesso viaggia cifrato, gli artefatti endpoint diventano decisivi quanto le catture di rete.

Su Windows la timeline si costruisce dagli eventi Sysmon: la creazione del processo sospetto (EventCode 1) con la relativa command line, e le connessioni di rete (EventCode 3) che riportano IP e porta di destinazione. Utile incrociare con i Prefetch per confermare l'esecuzione di interpreti come PowerShell o Python, e con le chiavi Run/RunOnce del registro se l'implant persiste al riavvio. Le entry di Amcache e ShimCache aiutano a datare la prima comparsa del binario.

Su Linux i log auditd registrano le SYSCALL rilevanti (execve, connect, socket), permettendo di legare l'invocazione di mosquitto_pub o di uno script Python al momento della connessione al broker. La cronologia della shell (.bash_history), i timestamp dei file nel filesystem e le unità systemd o cron sospette completano il quadro della persistenza. La correlazione con i flussi NSM consente di stimare frequenza e volume delle pubblicazioni.

Su macOS l'unified log e le tabelle osquery documentano l'attività di osascript, curl o binari custom verso broker non approvati, con evidenza di richieste ripetute a URI del broker.

Un caso storico di riferimento è GLOOXMAIL (S0026), che usava Jabber/XMPP verso server Google: un esempio in cui l'artefatto di rete si confonde con traffico di messaggistica legittimo, imponendo all'analista di partire dal processo anomalo piuttosto che dalla sola destinazione.

Gli artefatti digitali chiave da preservare includono:

• Il file dell'implant e la sua command line completa
• I record di connessione di rete con IP/porta del broker (1883, 8883, 5222, 5672)
• I topic utilizzati, ricostruibili da payload in chiaro o da memoria
• I timestamp per determinare l'intervallo di beaconing

Quando disponibili, le catture di traffico permettono di distinguere pubblicazioni brevi tipo telemetria da messaggi lunghi compatibili con esfiltrazione. In assenza di decifratura, l'analisi dei metadati di flusso — regolarità temporale, dimensione, numerosità delle sessioni verso lo stesso endpoint — resta l'indizio forense più robusto.

Il quadro di intelligence su T1071.005 è, allo stato dei dati MITRE forniti, deliberatamente scarno: nessun gruppo APT e nessuna campagna risultano formalmente associati, mentre è documentato un solo software. Questa scarsità non va letta come irrilevanza, bensì come segnale di un vettore emergente e sottovalutato, soprattutto in ambienti IoT e industriali dove i broker di messaggistica sono onnipresenti.

L'unico riferimento concreto è GLOOXMAIL (S0026), malware che sfrutta il protocollo Jabber/XMPP per comunicare con server operati da Google a fini di comando e controllo. È un esempio istruttivo di un principio ricorrente nell'evoluzione del C2: appoggiarsi a servizi di messaggistica pubblici e reputati affidabili per ottenere sia stealth sia resilienza. Il traffico verso infrastruttura di un grande provider è difficile da bloccare senza impatti operativi, e la cifratura nativa del canale riduce la visibilità dei difensori.

Sul piano dei pattern, GLOOXMAIL anticipa una tendenza più ampia: l'abuso di protocolli legittimi ad alto volume — dalla messaggistica istantanea alla telemetria MQTT — come tessuto in cui nascondere comandi. Il modello broker-centrico offre un vantaggio architetturale all'attaccante, che non deve esporre un listener diretto sull'host compromesso ma si limita a sottoscrivere un topic, spostando il punto di rendez-vous su infrastruttura di terze parti.

Per un Threat Intelligence Officer le implicazioni pratiche sono chiare. In assenza di attribuzioni consolidate, il monitoraggio va orientato per protocollo e comportamento più che per gruppo: alimentare feed di reputazione sui broker (coerente con la leva BrokerReputationList della detection) e curare allowlist dei broker legittimi diventa la contromisura strategica. La crescente adozione di MQTT sulle porte 1883/8883 e di XMPP sulla 5222 amplia la superficie sfruttabile.

Il trend atteso è un aumento dell'interesse offensivo verso i protocolli pub/sub man mano che le reti OT/IoT si integrano con l'IT aziendale. La convergenza rende i broker un ponte prezioso per movimento laterale ed esfiltrazione mascherata da telemetria. Chi produce intelligence dovrebbe quindi anticipare l'emergere di famiglie di malware progettate nativamente per MQTT/AMQP, applicando fin da ora profilazione dei flussi e caccia proattiva sui broker non censiti, senza attendere che un'attribuzione formale confermi la minaccia.

MITRE ATT&CK: T1071.005 (Publish/Subscribe Protocols), tattica TA0011; software S0026 (GLOOXMAIL); mitigazioni M1031, M1037; detection DET0002 con analitiche AN0002–AN0005. Tool di detection e analisi citati: Sysmon, Wireshark, MQTT Explorer, osquery, auditd. In assenza di contenuti D3FEND recuperabili, le sezioni SOC e Forensic integrano conoscenza professionale di cybersecurity per comandi, tool e artefatti operativi.