Source-linked AI summary

Automated Post-Exploitation Attack Chain Exploration Based on a Phase-guided Hybrid Planning-Monte Carlo Tree Search Algorithm

Jie Ying, Mengce Zheng, Ruoxi Chen, Wenrui Cheng, Tiantian Zhu, Zhongjie Zhu

arXiv:2610.32278v1cs.CRcs.CY

TL;DR

Manual discovery of post-exploitation attack chains in complex hosts is difficult, and existing approaches face modeling, efficiency, and solution-flexibility challenges. APEX models host information and attack actions for planning and uses a phase-guided hybrid Planning-MCTS algorithm to explore chains. It rediscovers known chains and identifies 9 previously unreported privilege escalation vectors in cloud environments.

  • Problem

    Existing host-modeling and planning approaches face imprecision, computational inefficiency, and limited alternative solutions when a primary chain cannot be implemented.

    Source: §I · p. 2
  • Method

    APEX models host objects, facts, and actions, gathers host information, and combines phase-guided planning with MCTS to explore attack chains.

    Source: §I · p. 2
  • Results

    APEX rediscovers known attack chains and identifies 9 previously unreported privilege escalation vectors in real-world cloud environments.

    Source: §X · p. 12
  • Takeaways & Limitations

    The distinct attack paths provide defenders with threat intelligence for proactively hardening complex production systems.

    Source: §X · p. 12

    The domain model excludes advanced techniques such as kernel-level exploits, race conditions, and hardware-based attacks.

    Source: B. Limitations and Future Work · p. 10

Abstract

from arXiv · show

Advanced attackers in post-exploitation scenarios increasingly craft attack chains that combine benign operations, configuration errors, and vulnerability exploitation to achieve objectives like privilege escalation. While such chains pose significant threats, manually discovering them in complex modern host environments is prohibitively labor-intensive. Automating this discovery is therefore essential for proactive defense, yet existing methods still suffer from inefficiency and lack diversity when exploring these attack chains. To address these limitations, we present APEX, an Automated Post-EXploitation attack chain exploration system. This system transforms attack chain discovery into a planning problem and solves it with a novel phase-guided hybrid Planning-Monte Carlo Tree Search (MCTS) algorithm. By organizing attack actions into semantic phases and integrating symbolic planning with MCTS, APEX enables efficient exploration of the state space while generating multiple diverse chains. Evaluations on a benchmark comprising 5 virtual machines, 30 synthetic problems and 291 cloud instances demonstrate that APEX successfully discovers both known and previously unreported attack chains--including 9 novel privilege escalation vectors--providing actionable intelligence for hardening complex production environments.

I. INTRODUCTION

Post-exploitation chains combine benign operations and malicious actions to pursue goals such as privilege escalation, but finding them manually in complex hosts is difficult. APEX models host conditions and attack actions for planning, then uses a phase-guided hybrid planner to explore chains and report remediation suggestions.

A. Post-Exploitation in Cyber Attacks

  • Post-exploitation begins after limited-privilege access and can involve multi-step chains toward objectives such as privilege escalation and lateral movement.The paper argues that chain intelligence can help defenders rectify misconfigurations and deploy patches.Source: §I · p. 1

I. INTRODUCTION

  • APEX proposes a phase-guided hybrid Planning-MCTS algorithm, combining AI planning efficiency with MCTS flexibility for attack-chain exploration.The system uses the host characterization and a specified objective to search for multiple feasible action chains.Source: §I · p. 2
  • The evaluation reports 9 unreported attack chains after testing known vulnerabilities on 5 virtual machines, 30 synthetic problems, and 291 live cloud instances.The passage describing 291 instances is split across two passages.Source: §I · p. 2

B. AI Planning

  • AI planning represents attack-chain discovery as searching for valid action sequences that transform an initial compromised-host state into a goal state.The paper uses PDDL to describe system objects, facts, actions, host state, and attacker goals.Source: B. AI Planning · p. 2

C. Monte Carlo Tree Search

APEX targets complex, stateful post-exploitation chains from an initial shell on a Unix system, where manual discovery is difficult. Its architecture separates reusable domain knowledge from host-specific collection and planning, while phase-guided hybrid search aims to find diverse, feasible chains efficiently.

C. Monte Carlo Tree Search

  • Hybridizing MCTS with a planner uses phase-based heuristics to guide action selection and dynamically generate feasible actions, reducing enumeration overhead.The paper reports that enumeration accounts for approximately 91% of runtime in naive approaches.Source: C. Monte Carlo Tree Search · p. 2

A. Motivation

  • Manually tracing multi-vector chains through complex host attributes is difficult, and existing tools are often ill-suited to these stateful sequences.The threat model starts with shell access on a Unix host and excludes containerized environments.Source: A. Motivation · p. 3, B. Threat Model · p. 3

B. Threat Model

  • The threat model assumes initial shell access on a Unix host and focuses on feasible chains toward specified goals, including privilege escalation, tampering, exfiltration, or lateral movement.Attackers may use existing utilities and introduce external tools if a method is found, but do not initially possess other users' credentials.Source: B. Threat Model · p. 3

A. The APEX Architecture

  • APEX separates reusable static components from a dynamic layer that collects host information, parses a host-specific PDDL problem, and solves for chains and reports.The architecture describes the dynamic layer as adapting the instantiated problem to each target.Source: A. The APEX Architecture · p. 3

B. Core Design Principles

  • APEX's design principles combine formal PDDL abstraction, phase-guided search, hybrid solving, and read-only operations.The principles are intended to balance feasibility and diversity while keeping assessment passive.Source: B. Core Design Principles · p. 3

V. SYSTEM DESIGN AND MODELING

APEX uses a compact formal model to represent the host entities, relationships, and actions needed for post-exploitation planning. Its PDDL domain describes system state and transitions while aiming to preserve realistic attack-chain reasoning without making planning intractable.

A. Modeling Philosophy and Scope

  • The modeling approach seeks a minimal sufficient representation: modeling every system detail risks state-space explosion, while oversimplification can miss realistic attack-chain interactions.The model is intended to include only entities and relationships necessary for achieving objectives through benign and malicious action chains.Source: A. Modeling Philosophy and Scope · p. 3
  • The model covers seven attack surfaces, including file permissions, process execution, automated execution, dependencies, vulnerabilities, user/group relationships, and data movement.The paper characterizes these surfaces as a minimal but sufficient basis for post-exploitation reasoning.Source: A. Modeling Philosophy and Scope · p. 4

B. PDDL Domain Definition

  • The model for post-exploitation scenarios uses 9 object types representing core entities, 30 predicates capturing system state, and 19 actions modeling state transitions.Three derived capability predicates compute effective permissions from base predicates, avoiding storage of a quadratic number of user-file permission facts in the initial state.Source: B. PDDL Domain Definition · p. 4
  • The action set is designed to model complex multi-step attacks while maintaining the minimalism needed for efficient planning.Actions have preconditions and effects intended to represent distinct capabilities and security-relevant dependencies.Source: B. PDDL Domain Definition · p. 4

C. Automation Script for Host State Extraction

APEX collects host state through passive, read-only reconnaissance and uses a phase-guided search to organize attack actions by their roles and dependencies. The phases constrain action selection to coherent progressions from capability discovery through privilege changes and dependent operations toward a goal.

C. Automation Script for Host State Extraction

  • Host-state extraction uses read-only commands to build a security-relevant snapshot without altering the host.The five extraction categories cover identity and privilege context, filesystem state, system dynamics, software vulnerability context, and capability-derivation primitives.Source: C. Automation Script for Host State… · p. 4

VI. THE PHASE-GUIDED HYBRID PLANNING-MCTS ALGORITHM

A. Phase Guidance: Modeling Attack Action Semantics

  • Phase guidance organizes actions into capability derivation, privilege manipulation, effect-dependent, and goal-directed phases, pruning implausible paths and structuring attack exploration.Capability derivation infers system properties without changing state; effect-dependent actions are selected dynamically from the preceding privilege action’s effects.Source: §VI · p. 5, A. Phase Guidance: Modeling Attack… · pp. 5–6
  • The effect-dependent phase selects actions whose preconditions intersect the effects of the preceding privilege-manipulation action.This dynamically includes operations that use newly established capabilities, such as writing a file made writable by a permission change.Source: A. Phase Guidance: Modeling Attack… · pp. 5–6
  • Phase transitions cycle through privilege manipulation, effect-dependent actions, and goal-directed actions, allowing new conditions to feed later system manipulation.Capability derivation initializes the search; an example progression moves from inferring executable capabilities to permission changes, payload writing, and elevated access.Source: A. Phase Guidance: Modeling Attack… · pp. 5–6, C. Automation Script for Host State… · p. 5
  • Semantic pruning limits each node to phase-relevant actions and enforces logical ordering and causal dependencies between phases.The phase system reflects the logical dependencies between operation types, so effect-dependent actions cannot precede the privilege changes that enable them.Source: A. Phase Guidance: Modeling Attack… · pp. 5–6

B. Hybrid Architecture: Synergizing Planning and MCTS

PG-HP-MCTS combines phase-specific planning with MCTS: the planner enumerates valid actions, while MCTS directs exploration and evaluates phase sequences. This division uses semantic and logical pruning to reduce search while retaining multiple-path exploration.

B. Hybrid Architecture: Synergizing Planning and MCTS

  • The hybrid architecture combines planning’s sound action enumeration with MCTS’s anytime search and ability to discover multiple diverse solutions.The planner checks preconditions and parameter bindings; MCTS uses UCT selection and simulations to guide high-level exploration.Source: B. Hybrid Architecture: Synergizing… · p. 6
  • At each node, the system builds a temporary planning problem containing only action schemas appropriate to the current phase and state.A modified planner enumerates all grounded actions with satisfied preconditions without searching for a complete plan.Source: B. Hybrid Architecture: Synergizing… · p. 6
  • Phase guidance and planner filtering provide dual pruning, with temporary action sets averaging 23% of the full domain and branch factor reduced by 70%.Phase guidance restricts action schemas; the planner filters those to logically applicable instantiations.Source: B. Hybrid Architecture: Synergizing… · p. 6, C. Algorithm Execution and Innovation… · p. 7

C. Algorithm Execution and Innovation Impact

  • The algorithm maintains phase constraints during random rollouts and uses rewards from multi-step simulations to evaluate explored phase sequences.Initialization first enriches the state with inferred capability facts before the main search begins.Source: C. Algorithm Execution and Innovation… · pp. 6–7
  • Phase restrictions transform exploration from all action sequences to sequences formed from smaller phase-specific action sets.The phase system reduces the number of action choices by an average of 74% per phase, making deeper exploration computationally feasible where brute force would be intractable.Source: C. Algorithm Execution and Innovation… · p. 7
  • The integration targets computational inefficiency through dual pruning and hybrid search, and solution inflexibility through MCTS’s multi-path exploration and anytime performance.Its stated division of labor combines planning completeness with stochastic-search flexibility.Source: C. Algorithm Execution and Innovation… · p. 7

D. Post-Processing and Report Generation

APEX filters capability-derivation actions from discovered chains and uses an LLM to produce analyst-facing walkthroughs and mitigation suggestions. Its evaluation setup includes known-chain virtual machines, synthetic planning problems, and cloud instances, with planner, MCTS, and ChainReactor baselines.

D. Post-Processing and Report Generation

  • APEX post-processes discovered chains by filtering derivation actions and using an LLM to generate step-by-step reports with mitigation recommendations.This bridges formal planning output and security guidance for analysts.Source: D. Post-Processing and Report Generation · p. 7

VII. EVALUATION

  • The evaluation is organized around effectiveness, efficiency, solution quality and diversity, and practicality research questions.The questions ask whether APEX discovers known and unknown chains, outperforms planner and MCTS baselines, generates multiple concise and diverse chains, and finds unreported chains in cloud environments.Source: §VII · p. 7

A. Experimental Setup

  • The benchmark includes five CTF virtual machines with documented multi-step privilege-escalation chains as ground truth.The chains combine misconfigurations, SUID binaries, and scheduled tasks.Source: A. Experimental Setup · p. 8
  • Thirty synthetic planning problems vary object counts from 500 to 3,000 while maintaining three to four predicates per object, each with a solvable privilege-escalation path.These problems are used to evaluate scalability under controlled complexity.Source: A. Experimental Setup · p. 8
  • The cloud dataset contains 291 instances across Amazon EC2 and Alibaba Cloud ECS, launched with default configurations and accessed as a low-privileged user with root privilege as the goal.The comparison baselines are Powerlifted configured for satisficing planning, pure MCTS, and a reproduced ChainReactor pipeline.Source: A. Experimental Setup · p. 8

B. Evaluation on Benchmark Environments

Across CTF, synthetic, and cloud evaluations, APEX found validated privilege-escalation chains, including previously unreported chains in production cloud instances. The results also report multiple alternatives per target and higher synthetic-problem success than the planner and pure-MCTS baselines.

B. Evaluation on Benchmark Environments

  • APEX found valid privilege-escalation chains on all five CTF virtual machines, a 100% success rate, with an average time to first solution of 870.6 seconds.It averaged 2.4 distinct chains per VM, and all discovered chains were manually validated as operationally feasible.Source: B. Evaluation on Benchmark Environments · p. 8, Table I · p. 9
  • Across 30 synthetic problems, APEX solved 28 (93%), versus 17 (57%) for the pure optimal planner and 2 (7%) for pure MCTS; at 3,000 objects, APEX achieved 60% success while both competitors failed.Phase-guided PG-HP-MCTS had an average behavioral enumeration count of 219, compared with 952 without phase guidance.Source: B. Evaluation on Benchmark Environments · p. 8

C. Large-Scale Real-World Evaluation

  • Cloud-instance information collection averaged 3.1 minutes per instance, with a maximum of 5.5 minutes.The evaluation covered 175 Amazon EC2 and 116 Alibaba Cloud ECS instances.Source: C. Large-Scale Real-World Evaluation · p. 9
  • APEX found 9 previously unreported attack chains in production cloud environments and privilege-escalation chains in 27 instances; per-instance total analysis averaged approximately 19.4 minutes, over 47.6% below ChainReactor’s reported 37-minute average.The 27 instances comprised 19 EC2 instances (10.9%) and 8 ECS instances (6.9%); all discovered chains involved either pure configuration errors or hybrid chains combining vulnerabilities with misconfigurations.Source: C. Large-Scale Real-World Evaluation · pp. 9–10
  • Vulnerable cloud instances yielded an average of 2.1 distinct attack paths, with 2.3 chains per EC2 instance and 1.8 per ECS instance.Case studies include chains involving Docker-group access and a writable service file, SUID misuse and a cron script, and environment-variable injection through a writable profile script.Source: C. Large-Scale Real-World Evaluation · pp. 9–10
  • On a randomly selected 50-instance subset, APEX identified potential attack chains on 6 instances versus ChainReactor’s 2 and found 14 chains, seven times as many, with an average solution time of 14.4 minutes.The reported solution time was 42.6% lower than ChainReactor’s.Source: C. Large-Scale Real-World Evaluation · p. 10, Table III · p. 10

VIII. DISCUSSION & LIMITATION

APEX’s hybrid search finds multiple feasible chains, giving defenders a broader view of attack paths and potential shared mitigations. Its current scope and modeling impose limits on coverage, vulnerability updates, stealth, execution validation, and dynamic environments.

A. Discussion

  • APEX balances computational efficiency with solution diversity, finding multiple feasible chains within operationally relevant timeframes rather than stopping at one solution.The diverse chains can reveal interacting vulnerability classes and shared weaknesses, such as a writable service file, that defenders can prioritize for mitigation.Source: A. Discussion · p. 10
  • Diverse chains can reveal interacting vulnerability classes and shared weaknesses, helping defenders prioritize fixes that break attack surfaces rather than isolated vulnerabilities.The authors frame this as a shift from reactive patching toward proactive attack-surface reduction.Source: A. Discussion · p. 10
  • The framework is instantiated for Unix post-exploitation, but its domain modeling and phase-guided search can be adapted to other multi-step security domains.The authors name cloud misconfiguration analysis and software supply-chain attack exploration as examples; adaptation requires a new domain model and phase-guided hybrid MCTS design.Source: A. Discussion · p. 10

B. Limitations and Future Work

  • The current domain model abstracts prevalent attack vectors and excludes advanced techniques such as kernel-level exploits, race conditions, and hardware-based attacks.The authors propose a modular extension framework to incorporate new patterns.Source: B. Limitations and Future Work · p. 10
  • Vulnerability capability modeling requires manual CVE curation, a labor-intensive process the authors say cannot scale to the continuous stream of new vulnerabilities.They propose investigating LLM-based extraction from CVE descriptions, exploit proofs-of-concept, and advisories.Source: B. Limitations and Future Work · p. 10
  • APEX optimizes logical feasibility rather than stealth, so generated chains may trigger alerts in monitored environments.The authors propose detection-awareness based on EDR signatures or logging patterns as future work.Source: B. Limitations and Future Work · p. 10
  • APEX generates chains but does not execute them to validate operational feasibility or collect runtime data.The authors propose safe, controlled execution in isolated environments with comprehensive event logging.Source: B. Limitations and Future Work · pp. 10–11
  • APEX assumes static host configurations and does not model interactive defender responses.The authors identify adaptive planning in dynamic environments as a future direction.Source: B. Limitations and Future Work · p. 11

IX. RELATED WORK

APEX targets post-exploitation chain discovery, where host-specific state and interacting weaknesses must be modeled beyond initial-access tools or individual-vulnerability analysis. It combines phase guidance with planning and MCTS, and the evaluation reports known-chain rediscovery and nine previously unreported privilege-escalation vectors in cloud environments.

A. Automated Penetration Testing and Post-Exploitation Analysis

  • Pre-exploitation tools and individual-vulnerability methods focus on initial compromise or isolated flaws, while APEX models post-exploitation host-state transitions and how independent weaknesses combine into chains.The paper emphasizes permissions, file dependencies, and capability propagation as key elements of host-level reasoning.Source: A. Automated Penetration Testing and… · p. 11

B. Formal Modeling and Planning for Attack Simulation

  • Prior formal approaches include attack graphs, Petri nets, logical frameworks, and game-theoretic models; AI planning has also been applied to network penetration testing and smart-grid security.Existing host-level planning approaches often stop after one feasible solution, whereas APEX integrates MCTS to explore multiple diverse chains while retaining classical planning’s formal correctness guarantees.Source: B. Formal Modeling and Planning for… · p. 11

C. Search Algorithms and System-Specific Security Analysis

  • APEX combines planning and MCTS for concrete, constrained post-exploitation hosts, where system components and their interactions matter more than abstract network states.MCTS offers exploration and exploitation through randomized simulations, while pure MCTS lacks formal reasoning for complex security operations.Source: C. Search Algorithms and… · p. 11

D. Positioning of Our Work

  • Prior privilege-escalation research catalogs mechanisms across platforms but offers limited methodology for automatically discovering how mechanisms chain together.Compared with CHAINREACTOR, APEX adds semantic phase guidance, MCTS-based multi-chain exploration, finer-grained host-state and capability modeling, and reported discovery of previously unreported cloud chains.Source: C. Search Algorithms and… · p. 11, D. Positioning of Our Work · pp. 11–12

X. CONCLUSION

  • APEX rediscovers known attack chains and identifies 9 previously unreported privilege-escalation vectors in real-world cloud environments.Generating multiple distinct paths provides defenders threat intelligence for proactive hardening of production systems.Source: §X · p. 12

APPENDIX A EXTENDED DISCUSSION ON POST-EXPLOITATION AND

The appendix frames post-exploitation as a multi-step process in which host configuration and legitimate system operations can interact with vulnerabilities. It describes modeling this search in PDDL and combining phase guidance with symbolic planning and MCTS.

APPENDIX A EXTENDED DISCUSSION ON POST-EXPLOITATION AND

  • Post-exploitation chains can combine misconfigurations, vulnerable software, and legitimate utilities; complex interactions among permissions, services, and configurations create many potential escalation and persistence paths.The appendix notes that blending malicious actions with legitimate operations can make these chains difficult to detect through conventional mechanisms.Source: Appendix A · p. 14

A. Formal Planning Problem

  • A classical planning problem represents states, available actions, a transition function, an initial state, and goal states; a solution is an action sequence that reaches a goal.The appendix specifies these components as <S, A, γ, s0, SG>.Source: A. Formal Planning Problem · p. 14

B. PDDL Domain and Problem Specification

  • PDDL separates a domain’s objects, predicates, and actions from a problem’s concrete host objects, initial state, and attacker goal.APEX retrieves host information, including file systems, user-group relationships, and executable properties, to generate the problem file; actions specify parameters, preconditions, and effects.Source: B. PDDL Domain and Problem Specification · p. 14

APPENDIX C EXTENDED MOTIVATION EXAMPLE

  • The Linux example chains low-privilege enumeration, a gzip arbitrary-file-write vulnerability, modification of a root-run backup script, and its scheduled execution to obtain a root shell.The example highlights the interaction of a software vulnerability, a misconfigured privileged task, and benign system execution.Source: Appendix C · pp. 14–15

A. Formal Abstraction Principle

  • The authors use a minimal set of PDDL constructs to represent post-exploitation mechanics in a way they describe as logically sound, reproducible, and unambiguous.This is their stated formal abstraction principle.Source: A. Formal Abstraction Principle · p. 15

B. Phase-Guided Search Principle

  • Phase-specific constraints and heuristics prune irrelevant branches early and focus exploration on promising avenues, improving computational efficiency.The authors base this search guidance on semantically meaningful phases in post-exploitation actions.Source: B. Phase-Guided Search Principle · p. 15

C. Hybrid Solving Principle

  • APEX uses planners for well-defined subproblems within phases and MCTS for high-level strategy management, combining constraint-satisfaction rigor with search over large state spaces.The authors characterize this as a combination of symbolic planning and probabilistic search.Source: C. Hybrid Solving Principle · p. 15

D. Minimal Interference Principle

APEX’s information collection is read-only, and its host model represents core Unix attack surfaces through predicates and actions. The model omits several lower-level details, focusing instead on logical dependencies among permissions, user contexts, and automated execution.

D. Minimal Interference Principle

  • During information collection, APEX forbids file changes, service or process manipulation, and configuration changes, aiming for passive assessment safe for production environments.The authors describe these as strict read-only mandates.Source: D. Minimal Interference Principle · p. 15

A. Attack Surface Details

  • The modeled attack surfaces include file permissions, process execution and privilege inheritance, scheduled tasks, dependencies, vulnerabilities, and user-group relationships.These represent paths involving access control, execution context, automated execution, loaded files, CVEs, and group-based privileges.Source: A. Attack Surface Details · p. 15

B. Omitted Aspects

  • The model omits exploitation-process details, network-stack states, memory layouts, kernel internals, and fine-grained process scheduling.The authors state these are unnecessary for reasoning about logical chains involving file permissions, user contexts, and automated execution.Source: B. Omitted Aspects · p. 15

APPENDIX F PDDL DOMAIN DETAILS

  • The PDDL domain defines 30 predicates for executable capabilities, privilege and control, file-system state, process execution, and derived capabilities.Capability predicates abstract executable effects, including vulnerability-based operations that bypass normal permission checks.Source: Appendix F · pp. 15–16
  • The domain contains 19 state-transition actions, including file manipulation, configuration changes, permission derivation, capability propagation, and process execution.Examples include scheduled-execution hijacking and launching a SUID process to obtain a process running as the binary’s owner.Source: Appendix F · p. 16

APPENDIX G SCRIPT IMPLEMENTATION DETAILS

The scripts collect host identity, file, execution, and vulnerability facts to construct planner state, while deriving access capabilities without storing a quadratic number of permission facts. The appendix also shows how a PDDL chain is rendered as a report and gives a Docker-group-to-root example.

APPENDIX G SCRIPT IMPLEMENTATION DETAILS

  • Identity and file-system collection records users, groups, memberships, execution context, file types, permissions, ownership, and SUID/SGID flags.These facts instantiate predicates such as attacker_control, user_in_group, user_has_file_perm, and has_suid_flag.Source: Appendix G · p. 16
  • The scripts model scheduled jobs, services, library and shell startup dependencies, known vulnerable executable versions, and writable files used to derive access capabilities.Planner axiom actions compute user_has_access_read/write/exec, avoiding storage of a quadratic number of permission facts.Source: Appendix G · pp. 16–17

APPENDIX H REPORT GENERATION DETAILS

  • APEX’s report-generation prompt converts filtered formal PDDL attack chains into actionable natural-language reports.The example prompt asks for a natural-language walkthrough and defensive recommendations.Source: Appendix H · p. 17

A. Input: PDDL Attack Chain Example (Docker Group Esca-

  • The example chain uses the default EC2 user’s Docker-group access to modify a systemd timer, which then grants a root shell.The PDDL sequence launches Docker, writes a payload to the timer, and spawns a shell with root control.Source: A. Input: PDDL Attack Chain Example… · p. 17

B. LLM Prompt Template

The prompt asks an LLM to translate a PDDL attack chain into a stepwise walkthrough, actionable mitigations, and chain metadata. The example output describes a Docker-to-root path and supplies concrete defenses and risk details.

B. LLM Prompt Template

  • The prompt requires each PDDL action to be translated into a natural-language attack walkthrough.The input slot is “[insert PDDL sequence here].”Source: B. LLM Prompt Template · p. 17
  • The prompt requests specific, actionable mitigations, including concrete commands or configuration changes.The example output recommends securing the systemd timer, restricting Docker-group membership, and auditing systemd file modifications.Source: B. LLM Prompt Template · p. 17, C. Output: Generated Natural Language… · p. 17
  • The requested report metadata includes step count, attacker skill level, and overall risk assessment.The prompt specifies these fields in addition to the walkthrough and mitigation recommendations.Source: B. LLM Prompt Template · p. 17

C. Output: Generated Natural Language Report

  • The example walkthrough describes a Docker-group user modifying a systemd timer so its scheduled execution grants a root shell.It frames the chain as using Docker’s host-filesystem mounting capability to alter the timer while retaining root execution context.Source: C. Output: Generated Natural Language… · p. 17
  • The example recommends systemd timer ownership and permission changes, Docker-group restrictions, file-modification auditing, and Docker daemon hardening.The daemon configuration shown includes authorization plugins, user namespace remapping, and no-new-privileges.Source: C. Output: Generated Natural Language… · p. 17
  • The example labels the chain’s required skill as intermediate, its risk as critical, and its impact as complete system compromise.Its risk description identifies a direct path from the default user to root.Source: C. Output: Generated Natural Language… · p. 17
Loading 2610.32278v1…