LLM offensive workflow: come gli hacker industrializzano i modelli AI

Negli ultimi mesi, in diversi spazi del dark web, il dibattito sulle LLM ha smesso di ruotare attorno alla solita domanda “si possono aggirare i filtri?”, per spostarsi su un piano molto più operativo: quale modello usare, attraverso quale interfaccia, con quale endpoint, in quale punto della pipeline e con quale livello di affidabilità tecnica?

Nel nostro lavoro quotidiano di OSINT abbiamo individuato una discussione in un forum underground dedicato a hacking, malware e AI che rende questo passaggio molto evidente. Il tono della conversazione è quello tipico di questi ambienti, spesso volgare e iper competitivo, ma il contenuto è più interessante di quanto sembri a prima vista: non si parla più di semplici prompt “furbi”, bensì di workflow multi-modello, proxy API, context engineering, tool invocation, deploy locale di modelli uncensored, orchestrazione tra agenti e ottimizzazione del costo per output utile.

In altre parole, il focus non è più la singola LLM, ma l’intera filiera tecnica con cui una comunità ostile prova a trasformarla in un componente operativo.

Dal prompt singolo alla pipeline multi-modello

La parte più significativa del thread presente nel Dark Web non riguarda tanto i singoli modelli, quanto il modo in cui vengono inseriti in una pipeline. Gli utenti non cercano più “la migliore AI” in senso assoluto. Cercano invece una combinazione di sistemi con ruoli distinti.

Nel thread vengono citati in modo ricorrente Claude Opus 4.6, Claude 4.7, Claude Code, Gemini CLI con 3.1 Pro, GLM-5, GLM-5 Abliterated, Qwen 3.6 Uncensored, Qwen 3.5 uncensored, MiniMax 2.5, Big Pickle, Grok, oltre a piattaforme come OpenCode, Kilo Code, OpenRouter, Venice.ai, vast.ai, manus.im e vari marketplace paralleli che offrono accessi, API key o abbonamenti rivenduti.

Quello che emerge chiaramente è un pattern ormai maturo:

un modello viene usato per generare idee, scomporre il problema o produrre una roadmap;
un secondo modello viene impiegato per sintetizzare più output in un unico task tecnico o in una specifica;
un terzo viene utilizzato per generare codice, patch o blocchi operativi;
un quarto svolge il ruolo di revisore, debugger o validatore;
quando un modello si rifiuta, lo si sposta su compiti di analisi e si affida la generazione iniziale a un’alternativa più permissiva.

Questa logica è molto vicina a una agentic architecture rudimentale. Non c’è una formalizzazione accademica del workflow, ma dal punto di vista pratico il concetto è chiaro: distribuire il carico cognitivo tra più modelli, sfruttando differenze di comportamento, qualità e rigidità delle policy.

Non conta solo il modello: conta l’interfaccia

Uno dei punti più tecnici emersi dal thread è che, per questi utenti, il nome del modello non basta a prevederne il comportamento. La stessa famiglia di modelli cambia radicalmente in base alla superficie di accesso.

Nel forum si distingue esplicitamente tra:

web app
desktop app
API ufficiale
CLI
ambienti agentici
endpoint di terze parti
proxy API non ufficiali

La percezione condivisa è che Claude Code, soprattutto quando lavora in CLI su repository, file e task lunghi, sia più utile del classico front-end conversazionale. Allo stesso modo, alcuni sostengono che certi endpoint non ufficiali o rivenduti tramite provider paralleli risultino meno restrittivi rispetto ai canali ufficiali. Altri, al contrario, contestano l’autenticità di questi accessi e ipotizzano che dietro alcune “cheap API” non ci sia il modello dichiarato, ma una catena di proxy, wrapper o backend diversi da quelli pubblicizzati.

Dal punto di vista tecnico, questo è un passaggio cruciale: il comportamento reale non dipende solo dai pesi del modello, ma dall’intero control plane che sta attorno al modello stesso: system prompt invisibili, filtri server-side, middleware per reasoning, enforcement policy, logging, tool router, limiti di sessione, memoria persistente, rate limiting e sistemi di trust & safety.

Context priming, persistent memory e context steering

Un altro elemento presente nella discussione riguarda il modo in cui il contesto viene costruito e sfruttato. In questi ambienti si parla spesso, anche se con un lessico poco rigoroso, di “scaldare” il modello prima di chiedere ciò che interessa davvero.

Si tratta di context priming o context steering: costruire gradualmente una cornice in cui l’utente appare come sviluppatore, amministratore, auditor, ricercatore o tester, così che il modello interpreti le richieste successive dentro una semantica considerata “legittima”.

Nel thread questo meccanismo viene descritto in modo quasi empirico: partire con task neutri, lavorare su frammenti limitati di codice, presentarsi come professionista, far passare il lavoro come audit strutturale, debugging o refactoring, e solo dopo spostare il dialogo su richieste più sensibili. Alcuni utenti sottolineano inoltre che ChatGPT, secondo la loro esperienza, tende a “ricordare” un rifiuto anche dopo l’apertura di una nuova chat, mentre Claude sarebbe più gestibile in sessioni nuove se il contesto viene ricostruito in modo diverso.

Il dato interessante, al netto dell’aneddotica, è che queste comunità hanno già capito qualcosa che in ambito enterprise viene spesso raccontato in modo più sofisticato: il comportamento della LLM non dipende solo dal prompt corrente, ma dall’intera state machine conversazionale costruita fino a quel momento.

Structural prompting: ridurre la valutazione semantica

Nel thread compare anche un filone molto specifico di prompting tecnico. L’idea non è chiedere al modello di capire “cosa fa” un codice o un testo, ma costringerlo a lavorare solo sulla struttura, sulla sintassi e sulle relazioni formali.

Si parla anche di un prompt che mette il modello in STRICT PARSER MODE, definendolo esclusivamente come AST linter, structural patcher e syntax mapper, imponendo vincoli come:

nessuna interpretazione semantica;
focus soltanto sul mapping tra strutture dati e interfacce;
O(1) semantic depth;
domain blindness su variabili, endpoint, .env, funzioni e riferimenti;
output limitato a codice raw, senza spiegazioni o valutazioni etiche.

Non è una magia e non è una “rottura” del modello in senso stretto. È piuttosto una forma di constraint framing, in cui si cerca di ridurre lo spazio di decisione del modello, spostandolo da un ruolo generalista a un compito pseudo-meccanico. L’obiettivo è abbassare la probabilità che entri in gioco la valutazione semantica del task.

Questo è un dettaglio molto interessante perché mostra una comprensione, anche se informale, del fatto che una LLM può essere manipolata non solo attraverso il contenuto, ma attraverso il ruolo operativo che le viene assegnato.

Hallucination e l’incertezza di affidabilità

Il thread non è però un inno ingenuo alle versioni “senza censura”. Al contrario, una parte della discussione è sorprendentemente critica sul piano tecnico.

Più utenti fanno notare che modelli come Dolphin-Mistral 24B Venice Edition, alcune release patched da Hugging Face, varianti uncensored di Qwen, MiniMax o altri sistemi modificati producono spesso un output che appare convincente solo in superficie. Il problema non è tanto la forma del testo, quanto la sostanza del codice:

funzioni inventate;
API inesistenti;
librerie non reali;
mapping logici incoerenti;
codice che non compila;
bypass immaginari;
riferimenti a tool che il contesto reale non possiede.

Nel linguaggio del software engineering, si tratta del classico fenomeno di hallucination strutturata: l’output ha un’alta plausibilità sintattica, ma una bassa aderenza al sistema reale. Per questo motivo, anche gli utenti che promuovono i modelli uncensored li trattano spesso come generatori di bozze, prototipi, skeleton o patch preliminari, più che come motori affidabili per lavori complessi.

È un punto chiave. Per quanto aggressiva possa essere la retorica del forum, la pratica racconta una realtà molto più prudente: i modelli permissivi servono, ma non sono quasi mai considerati sufficienti da soli.

Proxy API: sono sempre di qualità e trasparenti?

Una parte molto interessante della discussione nel Dark Web riguarda la qualità e la trasparenza delle API economiche vendute su marketplace paralleli.

Alcuni utenti sostengono di aver ottenuto accessi estremamente economici a Claude via rivenditori, proxy cinesi o servizi non ufficiali. Altri contestano apertamente questi canali, sostenendo che dietro il branding “Claude” si nascondano backend diversi, wrapping aggressivo o persino modelli alternativi “promptati” per sembrare altro. Le critiche tecniche si concentrano su aspetti molto concreti:

reasoning identico tra modelli teoricamente diversi;
costi anomali dovuti a system prompt molto lunghi;
oltre 22k token di prompt di sistema in richieste banalissime;
reasoning forzato anche su input semplici;
differenze sospette tra sonnet e opus quasi nulle;
errori di tool invocation, come risposta in bash dove ci si aspetterebbe run_command;
presunta iniezione di system prompt da parte di layer intermedi.

Questi dettagli sono tecnicamente rilevanti perché spostano il problema dal “quale modello usi” al “quale stack stai realmente interrogando”. Nella pratica, il mercato grigio delle LLM non vende solo accesso, ma opacità. E questa opacità influisce direttamente su latenza, qualità, costo, tool use e prevedibilità del comportamento.

Tool use, CLI e repository-scale context

Un altro aspetto notevole del thread è la centralità degli ambienti CLI e agentici rispetto al semplice chatbot.

Gli utenti citano in particolare Claude Code, Codex CLI, OpenCode, Cursor, Kilo Code e altri ambienti in cui il modello non è limitato alla generazione di testo, ma opera su file, alberi di progetto, comandi, debugging, compilazione e test. In questi contesti, il valore aggiunto percepito non sta solo nella “qualità della scrittura”, ma nella capacità di mantenere repository-scale context, cioè una rappresentazione sufficientemente coerente di una base di codice estesa.

La discussione mostra che, per chi lavora su task tecnici lunghi, la differenza tra chat e CLI è sostanziale. La chat è utile per ideare, discutere, sintetizzare. La CLI è utile per intervenire sul progetto, navigare file, riscrivere blocchi, eseguire task, interpretare errori e chiudere loop iterativi.

Questo è uno dei motivi per cui certi utenti continuano a preferire ecosistemi come Claude Code o Gemini CLI, nonostante i rifiuti, i limiti e i ban: quando funzionano, consentono un livello di integrazione nel workflow che la classica UI web non offre.

Split-by-context workflow: una segmentazione architetturale

Verso la fine della discussione emerge anche un pattern più maturo: la suddivisione del lavoro per contesti architetturali. Un utente descrive un approccio in cui il codice o il problema viene spezzato in blocchi coerenti, seguendo una logica simile alla clean architecture, e ogni blocco viene trattato come un contesto separato da far analizzare o implementare alla LLM.

Questa tecnica ha una base tecnica molto solida: ridurre il contesto attivo significa diminuire rumore, collisioni semantiche, dispersione del focus e probabilità di allucinazione. In pratica si sacrifica la visione globale per aumentare la qualità locale. È un compromesso sensato quando si lavora con modelli potenti ma instabili, o quando il token budget e la memoria della sessione diventano fattori limitanti.

Anche questo conferma che l’uso di LLM in ambienti ostili si sta professionalizzando. Non si parla più solo di prompt, ma di scoping, context partitioning, task decomposition e orchestrazione di contesti separati.

Deploy locale: qual è il costo dell’autonomia?

Nel thread torna spesso l’idea di risolvere il problema a monte: evitare i provider mainstream e far girare modelli locali o semi-locali su hardware dedicato o noleggiato.

Vengono citati vast.ai per il noleggio di macchine potenti, GLM-5 Abliterated come modello molto apprezzato in quel contesto, e poi Qwen 3.6 Uncensored o altre release analoghe deployate su server personali o ambienti remoti. L’argomento è chiaro: se il provider ufficiale applica limiti, filtri, ban, policy e logging, allora la sovranità sul modello diventa un vantaggio operativo.

Ma anche qui il forum offre una fotografia meno ingenua di quanto sembri. Chi promuove queste soluzioni ammette implicitamente che il deploy locale ha costi e trade-off importanti:

richiesta di RAM e GPU elevate;
inferenza costosa o complessa;
qualità non sempre all’altezza dei modelli commerciali top-tier;
minore affidabilità su reasoning profondo;
maggiore manutenzione;
necessità di combinare il modello locale con altri sistemi per refining, analisi o review.

Non è quindi un’alternativa universale, ma un pezzo della pipeline.

Ban, memory controls e governance del rischio

Un altro tema che attraversa tutto il thread è il rischio di ban. Alcuni utenti riportano warning e sospensioni su Gemini o su altri servizi dopo molte ore di utilizzo su task sensibili. Altri sostengono di non vedere ban, soprattutto usando account acquistati, accessi rivenduti o configurazioni intermedie. Alcuni propongono persino di disattivare la memoria in certi ambienti, proprio per ridurre la persistenza del contesto e il rischio che richieste successive vengano giudicate in continuità con quelle precedenti.

Dal punto di vista tecnico, questo è molto rilevante. La moderazione non viene più percepita come un semplice rifiuto locale, ma come una forma di governance distribuita del rischio: memoria persistente, telemetria, session history, profiling dell’account, reputazione del provider, livello di tolleranza dell’interfaccia e possibili correlazioni tra sessioni.

In pratica, chi usa queste piattaforme in modo aggressivo non progetta solo il task. Progetta anche il rischio di enforcement.

Dall’AI come tool all’AI come supply chain

Nei forum del dark web l’AI non viene più trattata come un “assistente intelligente” e nemmeno come un gadget da testare. Viene trattata come una supply chain con vari livelli:

Modelli premium e più intelligenti, ma più rigidi.
Modelli permissivi, meno affidabili ma più disponibili.
Proxy API e dei marketplace.
Layer di orchestrazione tra più modelli.
Deploy locale per i casi in cui serve più autonomia.
Il livello umano, che continua a essere essenziale per selezionare output, correggere errori, validare il codice e decidere cosa tenere e cosa scartare.

È questo il punto che interessa davvero chi osserva il fenomeno dal lato difensivo. Il rischio non è semplicemente che una LLM generi un output problematico. Il rischio è che si stia consolidando una filiera tecnica, economica e operativa che permette di usare più modelli insieme, di distribuire i ruoli, di abbassare il costo dell’iterazione e di rendere più accessibili task che prima richiedevano più tempo, più esperienza o più personale.

In questo senso, il thread non racconta tanto di un modello “messo in ginocchio”. Racconta piuttosto l’inizio di una normalizzazione: Claude, Gemini, Qwen, GLM, Grok, MiniMax e gli altri non sono più visti come sistemi monolitici, ma come moduli intercambiabili di una pipeline ibrida, in cui qualità, censura, costo, contesto e tool use vengono trattati come variabili ingegneristiche.

E quando una comunità ostile smette di parlare di singoli prompt miracolosi e inizia invece a ragionare in termini di orchestrazione, context partitioning, API economics, proxy trust, repository-scale context e deploy distribuito, significa che il fenomeno è uscito dalla fase sperimentale.

A quel punto, più che di chatbot, bisognerebbe iniziare a parlare di infrastruttura.

Analisi di Vasily Kononov – Threat Intelligence Lead, CYBEROO