DeadLock sottrae i server C2 alla giustizia: i proxy ora vivono…

Microsoft Threat Intelligence ha pubblicato l'11 agosto 2026 l'analisi tecnica completa di DeadLock, gruppo ransomware attivo da luglio 2025 che ha rivendicato 96

{"main_topic":"ransomware","topics":["ransomware","blockchain","malware","cybersec","enterprise-ai"]}

Microsoft Threat Intelligence ha pubblicato l'11 agosto 2026 l'analisi tecnica completa di DeadLock, gruppo ransomware attivo da luglio 2025 che ha rivendicato 96 vittime, concentrandosi in Italia, Spagna, Polonia, Turchia e USA. La ricerca documenta per la prima volta a questa scala enterprise un modello di infrastruttura in cui gli indirizzi dei server di comando e controllo non risiedono su macchine fisiche sequestrabili, ma su smart contract della blockchain Polygon: aggiornabili dall'attaccante, immutabili per le forze dell'ordine, leggibili gratuitamente dalle vittime. La stessa architettura ospita il data leak blog via protocollo Wasabi, eliminando ogni dipendenza da hosting tradizionale.

Punti chiave

DeadLock utilizza due wallet Polygon identificati—0x8EF7c3e531d871D3B9D559722DE77EB1dEc19dAe per i proxy C2 e 0x757984507c82c8dA1d3969c535dB5706eEE6426C per i post del data leak blog—memorizzando indirizzi e contenuti su blockchain anziché su server.
L'HTML di recovery consegnato alle vittime esegue JavaScript che effettua chiamate eth_call read-only al contratto per recuperare l'indirizzo proxy attuale: zero costo di gas, nessuna transazione da tracciare forensicamente.
L'encryptor, scritto in Rust, adotta schema ibrido XChaCha20 con Curve25519 e chiave effimera per file: secondo Microsoft, non esiste percorso pratico di recovery crittografica senza la chiave privata dell'attaccante.
Il gruppo integra BYOVD—Bring Your Own Vulnerable Driver—sfruttando CVE-2024-51324 nel driver Baidu Antivirus per terminare processi EDR, con geofencing che innesca auto-eliminazione in sistemi con lingue dell'area CIS e persiano.

Come funziona l'indirection blockchain: nessun server da sequestrare

Il meccanismo centrale è un layer di indirizzamento che sostituisce DNS, CDN e server web con la blockchain pubblica. Il file RECOVERY_CHAT.<UID>.html—applicazione web single-page consegnata alla vittima post-encryption—contiene JavaScript che interroga lo smart contract Polygon all'indirizzo 0x8EF7c3e531d871D3B9D559722DE77EB1dDec19dAe. La chiamata eth_call, essendo read-only, non richiede gas né genera transazione on-chain. Restituisce semplicemente l'URL proxy corrente, al momento documentato come 138.226.236[.]51/prrq.php.

L'operatore DeadLock aggiorna il proxy con una normale transazione on-chain—pagando gas in MATIC—e tutte le vittime successive leggono automaticamente il nuovo indirizzo. Non esiste punto di fallimento centralizzato: nessun registrar da pressare, nessun hosting provider da notificare, nessun dominio da sinkhole. Il data leak blog segue la stessa logica, con contenuti ospitati su Polygon e accessibili via protocollo Wasabi, che offre browsing senza server web tradizionale.

Microsoft Threat Intelligence ha formulato la natura del problema in termini operativi: "This infrastructure model represents a meaningful evolution from traditional ransomware communication channels and poses new challenges for takedown efforts". La citazione è riportata nel report del 10 agosto 2026.

"DeadLock is the first financially motivated ransomware operation to use the technique as the core of a functioning double-extortion campaign against real enterprise targets at documented scale" — TechTimes/ReliaQuest, citando ricerca Microsoft e Group-IB

Il percorso storico: da EtherHiding al modello DeadLock

Group-IB aveva documentato per primo l'uso di EtherHiding da parte di DeadLock nel gennaio 2026, con contratti creati e aggiornati già in agosto e novembre 2025. La tecnica—precedentemente osservata in campagne Lazarus APT e nella botnet Aeternum—consiste nell'oscurare payload maligni dentro transazioni blockchain. DeadLock ne ha fatto tuttavia qualcosa di qualitativamente diverso: non mero hosting di payload, ma infrastruttura operativa persistente per un modello di doppia estorsione.

ReliaQuest ha identificato DeadLock come gruppo emergente più significativo tecnicamente nel secondo trimestre 2026. Cisco Talos ha associato il gruppo a tempi di attacco compressi—circa cinque giorni tra compromissione iniziale e encryption—e a crittografia sofisticata. Il dato delle vittime mostra convergenza tra fonti: TechTimes riporta "80+" vittime su leak site a luglio 2026, BleepingComputer conferma "80 vittime" nello stesso arco temporale, mentre Microsoft Threat Intelligence aggiorna a 96 rivendicazioni ad agosto 2026. La crescita è coerente con l'attività documentata da maggio 2026, quando DeadLock è apparso su Ransomware.Live.

L'encryptor Rust: architettura crittografica e contromisure anti-analisi

L'analisi tecnica di TechTimes, coerente con il report Microsoft, dettaglia l'implementazione crittografica. Per ogni file target, il malware genera chiave casuale a 32 byte e nonce a 24 byte per XChaCha20. Crea poi una coppia di chiavi effimera Curve25519, incapsula la chiave di file tramite crypto_box del progetto NaCl, e appende il ciphertext al file originale. Questo schema elimina qualsiasi shortcut matematico: secondo Microsoft Threat Intelligence, "there is no mathematical shortcut to decryption without the attacker's private key".

L'encryptor implementa inoltre throttling selettivo: sospende l'operazione se rileva memoria sopra il 29% o CPU sopra il 70%, probabilmente per evitare rilevamenti basati su spike di risorse. Per file sotto i 50 MB esegue encryption completa; per quelli più grandi adotta chunk intermittenti da 512 byte, preservando leggibilità parziale del contenuto senza compromettere l'irrecuperabilità strutturale.

Il meccanismo BYOVD sfrutta CVE-2024-51324—vulnerabilità nel driver Baidu Antivirus con CVSS 3.8 LOW secondo NVD—per terminare processi EDR. Il vettore richiede privilegi elevati, indicando che l'operatore dispone già di accesso amministrativo al momento dell'esecuzione.

Cosa fare adesso

Il modello DeadLock impone una riprogettazione delle strategie di detection e response. Le raccomandazioni seguenti derivano direttamente dalle tecniche documentate nelle fonti primarie.

Monitorare chiamate eth_call verso indirizzi smart contract sospetti: le query read-only verso wallet noti come 0x8EF7c3e531d871D3B9D559722DE77EB1dDec19dAe devono generare alert nel proxy web o nel network monitoring, essendo indicatore di contatto con infrastruttura DeadLock.
Analizzare gli artifact HTML post-encryption: il file RECOVERY_CHAT.<UID>.html è un'applicazione completa con embedded JavaScript, chat E2E via Session e logica blockchain: il suo hash e le sue connessioni di rete sono indicatori di compromissione altamente specifici.
Restringere l'installazione di messenger decentralizzati come Session: la fonte documenta l'uso di Session come canale parallelo di comunicazione con le vittime; il controllo dell'installazione e dell'uso aziendale riduce la superficie di contatto.
Controllare la presenza del driver Baidu Antivirus e relativi processi terminati: CVE-2024-51324 è documentata come vulnerabilità BYOVD attiva; la rilevazione del driver o di terminations anomale di processi EDR richiede investigazione immediata.

Il paradosso della decentralizzazione: arma a doppio taglio

La blockchain Polygon funziona esattamente come progettato: immutabilità, resistenza alla censura, accesso permissionless. Queste proprietà, sviluppate per eliminare intermediari fidati, diventano nel modello DeadLock proprio l'intermediario fidato del crimine. Non emerge—né nelle fonti primarie né in quelle di contesto—che Polygon Labs o exchange di criptovalute abbiano intrapso contromisure di congelamento sui wallet identificati.

La transizione da EtherHiding sperimentale a infrastruttura operativa enterprise apre una traiettoria che altri gruppi probabilmente seguiranno. Cry0 è già citato nelle fonti come gruppo con template simile. Entro fine 2026, il ransomware blockchain-native potrebbe non essere più anomalia ma segmento di mercato.

Il dossier non identifica vettori di accesso iniziale conclusivi, non determina l'identità degli operatori, non quantifica i pagamenti riscossi. Non emerge sovrapposizione infrastrutturale che colleghi DeadLock a Lazarus o ad APT nordcoreani: le analogie tecniche con EtherHiding non costituiscono attribuzione.

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

Fonti

Fonti e riferimenti