First Seen External MQTT Broker Connection

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

First Seen External MQTT Broker Connection

edit

Identifies the first MQTT relationship from an internal source to an external broker that was not observed during the previous 14 days. This includes protocol-decoded MQTT and direct AWS IoT Core MQTT identified from TLS ClientHello metadata without decryption. 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.

Rule type: new_terms

Rule indices:

  • logs-network_traffic.tls-*
  • logs-panw.panos*
  • logs-suricata.eve-*
  • logs-zeek.connection-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Network
  • Domain: OT/IoT
  • Platform: AWS
  • Use Case: Network Security Monitoring
  • Use Case: Threat Detection
  • Tactic: Command and Control
  • Data Source: PAN-OS Logs
  • Data Source: Network Traffic
  • Data Source: Network Packet Capture
  • Data Source: Suricata Logs
  • Data Source: Zeek
  • Service: AWS IoT
  • Rule Type: New Terms
  • Resources: Investigation Guide

Version: 2

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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. The Network Packet Capture path recognizes direct AWS IoT Core MQTT inside TLS without decryption by using the client-offered ALPN x-amzn-mqtt-ca on TCP/443 or a default account-specific AWS IoT ATS SNI on TCP/8883. It does not expose MQTT client IDs, topics, commands, results, or file content.

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.ip belongs to an approved private or public MQTT broker. Review destination reputation, ASN, geolocation, passive DNS, and other internal clients communicating with it.
  • For Network Packet Capture TLS events, preserve tls.client.server_name exactly. On TCP/443, verify that tls.detailed.client_hello.extensions.application_layer_protocol_negotiation contains x-amzn-mqtt-ca. On TCP/8883, confirm that the SNI matches <account-specific-prefix>-ats.iot.<region>.amazonaws.com. Determine whether the source asset and complete endpoint are approved for AWS IoT use.
  • For Suricata events, inspect suricata.eve.mqtt for 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. A Global publication containing online or offline status and a gid increases 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 nearby OnKeySrv.dat or OnKeySvr.dat files.

False positive analysis

  • Confirm newly deployed or intermittently active IoT, telemetry, messaging, and monitoring applications with the asset owner.
  • Validate broker migrations, AWS IoT device onboarding, 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.

Setup

edit

Setup

This rule requires one or more of the following integrations:

  • Network Packet Capture with TLS parsing on TCP ports 443 and 8883 and include_detailed_fields: true.
  • Suricata with the MQTT application-layer parser and MQTT EVE output enabled.
  • Zeek connection logs with the MQTT analyzer enabled so network.protocol is populated with mqtt.
  • PAN-OS traffic logs with App-ID enabled and MQTT identified as mqtt-base.

Place network sensors where they observe client-to-broker traffic before source NAT so internal client addresses remain visible. Suricata and Zeek must observe plaintext MQTT or receive decrypted traffic. PAN-OS must identify the session with the MQTT App-ID; without decryption, generic MQTT over TLS may only be identified as SSL.

The Network Packet Capture AWS IoT path does not require TLS decryption. It requires SNI in tls.client.server_name and, for TCP/443, client-offered ALPN in tls.detailed.client_hello.extensions.application_layer_protocol_negotiation. Encrypted ClientHello can hide SNI, and custom AWS IoT domains on TCP/8883 do not match the default ATS hostname pattern.

Rule query

edit
(
  data_stream.dataset:suricata.eve and
  suricata.eve.event_type:mqtt and
  network.protocol:mqtt or
  data_stream.dataset:zeek.connection and
  network.protocol:mqtt or
  data_stream.dataset:panw.panos and
  network.application:mqtt-base or
  data_stream.dataset:network_traffic.tls and
  tls.established:true and
  tls.client.server_name:* and
  (
    destination.port:443 and
    tls.detailed.client_hello.extensions.application_layer_protocol_negotiation:"x-amzn-mqtt-ca" or
    destination.port:8883 and
    tls.client.server_name:(
      *-ats.iot.*.amazonaws.com or
      *-ats.iot.*.amazonaws.com. or
      *-ats.iot.*.amazonaws.com.cn or
      *-ats.iot.*.amazonaws.com.cn.
    )
  )
) and
  network.transport:tcp and
  source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16 or "FC00::/7") and
  destination.ip:(
    * and not (
      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
      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
      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
      192.31.196.0/24 or 192.52.193.0/24 or 192.88.99.0/24 or 198.18.0.0/15 or
      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
      "FC00::/7" or "FE80::/10" or "FF00::/8"
    )
  ) and
  not (
    data_stream.dataset:panw.panos and (
      event.action:(flow_denied or flow_dropped) or
      network.application:(incomplete or insufficient-data or not-applicable)
    )
  )

Framework: MITRE ATT&CKTM