HAProxy trojanizzato in Corea del Sud: la backdoor ted intercetta traffico e nasconde il controllo remoto

Rapid7 Labs ha scoperto un toolkit Linux finora non documentato, incorporato in build alterate di HAProxy 2.8.12 presso due organizzazioni sudcoreane dei settori automotive e media. Il malware, chiamato ted sulla base dei simboli e delle stringhe di debug, consente di manipolare selettivamente le risposte HTTP, eseguire comandi e sottrarre credenziali.

Non si tratta di una vulnerabilità di HAProxy. Gli aggressori devono prima ottenere l’esecuzione di codice sul server e sostituire il binario legittimo del bilanciatore. La presenza dell’impianto prova quindi una compromissione più profonda del sistema, il cui vettore iniziale resta sconosciuto.

Rapid7 attribuisce l’operazione, con media confidenza, ad attori sponsorizzati dallo Stato nordcoreano. Le tracce tecniche si sovrappongono a infrastrutture e modalità operative associate ad APT37, Lazarus e Kimsuky, senza permettere un’attribuzione più precisa.

Le build compromesse dipendono da HAProxy 2.8.12

Entrambe le vittime eseguivano HAProxy 2.8.12, versione distribuita l’8 novembre 2024. ted non si limita ad affiancare il software: il binario HAProxy viene sostituito con una build trojanizzata contenente direttamente il codice dell’impianto.

Il malware accede alle strutture interne del programma usando offset fissi, specifici della release osservata. Rapid7 non ha determinato se altre build della serie 2.8 siano compatibili con lo stesso codice.

Questo vincolo offre un possibile elemento investigativo, ma non riduce la gravità dell’intrusione. Una diversa versione potrebbe richiedere agli attaccanti soltanto una ricompilazione o un adattamento degli offset, possibilità sulla quale non sono però disponibili evidenze.

La release corrente del ramo è HAProxy 2.8.28, pubblicata il 27 agosto 2026, sedici point release dopo quella compromessa. Il tracker del progetto elenca 529 bug presenti nella 2.8.12 e già corretti nel ramo 2.8, inclusi un problema critico e 16 classificati come major.

Aggiornare rimane necessario, ma non costituisce una bonifica. ted non sfrutta uno di questi bug e un sistema già infetto può conservare altri componenti malevoli anche dopo la sostituzione di HAProxy. Inoltre, una build ricompilata può mostrare la stessa stringa di versione del binario autentico.

La versione dichiarata, da sola, non prova nulla.

Non essendo stata individuata una falla del prodotto, non esiste in questo caso un identificativo CVE da correggere. Non si pone neppure il tema dell’inserimento nel catalogo KEV della CISA: l’attacco richiede una compromissione precedente e la sostituzione del software.

L’iniezione colpisce soltanto i visitatori selezionati

ted applica quattro controlli prima di modificare una risposta HTTP. La richiesta deve contenere uno User-Agent, mentre URL e Referer devono corrispondere ai pattern configurati dagli operatori.

Anche l’origine del client viene verificata. L’indirizzo deve essere incluso in una whitelist, tramite corrispondenza esatta o a livello di rete /24, salvo che la richiesta contenga una particolare chiave nel campo Accept-Language.

Quest’ultima agisce come lasciapassare: permette all’operatore di ignorare completamente il filtro IP. Può quindi essere usata per testare l’impianto o raggiungerlo da indirizzi non inseriti preventivamente nella configurazione.

Quando tutte le condizioni sono soddisfatte, il malware sostituisce il contenuto destinato al visitatore. Durante l’operazione riscrive il tipo e la lunghezza della risposta, forza lo stato HTTP 200 ed elimina l’header Accept-Ranges.

La rimozione di Accept-Ranges impedisce al client di richiedere porzioni specifiche del file. Riduce così la possibilità che differenze nelle dimensioni o nel comportamento della risposta facciano emergere l’alterazione.

La selettività è centrale nell’operazione. Utenti comuni, scanner e sistemi automatici possono ricevere contenuti legittimi, mentre soltanto gli obiettivi prescelti vedono la pagina manipolata. Un controllo sporadico del sito rischia pertanto di non rilevare nulla.

Il canale C2 scompare dalle statistiche del bilanciatore

Una richiesta verso uno specifico percorso immagine attiva la modalità di command-and-control. La connessione termina direttamente sull’HAProxy compromesso e non raggiunge i server backend.

Per occultarla, ted decrementa i contatori delle connessioni attive del bilanciatore. Lo scambio non appare quindi nelle statistiche native di HAProxy, mentre i backend non possono registrarlo perché non ricevono la richiesta.

Il corpo contenente il comando viene scritto in una named pipe collocata sotto /tmp. Dopo l’uso, il canale della richiesta viene azzerato. L’output del comando torna all’operatore sul socket grezzo, preceduto da una comune intestazione HTTP/1.0 200 OK.

Attraverso questo canale gli attaccanti possono:

• inviare beacon;
• caricare e scaricare file;
• eseguire comandi shell;
• sostituire la configurazione di ted.

Il risultato è un C2 mimetizzato nel traffico web e sottratto alle principali fonti di telemetria del servizio. Per rilevarlo occorre quindi confrontare HAProxy con dati indipendenti, come flussi di rete acquisiti esternamente al server.

Persistenza, cancellazione delle tracce e furto di password

Il toolkit comprende uno stager che avvia l’installazione soltanto se trova HAProxy oppure cron già in esecuzione. Prima di procedere controlla anche di disporre dei privilegi root.

Una volta attivo, sovrascrive il binario legittimo crond e assegna al sostituto il timestamp di creazione associato a /usr/bin/ssh. La manipolazione serve a rendere meno evidente l’introduzione di un nuovo eseguibile.

ted interviene anche sulle tracce lasciate durante l’installazione. Dalla cronologia Bash di root elimina i termini tmp, wget, cron e crond; le stesse parole vengono rimosse da sei log di sistema, inclusi auth.log e audit/audit.log.

L’assenza di queste stringhe non equivale dunque all’assenza dell’attività. Lacune temporali, righe incongruenti o differenze rispetto a copie centralizzate dei log possono essere più indicative di una semplice ricerca testuale.

Rapid7 ha inoltre identificato un componente sshd trojanizzato, capace di acquisire password in chiaro, cifrarle e salvarle in un percorso fisso. Codice analogo è comparso in versioni alterate di agetty, atd e polkitd.

L’operazione supera quindi la manipolazione del traffico web. Comprende persistenza, controllo remoto, raccolta di credenziali e alterazione di più componenti fondamentali del sistema.

Al toolkit è associato anche curlRAT, un remote access trojan che effettua normalmente il beaconing ogni 12 ore. Un flag controllato dall’operatore riduce l’intervallo a 30 secondi. Il malware interrompe l’esecuzione se non trova un file-marker che confermi la virtualizzazione dell’host.

curlRAT non deve essere confuso con CurlBack RAT, famiglia distinta attribuita a SideCopy, gruppo collegato al Pakistan.

Attribuzione nordcoreana ancora non definitiva

Le vittime note sono due organizzazioni sudcoreane attive nei comparti automotive e media. Non è noto quando sia iniziata la compromissione, né come gli operatori abbiano ottenuto il primo accesso.

Una possibile pista riguarda un portale Groupware esposto. ENKI aveva documentato una precedente compromissione, attribuita a Kimsuky, ai danni di un fornitore coreano di software collaborativo tramite una vulnerabilità in un server di posta. Non esistono però prove dirette che lo stesso percorso sia stato usato nei casi analizzati da Rapid7.

L’attribuzione con media confidenza combina elementi differenti: domini associati ad APT37, un modello di distribuzione avvicinato a Lazarus e l’ipotesi di accesso iniziale collegata a Kimsuky.

Una valutazione di Mandiant del 2023 descriveva le operazioni nordcoreane come caratterizzate dalla condivisione di strumenti e dalla sovrapposizione degli obiettivi tra cluster. Queste intersezioni spiegano perché gli indicatori possano puntare contemporaneamente verso più gruppi.

Il metodo ricorda anche Operation SyncHole, nella quale visitatori di siti d’informazione sudcoreani venivano filtrati lato server e reindirizzati. Kaspersky aveva valutato con media confidenza che la destinazione potesse eseguire codice malevolo contro una vulnerabilità di Cross EX.

In un’altra attività, AhnLab ed ENKI WhiteHat avevano descritto a luglio una campagna watering-hole basata su siti sudcoreani compromessi e diretta contro il client di firma AnySign4PC. Il confronto indica una continuità nelle tecniche di selezione delle vittime, non una prova che le operazioni appartengano allo stesso attore.

Indicatori da cercare e priorità di risposta

Gli indicatori su disco comprendono:

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

Gli hash SHA-256 pubblicati sono:

• 72e70936f0dbe459142a1d867617c35f8d0cce5d18c6a49e1090a2a5adc8e558
• 4bb923eb040aa13ca8fd409c31ee4729c60ddff32e350efe1c5a4a9168a065f5

I sei domini associati all’attività sono:

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

Al 4 settembre 2026 nessuno risultava risolvere tramite Google Public DNS: le interrogazioni per record A e NS restituivano NXDOMAIN. Sono quindi indicatori utili soprattutto per l’analisi retrospettiva di log DNS, proxy, firewall e flussi di rete, non per il blocco del traffico corrente.

La risposta dovrebbe partire dall’isolamento dell’host e dalla verifica dei binari rispetto a copie ottenute da canali affidabili. Occorre controllare non soltanto HAProxy, ma anche crond, sshd, agetty, atd e polkitd.

Vanno inoltre cercate named pipe anomale in /tmp, alterazioni della cronologia di root, ripuliture selettive dei log e connessioni non spiegate dai contatori di HAProxy. L’analisi della memoria può individuare codice o strutture estranee residenti nei processi.

Una reinstallazione del solo bilanciatore non è sufficiente. Dato il coinvolgimento di componenti privilegiati e il furto di password, la bonifica deve includere la rotazione delle credenziali potenzialmente esposte e, quando l’integrità dell’host non può essere dimostrata, la ricostruzione del sistema da sorgenti affidabili.