Rapid7 Labs has disclosed a previously undocumented Linux implant embedded directly inside the trojanized HAProxy binaries of two South Korean organizations — one in the automotive sector and one in media. The attackers named the implant “ted” in debug strings left in the binary. It is not a vulnerability in HAProxy itself; deploying it requires the attacker to already have code execution on the host and the ability to replace the running HAProxy binary. Rapid7 attributes the toolkit with medium confidence to North Korean state-sponsored actors, drawing on overlapping infrastructure and delivery patterns linked to APT37, Lazarus, and Kimsuky — three clusters whose tooling and targeting Mandiant has previously described as overlapping.
The implant is engineered to be invisible at the network layer. A specially crafted request for a specific image path puts the filter into command-and-control mode. The ted implant decrements HAProxy’s own live connection counters, dropping the connection from the load balancer’s statistics. Command output returns on the raw socket under a standard HTTP/1.0 200 OK header, making the exchange look like ordinary web traffic to any external observer. Neither backend logs nor the load balancer’s statistics record the C2 exchange. Through this channel, the operator can beacon, upload and download files, run shell commands, and update the implant’s configuration. A companion remote access trojan Rapid7 calls curlRAT beacons every 12 hours by default, switching to 30-second intervals when the operator sets a flag, and aborts unless it finds a marker file confirming the host is virtualized. The six command-and-control domains identified in the report all return NXDOMAIN as of September 4, making them useful for reviewing historical logs rather than for blocking live traffic. Rapid7 hypothesizes the attackers gained initial access through an exposed Groupware portal — a class of Korean enterprise collaboration software — consistent with documented Kimsuky methods, but does not have direct forensic evidence of the entry point.
How to check if you’re affected
Affected versions include HAProxy 2.8.12 on Linux — both victims ran exactly that release. The implant’s code reads HAProxy’s internal structures at offsets fixed to that build, so it does not automatically work on other versions. Upgrading HAProxy does not clean a host the implant already sits on, because the attackers replace the binary rather than exploit a flaw in it. To check: compare the SHA-256 hash of your running HAProxy binary against the official HAProxy release hash for 2.8.12. A recompiled trojanized HAProxy reports the same version string as a clean build, so version output alone is not sufficient. Also review historical DNS and network logs for the six IOC domains listed in the Rapid7 report, and look for unusual file paths under /tmp associated with named-pipe activity.