Riepilogo Tecnico: Honeyval – Un Framework di Valutazione Completo per Honeypot HTTP Alimentati da LLM

Enunciato del Problema

Gli honeypot sono sistemi esca difensivi progettati per imitare componenti reali di uno stack software al fine di rilevare, monitorare e studiare gli attaccanti. Sebbene gli honeypot ad alta interazione tradizionali offrano simulazioni realistiche, si basano su risorse di sistema reali, esponendo i difensori a rischi di sicurezza significativi. Recentemente, i Modelli Linguistici di Grandi Dimensioni (LLM) sono emersi come soluzione per simulare interazioni di sistema con alta fedeltà senza richiedere l'accesso a risorse host vulnerabili.

Tuttavia, lo sviluppo di honeypot alimentati da LLM manca di un framework di valutazione unificato, scalabile e riproducibile. I metodi di valutazione attuali soffrono di tre limitazioni principali:

1. Scalabilità: La dipendenza da test manuali in laboratorio o da distribuzioni reali sparse rende difficile lo sviluppo iterativo.
2. Riproducibilità: Le valutazioni spesso mancano di configurazioni di sistema precise. Quando gli LLM simulano sistemi sottodefiniti, generano dettagli incoerenti (ad esempio, stati del file system) tra diverse esecuzioni, rendendo i risultati non confrontabili.
3. Rappresentatività: I confronti statici tra comandi e output o le interazioni aperte non riescono a catturare catene di attacco realistiche o ad adattarsi a obiettivi avversari specifici.

Le valutazioni esistenti misurano tipicamente la somiglianza delle risposte rispetto a comandi fissi, conducono test manuali o vengono distribuite online. Questi metodi non affrontano adeguatamente la dinamica "gatto e topo" in cui sia gli attaccanti che i difensori si adattano l'uno all'altro.

Metodologia: Il Framework Honeyval

Per colmare queste lacune, gli autori introducono Honeyval, un framework di valutazione completo specificamente progettato per honeypot HTTP alimentati da LLM. Il framework si basa su 16 configurazioni realistiche di applicazioni backend tratte da BaxBench, un benchmark per la sicurezza delle applicazioni web generate da LLM.

Componenti Principali

1. Ambienti: Honeyval utilizza 16 applicazioni backend distinte (ad esempio, calcolatrici, cataloghi prodotti, servizi di accesso) definite da specifiche OpenAPI standardizzate. Ogni applicazione include:

   • Un'implementazione sicura.
   • Un'implementazione insicura e sfruttabile.
   • Una suite di test funzionali.
   • Un obiettivo di sfruttamento definito (ad esempio, scaricare uno script, eliminare una tabella del database, modificare una password di amministratore o esfiltrare l'archiviazione del browser).

2. Compiti di Valutazione: Il framework impiega tre compiti distinti per garantire robustezza e confrontabilità:

   • Compito Principale (Honeypot vs. Attaccante): Un agente di hacking AI interagisce direttamente con l'honeypot alimentato da LLM. L'honeypot simula l'API backend, mentre l'agente tenta di raggiungere l'obiettivo di sfruttamento definito. Le metriche tracciate includono la lunghezza dell'interazione (numero di richieste), i costi di esecuzione, la latenza e i tassi di rilevamento dell'honeypot.
   • Compito di Controllo dell'Agente: L'agente di hacking interagisce con le implementazioni reali sicure e insicure delle applicazioni backend. Questo compito misura la capacità di base dell'agente di sfruttare le vulnerabilità e la sua abilità nel distinguere tra sistemi reali e honeypot (Tasso di Falsi Positivi).
   • Compito di Controllo dell'Honeypot: L'honeypot viene testato contro la suite di test funzionali dell'applicazione backend che simula. Ciò garantisce che le risposte dell'LLM abbiano alta fedeltà funzionale e non siano facilmente rilevabili da richieste benigne.

3. Agenti e Modelli:

   • Attaccanti: Il framework viene testato contro un agente ReAct personalizzato e agenti di codifica all'avanguardia (Claude Code, Gemini CLI).
   • Honeypot: Lo studio valuta cinque LLM a basso costo (Gemini 3 Flash, Claude Haiku 4.5, Gemini 2.5 Flash, Qwen 3.5 9B, GPT 5.4 Nano) che fungono da spina dorsale della simulazione.
   • Baseline: Un honeypot a bassa interazione basato su regole (API simulata) funge da baseline per il confronto.

4. Adattabilità: Il framework consente di testare configurazioni di honeypot personalizzate (ad esempio, istruendo l'LLM a tentare un'iniezione di prompt o a convincere l'attaccante che il sistema è sicuro) e configurazioni di agenti (ad esempio, istruendo gli agenti a nascondere le loro intenzioni).

Contributi Chiave

1. Formulazione dei Requisiti: Gli autori identificano e formalizzano quattro requisiti chiave per la valutazione degli honeypot LLM: Scalabilità, Riproducibilità, Rappresentatività e Adattabilità.
2. Framework Honeyval: Introducono e rendono open-source il primo framework di valutazione completo per honeypot HTTP alimentati da LLM, caratterizzato da 16 ambienti backend radicati e una struttura di compiti tripartita (Principale, Controllo Agente, Controllo Honeypot).
3. Valutazione Empirica Estesa: Il documento presenta una valutazione su larga scala di LLM a basso costo come honeypot contro agenti di hacking AI all'avanguardia, analizzando le dinamiche di interazione, le asimmetrie di costo e i tassi di rilevamento.

Risultati e Analisi

Lunghezza dell'Interazione e Coinvolgimento

Gli honeypot alimentati da LLM superano significativamente le baseline basate su regole nel coinvolgere gli attaccanti.

• Metrica: Lunghezza media dell'interazione (richieste per interazione).
• Risultato: Gli honeypot alimentati da LLM hanno sostenuto interazioni per una media di 82,6 richieste, rispetto alle 30,6 richieste degli honeypot basati su regole. Ciò indica che gli LLM possono mantenere l'illusione di un sistema reale molto più a lungo, fornendo ai difensori più dati sulle tattiche degli attaccanti.

Rilevabilità

• Metrica: Tasso di Veri Positivi (TPR) di rilevamento dell'honeypot da parte degli agenti vs. Tasso di Falsi Positivi (FPR) su applicazioni reali.
• Risultato: Mentre gli honeypot basati su regole sono stati identificati a tassi schiaccianti, gli honeypot alimentati da LLM sono stati significativamente più difficili da rilevare. Nella maggior parte dei casi, i tassi di rilevamento erano ben al di sotto del 40%. Vale la pena notare che anche modelli più piccoli come Qwen 3.5 9B hanno ottenuto buoni risultati. Tuttavia, gli agenti che utilizzavano Gemini CLI hanno mostrato tassi di rilevamento elevati ma anche alti FPR sulle applicazioni reali, suggerendo un giudizio inaffidabile in quella specifica configurazione.

Asimmetria dei Costi

• Metrica: Vantaggio relativo dei costi di esecuzione (Costo Agente / Costo Honeypot).
• Risultato: Nonostante l'uso di un'architettura ingenua in cui l'honeypot elabora ogni richiesta individualmente, gli honeypot alimentati da LLM hanno generalmente mantenuto un vantaggio di costo rispetto agli agenti attaccanti. Ciò suggerisce che anche in una configurazione non ottimizzata, il difensore può sostenere l'interazione a un costo inferiore rispetto a quello che l'attaccante può sostenere per l'attacco.

Trade-off tra Latenza e Fedeltà

• Latenza: Un limite chiave identificato è la latenza di risposta. Anche i modelli più veloci (Gemini 3 Flash) hanno richiesto circa 3,3 secondi per risposta.
• Fedeltà: I modelli hanno raggiunto un'alta fedeltà funzionale (punteggi Pass@1 >70% sulle suite di test), ma questo è avvenuto a scapito di una generazione di token elevata (media di 200–500+ token per risposta), che aumenta i costi e la latenza.
• Correlazione con il Rilevamento: Sebbene la latenza non abbia correlato strettamente con i tassi di rilevamento su tutti i modelli, gli agenti hanno spesso citato la latenza di risposta e i timeout come prove per classificare un'applicazione come honeypot.

Impatto delle Istruzioni Personalizzate

Lo studio ha esplorato la modifica dei prompt degli honeypot per raggiungere obiettivi controffensivi:

• Prompt "Convinci": Istruire l'honeypot ad affermare che l'applicazione è sicura ha aumentato la lunghezza dell'interazione (media 102,6 richieste) ma ha anche aumentato il tasso di rilevamento (TPR 0,45).
• Prompt "Attento PI" (Prompt Injection): Istruire l'honeypot a tentare un'iniezione di prompt ha aumentato significativamente i tassi di rilevamento (TPR 0,49) e ridotto la lunghezza dell'interazione, poiché gli agenti hanno spesso rilevato i tentativi di iniezione. Questa configurazione ha anche degradato la fedeltà funzionale sulle suite di test benigne.

Significato e Affermazioni

Il documento afferma che Honeyval fornisce una base necessaria, scalabile e riproducibile per lo sviluppo di honeypot alimentati da LLM. Gli autori affermano che:

1. Gli LLM sono Difensori Promettenti: Gli honeypot alimentati da LLM offrono un'alternativa valida ai sistemi ad alta interazione, fornendo simulazioni ad alta fedeltà con rischi di sicurezza minimi e costi operativi inferiori rispetto al costo dell'attacco.
2. La Valutazione è Critica: I compromessi unici osservati (ad esempio, interazioni più lunghe vs. rischio di rilevamento più elevato quando si utilizzano prompt controoffensivi) evidenziano la necessità dei compiti di controllo forniti da Honeyval per monitorare gli effetti collaterali delle modifiche alla configurazione.
3. Direzioni Future: Il lavoro suggerisce che, sebbene le attuali architetture ingenua siano efficaci, i futuri miglioramenti nella gestione del contesto (caching, memoria) e nell'hardware di inferenza potrebbero migliorare ulteriormente le prestazioni. Il framework è progettato per supportare l'evoluzione sia degli attaccanti automatizzati che dei difensori.

Gli autori concludono che, sebbene gli honeypot alimentati da LLM mostrino chiare promesse, il loro dispiegamento richiede una configurazione e un monitoraggio attenti, facilitati da Honeyval. Il framework è reso open-source per avanzare gli sforzi della comunità in questo dominio.