The implant never connected to the attacker

At the bottom of Lumen’s report on BambooToken is an indicator list, and the command and control servers are given with their ports [1]. Three of them are tagged MQTT: 1883, 8883, and 2883.

I looked the numbers up, because two of them I recognised and one I did not.

IANA assigns 2883 to an unrelated service [2]. The malware runs MQTT on it anyway, which is entirely allowed, because a port registration is a convention and not a constraint. That small mismatch is the practical half of this story. The other half is stranger, and it is that the infected machines in this campaign never connected to the attacker at all.

What happened

On September 15, 2026, Lumen’s Black Lotus Labs published research on a malware family it named BambooToken, found as an undocumented sample uploaded to VirusTotal in early 2026 [1]. Working backwards from it, the team dated the framework to at least February 2023 and tracked activity through July 2026 [1].

Lumen’s telemetry put roughly a dozen compromised enterprise estates in Asia and South America: backend servers for several mobile applications, a GitLab server in Hong Kong, a Vietnamese company building a portable lifestyle device, a hotel in Vietnam, a biomedical company in Argentina, a legal firm in Chile, a cryptocurrency website in Lithuania, and a finance organisation in Malaysia [1].

The interesting part is how the malware changed.

The February 2023 version spoke HTTP, the way most implants do. By the 2024 and 2025 builds it had moved its command channel onto MQTT, and a Linux build first seen in December 2025 uses MQTT with a wider set of topics [1]. So this is a family that had a working command channel and deliberately replaced it.

MQTT is a publish and subscribe protocol, built for telemetry between devices and controllers. Nothing sends a message to anything directly. Publishers send to a named topic on a central broker, subscribers receive from that topic, and the broker sits between them [1]. IANA registers it on 1883, with the TLS variant on 8883 [2].

Applied to an implant, that architecture has an effect Lumen names plainly: the compromised machine never communicates directly with the C2 server [1].

Why this matters

Most command and control detection assumes a link that broker-based C2 deletes.

Think about what the standard approaches actually key on. Reputation blocking needs a destination the attacker owns. Beacon analysis needs a repeating conversation with one suspicious endpoint. Threat intelligence feeds distribute attacker infrastructure so you can match against it. Domain age and registration heuristics assume the attacker registered something. Every one of those is looking for a connection between the victim and the adversary.

In publish and subscribe there is no such connection. The victim connects to a broker. The operator connects to a broker. Both of those are ordinary outbound sessions to a piece of messaging infrastructure, and the two parties never appear in the same flow record.

Takedown gets harder in the same way. Seizing a C2 domain removes the attacker’s control plane. A broker is a different proposition, because it is generic infrastructure and because in this campaign the domains sat behind Cloudflare as a proxy [1].

There is a second-order problem worth naming. One of the C2 domains reached Cloudflare Radar’s top 500,000 domains in December 2025, and the older one was in the top million at the peak of the earlier campaign [1]. Popularity rankings get used as a reputation input on the reasonable theory that widely visited domains are usually legitimate. A domain with enough infected hosts checking into it earns that ranking honestly.

Technical breakdown

The enterprise intrusions run like this. Lumen describes a second, separate cluster of small network devices reached by internet scanning, which I have kept out of the chain below rather than fuse two different entry routes into one picture.

The topics are the addressing

Each agent embeds a GUID and subscribes to a small set of topics built from it, alongside a global broadcast topic used to reach every implant at once [1]. The Windows build subscribes to four, the later Linux build to five [1].

That structure is worth understanding because it explains the operator’s ergonomics. Publishing to the global topic reaches the whole estate. Publishing to a GUID-scoped topic reaches exactly one host. The operator needs no inbound connectivity to the victim and no port open on the victim side, and Lumen notes the broker must approve a subscription before the subscriber receives anything, which keeps casual observers out of the channel [1].

Asynchrony matters too. A host that is offline when a command is published can receive it later, so a network outage or a laptop lid does not cost the operator the session.

The side-loading, stated precisely

The phrase supply chain attaches itself to this campaign easily, and the report uses it in one sense while ruling out another. The two lead to different remediation, so they are worth separating.

Lumen states it does not assess that Tendyron’s code-signing certificate or build environment was compromised, and that the actor appears to be abusing a file vulnerable to side-loading which is likely to be present natively in targeted networks [1]. A second variant masquerading as a Chinese office software vendor fails certificate signature validation outright, which means the certificate was not used to sign the malicious components [1]. The Hacker News reported the same distinction from the same research [4]. No supplier was breached to deliver this.

What the report does raise is reach at the victim end. The compromised estate included a GitLab server, a software development company and several mobile application backends [1]. Those organisations are suppliers to other organisations, which is a real concern and a different one.

MITRE files this behaviour under T1574.001, and its description of why it works is the clearest one available: side-loading masks actions performed under a legitimate, trusted and potentially elevated process, and the benign executable used to load the payload may not be flagged during delivery or execution [3]. The mitigations that page lists are the ones worth budgeting for, chiefly restricting library loading and execution prevention [3].

A small aside for anyone citing this technique in a report. MITRE has consolidated its DLL sub-techniques, and T1574/002, the ID many write-ups still use for side-loading, now redirects to T1574.001 [3].

What a missed compiler flag gave away

The detail I liked most is a mistake. Lumen found a sample where the developer had not set the compilation flags that strip unused code, leaving strings in the binary that name capabilities absent from the executing code: a keylogger, a clipboard grabber, audio recording, and webcam and desktop capture [1].

None of that runs in the analysed samples. It tells you what the toolkit is for anyway, which is surveillance rather than immediate theft, and that fits the victim profile better than the current feature set does.

Set against that, the same actor forged PE header metadata claiming a Windows Server 2003 and Visual Studio 2005 build environment, and deliberately varied the compilation timestamps rather than fixing them to one value, because a constant would itself have become a signature [1]. Careful about the thing that gets fingerprinted, careless about the linker settings.

What defenders should do Monday morning

Immediate, today. Ask whether MQTT should ever leave your network. For most enterprises with no IoT estate the answer is no, and that makes it one of the cheapest high quality detections available: any outbound MQTT is an incident. Check what your egress filtering does with 1883, 8883 and 2883, and then check whether your tooling identifies the protocol or only matches the port, because this campaign used one port that is not registered to MQTT at all [1][2].

Near term, this week. Hunt for the side-loading pattern rather than the sample. Look for signed vendor executables loading DLLs that are unsigned, or that do not appear in your software inventory, from directories a user can write to. That query finds this campaign and it finds the next one, which is the point of writing it against behaviour instead of a filename, a habit covered in detect the behaviour, not the tool name.

Structural, this quarter. Audit where your C2 detection gets its confidence. If the honest answer is mostly reputation feeds and known-bad infrastructure, you are covered against adversaries who own their endpoints and uncovered against anyone who rents a middleman. Add at least one detection that keys on protocol and volume rather than destination, and make sure large egress gets reviewed even when the destination sits in your own region, which Lumen specifically calls out [1].

Checklist

• Outbound MQTT decision made and written down: permitted, or an incident.
• Egress rules cover 1883, 8883 and non-standard ports, by protocol identification.
• Hunt shipped for signed binaries loading unsigned or unknown DLLs.
• Library loading restricted where the platform supports it, MITRE M1044.
• Alerting on WMI enumeration of installed antivirus products.
• Large outbound transfers reviewed regardless of destination geography.
• At least one C2 detection that does not depend on destination reputation.
• Indicators from the Lumen report ingested, with the caveat that they age.

The detection model aged before the malware did

BambooToken is not a sophisticated implant by the standards of the field. It enumerates a host, spawns a shell, and moves files. The 2023 version did all of that over HTTP.

What changed is the transport, and that single change quietly invalidates a category of defence. We have spent a decade building detection around the idea that an infected machine eventually talks to something the adversary controls, and treating the discovery of that endpoint as the win condition. Broker-based C2 does not defeat that idea cleverly. It sidesteps it, by arranging for the adversary’s endpoint never to appear in the victim’s traffic at all.

The uncomfortable part is that the fix has been sitting in plain sight and is unglamorous. An enterprise with no IoT estate should never see MQTT leave its network, and almost nobody alerts on it, because nobody wrote the rule for a protocol they had no reason to think about. Three prior campaigns have used MQTT for C2 [1]. This is the fourth, and it will not be the last, because the technique’s advantage is structural rather than clever.

Go and find out what your perimeter does with port 1883 this week. The answer takes ten minutes and you will either be reassured or you will have found something.