Trojanisiertes HAProxy in Südkorea: Die Backdoor ted fängt Datenverkehr ab und verbirgt die Fernsteuerung

Rapid7 Labs hat ein bislang undokumentiertes Linux-Toolkit entdeckt, das in manipulierten Builds von HAProxy 2.8.12 bei zwei südkoreanischen Organisationen aus den Bereichen Automobilindustrie und Medien eingebettet war. Die als ted bezeichnete Malware – benannt nach Symbolen und Debug-Strings – kann HTTP-Antworten gezielt manipulieren, Befehle ausführen und Zugangsdaten stehlen.

Dabei handelt es sich nicht um eine Schwachstelle in HAProxy. Die Angreifer müssen zunächst Code auf dem Server ausführen können und anschließend die legitime Load-Balancer-Binary ersetzen. Das Vorhandensein des Implantats belegt daher eine weitergehende Kompromittierung des Systems; der ursprüngliche Angriffsvektor ist weiterhin unbekannt.

Rapid7 schreibt die Operation mit mittlerer Zuverlässigkeit nordkoreanischen staatlich unterstützten Akteuren zu. Technische Spuren überschneiden sich mit Infrastrukturen und Vorgehensweisen, die mit APT37, Lazarus und Kimsuky in Verbindung stehen, erlauben jedoch keine präzisere Zuordnung.

Die kompromittierten Builds hängen von HAProxy 2.8.12 ab

Beide Opfer nutzten HAProxy 2.8.12, eine am 8. November 2024 veröffentlichte Version. ted läuft nicht lediglich neben der Software: Die HAProxy-Binary wird durch einen trojanisierten Build ersetzt, der den Implantat-Code direkt enthält.

Die Malware greift über feste Offsets auf interne Programmstrukturen zu, die spezifisch für das beobachtete Release sind. Rapid7 konnte nicht feststellen, ob andere Builds der 2.8-Reihe mit demselben Code kompatibel sind.

Diese Einschränkung kann bei Untersuchungen einen Anhaltspunkt liefern, mindert jedoch nicht die Schwere des Eindringens. Eine andere Version würde für die Angreifer möglicherweise lediglich eine Neukompilierung oder Anpassung der Offsets erfordern. Dafür liegen allerdings keine Belege vor.

Das aktuelle Release dieses Zweigs ist HAProxy 2.8.28, veröffentlicht am 27. August 2026 – sechzehn Point-Releases nach der kompromittierten Version. Der Projekt-Tracker führt 529 Fehler auf, die in 2.8.12 vorhanden waren und im 2.8-Zweig bereits behoben wurden, darunter ein kritisches Problem und 16 als „major“ eingestufte Fehler.

Eine Aktualisierung bleibt notwendig, stellt jedoch keine Bereinigung dar. ted nutzt keinen dieser Fehler aus, und ein bereits infiziertes System kann auch nach dem Austausch von HAProxy weitere schädliche Komponenten enthalten. Außerdem kann ein neu kompilierter Build dieselbe Versionszeichenfolge wie die authentische Binary anzeigen.

Die angegebene Version allein beweist daher nichts.

Da keine Sicherheitslücke im Produkt identifiziert wurde, gibt es in diesem Fall keine CVE, die behoben werden müsste. Auch eine Aufnahme in den KEV-Katalog der CISA steht nicht zur Debatte: Der Angriff setzt eine vorherige Kompromittierung und den Austausch der Software voraus.

Die Injektion trifft nur ausgewählte Besucher

ted führt vier Prüfungen durch, bevor eine HTTP-Antwort verändert wird. Die Anfrage muss einen User-Agent enthalten, während URL und Referer den von den Betreibern konfigurierten Mustern entsprechen müssen.

Auch die Herkunft des Clients wird überprüft. Die IP-Adresse muss entweder exakt oder auf /24-Netzebene in einer Whitelist enthalten sein – es sei denn, die Anfrage enthält einen bestimmten Schlüssel im Feld Accept-Language.

Dieser Schlüssel dient als Zugangspass: Er ermöglicht es dem Betreiber, die IP-Filterung vollständig zu umgehen. Dadurch kann das Implantat getestet oder von Adressen aus erreicht werden, die nicht vorab in der Konfiguration hinterlegt wurden.

Sind alle Bedingungen erfüllt, ersetzt die Malware den für den Besucher bestimmten Inhalt. Dabei schreibt sie den Antworttyp und die Antwortlänge neu, erzwingt den HTTP-Status 200 und entfernt den Header Accept-Ranges.

Durch das Entfernen von Accept-Ranges wird verhindert, dass der Client bestimmte Dateibereiche anfordert. Dadurch sinkt die Wahrscheinlichkeit, dass Unterschiede bei Antwortgröße oder Antwortverhalten die Manipulation sichtbar machen.

Die Selektivität ist ein zentraler Bestandteil der Operation. Normale Benutzer, Scanner und automatisierte Systeme können legitime Inhalte erhalten, während nur ausgewählte Ziele die manipulierte Seite sehen. Eine gelegentliche Überprüfung der Website kann deshalb unauffällig bleiben.

Der C2-Kanal verschwindet aus den Load-Balancer-Statistiken

Eine Anfrage an einen bestimmten Bildpfad aktiviert den Command-and-Control-Modus. Die Verbindung endet direkt auf dem kompromittierten HAProxy und erreicht die Backend-Server nicht.

Um sie zu verbergen, verringert ted die Zähler für aktive Verbindungen des Load-Balancers. Der Austausch erscheint dadurch nicht in den nativen HAProxy-Statistiken. Die Backends können ihn ebenfalls nicht protokollieren, da sie die Anfrage nicht erhalten.

Der Befehlsinhalt wird in eine unter /tmp abgelegte Named Pipe geschrieben. Nach der Verwendung wird der Anfragekanal geleert. Die Ausgabe des Befehls wird über den Raw-Socket an den Betreiber zurückgesendet, wobei eine gewöhnliche HTTP/1.0 200 OK-Headerzeile vorangestellt wird.

Über diesen Kanal können die Angreifer:

• Beacons senden;
• Dateien hoch- und herunterladen;
• Shell-Befehle ausführen;
• die ted-Konfiguration ersetzen.

Das Ergebnis ist ein im Webverkehr getarnter C2-Kanal, der den wichtigsten Telemetriequellen des Dienstes entzogen wird. Für seine Erkennung muss HAProxy daher mit unabhängigen Daten abgeglichen werden, etwa mit Netzwerkflüssen, die außerhalb des Servers erfasst wurden.

Persistenz, Spurenlöschung und Passwortdiebstahl

Das Toolkit umfasst einen Stager, der die Installation nur startet, wenn HAProxy oder cron bereits ausgeführt wird. Vor dem Fortfahren prüft er außerdem, ob Root-Rechte vorhanden sind.

Nach der Aktivierung überschreibt er die legitime Binary crond und weist der Ersatzdatei den mit /usr/bin/ssh verknüpften Erstellungszeitstempel zu. Dadurch soll die Einführung eines neuen Executables weniger auffällig wirken.

ted manipuliert auch die während der Installation hinterlassenen Spuren. Aus der Bash-History von Root entfernt die Malware die Begriffe tmp, wget, cron und crond. Dieselben Wörter werden aus sechs System-Logs gelöscht, darunter auth.log und audit/audit.log.

Das Fehlen dieser Zeichenfolgen bedeutet daher nicht, dass die entsprechende Aktivität nicht stattgefunden hat. Zeitliche Lücken, widersprüchliche Zeilen oder Abweichungen gegenüber zentralisierten Log-Kopien können aussagekräftiger sein als eine einfache Textsuche.

Rapid7 identifizierte außerdem eine trojanisierte sshd-Komponente, die Klartextpasswörter erfassen, verschlüsseln und an einem festen Pfad speichern kann. Vergleichbarer Code wurde in manipulierten Versionen von agetty, atd und polkitd gefunden.

Die Operation geht somit über die Manipulation des Webverkehrs hinaus. Sie umfasst Persistenz, Fernsteuerung, das Sammeln von Zugangsdaten und die Manipulation mehrerer grundlegender Systemkomponenten.

Mit dem Toolkit ist außerdem curlRAT verbunden, ein Remote-Access-Trojaner, der normalerweise alle 12 Stunden einen Beacon sendet. Ein vom Betreiber kontrolliertes Flag verkürzt das Intervall auf 30 Sekunden. Die Malware beendet ihre Ausführung, wenn sie keine Marker-Datei findet, die die Virtualisierung des Hosts bestätigt.

curlRAT darf nicht mit CurlBack RAT verwechselt werden, einer eigenständigen, SideCopy zugeschriebenen Malware-Familie, die mit Pakistan in Verbindung steht.

Zuordnung zu Nordkorea weiterhin nicht abschließend

Bei den bekannten Opfern handelt es sich um zwei südkoreanische Organisationen aus den Bereichen Automobilindustrie und Medien. Wann die Kompromittierung begann und wie die Betreiber den initialen Zugriff erlangten, ist nicht bekannt.

Ein möglicher Ansatzpunkt ist ein exponiertes Groupware-Portal. ENKI hatte zuvor über die mutmaßlich Kimsuky zugeschriebene Kompromittierung eines koreanischen Anbieters von Kollaborationssoftware berichtet, bei der eine Schwachstelle in einem Mailserver ausgenutzt wurde. Es gibt jedoch keine direkten Belege dafür, dass derselbe Weg in den von Rapid7 untersuchten Fällen verwendet wurde.

Die Zuordnung mit mittlerer Zuverlässigkeit basiert auf unterschiedlichen Indizien: Domains, die mit APT37 in Verbindung stehen, ein Verbreitungsmodell mit Ähnlichkeiten zu Lazarus sowie die Vermutung, dass der initiale Zugriff mit Kimsuky verbunden war.

Eine Mandiant-Bewertung aus dem Jahr 2023 beschrieb nordkoreanische Operationen als durch gemeinsam genutzte Tools und eine Überschneidung der Ziele zwischen verschiedenen Clustern geprägt. Diese Überschneidungen erklären, warum Indikatoren gleichzeitig auf mehrere Gruppen hindeuten können.

Die Vorgehensweise erinnert außerdem an Operation SyncHole, bei der Besucher südkoreanischer Nachrichtenseiten serverseitig gefiltert und umgeleitet wurden. Kaspersky bewertete mit mittlerer Zuverlässigkeit, dass das Ziel anschließend über eine Schwachstelle in Cross EX schädlichen Code ausführen konnte.

Bei einer weiteren Kampagne beschrieben AhnLab und ENKI WhiteHat im Juli eine Watering-Hole-Kampagne, die auf kompromittierten südkoreanischen Websites basierte und sich gegen den Signatur-Client AnySign4PC richtete. Der Vergleich deutet auf eine Kontinuität bei den Techniken zur Auswahl der Opfer hin, ist jedoch kein Beleg dafür, dass die Operationen demselben Akteur zuzuordnen sind.

Zu suchende Indikatoren und Prioritäten bei der Reaktion

Zu den dateibasierten Indikatoren gehören:

• ~/cache/haproxy-1000.cache
• /var/lib/sshd/c8c68e629bba773a10ac80012d10bf19
• /var/lib/snapd/g580
• /tmp/jasper-log

Die veröffentlichten SHA-256-Hashes sind:

• 72e70936f0dbe459142a1d867617c35f8d0cce5d18c6a49e1090a2a5adc8e558
• 4bb923eb040aa13ca8fd409c31ee4729c60ddff32e350efe1c5a4a9168a065f5

Die sechs mit der Aktivität verbundenen Domains sind:

• img.monderhouse[.]space
• img.smartnords[.]site
• img.darklights[.]store
• img.responsive.pstatic[.]autos
• img.socialteams[.]store
• img.worksongo[.]store

Am 4. September 2026 ließ sich keine dieser Domains über Google Public DNS auflösen: Abfragen nach A- und NS-Records lieferten NXDOMAIN. Sie sind daher vor allem für die nachträgliche Analyse von DNS-, Proxy-, Firewall- und Netzwerkfluss-Logs nützlich, nicht für die Blockierung des aktuellen Datenverkehrs.

Die Reaktion sollte mit der Isolierung des Hosts und dem Abgleich der Binaries mit Kopien aus vertrauenswürdigen Quellen beginnen. Dabei müssen nicht nur HAProxy, sondern auch crond, sshd, agetty, atd und polkitd überprüft werden.

Außerdem sollte nach ungewöhnlichen Named Pipes in /tmp, Veränderungen an der Root-History, selektiven Log-Bereinigungen und Verbindungen gesucht werden, die sich nicht durch die HAProxy-Zähler erklären lassen. Eine Speicheranalyse kann dabei helfen, fremden Code oder ungewöhnliche Strukturen in den Prozessen zu erkennen.

Eine Neuinstallation ausschließlich des Load-Balancers reicht nicht aus. Da privilegierte Komponenten betroffen sind und Passwörter gestohlen wurden, muss die Bereinigung auch die Rotation potenziell offengelegter Zugangsdaten umfassen. Kann die Integrität des Hosts nicht nachgewiesen werden, sollte das System aus vertrauenswürdigen Quellen neu aufgebaut werden.