Gli attaccanti stanno sfruttando sempre più spesso la fiducia associata alle piattaforme di intelligenza artificiale per costruire campagne di social engineering.

Una nuova operazione analizzata da Huntress mostra un’evoluzione particolarmente interessante di questa tecnica, perché utilizza un Custom GPT ospitato direttamente sul dominio legittimo di ChatGPT come primo elemento della catena d’attacco.

L’obiettivo finale della campagna è l’installazione di un Remote Access Trojan, ma il percorso per arrivarci combina diverse tecniche di evasione e persistenza.

Un Custom GPT ingannevole

La campagna prende avvio da un Custom GPT chiamato “Plus 5.6”, un nome scelto per farlo apparire come una versione ufficiale e aggiornata di ChatGPT.

Un Custom GPT, lo ricordiamoè una versione personalizzata di ChatGPT configurata per svolgere compiti specifici. Può essere impostato con istruzioni e funzionalità particolari, così da fornire risposte e comportamenti adattati a uno specifico obiettivo.

Proprio per questo, l’elemento che rende l’attacco particolarmente insidioso è che il GPT non si trova su un dominio contraffatto, ma all’interno della piattaforma legittima di ChatGPT. La vittima, quindi, non viene inizialmente indirizzata verso un sito che imita ChatGPT, ma interagisce con un contenuto malevolo ospitato direttamente nel servizio originale.

Fonte: Huntress.

Secondo l’analisi condotta da Huntress, l’attacco inizierebbe da una semplice ricerca di ChatGPT su Google, dalla quale l’utente può raggiungere il Custom GPT.

Una volta avviata l’interazione, il GPT mostra un falso messaggio relativo alla disponibilità del servizio e suggerisce di utilizzare un presunto dominio alternativo per continuare ad accedere a ChatGPT.

Fonte: Huntress.

Il collegamento fornito dal GPT condurrebbe, quindi, a una pagina ospitata su Google Sites, costruita per apparire come una verifica di sicurezza basata su Cloudflare.

A questo punto entra in gioco la tecnica ClickFix. La pagina simula un controllo CAPTCHA e fornisce alla vittima le istruzioni necessarie per eseguire manualmente un comando sul proprio computer, presentandolo come un’operazione necessaria per completare la verifica.

Fonte: Huntress.

È proprio questo passaggio a trasformare una semplice interazione con un Custom GPT in un vero e proprio vettore di infezione. La fiducia iniziale riposta in ChatGPT viene infatti sfruttata per accompagnare progressivamente l’utente fuori dalla piattaforma e convincerlo a eseguire un’azione che avvia la catena del malware.

La fase operativa dell’attacco

Una volta raggiunta la falsa pagina di verifica, l’attacco entra nella fase operativa. L’utente viene così indotto ad avviare PowerShell, lo strumento di Windows che gli aggressori utilizzano per proseguire automaticamente con l’infezione.

Una volta eseguito il comando, PowerShell scarica uno script e da quel momento non è più necessaria alcuna interazione da parte della vittima, perché la catena d’attacco prosegue attraverso una serie di componenti progettati per scaricare, installare ed eseguire il payload finale.

Lo script avviava quindi l’installazione di un pacchetto MSI, denominato ISOSimple.msi, che rappresenta il passaggio successivo della catena. L’utilizzo di un installer MSI contribuisce a rendere il comportamento meno evidente, mentre le successive tecniche di esecuzione consentono al malware di nascondersi dietro software apparentemente legittimo.

La catena non si conclude quindi con il comando PowerShell. Al contrario, quello rappresenta soltanto il punto di inizio. Huntress ha ricostruito una sequenza composta da diversi livelli, nella quale ogni fase prepara quella successiva fino ad arrivare all’esecuzione del RAT.

Tra queste tecniche rientra anche il DLL sideloading, che permette di sfruttare un’applicazione legittima per caricare una libreria malevola e proseguire l’infezione senza affidarsi direttamente a un eseguibile riconducibile al malware.

Fonte: Huntress.

Il payload finale è un RAT

La catena di infezione prosegue con un ulteriore livello di occultamento. Tra i componenti utilizzati dagli attaccanti c’è infatti un file che appare a tutti gli effetti come un normale audio WAV, ma che contiene al suo interno dati cifrati utilizzati per recuperare il loader del malware (Common.Integrator.Preview.wav).

Secondo i ricercatori non si tratterebbe in questo caso di steganografia ma di una sovrascrittura di una registrazione audio reale con del testo cifrato.

Una volta estratto il loader, attraverso ulteriori tecniche di evasione per evitare i controlli di sicurezza di Windows si arriva all’esecuzione del payload finale ovvero un trojan ad accesso remoto dotato di numerose funzionalità che permettono agli attaccanti di controllare il sistema compromesso.

Il malware può gestire sessioni desktop da remoto, acquisire immagini dalla webcam, utilizzare microfono e audio del computer, interagire con diversi browser e cercare file presenti nel dispositivo. Può inoltre scaricare ed eseguire ulteriori payload, consentendo agli aggressori di estendere le proprie attività anche dopo la compromissione iniziale.

Sempre secondo l’analisi la comunicazione con l’infrastruttura di comando e controllo verrebbe effettuata attraverso il DNS over HTTPS, sfruttando i servizi Cloudflare, Google e Quad9. In questo modo le richieste vengono inserite all’interno di traffico HTTPS (apparentemente legittimo) verso resolver noti, rendendo più complessa l’individuazione della comunicazione tra il dispositivo compromesso e l’infrastruttura utilizzata dagli attaccanti.

La fiducia diventa parte della superficie d’attacco

La campagna evidenzia un aspetto importante per la cybersecurity. La presenza di un dominio legittimo non è più sufficiente per stabilire che ciò che viene presentato all’utente sia affidabile.

In questo caso, il primo elemento dell’attacco risiedeva proprio all’interno di una piattaforma autentica, mentre il successivo passaggio sfruttava un servizio Google legittimo per ospitare la pagina ClickFix.

Secondo Huntress, il proprio SOC ha gestito almeno 40 incidenti collegati allo specifico dominio Google Sites utilizzato nella campagna, due dei quali confermati come derivanti direttamente dall’utilizzo del Custom GPT.

L’episodio conferma quindi come l’abuso delle funzionalità legittime delle piattaforme AI stia diventando un nuovo elemento del social engineering, spostando il problema dalla semplice verifica dell’URL alla valutazione di ciò che la piattaforma sta effettivamente chiedendo all’utente di eseguire.

Inoltre, vale la pena notare che dopo la rimozione del primo Custom GPT segnalato da Huntress, i ricercatori hanno individuato una seconda versione collegata alla stessa campagna. Il meccanismo rimaneva sostanzialmente invariato, mentre cambiavano alcuni componenti utilizzati per mascherare l’attività.

Nella seconda variante veniva utilizzato un eseguibile firmato Stardock al posto del componente Canon e il loader non era più nascosto in un file WAV, ma all’interno di un pacchetto Microsoft NuGet apparentemente legittimo.