Ted Implant in Trojanized HAProxy Builds: Detecting and Eradicating Linux Load-Balancer Traffic Interception

Security teams running HAProxy on Linux should treat this as an active integrity incident, not a product patch event: attackers embedded a previously undocumented toolkit, self-identified as ted in debug strings, directly into trojanized HAProxy builds used by two South Korean organizations. The implant intercepted web traffic and selectively returned altered pages, meaning the load balancer itself became the adversary-in-the-middle control point. This is not a HAProxy vulnerability; deployment required prior code execution on the host, so the defensive center of gravity is build provenance, binary integrity, egress control, and post-compromise eradication.

What happened and why it matters

The reporting describes a Linux implant compiled into HAProxy load balancer binaries at two victim organizations. Because HAProxy terminates, routes, or inspects high volumes of HTTP and HTTPS-adjacent traffic depending on architecture, a trojanized build gives the operator a privileged vantage point without needing to attack every backend application. Selective page alteration is especially dangerous: it enables watering-hole delivery, credential or session capture, targeted redirect logic, malware distribution to chosen users, and quiet suppression of security controls such as CSP headers, cookie flags, or authentication prompts.

The key defender point is that there is no CVE identifier in the source reporting and no evidence that HAProxy upstream code was vulnerable. Do not fabricate a patch-only response. If an attacker can execute code on a load balancer host, replace the daemon, alter systemd units, or restart services, then vulnerability management alone will not save you. This is an intrusion scenario with supply-chain characteristics: trusted infrastructure software was modified after compromise or through an unauthorized build path.

Severity is high for internet-facing load balancers, reverse proxies, API gateways, Kubernetes ingress nodes using HAProxy, PCI-DSS cardholder data edge components, healthcare portals, and any environment where HAProxy handles authentication, session cookies, or TLS keys. Urgency is highest where HAProxy binaries were built in-house, deployed outside package management, copied manually between hosts, or run on systems with compilers, curl, wget, git, or broad egress.

Technical analysis

Affected products and platforms. The affected component in this reporting is trojanized HAProxy running on Linux hosts. Any HAProxy version can be impacted if an attacker replaces or rebuilds the binary, because the weakness is not a vulnerable parser or overflow in HAProxy itself. Risk concentrates around:

• Internet-facing HAProxy load balancers and reverse proxies
• HAProxy Enterprise or community builds deployed from source, internal mirrors, golden images, containers, or configuration management
• Hosts where HAProxy has access to TLS private keys, session cookies, authorization headers, or backend trust relationships
• Environments that permit package installation, source compilation, or service restarts on production proxy nodes

Attack chain, defender view. A plausible intrusion sequence consistent with the reporting is:

1. Initial code execution on the HAProxy host through stolen credentials, exposed management interfaces, vulnerable adjacent services, CI/CD abuse, configuration management compromise, or supply-chain access.
2. Reconnaissance of HAProxy paths: /usr/sbin/haproxy, /usr/local/sbin/haproxy, /etc/haproxy/haproxy.cfg, systemd units, container images, startup scripts, and log destinations.
3. Replacement of the legitimate binary with a trojanized build containing the ted implant. Debug strings inside the binary reportedly identify the implant name, which is a useful forensic lead but should not be the only detection mechanism.
4. Service reload or restart so the malicious build begins handling traffic. HAProxy reloads are operationally common, which gives attackers cover if defenders only alert on outages.
5. Selective interception and response modification for chosen visitors. The implant can alter pages for targeted users while leaving most traffic normal, reducing obvious availability impact and bypassing naive synthetic monitoring.
6. Optional persistence through systemd unit changes, cron, configuration management drift, container image replacement, or repeated redeployment from a compromised artifact source.

Relevant MITRE ATT&CK techniques include Modify System Image or Replace Binary style behavior aligned to system image tampering, Web Protocols for command and control or staged delivery, Adversary-in-the-Middle behavior at the proxy layer, Input or Web Traffic Capture, and Service Stop or Modify during reload operations.

Exploitation status. This activity is described as observed in real intrusions against two South Korean organizations. There is no public indication in the source summary that it is in CISA KEV, because KEV tracks vulnerabilities rather than custom implants installed after code execution. Treat it as confirmed active tradecraft, not theoretical.

Detection and response

Detection must focus on three layers: provenance, process behavior, and traffic outcome. Provenance asks whether the running HAProxy binary matches the expected signed package or approved internal build. Process behavior asks whether production proxy hosts are compiling, downloading, or spawning tooling that load balancers should not run. Traffic outcome asks whether selected clients receive different responses than canary or backend-direct requests.

---
title: Production HAProxy Host Source Build or Download Activity
id: 9c1f0b26-6d5a-4f0d-9f7e-2b8a1c4d7e90
status: experimental
description: Detects compilation or retrieval activity tied to HAProxy on production Linux proxy hosts, consistent with rebuilding or replacing a load balancer binary after code execution.
references:
  - https://attack.mitre.org/techniques/T1601/
  - https://thehackernews.com/2026/09/new-ted-backdoor-hides-inside-victims.html
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.defense_evasion
  - attack.persistence
  - attack.t1601
logsource:
  category: process_creation
  product: linux
detection:
  selection_tool:
    Image|endswith:
      - '/gcc'
      - '/cc'
      - '/clang'
      - '/make'
      - '/cmake'
      - '/git'
      - '/curl'
      - '/wget'
  selection_context:
    CommandLine|contains:
      - 'haproxy'
      - 'HAProxy'
      - '/usr/sbin/haproxy'
      - '/usr/local/sbin/haproxy'
      - '/etc/haproxy'
  condition: selection_tool and selection_context
falsepositives:
  - Controlled package builds inside isolated build pipelines
  - Emergency vendor-supported rebuilds performed through change management
level: high
---
title: HAProxy Process Spawning Shell Interpreter or Downloader
id: 4a7d9e12-8c3b-4a61-b2f5-0d9e6a1c3b44
status: experimental
description: Detects shells, interpreters, downloaders, or system modification tools launched by the HAProxy daemon, which should rarely occur on a hardened proxy node.
references:
  - https://attack.mitre.org/techniques/T1059/
  - https://thehackernews.com/2026/09/new-ted-backdoor-hides-inside-victims.html
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/haproxy'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/php'
      - '/curl'
      - '/wget'
      - '/socat'
      - '/nc'
      - '/ncat'
      - '/openssl'
  condition: selection_parent and selection_child
falsepositives:
  - Vendor health-check wrappers that explicitly execute local helpers
  - Legacy init scripts should be migrated and then this rule should be tight
level: critical
---
title: HAProxy Binary Configuration or Service Unit Modification Command
id: 7e2b6a41-5f08-4f6b-9a13-c8d0e2f7a951
status: experimental
description: Detects command-line modification of HAProxy binaries, configuration, or systemd units outside approved automation contexts.
references:
  - https://attack.mitre.org/techniques/T1601/
  - https://attack.mitre.org/techniques/T1562/
  - https://thehackernews.com/2026/09/new-ted-backdoor-hides-inside-victims.html
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.defense_evasion
  - attack.persistence
  - attack.t1601
logsource:
  category: process_creation
  product: linux
detection:
  selection_tool:
    Image|endswith:
      - '/cp'
      - '/mv'
      - '/install'
      - '/sed'
      - '/tee'
      - '/truncate'
      - '/chmod'
      - '/chown'
      - '/systemctl'
      - '/ln'
  selection_target:
    CommandLine|contains:
      - '/usr/sbin/haproxy'
      - '/usr/local/sbin/haproxy'
      - '/etc/haproxy/haproxy.cfg'
      - '/etc/systemd/system/haproxy.service'
      - '/lib/systemd/system/haproxy.service'
      - '/etc/init.d/haproxy'
  condition: selection_tool and selection_target
falsepositives:
  - Configuration management and approved deployment windows
  - Package manager upgrades should be correlated with rpm dpkg or apt transaction records
level: high

// Microsoft Sentinel or Defender hunt for HAProxy trojanization, rebuild behavior, and integrity findings
// Tune the host list to your load balancer inventory before broad deployment.
let proxy_hosts = dynamic(["haproxy-01","haproxy-02","edge-lb-01"]); // replace with inventory or CMDB join
union isfuzzy=true
(Syslog
| where TimeGenerated > ago(14d)
| where Computer in~ (proxy_hosts) or Computer has_any ("haproxy","lb","proxy","edge")
| where SyslogMessage has_any ("haproxy","/usr/sbin/haproxy","/usr/local/sbin/haproxy","/etc/haproxy","haproxy.service")
| where SyslogMessage has_any ("gcc","make","cmake","clang","git clone","curl","wget","rpmbuild","debuild","mismatch","modified","altered","checksum","failed verification")
| project TimeGenerated, Computer, Facility, SeverityLevel, ProcessName, SyslogMessage),
(DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where DeviceName in~ (proxy_hosts) or DeviceName has_any ("haproxy","lb","proxy","edge")
| where FileName in~ ("gcc","cc","clang","make","cmake","git","curl","wget","sh","bash","python3","perl","cp","mv","install","sed","systemctl")
| where ProcessCommandLine has_any ("haproxy","/usr/sbin/haproxy","/usr/local/sbin/haproxy","/etc/haproxy","haproxy.service")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256),
(DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName =~ "haproxy" or InitiatingProcessCommandLine has "haproxy"
| where FileName in~ ("sh","bash","dash","zsh","python","python3","perl","curl","wget","openssl","nc","socat","ncat")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName, SHA256)
| order by TimeGenerated desc;

-- Velociraptor hunt: enumerate HAProxy binaries, service units, running processes, and network listeners
LET paths <= SELECT FullPath, Size, Mtime, Ctime, hash(path=FullPath) AS Hash
FROM glob(globs=[
  '/usr/sbin/haproxy',
  '/usr/local/sbin/haproxy',
  '/etc/haproxy/haproxy.cfg',
  '/etc/systemd/system/haproxy.service',
  '/lib/systemd/system/haproxy.service',
  '/etc/init.d/haproxy'
])

LET procs <= SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ 'haproxy' OR Exe =~ 'haproxy' OR CommandLine =~ 'haproxy'

LET conns <= SELECT Pid, Name, LocalAddr, LocalPort, RemoteAddr, RemotePort, State
FROM netstat()
WHERE Name =~ 'haproxy' OR LocalPort in (80, 443, 8080, 8443)

SELECT 'file' AS ArtifactType, FullPath AS Detail, Size, Mtime, Ctime, Hash.sha256 AS SHA256, '' AS Extra
FROM paths
UNION ALL
SELECT 'process' AS ArtifactType, Name AS Detail, 0 AS Size, CreateTime AS Mtime, '' AS Ctime, '' AS SHA256, CommandLine AS Extra
FROM procs
UNION ALL
SELECT 'netstat' AS ArtifactType, Name AS Detail, LocalPort AS Size, '' AS Mtime, '' AS Ctime, '' AS SHA256, format('%v:%v -> %v:%v %v', args=[LocalAddr, LocalPort, RemoteAddr, RemotePort, State]) AS Extra
FROM conns

#!/usr/bin/env bash
# HAProxy trojanization verification and containment helper. Run from a trusted admin host or rescue shell.
# Do not execute blindly during a live incident without preserving volatile data first.
set -u

log() { printf '[%s] %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$*"; }

CANDIDATES="/usr/sbin/haproxy /usr/local/sbin/haproxy /sbin/haproxy /opt/haproxy/sbin/haproxy"
log "Collecting volatile evidence first: process list, sockets, service state"
ps auxww | grep -i '[h]aproxy' || true
ss -lntup 2>/dev/null | grep -i haproxy || true
systemctl status haproxy --no-pager -l 2>/dev/null || service haproxy status 2>/dev/null || true
systemctl cat haproxy 2>/dev/null || true

log "Locating HAProxy binaries and hashing"
for f in $CANDIDATES; do
  if [ -f "$f" ]; then
    stat "$f" || true
    sha256sum "$f" || true
    command -v strings >/dev/null 2>&1 && strings -a "$f" | grep -E 'ted|debug|haproxy' | head -n 40 || true
  fi
done

log "Package ownership and integrity checks"
if command -v rpm >/dev/null 2>&1; then
  for f in $CANDIDATES; do [ -f "$f" ] && rpm -qf "$f" 2>/dev/null; done
  rpm -qa | grep -i haproxy || true
  rpm -Va 2>/dev/null | grep -Ei 'haproxy|/usr/sbin|/usr/local/sbin|/etc/haproxy' || true
elif command -v dpkg-query >/dev/null 2>&1; then
  for f in $CANDIDATES; do [ -f "$f" ] && dpkg-query -S "$f" 2>/dev/null; done
  dpkg-query -l | grep -i haproxy || true
  if command -v debsums >/dev/null 2>&1; then debsums -ac 2>/dev/null | grep -Ei 'haproxy|/usr/sbin|/usr/local/sbin|/etc/haproxy' || true; fi
fi

log "Recent modifications around proxy paths"
find /usr/sbin /usr/local/sbin /etc/haproxy /etc/systemd/system /lib/systemd/system -maxdepth 3 \( -iname '*haproxy*' -o -name 'haproxy.cfg' \) -mtime -45 -ls 2>/dev/null || true

log "Audit configuration for watches on proxy assets"
auditctl -l 2>/dev/null | grep -Ei 'haproxy|/usr/sbin|/etc/systemd' || true

log "Containment options, prompt before action"
printf 'Enter QUARANTINE to stop haproxy and mask service, or press Enter to skip: '
read -r ans
if [ "$ans" = "QUARANTINE" ]; then
  systemctl stop haproxy 2>/dev/null || service haproxy stop 2>/dev/null || true
  systemctl mask haproxy 2>/dev/null || true
  log "HAProxy stopped and masked. Replace with known-good build before unmasking."
fi

log "Rebuild reminders: use signed distro packages or reproducible internal builds, verify signatures, remove compilers, restrict egress, enable FIM and auditd watches, then rotate credentials and TLS material exposed to the host."

Immediate response playbook

1. Declare an integrity incident for edge infrastructure. If HAProxy was replaced, assume the host had root-equivalent compromise and that observed traffic may have been selectively manipulated.
2. Preserve evidence before restart. Capture memory if feasible, disk image, ps, ss, systemd unit contents, package database, audit logs, HAProxy logs, load balancer config maps, CI/CD artifacts, and container image digests. A service restart destroys the exact running image if the binary was swapped on disk and the process is still resident.
3. Compare the running process to on-disk and package state. Use ls -l /proc/<pid>/exe, sha256sum, package verification, and known-good hashes from your software bill of materials or artifact repository. Check for debug or implant strings, including ted, but treat absence of strings as non-exonerating.
4. Isolate without tipping off selectively. Prefer network isolation or controlled failover to a known-good node over a noisy reboot. Maintain service using a clean standby load balancer built from verified sources.
5. Hunt laterally. The same access used to trojanize HAProxy can reach adjacent proxies, ingress controllers, CI runners, artifact repositories, bastion hosts, and configuration management. Search for identical hashes and build timestamps across the fleet.
6. Assume cryptographic and session exposure. If TLS keys, session cookies, authorization headers, OAuth tokens, or backend credentials transited or resided on the host, rotate them. Invalidate sessions for affected user populations where selective targeting is suspected.
7. Rebuild, do not repair. Reinstall HAProxy from signed vendor or distribution packages, or from a reproducible internal pipeline with provenance attestations. Remove compilers and download tools from production proxy nodes. Reissue host identity, SSH keys, service account tokens, and automation credentials.
8. Validate traffic outcomes. Deploy canary transactions from controlled external vantage points and compare edge responses to backend-direct responses. Look for injected scripts, changed redirects, altered download URLs, stripped security headers, modified cookie attributes, or target-specific response deltas.

Remediation and hardening

Because this is not a HAProxy software flaw, the correct remediation is verified rebuild plus control-plane hardening. Use the latest supported HAProxy release from the official project at https://www.haproxy.org/ or your distribution vendor, and validate package signatures through your normal update channel. Review HAProxy security history and release notes through https://www.haproxy.org/#news and the project repository at https://github.com/haproxy/haproxy, but do not expect a single patch for an implant compiled after compromise.

Implement these controls with owners and deadlines:

• Binary provenance: Deploy HAProxy only from signed packages or reproducible internal builds. Store approved SHA256 digests and SBOMs. Alert on any hash drift for /usr/sbin/haproxy, /usr/local/sbin/haproxy, container image layers, and systemd units.
• File integrity monitoring: Use AIDE, Tripwire, OSQuery, EDR FIM, or auditd watches on HAProxy binaries, configuration, service units, startup scripts, and package manager transactions. Page on changes outside a deployment window.
• No build toolchain on proxies: Remove gcc, clang, make, cmake, git, curl, wget, package build tools, and unused interpreters from production load balancers. If a pipeline must build artifacts, do it in an isolated builder and ship signed artifacts.
• Egress restrictions: Proxy nodes should talk to backends, telemetry, logging, identity, and approved update endpoints only. Deny arbitrary outbound HTTP and HTTPS from HAProxy hosts. Unexpected egress from a load balancer is high signal.
• Service control: Protect systemd units and reload paths. Require authenticated change tickets for systemctl reload haproxy, daemon-reload, binary replacement, or configuration management runs. Log and alert on reload storms.
• Least privilege and mandatory access control: Run HAProxy as a dedicated user with chroot where appropriate, SELinux or AppArmor enforcing, no sudo, no writable binary paths, and locked-down /etc/haproxy. Avoid making binaries immutable with chattr +i unless your deployment pipeline explicitly supports it; immutability can also block emergency patching if misused.
• Secrets protection: Prefer external TLS key custody, hardware-backed keys, short-lived service credentials, and strict separation between proxy nodes and secret stores. Rotate after any suspected binary swap.
• Supply-chain governance: Pin base images, verify signatures, enforce provenance attestations such as SLSA-style metadata or Sigstore where practical, require two-person approval for load balancer artifact promotion, and monitor artifact repositories for unexpected publishes.
• Detection content operationalization: Deploy the Sigma rules through your Linux telemetry pipeline, onboard proxy nodes to Defender or EDR where supported, stream Syslog and auditd to Sentinel, and schedule the Velociraptor hunt weekly plus after every deployment.
• External assurance monitoring: Use independent canary clients from multiple networks and user profiles to detect selective page alteration. Compare edge and backend responses for headers, body hashes, redirects, script tags, cookie flags, TLS behavior, and content length variance.

There is no CISA deadline in the source reporting because there is no CVE. Your internal deadline should still be aggressive: verify exposed HAProxy binaries within 24 hours, complete fleet hash comparison within 72 hours, and rotate secrets for any host with unexplained drift immediately after evidence preservation.

Executive takeaways for leadership

• This is post-compromise infrastructure tampering, not a routine HAProxy patch. Funding for EDR coverage, FIM, signed builds, and clean-room recovery is the relevant control investment.
• Internet edge devices are identity systems. Treat proxy compromise like IdP or VPN compromise: preserve forensics, rotate secrets, invalidate sessions, and review downstream application logs.
• Selective page alteration defeats simple uptime checks. Require canary-based integrity monitoring and backend-direct comparisons for customer-facing flows.
• Remove build and download tooling from production proxies and restrict egress. These are low-cost controls that sharply reduce the attacker’s ability to implant traffic-interception logic.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub