PaperlayerView exact revision on arXiv

Source-linked AI summary

LLM-Based Penetration Testing in the Presence of Honeypots

Xinhong Xie, Piyush Nagasubramaniam, Neeraj Karamchandani, Sencun Zhu

arXiv:2609.08093v1cs.CR

TL;DR

The paper addresses how LLM attackers should use imperfect honeypot evidence to select targets and stop after entry when operating under a finite budget. It proposes a detector-guided policy and finds that its benefits depend on available budget in a controlled testbed, while noting limits on scale and service diversity.

  • Problem

    Existing work does not examine how imperfect honeypot evidence should guide target selection and post-entry stopping for LLM attackers with finite execution budgets.

    Source: §1.2 · p. 2

  • Method

    A two-stage policy combines conservative pre-connect screening, budget-aware host ranking, and post-connect stopping for an LLM attack agent.

    Source: §7 · p. 12

  • Results

    In a controlled containment configuration, post-connect verification reduced LLM budget spent continuing an entered honeypot branch, and the full policy's benefit depended on available budget.

    Source: §7 · p. 12

  • Takeaways & Limitations

    The results support evaluating honeypot detection as part of an integrated attack process rather than as an isolated classification task.

    Source: §7 · p. 12

    Evaluation is limited to a controlled 20-host post-triage pool concentrated on SSH and web services, with few successful post-connect branches and detector overhead excluded from the primary LLM budget.

    Source: §6.3 · p. 12

Abstract

from arXiv · show

Large language model (LLM) agents are increasingly employed for offensive cybersecurity tasks such as automated vulnerability discovery, reconnaissance, and penetration testing. This new capability also threatens one of the defender's most valuable tools: deception. Traditional honeypots rely on realism and obscurity to lure human or script-driven attackers into revealing tactics, techniques, and procedures (TTPs), but LLM-driven attackers can reason about heterogeneous artifacts and use the honeypot suspicion to guide target-selection decisions. We present a systematic study of honeypot-aware budget allocation for LLM attack agents. We formalize the attacker's problem as a budgeted decision process: an agent interacts with potential targets, consuming LLM execution budget during reconnaissance and exploitation, and must decide whether to (continue exploitation) or (skip) when honeypot suspicion arises. Our findings show that with the proposed detector-guided policy, LLM agent attackers can effectively allocate budget to compromise hosts in a host pool, highlighting the importance of dynamically allocating budget in a controlled mixed-host testbed. While defenses are beyond our present scope, we discuss implications for future adversarially resilient and adaptive honeypot design.

1 Introduction

LLM agents can reassess deception evidence and redirect attacks, making target choice under limited execution budgets a central problem. This work integrates imperfect honeypot evidence into budget-constrained target selection and post-entry stopping.

1 Introduction

  • Because LLM agents can revise decisions as evidence arrives, they can reconsider whether a deceptive-looking host merits further attack cost, unlike fixed attack sequences.Source: §1 · p. 1

1.1 Motivation

  • Resource-constrained attackers could use evidence gathered before and during interaction to estimate honeypot likelihood, prioritize severe vulnerabilities, and avoid deceptive branches.Source: §1.1 · p. 2

1.2 Research Gap

  • Existing work leaves open how imperfect honeypot evidence should guide target selection and post-entry stopping for LLM attackers with finite execution budgets.Source: §1.2 · p. 2

1.4 Contributions

  • Its contribution is a unified policy combining conservative pre-connect screening, budget-aware host ranking, and post-connect stopping, evaluated on controlled mixed hosts.Source: §1.2 · p. 2, §1.4 · p. 2

1.3 Problem Statement

  • The paper frames the problem as allocating a finite query budget across potential targets to maximize confirmed genuine hosts while avoiding honeypots.Source: §1.3 · p. 2

2 Background and Related Work

Honeypots use decoy systems to attract attackers, but fingerprintable implementation artifacts can reveal deception. The threat model studies an LLM attacker allocating a finite budget within a pre-triaged pool of vulnerable hosts.

2.1 Honeypot Deception and Fingerprinting

  • Protocol behavior, banners, timing, and incomplete functionality can expose deceptive services, motivating protocol-level evidence for honeypot detection.Source: §2.1 · p. 2

2.2 Threat Model

  • The attacker selects among pre-triaged vulnerable genuine hosts and honeypots, choosing whether to continue engagement or disengage under a total token budget.The study focuses on target selection within the candidate set, not upstream network-wide discovery; deceptive hosts are outbound-contained in the evaluation.Source: §2.2 · pp. 2–3

3 Attacker Decision Model

The attacker screens and ranks candidate hosts using honeypot evidence, vulnerability severity, and realized LLM cost. It updates budget pressure as spending departs from the expected pace and verifies hosts again after entry.

3.1 System Overview

  • The system screens candidates before entry, ranks them for engagement, and uses post-entry evidence to reassess authenticity and stop suspected honeypot branches.Source: §3.1 · p. 3

3.2 Detector-Guided Host Decision

  • A normalized genuine-likeness score is updated with pre- and post-connect evidence to determine whether a host is rejected, entered, or abandoned.Source: §3.2 · p. 3

3.3 Two-Stage Detection Decisions

  • Pre-connect screening rejects hosts below its threshold, while post-connect verification abandons branches below a separate threshold; passing screening does not confirm genuineness.Source: §3.3 · pp. 3–4

3.4 Budget-Aware Entry Scoring

  • The entry score prioritizes likely genuine, higher-severity hosts while penalizing honeypot evidence and previously spent LLM budget; greater budget pressure strengthens the cost penalty.Source: §3.4 · p. 4

3.5 Budget-Pressure Update

  • Budget pressure rises when realized LLM cost exceeds the expected spending pace and falls when spending is below that pace.The update uses a step size; the expected pace is informed by conservative and optimistic budget horizons.Source: §3.5 · p. 4

4 Experimental Setup and Episode Construction

The evaluation uses a controlled mixed-host pool to study budget-limited LLM attack decisions, with screening before entry and verification after a foothold.

4.1 Testbed and Target Pool

  • The testbed contains 20 post-triage hosts—8 honeypots and 12 genuine vulnerable machines—in an isolated network spanning SSH, Web, SMB, and FTP.The genuine set consists of intentionally vulnerable laboratory machines; verifiable access or command execution counts as genuine progress.Source: §4.1 · p. 5

4.2.1 Pre-Connect Detector

  • The pre-connect detector compares protocol artifacts with real and honeypot prototypes and uses the weaker of two probe scores; its uncalibrated score screens honeypot-labeled hosts.Genuine and uncertain hosts remain candidates for downstream ranking.Source: §4.2.1 · p. 5

4.2.2 Post-Connect Detector

  • After a shell-like foothold, the post-connect detector first checks whether low-risk command responses are consistent and stateful, abandoning branches that fail this gate.Checks include command availability, output consistency, filesystem and process information, and persistence across commands.Source: §4.2.2 · p. 5
  • Hosts passing the command gate undergo an outbound test; valid payloads reaching an isolated collector provide stronger evidence of genuine network execution.The outbound score increases with valid payload count; under the containment model, these side effects are permitted for genuine hosts but blocked for honeypots.Source: §4.2.2 · pp. 5–6

4.4 Parameter Settings

  • Table 1’s detector and policy settings are shared across policies and budget regimes, while decision-range parameters are computed separately for each maximum budget.LLM invocations count toward the episode budget, but local-tool runtime does not.Source: Table 1 · p. 6, §4.4 · pp. 6–7, §4.3 · p. 6

4.3 LLM Attacker

  • The LLM attacker iteratively observes and acts on a selected host, with initial access requiring verifiable capability and a foothold triggering post-connect verification.A branch ends upon genuine confirmation, honeypot abandonment, terminal failure, or budget exhaustion.Source: §4.3 · p. 6

5 Experimental Evaluation

The evaluation examines how a detector-guided, two-stage attack policy allocates limited LLM budget across candidate hosts, including detector signals, host ranking, post-entry stopping, and end-to-end outcomes. It also assesses the distinct roles of pre-connect screening, post-connect verification, and dynamic budget pressure.

5.1 Ground Truth and Outcome Definitions

  • The controlled testbed contained 20 hosts—eight honeypots and twelve intentionally vulnerable machines—and distinguished genuine confirmations, false rejects, false entries, delayed abandonments, and unresolved hosts.CVE scans skip hosts with no or poor CVE results as non-vulnerable; each scan costs $0.002–$0.003, or $2–$3 for 1,000 such machines.Source: §5 · p. 7, §5.1 · p. 7

5.2.1 RQ1: Detector Effectiveness

  • The proposed pre-connect detector raises accuracy from 0.70 to 0.80, F1-score from 0.50 to 0.67, and recall from 0.38 to 0.50, while reducing genuine-host false-rejection rate from 0.08 to 0.00.Under controlled containment, the post-connect detector achieved accuracy, precision, recall, and F1-score of 1.00 on 8 honeypot and 8 genuine branches; pre-connect screening conservatively rejects only hosts with strong honeypot evidence, preserving all genuine hosts in the evaluated pool.Source: §5.2.1 · pp. 7–8, Table 2 · p. 8, Table 3 · p. 8

5.2.2 RQ2: Entry-Ranking Quality

  • The proposed detector places three genuine hosts among the top three candidates, versus two for no-detector and service-metadata settings and one for banner-only.It also achieves entry precision 0.75 and false-entry rate 0.25, compared with 0.60 and 0.40 without detector guidance; all methods prioritize the first genuine host, while detector guidance improves subsequent candidates.Source: Table 4 · p. 8, §5.2.2 · p. 8
  • The entry-score ablation places 1.77 expected genuine hosts in the top three with CVSS-only ordering, while detector-score strategies place 3.00 there; the full score raises top-five count from 4.50 to 4.83.CVSS-only performs worse than random ordering, and the full score mainly refines later entry decisions after detector scores prioritize early candidates.Source: §5.2.2 · p. 8, Table 5 · p. 9

5.2.3 RQ3: Post-Connect Loss Reduction

  • 0.042 average honeypot cost under the proposed post-connect detector, versus 0.500 without stopping, represents a 91.6% reduction and stops all evaluated honeypot branches.The detector terminates an entered ambiguous honeypot after shell-level evidence becomes available; the rule-based baseline costs 0.438 and stops 50% of evaluated branches.Source: Table 6 · p. 9, §5.2.3 · p. 9

5.2.4 RQ4: End-to-End Budget Efficiency

  • At $5, the full policy confirmed 3.66 genuine hosts versus 3.00 for fixed-budget allocation and 2.33 for random selection, reaching 91.5% of the four-host testbed ceiling.At $3, it confirmed 2.33 genuine hosts versus 1.66 for each baseline; at $4, it confirmed 2.66 versus 2.33 for fixed-budget and 1.66 for random. Figure 2 also shows lower cumulative expenditure for the detector-guided policy at the second and third genuine-host confirmations.Source: §5.2.4 · p. 10, Figure 2 · p. 10, Table 7 · p. 11

5.2.5 Ablation Test

  • At Bmax=$5, the leave-one-component-out ablation found that removing the pre-connect detector, post-connect detector, or dynamic budget-pressure mechanism degraded the full policy in different ways.The ablations kept the candidate pool, LLM attacker, host ordering, and total execution budget unchanged.Source: §5.2.5 · pp. 10–11
  • Removing the pre-connect detector lowers confirmed genuine hosts from 3.66 to 3.33, raises wasted honeypot cost from 0.18 to 0.61, and increases honeypot entry from 58% to 63%.Budget to the first genuine confirmation decreases from 0.91 to 0.74, so the detector’s main benefit is improving candidate quality and ranking rather than reaching the first genuine host faster.Source: §5.2.5 · p. 11
  • Removing post-connect verification reduces confirmed genuine hosts from 3.66 to 2.66, raises budget to the first genuine confirmation from 0.91 to 1.28, and increases wasted honeypot cost from 0.18 to 0.31.Honeypot entry remains at 58% because this detector operates after entry; its role is to distinguish genuine progress from deceptive apparent footholds.Source: §5.2.5 · pp. 11–12
  • Setting µk = 0 reduces confirmed genuine hosts from 3.66 to 0.33 and yields no honeypot entries or honeypot-related cost.These zero values do not indicate better deception avoidance: without cost pressure, expenditure no longer lowers a host’s priority, limiting budget reallocation and progress through the candidate pool.Source: §5.2.5 · p. 12
  • The full three-component policy confirms the most genuine hosts while keeping honeypot expenditure substantially below detector-ablated variants.The components improve candidate quality before entry, verify apparent progress after entry, and promote reallocation away from costly branches.Source: §5.2.5 · p. 12, Table 8 · p. 12

6 Discussion and Future Work

The discussion proposes measuring honeypot effectiveness by the LLM cost imposed before an attacker reaches a confident decision, with pre-connect uncertainty and post-connect verification affecting different stages. The study is limited to isolated passive detection and budget allocation, and its controlled evaluation motivates broader future work.

6.1 Implications

  • Pre-connect uncertainty and post-connect verification affect different stages of the LLM cost imposed before an attacker reaches a confident decision.The authors propose this cost as a complement to measuring whether a honeypot is eventually detected.Source: §6.1 · p. 12

6.2 Ethical and Policy Considerations

  • All experiments used authorized systems in an isolated laboratory network; active retaliation and third-party interaction are outside the study's scope.The study covers passive honeypot detection and budget allocation.Source: §6.2 · p. 12

6.3 Limitations

  • The evaluation is limited by its 20-host post-triage pool, service concentration, few successful post-connect branches, and exclusion of deterministic detector overhead from the primary LLM budget.It evaluates decisions within a post-triage candidate set, not end-to-end network-wide discovery or large-scale asset enumeration.Source: §6.3 · p. 12
  • Future work should evaluate larger, more heterogeneous candidate pools and integrate the policy with large-scale discovery or vulnerability-triage pipelines.The authors also identify multi-agent co-evolution, online learning, and large-scale deployment traces as directions for future work.Source: §6.3 · p. 12

7 Conclusion

The paper introduces a host-level policy for LLM attackers that combines conservative pre-connect screening, budget-aware ranking, and post-connect stopping. In the controlled testbed, the stages affected different parts of the attack process, and the policy's benefit depended on available budget; evaluation of larger and more diverse environments remains future work.

7 Conclusion

  • The two-stage detector-guided policy combines conservative pre-connect screening, budget-aware host ranking, and post-connect stopping.The contribution is a host-level formulation of honeypot-aware budget allocation for LLM attack agents.Source: §7 · p. 12
  • In the controlled containment configuration, pre-connect screening preserved all genuine hosts, while post-connect verification reduced LLM budget spent continuing entered honeypot branches.The end-to-end benefit of the full policy depended on the available budget.Source: §7 · p. 12
  • The study leaves larger, more heterogeneous data-center environments for future evaluation, including more diverse services and adaptive attackers and honeypots.Source: §7 · p. 12
Loading 2609.08093v1…