'Ted' Backdoor Found Baked Into HAProxy Builds at Two South Korean Firms

Key points

• Researchers found a new Linux backdoor, nicknamed "ted" after debug strings in the binary, hidden inside the HAProxy load balancers of two South Korean organisations.
• The implant was compiled directly into HAProxy, the popular open-source software that spreads website traffic across servers, so it ran with the same trust as the load balancer itself.
• It could read web traffic passing through and serve altered pages to specific visitors picked by the attackers.
• This is not a flaw in HAProxy. The attackers already had deep access to the machines before planting it.
• Affected organisations should rebuild HAProxy from clean source and hunt for how the attackers got root access in the first place.

A quiet but nasty piece of Linux malware has turned up inside the web infrastructure of two South Korean organisations, and it did not arrive as a separate program sitting next to the software it targets. It was welded in.

The implant, which its authors call "ted" in strings left behind in the compiled code, was built directly into trojanised copies of HAProxy. HAProxy is the widely used open-source load balancer that sits at the front door of many websites, deciding which back-end server should handle each visitor's request.

Once inside HAProxy, the backdoor could watch the web traffic flowing through and, for visitors the attackers chose, swap the real page for a different one. Everyone else got a normal response and saw nothing wrong.

The finding was first reported by The Hacker News, drawing on research into the two compromised South Korean deployments.

Is this a HAProxy vulnerability?

No. HAProxy itself is not flawed here, and patching it will not help.

The attackers needed to already be running code on the server as a privileged user before they could plant "ted". In practice that means they had root or something close to it on the load balancer machine. From there, they rebuilt HAProxy from source with their own malicious code stitched into it, then put the poisoned binary in place of the legitimate one.

So the real question for defenders is not "is my HAProxy up to date" but "how did anyone get that level of access to my load balancer host in the first place".

What could the attackers actually do?

Two things stand out: passive snooping and selective tampering.

Because HAProxy sees traffic before it is passed to the back-end web servers, a backdoor living inside it sees the same traffic. That can include login form contents, session cookies, and anything else that has not been end-to-end encrypted past the load balancer. Many setups terminate HTTPS at HAProxy, meaning traffic is briefly in the clear at exactly the point "ted" is reading it.

The implant can also rewrite what specific visitors get back. That opens the door to targeted phishing pages, fake login prompts, or malicious downloads served only to a handful of chosen users while everyone else sees the real site. It is the sort of trick that stays invisible to routine monitoring for a long time.

What should affected organisations do now?

Treat the load balancer host as fully compromised, not just the HAProxy binary.

A sensible response looks like this:

• Rebuild HAProxy from a known-good source tarball on a clean machine, and compare hashes against the running binary.
• Rotate every credential, session token and TLS private key that ever touched the affected load balancer.
• Pull logs from the host and any jump boxes used to administer it, and work backwards to find how root access was obtained.
• Check other internet-facing hosts for the same debug strings and build fingerprints, in case the same crew has been busy elsewhere.

For ordinary users of services fronted by a compromised load balancer, the practical advice is the usual: if you are told your account may have been affected, change the password, turn on multi-factor authentication if you have not already, and be sceptical of any login page that looks even slightly off.

South Korea's Personal Information Protection Commission (PIPC) has jurisdiction over breach notifications for South Korean users, and any confirmed exposure of personal data through these load balancers would fall under its regime.