Interlock, il ransomware che entra dalla porta principale

L'origine

Interlock compare per la prima volta a fine settembre 2024. Nei due anni successivi colpisce aziende, università e infrastrutture critiche tra Nord America ed Europa. L'FBI è netto su un punto: non è spionaggio, non c'è una nazione dietro. Gli attori scelgono le vittime per opportunità, e la motivazione è il denaro.

C'è un dettaglio che ha attirato l'attenzione dei ricercatori: diverse analisi open source segnalano somiglianze tra Interlock e Rhysida, al punto che si ipotizza una derivazione o una condivisione di codice tra i due gruppi.

Ma la cosa che rende Interlock interessante da studiare non è la sua origine. È come entra.

Il vettore: quando l'utente è l'exploit

1. 01
   Sito legittimo

   gli attori compromettono un sito che i dipendenti visitano per lavoro
2. 02
   Finto aggiornamento

   mascherato da update di Chrome o di software di sicurezza
3. 03
   Finto CAPTCHA

   la pagina ha già messo negli appunti PowerShell in Base64
4. 04
   L'utente incolla

   apre Esegui e lancia il payload con le proprie mani

La stragrande maggioranza dei gruppi ransomware entra in tre modi: phishing con allegato, credenziali comprate, o vulnerabilità nota su un dispositivo perimetrale. Interlock ne usa uno atipico, tanto che l'FBI lo segnala esplicitamente come "uncommon method among ransomware groups": il drive-by download da siti legittimi compromessi.

Il funzionamento è questo. Gli attori compromettono un sito reale — uno che i dipendenti della vittima visitano normalmente, per lavoro. Su quel sito piazzano un payload mascherato da aggiornamento. All'inizio erano finti update di Google Chrome o Microsoft Edge. Poi, secondo Sekoia, il travestimento si è evoluto in qualcosa di più insidioso: finti aggiornamenti di software di sicurezza.

FortiClient.exe
Ivanti-Secure-Access-Client.exe
GlobalProtect.exe
Cisco-Secure-Client.exe
AnyConnectVPN.exe
Webex.exe
zyzoom_antimalware.exe

Guardate bene quella lista. Sono i nomi degli strumenti che il reparto IT dice ai dipendenti di tenere aggiornati. L'attaccante non sta aggirando la cultura della sicurezza aziendale: la sta usando come vettore. Un utente che vede "aggiorna il tuo client VPN" e clicca sta facendo, dal suo punto di vista, esattamente la cosa giusta.

ClickFix: il CAPTCHA che infetta

La seconda variante di initial access è ancora più elegante, e vale la pena capirla perché è ormai ovunque — la stessa tecnica è stata usata da Lumma Stealer e DarkGate.

Si chiama ClickFix e sfrutta un riflesso condizionato. All'utente compare un finto CAPTCHA: "verifica di non essere un robot". Ma invece della solita griglia di semafori, il CAPTCHA dà delle istruzioni:

1. Premi Windows + R
2. Premi CTRL + V
3. Premi Invio

L'utente non lo sa, ma la pagina gli ha già messo negli appunti uno script PowerShell codificato in Base64. Seguendo le istruzioni, apre la finestra Esegui e lancia il payload con le proprie mani, sul proprio account, senza alcun exploit.

Questo è il punto concettuale che rende ClickFix difficile da fermare: non c'è vulnerabilità da patchare. Nessun software si comporta in modo scorretto. L'antivirus non vede un exploit perché non c'è. Vede un utente che apre Esegui e lancia un comando — cosa che gli amministratori fanno dieci volte al giorno. In ATT&CK questa tecnica ha un ID dedicato, T1204.004 (Malicious Copy and Paste), e la sua esistenza dice molto: il framework ha dovuto creare una casella per "l'utente incolla da solo il proprio malware".

La catena d'attacco

Una volta eseguito il payload, la sequenza è metodica.

1. 01
   Persistenza

   un RAT nella cartella Esecuzione automatica, o una chiave Run "Chrome Updater"
2. 02
   Ricognizione

   sei comandi PowerShell legittimi di discovery in pochi secondi
3. 03
   Credenziali

   cht.exe e klg.dll, poi Kerberoasting verso i domain admin
4. 04
   Movimento laterale

   RDP, AnyDesk e PuTTY: tutti già in whitelist
5. 05
   Esfiltrazione e impatto

   AzCopy verso un blob Azure, poi conhost.exe cifra le VM

Persistenza

Il finto eseguibile di Chrome è in realtà un RAT. Esegue uno script PowerShell che deposita un file nella cartella Esecuzione automatica di Windows: da quel momento il RAT riparte a ogni login. In alternativa, gli attori modificano il registro aggiungendo una chiave Run chiamata — con una certa sfacciataggine — "Chrome Updater".

È masquerading da manuale (T1036.005): un nome che nessun amministratore guarderà due volte.

Ricognizione

Uno script PowerShell raccoglie il quadro della macchina. Nulla di esotico, tutti comandi legittimi:

WindowsIdentity.GetCurrent()   → chi sono            (T1033)
systeminfo                     → che macchina è      (T1082)
tasklist /svc                  → cosa gira           (T1007)
Get-Service                    → quali servizi       (T1007)
Get-PSDrive                    → quali dischi e share(T1082)
arp -a                         → chi c'è in rete     (T1016)

Nessuno di questi comandi è malevolo. È la sequenza a esserlo — sei comandi di discovery in pochi secondi, dallo stesso processo. Ed è esattamente lì che va costruita la detection.

Credenziali

Stabilito il controllo remoto, scaricano un credential stealer (cht.exe) e un keylogger (klg.dll). Il primo raccoglie login e URL dai browser (T1555.003), il secondo registra i tasti in un file chiamato conhost.txt — di nuovo, un nome che sembra Windows.

Da febbraio 2025 sono stati osservati anche Lumma Stealer e Berserk Stealer. Per arrivare agli account domain admin, i ricercatori Talos ipotizzano un attacco Kerberoasting (T1558.003).

Movimento laterale

Credenziali valide + RDP (T1021.001). Più AnyDesk per la connettività e PuTTY per gli spostamenti. Tutti strumenti legittimi, spesso già presenti e già in whitelist. È living-off-the-land: l'attaccante usa la vostra cassetta degli attrezzi.

Esfiltrazione

Qui c'è la scelta più astuta. Gli attori usano Azure Storage Explorer e AzCopy per caricare i dati su un blob Azure (T1567.002).

Perché funziona: il traffico verso Azure esce da quasi tutte le reti aziendali senza far scattare nulla. È Microsoft. È già in whitelist. Un DLP che blocca l'upload verso domini sconosciuti non batte ciglio davanti a un trasferimento verso *.blob.core.windows.net.

Impatto

Il binario di cifratura si chiama — inevitabilmente — conhost.exe, come il legittimo Console Window Host di Windows. Cifra con AES + RSA. Esistono encryptor per Windows, Linux e persino FreeBSD: quest'ultimo è una rarità, e suggerisce un interesse per appliance e sistemi che spesso non hanno EDR.

Un dettaglio operativo importante: Interlock cifra le macchine virtuali, lasciando host fisici e workstation intatti. Se il vostro EDR è installato sulle workstation ma non sulle VM, siete ciechi esattamente dove colpiscono.

Dopo la cifratura, una DLL (tmp41.wasd) eseguita via rundll32.exe cancella il binario di cifratura (T1070.004). Niente artefatto, niente analisi.

La nota di riscatto (!__README__!.txt) arriva via GPO — cioè usando l'infrastruttura di distribuzione dell'azienda stessa. Non contiene una cifra: solo un codice univoco e un indirizzo .onion. La doppia estorsione (T1657) è dichiarata, e il gruppo ha già dimostrato di pubblicare davvero i dati.

Detection: dove guardare

L'errore sarebbe cercare hash. Gli hash cambiano. I comportamenti no.

1. ClickFix lascia una traccia precisa. L'esecuzione via finestra Esegui popola RunMRU nel registro:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

Una voce in RunMRU che contiene powershell, -enc, o stringhe Base64 lunghe è un segnale ad altissima confidenza. Gli utenti normali non incollano PowerShell offuscato nella finestra Esegui. Questa singola regola intercetta ClickFix a prescindere dal payload.

2. PowerShell che genera processi figli anomali. powershell.exe che lancia rundll32.exe, o che scrive nella cartella Startup, o che modifica chiavi Run.

3. Nomi legittimi in posti sbagliati. conhost.exe vive in C:\Windows\System32. Se compare altrove, non è conhost. Stessa logica per cht.exe e klg.dll.

4. La sequenza di discovery. Sei comandi di ricognizione in rapida successione dallo stesso processo padre.

5. Traffico Azure anomalo. AzCopy o StorageExplorer.exe su un endpoint che non ha mai toccato Azure. Il volume in uscita conta più della destinazione.

6. EDR sulle VM. Non è una regola di detection, è un prerequisito. Interlock colpisce lì apposta.

Rimedi

CISA e le agenzie coautrici raccomandano queste misure. Le ho ordinate per rapporto efficacia/sforzo contro questa specifica catena:

Contro l'initial access — dove si vince davvero:

• Filtraggio DNS per bloccare l'accesso a siti e applicazioni malevoli
• Web application firewall per intercettare comandi o injection da domini sospetti
• Formazione degli utenti a riconoscere e segnalare social engineering. Contro ClickFix il messaggio è uno solo, e deve essere letterale: nessun sito web legittimo vi chiederà mai di premere Windows+R e incollare qualcosa. Mai. Chi lo chiede vi sta attaccando.

Contro l'esecuzione:

• Limitare command line e scripting dove non servono (CPG 2.N). Non tutti gli utenti hanno bisogno di PowerShell.
• EDR robusto su VM, sistemi e reti — con priorità alle VM, per i motivi visti sopra.

Contro il movimento laterale:

• Segmentazione di rete (CPG 2.F)
• MFA su tutti i servizi possibili, in particolare webmail, VPN e accessi a sistemi critici (CPG 2.H)
• Least privilege e audit degli account amministrativi (CPG 2.E)
• Accesso just-in-time: gli account admin restano disabilitati finché non servono davvero
• Filtrare il traffico impedendo a origini sconosciute di raggiungere servizi remoti interni

Per sopravvivere all'impatto:

• Backup offline, cifrati e immutabili (CPG 2.R) — immutabili è la parola chiave: un backup che l'attaccante può cancellare non è un backup
• Piano di ripristino testato (CPG 5.A) con copie in posizione fisicamente separata

Sul pagamento: le agenzie non incoraggiano a pagare. Pagare non garantisce il recupero dei file, e finanzia il prossimo attacco.

Cosa insegna Interlock

Il tema di questo dossier non è un malware. È che la catena d'attacco più efficace del 2025-2026 non contiene un solo exploit.

Un sito legittimo. Un CAPTCHA. Un utente che segue le istruzioni. PowerShell, che è preinstallato. RDP, che è già acceso. AnyDesk, che magari l'IT usa davvero. Azure, che è in whitelist. Nomi di file identici a quelli di Windows.

Non c'è una CVE da patchare in tutta la sequenza. E questo ribalta la priorità difensiva: contro Interlock, un programma di patching perfetto vi protegge molto meno di un utente che sa che nessun CAPTCHA chiede di aprire la finestra Esegui.