First Seen External MQTT Broker Connection
Identifies the first MQTT relationship from an internal source to an external broker that was not observed during the previous 14 days. MQTT is commonly used by IoT and messaging applications, but malware including BambooToken, IOCONTROL, MQsTTang, and WailingCrab has used publish/subscribe traffic for command and control.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/09/16"
3integration = ["panw", "suricata", "zeek"]
4maturity = "production"
5updated_date = "2026/09/16"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies the first MQTT relationship from an internal source to an external broker that was not observed during the
11previous 14 days. MQTT is commonly used by IoT and messaging applications, but malware including BambooToken, IOCONTROL,
12MQsTTang, and WailingCrab has used publish/subscribe traffic for command and control.
13"""
14false_positives = [
15 """
16 New or infrequently used IoT devices, telemetry agents, application messaging services, test environments, and
17 broker migrations can create legitimate first-seen relationships. Sensor onboarding or retention gaps can also cause
18 existing relationships to appear new.
19 """,
20]
21from = "now-9m"
22index = ["logs-panw.panos*", "logs-suricata.eve-*", "logs-zeek.connection-*"]
23interval = "5m"
24language = "kuery"
25license = "Elastic License v2"
26name = "First Seen External MQTT Broker Connection"
27note = """## Triage and analysis
28
29### Investigating First Seen External MQTT Broker Connection
30
31MQTT uses a broker to relay messages between publishers and subscribers. This architecture is useful for legitimate IoT
32and application messaging, but it also allows malware to receive commands and return results without connecting directly
33to an operator. This rule surfaces the first protocol-decoded or application-identified MQTT relationship between an
34internal source and an external destination within the 14-day new-terms history window.
35
36The alert does not prove malicious command and control. Suricata and Zeek require plaintext MQTT or traffic decrypted
37before inspection. PAN-OS coverage depends on App-ID identifying the traffic as `mqtt-base`; encrypted sessions may only
38be identified as SSL when decryption is unavailable.
39
40### Possible investigation steps
41
42- Identify the asset, owner, operating system, and expected role of `source.ip`. MQTT from servers, workstations, routers,
43 firewalls, build systems, and other assets that are not approved MQTT clients warrants additional scrutiny.
44- Determine whether `destination.ip` belongs to an approved private or public MQTT broker. Review destination reputation,
45 ASN, geolocation, passive DNS, and other internal clients communicating with it.
46- For Suricata events, inspect `suricata.eve.mqtt` for CONNECT client IDs, credentials, subscribed topics, published
47 topics, payloads, keepalive values, and broker response codes. Review equivalent protocol details in the originating
48 network sensor when available.
49- Look for GUID- or UUID-scoped topics and BambooToken-associated suffixes such as `/Plugin`, `/removePlugin`,
50 `/unPlugin`, and `/LUA`. A `Global` publication containing `online` or `offline` status and a `gid` increases confidence.
51- Review the connection duration, reconnect cadence, bytes transferred, and additional ports contacted on the
52 destination. BambooToken infrastructure has included TCP ports 1883, 2883, and 8883.
53- Correlate with endpoint telemetry for unexpected MQTT-capable processes, DLL side-loading, shell execution, discovery,
54 file transfer, or persistence. For BambooToken, investigate `OnKeySrv.exe`, `OnKeyToken_KEB.dll`, and nearby
55 `OnKeySrv.dat` or `OnKeySvr.dat` files.
56
57### False positive analysis
58
59- Confirm newly deployed or intermittently active IoT, telemetry, messaging, and monitoring applications with the asset
60 owner.
61- Validate broker migrations, disaster-recovery tests, development environments, and vendor-managed services.
62- Scope exceptions to an approved source asset and broker pair where possible. Avoid excluding all MQTT traffic or an
63 entire public broker globally.
64
65### Response and remediation
66
67- Isolate the source if the process, topic structure, payload, or destination indicates command and control.
68- Block unauthorized broker access and preserve MQTT transactions, flow metadata, DNS history, and endpoint process
69 evidence.
70- Remove confirmed malware and persistence, rotate credentials available to the affected system, and search for the same
71 client ID, topic hierarchy, destination, and artifacts across the environment.
72- Establish an inventory of approved MQTT clients, brokers, ports, and topic prefixes, and restrict outbound MQTT where
73 operationally feasible.
74"""
75references = [
76 "https://www.lumen.com/blog/en-us/the-banana-stand-brokering-and-managing-infections-across-asia-using-mqtt",
77 "https://docs.suricata.io/en/latest/output/eve/eve-json-format.html#event-type-mqtt",
78 "https://www.elastic.co/docs/reference/integrations/suricata",
79 "https://docs.zeek.org/en/current/scripts/base/protocols/mqtt/main.zeek.html",
80 "https://www.elastic.co/docs/reference/integrations/zeek",
81 "https://www.elastic.co/docs/reference/integrations/panw",
82]
83risk_score = 47
84rule_id = "b6e05109-768e-4673-bc7b-6760912eb704"
85setup = """## Setup
86
87This rule requires one or more of the following integrations:
88
89- Suricata with the MQTT application-layer parser and MQTT EVE output enabled.
90- Zeek connection logs with the MQTT analyzer enabled so `network.protocol` is populated with `mqtt`.
91- PAN-OS traffic logs with App-ID enabled and MQTT identified as `mqtt-base`.
92
93Place network sensors where they observe client-to-broker traffic before source NAT so internal client addresses remain
94visible. Suricata and Zeek must observe plaintext MQTT or receive decrypted traffic. PAN-OS must identify the session with
95the MQTT App-ID; without decryption, MQTT over TLS may only be identified as SSL.
96"""
97severity = "medium"
98tags = [
99 "Domain: Network",
100 "Use Case: Network Security Monitoring",
101 "Use Case: Threat Detection",
102 "Tactic: Command and Control",
103 "Data Source: PAN-OS Logs",
104 "Data Source: Suricata Logs",
105 "Data Source: Zeek",
106 "Rule Type: New Terms",
107 "Resources: Investigation Guide",
108]
109timestamp_override = "event.ingested"
110type = "new_terms"
111
112query = '''
113(
114 data_stream.dataset:suricata.eve and
115 suricata.eve.event_type:mqtt and
116 network.protocol:mqtt or
117 data_stream.dataset:zeek.connection and
118 network.protocol:mqtt or
119 data_stream.dataset:panw.panos and
120 network.application:mqtt-base
121) and
122 network.transport:tcp and
123 source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16 or "FC00::/7") and
124 destination.ip:(
125 * and not (
126 10.0.0.0/8 or 100.64.0.0/10 or 127.0.0.0/8 or 169.254.0.0/16 or 172.16.0.0/12 or
127 192.0.0.0/24 or 192.0.0.0/29 or 192.0.0.10/32 or 192.0.0.170/32 or 192.0.0.171/32 or
128 192.0.0.8/32 or 192.0.0.9/32 or 192.0.2.0/24 or 192.168.0.0/16 or 192.175.48.0/24 or
129 192.31.196.0/24 or 192.52.193.0/24 or 192.88.99.0/24 or 198.18.0.0/15 or
130 198.51.100.0/24 or 203.0.113.0/24 or 224.0.0.0/4 or 240.0.0.0/4 or "::1" or
131 "FC00::/7" or "FE80::/10" or "FF00::/8"
132 )
133 ) and
134 not (
135 data_stream.dataset:panw.panos and (
136 event.action:(flow_denied or flow_dropped) or
137 network.application:(incomplete or insufficient-data or not-applicable)
138 )
139 )
140'''
141
142
143[[rule.threat]]
144framework = "MITRE ATT&CK"
145[[rule.threat.technique]]
146id = "T1071"
147name = "Application Layer Protocol"
148reference = "https://attack.mitre.org/techniques/T1071/"
149[[rule.threat.technique.subtechnique]]
150id = "T1071.005"
151name = "Publish/Subscribe Protocols"
152reference = "https://attack.mitre.org/techniques/T1071/005/"
153
154
155
156[rule.threat.tactic]
157id = "TA0011"
158name = "Command and Control"
159reference = "https://attack.mitre.org/tactics/TA0011/"
160
161[rule.investigation_fields]
162field_names = [
163 "@timestamp",
164 "source.ip",
165 "source.port",
166 "destination.ip",
167 "destination.port",
168 "destination.as.organization.name",
169 "network.protocol",
170 "network.transport",
171 "network.application",
172 "network.community_id",
173 "data_stream.dataset",
174 "observer.name",
175]
176
177[rule.new_terms]
178field = "new_terms_fields"
179value = ["source.ip", "destination.ip"]
180[[rule.new_terms.history_window_start]]
181field = "history_window_start"
182value = "now-14d"
Triage and analysis
Investigating First Seen External MQTT Broker Connection
MQTT uses a broker to relay messages between publishers and subscribers. This architecture is useful for legitimate IoT and application messaging, but it also allows malware to receive commands and return results without connecting directly to an operator. This rule surfaces the first protocol-decoded or application-identified MQTT relationship between an internal source and an external destination within the 14-day new-terms history window.
The alert does not prove malicious command and control. Suricata and Zeek require plaintext MQTT or traffic decrypted
before inspection. PAN-OS coverage depends on App-ID identifying the traffic as mqtt-base; encrypted sessions may only
be identified as SSL when decryption is unavailable.
Possible investigation steps
- Identify the asset, owner, operating system, and expected role of
source.ip. MQTT from servers, workstations, routers, firewalls, build systems, and other assets that are not approved MQTT clients warrants additional scrutiny. - Determine whether
destination.ipbelongs to an approved private or public MQTT broker. Review destination reputation, ASN, geolocation, passive DNS, and other internal clients communicating with it. - For Suricata events, inspect
suricata.eve.mqttfor CONNECT client IDs, credentials, subscribed topics, published topics, payloads, keepalive values, and broker response codes. Review equivalent protocol details in the originating network sensor when available. - Look for GUID- or UUID-scoped topics and BambooToken-associated suffixes such as
/Plugin,/removePlugin,/unPlugin, and/LUA. AGlobalpublication containingonlineorofflinestatus and agidincreases confidence. - Review the connection duration, reconnect cadence, bytes transferred, and additional ports contacted on the destination. BambooToken infrastructure has included TCP ports 1883, 2883, and 8883.
- Correlate with endpoint telemetry for unexpected MQTT-capable processes, DLL side-loading, shell execution, discovery,
file transfer, or persistence. For BambooToken, investigate
OnKeySrv.exe,OnKeyToken_KEB.dll, and nearbyOnKeySrv.datorOnKeySvr.datfiles.
False positive analysis
- Confirm newly deployed or intermittently active IoT, telemetry, messaging, and monitoring applications with the asset owner.
- Validate broker migrations, disaster-recovery tests, development environments, and vendor-managed services.
- Scope exceptions to an approved source asset and broker pair where possible. Avoid excluding all MQTT traffic or an entire public broker globally.
Response and remediation
- Isolate the source if the process, topic structure, payload, or destination indicates command and control.
- Block unauthorized broker access and preserve MQTT transactions, flow metadata, DNS history, and endpoint process evidence.
- Remove confirmed malware and persistence, rotate credentials available to the affected system, and search for the same client ID, topic hierarchy, destination, and artifacts across the environment.
- Establish an inventory of approved MQTT clients, brokers, ports, and topic prefixes, and restrict outbound MQTT where operationally feasible.
References
Related rules
- Deprecated TLS Version or Weak Cipher Negotiated Externally
- Potential ICMP Tunneling Activity to the Internet
- Newly Observed IPSEC NAT Traversal Peer
- SMB (Windows File Sharing) Activity from the Internet
- SMB (Windows File Sharing) Activity to the Internet