Dissezione dell'operazione CastleBot Malware-as-a-Service

IBM X-Force ha indagato su un framework malware emergente denominato CastleBot. Si ritiene che il malware faccia parte di un'operazione Malware-as-a-Service (MaaS) e che sia specificamente progettato per una implementazione flessibile di malware. CastleBot è attualmente utilizzato dai criminali informatici per distribuire di tutto, dagli infostealer alle backdoor come NetSupport e WarmCookie, che sono state collegate ad attacchi ransomware.

La caratteristica che rende CastleBot particolarmente preoccupante è il modo in cui viene distribuito: più spesso tramite installatori di software trojanizzati scaricati da siti web falsi, attirando utenti ignari a lanciare l'infezione con le proprie mani. Questa tecnica fa parte di una tendenza in crescita che X-Force sta osservando. Spesso CastleBot viene abilitato attraverso l'avvelenamento SEO, facendo in modo che le pagine dannose si posizionino più in alto nei motori di ricerca rispetto ai distributori di software legittimi. Una volta all'interno, CastleBot esegue un processo in tre fasi: uno stager/downloader, un loader e una backdoor core, che richiede una serie di compiti al suo server di comando e controllo (C2). Le informazioni raccolte dalla macchina infetta permettono agli operatori di filtrare facilmente le vittime, gestire le infezioni in corso e implementare malware su obiettivi di alto valore con precisione.

CastleBot è ancora in evoluzione e la nostra ricerca dimostra che probabilmente è solo l'inizio. In questo report analizziamo nel dettaglio come funziona, come si diffonde e perché è importante.

• CastleBot è un nuovo malware probabilmente operato come Malware-as-a-Service, che può essere utilizzato per fornire una vasta gamma di payload dannosi
• I payload successivi vanno da infostealer a backdoor collegate ad attacchi ransomware, come NetSupport e WarmCookie
• X-Force ha osservato che gli installatori di software trojanizzati sono il vettore di infezione più comune per diffondere CastleBot
• Il framework CastleBot comprende tre componenti: uno stager, un loader e un core e sembra essere in fase di sviluppo attivo
• Il malware sembra permettere agli operatori di filtrare facilmente le vittime, aggiornare payload e gestire più campagne durante il loro ciclo di vita

CastleBot è apparso per la prima volta all'inizio del 2025. X-Force ha notato un aumento del volume dei campioni e dei diversi payload a partire da maggio, e da allora ha osservato l’implementazione di vari payload backdoor e infostealer. Il vettore di infezione più comune di CastleBot è il software trojanizzato, che rientra in una tendenza che X-Force continua a osservare dal 2024. I pacchetti software trojanizzati e gli installatori vengono spesso distribuiti tramite siti web fasulli utilizzando l'avvelenamento SEO per attrarre le vittime. CastleBot veniva distribuito anche tramite il repositoryGitHub, impersonando software legittimo, e tramite la popolare tecnica ClickFix.

X-Force ha identificato tre componenti come parte del framework del malware CastleBot: uno stager, un loader e il core/backdoor di CastleBot.

Si noti che la precedente segnalazione pubblica di Prodraft si riferisce allo stesso framework malware di "CastleLoader".

Nella maggior parte dei casi, il componente core di CastleBot viene implementato tramite uno stager shellcode, che fa parte della stessa famiglia di malware CastleBot. Lo stager è un payload leggero shellcode che può essere iniettato da qualsiasi altro loader di primo stadio. X-Force ha osservato vari crypter utilizzati con CastleBot, tra cui Dave, un crypter basato su AutoIt, e semplici crypter compilati in C.

Il malware utilizza l'algoritmo di hashing DJB2 per risolvere le API necessarie in tempo di esecuzione. Prima di ogni chiamata API, carica la DLL corrispondente e attraversa la tabella degli indirizzi di esportazione (EAT) alla ricerca della funzione API tramite hash DJB2 generati in precedenza. Se l'esportazione viene inoltrata a un'altra DLL, lo stager analizza il nome DLL, lo carica e risolve la funzione tramite GetProcAddress.

Una volta eseguito, lo stager scarica due payload tramite HTTP con l'user agent "Googlebot". I percorsi URL sono simili tra i campioni e indirizzano lo stesso server C2 del componente core di CastleBot.

Esempio di URL per il download:

Entrambi i payload vengono decrittati tramite una stringa XOR hardcoded, in questo caso "GySDoSGySDoS" (codificato UTF-16), rivelando un PE (CastleBot Core) e uno stub di shellcode (CastleBot Loader).

Lo stager utilizza quindi VirtualProtect per abilitare l'esecuzione sull'heap della regione di memoria che memorizza il secondo payload shellcode decriptato. Quest'ultimo, agendo come loader, viene eseguito direttamente in memoria e riceve un puntatore al PE decriptato come argomento.

Il CastleBot Loader è un loader PE completo, che inizia mappando ogni sezione del PE fornito in una nuova regione di memoria assegnata tramite NtAllocateVirtualMemory. Prosegue effettuando le correzioni necessarie, risolvendo importazioni, impostando le opzioni di protezione della memoria appropriate ed eseguendo funzioni di callback TLS esistenti.

In particolare, il loader imposta anche una nuova struttura LDR_DATA_TABLE_ENTRY e i relativi LDR_DDAG_NODE (estesi in Windows 8 e successivi), che vengono poi aggiunti alle doppie liste collegate PEB_LDR_DATA contenenti i moduli caricati per ogni processo. Per gli agenti di rilevamento e risposta degli endpoint (EDR) che monitorano il PEB, questo farebbe apparire il payload iniettato come se fosse stato caricato legittimamente dal sistema operativo.

A meno che il file iniettato non sia una DLL, il campo ImageBaseAddress del PEB è anch'esso impostato come indirizzo base del payload iniettato.

Infine, per eseguire il payload, CastleBot Loader esegue il punto di ingresso o assegna una nuova console per applicazioni della console.

Nel campione analizzato sopra, il payload iniettato è la backdoor x86 CastleBot (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04).

CastleBot core utilizza lo stesso meccanismo di risoluzione API dei componenti stager e loader, tranne che per l'algoritmo di hashing, che è l'AP hash, sviluppato da Arash Partow.

Anzitutto, la backdoor inizia decifrando la propria configurazione. Quasi tutte le stringhe del binario, comprese quelle che fanno parte della configurazione, sono memorizzate come UTF-16 e decriptate in linea tramite una chiave XOR univoca da 4 byte per ogni stringa. Durante la decrittazione, viene creata la seguente struttura di configurazione:

Il malware tenta di creare un mutex, utilizzando il nome della configurazione, per assicurarsi che venga eseguita solo una singola istanza. Nel passo successivo, invia una richiesta HTTP GET all'URL hardcoded per recuperare le sue impostazioni, utilizzando l'ID della campagna nel percorso URL:

In risposta, CastleBot riceve un blocco di dati criptati.

Tutta la comunicazione C2 è criptata tramite l'algoritmo simmetrico ChaCha, ad eccezione della richiesta GET iniziale del malware. Dopo la decodifica, il protocollo C2 utilizza una struttura dati personalizzata serializzata, internamente denominata container, in grado di memorizzare valori di diversi tipi.

Alla base della struttura dati serializzata c'è sempre un campo di tipo ContainerFieldArray. Le strutture seguenti definiscono ulteriormente come vengono configurati i tipi di array e di bool:

Quando si analizza il container decrittato che definisce le impostazioni richieste dalla backdoor, i dati iniziano con il byte 0x0D, che indica il tipo ContainerFieldArray .Questo byte è seguito dal nome del campo, che a sua volta è la lunghezza di 2 byte seguita dal nome codificato UTF-16. Dopo il nome, un campo array definisce una lunghezza di 4 byte dei dati, seguita dai dati stessi, che di nuovo inizia con il primo byte che definisce il tipo.

Le impostazioni ricevute dal campione analizzato sopra vengono analizzate come segue.

Dati serializzati:

Oggetto deserializzato:

Per ogni impostazione abilitata, CastleBot esegue le seguenti azioni:

run_as_admin: Il malware eseguirà il suo genitore tramite "cmd.exe /c <parent_process>" tramite ShellExecuteW con il verbo "runas" per avviarlo come amministratore.

anti_vm: CastleBot utilizzerà l'istruzione cpuid con la foglia 0x40000000 per cercare di rilevare gli ambienti hypervisor. Se vengono rilevati VMware o Parallels, il malware verrà eliminato.

prevent_restart: CastleBot creerà un nuovo file nascosto in %PROGRAMDATA% con il nome corrispondente al nome del mutex incorporato nella configurazione. Se il file esiste già, il malware verrà eliminato.

show_fake_error: il malware visualizza una finestra di messaggio "Errore di sistema" con il messaggio "The program can't start because VCRUNTIME140.dll is missing from your computer. Try reinstalling the program to fix this problem."

Nella fase successiva, CastleBot raccoglie informazioni sull'host infetto per registrarsi con il server C2 e richiedere compiti.

• Nome utente tramite GetUserNameW
• Nome NetBIOS via GetComputerNameW
• Architettura di sistema tramite IsWow64Process
• Nome di dominio DNS locale, utilizzando LsaQueryInformationPolicy per recuperare la struttura PolicyDnsDomainInformation. Il valore predefinito è "WORKGROUP".
• Numero di serie del volume recuperato tramite GetVolumeInformationW. CastleBot lo utilizza per calcolare un ID vittima univoco utilizzando un generatore congruenziale lineare (LCG) con un moltiplicatore di 0x41C64E6D e un addendo di 0x3039.
• Versione Windows tramite RtlGetVersion e GetSystemMetrics(89)

Le informazioni vengono compilate nell'oggetto qui sotto, seguite dalla serializzazione e dalla crittografia ChaCha:

I valori codificati in modo rigido sono la chiave di accesso (identica all'User-Agent della configurazione), l'identificatore della campagna e la versione build di CastleBot, che è "1.0" per il campione analizzato.

La backdoor invia i dati criptati in una richiesta HTTP POST a

 La risposta è un container crittografato più grande contenente le attività preconfigurate di CastleBot.

Il container ricevuto dal server C2 dal campione CastleBot analizzato viene decrittato e deserializzato in un oggetto con i seguenti campi:

Il campo "tasks" è un tipo di array personalizzato come descritto sopra, contenente almeno un array senza nome (nome di lunghezza zero), ognuno dei quali rappresenta un'attività. CastleBot può anche ricevere un array con più attività da svolgere una dopo l'altra. Ogni compito contiene un ID e diversi campi che descrivono il modo in cui il compito deve essere eseguito, che vengono copiati in una struttura di compiti durante la deserializzazione.

Il campo più importante in ogni attività è "launch_method", che determina il tipo di payload che CastleBot deve gestire.

Gli altri campi possono essere utilizzati per impostare opzioni specifiche per l'esecuzione dell'attività:

CastleBot supporta l'iniezione di processi semplici per i payload PE. Inizia creando un nuovo processo sospeso, basato sul percorso di installazione e sui campi argument. Per funzionare su Windows 11 24H2 e versioni successive, gli sviluppatori del malware hanno scelto di agganciare la funzione NtManageHotPatch di NTDLL alla memoria per bypassare il controllo della memoria appena aggiunto. Consulta il post di Hasherezade per maggiori dettagli, che fornisce anche l'esatta implementazione POC utilizzata da CastleBot:

Il resto dell'iniezione del processo segue le comuni tecniche di iniezione allocando memoria nel processo di destinazione, scrivendo le sezioni nel buffer e modificando il contesto del thread prima di riprendere l'esecuzione.

Se il campo metodo di avvio è impostato su "1", CastleBot stabilisce la persistenza creando un'attività programmata. Per registrare l'attività, il malware utilizza l'interfaccia COM di ITaskService per connettersi al servizio Task Scheduler. Crea un nuovo compito e un'azione di esecuzione per il payload di destinazione, che viene attivato ogni volta che l'utente attuale effettua il login (TASK_TRIGGER_LOGON).

Ogni attività nel container "task" viene gestita in modo iterativo secondo i campi specificati. Una volta completata un'attività senza errori, il malware ne segnala l'esecuzione corretta tramite una richiesta HTTP GET a:

X-Force ha osservato una variante core aggiornata di CastleBot, che supporta nuovi metodi di lancio e un'opzione chiamata "wow64_bypass", usata specificamente per lanciare i binari di sistema a 32 bit nella cartella SysWOW64.

L'implementazione aggiuntiva dell'iniezione di processo (metodo di avvio 6) scrive sia il componente CastleBot Loader (consulta la sezione di analisi sopra) sia il payload PE nel processo di destinazione. Quindi utilizza QueueUserAPC e ResumeThread per trasferire l'esecuzione al loader, che carica correttamente il payload del PE in memoria e lo esegue.

Questa tecnica utilizza un numero notevolmente inferiore di chiamate API WriteProcessMemory e fornisce una funzionalità di caricamento più completa dallo stub CastleBot Loader.

L'obiettivo principale di CastleBot è consentire la distribuzione di carichi secondari sulle macchine vittime. X-Force ha scoperto diversi payload distribuiti da CastleBot, spesso con diversi payload in una singola campagna. I payload variano in sofisticazione, da infostealer commodity a backdoor più performanti come NetSupport o WarmCookie, collegati ad attacchi ransomware.

Il framework CastleBot MaaS sembra consentire agli operatori di filtrare le macchine infette e aggiornare facilmente i payload per gestire più campagne attive con grande flessibilità, secondo l' analisi e le schermate di Prodaft del pannello C2. Grazie alla fluidità dei payload e alla capacità dell'operatore di aggiungere più compiti e payload a una singola campagna, le catene di infezione di CastleBot sono più complesse rispetto alle tradizionali fasi di malware statiche.

X-Force non ha prove di una pubblicità diffusa del MaaS sul dark web: questo fatto potrebbe indicare che il servizio è attualmente venduto solo a un gruppo privato di affiliati.

Senza identificare il malware come framework a sé stante, vari frammenti delle campagne che hanno portato a NetSupport sono stati segnalati pubblicamente da altri ricercatori nel giugno e luglio 2025.

DomainTools osservato pagine Docusign false che impiegano la tecnica ClickFix per eseguire uno script PowerShell malevolo, che a sua volta scarica CastleBot per distribuire NetSupport. IOC della campagna:

Unit42 di PaloAlto ha segnalato un'attività simile con siti web che imitano Docusign e Okta, usando ClickFix per implementare CastleBot tramite i componenti iniziali dello stager e del loader. Contiene un'analisi parziale di un "NetSupport RAT Loader", che X-Force identifica come framework CastleBot. IOC della campagna:

Uno dei payload più interessanti di CastleBot è la backdoor WarmCookie (nota anche come Quickbind, BadSpace). Probabilmente fa parte di un più ampio ecosistema di crimini informatici che consente attacchi ransomware ed è stato tra le famiglie di malware prese di mira con successo dalle forze dell'ordine internazionali durante l'Operazione Endgame nel 2024. In precedenza, l'attore delle minacce Hive0137 distribuiva WarmCookie tramite campagne di e-mail malevole, anche se nel 2025 non è stata osservata alcuna attività significativa, secondo la visibilità di X-Force. WarmCookie è pubblicamente legato alle operazioniTA866/Asylum Ambuscade.

La campagna osservata da X-Force è iniziata a giugno con un archivio ZIP armato che imitava un installatore per un software legittimo SSMS-20.2-enu.zip (4766f5cc6501fc40c7151a0ce1c9d2cc49fca9b0b9cab2a206dd2426947e9afe). Tra i componenti legittimi, contiene un eseguibile dannoso SSMS_Windows.x64.exe (05ecf871c7382b0c74e5bac267bb5d12446f52368bb1bfe5d2a4200d0f43c1d8) identificato come una variante di Dave Loader, che decrittografa un payload memorizzato nelle sue risorse. Dopo la decrittazione, Dave Loader inietta la backdoor di CastleBot (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04), che riceve il compito di scaricare ed eseguire un payload WarmCookie (5bca7f1942e07e8c12ecd9c802ecdb96570dfaaa1f44a6753ebb9ffda0604cb4) da

Il server WarmCookie C2 si trova in:

Un secondo esempio trovato più avanti a giugno utilizzava un eseguibile simile, imitando un installatore per Zscaler Zscaler-windows-4.4.0.379-installer-x64.exe (bf21161c808ae74bf08e8d7f83334ba926ffa0bab96ccac42dde418270387890). Il binario compilato da AutoIt è un semplice loader shellcode, che esegue lo stager CastleBot incorporato, che a sua volta scarica lo stesso binario backdoor di CastleBot (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04).

Le esecuzioni sandbox del campione CastleBot padre indicano che lo stesso affiliato potrebbe aver rilasciato un payload StealC con un server C2 su "http://107.158.128[.]105/c91252f9ab114f26.php" durante la campagna; tuttavia, X-Force non è stata in grado di recuperare un campione. 

Entrambe le campagne utilizzano l'ID campagna CastleBot "81a16c72f9c9f4ea94d68b609c78f72d4a8725e7b8f6949b12d8871b6c6843e3".

Inoltre, X-Force sta monitorando diverse campagne CastleBot che distribuiscono vari infostealer. Il malware supporta più task di download per qualsiasi campagna, con il conseguente dispiegamento di diversi payload sullo stesso client. L'eseguibile AMD_Chipset_DriverOnly_DCH_AMD_Z_V1.2.0.105_20238.exe (e6aab1b6a150ee3cbc721ac2575c57309f307f69cd1b478d494c25cde0baaf85) carica il payload core embedded di CastleBot (b45cce4ede6ffb7b6f28f75a0cbb60e65592840d98dcb63155b9fa0324a88be2 ) dalla sua risorsa e lo esegue. L'endpoint delle impostazioni del suo server C2 si trova in

che si è trovato a trasmettere un totale di tre attività separate in un singolo messaggio C2, ciascuna delle quali implementa un payload diverso:

• ID attività: 0x16
• • URL per il download: https[:]//google.herionhelpline[.]com/app/AcerUSBUpdate.exe
  • Payload: 03122e46a3e48141553e7567c659642b1938b2d3641432f916375c163df819c1 (Rhadamanthys)
  • Percorso di installazione: nessuno
  • Metodo di lancio: 6

• ID attività: 0x17 
• • URL per il download: https[:]//google.herionhelpline[.]com/app/light1_v5_signed.html
  • Payload: 12de997634859d1f93273e552dec855bfae440dcf11159ada19ca0ae13d53dff (Remcos)
  • Percorso di installazione: %ProgramData%\AmazonApp\AmazonWebServiceUpdate.exe
  • Metodo di lancio: 1

• ID attività: 0x18
• • https[:]//google.herionhelpline[.]com/app/SlackUpdateWeb.html
  • Payload: c8f95f436c1f618a8ef5c490555c6a1380d018f44e1644837f19cb71f6584a8a (DeerStealer)
  • Percorso di installazione: %AppData%\SlackUpdate\SlackServiceUpdate.exe
  • Metodo di lancio: 1

X-Force ha scoperto altre campagne che distribuiscono SecTopRAT (alias ArechClient), HijackLoader (alias Shadowladder) e MonsterV2 (alias Aurotun Stealer). 

SecTopRAT e HijackLoader:

• GlobalProtect-win-6.3.zip con sideloading eseguibile msvcp140.dll (8bf93cef46fda2bdb9d2a426fbcd35ffedea9ed9bd97bf78cc51282bd1fb2095)
• Server CastleBot C2: http[:]//107.158.128[.]45/service/settings/81a16c72f9c9f4ea94d68b609c78f72d4a8725e7b8f6949b12d8871b6c6843e3
• Payload ospitato su http[:]//107.158.128[.]45/service/download/Exchanger32.zip (4834bc71fc5d3729ad5280e44a13e9627e3a82fd4db1bb992fa8ae52602825c6)

MonsterV2:

• libssl-1_1.dll (53dddae886017fbfbb43ef236996b9a4d9fb670833dfa0c3eac982815dc8d2a5) sideload DLL, inietta in modo riflessivo lo stager CastleBot
• CastleBot C2 server: http[:]//107.158.128[.]45/service/settings/8306a6b35d4be6de72be58860791e3644468fd67f675e4045a246dd27fa5692c
• Payload ospitato su http[:]//107.158.128[.]45/service/download/CCver_Setup.exe (ab725f5ab19eec691b66c37c715abd0e9ab44556708094a911b84987d700aa62)

CastleBot è l'ultima prova di un cambiamento nei vettori di infezione iniziale nel landscape delle minacce del crimine informatico. Backdoor e framework vengono sempre più diffusi tramite siti web falsi, come parte di software trojanizzati o tramite la tecnica ClickFix A pochi mesi dall'aumento dell'attività di CastleBot, gli sviluppatori hanno già aggiunto diverse nuove caratteristiche e probabilmente cercheranno di tenere il passo con l'adattamento del rilevamento e risposta degli endpoint (EDR) e le soluzioni di sicurezza di rete. L'attività attuale suggerisce che più affiliati utilizzano CastleBot per distribuire sia infostealer che backdoor, il che potrebbe portare a incidenti ransomware ad alto impatto.

Si consiglia ai difensori di rimanere vigili con le tecniche menzionate in questo report e di adottare le azioni appropriate per ridurre il rischio di un'infezione da CastleBot.

• Assicurarsi che il software EDR e i controlli di sicurezza associati siano aggiornati.
• Addestrare gli utenti a esercitare estrema cautela durante il download del software e ad astenersi dall'installare software non autorizzato o non verificato
• Implementare l'autenticazione a più fattori e monitorare la fuga di credenziali aziendali.
• Impostare avvisi o valutare la possibilità di bloccare le connessioni HTTP (non HTTPS) in uscita e gli URL contenenti indirizzi IP in particolare

IBM X-Force Premier Threat Intelligence è ora integrato con OpenCTI di Filigran, offrendo threat intelligence attuabile su questa attività di minaccia e altro ancora. Accedi agli insight sugli attori delle minacce, sui malware e sui settori. Installa l'OpenCTI Connector di X-Force per migliorare il rilevamento e la risposta, rafforzando la cybersecurity con l'esperienza di IBM X-Force. Ottieni oggi stesso una versione di prova di 30 giorni di X-Force Premier Threat Intelligence!