Ted Backdoor & curlRAT: Trojanized HAProxy Load-Balancer Toolkit

Rapid7 Labs documented a previously undocumented Linux toolkit at two South Korean organizations (automotive, media) in which a custom backdoor, internally referred to as "ted" from debug strings left in the binary, is compiled directly into the victims' own HAProxy 2.8.12 source tree as a native filter-API plugin. It is not a separate process bolted onto HAProxy; it rides HAProxy's own memory pools, event scheduler, and process-management infrastructure, so ordinary load-balancing continues to work while the implant intercepts decrypted HTTP traffic underneath it.

The attacker's objective is threefold: (1) a self-erasing command-and-control channel triggered by a request for a specific fake image path, with commands relayed through a named pipe and the triggering request scrubbed from HAProxy's own connection counters and logs before it ever reaches the backend; (2) a watering-hole capability that selectively rewrites or swaps page content for visitors matched by IP, User-Agent, referer, or a credential smuggled in the Accept-Language header; and (3) long-term persistence and credential theft via trojanized replacements of crond, sshd, agetty, atd, and polkitd, including an SSH keylogger and a companion beacon, curlRAT.

The single highest-value defensive angle is that this implant's entire design goal is making the load balancer's own logs and counters lie. Any hunt or control that depends solely on HAProxy's own logging, access logs, or connection statistics will not see it. Effective detection has to come from independent telemetry: EDR-visible process and file-write events on the underlying Linux host, binary integrity/hash verification, and out-of-band network egress monitoring, none of which the implant is documented to tamper with.

Web Hunter Decisions

Hash confidence tiering. Five distinct SHA-256 values surfaced across the five sources above. Three are corroborated by two or more independently-fetched snapshots (72e70936…, 4bb923eb…, 94630b96…) and are shipped as high-confidence. Two appear in only a single snapshot each (a8bfab4d… in GBHackers only, 5db1b6d5… in the hendryadrian mirror only) and are shipped as single-source/lower-confidence rather than silently dropped or silently trusted: both are still traceable to a saved snapshot, not invented, so they ship with an honest confidence label instead.

No hostile or injected content encountered. All five fetched sources returned ordinary journalistic/technical reporting. None contained instructions directed at the research agent, no prompt-injection attempts, and no request to fetch additional URLs, change output paths, or skip pipeline steps. All five are retained as legitimate citations.

Unconfirmed detail flagged, not shipped as fact. The task brief's claim that curlRAT "aborts on non-virtualized hosts" is confirmed verbatim in the Rapid7 source (it refuses to run unless it detects virtualization signatures, consistent with confirming deployment onto the intended cloud/VM-hosted production infrastructure rather than a bare-metal analysis box). This is stated accurately in Section 6 below rather than assumed to mean conventional sandbox-evasion (which is normally the inverse check).

Hunt Hypotheses

1. H1 (high conf). A host runs a HAProxy, crond, sshd, agetty, atd, or polkitd binary whose SHA-256 matches a known ted/curlRAT sample.
2. H2 (high conf, FP medium). The HAProxy process itself spawns a shell or network utility as a child process, which a load balancer has no legitimate reason to do outside of a configured external-check script.
3. H3 (medium conf). A named pipe matching the pattern /tmp/t[ID]_w.pipe is created by a process whose parent is haproxy, consistent with the documented ted_make_pipe_name / ted_create_multi_pipe_file command-relay mechanism.
4. H4 (high conf, perishable). A host resolves one of the six documented C2 domains. All six were NXDOMAIN as of 2026-09-04, so this is a retrospective/historical-log hunt, not a live-detection control.
5. H5 (medium conf, FP medium). A cron/at/getty/polkit daemon image makes an outbound network connection directly, which none of these programs do as part of normal operation.
6. H6 (medium conf). A process executes from one of the documented non-standard artifact paths (/var/lib/snapd/g580, /tmp/jasper-log), consistent with the stager's root-verification / OS-fingerprinting step before dropping the toolkit.
7. H7 (high conf). A file write occurs at one of the four documented artifact paths (cache file, SSH-keylogger output, stager drop paths).
8. H8 (high conf, requires log ingestion). HAProxy's own access log records a request for the specific fake image path used to trigger C2 mode. Because the implant is documented to scrub this from HAProxy's live counters and connection logs, this only works against out-of-band-shipped logs (e.g. a syslog/Filebeat forwarder that ships the line before ted can erase it, or an upstream WAF/CDN log that never passed through the compromised HAProxy at all).

Attack Chain

The named-pipe pattern is not shipped in the machine-readable IOC appendix (Section 10) as an exact-match value because [ID] varies per HAProxy connection; it is hunted via a wildcard query (Q3) instead of an import-ready atomic indicator.

These checks have no reliable CQL equivalent (file birth-time comparison and log-content-gap detection are not standard EDR event fields) and are run directly on the host or via auditd.

1. Timestomp check: crond birth time vs. /usr/bin/ssh

stat --format='%W %n' /usr/sbin/crond /usr/bin/ssh 2>/dev/null
# Note: %W (birth/creation time) returns 0 on filesystems/tools that do not expose
# it. Where that happens, use a forensic tool that reads the statx btime field, or
# debugfs -R 'stat <inode>' /dev/<device> on ext4. Flag any host where crond's
# birth time exactly equals ssh's birth time to the second.

2. Log / history tamper detection via auditctl

auditctl -w /root/.bash_history -p wa -k ted_history_tamper
auditctl -w /var/log/auth.log -p wa -k ted_log_tamper
auditctl -w /var/log/audit/audit.log -p wa -k ted_log_tamper
# Alert on any write to these paths from a process other than the expected
# logging daemon (rsyslogd, auditd itself, or the shell's own history-append).

3. Root-verifying stager / OS-fingerprint sequence

Look for a short-lived process reading /etc/os-release, hostname, and CPU/hypervisor identification (/proc/cpuinfo, dmidecode, systemd-detect-virt) in quick succession, immediately followed by a new file write to /var/lib/snapd/g580 or /tmp/jasper-log. See Q6/Q7 in Section 8 for the EDR-side correlation of the resulting artifacts.

4. Live named-pipe enumeration

find /tmp -type p -name 't*_w.pipe' -newer /var/log/wtmp
# Any FIFO matching this naming convention under /tmp is worth immediate
# investigation regardless of age; the -newer filter is a triage convenience,
# not a requirement.

See Section 15 for the full Detection Coverage Map, including attack-chain steps this pack does not cover.

Playbook A: Binary Integrity Verification & Baseline (Immediate)

# Step 1: verify installed package integrity
# Debian/Ubuntu:
debsums -c haproxy openssh-server cron util-linux polkitd 2>&1 | tee /var/log/ted-hunt-debsums.log
# RHEL/CentOS/Rocky:
rpm -V haproxy openssh-server cronie util-linux polkit | tee /var/log/ted-hunt-rpmverify.log

# Step 2: capture current binary hashes for the ongoing baseline
sha256sum /usr/sbin/haproxy /usr/sbin/crond /usr/sbin/sshd /sbin/agetty /usr/sbin/atd /usr/lib/polkit-1/polkitd > /var/log/ted-hunt-binary-hashes.txt

Prerequisites: debsums or rpm package installed; read access to the package database and the listed binary paths (paths vary by distro: adjust to your layout before running at scale). Reboot required: none. Rollback: none required: this is a read-only verification and reporting step.

Playbook B: Egress Filtering for Edge/Load-Balancer Hosts (Immediate/Near term)

nft add table inet ted_hunt_egress
nft add chain inet ted_hunt_egress output { type filter hook output priority 0 \; policy drop \; }
nft add rule inet ted_hunt_egress output ct state established,related accept
nft add rule inet ted_hunt_egress output ip daddr { REPLACE_WITH_BACKEND_CIDR, REPLACE_WITH_MGMT_CIDR } accept
nft add rule inet ted_hunt_egress output udp dport 53 ip daddr REPLACE_WITH_INTERNAL_DNS accept

Prerequisites: nftables installed; a validated list of legitimate backend/management/DNS destinations for this specific host populated into the REPLACE_WITH_ placeholders before deploying: wrong values will break production load balancing. Reboot required: no; rules apply immediately. Persist across reboot with nft list ruleset > /etc/nftables.conf and enable the nftables service. Rollback: nft delete table inet ted_hunt_egress removes the entire policy immediately.

Playbook C: SSH Hardening: Disable Password Authentication (Near term)

# /etc/ssh/sshd_config.d/99-ted-hunt-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

# Apply:
sshd -t && systemctl reload sshd

Prerequisites: key-based access already provisioned and tested for every admin and service account that needs to reach this host, before disabling password auth: otherwise you will lock yourself out. Reboot required: no; an sshd reload is sufficient. Rollback: remove /etc/ssh/sshd_config.d/99-ted-hunt-hardening.conf and run systemctl reload sshd.

Playbook D: File Integrity Monitoring via AIDE (Near term)

apt-get install -y aide   # or: yum install -y aide
aideinit
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
echo "0 */6 * * * root /usr/bin/aide --check | /usr/bin/mail -s 'AIDE report' REPLACE_WITH_SOC_MAILBOX" > /etc/cron.d/ted-hunt-aide

Prerequisites: the baseline must be captured from a host already verified clean via Playbook A before trusting the AIDE database as a source of truth. Reboot required: no. Rollback: rm /etc/cron.d/ted-hunt-aide stops scheduled checks immediately; removing the aide package itself is optional and non-disruptive.

Validation gates for the queries above are detailed in Section 11. In short: confirm sensor coverage before trusting a clean result, baseline Q2/Q5 for at least 14 days before any prevention-mode promotion, and re-run the audit checklist in Section 10 fleet-wide as the first action on any new host brought into scope.

Full fetched-text snapshots of all five sources are saved alongside this pack in Ted-HAProxy-Backdoor-Hunt-sources/ for provenance verification.