BambooToken: When MQTT Becomes a Malware Command Channel

Aastha Thakker

10 minutes ago

5 min read

Keeping up with cybersecurity news every day is difficult. There is always a new CVE, malware campaign, data breach, attack technique, or security research report making the rounds. And with interview season going on, I have been spending more time revising concepts than keeping up with every single headline.

But recently, I came across the news about BambooToken, and the way it uses MQTT for command-and-control (C2) immediately caught my attention.

Some of you might have already heard about it. But if you haven’t, here is your sign to read about it. Because this is a good example of how attackers can take a technology normally associated with IoT and machine-to-machine communication and turn it into a C2 channel for malware targeting Windows and Linux systems.

What is BambooToken?

BambooToken is a previously undocumented malware framework analyzed by Lumen’s Black Lotus Labs. Researchers found evidence that it had been active since at least February 2023, with related activity observed as recently as July 2026. The campaign affected organizations across Asia and South America, with roughly a dozen compromised enterprise entities identified spanning mobile app companies, software developers, legal and financial services, hospitality, biomedical organizations, and cryptocurrency services. Researchers also found a compromised GitLab server in Hong Kong, which matters because development infrastructure can be a stepping stone toward source code, credentials, and downstream systems.

But who got hit wasn’t the interesting part. How the infected machines talked to the attacker was.

First, What Exactly is MQTT?

Before understanding BambooToken, we need to understand MQTT.

MQTT stands for Message Queuing Telemetry Transport.

It is a lightweight publish-subscribe protocol built for IoT and machine-to-machine communication. Devices don’t talk to each other directly; everything routes through a central broker. A publisher sends a message to a “topic,” and any device subscribed to that topic receives it.

A simplified MQTT architecture looks like this:

               MQTT Broker
             /     |      \
            /      |       \
        Device A Device B Device C
       Publisher Subscriber Subscriber

Instead of every device directly communicating with every other device, they communicate through a central MQTT broker. The communication revolves around topics.

For example:

home/temperaturehome/security/camerafactory/machine1/status

A device can subscribe to a topic:

factory/machine1/status

Another system can publish messages to that topic:

START

The subscribed device receives the message.

This publish-subscribe model is extremely useful for IoT because it is lightweight, asynchronous, and works well with many connected devices.

But there is another side to this.

If malware subscribes to a topic controlled by an attacker, that same architecture can become a command-and-control mechanism.

And that is essentially what makes BambooToken interesting.

Instead of:

sensor → broker → monitoring system

you can have:

Infected Host → publish(status) → MQTT Broker → publish(commands) ← Operator

And that is what makes BambooToken particularly interesting.

Why MQTT for C2?

Traditional malware usually reaches out over HTTP or HTTPS, connecting more or less directly to a C2 server. BambooToken instead has the infected machine subscribe to attacker-controlled topics on a broker. The operator publishes commands to those topics; the malware publishes stolen data back. This gives the attacker an asynchronous channel that doesn’t look like a direct connection to obvious C2 infrastructure.

The bigger reason MQTT is a smart choice, though, is that it hides in plain sight. Any organization already running IoT devices, industrial sensors, smart-building systems, or telemetry has legitimate MQTT traffic flowing across its network already. The protocol itself doesn’t scream “malware” the malicious use is buried inside normal-looking traffic. Which means the useful security question isn’t “is MQTT dangerous,” it’s “Why is this particular machine using MQTT, and what is it talking to?”

BambooToken has evolved

Early samples used a PowerShell-based stager that allocated memory and executed the payload directly. Later versions switched to DLL sideloading, placing a malicious DLL somewhere a legitimate, trusted application will load it automatically, instead of running an obviously suspicious executable.

Legitimate Application → loads DLL → expected DLL (missing)
                                    → malicious DLL loaded instead

Researchers found this technique used through Tendyron’s OnKey software, sideloaded via a rogue file named OnKeyToken_KEB.dll, and in samples impersonating the Kingsoft Office suite. One important clarification: researchers did not conclude that Tendyron's code-signing certificate or build environment was compromised. This is an attacker abusing how a legitimate app loads DLLs, not a signed-supply-chain breach. That distinction matters a lot when assessing how serious an incident actually is.

What can it actually do?

Once running, BambooToken collects system information and, on Windows, uses WMI to enumerate installed antivirus products, reconnaissance that helps the attacker understand the defensive environment before deciding what to do next.

Researchers also found strings referencing keylogging, clipboard theft, audio recording, webcam capture, and screenshots but these were in dead code. That’s an important distinction: code existing in a sample doesn’t prove it was ever deployed in an attack. Analysts couldn’t confirm these features were actively used, and it’s worth keeping “capability present” and “capability observed in the wild” as two separate claims rather than blurring them together.

There’s also a Linux variant, version 2.1, spotted in December 2025, still apparently under active development. It uses the same MQTT-based C2 and supports system info collection, spawning a shell, and uploading, downloading, or deleting files. Cross-platform reach means defenders can’t treat this as a Windows-only or IoT-only problem.

Now the Part I Find Most Interesting: SOC Detection

Reading a malware report is useful. But the better question for me is:

If BambooToken showed up in my environment, what would I actually look for? ( and this is what people ask in interview, right HRs? or experienced ppl?)

I wouldn’t start by blocking MQTT. That could easily break legitimate IoT or industrial systems.

I would build visibility instead: which hosts speak MQTT, to which brokers, over which ports, and how often. A sample correlated event might look like:

rundll32.exe loads OnKeyToken_KEB.dll
wmic.exe queries AntiVirusProduct
outbound MQTT connection → port 1883, unapproved external host

No single line here proves compromise. Stacked together on a host with no legitimate reason to speak MQTT, though, they form a strong hunting hypothesis. A basic detection logic might be:

IF   host = Windows OR Linux
AND  outbound MQTT to an unapproved/external broker
AND  host is not an authorized MQTT client
THEN raise investigation priority

+ suspicious DLL loading
+ WMI antivirus enumeration
+ unusual PowerShell or file transfer
→ escalate

This is where SIEM correlation becomes valuable. This is more resilient than blocklisting a single IP or domain, since attackers can rotate infrastructure far more easily than they can change the underlying behavior.

What Else Should Security Teams Monitor?

For environments where MQTT is legitimate, I would pay particular attention to:

Network telemetry

MQTT connections
External MQTT brokers
Unusual destination IPs
Unexpected ports
TLS vs non-TLS MQTT
New MQTT clients

Endpoint telemetry

DLL sideloading
Suspicious PowerShell
rundll32.exe activity
Unusual WMI queries
New DLLs next to trusted applications
Unexpected command shells

Identity and infrastructure

New service accounts
Suspicious authentication
Unusual access to GitLab or development servers
Unexpected file transfers
New persistence mechanisms

The important part is not collecting every possible event.

It is connecting the events that make sense together.

BambooToken itself isn’t really the point. The point is that legitimate protocols keep getting repurposed. We have already watched this happen with DNS, HTTP, cloud storage, and Git repositories. MQTT wasn’t designed to be dangerous; it’s just quiet and easy to blend into normal traffic. The useful lesson isn’t “watch out for MQTT” blocking it outright breaks real systems. It’s understanding what normal communication looks like in your own environment, so that unusual use of a familiar technology actually stands out when it matters.