Lab 13 Network Attack-Path Analysis

Mission Overview

Welcome to Lab 13 — Network Attack-Path Analysis.

In the previous labs, you built up a detailed understanding of the authorized network environment. You identified hosts, services, authentication surfaces, Windows and Linux exposures, infrastructure services, packet-level behavior, and segmentation controls.

Now you will combine those findings into something much closer to how professional penetration testers think:

Attack paths.

An individual weakness may appear low or medium risk when viewed alone. But when several weaknesses connect together, they may create a much more serious route through the environment.

For example:

User Workstation
      ↓
Management Service Reachable
      ↓
Weak Access Control
      ↓
Server Network
      ↓
Database Reachable
      ↓
Sensitive Asset

No single step necessarily proves compromise.

But together, they reveal how an attacker could gain increasing reach if one system were already compromised.

Mission Goal: Correlate validated findings, network trust relationships, administrative exposure, excessive permissions, and segmentation gaps into realistic attack-path models, then identify the security controls that should be strengthened first to break those paths.

Mission Information

Item	Details
Difficulty	Intermediate–Advanced
Estimated Time	120–150 minutes
Primary Skill	Attack-Path Modeling
Secondary Skill	Security Control Correlation
Environment	GoHackersCloud Network Pentesting Lab
Input	Evidence from Labs 02–12
Primary Outcome	Network Attack-Path Register
Safety Level	Authorized Analysis Only

Learning Objectives

By completing this lab, you will be able to:

• identify realistic network entry points

• identify high-value assets

• correlate multiple validated weaknesses

• understand trust relationships

• identify management-plane exposure

• identify dangerous segmentation gaps

• distinguish vulnerability severity from attack-path importance

• build attack-path diagrams

• identify required assumptions

• identify security controls that interrupt attack paths

• prioritize remediation based on path reduction

• identify chokepoints

• document compensating controls

• avoid overstating hypothetical attacks

• produce evidence-based attack-path findings

Attack-Path Methodology

Use:

Entry Point → Exposure → Weakness → Trust Relationship → Reachable Asset → Security Impact → Control Break → Remediation Priority

Conceptually:

Entry Point
    │
    ▼
Reachable Service
    │
    ▼
Validated Weakness
    │
    ▼
Trust Relationship
    │
    ▼
Additional Network Reach
    │
    ▼
High-Value Asset
    │
    ▼
Potential Business Impact
    │
    ▼
Control That Could Break Path

The central principle is:

Attack-path analysis connects validated facts. It does not invent exploitation that has not been demonstrated.

Part 1 — Revalidate Scope

This lab is primarily analytical.

You are not performing a new exploitation campaign.

Confirm:

Authorized Network:

Authorized Hosts:

Validated Findings Available:
Yes / No

Segmentation Results Available:
Yes / No

Authentication Assessment Available:
Yes / No

Privilege Escalation:
Not Performed

Credential Attacks:
Not Performed

Lateral Movement:
Not Performed

Assessment Date:

Investigator:

Part 2 — Create the Workspace

Create:

Network-Pentesting-Labs/
└── Lab-13/
    ├── Scope/
    ├── Evidence-Import/
    ├── Assets/
    ├── Entry-Points/
    ├── Trust-Relationships/
    ├── Attack-Paths/
    │   ├── Path-01/
    │   ├── Path-02/
    │   └── Path-03/
    ├── Control-Breaks/
    ├── Risk/
    ├── Diagrams/
    ├── Findings/
    └── Report/

Create:

Lab-13-Network-Attack-Path-Analysis.md

Suggested structure:

# Lab 13 — Network Attack-Path Analysis

## Mission Objective

## Authorization

## Evidence Sources

## Asset Classification

## Entry Points

## Validated Weaknesses

## Trust Relationships

## Management Exposure

## Segmentation Gaps

## Attack Path 01

## Attack Path 02

## Attack Path 03

## Control Break Analysis

## Remediation Priority

## Positive Security Controls

## Limitations

## Conclusion

Part 3 — Import Evidence from Previous Labs

Your attack-path model should be based on the evidence already collected.

Bring forward:

Lab 02:
Validated hosts

Lab 03:
TCP services

Lab 04:
UDP services

Lab 05:
Service enumeration

Lab 06:
Validated vulnerabilities

Lab 07:
Authentication and remote-access findings

Lab 08:
Windows / SMB findings

Lab 09:
Linux service findings

Lab 10:
Infrastructure findings

Lab 11:
Communication relationships

Lab 12:
Segmentation gaps

Create an Evidence Source Register.

Evidence ID	Source Lab	Observation
EV-01	Lab 07	SSH reachable from user network
EV-02	Lab 08	SMB exposed on Windows server
EV-03	Lab 12	User → Database allowed
EV-04	Lab 06	Validated service weakness

Part 4 — Understand What an Attack Path Is

An attack path is a sequence of conditions that could allow an attacker to progress from one position in the environment toward a more valuable target.

Example:

Compromised User Workstation
        ↓
SSH Reachable
        ↓
Administrative Surface Exposed
        ↓
Server Access Potential
        ↓
Database Network Reachability
        ↓
Sensitive Asset Exposure

The path may include:

• vulnerable services

• weak authentication

• excessive permissions

• network access

• management exposure

• trust relationships

• sensitive data access

Part 5 — Do Not Assume the Initial Compromise

For this lab, use a clearly stated scenario such as:

Assumption: A standard user workstation in the authorized user segment is already compromised.

You are not performing that compromise.

This lets you ask:

What could become reachable next?

Record:

Starting Assumption:

Compromised Asset:

Source Zone:

Privileges:
Standard User / Unknown

Credentials Available:
None assumed unless explicitly supplied

Persistence:
Not assumed

Part 6 — Identify Entry Points

Possible entry points include:

• user workstation

• public-facing web system

• remote-access gateway

• exposed server service

• VPN endpoint

• guest network

• third-party connection

For your lab, identify only modeled starting positions.

Create:

Entry ID	Asset	Zone	Reason
EP-01	User Workstation	User	Simulated compromise
EP-02	Web Server	Server/DMZ	Exposed service

Part 7 — Identify High-Value Assets

High-value assets may include:

• domain infrastructure

• database servers

• file servers

• backup systems

• administrative platforms

• management servers

• security infrastructure

• production application servers

Create:

Asset	Function	Sensitivity	Criticality
Database	Business data	High	High
File Server	Shared data	High	Medium/High
Management Server	Administration	High	High

Part 8 — Classify Assets

Use:

Standard Asset

Compromise has limited local impact.

Important Asset

Supports significant business functions.

High-Value Asset

Compromise could provide:

• broad control

• sensitive data

• privileged credentials

• administrative reach

Critical Asset

Compromise could materially affect core business or infrastructure.

Part 9 — Build the Asset Criticality Register

Asset	Role	Data	Privilege	Criticality
User01	Workstation	User	Low	Standard
Web01	Application	App	Medium	Important
DB01	Database	Sensitive	High	Critical
MGMT01	Administration	Privileged	High	Critical

Part 10 — Identify Trust Relationships

A trust relationship exists when one system or zone is allowed to communicate with another.

Examples:

User → Web

Web → Database

Management → Server

Server → DNS

These are legitimate relationships.

The security question is:

Can those relationships be abused if one side becomes compromised?

Part 11 — Build the Trust Relationship Register

Source	Destination	Service	Required	Security Relevance
User	Web	HTTPS	Yes	Normal
Web	DB	DB Port	Yes	Sensitive
Mgmt	Linux	SSH	Yes	Privileged
User	DB	DB Port	No	Segmentation Gap

Part 12 — Identify Excess Trust

From Lab 12, look for:

User → SSH

User → RDP

Guest → SMB

User → Database

Server → Unrelated Server

These can create attack-path edges.

Represent them as:

Unexpected Trust Relationship

Part 13 — Identify Management-Plane Exposure

Management services are especially important because they may lead to privileged access.

Examples:

• SSH

• RDP

• WinRM

• SNMP

• administrative HTTPS

• hypervisor management

• database administration

Create:

Asset	Service	Reachable From	Expected
Linux01	SSH	User	No
Windows01	RDP	Mgmt	Yes
Network Device	SNMP	User	No

Part 14 — Identify Authentication Findings

Bring forward findings such as:

• excessive privilege

• weak MFA requirements

• guest access

• anonymous resource access

• shared accounts

• overly broad administrative exposure

Do not translate every authentication observation into compromise.

Use:

Authentication Weakness
        +
Reachability
        +
Appropriate Conditions
        =
Potential Attack-Path Step

Part 15 — Identify Permission Weaknesses

From SMB/NFS/application assessments, identify:

• excessive read permission

• excessive write permission

• broad share access

• unnecessary administrative access

Example:

Standard User
      ↓
Finance Share
      ↓
Unexpected Read Access

This may represent an impact path without needing host compromise.

Part 16 — Identify Validated Vulnerabilities

Import only validated findings from Lab 06.

For example:

VULN-01
Legacy protocol enabled

VULN-02
Insecure administrative transport

VULN-03
Known configuration weakness

Do not use:

Scanner says vulnerable

as the sole basis for attack-path modeling.

Part 17 — Create the Attack-Path Building Blocks

Every path should use building blocks such as:

Entry Point

Network Reachability

Exposed Service

Validated Weakness

Authentication Condition

Permission Condition

Trust Relationship

Target Asset

Potential Impact

Part 18 — Use Evidence IDs

Example:

EP-01
User workstation compromise assumption

EV-12
User can reach SSH on Linux01

AUTH-03
Standard account receives excessive role

SEG-02
Linux01 can reach DB01

ASSET-04
DB01 classified critical

Now you can construct a defensible path.

Part 19 — Create Attack Path 01

Example:

Scenario

User workstation is assumed compromised.

Validated evidence shows the user network can directly reach a Linux administrative service that should be management-only.

The Linux server also has authorized connectivity to the database tier.

Model:

Compromised User Workstation
          │
          │ User → SSH unexpectedly allowed
          ▼
      Linux Server
          │
          │ Expected server → DB trust
          ▼
     Database Tier

Important:

You have not proven:

User workstation can automatically compromise Linux.

You have proven:

The attacker could interact with a management surface that architecture intended to isolate.

Part 20 — Document Attack Path 01

ATTACK PATH ID:
AP-01

Starting Position:
Compromised user workstation

Entry Zone:
User Network

Step 01:
Reach Linux SSH service

Evidence:
SEG-03 / AUTH evidence

Condition:
SSH reachable from unauthorized segment

Step 02:
Potential interaction with server authentication surface

Required Assumption:
Attacker would still require valid access or a separate exploitable weakness

Step 03:
Linux server has authorized connectivity to database tier

Evidence:
Segmentation matrix

Target:
Database

Potential Impact:
Increased attacker proximity to sensitive data systems

Confidence:
High for reachability
Lower for actual compromise progression

Part 21 — Separate Facts from Assumptions

Every path should explicitly distinguish:

Confirmed

Supported directly by evidence.

Conditional

Requires another condition to become true.

Assumed

Scenario assumption used for modeling.

Example:

Confirmed:
User → SSH reachable

Assumed:
User workstation compromised

Conditional:
Attacker obtains usable Linux access

Confirmed:
Linux → Database connectivity

This dramatically improves report quality.

Part 22 — Build an Assumption Register

Path	Assumption	Required
AP-01	User host compromised	Yes
AP-01	Linux access obtained	Conditional
AP-02	Supplied user identity represents standard role	Yes

Part 23 — Build Attack Path 02

Example:

Compromised User Workstation
          ↓
Direct Database Connectivity
          ↓
Database Authentication Surface
          ↓
Critical Data Asset

You validated in Lab 12:

User → Database: Allowed

Expected:

Deny

The attack-path significance is larger than simply:

“Port 3306 is open.”

Part 24 — Document Attack Path 02

ATTACK PATH ID:
AP-02

Entry:
User Network

Target:
Database Server

Evidence:
SEG-01

Confirmed Condition:
Database listener is reachable directly from the user zone.

Expected Architecture:
Only application and approved management systems should reach DB.

Potential Attack Benefit:
A compromised user workstation can directly interact with the
database authentication surface.

Compromise Proven:
No

Security Significance:
Application-tier network boundary can be bypassed at the network
layer.

Primary Control Break:
Network segmentation

Part 25 — Build Attack Path 03 — Guest Exposure

Example:

Untrusted Guest Device
       ↓
Internal SMB Reachable
       ↓
Windows Authentication Surface
       ↓
Internal File Server

This is important because the source zone has low trust.

Again:

SMB reachable
     ≠
SMB compromised

But the trust boundary is broken.

Part 26 — Build Attack Path 04 — Excessive Share Access

Suppose Lab 08 confirmed:

Standard User
    ↓
Restricted Share
    ↓
Read Access

Path:

Compromised Standard Account
        ↓
Authenticate to SMB
        ↓
Restricted Finance Share
        ↓
Sensitive Information Exposure

Notice this attack path does not require host exploitation.

It is an authorization path.

Part 27 — Build Attack Path 05 — Plaintext Credentials

Where Lab 11 confirmed a designated vulnerable HTTP authentication service:

Network Observer
      ↓
Plaintext HTTP Login
      ↓
Authentication Information Exposure
      ↓
Administrative Identity Risk

Keep it conditional:

Attacker must be able to observe the network path

Do not claim credential theft unless it was actually part of the authorized scenario.

Part 28 — Understand Different Attack-Path Types

Useful categories:

Network Path

Excessive network reachability.

Authentication Path

Weak identity/authentication controls.

Authorization Path

Excessive privileges or data access.

Management Path

Exposure of administrative interfaces.

Data Access Path

Direct access to sensitive information.

Infrastructure Path

Exposure of DNS/SNMP/management infrastructure.

Part 29 — Build the Attack-Path Register

ID	Type	Entry	Target	Key Control Failure
AP-01	Management	User	Linux	Admin exposure
AP-02	Network	User	Database	Segmentation
AP-03	Network	Guest	Windows	Guest isolation
AP-04	Authorization	User Account	Finance	Permissions

Part 30 — Score Path Length

You can describe paths as:

Short Path

One or two conditions between entry point and target.

Example:

User → Database

Medium Path

Multiple relationships required.

User → Server → Database

Long Path

Multiple systems, permissions, or assumptions are required.

Shorter paths often deserve greater attention because they require fewer failures.

Part 31 — Identify Path Preconditions

For every path document:

Initial Access Required:

Network Access Required:

Credential Required:

Privilege Required:

User Interaction Required:

Additional Vulnerability Required:

Existing Trust Required:

This prevents exaggerated risk statements.

Part 32 — Build the Preconditions Matrix

Path	Initial Access	Credential	Extra Vuln	Network Gap
AP-01	User host	Maybe	Maybe	Yes
AP-02	User host	DB auth needed	No for reachability	Yes
AP-04	User account	Yes	No	No

Part 33 — Identify Chokepoints

A chokepoint is a control that many attack paths depend upon.

Example:

                User Network
                    │
             Management Firewall
                /        \
             SSH          RDP
              │            │
            Linux        Windows

Restricting management access at the firewall may break several paths simultaneously.

Part 34 — Build the Chokepoint Register

Control	Paths Affected	Priority
Management segmentation	AP-01, AP-03	High
Database ACL	AP-02	High
SMB permission cleanup	AP-04	Medium

Part 35 — Understand Control Breaks

For each path ask:

What is the earliest practical control that could break this path?

Example:

User
 ↓
SSH
 ↓
Linux

Possible controls:

Network ACL
Host Firewall
Jump Host Requirement
MFA
Authentication Hardening

The best remediation may be the earliest and most broadly effective control.

Part 36 — Build the Control-Break Matrix

Path	Break Point	Control	Effect
AP-01	User→SSH	Firewall	Removes direct admin exposure
AP-02	User→DB	ACL	Restores tier isolation
AP-03	Guest→SMB	Firewall	Restores guest isolation
AP-04	User→Finance	Permissions	Removes unauthorized access

Part 37 — Think in Defense in Depth

One path may be interrupted at multiple layers.

Example:

User Workstation
     │
 [Segmentation]
     │
     ▼
SSH
     │
 [MFA]
     │
     ▼
Linux
     │
 [Least Privilege]
     │
     ▼
Database
     │
 [DB ACL]

Each control reduces risk.

Part 38 — Identify Missing Controls

Create:

Path	Existing Controls	Missing/Weak Controls
AP-01	SSH auth	Network restriction
AP-02	DB auth	User-zone ACL
AP-04	SMB auth	Correct share authorization

Part 39 — Identify Compensating Controls

A weakness may be partially mitigated by another control.

Example:

RDP reachable from user network

but:

MFA + host firewall restrictions + monitoring

may reduce risk.

Do not ignore compensating controls.

Part 40 — Build the Compensating Control Register

Path	Weakness	Compensating Control	Remaining Risk
AP-01	SSH broad exposure	MFA	Medium
AP-02	DB reachability	Strong DB auth	Medium/High

Part 41 — Prioritize Attack Paths

Do not prioritize based only on the CVSS score of individual vulnerabilities.

Consider:

Entry Accessibility

Path Length

Number of Assumptions

Asset Criticality

Privilege Gain

Data Sensitivity

Network Trust

Control Coverage

Likelihood

Business Impact

Part 42 — Simple Attack-Path Risk Model

Use:

Path Risk = Entry Accessibility + Weakness Strength + Reachability + Target Criticality − Effective Controls

This is qualitative, not mathematical.

Use:

• Critical

• High

• Medium

• Low

Part 43 — Build the Attack-Path Risk Matrix

Path	Entry	Target	Assumptions	Criticality	Priority
AP-01	User	Linux/Admin	Medium	High	High
AP-02	User	Database	Low	Critical	High
AP-03	Guest	Windows	Medium	High	High
AP-04	User	Sensitive Data	Low	High	High

Part 44 — Assess Confidence

Use separate confidence ratings.

High

All path edges are supported by validated observations.

Medium

Some path elements depend on reasonable but unverified conditions.

Low

Major portions of the path are hypothetical.

Example:

Risk:
High

Confidence:
Medium

This is perfectly valid.

Part 45 — Build the Path Confidence Register

Path	Risk	Confidence	Reason
AP-01	High	Medium	Access not demonstrated
AP-02	High	High	Direct network path validated
AP-04	High	High	Permission validated

Part 46 — Avoid Exploit Chaining

You do not need to execute:

Exploit A
   ↓
Exploit B
   ↓
Credential Theft
   ↓
Lateral Movement

to build the path.

Instead, document:

Validated Condition A
       +
Validated Trust B
       +
Validated Exposure C
       =
Attack Path

Part 47 — Create an Attack-Path Diagram

Example:

                      [User Workstation]
                              │
                  unexpected SSH access
                              │
                              ▼
                       [Linux Server]
                              │
                    trusted DB access
                              │
                              ▼
                      [Database Server]
                              │
                              ▼
                       Sensitive Data

Annotate controls:

User
 │
 │ [MISSING: Management ACL]
 ▼
Linux
 │
 │ [ALLOW: App/Server Trust]
 ▼
Database

Part 48 — Use Visual Status Indicators

For diagrams, you can use:

[CONFIRMED]
[CONDITIONAL]
[ASSUMED]
[BLOCKED]

Example:

[ASSUMED]
User Host Compromised
        │
        ▼
[CONFIRMED]
SSH Reachable
        │
        ▼
[CONDITIONAL]
Linux Authentication Achieved
        │
        ▼
[CONFIRMED]
DB Network Reachability

This makes the path defensible.

Part 49 — Identify Broken Paths

Not every apparent attack path should survive validation.

Example:

User
 ↓
SSH
 X
Linux

If management segmentation blocks SSH, the path is broken.

Record:

Attack path interrupted by network segmentation.

Part 50 — Build the Broken Path Register

Path	Control	Result
BP-01	SSH management ACL	Path blocked
BP-02	Guest isolation	Path blocked
BP-03	DB ACL	Path blocked

Positive controls matter.

Part 51 — Identify Security Control Value

Attack-path analysis can show that a single control protects multiple systems.

For example:

Restricting user-to-management access may break paths to Linux, Windows, SNMP, and administrative web interfaces.

This is much more useful than reporting each port independently.

Part 52 — Build the Control Effectiveness Matrix

Control	Services Protected	Attack Paths Broken
Mgmt ACL	SSH/RDP/SNMP	3
DB ACL	MySQL/PostgreSQL	2
Guest isolation	SMB/Admin	2

Part 53 — Identify Root Cause vs Symptoms

Suppose you found:

SSH reachable
RDP reachable
SNMP reachable
Admin web reachable

from the user network.

These may appear as four findings.

But the root cause may be:

Management network access controls are overly permissive.

Attack-path analysis helps identify that root cause.

Part 54 — Build the Root Cause Register

Root Cause	Related Findings
Weak management segmentation	SSH, RDP, SNMP, Admin UI
Excessive internal trust	DB, SMB
Excessive authorization	Share access

Part 55 — Prioritize Root-Cause Remediation

Prefer remediation that removes multiple attack-path edges.

Instead of:

Fix SSH
Fix RDP
Fix SNMP
Fix HTTPS admin

you may recommend:

Restrict all administrative protocols to the management zone.

Then add service-level controls as defense in depth.

Part 56 — Example Attack-Path Finding

Finding ID:
PATH-01

Title:
User Network Provides Direct Path to Administrative Server Services

Entry Point:
User Workstation

Affected Assets:
Linux Server
Windows Server
Network Management Host

Severity:
High

Confidence:
High

Description:
Multiple administrative services identified during the assessment
are directly reachable from the user network despite the intended
architecture placing administrative access within the dedicated
management zone.

Validated relationships include SSH, RDP, and management-service
reachability from the user assessment segment.

Attack Path:
Compromise of an ordinary user endpoint would place an attacker in
direct network proximity to multiple administrative authentication
surfaces.

Compromise of those services was not attempted or assumed to be
automatically possible.

Impact:
The segmentation gap increases potential post-compromise reach and
reduces the protection provided by management-plane isolation.

Root Cause:
Overly permissive network access between user and management
security zones.

Recommendation:
Restrict administrative protocols to approved management systems,
jump hosts, or management networks and apply deny-by-default
network policy between user and administrative zones.

Retest:
Verify SSH, RDP, SNMP, and management interfaces are inaccessible
from the user segment while remaining available through approved
administrative paths.

Part 57 — Example Attack-Path Finding — Database

Finding ID:
PATH-02

Title:
User Network Has Direct Network Path to Critical Database Tier

Entry:
User Network

Target:
Database Server

Severity:
High

Confidence:
High

Evidence:
Validated direct database-port reachability from the user zone.

Expected Architecture:
User → Application → Database

Observed Architecture:
User → Database also permitted

Attack-Path Impact:
A compromised user endpoint can interact directly with the
database authentication surface, bypassing the intended
application-tier network boundary.

Compromise Proven:
No

Recommendation:
Permit database connectivity only from required application and
approved management systems.

Part 58 — Example Attack-Path Finding — Excessive Data Access

Finding ID:
PATH-03

Title:
Standard User Identity Provides Direct Path to Restricted Business Data

Entry:
Compromised standard test identity

Service:
SMB

Target:
Restricted Finance Share

Severity:
High

Confidence:
High

Description:
The standard training identity can authenticate normally and read
the restricted Finance share despite having no documented
business requirement for that resource.

Attack Path:
Standard Account
      ↓
SMB Authentication
      ↓
Finance Share
      ↓
Sensitive Data

Required Exploitation:
None

Root Cause:
Excessive authorization.

Recommendation:
Correct share and filesystem permissions and enforce role-based
access.

Part 59 — Example Positive Attack-Path Control

Control:
Database Tier Network Isolation

Observation:
Database connectivity was available from the application server
but denied from user and guest zones.

Attack-Path Effect:
Direct user- or guest-originated paths to the database
authentication surface are interrupted.

Assessment:
Control materially reduces post-compromise attack-path options.

Part 60 — Build the Attack-Path Findings Register

ID	Entry	Target	Root Cause	Severity	Confidence
PATH-01	User	Mgmt Services	Segmentation	High	High
PATH-02	User	Database	Tier isolation	High	High
PATH-03	User Identity	Finance	Authorization	High	High

Part 61 — Build the Remediation Priority Register

Priority	Remediation	Paths Broken
1	Restrict management access	AP-01, AP-03
2	Restrict DB connectivity	AP-02
3	Correct SMB permissions	AP-04
4	Require encrypted admin transport	Relevant auth paths

Part 62 — Create a Remediation Roadmap

Use three phases.

Immediate

Address paths to critical assets.

Examples:

Block user → database
Block guest → internal SMB
Restrict management services

Near Term

Improve identity and service controls.

MFA
Least privilege
SMB signing
Role-based permissions

Strategic

Improve architecture.

Dedicated management zone
Microsegmentation
Network policy governance
Continuous validation

Part 63 — Build the Attack-Path Summary

NETWORK ATTACK-PATH SUMMARY

Entry Points:

High-Value Assets:

Validated Network Gaps:

Authentication Weaknesses:

Authorization Weaknesses:

Management Exposures:

Infrastructure Exposures:

Attack Paths Identified:

High-Risk Paths:

Medium-Risk Paths:

Broken Paths:

Primary Root Causes:

Most Valuable Security Control:

Highest-Priority Remediation:

Part 64 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
Network Attack-Path Analysis

Assessment Date:

Investigator:

Evidence Sources:


ENTRY POINTS

Entry Point 01:

Zone:

Assumption:

Entry Point 02:

Zone:

Assumption:


HIGH-VALUE ASSETS

Asset 01:

Role:

Criticality:

Asset 02:

Role:

Criticality:


TRUST RELATIONSHIPS

User → Server:

User → Database:

Server → Database:

Management → Server:

Guest → Internal:

Other:


VALIDATED WEAKNESSES

Authentication:

Authorization:

Segmentation:

Service Exposure:

Infrastructure Exposure:

Plaintext Communication:


ATTACK PATH 01

Entry:

Step 01:

Evidence:

Step 02:

Evidence:

Step 03:

Target:

Confirmed Conditions:

Conditional Conditions:

Assumptions:

Potential Impact:

Root Cause:

Breaking Control:

Severity:

Confidence:


ATTACK PATH 02

Entry:

Step 01:

Step 02:

Target:

Evidence:

Root Cause:

Breaking Control:

Severity:

Confidence:


ATTACK PATH 03

Entry:

Target:

Evidence:

Root Cause:

Breaking Control:

Severity:

Confidence:


BROKEN PATHS

Path:

Control Blocking Path:

Evidence:

Security Value:


CHOKEPOINTS

Chokepoint 01:

Paths Affected:

Priority:

Chokepoint 02:

Paths Affected:

Priority:


ROOT CAUSES

Root Cause 01:

Related Findings:

Root Cause 02:

Related Findings:


REMEDIATION PRIORITY

Priority 01:

Paths Broken:

Priority 02:

Paths Broken:

Priority 03:

Paths Broken:


FINAL ANALYSIS

Shortest Attack Path:

Highest-Impact Path:

Highest-Confidence Path:

Most Important Segmentation Gap:

Most Important Authorization Gap:

Best Existing Security Control:

Most Valuable Remediation:

Validated Attack Paths:

Conditional Paths:

Broken Paths:

Ready for Vulnerability Validation & Pentest Reporting:
Yes / No

Part 65 — What Not to Do

Do not:

Compromise additional systems

Perform credential theft

Dump credentials

Attempt password spraying

Perform lateral movement

Attempt privilege escalation

Execute remote commands simply to extend a path

Install persistence

Create accounts

Deploy payloads

Perform SMB relay

Use pass-the-hash techniques

Use stolen credentials

Attempt MFA bypass

Create network tunnels

Bypass segmentation

Perform VLAN hopping

Exploit databases

Extract sensitive data

Modify systems

Disable controls

Perform denial-of-service testing

Represent hypothetical compromise as proven compromise

The professional rule is:

Model the path from validated evidence without turning analysis into unnecessary exploitation.

Troubleshooting

I Have Only One Validated Finding

That is acceptable.

Build a short attack-path model and document which controls prevent further progression.

Attack-path analysis does not require many vulnerabilities.

I Can Reach a Management Service but Have No Credential

Record:

Management Surface Reachable:
Confirmed

Authentication Bypass:
Not Demonstrated

Progression:
Conditional

Do not guess passwords.

Scanner Says a Host Is Vulnerable

Use the result only if it passed Lab 06 validation.

Otherwise classify it as:

Potential path condition — not validated.

Several Findings Appear to Be the Same Problem

Look for a root cause such as:

Weak segmentation

or:

Excessive authorization

Attack-path analysis should consolidate related symptoms.

Path Requires Too Many Assumptions

Lower its confidence.

You may classify it:

Potential Attack Path

instead of validated attack path.

A Firewall Blocks the Path

That is valuable.

Document:

Path Interrupted

and identify the firewall/segmentation control as a positive defense where supported by evidence.

Evidence Requirements

Capture:

Evidence 01

Scope confirmation.

Evidence 02

Evidence Source Register.

Evidence 03

Entry Point Register.

Evidence 04

Asset Criticality Register.

Evidence 05

Trust Relationship Register.

Evidence 06

Management Exposure Register.

Evidence 07

Authentication Weakness Register.

Evidence 08

Permission Weakness Register.

Evidence 09

Validated Vulnerability Register.

Evidence 10

Attack-Path Building Blocks.

Evidence 11

Attack Path 01.

Evidence 12

Attack Path 02.

Evidence 13

Attack Path 03.

Evidence 14

Assumption Register.

Evidence 15

Preconditions Matrix.

Evidence 16

Chokepoint Register.

Evidence 17

Control-Break Matrix.

Evidence 18

Compensating Control Register.

Evidence 19

Attack-Path Risk Matrix.

Evidence 20

Path Confidence Register.

Evidence 21

Attack-Path Diagrams.

Evidence 22

Broken Path Register.

Evidence 23

Control Effectiveness Matrix.

Evidence 24

Root Cause Register.

Evidence 25

Attack-Path Findings Register.

Evidence 26

Remediation Priority Register.

Evidence 27

Final Attack-Path Summary.

Evidence 28

Mission Challenge worksheet.

Mission Deliverables

Complete:

• scope revalidated

• evidence from Labs 02–12 imported

• entry points identified

• starting assumptions documented

• high-value assets identified

• asset criticality assigned

• trust relationships documented

• excessive trust identified

• management exposure mapped

• authentication weaknesses imported

• permission weaknesses imported

• only validated vulnerabilities used

• attack-path building blocks created

• at least three meaningful paths evaluated where environment supports them

• confirmed conditions separated from assumptions

• path prerequisites documented

• chokepoints identified

• attack-breaking controls identified

• compensating controls documented

• path risk assessed

• confidence assessed separately

• broken paths documented

• positive security controls documented

• root causes identified

• findings consolidated appropriately

• remediation priorities ranked

• attack-path diagrams completed

• final Network Attack-Path Summary completed

• final report completed

Lab Report Template

# Lab 13 — Network Attack-Path Analysis

## Executive Summary

## Mission Objective

## Authorization and Scope

## Evidence Sources

## Assessment Assumptions

## Entry Points

## Asset Criticality

## High-Value Assets

## Trust Relationships

## Validated Vulnerabilities

## Authentication Weaknesses

## Authorization Weaknesses

## Segmentation Gaps

## Management-Plane Exposure

## Attack-Path Methodology

## Attack Path AP-01

### Entry Point
### Confirmed Conditions
### Conditional Conditions
### Target
### Potential Impact
### Control Break
### Risk
### Confidence

## Attack Path AP-02

## Attack Path AP-03

## Broken Attack Paths

## Existing Security Controls

## Chokepoint Analysis

## Root Cause Analysis

## Attack-Path Risk Matrix

## Validated Path Findings

## Remediation Priorities

## Retest Criteria

## Limitations

## Conclusion

Knowledge Check

Question 1 — What is an attack path?

A sequence of validated or clearly stated conditional security relationships that could allow an attacker to progress from an initial position toward a more valuable asset.

Question 2 — Does a reachable SSH service prove the attacker can compromise the server?

No.

It proves network access to the SSH authentication surface.

Question 3 — Why distinguish confirmed conditions from assumptions?

Because it prevents hypothetical attack progression from being reported as proven compromise.

Question 4 — What is a chokepoint?

A security control or network boundary that affects multiple potential attack paths.

Question 5 — Why can a medium-severity finding become important in an attack path?

Because it may connect an attacker to a much more valuable asset or enable another weakness.

Question 6 — What is an attack-path break?

A security control that prevents progression to the next step in the modeled path.

Question 7 — Why are shortest paths important?

They often require fewer conditions or security-control failures before reaching a valuable target.

Question 8 — Should scanner findings automatically be placed into attack paths?

No.

Use validated findings or clearly classify unvalidated conditions as hypothetical.

Question 9 — Why document broken attack paths?

They show which existing controls materially reduce attacker reach.

Question 10 — What is the central question of this lab?

If one authorized lab system were compromised, which validated network relationships and weaknesses could increase attacker reach, and which security controls should be strengthened first to break those paths?

Skills Achieved

After completing this lab, you should understand:

• attack-path modeling

• entry-point analysis

• high-value asset identification

• trust relationships

• management-plane exposure

• segmentation-gap correlation

• authentication-path analysis

• authorization-path analysis

• vulnerability correlation

• evidence-based attack chains

• confirmed vs conditional steps

• attack-path preconditions

• chokepoint identification

• control-break analysis

• compensating controls

• broken-path analysis

• root-cause identification

• attack-path risk prioritization

• remediation prioritization

• professional attack-path reporting

Professional Takeaway

A weak attack-path assessment looks like:

Port Open
   ↓
Vulnerability Found
   ↓
Assume Server Compromised
   ↓
Assume Credentials Stolen
   ↓
Assume Domain Compromised

That is not defensible.

A professional assessment looks like:

Starting Assumption
      ↓
Validated Reachability
      ↓
Validated Weakness
      ↓
Confirmed Trust Relationship
      ↓
Conditional Progression
      ↓
High-Value Asset
      ↓
Business Impact
      ↓
Breaking Control

Always distinguish:

Service Reachable
      ≠
Service Compromised

Vulnerability Present
      ≠
Exploit Succeeded

Server Reachable
      ≠
Server Access Obtained

Credential Required
      ≠
Credential Available

Network Trust
      ≠
Authentication Bypass

Potential Path
      ≠
Validated Compromise Chain

High CVSS
      ≠
Most Important Attack Path

And remember the most valuable question is often not:

“Which vulnerability has the highest score?”

It is:

“Which control, if fixed, removes the greatest number of realistic paths to our most important assets?”

What’s Next?

➡️ Lab 14 — Vulnerability Validation & Pentest Reporting

In the next lab, you will turn the technical evidence collected across the assessment into professional penetration-testing findings and a defensible client-style report.

You will work with:

• evidence validation

• finding quality

• observation vs vulnerability

• duplicate findings

• root-cause consolidation

• severity and confidence

• technical impact

• business impact

• remediation

• retest criteria

• executive summaries

• attack-path context

• positive controls

• report quality assurance

The methodology becomes:

Evidence → Validation → Finding → Risk → Business Context → Remediation → Retest → Report

The central question will be:

“Can every reported security finding be defended with evidence, explained in business context, remediated clearly, and independently retested?”