Lab 18 Attack Path Analysis

Mission Overview

Welcome to Lab 18 — Attack Path Analysis.

Until now, most labs have examined security controls individually:

Host Discovery
      ↓
Ports & Services
      ↓
Enumeration
      ↓
Vulnerabilities
      ↓
Authentication
      ↓
Host Security
      ↓
Web Security
      ↓
Privileges
      ↓
Network Segmentation

Real enterprise risk, however, rarely exists as a single isolated weakness.

A low-severity issue on one system may appear unimportant by itself. But when combined with another exposure, an overly privileged identity, and unnecessary network connectivity, it may create a path toward a critical asset.

For example:

External/User Access
        │
        ▼
Web Application
        │
        ▼
Weak Authentication Control
        │
        ▼
Application Account
        │
        ▼
Excessive Privilege
        │
        ▼
Database Connectivity
        │
        ▼
Sensitive Data

The individual observations tell only part of the story.

The attack path tells you how they relate.

Mission Goal: Correlate evidence from previous labs to identify plausible attack paths through the authorized training environment, determine which security controls enable or interrupt those paths, assess potential business impact, and produce a prioritized Attack Path Register—without exploiting the identified paths.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	90–120 minutes
Primary Skill	Attack Path Analysis
Secondary Skill	Security Risk Correlation
Environment	Isolated GoHackersCloud Lab
Testing Type	Evidence-Based Analysis
Primary Tools	Existing lab evidence, diagrams, spreadsheets/notes
Primary Outcome	Attack Path Register
Validation Style	Non-destructive / Evidence-based
Safety Level	Authorized Lab Only

Learning Objectives

By completing this lab, you will be able to:

• explain what an attack path is

• distinguish vulnerabilities from attack paths

• identify entry points

• identify critical assets

• identify trust boundaries

• correlate vulnerabilities with identities

• correlate identities with privileges

• correlate privileges with resources

• correlate network connectivity with security exposure

• identify attack-path prerequisites

• identify attack-path blockers

• distinguish confirmed facts from assumptions

• create attack-path diagrams

• assess attack-path feasibility

• assess potential business impact

• identify security control choke points

• prioritize attack paths

• recommend path-breaking remediation

• document residual risk

• communicate attack paths to technical and business stakeholders

Attack Path Methodology

Use:

Entry Point → Exposure → Identity → Privilege → Connectivity → Sensitive Asset → Business Impact

A more detailed model is:

Entry Point
    │
    ▼
Reachable Asset
    │
    ▼
Security Weakness
    │
    ▼
Identity / Access
    │
    ▼
Privilege
    │
    ▼
Trust Boundary
    │
    ▼
Reachable Next Asset
    │
    ▼
Critical Resource
    │
    ▼
Business Impact

The objective is not to execute this sequence.

The objective is to determine:

“Does existing evidence support the possibility of this path?”

Part 1 — Understand an Attack Path

Consider three isolated findings:

Finding A
Web application has weak authentication controls.

Finding B
Application account has excessive access.

Finding C
Application server can reach a sensitive database.

Viewed individually:

A        B        C

Attack-path analysis asks whether they connect:

Weak Authentication
        │
        ▼
Application Account
        │
        ▼
Excessive Access
        │
        ▼
Database Connectivity
        │
        ▼
Sensitive Data

This creates a much stronger risk story.

Part 2 — Vulnerability vs Attack Path

A vulnerability is generally:

A weakness in a system or control.

An attack path is:

A sequence of conditions, relationships, weaknesses, permissions, or connectivity that could allow progression toward a security objective.

Conceptually:

Vulnerability
     =
One Weakness

versus:

Attack Path
     =
Weakness
   + Identity
   + Privilege
   + Connectivity
   + Target

Not every vulnerability creates an attack path.

And not every attack path requires a traditional software vulnerability.

Part 3 — Rules of Engagement

This lab primarily uses evidence you already collected.

Permitted

• reviewing previous lab reports

• correlating existing findings

• mapping identities

• mapping privileges

• mapping network connectivity

• identifying reachable assets

• reviewing authentication relationships

• building attack-path hypotheses

• verifying configuration evidence

• performing minimal approved connectivity confirmation where required

• documenting potential impact

• recommending controls

Not Required

• exploitation

• privilege escalation

• credential attacks

• credential reuse testing

• password spraying

• session hijacking

• lateral movement

• pivoting

• tunneling

• persistence

• data extraction

• bypassing segmentation

• modifying security controls

A well-supported path does not need to be executed to be valuable.

Part 4 — Create the Workspace

Create:

Ethical-Hacking-Labs/
└── Lab-18/
    ├── Notes/
    ├── Evidence/
    │   ├── Assets/
    │   ├── Vulnerabilities/
    │   ├── Identity/
    │   ├── Privilege/
    │   ├── Network/
    │   └── Business-Impact/
    ├── Attack-Paths/
    ├── Diagrams/
    ├── Findings/
    └── Report/

Create:

Lab-18-Attack-Path-Journal.md

Suggested structure:

# Lab 18 — Attack Path Analysis

## Mission Objective

## Scope

## Assets

## Entry Points

## Vulnerabilities

## Identities

## Privileges

## Network Paths

## Trust Boundaries

## Critical Assets

## Attack Path Hypotheses

## Attack Path Validation

## Security Controls

## Choke Points

## Business Impact

## Attack Path Register

## Remediation

## Residual Risk

## Evidence

## Conclusion

Part 5 — Gather Evidence from Previous Labs

Start with evidence already produced.

Relevant labs include:

Previous Lab	Evidence
Lab 03	Hosts
Lab 04	Ports and services
Lab 05	Service configuration
Lab 06	Vulnerabilities
Lab 07	Authentication
Lab 08	Linux security
Lab 09	Windows security
Lab 10–13	Web security
Lab 14	Network traffic
Lab 15	DNS
Lab 16	Privileges
Lab 17	Segmentation

Attack-path analysis brings these together.

Part 6 — Build the Asset Register

Create:

Asset	Role	Zone	Exposure	Importance
User01	Workstation	User	Internal	Medium
Web01	Web server	Application	User-facing	High
DB01	Database	Database	Restricted	Critical
Admin01	Admin host	Management	Restricted	Critical

The importance column matters.

A path toward a static training web page is different from a path toward a sensitive database or identity-management system.

Part 7 — Identify Critical Assets

Ask:

What are we ultimately trying to protect?

Examples include:

• sensitive databases

• identity infrastructure

• administrative systems

• management consoles

• confidential files

• production applications

• backup systems

• security infrastructure

• cryptographic keys

• business-critical services

Mark them:

[CROWN JEWEL]
Database01

or:

[CRITICAL]
Identity Server

Part 8 — Understand Crown Jewels

A crown jewel is a resource whose compromise could have significant organizational impact.

Examples:

Customer Data

Identity Infrastructure

Financial Systems

Administrative Control Plane

Backups

Sensitive Intellectual Property

Attack-path prioritization should generally consider proximity to these assets.

Part 9 — Identify Entry Points

An entry point is where an attacker or untrusted user could potentially begin interacting with the environment.

Examples:

Web Application

User Workstation

Remote Access Service

VPN

Email

Public API

Cloud Application

Partner Connection

For your lab, use only entry points supported by your architecture.

Part 10 — Build the Entry Point Register

ID	Entry Point	Asset	Exposure	Authentication
EP-01	Web application	Web01	User-facing	Yes
EP-02	SSH	Linux01	Restricted	Yes
EP-03	RDP	Windows01	Management	Yes

Do not call an interface “internet exposed” unless that is actually true in your environment.

Part 11 — Identify Existing Weaknesses

Review your previous Vulnerability and Findings Registers.

Example:

Finding	Asset	Type	Confidence
Weak password policy	Web01	Authentication	Confirmed
Excessive sudo	Linux01	Privilege	Confirmed
Broad NTFS write	Win01	Permissions	Confirmed
User-to-DB access	Network	Segmentation	Confirmed

Do not invent weaknesses to make an interesting path.

Part 12 — Identify Identity Relationships

Create:

Identity
   │
   ▼
Authentication Method
   │
   ▼
System
   │
   ▼
Privilege

Example:

lab-user
   │
   ▼
Web Authentication
   │
   ▼
Application
   │
   ▼
Standard Role

Another:

lab-admin
    │
    ▼
SSH
    │
    ▼
Linux Server
    │
    ▼
sudo

Part 13 — Build the Identity Register

Identity	System	Role	Privilege	Evidence
lab-user	Web01	User	Standard	Lab 07
lab-admin	Linux01	Admin	Elevated	Lab 16
web-service	Linux01	Service	Restricted	Lab 16
DB-service	DB01	Service	Database	Configuration

Part 14 — Identify Privilege Relationships

Reuse Lab 16.

Example:

lab-user
    │
    ▼
Writable Application File
    │
    ▼
Privileged Service

or:

Standard User
     │
     ▼
Administrators Group

or:

Application Service
       │
       ▼
Sensitive Database Access

Record relationships without attempting to abuse them.

Part 15 — Identify Network Relationships

Reuse the communication matrix from Lab 17.

Example:

User → Web:443
ALLOW

User → DB:3306
BLOCK

Web → DB:3306
ALLOW

Management → Web:22
ALLOW

Network paths determine whether theoretical relationships are actually reachable.

Part 16 — Create the Relationship Graph

Combine assets and connections:

             User01
                │
             HTTPS
                │
                ▼
              Web01
                │
             DB/3306
                │
                ▼
               DB01

Then add security relationships:

             User01
                │
             HTTPS
                ▼
              Web01
                │
        Application Identity
                │
          Excessive Access
                │
             DB/3306
                ▼
               DB01

You now have the beginning of an attack-path graph.

Part 17 — Add Trust Boundaries

Mark security boundaries:

User Zone
    │
════╪════════════
    │
Application Zone
    │
════╪════════════
    │
Database Zone

An attack path crossing multiple trust boundaries deserves careful review.

Part 18 — Identify Path Preconditions

Every attack path requires conditions.

Example:

PATH-01

might require:

1. Web application reachable
2. Authentication weakness exists
3. Relevant application identity obtained
4. Identity has excessive database privilege
5. Network path to database exists

If one required condition does not exist:

Path Broken

This is why attack paths should not be presented as guaranteed attacks.

Part 19 — Build a Preconditions Table

Step	Required Condition	Evidence	Status
1	Web reachable	Lab 04	Confirmed
2	Auth weakness	Lab 07	Confirmed
3	App identity access	Evidence	Probable
4	DB connectivity	Lab 17	Confirmed
5	Sensitive DB access	Config	Needs validation

Now the path’s confidence becomes visible.

Part 20 — Distinguish Facts from Assumptions

Use:

Confirmed

Direct evidence exists.

Supported

Multiple observations support the relationship.

Assumed

Required for the hypothetical path but not validated.

Unknown

Insufficient evidence.

Example:

Web01 → DB01 network connectivity
CONFIRMED

but:

Web account automatically grants database administration
UNKNOWN

Do not convert the second statement into fact.

Part 21 — Create Attack Path 01

Example:

PATH-01 — Web Application to Sensitive Database

User
 │
 ▼
Web Application
 │
 ▼
Weak Authentication Control
 │
 ▼
Application Identity
 │
 ▼
Database Connectivity
 │
 ▼
Sensitive Database

Now evaluate each transition.

Part 22 — Document PATH-01

Attack Path ID:
PATH-01

Entry Point:
Web Application

Initial Asset:
Web01

Weakness:
Authentication control weakness

Identity:
Application user

Privilege:
Application-level access

Network Path:
Web01 → DB01

Target:
DB01

Target Importance:
Critical

Confidence:
Supported

Business Impact:
Potential unauthorized access to sensitive application data

Avoid claiming actual database compromise.

Part 23 — Create Attack Path 02

Example privilege path:

Standard User
      │
      ▼
Writable Application Resource
      │
      ▼
Privileged Service
      │
      ▼
Elevated Operating-System Context

Lab 16 may already have demonstrated the permission relationship.

Your job is to connect it.

Part 24 — Document PATH-02

Attack Path ID:
PATH-02

Entry Identity:
Standard Linux User

Weakness:
Privileged service depends on lower-privileged writable resource

Privilege Boundary:
Standard User → Privileged Service

Evidence:
Lab 16 permission assessment

Target:
Privileged host context

Confidence:
Confirmed relationship

Validation:
No exploitation performed

This is a valid attack-path observation without demonstrating escalation.

Part 25 — Create Attack Path 03

Example segmentation path:

User Workstation
      │
      ▼
Unexpected Network Access
      │
      ▼
Database Service
      │
      ▼
Sensitive Database

This path may be much shorter.

Sometimes the most dangerous attack paths are created by overly broad network access rather than complicated vulnerabilities.

Part 26 — Document PATH-03

Attack Path ID:
PATH-03

Source:
User Zone

Destination:
Database Zone

Weakness:
Segmentation policy permits unnecessary database connectivity

Target:
DB01

Privilege Required:
Unknown / Application dependent

Evidence:
Lab 17

Impact:
Expanded attack surface around sensitive database service

Notice the language:

Expanded attack surface

not:

Database compromised

Part 27 — Identify Authentication Choke Points

A choke point is a control that can stop or significantly reduce multiple attack paths.

Example:

             Path A
                │
                ▼
          Authentication
                ▲
                │
             Path B

Improving that authentication control may break several paths.

Part 28 — Identify Segmentation Choke Points

Example:

Web01
  │
  ▼
Firewall
  │
  ▼
DB01

If database access is restricted to only required application identities/systems, several possible paths may disappear.

Part 29 — Identify Privilege Choke Points

Example:

Standard User
     │
     ▼
Excessive Privilege
     │
     ▼
Critical Resource

Reducing the privilege may break the path without changing the entry point.

This is a powerful remediation strategy.

Part 30 — Build the Control Register

Control	Path	Effect
MFA	PATH-01	Reduces account compromise risk
Least privilege	PATH-02	Breaks privilege relationship
Network segmentation	PATH-03	Blocks direct DB access
Service isolation	PATH-02	Limits privileged service exposure

Part 31 — Identify Existing Path Blockers

Attack-path analysis should document controls that already prevent progression.

Example:

User
 │
 ▼
Web
 │
 ▼
Application
 │
 X
Firewall
 │
 ▼
Database

The path may terminate because the required connectivity is blocked.

Record:

Path blocked by segmentation control.

This is valuable positive evidence.

Part 32 — Build the Path Blocker Register

Path	Required Transition	Blocking Control	Status
PATH-04	User → DB	Firewall	Blocked
PATH-05	User → Admin	Management segmentation	Blocked
PATH-06	User → Privileged action	MFA/reauthentication	Restricted

Part 33 — Understand Attack Path Length

Compare:

Path A

User
 ↓
Database

with:

Path B

User
 ↓
Web
 ↓
Account
 ↓
Server
 ↓
Service
 ↓
Database

Longer does not automatically mean safer.

Shorter does not automatically mean more dangerous.

Evaluate the controls and conditions at every step.

Part 34 — Assess Path Feasibility

Use four levels:

High Feasibility

Most required conditions are directly supported by evidence.

Moderate Feasibility

Several conditions are supported but one or more require additional validation.

Low Feasibility

Multiple assumptions are required.

Blocked

A validated security control prevents a required transition.

Part 35 — Build a Feasibility Matrix

Path	Confirmed Steps	Assumptions	Blockers	Feasibility
PATH-01	4	1	0	Moderate
PATH-02	3	0	0	High
PATH-03	2	1	0	Moderate
PATH-04	2	0	1	Blocked

This prevents sensational reporting.

Part 36 — Assess Business Impact

Technical paths matter because of what they could affect.

Consider:

Confidentiality

Could the path expose sensitive information?

Integrity

Could it affect trusted configuration or data?

Availability

Could it affect business-critical services?

Administrative Control

Could it reach systems that control other assets?

Compliance

Could it affect regulated information?

Part 37 — Create the Impact Matrix

Target	Confidentiality	Integrity	Availability	Importance
Web01	Medium	High	High	High
DB01	Critical	Critical	High	Critical
Admin01	High	Critical	Critical	Critical

Use the lab’s intended business context.

Part 38 — Prioritize by Path, Not Just Finding

Suppose:

Finding A — Medium
Finding B — Medium
Finding C — Low

Individually they may not appear urgent.

But:

A
↓
B
↓
C
↓
Critical Asset

may justify much higher remediation priority.

This is one of the biggest benefits of attack-path analysis.

Part 39 — Build the Attack Path Risk Model

Use:

Entry Exposure + Weakness Confidence + Privilege Gain + Reachability + Target Criticality + Business Impact

Conceptually:

Accessible Entry
      +
Confirmed Weakness
      +
Privilege Relationship
      +
Network Path
      +
Critical Asset
      =
High-Priority Attack Path

Part 40 — Avoid Double Counting

Do not simply add every vulnerability score together.

For example:

CVSS 6.5
+
CVSS 5.3
+
CVSS 7.0
=
18.8

That is not a meaningful attack-path risk score.

Attack-path risk is contextual.

Part 41 — Build the Attack Path Register

ID	Entry	Weakness	Privilege	Target	Feasibility	Impact	Priority
PATH-01	Web	Weak auth	App identity	DB01	Moderate	Critical	High
PATH-02	Linux user	Writable resource	Privileged service	Linux01	High	High	High
PATH-03	User zone	Segmentation	N/A	DB01	Moderate	Critical	High
PATH-04	User zone	None	N/A	Admin01	Blocked	Critical	Positive

Part 42 — Create the Attack Path Diagram

Use a simple visual language:

[ENTRY]
   │
   ▼
[Web Application]
   │
   │ Weak Authentication
   ▼
[Application Identity]
   │
   │ Excessive Privilege
   ▼
[Application Server]
   │
   │ Allowed DB Connectivity
   ▼
[Database]
   │
   ▼
[CROWN JEWEL]

Mark confirmed relationships:

────►

Potential relationships:

- - - ►

Blocked relationships:

──X──►

Part 43 — Add Confidence to the Diagram

Example:

[Web]
  │
  │ CONFIRMED
  ▼
[Auth Weakness]
  │
  │ SUPPORTED
  ▼
[App Identity]
  │
  │ CONFIRMED
  ▼
[DB Connectivity]
  │
  │ UNKNOWN PRIVILEGE
  ▼
[Database]

This prevents the diagram from overstating certainty.

Part 44 — Create a Path Narrative

A professional attack path should also be understandable without the diagram.

Example:

The authorized assessment identified a user-accessible web application with an authentication weakness. The application tier has permitted connectivity to the sensitive database environment. Existing evidence also indicates that the associated application identity possesses access to database resources. These conditions create a plausible path from the user-facing application toward sensitive application data. No attempt was made to exploit the authentication weakness or access database information.

That is much stronger than:

“We hacked the database.”

Part 45 — Map Attack Paths to MITRE ATT&CK Carefully

Where useful, individual observed behaviors or path stages can be mapped to relevant MITRE ATT&CK techniques.

However:

Do not force every configuration weakness into an ATT&CK technique.

ATT&CK describes adversary behavior.

Your attack-path graph describes relationships and opportunities.

They complement each other but are not identical.

Part 46 — Identify Single Points of Security Failure

Suppose every path to a critical database depends on:

Firewall Rule X

That control becomes especially important.

Likewise:

MFA

or:

Privileged Access Gateway

may protect multiple paths.

Document these as:

Critical Security Choke Points

Part 47 — Build the Choke Point Register

Control	Assets Protected	Paths Affected	Importance
DB firewall	DB01	4	Critical
MFA	Admin access	3	High
Management segmentation	Servers	5	Critical
Least privilege	Linux01	2	High

This helps remediation teams invest in controls with broad impact.

Part 48 — Think Like a Defender

Attack-path analysis should answer:

Where can we break the path most efficiently?

Suppose:

Entry
 ↓
Weak Auth
 ↓
Account
 ↓
Server
 ↓
Database

Potential controls include:

MFA

Rate Limiting

Least Privilege

Server Hardening

Database Segmentation

Database Authorization

You do not necessarily need to fix every stage simultaneously to substantially reduce risk.

Part 49 — Prioritize Path-Breaking Controls

For each path, ask:

Which control would break the path?

Which control is easiest to implement?

Which control reduces the greatest number of paths?

Which control protects the most critical asset?

Which control provides defense in depth?

Part 50 — Example Remediation Strategy

For:

Web
 ↓
Weak Authentication
 ↓
Application Account
 ↓
Database

recommendations might include:

1. Strengthen authentication controls.

2. Implement MFA where appropriate.

3. Reduce application-account privilege.

4. Restrict database network connectivity.

5. Limit database authorization.

6. Monitor application-to-database activity.

This creates multiple defensive layers.

Part 51 — Understand Defense in Depth

A strong architecture should not depend on one control.

Instead:

Authentication
      │
      ▼
Authorization
      │
      ▼
Host Hardening
      │
      ▼
Network Segmentation
      │
      ▼
Database Authorization
      │
      ▼
Monitoring

If one layer fails, another may still stop the path.

Part 52 — Analyze Path Breakpoints

For each path mark:

Entry
  │
  ▼
Weakness
  │
  ▼
Identity
  │
  ▼
[BREAKPOINT 1 — MFA]
  │
  ▼
Server
  │
  ▼
[BREAKPOINT 2 — Segmentation]
  │
  ▼
Database

This makes remediation visually understandable.

Part 53 — Build the Remediation Matrix

Path	Breakpoint	Recommendation	Priority
PATH-01	Authentication	Strengthen authentication/MFA	High
PATH-01	DB access	Restrict DB privilege	High
PATH-02	File permissions	Restrict modification rights	Critical
PATH-03	Network	Block user-to-DB access	Critical

Part 54 — Recalculate Residual Risk

After proposed remediation, ask:

If this control were implemented correctly, what remains?

Example:

Before

User
 ↓
Web
 ↓
DB

After segmentation:

User
 ↓
Web
 │
 X
 ↓
DB

The original path is broken.

But perhaps another path exists:

Management
 ↓
DB

Attack-path management is continuous.

Part 55 — Build the Residual Risk Register

Path	Remediation	Path Status	Residual Risk
PATH-01	MFA + least privilege	Reduced	Medium
PATH-02	Correct ACL	Broken	Low
PATH-03	Segmentation	Broken	Low

This prepares you for later retesting.

Part 56 — Identify Detection Opportunities

Prevention is only part of the solution.

For each attack path ask:

What telemetry could reveal suspicious progression?

Examples:

Authentication Logs

Web Logs

EDR

Windows Security Events

Linux Authentication Logs

Firewall Logs

DNS Logs

Database Audit Logs

Cloud Audit Logs

Part 57 — Build the Detection Map

Example:

Login
  │
  └──► Authentication Logs
            │
            ▼
Server Access
  │
  └──► EDR / OS Logs
            │
            ▼
DB Connection
  │
  └──► Firewall + DB Logs

Attack-path analysis can therefore improve both prevention and detection.

Part 58 — Create the Detection Register

Path Stage	Evidence Source	Detection Opportunity
Authentication	Web/auth logs	Failed/suspicious login
Server access	EDR/OS logs	Unusual process/account activity
Network movement	Firewall	Unexpected connection
Database	DB audit	Unusual access

Part 59 — Identify Unknowns

Professional reporting should explicitly identify missing evidence.

Example:

Unknown:
Whether the application identity has write access to the
sensitive customer-data table.

Impact:
The final stage of PATH-01 cannot currently be classified as
confirmed.

Recommended Validation:
Review the application's database authorization configuration.

This is much better than guessing.

Part 60 — Build an Evidence Chain

For PATH-01:

Evidence 01
Web service exposure
        │
        ▼
Evidence 02
Authentication weakness
        │
        ▼
Evidence 03
Application identity
        │
        ▼
Evidence 04
Web-to-DB connectivity
        │
        ▼
Evidence 05
Database authorization

Each transition should have evidence.

Part 61 — Evidence Quality

Classify evidence as:

Direct

Configuration, logs, or observed behavior directly proves the relationship.

Corroborating

Supports other evidence.

Contextual

Helps explain business/security significance.

Missing

Required to complete the conclusion.

This makes the analysis defensible.

Part 62 — Create the Attack Path Evidence Matrix

Path	Stage	Evidence	Quality	Confidence
PATH-01	Web exposure	Lab 04	Direct	Confirmed
PATH-01	Auth weakness	Lab 07	Direct	Confirmed
PATH-01	DB route	Lab 17	Direct	Confirmed
PATH-01	DB privilege	Config review	Missing	Unknown

Part 63 — Attack Path Finding Example

Finding:
Multiple security conditions create a plausible path from the
user-facing application toward the sensitive database tier.

Evidence:
The application is reachable from the User Zone, an
authentication-control weakness was identified, and the
application server has permitted database connectivity.

Risk:
Successful compromise of the application identity could
potentially provide a route toward sensitive application data,
subject to database authorization controls.

Confidence:
Moderate.

Limitation:
Database privilege associated with the application identity was
not independently validated.

Recommendation:
Strengthen application authentication, apply least privilege to
the application identity, restrict database network access, and
monitor application-to-database activity.

Part 64 — Blocked Attack Path Example

Attack Path:
User Zone → Administrative Server

Result:
Blocked.

Evidence:
The User Zone could not reach the designated administrative
service while the authorized Management Zone could access the
same service.

Security Value:
Network segmentation prevents a lower-trust endpoint from
directly accessing the administrative interface.

Conclusion:
The tested path is interrupted by an effective segmentation
control.

This belongs in the report.

Part 65 — Executive Attack Path Summary

Executives generally do not need:

192.168.20.20:3306

as the primary message.

Instead:

A combination of application authentication weakness, excessive access, and permitted database connectivity creates a plausible route from the user-facing application toward sensitive data.

Then explain:

Restricting application privileges and database connectivity would break the path at multiple points.

Technical evidence can remain in the detailed section.

Part 66 — Attack Path Priority Model

Use:

Critical

A highly feasible path leads to a critical asset with severe potential impact.

High

A credible path exists toward a sensitive asset with limited blockers.

Medium

The path requires meaningful assumptions or additional conditions.

Low

The path is unlikely, heavily constrained, or targets a low-impact asset.

Blocked

A confirmed security control prevents progression.

Do not assign severity purely from diagram length.

Part 67 — Create the Final Attack Path Register

ID	Entry	Target	Feasibility	Impact	Controls	Priority
PATH-01	Web	DB01	Moderate	Critical	Partial	High
PATH-02	Linux user	Privileged service	High	High	Weak	High
PATH-03	User zone	DB01	Moderate	Critical	Weak segmentation	High
PATH-04	User zone	Admin01	Blocked	Critical	Strong segmentation	Blocked

Part 68 — Create the Executive Attack Path Map

Example:

                    [USER]
                       │
                       ▼
              [WEB APPLICATION]
                       │
                  Weak Auth
                       │
                       ▼
               [APP IDENTITY]
                       │
              Excessive Privilege
                       │
                       ▼
               [APP SERVER]
                       │
                DB Connectivity
                       │
                       ▼
               [DATABASE]
                       │
                       ▼
                [CROWN JEWEL]

Add remediation breakpoints:

                    [USER]
                       │
                  [MFA CONTROL]
                       X
                       │
              [WEB APPLICATION]
                       │
                [LEAST PRIVILEGE]
                       X
                       │
                 [DATABASE]

Part 69 — Mission Challenge

Using only evidence from previous labs, identify at least:

3 Plausible Attack Paths

2 Blocked Attack Paths

3 Critical Security Choke Points

5 Path-Breaking Recommendations

Complete:

ATTACK PATH ANALYSIS


CRITICAL ASSETS

Critical Asset 01:

Critical Asset 02:

Critical Asset 03:


ENTRY POINTS

Entry Point 01:

Entry Point 02:

Entry Point 03:


PATH 01

Entry Point:

Initial Asset:

Weakness:

Identity:

Privilege:

Network Path:

Trust Boundaries:

Target:

Target Criticality:

Confirmed Steps:

Assumptions:

Blocking Controls:

Feasibility:

Potential Impact:

Priority:

Recommended Breakpoint:


PATH 02

Entry Point:

Initial Asset:

Weakness:

Identity:

Privilege:

Network Path:

Target:

Feasibility:

Impact:

Priority:

Recommended Breakpoint:


PATH 03

Entry Point:

Weakness:

Privilege:

Connectivity:

Target:

Feasibility:

Impact:

Priority:

Recommended Breakpoint:


BLOCKED PATH 01

Source:

Target:

Required Transition:

Blocking Control:

Evidence:

Security Value:


BLOCKED PATH 02

Source:

Target:

Required Transition:

Blocking Control:

Evidence:

Security Value:


FINAL ANALYSIS

Highest-Risk Attack Path:

Most Critical Target:

Most Important Identity:

Most Important Trust Boundary:

Most Important Security Choke Point:

Strongest Existing Control:

Most Important Missing Control:

Highest-Priority Remediation:

Residual Risk:

Overall Conclusion:

Part 70 — What Not to Do

This lab does not require:

Exploitation

Privilege escalation

Password cracking

Password spraying

Credential stuffing

Credential theft

Session hijacking

MFA bypass

SUID abuse

sudo abuse

Service exploitation

Lateral movement

Pivoting

Port forwarding

Tunneling

Firewall bypass

VLAN hopping

Database exploitation

Data extraction

Persistence

Security-control disabling

Log clearing

Your objective is:

Connect evidence—not compromises.

Part 71 — Troubleshooting

You Cannot Find an Attack Path

That may be a positive result.

Start with:

Critical Asset
      ↑
Who Can Reach It?
      ↑
Which Identities?
      ↑
From Which Systems?
      ↑
How Can Those Systems Be Reached?

Working backward from the crown jewel is often effective.

A Path Contains Too Many Assumptions

Reduce its confidence.

Use:

Low Feasibility

or:

Requires Further Validation

Do not fill evidence gaps with assumptions.

A Network Path Is Blocked

Stop that branch.

Document:

PATH BLOCKED

and identify the security control responsible.

A Finding Does Not Connect Anywhere

It may remain an isolated finding.

Not every vulnerability belongs in an attack path.

Multiple Paths Use the Same Weakness

That is important.

The shared weakness may represent a:

Security choke point.

Prioritize it accordingly.

Mission Deliverables

Complete:

• scope confirmed

• previous lab evidence reviewed

• Asset Register created

• crown jewels identified

• Entry Point Register created

• vulnerabilities correlated

• identities mapped

• privileges mapped

• network relationships mapped

• trust boundaries identified

• relationship graph created

• attack-path prerequisites documented

• facts separated from assumptions

• at least three attack paths analyzed

• blocked paths documented

• path feasibility assessed

• business impact assessed

• security choke points identified

• path breakpoints identified

• Attack Path Register created

• Attack Path Evidence Matrix created

• remediation matrix created

• residual risk assessed

• detection opportunities documented

• executive attack-path map created

• final report completed

Lab Report Template

# Lab 18 — Attack Path Analysis

## Executive Summary

## Mission Objective

## Scope

## Rules of Engagement

## Methodology

## Environment Architecture

## Asset Register

## Critical Assets and Crown Jewels

## Entry Points

## Existing Security Findings

## Identity Relationships

## Privilege Relationships

## Network Relationships

## Trust Boundaries

## Relationship Graph

## Attack Path 01

### Entry Point
### Preconditions
### Evidence
### Identity
### Privilege
### Connectivity
### Target
### Feasibility
### Business Impact
### Security Controls
### Recommended Breakpoints

## Attack Path 02

## Attack Path 03

## Blocked Attack Paths

## Attack Path Evidence Matrix

## Attack Path Register

## Critical Security Choke Points

## Positive Security Controls

## Detection Opportunities

## Risk Prioritization

## Remediation Matrix

## Residual Risk

## Limitations

## Executive Attack Path Map

## Conclusion

Knowledge Check

Question 1 — What is an attack path?

A sequence of conditions, weaknesses, identities, privileges, connectivity, and trust relationships that could enable progression toward a security objective.

Question 2 — Is a vulnerability the same as an attack path?

No.

A vulnerability is an individual weakness. An attack path connects multiple conditions or relationships.

Question 3 — Must you exploit every step to document an attack path?

No.

Configuration, permissions, network evidence, authentication evidence, and other validated relationships can establish a credible path.

Question 4 — What is a crown jewel?

A critical organizational asset whose compromise could cause significant business or security impact.

Question 5 — Why identify attack-path prerequisites?

Because they show which conditions must be true before progression is possible.

Question 6 — What happens when a required transition is blocked?

That attack-path branch stops.

The blocking control should be documented as a positive security control.

Question 7 — Why separate confirmed facts from assumptions?

Because attack-path diagrams can otherwise exaggerate what the evidence actually proves.

Question 8 — What is a security choke point?

A control or relationship that affects multiple attack paths and therefore offers a high-value location for defensive improvement.

Question 9 — Why can several medium findings create high risk?

Because their combination may create a feasible path toward a critical asset.

Question 10 — What is the defender’s most important attack-path question?

“Where can we break the path most effectively?”

Skills Achieved

After completing this lab, you should understand:

• attack-path analysis

• vulnerability correlation

• asset criticality

• crown-jewel identification

• entry-point analysis

• identity relationships

• privilege relationships

• network relationships

• trust boundaries

• attack-path prerequisites

• attack-path blockers

• confirmed vs assumed relationships

• relationship graphs

• attack-path diagrams

• feasibility analysis

• business-impact analysis

• security choke points

• path breakpoints

• defense in depth

• path-based remediation

• residual-risk assessment

• detection mapping

• executive attack-path communication

• professional attack-path reporting

Professional Takeaway

A penetration tester should not stop at:

“I found ten vulnerabilities.”

A more useful question is:

“Which of these weaknesses actually connect, what can they lead to, and which combination creates the greatest business risk?”

Think in relationships:

Entry
  ↓
Exposure
  ↓
Weakness
  ↓
Identity
  ↓
Privilege
  ↓
Connectivity
  ↓
Critical Asset
  ↓
Business Impact

And from the defender’s perspective:

Attack Path
     │
     ▼
Find Choke Point
     │
     ▼
Break Relationship
     │
     ▼
Reduce Reachability
     │
     ▼
Reduce Privilege
     │
     ▼
Improve Detection

The goal is not to prove how far an attacker can go at any cost.

The goal is to provide enough defensible evidence for the organization to understand:

where risk concentrates, which controls matter most, and where remediation will have the greatest security benefit.

What’s Next?

➡️ Lab 19 — Vulnerability Validation & Evidence Collection

You have now built attack paths using evidence collected across the environment.

The next step is to improve the quality of the individual findings that support those paths.

Lab 19 will focus on:

• selecting findings for validation

• defining safe validation boundaries

• establishing validation criteria

• distinguishing scanner findings from validated findings

• reproducing observations safely

• collecting configuration evidence

• collecting network evidence

• recording timestamps

• preserving screenshots and outputs

• documenting affected assets

• determining confidence

• avoiding destructive proof-of-concept activity

• recording remediation evidence

• preparing findings for professional reporting

The methodology becomes:

Finding → Validation Question → Safe Test → Observation → Evidence → Confidence → Impact → Recommendation

By the end of Lab 19, you should be able to answer:

“Do I have enough reliable, reproducible, and defensible evidence to support this security finding without creating unnecessary risk?”