Three years. That is the dwell window now sitting on BambooToken, a malware family that has been steering Windows and Linux hosts over MQTT since at least February 2023. If your cybersecurity program still files MQTT under plant telemetry, you have been hosting a command channel while calling it uptime.

The campaign, documented by researchers this week, has hit organizations across Asia and South America. Operators did not need a noisy HTTP beacon or a fresh zero-day on your edge. They needed you to keep 1883 or 8883 open to a broker that looked like a sensor feed.

Your threat detection still lights up on brute-force sprays and odd user-agents. This traffic never qualifies. It looks like keepalives. It behaves like a remote shell with better manners.

MQTT Keepalives Break the Cybersecurity Model You Funded

Most firewall policies treat MQTT as plumbing. OT asked for it. Facilities asked for it. A vendor dropped a broker on a VLAN and walked away. The allow rule aged into background radiation, and nobody put a name on the clients.

BambooToken’s trick is architectural. MQTT is publish and subscribe. The implant does not have to hit a domain your sinkhole already hates. It connects to a broker, waits on a topic, and takes work like any other client. A threat-protection stack tuned for inbound scans and failed logons has almost nothing to latch onto.

Researchers assess BambooToken as active since at least February 2023, used against organizations in Asia and South America, with MQTT as the control channel for both Windows and Linux.

You already give DNS and NTP the same shrug. Something legitimate needs the port, so the exception becomes policy. Defense in depth on the slide deck still collapses to “we allowed what the plant needs.” An attacker who lives inside that exception inherits your availability argument as cover.

Dual-OS reach is the part that should change your week. One family, Windows and Linux, same broker logic. An incident response runbook that opens on the Windows EDR console leaves the Linux jump box running the same implant. Your cyber security tooling split by platform is a gift to anyone who standardized on MQTT.

Host-level ipban against SSH and RDP noise is still worth running. It will not notice a client that authenticated once to a broker and never failed a login again. Quiet success is the whole design.

Treat Every Broker as a Command Server or Lose the Timeline

Do the ugly inventory this week. MQTT is not a Q4 project, and security hardening here is the same work you already claim to do for VPN concentrators and jump hosts.

• List every host that speaks MQTT, including printers, cameras, building controllers, lab gear, and “temporary” vendor brokers that never left.
• Default-deny TCP 1883 and 8883 at site boundaries. Allow only named clients to named brokers, with source and destination both in the ticket.
• Kill anonymous auth. Require TLS, unique credentials or certificates per client, and topic ACLs that cannot publish to command topics from a sensor identity.
• Ship broker logs, client IDs, topic names, and connect/disconnect events into the same SIEM path you use for VPN. Alert on a new client ID, a client that starts publishing after months of subscribe-only, and any workstation or server that suddenly speaks MQTT.
• Assume a hit is dual-OS until proven otherwise. Isolate the Windows box and the Linux box that share the broker, then rotate broker secrets the way you rotate a stolen VPN.

Immediate actions are blunt. Snapshot broker ACLs before anyone “cleans up.” Capture the retained messages; MQTT’s retained flag is a free persistence trick. Pull process lists and autoruns on every MQTT client, not only the ones EDR already likes. If you find an unexpected publisher, treat that identity as C2 infrastructure and start containment from the broker outward.

Ongoing work is dull on purpose. Re-approve MQTT exceptions every quarter with an owner who can lose the access. Watch for new listeners on 1883/8883 inside east-west space. Add MQTT to tabletop incident response so the Linux admin and the Windows admin are in the same room. Defense in depth means the broker is a production command server in your model, even when the vendor brochure says telemetry.

You do not need a new product category to do this. You need names on flows, deny-by-default at the edge, and detections that fire on protocol misuse instead of waiting for a malware family name.

Unnamed Boot Traffic Trains You to Ignore C2

On the same day BambooToken’s MQTT path hit the wires, SANS published a first-boot look at macOS 27 “Golden Gate”: traffic a system generates before anyone logs in. The useful point is not that Apple phones home. A clean OS already starts conversations you never approved by name.

If you cannot list that chatter, you will not list an MQTT client either. Baseline unnamed traffic or three years of broker keepalives become the default, and your SOC learns to scroll past it.

BambooToken lasts because allowed noise is cheap cover. Name the brokers. Name the clients. Put MQTT in the same mental bucket as remote access. The protocol already gave someone a three-year lease on both of your fleets.

Sources

• BambooToken Malware Uses MQTT to Control Windows and Linux Systems
• MacOS 27 – First Boot