ClickFix nasconde il malware nella cache del browser e aggira Windows Run

🛡️ Executive Summary

• Una nuova campagna ClickFix inserisce il payload nella cache del browser mascherandolo da immagine PNG prima che la vittima esegua qualsiasi comando.
• Il comando incollato in Windows Run recupera il VBScript già presente sul dispositivo e avvia una catena PowerShell diretta al furto di credenziali.
• La tecnica riduce il valore dei controlli concentrati soltanto sui download e rende essenziale monitorare RunMRU, WScript, PowerShell e attività anomale nella cache.

ClickFix cambia ancora forma e sposta una parte decisiva della catena di infezione dentro un luogo normalmente considerato innocuo: la cache del browser. Microsoft Threat Intelligence ha individuato siti compromessi che precaricano un VBScript camuffato da immagine PNG prima ancora che l’utente venga convinto a eseguire il falso comando di verifica. Quando la vittima apre Windows Run, incolla il contenuto predisposto dagli attaccanti e preme Invio, il payload principale si trova quindi già sul dispositivo. La tecnica riduce la lunghezza del comando necessario, nasconde una parte del malware nel traffico ordinario del browser e prepara una catena successiva basata su PowerShell, injection e furto di credenziali.

ClickFix mette il payload nella cache prima che la vittima prema Invio

Nel rilievo pubblicato da Microsoft Threat Intelligence, un cluster di siti compromessi utilizza una variante di ClickFix nella quale la pagina precarica nella cache un contenuto presentato al browser come PNG. L’esca continua a seguire il modello ormai noto: una falsa verifica o un problema tecnico chiede all’utente di aprire Windows Run con Win+R, incollare il contenuto presente negli appunti ed eseguirlo. La differenza è che il comando non deve più contenere o recuperare direttamente l’intero payload iniziale. cmd.exe cerca invece nella directory del profilo del browser file con un determinato prefisso, confronta la loro dimensione con quella attesa dagli attaccanti e copia la voce corrispondente in %LOCALAPPDATA%\Temp\t.vbs, trasformandola di fatto in un VBScript eseguibile. Il vantaggio è duplice: il payload più voluminoso è stato già consegnato attraverso il normale caricamento della pagina e il comando inserito nella finestra Run può restare sotto i limiti di lunghezza dell’interfaccia Windows. L’evoluzione conferma quanto ClickFix sia diventato più di una semplice esca, dopo essere stato già utilizzato da attori nordcoreani, iraniani e russi nelle proprie campagne di accesso iniziale.

Leggi anche: APT36 usa ClickFix per infettare utenti Linux

VBScript apre la strada a PowerShell e al furto delle credenziali

Dopo l’esecuzione dalla cache, la catena non si ferma al VBScript. Lo script raccoglie informazioni sull’host attraverso Windows Management Instrumentation e recupera un secondo componente PowerShell, che a sua volta scarica ulteriori stadi. Microsoft ha osservato il caricamento di assembly .NET direttamente in memoria e l’iniezione di codice all’interno di un processo Windows legittimo, timeout.exe, utilizzato come contenitore per attività rivolte alle credenziali memorizzate nel browser e sul dispositivo. Ulteriore codice viene recuperato in memoria attraverso PowerShell e la persistenza viene rafforzata tramite componenti Python e attività pianificate.

La catena sfrutta quindi strumenti normalmente legittimi — cmd.exe, wscript.exe, PowerShell, compilatori .NET e processi di sistema — invece di dipendere da un singolo eseguibile facilmente classificabile come malevolo. È la stessa logica di mimetizzazione che rende efficaci molte campagne basate su strumenti amministrativi e contenuti apparentemente affidabili, un problema già evidente negli attacchi di SEO poisoning utilizzati per spingere gli utenti verso software e pagine manipolate.

La cache del browser diventa un livello di staging per il malware

Il passaggio più interessante non è la presenza di PowerShell, ormai ordinaria nelle intrusioni Windows, ma lo spostamento dello staging prima dell’azione esplicita dell’utente. Un sistema di sicurezza che ricostruisce l’infezione partendo dal momento in cui viene eseguito il comando può quindi non osservare il download del payload principale nello stesso intervallo temporale: il file è entrato nella cache durante la normale navigazione ed è stato successivamente individuato e ricopiato localmente. Questo separa consegna ed esecuzione e rende meno efficace una difesa concentrata esclusivamente sul blocco dei download sospetti. Non significa che il payload diventi invisibile. Restano tracce nella cache, nell’albero dei processi, nel registro RunMRU, nelle connessioni in uscita, nelle modifiche delle policy PowerShell e nelle attività pianificate. Cambia però il punto nel quale il SOC deve cercare. Il modello conferma la capacità di ClickFix di trasformare l’utente nel componente che chiude volontariamente la catena di esecuzione, evitando di affidarsi necessariamente allo sfruttamento di una vulnerabilità software.

Nessuna vulnerabilità Windows: l’attacco sfrutta fiducia e strumenti legittimi

È importante non confondere questa campagna con un nuovo bug di Windows o dei browser. ClickFix non deve superare una barriera tecnica se convince la vittima a eseguire personalmente il comando. Il sito compromesso prepara l’ambiente, il browser conserva il payload e l’esca sociale fornisce le istruzioni necessarie a recuperarlo dalla cache. Proprio questa caratteristica ha permesso alla tecnica di essere adottata tanto dal cybercrime quanto da gruppi legati ad attività statali: l’esecuzione appare inizialmente come una normale operazione dell’utente e utilizza binari presenti nel sistema. Microsoft non ha attribuito questa specifica campagna a un attore determinato né ha fornito un numero pubblico di vittime, quindi non esistono elementi per trasformare il cluster osservato in un’operazione attribuita. Il precedente utilizzo di tecniche analoghe da parte di gruppi come Sandworm deve essere trattato come contesto e non come prova, anche considerando la lunga storia dell’APT russo nell’abuso di malware e strumenti legittimi contro obiettivi strategici.

Continua con:

Malwarebytes denuncia: Lazarus ha compromesso Windows Update

Attacco alla catena di fornitura 3CX: client compromessi e minacce alla sicurezza

Per fermare ClickFix bisogna monitorare ciò che accade dopo il browser

La mitigazione parte da una regola elementare: un CAPTCHA non richiede l’apertura di Windows Run, PowerShell, Terminal o altri interpreti di sistema. Sul fronte aziendale, Microsoft raccomanda protezione cloud, web e network, application control e PowerShell script-block logging, ma la variante osservata rende particolarmente importanti le correlazioni comportamentali. Aperture anomale della finestra Run seguite da cmd.exe, ricerca ricorsiva nella cache del browser, creazione di file VBS temporanei, processi wscript.exe che generano PowerShell, modifiche della execution policy e nuove scheduled task costituiscono segnali più robusti del semplice controllo sull’arrivo di un file. La cache smuggling di ClickFix mostra quindi il limite delle difese costruite intorno al concetto tradizionale di download malevolo: il browser può aver già consegnato il payload prima che la vittima inizi materialmente l’infezione. Il vero evento da intercettare diventa la concatenazione tra comportamento dell’utente, strumenti amministrativi e riutilizzo di contenuti precedentemente memorizzati sul dispositivo.