Detect Publish/Subscribe Protocols in Elastic Security
Adversaries may communicate using publish/subscribe (pub/sub) application layer protocols to avoid detection/network filtering by blending in with existing traffic. Commands to the remote system, and often the results of those commands, will be embedded within the protocol traffic between the client and server. Protocols such as MQTT, XMPP, AMQP, and STOMP use a publish/subscribe design, with message distribution managed by a centralized broker. Publishers categorize their messages by topics, while subscribers receive messages according to their subscribed topics. An adversary may abuse publish/subscribe protocols to communicate with systems under their control from behind a message broker while also mimicking normal, expected traffic.
MITRE ATT&CK
- Tactic
- Command and Control
- Technique
- T1071 Application Layer Protocol
- Sub-technique
- T1071.005 Publish/Subscribe Protocols
- Canonical reference
- https://attack.mitre.org/techniques/T1071/005/
Elastic Detection Query
network where event.action == "connection_attempted" and
destination.port in (1883, 8883, 5222, 5223, 5269, 5672, 5671, 61613, 61614) and
not cidrmatch(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8") and
not (
destination.port in (1883, 8883) and
process.name in~ ("mosquitto", "mosquitto_pub", "mosquitto_sub", "mosquitto.exe")
)Detects outbound network connections to publish/subscribe protocol ports (MQTT 1883/8883, XMPP 5222/5223/5269, AMQP 5672/5671, STOMP 61613/61614) targeting external IP addresses. Excludes known-legitimate MQTT broker clients. Because EQL operates per-event, pair this rule with an ES|QL aggregation (groupBy host.name, process.name, destination.port, count > 1) to suppress single-packet noise; the EQL rule fires on each qualifying connection for real-time alerting while the aggregation query handles threshold-based hunting.
Data Sources
Required Tables
False Positives & Tuning
- IoT gateway software or home-automation platforms (Home Assistant, Node-RED, openHAB) legitimately using MQTT on 1883/8883 for device telemetry — scope-exclude those hosts or add their processes to the allowlist
- Enterprise and open-source XMPP chat clients (Pidgin, Psi+, Spark, Gajim) connecting to corporate or cloud-hosted Jabber/XMPP servers on port 5222
- Microservice middleware (RabbitMQ client libraries, Celery workers, Pika, aio-pika) making AMQP connections on 5672/5671 to legitimate cloud message brokers such as CloudAMQP or Azure Service Bus
Other platforms for T1071.005
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1MQTT C2 Publish Simulation
Expected signal: Sysmon for Linux Event ID 3: Network connection from mosquitto_pub to 127.0.0.1:1883. Process creation event for mosquitto_pub with topic name 'c2/beacon' and system data in the message payload.
- Test 2XMPP C2 Connection Simulation
Expected signal: Sysmon for Linux Event ID 3: Network connection from nc to 127.0.0.1:5222. Process creation event for nc with XMPP XML stanza in piped input.
- Test 3MQTT Subscribe for Commands Simulation
Expected signal: Sysmon for Linux Event ID 3: Network connection from mosquitto_sub to 127.0.0.1:1883. Long-lived connection (up to 10 seconds) as the client waits for messages on the 'c2/commands/#' wildcard topic.
References (6)
- https://attack.mitre.org/techniques/T1071/005/
- https://securityintelligence.com/x-force/wailingcrab-malware-misues-mqtt-messaging-protocol/
- https://www.mandiant.com/sites/default/files/2021-09/mandiant-apt1-report.pdf
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1071.005/T1071.005.md
- https://mqtt.org/
- https://xmpp.org/
Unlock Pro Content
Get the full detection package for T1071.005 including response playbook, investigation guide, and atomic red team tests.