Custom GPT armato: un RAT distribuito da chatgpt.com

Un Custom GPT che consegna un trojan

A fine settembre 2026 la società di sicurezza Huntress ha osservato una campagna che trasforma un Custom GPT ospitato su chatgpt.com in un canale di consegna malware. Il GPT si chiama «Plus 5.6» e imita un'offerta commerciale di abbonamento.

Il punto di partenza è un risultato sponsorizzato su Google per ricerche come «chatgpt». Chi clicca atterra su due indirizzi del dominio chatgpt.com, con il nome del Custom GPT in cima alla pagina. Grafica, certificato e marchio appartengono alla piattaforma vera.

Il GPT risponde ai prompt con un «Service Availability Notice». Il messaggio propone due strade: aggiornare il piano a pagamento oppure passare a un dominio di riserva su Google Sites, giustificato come rimedio alla «limited availability on the primary domain». Un invito finale spinge verso la seconda opzione chi cerca accesso immediato.

Huntress conta almeno 40 utenti infettati^[1] in questa campagna.

La catena tecnica, pezzo per pezzo

Il dominio di riserva mostra un falso controllo CAPTCHA con il marchio Cloudflare.

Da qui parte uno schema ClickFix. La vittima copia un comando PowerShell e lo esegue a mano sul proprio terminale, convinta di superare una verifica anti-bot.

Il comando porta a un installer MSI, «ISOSimple.msi». L'installer carica un binario firmato Canon, «COTFileReadApp.exe», e lo usa per il sideload di una DLL malevola, «ceiinfolog.dll». Quella libreria è la DLL Canon originale, alterata per caricarne una seconda, «rdCore.dll», priva di firma.

L'ultimo stadio estrae un loader cifrato da un file audio .WAV, esegue shellcode e installa due oggetti: uno script di persistenza e il payload RAT. Ogni anello della catena poggia su un componente che un controllo superficiale considera legittimo: un dominio noto, un binario firmato, un file musicale.

La firma digitale del binario Canon resta valida per tutto il percorso. Il codice ostile vive nella libreria caricata accanto, un pattern di sideload vecchio di quindici anni che funziona ancora oggi.

Quello che all'attaccante è bastato saltare

La gravità di questa campagna si misura per sottrazione. Zero vulnerabilità di OpenAI. Zero account compromessi.

Zero righe di codice, anche: un Custom GPT si costruisce con istruzioni in linguaggio naturale e file di riferimento caricati a mano, come prevede la funzione per qualsiasi utente.

All'attaccante sono bastati tre elementi: un account sulla piattaforma, un budget pubblicitario per il risultato sponsorizzato, un sito gratuito su Google Sites. Il resto lo ha fatto la fiducia che l'utente ripone nel dominio.

Qui sta la differenza fra una falla di prodotto e un abuso di funzione. Una CVE si chiude con una patch e un numero di versione. Una funzione nata per accettare istruzioni libere da chiunque si governa con moderazione, telemetria e revoca, tre cose che vivono fuori dal codice.

Il perimetro di difesa si sposta dal binario al contenuto pubblicato, e cambia chi deve guardarlo.

Il dominio fidato sostituisce l'exploit

Le liste di blocco aziendali trattano chatgpt.com come dominio di produttività. I proxy lo lasciano passare, i filtri DNS lo ignorano, gli utenti lo riconoscono a colpo d'occhio.

Una pagina ostile ospitata lì eredita tutta quella reputazione. Lo stesso vale per Google Sites, che offre hosting gratuito sotto un dominio con reputazione alta.

Il risultato è una catena di consegna costruita per intero su infrastruttura di terze parti rispettabile. Il traffico verso il dominio della piattaforma AI appare identico a quello dei colleghi che usano lo stesso servizio ogni giorno. Il segnale utile arriva a valle, quando parte PowerShell, e a quel punto il comando risulta già incollato dall'utente.

Chi difende una rete oggi deve assumere che i domini AI più noti ospitino contenuti arbitrari creati da chiunque abbia un account.

La stessa logica vale per gli artefatti condivisi, per le conversazioni pubbliche e per i connettori. Ogni superficie che permette a un estraneo di pubblicare testo sotto il dominio di una piattaforma AI diventa un canale di distribuzione.

Un filone con precedenti documentati

Questa campagna arriva dopo altri abusi della stessa famiglia. Huntress ricorda le conversazioni condivise con i chatbot usate come esca e gli artefatti Claude malevoli impiegati per diffondere stealer e trojan ad accesso remoto.

Il filone più ampio riguarda l'AI dentro le intrusioni. BleepingComputer riporta il caso di zero-day in Zammad che, secondo DIVD, hanno aperto la strada a una violazione di rete guidata da AI^[2].

The Record raccoglie invece le analisi di Google su vulnerabilità e attacchi informatici legati all'AI^[3]. Due direzioni distinte: l'AI come strumento dell'aggressore, la piattaforma AI come terreno di appoggio. Il caso «Plus 5.6» appartiene alla seconda.

La distinzione conta per chi scrive una policy. Il primo scenario chiede controlli sulla superficie esposta; il secondo chiede controlli su quello che i dipendenti raggiungono dentro servizi già approvati.

Tre domande per il team AI di un'impresa

Il racconto dell'incidente descrive; la decisione tocca a chi gestisce lo stack. Queste tre domande chiudono il perimetro con risposte verificabili in una settimana.

1. Chi presidia i contenuti di terze parti che transitano sui domini AI approvati in azienda?
2. Un utente standard riesce oggi a eseguire un comando PowerShell incollato dagli appunti?
3. Quale regola EDR segnala un installer MSI firmato da un fornitore estraneo al parco software?

Le risposte vanno scritte con un nome accanto. Una domanda di sicurezza orfana diventa debito tecnico, e in sicurezza il debito tecnico si paga con un incidente.

Il controllo più efficace in questo caso resta a monte: bloccare l'esecuzione di comandi incollati da un utente standard. ClickFix vive di quel gesto, e un criterio di esecuzione ben tarato lo spegne.

Il secondo controllo è la telemetria sugli installer firmati da fornitori fuori inventario. Un binario Canon su una postazione dove manca una stampante Canon è un segnale forte, economico da raccogliere.

Entrambi i controlli esistono già nei prodotti EDR in uso. Qui manca la configurazione.

Procurement, build/buy e conto economico

Per un CTO la lezione pratica tocca la categorizzazione dei domini. Il dominio di una piattaforma AI merita la stessa diffidenza di una piattaforma di file sharing: contenuto arbitrario caricato da utenti esterni, hosting solido, reputazione alta.

Per un Head of Engineering la domanda riguarda i connettori. Ogni integrazione che porta contenuto generato da terzi dentro un flusso aziendale va trattata come input ostile, con una barriera di esecuzione esplicita.

Per un CFO il calcolo è lineare. Quaranta postazioni compromesse costano in bonifica, in fermo macchina e in rotazione di credenziali assai più della licenza di controllo applicativo che le avrebbe fermate.

Il comitato acquisti ha una leva contrattuale concreta. Nei rinnovi con i fornitori di piattaforme AI vale la pena chiedere per iscritto i tempi di rimozione dei contenuti segnalati, un canale di abuse con SLA e log consultabili dal cliente.

Che cosa resta aperto

La moderazione dei contenuti pubblicati dagli utenti su una piattaforma AI è un problema di scala. Oggi viene affrontata con strumenti pensati per il testo tossico, poco adatti a un messaggio che spinge con garbo verso un dominio esterno.

La previsione falsificabile è questa: entro sei mesi comparirà una campagna analoga su una funzione equivalente di un'altra piattaforma AI diffusa, con lo stesso schema ClickFix a valle. La superficie è identica e il costo di ingresso resta vicino allo zero.

Fino ad allora la difesa pratica sta sull'endpoint, perché il dominio fidato arriva già oltre il perimetro.

Chi tiene un inventario dei servizi AI approvati faccia un passo in più: accanto a ogni servizio, scriva quali contenuti di terze parti quel servizio può ospitare. Quella colonna, oggi vuota quasi ovunque, è la mappa della superficie d'attacco reale.