XCTDH adotta HashHiding: il C2 ora viaggia sugli indirizzi Ethereum

La campagna malware attribuita al gruppo nordcoreano XCTDH ha introdotto una tecnica denominata HashHiding che codifica indirizzi IPv4:port nei primi 6 byte dell'indirizzo destinatario di transazioni Ethereum ordinarie. La scoperta, documentata da Ransom-ISAC il 25 settembre 2026, aggiorna un'architettura già osservata nell'ottobre 2025 e riduce drasticamente la superficie tracciabile del command and control. Il metodo è complementare al precedente sistema TxDataHiding su TRON, Aptos e BSC: non lo sostituisce, ma lo affianca come canale di segnalazione a bassissimo impatto on-chain.

Da payload pesanti a segnali minimalisti: l'evoluzione della catena di comando

La transizione tecnica è misurabile nel confronto tra le due generazioni documentate da Ransom-ISAC. Nell'ottobre 2025 la campagna impiegava TxDataHiding: payload embedded in transazioni su blockchain multiple, con estrazione che richiedeva parsing di dati on-chain voluminosi. Il RAT DEV#POPPER.js contava circa 530 linee.

A settembre 2026 il file è cresciuto a circa 2.500 linee, ma la novità strutturale sta nell'unificazione: RAT, dropper e modulo HashHiding convergono in un singolo endpoint /init, dove in precedente la struttura era parallela. Il modulo _Z viene estratto incondizionatamente dal RAT e concatenato a ogni processo figlio spawnato. Secondo Ransom-ISAC, il codice recita NtuXTb = ZtoHUM._I?._Z con un flag anti-double-run global._t_h, ma nessun gate condizionale ne limita l'esecuzione. Il componente opera come processo background detached e hidden.

La scansione dei blocchi segue una progressione esponenziale: offset 0, 1, 2, 4, 8, fino a 4096×256. Questo permette al malware di localizzare rapidamente l'ultima transazione del wallet controllato dall'attaccante, decodificare il C2 e recuperare il bootstrap code. Il valore trasferito nelle transazioni HashHiding è trascurabile: tra 0 e 150 wei, comunemente definito "valore bruciato".

Decodifica dimostrabile: come 20 byte nascondono 6 byte utili

L'indirizzo Ethereum è uno spazio di 20 byte (40 caratteri esadecimali). HashHiding sovrascrive i primi 6 byte con IPv4:port, lasciando i restanti 14 byte casuali o strutturati. La decodifica è verificabile con codice deobfuscato: tx.to.substring(2,10).match(/.{2}/g).map(h => parseInt(h,16)).join('.') produce l'indirizzo IP.

L'indirizzo 0xB5D6959401bbb5D69594005000ff8C84e0b715b1 decodifica in 181[.]214[.]149[.]148:443. La fonte sottolinea che l'indirizzo è "fabricated": nessuno detiene la chiave privata corrispondente, rendendo il destinatario pura funzione di trasporto. Ransom-ISAC ha pubblicato una recipe dimostrativa su CyberChef per replicare la trasformazione. OpenSourceMalware ha documentato la tecnica sottostante come "NullReceiver" nell'agosto 2026, prefigurandone l'adozione operativa.

Quattro rotazioni C2 sono state osservate nel periodo di raccolta. La resilienza deriva dalla velocità di aggiornamento: un'unica transazione dal wallet segnale reindirizza l'intera botnet senza modificare il codice sulle macchine compromesse.

"HashHiding takes a fundamentally different approach. Instead of hiding large payloads in transaction data, it encodes an IPv4 address and port, six bytes in total, directly into the to address of plain Ethereum coin transfers. No smart contracts, no calldata, no input data." — Ransom-ISAC (via CyberPress)

Perché le difese tradizionali smarriscono il bersaglio

La tecnica sottrae il C2 ai punti di controllo convenzionali. Le blocklist IP diventano obsolete per definizione: l'indirizzo cambia con una transazione, il wallet rimane costante. Il filtraggio DNS è aggirato perché la risoluzione avviene on-chain, non su server ricorsivi. I proxy web e i firewall applicativi non intercettano transazioni Ethereum native.

Il costo operativo per l'attaccante è prossimo allo zero. Le commissioni di gas su Ethereum sono irrisorie per trasferimenti da 0 wei, e la pseudonimità della blockchain offre un livello di indirezione. Rispetto a EtherHiding o tecniche di embedding in smart contract, HashHiding elimina la complessità del deploy e della verifica del codice: la transazione è ordinaria, indistinguibile da qualsiasi altro trasferimento a basso valore.

Il limite per i difensori è che il segnale esiste in un dominio al di fuori dell'infrastruttura aziendale monitorata. Il wallet 0x33ff...9891 è pubblico, tracciabile, ma il SOC medio non è strumentato per correlare connessioni HTTP sospette con transazioni on-chain.

Cosa fare adesso

• Monitorare on-chain il wallet noto 0x33ff3edaf55a8e03dcbc7cb40d498a49cd499891 e i pattern di indirizzo destinatario con prefisso decodificabile come IPv4:port
• Correlare nel SIEM connessioni HTTP outbound verso IP decodificabili da transazioni Ethereum con origine in host interni non autorizzati a operare con criptovalute
• Analizzare processi Node.js o JavaScript che eseguono scansioni di blocchi con offset esponenziali o che interagiscono con endpoint RPC Ethereum senza business case documentato
• Reperire e verificare il modulo _Z nelle immagini DEV#POPPER.js, riconoscendolo dal pattern di deobfuscation base-91 + CFF e dalle dimensioni caratteristiche (circa 69.500 caratteri offuscati)

La continuità che tradisce: stesso attore, architettura ridefinita

L'indirizzo contratto BSC 0x9bc1355344b54dedf3e44296916ed15653844509 è identico tra ottobre 2025 e settembre 2026. Questa costante è l'elemento più affidabile di continuità infrastrutturale, in un ecosistema dove tutto il resto muta. La campagna non è una reinvenzione: è un'ottimizzazione.

Il passaggio da TxDataHiding a HashHiding come canale primario di segnalazione C2 riflette una maturazione operativa. Gli attaccanti hanno compreso che il peso del payload on-chain è un rischio di rilevabilità: meno dati si immagazzinano sulla blockchain, meno superficie lasciano agli analisti. Il segnale minimalista è anche più difficilmente censurabile: nessuna piattaforma da segnalare, nessun contratto da disattivare, solo un indirizzo che emette transazioni ordinarie.

Cosa rimane fuori dal perimetro documentato. Il dossier non specifica il numero di vittime della componente HashHiding né la loro distribuzione geografica. Non è chiaro il meccanismo esatto di attribuzione DPRK: indicatori geopolitici, sovrapposizione infrastrutturale o TTP condivisi. Non è documentato se esistano contromisure efficaci oltre il monitoraggio del wallet noto. E non è verificabile indipendentemente che l'indirizzo decodificato sia effettivamente privo di chiave corrispondente: la fonte lo afferma, ma la crittografia a curva ellittica non permette di dimostrarlo negativamente senza tentativo di firma.

La tecnica è ora nel registro pubblico. Il replicabile è il primo passo del difendibile.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://securelist.com/moviereaper-malware-torrent-odyssey-solana/121344/
• https://cyberpress.org/xctdh-hides-malware-c2-on-blockchain/
• https://ransom-isac.org/blog/xctdh-adopts-hash-hiding/