ClearFake usa WordlistLoader per distribuire Amatera e aggirare EDR e Chrome ABE

🛡️ Executive Summary

• ClearFake compromette siti legittimi, mostra FakeCaptcha e usa ClickFix per indurre la vittima a eseguire WordlistLoader tramite WebDAV e rundll32.
• WordlistLoader disattiva ETW, rimuove hook e ricostruisce shellcode nascosto come parole inglesi prima di caricare Amatera direttamente in memoria.
• Amatera 4.3.3-alpha1 aggira Chrome Application-Bound Encryption e gli hook EDR; bloccare ClickFix e monitorare WebDAV, rundll32 e anomalie browser riduce il rischio.

ClearFake introduce un nuovo loader nella propria catena di infezione e lo utilizza per distribuire Amatera, infostealer conosciuto anche come ACR Stealer e diventato negli ultimi mesi una presenza sempre più frequente sui sistemi Windows compromessi. La novità individuata da Gen Threat Labs è WordlistLoader, componente intermedio capace di nascondere il proprio shellcode sotto forma di comuni parole inglesi, ripristinare moduli alterati dagli strumenti di sicurezza e disattivare Event Tracing for Windows prima di consegnare il controllo ad Amatera. L’infezione parte però da una tecnica molto meno sofisticata: un falso CAPTCHA mostrato su siti legittimi compromessi convince la vittima a copiare ed eseguire personalmente il comando che avvia l’attacco.

ClearFake trasforma un sito legittimo in una pagina FakeCaptcha

La ricerca tecnica pubblicata da Gen Threat Labs descrive una campagna nella quale ClearFake continua a sfruttare siti Web legittimi compromessi per sovrapporre alla pagina un FakeCaptcha. Il JavaScript malevolo viene inserito inizialmente come blob Base64 e recupera ulteriori istruzioni da uno smart contract blockchain attraverso la tecnica EtherHiding, permettendo agli operatori di separare il sito violato dall’infrastruttura che decide quale codice eseguire. La stessa architettura era già comparsa nelle campagne in cui ClearFake utilizzava smart contract BSC Testnet per nascondere il C2.

Quando l’utente seleziona il falso pulsante “I’m not a robot”, entra nel flusso ClickFix: un comando viene copiato negli appunti e la vittima viene istruita ad aprire la finestra Esegui di Windows, incollarlo e premere Invio. Non viene quindi sfruttata una CVE del browser o di Windows. L’attaccante costruisce invece un percorso nel quale è la persona davanti al computer ad autorizzare l’esecuzione iniziale, modello ormai ricorrente nelle campagne ClickFix basate su falsi CAPTCHA e siti compromessi.

WebDAV, conhost e rundll32 portano WordlistLoader sul sistema

Il comando copiato negli appunti segue uno schema abbastanza stabile. conhost viene utilizzato in modalità headless per avviare un processo cmd nascosto, mentre pushd mappa una condivisione WebDAV remota. Una DLL viene quindi eseguita attraverso rundll32 richiamandone l’export Run. È proprio questa DLL a contenere WordlistLoader. Gen osserva che il meccanismo assomiglia a catene precedentemente documentate nelle quali venivano impiegati loader Python, ma la nuova campagna sostituisce quello stadio con un componente nativo progettato specificamente per aumentare l’evasione. La combinazione tra ClickFix e WebDAV è particolarmente efficace perché riduce la necessità di consegnare alla vittima un allegato tradizionale: l’utente avvia manualmente un binario recuperato da una risorsa remota, mentre strumenti Windows perfettamente legittimi gestiscono gran parte dell’esecuzione. Un comportamento simile era già emerso nel ClickFix che utilizzava Win+R e WebDAV per avviare una catena malware, confermando che la finestra Esegui è ormai diventata uno dei punti di ingresso preferiti delle campagne social engineering Windows.

WordlistLoader rimuove gli hook e spegne ETW senza patcharlo direttamente

Prima di ricostruire il payload, WordlistLoader esegue tre operazioni preparatorie. La prima impedisce l’avvio di più istanze attraverso un named event. Le altre due puntano direttamente alle difese. Il loader enumera tutti i moduli caricati nel processo, confronta le prime istruzioni delle funzioni esportate con copie pulite lette dal disco e, quando individua determinati jump introdotti da strumenti di monitoraggio, ripristina i byte originali. Lo scopo è eliminare gli hook in user mode che antivirus ed EDR possono utilizzare per osservare chiamate sensibili.

Il secondo meccanismo prende di mira ETW, Event Tracing for Windows. WordlistLoader imposta un hardware breakpoint su ntdll!NtTraceEvent e registra un Vectored Exception Handler: quando la funzione dovrebbe essere eseguita, viene generata un’eccezione single-step e il flusso viene reindirizzato verso uno stub che restituisce semplicemente STATUS_SUCCESS. L’evento non raggiunge quindi NtTraceEvent, ma il chiamante riceve comunque una risposta apparentemente corretta. La tecnica evita di modificare direttamente il codice della funzione ETW, rendendo meno banale l’individuazione attraverso controlli che cercano semplicemente patch note ai componenti di sistema.

Il shellcode è nascosto dentro normali parole inglesi

La caratteristica che dà il nome a WordlistLoader è il metodo scelto per codificare il shellcode. Ogni build contiene una lista di 256 parole inglesi differenti, dove la posizione della parola corrisponde a un valore byte compreso tra 0x00 e 0xFF. Una seconda sequenza di parole rappresenta il payload codificato. Il loader non deve quindi conservare un tradizionale blob di shellcode immediatamente riconoscibile: attraversa la sequenza, trova la posizione di ciascuna parola nella wordlist e scrive il relativo valore nel buffer di output. Il risultato finale è il codice macchina originale. Gen ha individuato anche una variante che sostituisce le parole con UUID, rappresentando questa volta il payload attraverso blocchi da 16 byte convertiti con UuidFromStringA. Il shellcode così ottenuto aggiunge un ulteriore livello di evasione: prima di decrittare lo stadio successivo esegue un lunghissimo ciclo artificiale progettato per consumare tempo e mettere in difficoltà emulatori e sandbox. Soltanto al termine di questa fase viene ricostruito un reflective loader che carica Amatera in memoria.

Amatera evolve rapidamente e complica l’analisi statica

Gen ha osservato Amatera passare dalla versione 4.0.2 Beta alla 4.3.3-alpha1 in pochi mesi, con modifiche concentrate soprattutto sull’evasione. Dalla serie 4.1 il malware implementa control-flow flattening e indirect control-flow obfuscation, aumentando drasticamente la complessità del binario. Anche l’API hashing viene frammentato: invece di utilizzare un unico algoritmo facilmente ricostruibile dall’analista, Amatera contiene decine di resolver quasi identici con costanti e sequenze multiply-rotate-XOR differenti. Lo stesso nome API può quindi produrre hash diversi a seconda del resolver che lo tratta. Anche le stringhe vengono cifrate attraverso una nuova routine e il malware inserisce persino modifiche artificiali dello stack pensate per mettere in difficoltà la ricostruzione automatica di strumenti come IDA. Non è un dettaglio cosmetico: più tempo serve per comprendere il campione, maggiore è la finestra durante la quale una nuova build può circolare prima che detection e firme vengano adattate. L’evoluzione ricorda quella degli infostealer distribuiti attraverso campagne ClickFix sempre più capaci di modificare fingerprinting, loader e infrastruttura, anche se Amatera applica questa pressione soprattutto al livello Windows e browser.

Heaven’s Gate aggira il percorso normalmente osservato dagli EDR

Amatera è un processo a 32 bit, ma sfrutta la presenza di Windows a 64 bit per effettuare chiamate di sistema attraverso percorsi meno convenzionali. Nelle nuove versioni il malware evita parte della catena standard ntdll e raggiunge il layer WoW64 attraverso wow64cpu!KiFastSystemCall, risolvendo autonomamente i syscall number. Per operazioni che richiedono accesso a processi browser a 64 bit utilizza invece Heaven’s Gate, tecnica che permette a codice 32 bit di passare temporaneamente alla modalità x64. Gen ha osservato Amatera costruire dinamicamente trampoline per syscall a 64 bit, individuando gadget syscall; ret dentro ntdll e creando mapping separati RW e RX per generare ed eseguire gli stub. Il vantaggio consiste nell’evitare gli entry point tradizionali sui quali gli strumenti di sicurezza possono avere installato hook. Questa scelta mostra che Amatera non è semplicemente uno stealer che enumera file e password: una parte rilevante dello sviluppo viene investita proprio nel rendere più difficile osservare le primitive utilizzate per accedere a memoria e processi.

Amatera aggira Application-Bound Encryption dentro Chrome

La capacità più delicata riguarda Application-Bound Encryption, ABE, protezione introdotta nei browser Chromium per rendere più difficile il furto delle chiavi usate per cookie e credenziali. Amatera aveva già implementato un bypass basato sull’iniezione dentro il processo browser, ma dalla versione 4.1 la tecnica viene profondamente modificata e assume caratteristiche molto simili a quelle osservate in Remus/Lumma. Il malware cerca nella memoria di Chrome una struttura collegata a os_crypt_async::Encryptor, identifica la v20_master_key protetta tramite CryptProtectMemory e inserisce nel browser un payload capace di chiamare CryptUnprotectMemory direttamente dal contesto autorizzato. In questo modo la protezione “same process” viene rispettata formalmente, ma è codice dell’attaccante a eseguire l’operazione dall’interno del processo corretto. Per avviare il payload Amatera non crea neppure un classico remote thread: utilizza PoolParty variant 7, inserendo un work item TP_DIRECT nel thread pool del browser tramite la relativa I/O completion port. L’attacco dimostra ancora una volta che ABE aumenta sensibilmente il costo del furto delle credenziali ma non rende impossibile un’infezione che abbia già ottenuto esecuzione locale.

Bloccare ClickFix resta più efficace che inseguire ogni nuova build di Amatera

Gen pubblica numerosi hash di WordlistLoader e Amatera, domini C2 e siti compromessi osservati durante le campagne, indicatori utili per hunting e risposta agli incidenti ma inevitabilmente semplici da ruotare. La difesa più efficace deve quindi partire prima del payload. Un browser o un sito legittimo non ha motivo di chiedere a un utente di premere Win+R, incollare un comando e avviarlo per superare un CAPTCHA. Bloccare questo comportamento attraverso formazione, protezione degli appunti e policy endpoint elimina direttamente il passaggio umano necessario alla catena. In ambito aziendale diventano inoltre particolarmente interessanti le sequenze conhost --headless → cmd → pushd verso WebDAV → rundll32, insieme a processi browser che ricevono mapping di memoria o attività anomale sul thread pool. L’esplosione di campagne come StopAndProtect, che sfrutta migliaia di siti WordPress compromessi per distribuire ClickFix e malware, dimostra perché concentrarsi soltanto sull’hash finale non sia più sufficiente. ClearFake cambia infrastruttura, WordlistLoader cambia rappresentazione del shellcode e Amatera continua a modificare le tecniche di evasione, ma l’intera catena dipende ancora da un momento molto riconoscibile: convincere la vittima a eseguire personalmente il comando dell’attaccante.