ClickFix trasforma siti legittimi e strumenti di sistema in una catena di distribuzione malware
ClickFix usa falsi CAPTCHA Cloudflare su 17.000 siti per far eseguire comandi malevoli in PowerShell, sfruttando Polygon, Telegram e Steam.
Immagine illustrativa generata con AI
Oltre 17.000 URL mostravano falsi prompt di verifica
ClickFix è diventata una delle principali tecniche di accesso iniziale perché sposta l’azione decisiva da un exploit software alla vittima. Invece di compromettere il browser senza che l’utente se ne accorga, l’attacco lo convince a eseguire personalmente un comando.
Le indagini di CTM360 hanno individuato oltre 17.000 URL infetti che mostravano false pagine di verifica Cloudflare. Quando è stata preparata l’analisi, circa 3.000 di questi URL continuavano a distribuire l’esca.
Le pagine presentano problemi plausibili nel contesto: un test di verifica umana non riuscito, un errore di visualizzazione del browser, un documento inaccessibile o spazio di archiviazione insufficiente su un Mac. Viene quindi chiesto al visitatore di copiare un comando, aprire un’interfaccia di sistema, incollare il contenuto e premere Invio.
In alcuni casi, la pagina copia automaticamente il comando negli appunti. L’utente lo esegue poi tramite un’interfaccia legittima, per esempio PowerShell, Terminal, la finestra di dialogo Esegui di Windows, il prompt dei comandi o la barra degli indirizzi di Esplora file.
Questa sequenza è alla base dell’efficacia di ClickFix. Un utente autenticato avvia un’utilità nativa e firmata, eludendo così i controlli di sicurezza che si concentrano su allegati malevoli, download sospetti o exploit convenzionali del browser.
Microsoft ha attribuito a ClickFix il 47% degli incidenti di accesso iniziale gestiti nel 2025 dal team Defender Experts, rendendola la tecnica più diffusa in quel campione, davanti al phishing tradizionale. ESET ha rilevato un aumento del 517% nella prima metà del 2025, seguito da un ulteriore incremento del 108% tra la seconda metà del 2025 e la prima metà del 2026.
Nel marzo 2025, MITRE ha aggiunto questa tecnica con la denominazione T1204.004, User Execution: Malicious Copy and Paste. È associata a Windows, macOS e Linux.
L’attacco fa leva sui comportamenti, non su una versione vulnerabile del software
ClickFix non sfrutta una vulnerabilità software. CTM360 non ha assegnato né un identificativo CVE né un punteggio numerico di gravità, e non ci sono versioni di prodotti interessate da correggere.
Per lo stesso motivo, non è applicabile il trattamento previsto dal catalogo Known Exploited Vulnerabilities di CISA. Non esiste una scadenza per gli interventi di mitigazione KEV, perché l’attacco non dipende dallo sfruttamento di una vulnerabilità presente nel catalogo.
La campagna analizzata era configurata principalmente per Windows, ma questo non significa che ClickFix sia una minaccia limitata a Windows. Le impostazioni lato server includevano esche operative per macOS, tra cui un falso articolo di supporto Apple che prometteva di aiutare gli utenti a risolvere un problema di spazio insufficiente sul disco. Era presente anche uno slot di distribuzione per Linux, ma risultava vuoto nella configurazione esaminata. La distribuzione su dispositivi mobili era disattivata.
Dopo aver rilevato il sistema operativo e la versione del dispositivo, l’operatore poteva decidere che cosa mostrare a ciascun visitatore. Gli utenti Windows potevano ricevere una pagina di destinazione, gli utenti Mac un’altra, mentre ai visitatori da dispositivi mobili poteva non essere mostrato nulla di malevolo.
Tra le tecniche correlate ci sono FileFix e CrashFix. In queste varianti possono cambiare l’interfaccia e il pretesto, ma l’attacco continua a dipendere dalla capacità di convincere la vittima a trasferire istruzioni controllate dall’aggressore in un percorso di esecuzione locale considerato attendibile.
Campagne recenti hanno dimostrato che ClickFix può sfruttare la fiducia anche al di fuori dei normali siti web compromessi. In un altro incidente, un account Reddit verificato e dirottato è stato usato per diffondere annunci ClickFix rivolti agli utenti Windows e macOS.
Polygon, Telegram e Steam rendono i blocchi meno affidabili
Lo script esaminato da CTM360 sui siti compromessi non conteneva un dominio fisso controllato dall’aggressore. Al contrario, il browser della vittima inviava una richiesta gratuita e in sola lettura a uno smart contract sulla blockchain Polygon.
Il contratto restituiva un valore codificato che permetteva di risalire all’hostname dell’esca attiva in quel momento. Per il visitatore, il processo non richiedeva un wallet di criptovalute, pagamenti o transazioni sulla blockchain.
Nel corso di una giornata di osservazione, il contratto ha fornito tre diversi host per le esche, mentre i siti infetti sono rimasti invariati. Aggiornando il valore on-chain, l’operatore poteva reindirizzare tutti i siti coinvolti verso una nuova infrastruttura nel giro di pochi secondi.
Questa architettura riduce l’efficacia dei blocchi basati sui domini. I difensori possono rimuovere un hostname usato per l’esca, ma le pagine compromesse possono recuperare quello sostitutivo senza che l’aggressore debba modificare di nuovo ogni sito. Anche bloccare i servizi RPC della blockchain è problematico, perché si tratta di infrastrutture legittime e condivise, utilizzate da applicazioni non correlate.
Altre fasi della catena utilizzavano canali di risoluzione diversi. Le descrizioni dei canali Telegram e una pagina del profilo Steam potevano rivelare l’indirizzo di comando e controllo corrente del malware. La disattivazione di un singolo meccanismo, quindi, non avrebbe necessariamente interrotto l’intera catena.
Un sistema di distribuzione del traffico aggiungeva un ulteriore livello di resilienza. Interrogava l’operatore circa ogni 1,5 secondi e poteva decidere se mostrare le istruzioni malevole o contrassegnare silenziosamente il visitatore come verificato.
Ricercatori, crawler e sandbox automatiche potevano ricevere contenuti innocui, mentre i bersagli selezionati visualizzavano la sovrapposizione ClickFix. Inoltre, un cookie nascondeva la sovrapposizione ai visitatori di ritorno per 90 giorni, riducendo ulteriormente la probabilità che un’ispezione successiva riproducesse il percorso dell’infezione iniziale.
L’impronta digitale della macchina nasconde il payload finale
Il dropper recuperato includeva nel percorso di download un’impronta digitale della macchina codificata in base64. I dati raccolti comprendevano il GUID della macchina, il numero di serie del volume, il nome del computer, il produttore del BIOS, il modello del sistema, il processore grafico e il nome utente.
Queste informazioni permettevano al server di comando e controllo di identificare il computer che effettuava la richiesta prima di rilasciare la fase successiva. Il server poteva inviare un payload specifico per quella macchina, fornire contenuti diversi oppure non inviare alcun payload.
Il fatto che un’esecuzione in sandbox non rilevi nulla non dimostra quindi che un sito sia innocuo. Un ambiente automatizzato e la vera workstation di un dipendente possono ricevere risposte completamente diverse dallo stesso indirizzo.
CTM360 ha condotto due indagini indipendenti, basate su host e metodi diversi. In una delle due, gli analisti sono riusciti a seguire l’operazione solo fino al dropper, perché la fase di distribuzione successiva era subordinata all’impronta digitale della macchina.
La seconda indagine ha ricostruito la catena attraverso tre resolver basati su Telegram e due livelli di decrittazione AES. Alla fine ha recuperato Vidar Stealer, eseguito all’interno di un file binario Microsoft legittimo e firmato, tramite DLL side-loading.
Il DLL side-loading sfrutta il modo in cui un’applicazione cerca le librerie necessarie. Un eseguibile legittimo carica una DLL malevola collocata nel percorso in cui il programma si aspetta di trovare una dipendenza, permettendo al malware di essere eseguito nel contesto del file binario attendibile.
Entrambe le indagini hanno individuato la stessa struttura di API per la distribuzione del traffico. Per CTM360, è un indizio che le due operazioni utilizzassero lo stesso kit.
L’analisi di Sekoia del giugno 2026 sul framework ErrTraffic ha inoltre collegato il contratto Polygon a un cluster di operatori che, secondo quanto riportato, distribuisce esclusivamente Vidar. CTM360 ha valutato questa correlazione con un livello di confidenza moderato: il framework viene venduto a più affiliati per circa 380 dollari al mese, perciò l’infrastruttura e i confini dei cluster possono cambiare.
Il rapporto descrive inoltre ClickFix come una tecnica utilizzata da soggetti legati a Stati, ma non identifica alcun governo né attribuisce l’attività a uno Stato specifico.
La compromissione di WordPress può sopravvivere a una bonifica superficiale
I siti WordPress sono utili come infrastruttura di distribuzione perché combinano domini consolidati, certificati validi e traffico di visitatori autentici. Inoltre, potrebbero non essere sottoposti al monitoraggio continuo riservato ai sistemi aziendali più sensibili.
Nell’indagine a livello di host, PHP aggiungeva il loader malevolo a ogni risposta dinamica esaminata. Lo stesso contenuto compariva nelle pagine HTML, nei feed RSS e nell’output JSON.
Questo comportamento indicava la presenza di un plugin must-use di WordPress. Questi plugin vengono caricati automaticamente a ogni richiesta e non compaiono nell’elenco standard dei plugin, perciò è più facile che sfuggano a una normale verifica amministrativa.
Gli investigatori hanno inoltre trovato circa due dozzine di account amministratore creati da script. La combinazione di un’iniezione persistente lato server e numerosi account con privilegi elevati significa che eliminare un blocco JavaScript visibile, rimuovere pagine di spam o disattivare un singolo amministratore sospetto non basta a bonificare completamente il sito.
Non è stata individuata alcuna vulnerabilità di WordPress né alcuna versione del CMS interessata. I risultati descrivono installazioni compromesse e meccanismi di persistenza, non lo sfruttamento di una CVE di WordPress resa pubblica.
Gli amministratori che indagano su comportamenti simili dovrebbero controllare i plugin must-use, le modifiche PHP lato server, gli account amministratore inattesi e il contenuto iniettato in diversi formati di risposta. La bonifica deve eliminare sia l’iniezione di contenuti sia ogni percorso attraverso il quale l’aggressore potrebbe riottenere l’accesso.
I difensori dovrebbero interrompere la catena nei suoi punti critici
Gli hostname che cambiano rapidamente sono indicatori poco efficaci per contrastare questa attività. CTM360 individua invece quattro passaggi indispensabili per il successo della catena: scrivere le istruzioni negli appunti, avviare un interprete, consentirgli di connettersi a Internet ed eseguire malware che garantisce la persistenza, raccoglie dati o li esfiltra.
I browser gestiti possono bloccare per impostazione predefinita la scrittura negli appunti. L’esca può rimanere visibile, ma costringere l’utente a riscrivere manualmente un comando offuscato crea un ostacolo e può fermare la fase di preparazione dell’attacco.
Le organizzazioni possono anche instradare gli interpreti di script e le utilità a riga di comando con accesso alla rete attraverso un proxy autenticato. In questo modo è possibile interrompere la prima richiesta in uscita su Windows, macOS e Linux senza dipendere da un elenco aggiornato di domini malevoli.
I controlli sulle applicazioni dovrebbero limitare ciò che gli utenti interattivi possono avviare e le librerie che le utilità considerate attendibili possono caricare. Il monitoraggio dovrebbe concentrarsi su attività anomale degli interpreti, connessioni in uscita inattese da strumenti di sistema nativi, caricamento sospetto di DLL e comandi incollati nelle shell subito dopo l’attività nel browser.
La formazione degli utenti resta necessaria. Una pagina di verifica legittima, un visualizzatore di documenti, un aggiornamento software, una videochiamata o un articolo di supporto non dovrebbero chiedere di incollare un comando fornito da un sito in PowerShell, Terminal, nella finestra di dialogo Esegui o in un’altra interfaccia del sistema operativo.
Quella singola istruzione sostituisce l’exploit. Impedirne l’esecuzione, o rilevare l’attività che ne consegue, offre una difesa più duratura rispetto all’inseguimento di un’infrastruttura progettata per scomparire.
Fonti
Questo articolo è una rielaborazione originale basata sulle fonti seguenti.
