« First Occurrence of User-Agent For a GitHub User First Seen Network Flow Exporter »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

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. 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-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
  • Use Case: Network Security Monitoring
  • Use Case: Threat Detection
  • Tactic: Command and Control
  • Data Source: PAN-OS Logs
  • Data Source: Suricata Logs
  • Data Source: Zeek
  • Rule Type: New Terms
  • Resources: Investigation Guide

Version: 1

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; 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.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 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, 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:

  • 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, MQTT over TLS may only be identified as SSL.

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
) 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

« First Occurrence of User-Agent For a GitHub User First Seen Network Flow Exporter »