Guided Reasoning in LLM-Driven Penetration Testing Using Structured Attack Trees

Response to Reviewer Questions:

Q1: Figure 1: What are the dotted arrows suggesting?

The referenced dotted arrows represent an interaction between LLM and the structured task tree (STT) used to guide reasoning. This clarification will be added to the caption of Figure 1.

Q2: Figure 1: Curious, in the structure you’ve provided, is it possible to “rollback” a task? My interpretation is “no” - if that’s correct, would there be a good reason to incorporate “undoing”?

No, currently we do not consider the possibility of a task “rollback”. However, this raises an interesting point. If a scenario arises where additional information is discovered about the system (e.g., a new port is identified), it is possible that a previously failing task could now succeed with this new information. While the current version of the agent does not handle this case and it never arose in our benchmark HTB challenges, this is something that we will explore further in the future. Thank you for pointing this out to us.

Q3: How comprehensive are these tasks in terms of its coverage of penetration testing settings in general? Is there potentially a pentest scenario where new tasks must be added for successful completion?

MITRE ATT&CK is a widely adopted taxonomy for adversary behavior that is updated several times per year. The maintainers explicitly note that the list is descriptive, not exhaustive, and novel techniques (e.g., previously unseen hardware faults) can be discovered between releases. In this case, a new task may need to be added for successful completion. However, most ethical penetration testing is scoped to a documented threat model where the attacker can use only certain tactics/techniques. For this form of bounded auditing, the latest form of MITRE ATT&CK would be functionally comprehensive, providing enough coverage to capture known and realistic attacker actions.

Q4: Is there a tradeoff between the structure provided by your approach vs. the freedom of Deng et al. (2024)? In the long run, do you think an LM’s planning capabilities will be good enough that it is preferable to give the LM more freedom, rather than having it subscribe to a particular task scaffold / tree.

We believe there is an inherent trade-off here. Our structured reasoning approach currently produces the highest success rates because it constrains the search space and grounds each step in MITRE ATT&CK. This not only guides the agent, but also provides a shared vocabulary that allows LLMs to better associate their internal knowledge with concrete penetration testing tasks and actions. However, as noted in the previous question, this constrained search space is not comprehensive. Techniques outside of MITRE ATT&CK cannot be used by our structured approach. As LM planning capabilities improve, agents with more freedom can exploit novel techniques (e.g., zero-days), allowing them to achieve a higher success rate in the long term. However, we foresee two scenarios where structured reasoning remains advantageous: 1) when using smaller LMs, to avoid the circular reasoning we observed; and 2) in an audit of a specific threat model or for safety-critical testing, to bound attacker actions.

Q5: Lines 239-251: As someone not as familiar with how pentesting works, I think a bit more clarification of how this works would’ve helped. I ended up ChatGPT’ing several of the phrases (e.g. what does a “machine” refer to in this setting). Concretely, is a machine a Docker image / VM / some other kind of infra?

Each machine in our evaluation is a virtualized environment hosted by HackTheBox (HTB), typically implemented as a standalone Linux/Windows VM with common services exposed. Based on the reviewer feedback, we agree that we should provide more background on penetration testing and the HTB benchmarks. We plan to incorporate a subsection, after Section 4.1, to provide more details on what exactly the benchmark machines are, their format, and what a successful penetration test would mean in a HTB machine.

Q6: Suggested citations (Cybench and InterCode-CTF)

Thank you for pointing out these relevant works. We will include these additional citations with discussion.

Minor Comments:

• Minor nit: Perhaps you want to be using the “citep” instead of “cite” command for your citations, as that will add parentheses around the citations.

• Table 1: Minor thought, I think it might be helpful instead to highlight, in green, the top scores + fewest number of queries for each row. The highlighting of multiple “No. Queries” as green was a bit confusing initially. (so for example row 1 would highlight all the 6/6, and just 31. Row 2 would highlight 12/13, and just 49.

• Line 287: Nit, “In sum” => “In summary”

We agree with each of these comments and will make these changes in the camera-ready, if accepted. Thank you for taking the time to identify and write these out for us.

Response to Reviewer Questions:

Q1: On average, how many tokens does the proposed STT-based method consume per task during your evaluation?

On average, our method consumes approximately 324 tokens per task, compared to 321.1 tokens for the baseline (PentestGPT). In both cases, the prompt includes a predefined system prompt and dynamic content based on the task.

For our method, the dynamic portion of the prompt includes either:

1. the description of the current task from the STT along with information provided by the tester, or
2. descriptions of potential next tasks from the STT when selecting the next step.

PentestGPT uses a similar structure, where the dynamic content includes either:

1. information provided by the tester, or
2. the current LLM-generated PTT state, which serves as context for downstream task selection and command generation.

Both approaches provide the LLM with comparable amounts of context, either in the form of task descriptions from MITRE ATT&CK (ours), or the PTT state generated through self-reasoning (PentestGPT). Hence, the actual token count is close because similar information is provided to the LLM in either case. We agree that including this information adds context to the work and our approach. This data will be added with discussion to Table 1.

Q2: Also given that input token length can affect LLM inference speed, can you provide data on the average time taken for each task in your evaluation?

We agree that inference time provides an important metric. This could be done if models are executed locally. However, the models used in this work were executed on cloud resources that we do not directly control. As such, inference time cannot be directly measured and is prone to noise due to variance in utilization, latency, etc. of the servers. For this reason, we chose to provide the number of inferences performed as our primary efficiency metric, rather than time for inference. This comment still raises an important point regarding the tokens in input prompts relative to the baseline. The average prompt length, in tokens, for our proposed approach is 324 tokens compared to 321.1 tokens for the baseline (PentestGPT). These values are close because similar information is provided to the LLM in either case. The primary difference is whether the task information is provided by the STT (ours) or the LLM-generated PTT (PentestGPT), which is prone to circular reasoning. We plan to add this new data and corresponding discussion to our evaluation in Section 4.2.2 and Table 1. We appreciate this comment as it exposes an interesting data point for our work that we did not consider initially.

Q3: How is the STT generated?

The STT is generated using systematization efforts focused on composing MITRE ATT&CK into an ordered representation to reflect how an adversary can progress through an end-to-end cyberattack (i.e., a kill-chain). These efforts use the requirements and information generated by each MITRE ATT&CK technique to represent which techniques can be completed at a given time. The allowable next steps in each case are determined by the information/context generated by the current step in the matrix. For example, in order to do “Search Victim-Owned Websites”, you must first identify an open HTTP port, which requires a prior technique, such as “Active Scanning”. Hence, dependencies exist between different techniques based on the context available. We used [1] to create the ordering of different TTPs in our STT, however, there are a number of other examples that are functionally equivalent (e.g., [2]). We will update Section 3.2 of the manuscript to discuss more details regarding how the STT is constructed/ordered.

Q4: Can the structure of the STT be modified to improve performance? Would it be possible to design the nodes with more flexible numbers of next steps?

Existing penetration testing agents using LLMs rely on self-guided reasoning, which has been shown to be prone to hallucinations and circular reasoning. We address this specific research gap by leveraging the extensive systematization efforts focused on attacker reasoning during penetration testing to construct an STT-based reasoning pipeline, which reduces the hallucination and circular reasoning present in prior work. We do believe the structure of the STT can be modified to improve performance (e.g., by adding flexibility). In fact, we are considering adding probability based node selection as an extension of our work. We appreciate and resonate with the reviewer on the possibility to improve the STT.

Response to Reviewer Questions:

Q1: How does one guarantee that the LLM agent will generate “executable commands”?

This and the following question appear to have identified an area where we did not provide sufficient explanation. We cannot guarantee that the LLM agent generates “executable commands”. When invalid commands were generated by the agent and applied to the HTB machine, an error is usually generated. When this error is given to the agent, the agent recognizes this and instead of marking success/failure, marks the task as “in-progress” and generates another command to run. Upon five invalid commands, the STT would mark the task as failed. We note that this is similar to the approach used by prior work, such as [1]. Section 3.1 will be updated to provide more clarification of this behavior.

Q2: Is the “in-progress” status necessary? If a task is not completed in one iteration, it is marked as failed. The paper does not mention whether multiple attempts are allowed for a single task in Section 3.

Yes, the “in-progress” status captured when the agent generated invalid commands, prompting multiple attempts. We agree that this needs additional clarification. We will update Section 3.1 to make the need and behavior of the “in-progress” status more clear.

Response to Review:

C1: It was unclear how TTPs, which are non-ordered in the MITRE ATT&CK, were processed into the ordered tasks in the proposed STT.

Thank you for pointing this out. While ordering is not explicitly contained within MITRE ATT&CK, there exist systematization efforts focused on composing MITRE ATT&CK into an ordered representation to reflect how an adversary can progress through an end-to-end cyberattack (i.e., a kill-chain). These efforts use the requirements and information generated by each MITRE ATT&CK technique to represent which techniques are able to be completed with the goal of modeling end-to-end cyberattacks. We used [2] to create the ordering of different TTPs in our STT, however, there are a number of other examples that are functionally equivalent (e.g., [3]). We will update Section 3.2 of the manuscript to discuss how the TTPs are ordered in the STT.

References:

[1] Deng, G., Liu, Y., Mayoral-Vilches, V., Liu, P., Li, Y., Xu, Y., ... & Rass, S. (2023). Pentestgpt: An llm-empowered automatic penetration testing tool. arXiv preprint arXiv:2308.06782.

[2] Goohs, J., Dykstra, J., Melaragno, A., & Casey, W. (2024, October). A Game Theory for Resource-Constrained Tactical Cyber Operations. In MILCOM 2024-2024 IEEE Military Communications Conference (MILCOM) (pp. 1052-1057). IEEE.

[3] Sadlek, L., Čeleda, P., & Tovarňák, D. (2022, April). Identification of attack paths using kill chain and attack graphs. In NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium (pp. 1-6). IEEE.