As reported by SecurityAffairs, Lumen's Black Lotus Labs has uncovered BambooToken, a multiplatform malware family that has been quietly operating since February 2023. What sets this threat apart is its use of MQTT — a protocol designed for IoT and industrial telemetry — as a command-and-control channel. This is not a trivial design choice, and it carries implications that extend well beyond the immediate campaign.
Why MQTT Changes the Detection Equation
Most malware C2 detection strategies are built around identifying direct, synchronous connections between infected hosts and attacker-controlled servers. Traditional indicators — beaconing intervals, suspicious domains, TLS anomalies — assume a point-to-point communication model. MQTT shatters that assumption.
The publish/subscribe architecture introduces a broker as an intermediary. The compromised host never touches the actual C2 infrastructure directly. From a network forensics perspective, the traffic looks like legitimate IoT telemetry, especially in environments where MQTT is already in use — manufacturing floors, smart building systems, and increasingly, cloud-native microservices architectures.
The broker-mediated, asynchronous nature of MQTT means an infected host can disappear for hours, reconnect, and resume its session — all without triggering connection-based alerting that expects regular heartbeat patterns.
Who Is Most Exposed
Organizations in the following categories face elevated risk from BambooToken and copycat threats that will inevitably follow:
The Broader Trend: Protocol Abuse as Evasion
BambooToken joins a short but growing list of malware — IOCONTROL, Korplug, and WailingCrab — that have recognized the evasion value of legitimate messaging protocols. This is part of a broader shift where threat actors are moving away from custom C2 infrastructure toward abusing protocols that defenders are reluctant to block or inspect deeply. We have seen this with DNS, ICMP, and now MQTT. Expect WebSocket, AMQP, and gRPC to follow.
The three-year undetected operational window is itself a warning. BambooToken was not caught by automated sandboxing or signature-based AV. It was found through proactive threat hunting on VirusTotal. This underscores that detection of novel C2 channels requires human-driven hypothesis testing, not just automated tooling.
Shield53 Recommendations
- Inventory MQTT usage: Identify all legitimate MQTT brokers and traffic patterns in your environment. You cannot detect anomalous MQTT if you do not know what normal looks like.
- Implement MQTT traffic inspection: Deploy deep packet inspection for MQTT traffic, especially outbound connections to external brokers. Flag unexpected topic subscriptions and payloads that do not match expected telemetry formats.
- Restrict outbound MQTT: At the network perimeter, block outbound MQTT (TCP 1883, 8883) unless explicitly required. For legitimate use cases, enforce allowlists of approved broker endpoints.
- Hunt for sideloading artifacts: BambooToken uses DLL sideloading for initial execution. Monitor for legitimate signed binaries loading unsigned DLLs from writable directories. Focus on common sideloading targets like system utilities and installed software.
- Develop MQTT-specific detection rules: Create SIEM and EDR rules that flag: processes initiating MQTT connections that are not known IoT clients, unusual topic naming patterns, and subscription bursts from single hosts.
- Prioritize threat hunting over waiting for alerts: If BambooToken evaded detection for three years, assume similar threats are resident in your network today. Establish recurring hunting cadences focused on protocol-abuse hypotheses.
The takeaway for security leaders is structural: your detection strategy must account for threats that deliberately operate inside your blind spots. MQTT is one such blind spot today. The next protocol-abusing malware family is already being built — the question is whether your monitoring architecture will see it.