A Real Automated Pentesting Attack Path: 2026 Case Study

Sıla Özeren Hacıoğlu | 8 MIN READ

LAST UPDATED ON JULY 23, 2026

What Does a Real Automated Pentest Attack Path Look Like?

A real automated pentest attack path looks like a step-by-step chain from a single foothold to a high-value objective, with every step executed and proven. In this automated pentest, it runs from a low-privilege HR user to Domain Admin on a database server in 32 minutes: 12 steps, 3 machines, 5 captured credentials, and 3 choke points that each could have stopped it.

Nothing here is theoretical. Every action was executed against the live environment and confirmed by successful exploitation. The point of walking it through is not to celebrate the compromise, it is to show precisely where the chain could have been broken, and which single mitigations would have closed it down.

The starting condition is assume-breach: the tool is placed on HR01 as the user hruser, a standard low-privilege domain account. This represents the patient-zero state after a phished employee, a stolen credential, or a compromised endpoint. The question the run answers is not can the attacker get in? It is now that they're in, how far can they get?

How Does an Automated Pentest Go from an HR Workstation to Domain Admin in 32 Minutes?

In this example, an automated pentest reaches Domain Admin from a single low-privilege HR user in 32 minutes by repeating one loop: escalate privilege, dump credentials, switch identity, then pivot to the next host. Here it runs from HR01 to IT01 to the DB02 database server, across twelve steps and three machines. The specific path is one real run. The loop is what generalizes.

Steps 1 and 2: Discovery Before Anything Else Happens

The first work the automated pentesting tool does is enumeration.

Step 1. Active Directory enumeration from HR01 as hruser surfaces 3 workstations and 4 users. This is the graph the rest of the chain is built on: without knowing which machines exist and who uses them, none of the later decisions are possible.

3 Workstations

HR01, DB02, IT01

4 Active Directory Users

APVDEMO.LOCAL\hruser
APVDEMO.LOCAL\agent
APVDEMO.LOCAL\ituser
APVDEMO.LOCAL\admin (Domain Admin)

Step 2. Service enumeration on HR01 surfaces 1 vulnerable service running locally.

Vulnerable Service

SVC SCCM SQL

Neither step exploits anything. They are both Discovery, and Discovery will keep running throughout the engagement. Every time the tool reaches a new host or operates under a new identity, it enumerates again from the new position.

Step 3: Local Privilege Escalation via Modifiable Service

Severity: High. Context: hruser on HR01 escalates to SYSTEM.

The vulnerable service Discovery found in Step 2 is a classic Windows misconfiguration: a service whose binary path or configuration can be modified by a non-privileged user. The tool exploits it via Modifiable Service Exploitation, redirecting the service to execute code of its choice. When the service runs, the code runs with SYSTEM privileges.

The user context of the running implant changes from hruser to SYSTEM. The automated penetration testing tool is now operating at the highest privilege level available on the local machine.

Step 4: Credential Harvest via LSASS Dumping

Severity: Critical. Context: SYSTEM on HR01.

With SYSTEM privileges, the tool dumps the memory of the LSASS process. LSASS holds the cached credentials of every user who has authenticated to the host since the last reboot. The dump yields 2 credentials.

This is where the compromise stops being about one workstation. The captured credentials are the keys to other machines.

Step 5: User Context Switch to agent

The tool switches the implant's active identity to one of the captured users, agent. The implant is still running on HR01, but it is now operating as if the agent user had logged in. Any network action that follows will be authenticated as agent, not hruser and not SYSTEM.

Step 6: Admin Check Across Systems via SMB

Severity: Low. Highly mitigable.

Operating as agent, the tool runs a parallel administrator privilege check over SMB against reachable hosts. It discovers that agent has local administrator rights on at least one other machine in the environment. 1 credential is obtained in the process.

This is the first of three choke points flagged "Highly Mitigable" in the path. Removing agent from unnecessary local admin groups across the domain would break the chain here, preventing the pivot in Step 7 and everything downstream.

Step 7: Lateral Movement from HR01 to IT01

Severity: Critical. Context: agent pivots from HR01 to IT01.

The tool uses the administrator access discovered in Step 6 to execute code on IT01 via SMB. A new implant session is created on IT01 running as administrator. The chain has officially left the HR subnet.

Step 8: LSASS Dumping on IT01

Severity: Critical. Context: SYSTEM on IT01.

Same technique, new host. The tool dumps LSASS on IT01 and captures 1 additional credential, this time belonging to ituser. Every new host visited is a new opportunity to harvest whichever privileged users have logged in recently.

Step 9: User Context Switch to ituser

Highly mitigable.

The implant switches identity again, this time to ituser. ituser has broader access than agent, including reach into the database tier of the environment.

Step 10: LAPS Password Dumping

Severity: Critical. Highly mitigable.

Operating as ituser, the tool performs Local Administrator Password Solution (LAPS) password dumping. LAPS stores randomized local admin passwords in Active Directory, and LAPS entries are protected by AD permissions. If ituser has read access to LAPS passwords they should not be able to read, the tool retrieves them.

1 credential is dumped: the local admin password for DB02, a database server.

This is the third Highly Mitigable choke point. Correcting LAPS read permissions so only genuinely authorized users can retrieve local admin passwords would stop the next pivot dead.

Step 11: Lateral Movement to DB02 → Domain Admin Acquired

Severity: Critical. Context: ituser pivots from IT01 to DB02 as administrator.

Using the LAPS-derived local admin password for DB02, the tool executes code on the database server via SMB. A new implant session is created on DB02 running as administrator.

Domain Admin privileges are acquired at this step. The path has reached its objective.

Step 12: Final LSASS Dump on DB02

Severity: Critical. Context: SYSTEM on DB02.

The tool dumps LSASS one more time for additional credential material. At this point, the chain is complete: the attacker has Domain Admin and persistent ability to authenticate across the environment.

Where Could This Attack Kill Chain Have Been Broken?

This attack kill chain could have been broken at three choke points: Steps 6, 9, and 10. Each was a single configuration change, and applying any one of them alone would have stopped the chain before Domain Admin.

These are the three steps flagged "Highly Mitigable," the ones a remediation team cares about most:

Step 6 (choke point). agent should not have had local admin on machines outside its role. Removing unnecessary local admin membership would have stopped the pivot to IT01 and eliminated Steps 7 through 12 entirely.
Step 9 (choke point). Tightening which users are reachable as login targets from compromised workstations would have prevented the context switch to ituser, stopping Steps 10 through 12.
Step 10 (choke point). Correcting LAPS permissions so ituser could not read DB02's local admin password would have prevented the final pivot and the Domain Admin compromise.

That is what a validated attack path gives a defender: not a list of 12 separate problems to fix, but a prioritized view of the few changes that collapse the whole chain.

What Does This Attack Path Prove That a Vulnerability Scanner Can't?

The individual findings in this path would barely register on a vulnerability scanner. A modifiable service misconfiguration, a local admin group with one extra member, a LAPS permission that is slightly too broad, none of them carry a CVSS 9 on their own. A scanner would either miss them or rank them Medium at best. But chained together, starting from a single phished employee, they produce a validated route from an HR workstation to a database server with Domain Admin privileges in 32 minutes.

This is the argument for attack-path-based validation in one example. Individual weaknesses are data points. The path is the story. Fixing three choke points is more valuable than fixing 50 scanner findings, because the three choke points are the ones an attacker would actually have used.

How Would This Attack Path Differ with Autonomous Penetration Testing?

The chain above was produced by automated penetration testing, which follows a rule-based engine: at each step it picked the next technique from a predefined decision tree. Autonomous penetration testing reaches the same objective differently. It self-scopes from a signal and reasons about each move in real time, adapting or writing a custom exploit when a step does not fit its rules, instead of stopping at their edge.

Same artifact, different decision-making:

What stays the same. Both build a validated, end-to-end chain to Domain Admin and surface the choke points that hold it together. The 12-step route above is exactly the kind of path either approach produces.
What changes. Automated runs are operator-scoped and chain along encoded rules. An autonomous run self-scopes from a signal like a new CVE or threat report, re-enumerates from every new foothold, and improvises when the playbook runs out.
Why it matters here. A misconfiguration or identity weakness the rulebook never anticipated can stop an automated chain at the edge of its rules. An autonomous run reasons past that point, so it can surface paths an automated baseline misses.

Enter Picus Autonomous Penetration Testing

You just read one validated chain. Picus Autonomous Penetration Testing produces them continuously, against your live environment. Specialist agents reason through each step, and when one is blocked they reroute or write a custom exploit instead of stopping at the edge of a rulebook. The output is what you saw above: a real route to crown jewels like Domain Admin, with the few choke points that collapse the whole chain pinpointed to fix.

It layers on your automated baseline, no rip-and-replace, turning each new signal into a run that feeds one prioritized queue ranked by reachable paths and choke points, not raw CVSS. Every action is auditable, with control from full oversight to full autonomy.

See it run a live attack path in your own environment. Request your free demo.

Wall-clock time depends on environment size, scope, and how fast the chain reaches its objective. The walkthrough above completed a full chain from a low-privilege HR workstation to Domain Admin in 32 minutes, across three machines and twelve steps. Shorter chains in smaller environments can complete in under ten minutes; complex enterprise runs spanning multiple subnets can take hours, especially when lateral movement requires harvesting credentials across many hosts before a usable identity is recovered.

A "highly mitigable" finding is a step in the chain that could have been prevented by a single, well-bounded configuration change rather than a complex remediation effort. In the walkthrough above, three steps were flagged highly mitigable: an unnecessary local admin group membership, an over-broad user reachability configuration, and an LAPS read permission that was scoped too widely. Highly mitigable findings are the highest-leverage remediation targets because each one closes off everything downstream that depended on it.

A choke point is a single weakness that multiple attack paths depend on. Because many paths pass through it, mitigating one choke point can close dozens of downstream paths at once. In the walkthrough, the local admin membership of the agent user functioned as a choke point: removing that one configuration would have eliminated Steps 7 through 12 of the chain. Choke points are where defenders get the highest remediation return per fix.

Most of the weaknesses chained in this path are not CVEs. A modifiable service misconfiguration, an over-permissive local admin group, and an LAPS read permission that is scoped too widely are configuration and identity issues, not software vulnerabilities. Scanners that match against CVE databases either miss them entirely or rank them as Low or Medium severity in isolation. Their criticality only becomes visible when they are chained together into a route to Domain Admin, which is what an automated pentest demonstrates and a scanner cannot.

No. Patching addresses known software vulnerabilities, but the attack path in this walkthrough did not depend on a single unpatched CVE. It depended on identity misconfigurations, excessive privilege assignments, and credential exposure on hosts where privileged users had recently logged in. Even a fully patched environment is exposed to this class of chain if Active Directory permissions, local admin group membership, and LAPS access controls are not tightened. This is why exposure validation programs treat configuration and identity hygiene as first-class remediation priorities, not an afterthought to patch management.