Sommario
L’analisi di XLab inquadra MystroDX come una backdoor avanzata per Linux capace di operare in dual-mode e di eludere i controlli con crittografia multilivello e offuscamento accurato. L’osservazione iniziale parte dal 6 giugno 2025, quando il sistema Cyber Threat Insight and Analysis rileva traffico dall’IP 139.84.156.79 che distribuisce un ELF sospetto denominato dst86.bin. I motori tradizionali lo scambiano per Mirai con un tasso di rilevamento minimo su VirusTotal (4/65), mentre il modulo AI di XLab non lo segnala in prima istanza, spingendo a un’investigazione manuale che rivela un dropper per MystroDX. Implementata in C++, la backdoor combina file management, reverse shell, SOCKS proxy e port forwarding, abilita in modo dinamico TCP o HTTP per il C2, può attivare o disattivare la cifratura AES e mantiene la persistenza con un guardian dual-process che riavvia i componenti se interrotti. La combinazione di XOR a singolo byte, algoritmo transform proprietario e AES-CBC complica l’analisi, mentre la modalità passiva basata su RAW socket riduce l’impronta di rete. Il quadro che emerge descrive una minaccia stealth, resiliente e fortemente configurabile, progettata per campagne durature con C2 multipli e IOC diversificati.
Origini della campagna e primo avvistamento
L’innesco parte da 139.84.156.79, nodo dal quale viene servito un eseguibile ELF per architetture x86 identificato come dst86.bin e, in alcune occorrenze, come dst-x86.bin. Gli scanner automatici classificano inizialmente il campione come variante Mirai, ma il basso detection rate e alcune anomalie semantiche nelle stringhe interne inducono XLab a un’analisi manuale che identifica un dropper orientato all’installazione di MystroDX. La scelta di mascherare il codice con etichette riconducibili a famiglie IoT botnet note non è casuale: serve a deviare il triage verso categorie a bassa priorità, guadagnando tempo per la propagazione.
Architettura della backdoor e modello operativo
Il nucleo in C++ espone un set di funzionalità tipiche di una backdoor modulare. La gestione file copre upload e download con possibilità di esfiltrare dati sensibili e di caricare ulteriore strumentazione. La reverse shell fornisce un canale interattivo per eseguire comandi remoti, mentre il SOCKS proxy consente tunneling del traffico attraverso l’host compromesso per raggiungere risorse interne. Il port forwarding funge da ponte tra servizi locali e gli operatori esterni, aggirando controlli firewall che altrimenti bloccherebbero le connessioni in ingresso. Le feature vengono abilitate dal file di configurazione cifrato: la backdoor non espone necessariamente l’intero arsenale, ma solo i moduli richiesti per lo scenario operativo, riducendo la superficie di osservazione.
Catena d’infezione e infrastruttura di distribuzione
La distribuzione di dst86.bin avviene via HTTP dal server su 139.84.156.79 utilizzando l’URL http://139.84.156.79/dst-x86.bin. La telemetria limita la visibilità sui vettori iniziali, ma l’impianto lascia spazio a più ipotesi coerenti con l’evidenza: phishing con link a watering hole compromessi, abuso di pagine o script vulnerabili, oppure catene supply chain su software terzi. Una volta eseguito, il dropper scarica e installa la backdoor, configura i processi di persistenza, imposta la comunicazione C2 e si occupa di ripulire eventuali tracce superficiali, riducendo la finestra di rilevamento nelle fasi iniziali.
Crittografia multilivello e offuscamento
La strategia di evasion si appoggia a tre livelli principali. Le stringhe riconducibili a VM e strumenti di debug — termini come “vmware”, “vbox”, “gdb” o “lldb” — sono protette con XOR a singolo byte, soluzione leggera ma efficace contro il pattern matching ingenuo. Chiavi AES, payload e pacchetti trigger impiegano un algoritmo transform proprietario che riconfigura i dati con operazioni ripetute, allontanandoli dalle firme note. La configurazione vera e propria è cifrata con AES in modalità CBC, scelta che aggiunge randomizzazione tramite IV e confonde i diff binari tra varianti. Questo impianto rende la static analysis meno fruttuosa e costringe i difensori a un approccio behavioral, basato su telemetria e traffico.
AES-CBC, padding e gestione chiavi
La CBC protegge l’ordine dei blocchi e richiede padding; MystroDX usa padding a 8 byte, conserva la lunghezza del plaintext e applica una chiave presente nella configurazione. L’abilitazione dinamica della cifratura sul canale C2 avviene on-demand, così da iniziare in chiaro quando occorre mimetizzarsi e poi passare a AES con il comando idoneo, riducendo la finestra in cui un IDS può apprendere firme.
Modalità dual-mode: attivo e passivo
Il Backdoor Type comanda il comportamento. In modalità attiva la backdoor stabilisce connessioni outbound verso i C2 e resta in ascolto di istruzioni; è la scelta preferita quando l’ambiente consente traffico in uscita verso Internet senza eccessive restrizioni. In modalità passiva la backdoor non apre porte visibili: utilizza RAW socket per sniffare il traffico e attende pacchetti di attivazione validati da un magic a 4 byte, con campi per protocollo e porta e payload cifrato via transform. Tra i trigger risultano DNS e ICMP, vettori che attraversano spesso i perimetri con meno ispezioni. Questa configurazione abbatte la visibilità di rete e rende i port scan inefficaci.
Attivazione remota e riduzione dell’impronta
La sequenza tipica in passive mode prevede il recapito del trigger al nodo infetto, la validazione del magic, la lettura dei campi protocol e port e, solo dopo, la connessione verso il C2. Così l’host controllato resta “freddo” fino al momento dell’operazione, limitando gli indicatori che un NIDS potrebbe correlare.
Protocolli di comando e controllo
Le comunicazioni C2 si appoggiano a TCP o HTTP in base alla configurazione, con possibilità di mimetizzare il traffico web. Il formato dei pacchetti è strutturato: length a 4 byte, main code a 4 byte, sub code a 4 byte, direction a 4 byte, quindi data. Quando la cifratura è attiva, l’header prevede prima la ciphertext length, poi la plaintext length con padding e infine il ciphertext. I main code categorizzano le funzioni: 1 per management generale, 2 per reverse shell, 5 per file management, 7 per encryption e 8 per SOCKS; i sub code raffinano il comportamento, per esempio 1 per beacon, 2 per upload info, 4 per heartbeat e 7 per enable encryption. La flessibilità del protocollo consente di alternare stealth e prestazioni senza cambiare binario.
End-point C2 e mimetismo del traffico
La campagna collega a più C2: airtel.vpndns.net:443 è associato al cluster neybquno, 149.28.130.195:443 al cluster zoufkcfr; si osservano anche 149.28.137.254:8010 e 149.28.137.254:8443, oltre a 156.244.6.68:443 e 185.22.153.228:443. L’uso di porte 443 e di HTTP aiuta a confondere il traffico nel flusso legittimo, specialmente dove i controlli si limitano alla porta e non al contenuto.
Persistenza a prova di riavvio con guardian dual-process
La persistenza usa nomi di processi che ricordano servizi storici, “chargen” e “daytime”, per mimetizzarsi tra i demoni di sistema. Il launcher e la backdoor si sorvegliano a vicenda: se uno termina, l’altro lo riavvia, preservando l’operatività anche dopo kill o crash. L’installazione imposta l’avvio automatico e la riconfigurazione al reboot, mantenendo il ciclo anche in presenza di aggiornamenti o pulizie superficiali. Questo schema alza l’asticella per l’eradication, perché richiede di neutralizzare entrambi i processi e di ripulire le chiavi di avvio in un’unica sequenza controllata.
Tecniche di evasione e anti-analisi
Le verifiche di VM e debugger modificano il comportamento quando vengono rilevate stringhe sospette, riducendo telemetria e attività per non tradirsi nelle sandbox. La passive mode azzera l’esposizione su porte locali, i processi mascherati riducono l’attrito con gli amministratori, e la cifratura selettiva copre porzioni del protocollo in funzione del rischio. Il basso detection iniziale su VirusTotal conferma che la combinazione di XOR, transform e AES-CBC, insieme a packaging credibile, è sufficiente a superare filtri signature-based non contestualizzati.
Indicatori di compromissione e telemetria utile
Gli IOC associano il downloader a http://139.84.156.79/dst-x86.bin con server su 139.84.156.79; i C2 includono airtel.vpndns.net:443 (cluster neybquno), 149.28.130.195:443 (cluster zoufkcfr), 149.28.137.254:8010, 149.28.137.254:8443, 156.244.6.68:443 e 185.22.153.228:443. Tra gli hash compaiono 5e3a2a0461c7888d0361dd75617051c6 e fa3b4d5fd1f6c995395244f36c18ffec per i dropper, oltre a un parziale 72d377fa8ccf attribuito al binario chargen. In ottica hunting risultano utili beacon e heartbeat regolari, l’uso di RAW socket senza bind su porte applicative, la comparsa di stringhe anomale nei log di sistema e la creazione di processi con nomi “chargen” e “daytime” fuori contesto.
Implicazioni per la difesa in ambienti Linux
La presenza di MystroDX obbliga a una postura behavioral su Linux, dove gli apparati EDR tradizionali sono spesso più rari rispetto al mondo Windows. L’adozione di sensoristica a basso impatto per process creation, network telemetry e file IO consente di correlare pattern come la generazione di RAW socket, il traffico HTTP fuori profilo e la creazione di processi specchio che si rilanciano. Sul fronte segreti, l’uso di DLP e linting nei ticket e nelle KB interne evita che token e chiavi finiscano in chiaro in casi di supporto, riducendo il valore informativo in caso di esfiltrazione. Sui perimetri è decisiva l’ispezione L7 per distinguere HTTP legittimo dai canali C2 travestiti, mentre in passive mode l’attenzione si sposta sui trigger DNS/ICMP con magic e sulla successiva connessione condizionata.
Rimozione sicura e controlli post-incident
L’eradication richiede di identificare e terminare sia “chargen” sia “daytime”, rimuovere le voci di avvio, cancellare la configurazione cifrata e verificare la riconfigurazione del resolver e delle rotte di rete. È consigliabile disconnettere temporaneamente l’host dai segmenti critici, acquisire immagini per la forensics, e solo dopo procedere alla bonifica per evitare riaccensioni dalla controparte.
Hardening preventivo e visibilità continuativa
La difesa preventiva abbina patching regolare, riduzione della superficie di attacco, principio del privilegio minimo e rotazione credenziali. La telemetria deve essere ridondata e a prova di tampering, con pipeline che replicano gli eventi verso storage immutabile. La baselining per host facilita l’individuazione di deviazioni fini, come l’apertura di RAW socket da processi che normalmente non li usano.
Disassemblare il protocollo di MystroDX
La robustezza di MystroDX non risiede solo nei moduli funzionali, ma nella ingegnerizzazione del protocollo e della configurazione. L’adozione di XOR per camuffare stringhe sensibili, di un transform proprietario per chiavi e payload, e di AES-CBC per il config crea un gradiente di complessità che spezza gli approcci signature-based e obbliga a strumenti di analisi dinamica. Il formato pacchetto con main code e sub code separa le intenzioni operative dalla transcodifica, permettendo una negoziazione del canale in base al rischio. La dual-mode con RAW socket e trigger DNS/ICMP rende la visibilità squisitamente event-driven: senza telemetria fine, il dwell time si allunga. Per comprimere la finestra di esposizione servono tre azioni concrete: profilare il traffico HTTP/TCP per riconoscere C2 mimetizzati, correlare la creazione di processi gemelli con schemi di riavvio reciproco e modellare gli indicatori di passive activation su ICMP/DNS con magic specifici. In assenza di questi presidi, la combinazione di persistenza duale, cifratura opzionale e modularità renderà la backdoor resiliente a lungo, con impatti che vanno dalla ricognizione silente all’esfiltrazione e al lateral movement.
