HAProxy trojanisé en Corée du Sud : la backdoor ted intercepte le trafic et dissimule le contrôle à distance

Rapid7 Labs a découvert un toolkit Linux jusqu’alors inédit, intégré à des versions altérées de HAProxy 2.8.12 dans deux organisations sud-coréennes des secteurs automobile et des médias. Le malware, baptisé ted d’après ses symboles et ses chaînes de débogage, permet de manipuler sélectivement les réponses HTTP, d’exécuter des commandes et de dérober des identifiants.

Il ne s’agit pas d’une vulnérabilité de HAProxy. Les attaquants doivent d’abord obtenir l’exécution de code sur le serveur, puis remplacer le binaire légitime du répartiteur de charge. La présence de cet implant révèle donc une compromission plus profonde du système, dont le vecteur initial reste inconnu.

Rapid7 attribue l’opération, avec un niveau de confiance moyen, à des acteurs soutenus par l’État nord-coréen. Les éléments techniques présentent des recoupements avec des infrastructures et des modes opératoires associés à APT37, Lazarus et Kimsuky, sans permettre une attribution plus précise.

Les versions compromises reposent sur HAProxy 2.8.12

Les deux victimes exécutaient HAProxy 2.8.12, une version publiée le 8 novembre 2024. ted ne se contente pas de s’exécuter à côté du logiciel : le binaire HAProxy est remplacé par une version trojanisée qui contient directement le code de l’implant.

Le malware accède aux structures internes du programme au moyen d’offsets fixes, propres à la version observée. Rapid7 n’a pas déterminé si d’autres versions de la branche 2.8 sont compatibles avec ce même code.

Cette contrainte peut constituer un élément utile à l’enquête, mais elle ne réduit pas la gravité de l’intrusion. Une version différente pourrait uniquement obliger les attaquants à recompiler le code ou à adapter les offsets, une possibilité pour laquelle aucune preuve n’est toutefois disponible.

La version actuelle de la branche est HAProxy 2.8.28, publiée le 27 août 2026, soit seize versions correctives après celle qui a été compromise. Le suivi du projet recense 529 bogues présents dans la version 2.8.12 et déjà corrigés dans la branche 2.8, dont un problème critique et 16 classés comme majeurs.

La mise à jour reste nécessaire, mais elle ne constitue pas une remédiation complète. ted n’exploite aucun de ces bogues, et un système déjà infecté peut conserver d’autres composants malveillants après le remplacement de HAProxy. En outre, une version recompilée peut afficher la même chaîne de version que le binaire authentique.

La version déclarée, à elle seule, ne prouve rien.

Aucune faille du produit n’ayant été identifiée, aucun identifiant CVE n’est applicable dans ce cas. La question d’une inscription au catalogue KEV de la CISA ne se pose pas davantage : l’attaque nécessite une compromission préalable ainsi que le remplacement du logiciel.

L’injection ne cible que certains visiteurs

ted effectue quatre contrôles avant de modifier une réponse HTTP. La requête doit contenir un User-Agent, tandis que l’URL et le champ Referer doivent correspondre aux motifs configurés par les opérateurs.

L’origine du client est également vérifiée. L’adresse doit figurer dans une liste blanche, selon une correspondance exacte ou au niveau du réseau /24, sauf si la requête contient une clé particulière dans le champ Accept-Language.

Cette dernière sert de laissez-passer : elle permet à l’opérateur d’ignorer complètement le filtrage par adresse IP. Elle peut donc être utilisée pour tester l’implant ou y accéder depuis des adresses qui n’ont pas été ajoutées au préalable à la configuration.

Lorsque toutes les conditions sont réunies, le malware remplace le contenu destiné au visiteur. Au cours de l’opération, il réécrit le type et la longueur de la réponse, force le statut HTTP 200 et supprime l’en-tête Accept-Ranges.

La suppression d’Accept-Ranges empêche le client de demander des portions spécifiques du fichier. Elle réduit ainsi le risque que des différences de taille ou de comportement de la réponse révèlent l’altération.

La sélectivité est au cœur de l’opération. Les utilisateurs ordinaires, les scanners et les systèmes automatisés peuvent recevoir du contenu légitime, tandis que seules les cibles désignées voient la page manipulée. Une vérification ponctuelle du site risque donc de ne rien détecter.

Le canal C2 disparaît des statistiques du répartiteur

Une requête vers un chemin d’image spécifique active le mode command-and-control. La connexion se termine directement sur le HAProxy compromis et n’atteint pas les serveurs backend.

Pour la dissimuler, ted décrémente les compteurs de connexions actives du répartiteur. L’échange n’apparaît donc pas dans les statistiques natives de HAProxy, tandis que les serveurs backend ne peuvent pas l’enregistrer puisqu’ils ne reçoivent pas la requête.

Le corps contenant la commande est écrit dans un named pipe placé sous /tmp. Après utilisation, le canal de la requête est remis à zéro. La sortie de la commande est renvoyée à l’opérateur sur le socket brut, précédée d’un en-tête courant HTTP/1.0 200 OK.

Par ce canal, les attaquants peuvent :

• envoyer des balises de communication ;
• téléverser et télécharger des fichiers ;
• exécuter des commandes shell ;
• remplacer la configuration de ted.

Le résultat est un canal C2 camouflé dans le trafic web et soustrait aux principales sources de télémétrie du service. Sa détection nécessite donc de comparer HAProxy à des données indépendantes, telles que des flux réseau capturés depuis l’extérieur du serveur.

Persistance, effacement des traces et vol de mots de passe

Le toolkit comprend un stager qui ne lance l’installation que s’il détecte HAProxy ou cron déjà en cours d’exécution. Il vérifie également qu’il dispose des privilèges root avant de poursuivre.

Une fois actif, il écrase le binaire légitime crond et attribue à son remplaçant l’horodatage de création associé à /usr/bin/ssh. Cette manipulation vise à rendre plus difficile la détection de l’introduction d’un nouvel exécutable.

ted modifie également les traces laissées pendant l’installation. Dans l’historique Bash de root, il supprime les termes tmp, wget, cron et crond ; les mêmes mots sont retirés de six journaux système, dont auth.log et audit/audit.log.

L’absence de ces chaînes ne signifie donc pas que l’activité n’a pas eu lieu. Les lacunes temporelles, les lignes incohérentes ou les différences par rapport à des copies centralisées des journaux peuvent être plus révélatrices qu’une simple recherche textuelle.

Rapid7 a également identifié un composant sshd trojanisé capable de capturer des mots de passe en clair, de les chiffrer et de les enregistrer dans un chemin fixe. Un code similaire est apparu dans des versions altérées de agetty, atd et polkitd.

L’opération va donc au-delà de la manipulation du trafic web. Elle comprend des mécanismes de persistance, du contrôle à distance, la collecte d’identifiants et la modification de plusieurs composants fondamentaux du système.

Le toolkit est également associé à curlRAT, un cheval de Troie d’accès à distance qui émet normalement une balise de communication toutes les 12 heures. Un indicateur contrôlé par l’opérateur réduit cet intervalle à 30 secondes. Le malware interrompt son exécution s’il ne trouve pas un fichier marqueur confirmant la virtualisation de l’hôte.

curlRAT ne doit pas être confondu avec CurlBack RAT, une famille distincte attribuée à SideCopy, un groupe lié au Pakistan.

Une attribution nord-coréenne qui reste incertaine

Les victimes connues sont deux organisations sud-coréennes actives dans les secteurs automobile et des médias. On ignore quand la compromission a commencé et comment les opérateurs ont obtenu leur premier accès.

Une piste possible concerne un portail Groupware exposé sur Internet. ENKI avait documenté une compromission antérieure, attribuée à Kimsuky, visant un fournisseur coréen de logiciels collaboratifs au moyen d’une vulnérabilité dans un serveur de messagerie. Aucune preuve directe ne permet toutefois d’affirmer que le même vecteur a été utilisé dans les cas analysés par Rapid7.

L’attribution, établie avec un niveau de confiance moyen, repose sur plusieurs éléments : des domaines associés à APT37, un modèle de diffusion rapproché de celui de Lazarus et l’hypothèse d’un accès initial lié à Kimsuky.

Une évaluation de Mandiant datant de 2023 décrivait les opérations nord-coréennes comme caractérisées par le partage d’outils et le chevauchement des cibles entre différents clusters. Ces recoupements expliquent pourquoi les indicateurs peuvent pointer simultanément vers plusieurs groupes.

La méthode rappelle également Operation SyncHole, au cours de laquelle les visiteurs de sites d’information sud-coréens étaient filtrés côté serveur puis redirigés. Kaspersky avait estimé, avec un niveau de confiance moyen, que la destination pouvait exécuter du code malveillant en exploitant une vulnérabilité de Cross EX.

Dans le cadre d’une autre activité, AhnLab et ENKI WhiteHat avaient décrit en juillet une campagne de watering hole reposant sur des sites sud-coréens compromis et visant le client de signature AnySign4PC. La comparaison révèle une continuité dans les techniques de sélection des victimes, mais ne prouve pas que les opérations soient le fait du même acteur.

Indicateurs à rechercher et priorités de réponse

Les indicateurs présents sur le disque comprennent :

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

Les empreintes SHA-256 publiées sont les suivantes :

• 72e70936f0dbe459142a1d867617c35f8d0cce5d18c6a49e1090a2a5adc8e558
• 4bb923eb040aa13ca8fd409c31ee4729c60ddff32e350efe1c5a4a9168a065f5

Les six domaines associés à l’activité sont :

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

Au 4 septembre 2026, aucun ne semblait être résolu par Google Public DNS : les requêtes pour les enregistrements A et NS renvoyaient NXDOMAIN. Il s’agit donc surtout d’indicateurs utiles à l’analyse rétrospective des journaux DNS, des proxys, des pare-feu et des flux réseau, plutôt qu’au blocage du trafic actuel.

La réponse doit commencer par l’isolement de l’hôte et la vérification des binaires par rapport à des copies obtenues auprès de sources fiables. Il faut contrôler non seulement HAProxy, mais aussi crond, sshd, agetty, atd et polkitd.

Il convient également de rechercher des named pipes anormaux dans /tmp, des modifications de l’historique de root, des nettoyages sélectifs des journaux et des connexions qui ne sont pas reflétées par les compteurs de HAProxy. L’analyse mémoire peut permettre d’identifier du code ou des structures inhabituelles résidant dans les processus.

La réinstallation du seul répartiteur ne suffit pas. Étant donné l’implication de composants privilégiés et le vol de mots de passe, la remédiation doit inclure la rotation des identifiants potentiellement exposés et, lorsque l’intégrité de l’hôte ne peut pas être démontrée, la reconstruction du système à partir de sources fiables.