ClickFix trasforma siti legittimi in trappole: cinque stadi PowerShell e Lua portano a MimicRAT

La campagna ClickFix intercettata da Elastic Security Labs mette in scena un cambio di paradigma che, per chi difende reti e endpoint, pesa più di mille “nuovi domini” messi in blacklist. Qui non si parla di una landing creata ad arte su un’infrastruttura effimera: il punto d’ingresso è un sito legittimo compromesso, e l’innesco non è un download che il browser può bloccare, ma un’azione “umana” guidata, con un comando che finisce negli appunti e viene eseguito dalla vittima. Il risultato è una catena malware a cinque stadi che parte da PowerShell offuscato, attraversa bypass di ETW e AMSI, passa da un loader basato su Lua che lavora in memoria e culmina in MimicRAT, un RAT nativo C++ progettato per mimetizzarsi nel traffico web e rimanere malleabile nelle mani dell’attaccante. Elastic individua la campagna all’inizio di febbraio 2026 grazie a telemetria endpoint che segnala esecuzione di PowerShell offuscato. Gli indicatori di compromissione iniziano a emergere pubblicamente l’11 febbraio 2026, e la campagna risulta ancora attiva. Il dettaglio che cambia il peso dell’evento è l’uso sistematico di siti fidati come veicolo, perché sposta la difesa dal perimetro “domini malevoli” alla capacità di riconoscere una catena di esecuzione che si appoggia a fiducia pregressa e a comportamenti comuni.

Siti legittimi come vettore: la fiducia diventa superficie d’attacco

La scelta tattica più efficace, in questo scenario, è far lavorare l’utente al posto del malware. ClickFix sfrutta siti compromessi in settori e aree geografiche differenti, alimentando una distribuzione più resiliente rispetto a infrastrutture create da zero. Se un dominio malevolo cade, la campagna prosegue altrove. Se un provider blocca un host, il vettore può spostarsi su un altro sito legittimo violato, mantenendo lo stesso copione. Il caso descritto da Elastic parte da bincheck.io, un servizio lecito di validazione BIN. Qui viene iniettato uno snippet JavaScript malevolo che carica uno script esterno da https://www.investonline.in/js/jq.php, ospitato su una piattaforma indiana di fondi mutuali compromessa. L’uso di un percorso che “suona” familiare e un nome che richiama librerie comuni non è decorazione: lo script finge di essere jQuery per ridurre sospetto e far sembrare normale la presenza di risorse esterne.

Da quel punto, la campagna introduce un’altra maschera: una falsa pagina di verifica Cloudflare. È un passaggio psicologico, prima ancora che tecnico. La verifica Cloudflare è diventata, per milioni di utenti, un gesto quotidiano. I criminali si agganciano a questa normalità e la trasformano in una procedura di esecuzione guidata.

La falsa verifica Cloudflare e l’abuso degli appunti

Il meccanismo ClickFix non deve convincere la vittima a scaricare un file. Deve convincerla a compiere un’azione che, a prima vista, sembra “risolvere” un problema. Lo script mostra una pagina che imita Cloudflare e copia negli appunti un comando PowerShell maligno. Poi istruisce l’utente a incollarlo ed eseguirlo tramite Win+R o direttamente in PowerShell.

Qui si vede la logica dell’aggiramento. Un download diretto può essere analizzato, bloccato, avvisato, isolato. Un comando eseguito manualmente, invece, si colloca in una zona più ambigua: non è un file scaricato, non passa necessariamente dagli stessi controlli e, soprattutto, è “autorizzato” dall’utente. È un abuso del concetto di consenso operativo: l’utente crede di completare una verifica, in realtà sta avviando l’attacco.

La campagna è costruita per essere globale. Il lure supporta 17 lingue, tra cui italiano, e localizza dinamicamente in base alle impostazioni del browser. Questo dettaglio spiega perché la catena può colpire “senza scelta” e senza targeting stretto, ma ottenere comunque esecuzione. Elastic segnala vittime che includono un’università con base negli USA e utenti di lingua cinese, un indizio della portata trasversale e della capacità di adattamento del social engineering.

La catena a cinque stadi: dalla riga PowerShell al RAT nativo C++

Una volta eseguito il comando, la campagna entra nella parte che interessa di più chi difende endpoint: la sequenza di stadi è progettata per ridurre visibilità e analisi, alternando script e componenti in memoria. Il primo stadio è un one-liner PowerShell offuscato che ricostruisce un dominio usando slicing di stringhe e aritmetica. Elastic descrive la ricostruzione del dominio xMRi.neTwOrk, con risoluzione verso l’IP 45.13.212.250, e cita un dominio alternativo WexMrI.CC sullo stesso indirizzo. L’offuscazione “mixed-case” qui non è estetica: è un modo per cambiare fingerprint e disturbare pattern basati su matching semplice. Il secondo stadio è uno script PowerShell più articolato, con offuscazione basata su conversioni aritmetico-ASCII e decoy, e soprattutto con una sequenza di bypass che rivela l’intento: ridurre la telemetria e disinnescare scansioni di contenuto. Il bypass di ETW avviene patchando il campo m_enabled di System.Diagnostics.Eventing.EventProvider a 0 via reflection. In parallelo, l’attacco interviene su AMSI, impostando amsiInitFailed a true in System.Management.Automation.AmsiUtils e patchando in memoria la routine di scanning con operazioni come Marshal.Copy per redirigere ScanContent. In termini pratici, il messaggio è che l’attore presume difese attive e opera come se dovesse attraversare endpoint moderni, non macchine “nude”. Nello stesso stadio, lo script decodifica un archivio ZIP in Base64, lo estrae in una directory sotto %ProgramData% con naming casuale e avvia zbuild.exe, per poi tentare la pulizia degli artefatti. Qui il pattern è quello della consegna controllata: creare lo stretto necessario sul disco e passare rapidamente a uno stadio che lavora in memoria. Il terzo stadio è un loader basato su Lua, un binario custom che incorpora un interprete Lua 5.4.7. Elastic evidenzia la decrittazione di uno script Lua incorporato via XOR, con routine nominata come fxh::utility::lua_script_xor_decrypt. Lo script Lua decodifica shellcode con un alfabeto Base64 personalizzato, alloca memoria eseguibile e invoca l’esecuzione attraverso funzioni Lua. Il punto operativo è uno: l’attacco evita la creazione di file e sposta il carico malevolo in memoria, riducendo l’efficacia di controlli file-based e complicando analisi post-mortem se l’endpoint non cattura la memoria o se i log vengono degradati dai bypass precedenti. Il quarto stadio è uno shellcode che, secondo Elastic, mostra somiglianze con firme Meterpreter e funge da loader riflettivo. Qui si intravede un approccio “modulare”: uno stadio intermedio che prepara il terreno e carica l’impianto finale, mantenendo flessibilità. Non serve che tutti gli stadi siano originali, serve che la catena nel suo complesso sia efficace e difficile da spezzare. Il quinto stadio è MimicRAT, un RAT nativo PE x64 compilato con toolchain MSVC e con metadata di compilazione che indicano una data recente, 29 gennaio 2026. Elastic sottolinea che non deriva direttamente da framework C2 noti, ma imita comportamenti e profili di strumenti come Cobalt Strike e Sliver, sfruttando profili HTTP malleabili per confondere la distinzione tra traffico legittimo e C2. Questo è un passaggio cruciale: l’obiettivo non è solo ottenere accesso, ma rendere difficile classificare quel traffico come “anomalo” a colpo d’occhio.

MimicRAT: profili C2 malleabili, token Windows e tunneling SOCKS5

MimicRAT è progettato per dare all’attaccante controllo operativo e movimento laterale. Elastic attribuisce al RAT capacità come furto di token Windows e tunneling SOCKS5, due elementi che, insieme, trasformano un’infezione in un punto di pivot. Il furto di token consente di impersonare contesti e avviare processi con privilegi di altri utenti o servizi. Il tunneling SOCKS5 consente di usare la macchina compromessa come proxy per raggiungere risorse interne, spostando la superficie d’attacco verso segmenti non esposti e rendendo più difficile attribuire le connessioni all’attore originale. La comunicazione avviene via HTTPS sulla porta 443, con traffico che imita analisi web legittima. Elastic descrive l’uso di header e cookie che ricordano navigazione comune e richiami a domini che suonano familiari, un classico schema per mescolare il C2 nel rumore di fondo del browsing. Il dettaglio che rende questo più insidioso è la “malleabilità”: profili e pattern possono cambiare per adattarsi all’ambiente della vittima e sfuggire a firme statiche. Elastic descrive anche un relay su CloudFront con dominio d15mawx0xveem1.cloudfront.net, un modo efficace per sfruttare infrastrutture cloud ampiamente utilizzate e quindi difficili da bloccare senza impatto collaterale. Il C2, in questo disegno, non è un singolo server facile da isolare, ma una sequenza di componenti che separa consegna iniziale e controllo post-sfruttamento.

Infrastruttura a cluster: consegna e post-sfruttamento separati

L’analisi di Elastic propone una suddivisione in cluster. Un Cluster A gestisce la consegna iniziale, usando IP come 45.13.212.250 e 45.13.212.251 e domini come xmri.network e wexmri.cc. Un Cluster B gestisce attività post-sfruttamento con un IP come 23.227.202.114 e dominio www.ndibstersoft.com. In mezzo, il relay CloudFront rende la catena più elastica. Questo tipo di separazione è significativo perché consente all’attaccante di cambiare rapidamente un pezzo senza riscrivere tutto. Se la parte di consegna viene bloccata, si sostituisce. Se il C2 viene attenzionato, si ruota. Se un componente viene attribuito e segnalato, si sposta la pressione altrove mantenendo la stessa logica di attacco.

La crittografia e la “normalità” del traffico

Elastic descrive un impianto che combina crittografia asimmetrica RSA-1024 e simmetrica AES, con chiavi derivate via SHA-256, e menziona anche l’uso di RC4 per parte del flusso. Al di là della scelta specifica degli algoritmi, il punto operativo è che la campagna non punta su “obfuscation da script kiddie”: vuole proteggere il canale, rendere più complessa l’ispezione e mantenere un comportamento coerente con software che, in apparenza, parla “web”. In un ambiente dove molte difese si basano su decrittazione TLS selettiva, ispezione proxy e analisi comportamentale, il fatto che il traffico sembri telemetria o analytics non è un trucco infantile. È un modo per alzare la soglia di confidenza richiesta prima di bloccare, perché bloccare “cose simili al browsing” spesso crea falsi positivi e attrito operativo.

Perché ClickFix funziona: bypass del browser, bypass della prudenza

ClickFix prende un problema reale della difesa moderna: il browser e l’endpoint sono diventati più bravi a bloccare download malevoli, ma l’utente resta un vettore di esecuzione potentissimo. Copiare un comando negli appunti e spingere la vittima a incollarlo è un modo per aggirare le protezioni “sul file” e spostare l’azione su un terreno dove la decisione umana viene manipolata. L’uso di siti compromessi aggiunge un secondo acceleratore: la reputazione. Se l’utente si trova su una piattaforma che considera affidabile, accetta più facilmente un passaggio di verifica. Se la pagina è localizzata nella sua lingua e appare coerente con il contesto, il cervello riduce il sospetto. E se la “soluzione” proposta è semplice, un copia-incolla, la probabilità di esecuzione sale. In questo senso, la campagna descritta da Elastic non è solo malware delivery. È un test di maturità su due fronti: l’educazione dell’utente e la capacità dell’organizzazione di rilevare PowerShell anomalo, bypass di ETW/AMSI, esecuzioni in memoria e traffico HTTPS che si mimetizza nel rumore. Quando questi elementi si sommano, la difesa basata su singole firme non regge.

Indicatori e tracce: l’artefatto non è solo un dominio

Elastic riporta indicatori specifici, includendo hash di payload e loader e una sequenza infrastrutturale che attraversa domini, IP e URL. Nel contesto difensivo, la tentazione è sempre quella di correre verso la lista IOC e alimentare blocchi. Qui, però, la sostanza è che la catena è costruita per ruotare. La parte più preziosa, spesso, non è il dominio di consegna, ma il pattern comportamentale: la combinazione tra PowerShell offuscato, patch di EventProvider, manipolazione di AmsiUtils, estrazione in %ProgramData%, esecuzione di un binario intermedio, loader Lua e shellcode in memoria. È questa sequenza, più dei singoli indicatori, che consente di intercettare varianti e campagne parallele. Non a caso, Elastic collega l’infrastruttura e i metodi a campagne ClickFix simili e cita documentazione di campagne analoghe attribuite in altri contesti, segnalando un ecosistema operativo che non vive su un singolo episodio.

Un RAT “custom” che imita il mainstream per confondere i sistemi

Il nome MimicRAT è quasi una dichiarazione. L’impianto “mima” pattern riconoscibili, non perché sia identico, ma perché vuole entrare nello spazio grigio tra traffico lecito e traffico tipico di framework noti. Questo consente all’attaccante di sfruttare due debolezze: la prima è che gli ambienti enterprise producono talmente tanto rumore che l’analisi deve essere selettiva; la seconda è che blocchi troppo aggressivi su pattern web possono causare impatti operativi immediati. Quando un RAT offre profili C2 malleabili, capacità di token theft e SOCKS tunneling, non serve che sia “più potente” di alternative note. Serve che sia abbastanza modulare da adattarsi al bersaglio e abbastanza discreto da restare vivo. Il fatto che Elastic rilevi metadata di compilazione recenti aggiunge un elemento di contesto: non è un vecchio pezzo riciclato, ma un’implementazione che evolve in tempo reale con la difesa.