Technische Samenvatting: Honeyval – Een Omvattend Evaluatiekader voor LLM-gedreven HTTP Honeypots

Probleemstelling

Honeypots zijn defensieve misleidingsystemen die zijn ontworpen om echte componenten van een softwarestack na te bootsen om aanvallen te detecteren, te monitoren en te bestuderen. Hoewel traditionele high-interaction honeypots realistische simulaties bieden, maken ze gebruik van daadwerkelijke systeembronnen, waardoor verdedigers worden blootgesteld aan aanzienlijke veiligheidsrisico's. Recentelijk zijn Large Language Models (LLM's) opgekomen als oplossing om systeeminteracties met hoge fideliteit te simuleren zonder toegang te vereisen tot kwetsbare hostbronnen.

Echter, de ontwikkeling van LLM-gedreven honeypots mist een verenigd, schaalbaar en reproduceerbaar evaluatiekader. Bestaande evaluatiemethoden lijden aan drie primaire beperkingen:

1. Schaalbaarheid: De afhankelijkheid van handmatige tests in het laboratorium of schaarse implementaties in de echte wereld maakt iteratieve ontwikkeling moeilijk.
2. Reproduceerbaarheid: Evaluaties missen vaak precieze systeemconfiguraties. Wanneer LLM's onvoldoende gespecificeerde systemen simuleren, genereren ze inconsistente details (bijvoorbeeld bestandssysteemtoestanden) tussen verschillende runs, waardoor resultaten niet vergelijkbaar zijn.
3. Representativiteit: Statische vergelijkingen van commando's en output of open-ended interacties slagen er niet in om realistische aanvalsketens vast te leggen of zich aan te passen aan specifieke tegenstanderdoelen.

Bestaande evaluaties meten doorgaans de gelijkenis van antwoorden tegen vaste commando's, voeren handmatige tests uit of implementeren online systemen. Deze methoden adresseren de "kat-en-muis"-dynamiek waarin zowel aanvallers als verdedigers zich aan elkaar aanpassen, niet adequaat.

Methodologie: Het Honeyval Kader

Om deze gaten op te vullen, introduceren de auteurs Honeyval, een omvattend evaluatiekader dat specifiek is ontworpen voor LLM-gedreven HTTP honeypots. Het kader is gebaseerd op 16 realistische backend-toepassingsconfiguraties afkomstig uit BaxBench, een benchmark voor door LLM's gegenereerde webapp-beveiliging.

Kerncomponenten

1. Omgevingen: Honeyval maakt gebruik van 16 verschillende backend-toepassingen (bijvoorbeeld rekenmachines, productcatalogi, inlogdiensten) die zijn gedefinieerd door gestandaardiseerde OpenAPI-specificaties. Elke applicatie omvat:

   • Een veilige implementatie.
   • Een onveilige, uitbuitbare implementatie.
   • Een functionele testset.
   • Een gedefinieerd exploit-doel (bijvoorbeeld het downloaden van een script, het verwijderen van een database-tabel, het wijzigen van een beheerderswachtwoord of het exfiltreren van browseropslag).

2. Evaluatietaken: Het kader hanteert drie distincte taken om robuustheid en vergelijkbaarheid te waarborgen:

   • Hoofdtaken (Honeypot vs. Aanvaller): Een AI-hackagent interageert rechtstreeks met de LLM-gedreven honeypot. De honeypot simuleert de backend-API, terwijl de agent probeert het gedefinieerde exploit-doel te bereiken. Gevolgde metrieken omvatten interactielengte (aantal verzoeken), operationele kosten, latentie en detectiesnelheden van de honeypot.
   • Agent Control-taak: De hackagent interageert met de echte veilige en onveilige implementaties van de backend-toepassingen. Deze taak meet de basisvaardigheid van de agent om kwetsbaarheden uit te buiten en zijn vermogen om onderscheid te maken tussen echte systemen en honeypots (Fout-positiefpercentage).
   • Honeypot Control-taak: De honeypot wordt getest tegen de functionele testset van de backend-toepassing die hij simuleert. Dit zorgt ervoor dat de antwoorden van de LLM een hoge functionele fideliteit hebben en niet eenvoudig kunnen worden gefingerprintd door onschadelijke verzoeken.

3. Agents en Modellen:

   • Aanvallers: Het kader test tegen een aangepaste ReAct-agent en geavanceerde coderingsagents (Claude Code, Gemini CLI).
   • Honeypots: De studie evalueert vijf kostenefficiënte LLM's (Gemini 3 Flash, Claude Haiku 4.5, Gemini 2.5 Flash, Qwen 3.5 9B, GPT 5.4 Nano) die fungeren als de simulatie-ruggengraat.
   • Baselines: Een op regels gebaseerde, low-interaction honeypot (mock API) dient als baseline voor vergelijking.

4. Aanpasbaarheid: Het kader maakt het testen van aangepaste honeypot-configuraties mogelijk (bijvoorbeeld het instrueren van de LLM om prompt-injectie te proberen of de aanvaller ervan te overtuigen dat het systeem veilig is) en agent-configuraties (bijvoorbeeld het instrueren van agents om hun intentie te verbergen).

Belangrijkste Bijdragen

1. Vormgeving van Vereisten: De auteurs identificeren en formaliseren vier kernvereisten voor de evaluatie van LLM-honeypots: Schaalbaarheid, Reproduceerbaarheid, Representativiteit en Aanpasbaarheid.
2. Honeyval Kader: Zij introduceren en open-source het eerste omvattende evaluatiekader voor LLM-gedreven HTTP honeypots, met 16 onderbouwde backend-omgevingen en een drievoudige taakstructuur (Hoofd, Agent Control, Honeypot Control).
3. Uitgebreide Empirische Evaluatie: Het artikel presenteert een grootschalige evaluatie van kostenefficiënte LLM's als honeypots tegen state-of-the-art AI-hackagents, waarbij interactiedynamiek, kostenasymmetrieën en detectiesnelheden worden geanalyseerd.

Resultaten en Analyse

Interactielengte en Betrokkenheid

LLM-gedreven honeypots presteren significant beter dan op regels gebaseerde baselines in het betrekken van aanvallen.

• Metriek: Gemiddelde interactielengte (verzoeken per interactie).
• Vindpunt: LLM-gedreven honeypots handhaafden interacties gemiddeld gedurende 82,6 verzoeken, vergeleken met 30,6 verzoeken voor op regels gebaseerde honeypots. Dit geeft aan dat LLM's de illusie van een echt systeem veel langer kunnen volhouden, waardoor verdedigers meer data krijgen over tactieken van aanvallen.

Detecteerbaarheid

• Metriek: True Positive Rate (TPR) van honeypot-detectie door agents versus False Positive Rate (FPR) op echte applicaties.
• Vindpunt: Waar op regels gebaseerde honeypots in overweldigende mate werden geïdentificeerd, waren LLM-gedreven honeypots aanzienlijk moeilijker te detecteren. In de meeste gevallen lagen de detectiesnelheden ruim onder de 40%. Opmerkelijk is dat zelfs kleinere modellen zoals Qwen 3.5 9B goed presteerden. Agents die echter de Gemini CLI gebruikten, vertoonden hoge detectiesnelheden, maar ook hoge FPR's op echte applicaties, wat wijst op onbetrouwbare beoordeling in die specifieke configuratie.

Kostenasymmetrie

• Metriek: Relatief voordeel in operationele kosten (Agentkosten / Honeypotkosten).
• Vindpunt: Ondanks het gebruik van een naïeve architectuur waarbij de honeypot elk verzoek individueel verwerkt, behielden LLM-gedreven honeypots over het algemeen een kostenvoordeel ten opzichte van de aanvallende agents. Dit suggereert dat zelfs in een niet-geoptimaliseerde opstelling de verdediger de interactie kan volhouden tegen lagere kosten dan de aanvaller de aanval kan volhouden.

Latentie en Fideliteit Trade-offs

• Latentie: Een belangrijke beperking die is geïdentificeerd, is de responslatentie. Zelfs de snelste modellen (Gemini 3 Flash) deden ongeveer 3,3 seconden per antwoord.
• Fideliteit: Modellen behaalden een hoge functionele fideliteit (Pass@1-scores >70% op testsets), maar dit ging ten koste van een hoge token-generatie (gemiddeld 200–500+ tokens per antwoord), wat de kosten en latentie opdrijft.
• Detectiecorrelatie: Hoewel latentie niet strikt correleerde met detectiesnelheden over alle modellen heen, citeerden agents frequent responslatentie en time-outs als bewijs om een applicatie te classificeren als honeypot.

Impact van Aangepaste Instructies

De studie onderzocht het aanpassen van honeypot-prompten om tegenoffensieve doelen te bereiken:

• "Overtuigen"-prompt: Het instrueren van de honeypot om te beweren dat de applicatie veilig is, verhoogde de interactielengte (gemiddeld 102,6 verzoeken), maar verhoogde ook de detectiesnelheid (TPR 0,45).
• "Voorzichtig PI" (Prompt Injection)-prompt: Het instrueren van de honeypot om prompt-injectie te proberen, verhoogde de detectiesnelheden aanzienlijk (TPR 0,49) en verkortte de interactielengte, aangezien agents de injectiepogingen vaak detecteerden. Deze configuratie degradeerde ook de functionele fideliteit op onschadelijke testsets.

Betekenis en Beweringen

Het artikel beweert dat Honeyval een noodzakelijke, schaalbare en reproduceerbare basis biedt voor de ontwikkeling van LLM-gedreven honeypots. De auteurs stellen het volgende:

1. LLM's zijn Veelbelovende Verdedigers: LLM-gedreven honeypots bieden een haalbaar alternatief voor high-interaction systemen, waarbij ze simulaties met hoge fideliteit bieden met minimale veiligheidsrisico's en lagere operationele kosten in vergelijking met de kosten van de aanval.
2. Evaluatie is Kritiek: De unieke trade-offs die worden waargenomen (bijvoorbeeld langere interacties versus een hoger detectierisico bij het gebruik van tegenoffensieve prompten) benadrukken de noodzaak van de control-taken die door Honeyval worden geboden om de neveneffecten van configuratiewijzigingen te monitoren.
3. Toekomstige Richtingen: Het werk suggereert dat hoewel huidige naïeve architecturen effectief zijn, toekomstige verbeteringen in contextbeheer (caching, geheugen) en inferentiehardware de prestaties verder kunnen verbeteren. Het kader is ontworpen om de evolutie van zowel geautomatiseerde aanvallen als verdedigers te ondersteunen.

De auteurs concluderen dat hoewel LLM-gedreven honeypots duidelijke belofte tonen, hun implementatie zorgvuldige configuratie en monitoring vereist, wat Honeyval faciliteert. Het kader is open-source gemaakt om de inspanningen van de gemeenschap op dit gebied te bevorderen.