LLM e attacchi web: le pagine pulite diventano trappole in tempo reale

Usare la GenAI per costruire una minaccia che si carica solo dopo che la vittima ha già visitato una pagina web apparentemente innocua: è la nuova frontiera degli attacchi web descritta dai ricercatori di Unit 42 di Palo Alto Networks nel paper The Next Frontier of Runtime Assembly Attacks: Leveraging LLMs to Generate Phishing JavaScript in Real Time. Gli esperti mostrano come una pagina inizialmente pulita possa trasformarsi, in tempo reale, in una trappola di phishing grazie a codice JavaScript generato sul momento da un LLM, senza mai esporre su rete un payload statico facilmente rilevabile.

L’idea di fondo è semplice e allo stesso tempo insidiosa: invece di consegnare subito al browser un codice malevolo offuscato, l’attaccante fornisce solo il ‘guscio’ della pagina e delega a un servizio di AI esterno la generazione del vero script dannoso, al momento opportuno. Questo sposta l’attenzione dalle classiche tecniche di offuscamento alla capacità di sfruttare API di LLM legittimi, usando prompt testuali che descrivono il comportamento desiderato, così che sia il browser della vittima a svolgere il lavoro sporco di assemblare ed eseguire il codice malevolo.

La kill chain parte dal prendere una pagina già usata in una campagna di phishing reale e analizzarne nel dettaglio il comportamento. Il focus è su come il JavaScript personalizza la pagina a partire dai parametri nell’URL, su come intercetta le credenziali inserite dall’utente e su come le invia a un server controllato dai cyber criminali. Da questa analisi l’attaccante ricava la logica funzionale, che gli permette di tradurre i comportamenti in testo. Ogni funzione importante della pagina viene descritta in linguaggio naturale: serve un form che raccolga determinati campi, bisogna inviare una richiesta POST a un certo URL, la pagina deve somigliare a un determinato tipo di interfaccia, e così via.

Il flusso di lavoro del PoC dimostrato dai ricercatori della Unit 42

L’operazione non è banale, perché i sistemi di sicurezza integrati nei LLM tendono a bloccare richieste troppo esplicite legate a phishing o furto di credenziali, ma in questo caso la tecnica funziona grazie a piccoli cambi di formulazione che trasformano un prompt respinto in uno accettato, pur mantenendo invariata la funzione finale che si vuole ottenere. Per esempio la richiesta scrivimi uno script per rubare le credenziali di login viene intercettata e bloccata, ma quella uno script che invii dati di un form a un server remoto via POST passa i controlli.

Siamo pertanto di fronte a un processo iterativo in cui l’attaccante testa le risposte del modello, affina i prompt, elimina le parole chiave che attivano i filtri e conserva le formulazioni che portano a ottenere gli obiettivi desiderati. Il risultato è una libreria di descrizioni testuali che rappresentano, in forma di prompt, i vari pezzi del kit di phishing. Con questo ‘vocabolario’ il threat actor passa alla fase operativa, che coinvolge il browser della vittima.

La pagina che l’utente visita viene servita da un server che, a un’analisi superficiale, appare del tutto innocuo. Il codice presente è minimale: qualche elemento di interfaccia, un form apparentemente legittimo, uno script che gestisce piccole funzioni a corredo. È di fatto assente qualsiasi payload dannoso statico, quindi gli strumenti di analisi che eseguono una scansione del codice sorgente al momento dell’upload classificano la pagina come benigna.

Dopo che la pagina è stata caricata e la vittima sta già navigando sul sito, lo scenario cambia. Il JavaScript legittimo presente nel sorgente invia richieste a un servizio di LLM attraverso le sue API pubbliche, incapsulate in chiamate HTTP indistinguibili dal normale traffico applicativo. Nel proof of concept realizzato dai ricercatori figurano servizi come DeepSeek o Google Gemini, ma il meccanismo, per come è descritto, è applicabile a qualunque LLM accessibile via API. Il payload di queste richieste non contiene codice, ma solo i prompt che descrivono le funzionalità che lo script finale dovrà implementare.

Esempio di una pagina di phishing renderizzata assemblando JavaScript generato dinamicamente in tempo reale nel browser

La risposta dell’LLM arriva come testo: i frammenti di JavaScript vengono fornito sottoforma di stringhe. A questo punto entra in gioco la runtime assembly, che modifica il codice originario della pagina, concatenando le nuove stringhe e inserendole nel DOM. In pochi istanti, senza modificare l’URL e senza che l’utente percepisca differenze evidenti, la pagina si trasforma in un form di phishing capace di imitare l’interfaccia di un servizio noto e di inviare le credenziali agli attaccanti.

Un effetto collaterale di questo approccio è una forma di polimorfismo praticamente automatica, dato che gli LLM non producono, per loro stessa natura, output deterministici: lo stesso prompt può generare risposte diverse in momenti diversi, pur mantenendo invariata la logica. È proprio questo aspetto a rendere più difficile la detection ai motori di sicurezza. Un altro elemento evidenziato dagli esperti di Unit 42 riguarda il concetto di offuscamento: di solito chi scrive malware per browser usa tecniche come encoding, cifratura, concatenazione di stringhe e vari passaggi intermedi per nascondere il codice malevolo. Qui l’offuscamento avviene in chiaro perché il comportamento pericoloso è descritto in un paragrafo di testo, leggibile, che un LLM trasforma in codice eseguibile, e per un motore di analisi classico quel blocco di testo non è sospetto per sua natura.

Il report inquadra questa tecnica in una tendenza più ampia che gli analisti osservano da tempo sotto l’etichetta di runtime assembly. Una parte consistente delle URL malevole analizzate ogni giorno non consegna un codice pericoloso ‘completo’ al primo colpo, ma lo costruisce per step successivi direttamente nel browser, usando script dinamici, decodifiche progressive e concatenazioni di stringhe. La novità introdotta dall’uso degli LLM non è dunque la logica di assemblaggio in runtime, ma il modo in cui si produce il codice da assemblare, che non passa per frammenti offuscati preparati in anticipo, ma per un output generato al volo da servizi esterni legittimi.

Sul fronte difensivo, il messaggio che emerge dal lavoro della Unit 42 è la necessità di spostare l’attenzione molto più vicino al punto di esecuzione, cioè dentro il browser stesso o in ambienti di analisi che eseguono le pagine, osservando cosa succede dopo le chiamate all’LLM e dopo l’assemblaggio del codice. Questo significa, in pratica, mettere al centro l’analisi comportamentale, tramite il monitoraggio di pattern di azioni sospette che si evolvono nel tempo.