Stealthy 'Ted' Backdoor Infiltrates Custom Linux HAProxy Builds

The Emergence of 'Ted': A Silent Infrastructure Threat

In the modern enterprise IT ecosystem, reverse proxies and load balancers serve as the digital front door for web applications, handling massive volumes of sensitive, unencrypted traffic at the point of SSL/TLS termination. When an adversary gains control of these critical choke points, the security posture of an entire organization collapses from within. Security researchers have recently identified a previously undocumented, highly sophisticated Linux malware framework nicknamed "Ted," which directly embeds itself within custom-compiled builds of the widely used HAProxy software.

Discovered active inside the networks of at least two organizations based in South Korea, the implant gets its moniker from internal debugging strings left scattered throughout its compiled binaries. Rather than exploiting a zero-day vulnerability in HAProxy itself, the threat actors behind Ted achieved initial host access through separate means, subsequently replacing or modifying the legitimate HAProxy source code or compilation pipeline. The result is a fully functional load balancer that quietly doubles as an intercepting proxy, capable of reading incoming and outgoing traffic, modifying HTTP responses on the fly, and serving customized, malicious content to targeted end users.

This tactic highlights a growing and worrisome trend in advanced persistent threat (APT) methodologies: instead of running noisy, standalone malicious processes that trip endpoint detection and response (EDR) sensors, attackers are increasingly choosing to graft their persistence logic directly into legitimate, high-trust system services.

Not a Vulnerability, But a Post-Exploitation Masterclass

It is critical to distinguish between a software vulnerability in an upstream open-source project and a post-exploitation binary modification. HAProxy—an open-source, high-performance TCP/HTTP load balancer trusted by millions of infrastructure engineering teams worldwide—contains no intrinsic security flaw that allows Ted to exist. The core software repository remains secure.

Instead, the deployment of Ted relies on pre-existing host access. Once attackers establish administrative privileges or control over a target's build environment, they modify the HAProxy source code before compilation, or manipulate the build flags to link malicious modules directly into the final executable executable.

By embedding the backdoor into the compiled binary of HAProxy, the attackers achieve several crucial operational objectives:

• Process Disguise: The malware does not execute as an unfamiliar process like nc, python, or a randomly named payload in /tmp. To the operating system and system administrators, the running process is simply /usr/sbin/haproxy or a localized binary path.
• Traffic Privileges: Because HAProxy routinely handles incoming network connections, manages sockets, and processes raw HTTP headers, the malicious routines inherit all necessary privileges to inspect and tamper with web traffic without invoking unusual network system calls.
• Persistence: As long as the system service for HAProxy is configured to run on startup or automatically restart upon failure, the backdoor maintains persistent, self-healing execution alongside the legitimate server application.

How HAProxy Trojanization Works Under the Hood

To understand why the Ted backdoor is so dangerous, one must examine the operational role of load balancers in enterprise environments. Typically, an HAProxy instance terminates incoming HTTPS connections from the internet, decrypts the traffic using corporate SSL certificates, evaluates routing rules, and forwards the plaintext HTTP requests to internal backend servers. Conversely, response traffic from backend servers travels back through HAProxy, where it is re-encrypted and delivered back to the client.

Ted hooks into this data flow precisely at the point where traffic exists in unencrypted memory. By intercepting data buffers during the HTTP parsing phase, the implant grants its operators several capabilities:

1. Passive Eavesdropping: Ted can log session cookies, authorization headers, basic auth credentials, POST request bodies containing passwords, and private API keys before they ever reach application logs or security monitoring tools.
2. Traffic Alteration: When a victim requests a page, Ted can dynamically inject malicious JavaScript, alter hyperlink destinations, or rewrite response bodies. This allows attackers to perform watering-hole attacks, drive-by downloads, or credential harvesting directly within legitimate web interfaces.
3. Selective Targeting: The implant features conditional logic, allowing the operators to specify criteria for when to manipulate traffic. For instance, ordinary web visitors might receive completely normal responses, while visitors connecting from specific IP ranges or possessing unique user-agent strings are served modified payloads.

Leaving behind debug symbols referencing string literals like ted suggests the malware may still be under active development or that the operators prioritized rapid deployment over comprehensive anti-forensic sanitization. Nonetheless, the architecture of the implant demonstrates a sophisticated understanding of network infrastructure internals.

Selective Traffic Manipulation: The Art of Targeted Content Injection

One of the most insidious aspects of the Ted implant is its capability to serve altered web pages selectively. In traditional network attacks, modifying web content en masse often leads to swift detection; users notice broken layouts, unexpected pop-ups, or degraded performance, prompting immediate IT intervention.

Ted circumvents this by acting as an intelligent, conditional inline proxy. By evaluating incoming requests against internal rule sets, the implant can maintain a low profile. A standard monitoring probe or automated health-check ping sent to the load balancer receives an unaltered, valid 200 OK response. However, if a targeted user—perhaps an administrator accessing an internal management dashboard or an employee logging into a web application—sends a matching request, Ted intercepts the HTTP response payload from the backend and stitches malicious content into the HTML stream.

This technique allows attackers to conduct seamless phishing attacks, capture multi-factor authentication (MFA) tokens in real time, or silently push browser exploits without altering the underlying code stored on the actual web servers. Because the backend servers remain completely clean, traditional file integrity monitoring (FIM) deployed on web application servers will never register a change.

Geopolitical and Tactical Context: The South Korean Targets

While details surrounding the specific organizations targeted in South Korea remain restricted, the geographic focus provides valuable intelligence context. South Korea has long been a primary target for sophisticated state-sponsored threat groups operating out of East Asia, including various North Korean APT collectives (such as Lazarus, Kimsuky, and Andariel) as well as Chinese nation-state actors.

Attackers operating in this region frequently focus on supply chain compromises, corporate software updates, and core network infrastructure to maintain long-term persistence within high-value financial, defense, and technology sectors. Trojanizing load balancers fits squarely into the playbook of strategic espionage actors who prioritize stealth, durability, and high-yield intelligence gathering over destructive outcomes.

Furthermore, South Korean enterprises often rely on customized, localized Linux distributions and proprietary internal build scripts. By targeting custom HAProxy builds rather than relying on off-the-shelf Linux implants, the authors of Ted demonstrated a willingness to adapt their tooling directly to the build pipelines of their target organizations.

Why Traditional Security Defenses Miss Embedded Infrastructure Implants

The discovery of Ted underscores a glaring weakness in contemporary enterprise defense strategies: an over-reliance on process-based anomaly detection and standard antivirus signatures.

Most commercial EDR solutions evaluate process hierarchies, looking for anomalous parent-child relationships (such as a web server executing a bash shell) or unverified running executables located in standard temporary directories. When an attacker compiles malware directly into a trusted application like HAProxy, those baseline assumptions break down:

• Process Name and Lineage: The executable runs under the expected binary path (/usr/sbin/haproxy) and is launched by systemd, appearing entirely benign to automated process-monitoring rules.
• Binary Signatures: If the enterprise compiles software from source locally (a common practice for performance tuning or custom module integration), the resulting binary will naturally lack a vendor digital signature, rendering standard signature validation controls ineffective.
• Network Behavior: Because HAProxy is supposed to listen on ports 80 and 443 and establish outbound connections to internal backends, outbound network connections generated by the embedded backdoor blend directly into normal application traffic.

Without explicit file hashing of compiled binaries against known baseline builds, or detailed memory inspection of running daemons, implants like Ted can quietly persist undetected for months or years.

Hardening Load Balancers and Building Pipeline Integrity

Defending against host-level infrastructure trojanization requires organizations to expand their security focus beyond standard endpoint security and adopt strict software supply chain and build integrity controls. To mitigate the risk posed by implants like Ted, engineering and SecOps teams should implement several defensive measures:

1. Deterministic and Reproducible Builds: Organizations that compile critical infrastructure tools from source must transition to reproducible build environments. If two identical source trees compiled with identical settings produce different binary hashes, security teams can instantly identify unauthorized code injection.
2. Binary Integrity Monitoring: Implement strict File Integrity Monitoring (FIM) on all critical system binaries, dynamic libraries, and systemd service configurations. Any unexpected change to the SHA-256 hash of executable files should immediately trigger automated isolate-and-investigate workflows.
3. Source Code Auditing and Immutable CI/CD: Source code repositories used to build custom infrastructure binaries must require multi-party code reviews, signed commits, and restricted branch access. Build pipelines should execute on isolated, short-lived ephemeral workers to prevent persistent tampering of the compilation environment.
4. Network-Level Traffic Inspection: Do not rely solely on proxy logs produced by load balancers, as a trojanized proxy can easily falsify its own audit logs. Employ out-of-band network tap devices and intrusion detection systems (IDS) to analyze raw network traffic entering and leaving load balancers.
5. Memory Analysis and Process Inspection: Periodically conduct live memory analysis on edge appliances to detect injected code regions, unexpected hooked functions, or unlinked dynamic libraries running within host processes.

The Future of Infrastructure-Level Persistence

The discovery of the Ted backdoor represents a sobering evolution in the threat landscape. As enterprise endpoint defenses become increasingly adept at spotting conventional malware, advanced threat actors will continue shifting their attention toward core network infrastructure, load balancers, firewalls, and continuous integration systems.

By turning an organization's own custom-compiled tools against them, attackers achieve unprecedented levels of stealth and access. The Ted implant serves as a critical warning for organizations worldwide: securing the application code is no longer enough—you must also guarantee the absolute integrity of the software tools and build pipelines that deliver it.