Lab 01 — Active Directory Attacks

Welcome to the first practical lab in the OffSec Labs section.

In this lab, you will assess a deliberately vulnerable Active Directory training environment from the perspective of an authorized penetration tester.

The objective is not simply to run attack tools.

You will learn to think in terms of:

IDENTITY
   ↓
PERMISSIONS
   ↓
RELATIONSHIPS
   ↓
MISCONFIGURATIONS
   ↓
ATTACK PATHS
   ↓
BUSINESS IMPACT

This is one of the most important concepts in modern enterprise penetration testing.

Perform every activity only inside the GoHackersCloud lab, your own isolated Active Directory environment, or another environment where you have explicit authorization.

Mission Information

Lab: 01 — Active Directory Attacks
Track: OffSec Labs
Difficulty: Intermediate → Advanced
Estimated Time: 3–5 Hours
Environment: Isolated Windows Active Directory Lab
Primary Role: Penetration Tester / Security Consultant
Focus: Active Directory Security Assessment
Deliverable: Active Directory Penetration Test Report

Mission Scenario

You have joined an authorized internal penetration test for a fictional organization:

NovaTech Industries

The organization operates a Windows domain:

corp.novatech.local

The security team wants to understand whether ordinary domain access could lead to unintended administrative privileges.

Your mission is to identify:

Weak Identity Controls

Excessive Group Membership

Authentication Exposure

Service Account Risks

Delegation Issues

ACL Misconfigurations

Privilege Relationships

Potential Attack Paths

You must document each finding and explain how the organization should remediate it.

Lab Architecture

Build or use an isolated environment similar to:

                    LAB NETWORK
                  10.10.10.0/24

                         |
              +----------+----------+
              |                     |
              v                     v
       +-------------+       +-------------+
       |    DC01     |       |    SRV01    |
       |-------------|       |-------------|
       | Domain      |       | Member      |
       | Controller  |       | Server      |
       | DNS         |       | File/App    |
       +-------------+       +-------------+
              |
              |
              v
       +-------------+
       |    WS01     |
       |-------------|
       | Windows     |
       | Workstation |
       +-------------+

              ^
              |
       +-------------+
       | Pentest VM  |
       |-------------|
       | Authorized  |
       | Lab System  |
       +-------------+

Example lab systems:

System	Role
DC01	Domain Controller
SRV01	Member Server
WS01	Workstation
Pentest VM	Security Testing Workstation

Learning Objectives

By completing this lab, you should be able to:

• Understand an Active Directory environment before testing it
• Identify the domain and Domain Controller
• Enumerate domain users
• Enumerate groups and privileged memberships
• Identify computers and servers
• Understand Kerberos and NTLM exposure
• Analyze service accounts
• Review password and account policies
• Identify dangerous permissions
• Analyze delegation
• Build identity attack paths
• Assess local administrator exposure
• Validate privilege relationships safely
• Collect professional evidence
• Translate technical weaknesses into remediation

Prerequisites

You should already understand:

Windows Fundamentals

TCP/IP

DNS

SMB

LDAP

Kerberos Basics

NTLM Basics

Users and Groups

Windows Permissions

PowerShell Fundamentals

Penetration Testing Methodology

Active Directory Refresher

Active Directory provides centralized:

Authentication

Authorization

Identity Management

Computer Management

Policy Management

Resource Access

A simplified structure is:

FOREST
   ↓
DOMAIN
   ↓
ORGANIZATIONAL UNITS
   ↓
USERS
GROUPS
COMPUTERS
SERVICES

Why Active Directory Is Security Critical

Active Directory frequently controls access to:

Employee Accounts

Servers

Workstations

Applications

File Shares

Administrative Systems

Cloud Integrations

Security Infrastructure

A single identity misconfiguration can therefore create a much larger enterprise attack path.

The AD Attack-Path Mindset

Do not think only in terms of:

Can I Compromise DC01?

Think:

What Access Do I Have?
        ↓
What Can This Identity Reach?
        ↓
Which Permissions Does It Have?
        ↓
Which Other Identities Can It Influence?
        ↓
Can Those Identities Influence Others?
        ↓
Does the Chain Reach a Privileged Asset?

This is the central concept of the lab.

Phase 01 — Confirm Authorization

Before touching the environment, record:

Client / Lab:

Assessment Name:

Authorized Domain:

Authorized IP Range:

Testing Window:

Allowed Techniques:

Restricted Systems:

Evidence Location:

Cleanup Requirements:

Example:

Domain:
corp.novatech.local

Authorized Range:
10.10.10.0/24

Environment:
Training Lab

Objective:
Assess Active Directory privilege relationships.

Phase 02 — Create Your Evidence Folder

Create a structured workspace:

AD-Lab/
|
+-- 01-Scope/
|
+-- 02-Recon/
|
+-- 03-Users/
|
+-- 04-Groups/
|
+-- 05-Computers/
|
+-- 06-Kerberos/
|
+-- 07-ACLs/
|
+-- 08-Attack-Paths/
|
+-- 09-Evidence/
|
+-- 10-Report/

For every important observation record:

Timestamp

System

Account

Command / Method

Observation

Security Significance

Evidence

Recommended Next Step

Phase 03 — Establish the Current Identity

From an authorized Windows lab workstation:

whoami

Then:

whoami /all

Review:

Username

Domain

Groups

Privileges

Integrity Level

Record your initial security context.

Why This Matters

Before testing privileges, you need to know:

WHO AM I?

because every later finding depends on the permissions associated with that identity.

Phase 04 — Identify the Domain

From Windows:

$env:USERDOMAIN

You can also review:

$env:USERDNSDOMAIN

Record:

Domain Name

DNS Domain

Current User

Current Workstation

Phase 05 — Identify the Domain Controller

In the authorized Windows lab:

nltest /dsgetdc:corp.novatech.local

You may also review DNS:

nslookup corp.novatech.local

Document:

Domain Controller

IP Address

DNS Information

Domain Name

Phase 06 — Understand Important AD Services

Common services include:

Service	Typical Purpose
DNS	Domain/service discovery
Kerberos	Authentication
LDAP	Directory access
LDAPS	Protected directory access
SMB	Windows file/resource access
RPC	Windows service communication

Your objective is not to attack every open service.

Ask:

What Does This Service Tell Me
About the Environment?

Phase 07 — Enumerate Domain Users

From an authorized domain workstation:

net user /domain

Record interesting categories:

Standard Users

Administrators

Service Accounts

Helpdesk Accounts

Backup Accounts

Application Accounts

Create a simple table:

User	Type	Privileged?	Notes
alice	Employee	No	Standard user
svc_backup	Service	Unknown	Review
helpdesk01	Admin support	Possibly	Review groups

Phase 08 — Enumerate Groups

Run:

net group /domain

Look for groups associated with:

Administration

Server Management

Backup

Helpdesk

Remote Access

Application Administration

Phase 09 — Review Domain Admins

In the lab:

net group "Domain Admins" /domain

Document:

Direct Members

Unexpected Members

Service Accounts

Shared Accounts

The key question is:

Who Has Administrative
Control of the Domain?

Phase 10 — Review Other Privileged Groups

Do not stop with Domain Admins.

Review groups such as:

Enterprise Admins

Administrators

Account Operators

Backup Operators

Server Operators

depending on your lab design.

The important lesson is:

PRIVILEGE
IS NOT ALWAYS
DOMAIN ADMINS

Phase 11 — Investigate Nested Groups

An account may receive privilege indirectly.

Example:

Alice
  ↓
IT Support
  ↓
Server Administrators
  ↓
Privileged Server

Alice may not appear obviously privileged when reviewing only her direct memberships.

This is why relationship analysis matters.

Phase 12 — Review the Current User’s Group Membership

Use:

whoami /groups

Ask:

Which Groups Do I Belong To?

Are Any Nested?

What Resources Do They Control?

Can Any Group Modify Another Group?

Phase 13 — Enumerate Computers

From the domain environment, identify:

Domain Controllers

Member Servers

Workstations

Administrative Systems

If the ActiveDirectory PowerShell module is available:

Get-ADComputer -Filter * |
Select-Object Name, OperatingSystem

Do not assume every environment has this module installed.

Phase 14 — Build an Asset Classification

Classify discovered systems:

Asset	Type	Importance
DC01	Domain Controller	Critical
SRV01	Application Server	High
FILE01	File Server	High
WS01	Workstation	Normal

This helps prioritize attack-path analysis.

Phase 15 — Review Domain Password Policy

Where permitted:

net accounts /domain

Review:

Minimum Password Length

Password History

Maximum Password Age

Minimum Password Age

Lockout Threshold

Lockout Duration

Security Questions

Ask:

Are Weak Passwords Easier to Maintain?

Is Lockout Configured?

Could Service Accounts Retain
Passwords for Long Periods?

Are Privileged Accounts Subject
to Stronger Controls?

Phase 16 — Identify Service Accounts

Look for naming patterns such as:

svc_

service_

sql_

backup_

app_

But do not rely only on names.

A normal-looking account may also be used by a service.

Document:

Account

Purpose

Group Membership

Privilege

Password Management

Service Relationship

Phase 17 — Understand Service Account Risk

Service accounts often create risk because they may have:

Long-Lived Passwords

Excessive Privileges

Interactive Logon Rights

Multiple Server Access

Application Dependencies

A better model is:

SERVICE ACCOUNT
      ↓
BUSINESS SERVICE
      ↓
ACCESS RIGHTS
      ↓
SERVER / DATA

Phase 18 — Understand Kerberos

A simplified authentication flow is:

USER
 ↓
DOMAIN CONTROLLER
 ↓
KERBEROS
 ↓
SERVICE TICKET
 ↓
APPLICATION

Important concepts include:

KDC

TGT

Service Ticket

SPN

Service Account

Phase 19 — Review Kerberos Tickets

On your authorized Windows workstation:

klist

Observe:

Ticket Types

Service Names

Domain

Expiration

Do not treat tickets as merely attack artifacts.

They are evidence of:

Which Services
the Identity Has Accessed

Phase 20 — Understand SPNs

A Service Principal Name associates a service instance with an identity.

Conceptually:

SERVICE
   ↓
SPN
   ↓
ACCOUNT

Examples of services might include:

Web Application

Database

File Service

Custom Enterprise Application

Phase 21 — Review Service Principal Names

Where the ActiveDirectory module is available:

Get-ADUser -Filter {ServicePrincipalName -like "*"} `
-Properties ServicePrincipalName |
Select-Object SamAccountName, ServicePrincipalName

Document:

Account

Service

Privilege

Password Governance

Business Importance

Phase 22 — Understand Kerberos Service Account Exposure

The important security question is not simply:

Does an SPN Exist?

Ask:

Is the Service Account Highly Privileged?

Is Its Password Properly Managed?

Is the Account Used Interactively?

Is It a Member of Sensitive Groups?

Could a Managed Service Account
Be Used Instead?

Phase 23 — Review Accounts with Unusual Authentication Configuration

In an authorized training domain, review account configuration for exceptions or legacy settings.

Focus on identifying:

Authentication Exceptions

Legacy Requirements

Weak Service Configurations

Unnecessary Compatibility Settings

Do not immediately exploit them.

First understand:

WHY DOES THIS CONFIGURATION EXIST?

Phase 24 — Understand LDAP

LDAP provides access to directory information.

Conceptually:

CLIENT
  ↓
LDAP
  ↓
ACTIVE DIRECTORY
  ↓
DIRECTORY OBJECTS

Directory objects may include:

Users

Groups

Computers

Organizational Units

Policies

Service Accounts

Phase 25 — Understand AD Objects

Think of Active Directory as a graph of objects:

USER
 |
 +-- MemberOf --> GROUP
 |
 +-- Permission --> COMPUTER
 |
 +-- Permission --> GROUP
 |
 +-- Permission --> USER

This graph model is essential for identifying complex attack paths.

Phase 26 — Understand ACLs

Active Directory objects have access-control information defining:

Who

can perform:

What Action

against:

Which Object

Conceptually:

IDENTITY
    ↓
PERMISSION
    ↓
OBJECT

Phase 27 — Review Object Permissions

Where the ActiveDirectory module is available, you can inspect directory objects and their security descriptors using authorized administrative tooling.

For example:

Get-ADUser alice

Then investigate the object’s permissions using the lab’s approved AD administration tools.

Focus on relationships such as:

User A
Can Modify
User B

or:

Group A
Can Modify
Group B

Phase 28 — Understand Dangerous Permission Relationships

Examples of relationships that deserve review include the ability to:

Modify Group Membership

Reset Another User's Password

Modify Object Permissions

Change Ownership

Control a Computer Object

Modify Sensitive Attributes

The security issue is often:

LOW-PRIVILEGE IDENTITY
        ↓
POWERFUL DIRECTORY PERMISSION
        ↓
PRIVILEGED OBJECT

Phase 29 — Build a Permission Graph

Example:

analyst01
    |
    | MemberOf
    v
Helpdesk
    |
    | Can Manage
    v
ServerAdmins
    |
    | Administrative Access
    v
SRV01

Now you have an attack path.

Phase 30 — Understand Attack Paths

An attack path is a chain of security relationships.

Example:

USER
 ↓
GROUP
 ↓
PERMISSION
 ↓
ACCOUNT
 ↓
SERVER
 ↓
ADMINISTRATIVE ROLE

No individual relationship may appear critical.

The combination can be critical.

Phase 31 — Analyze Paths, Not Just Vulnerabilities

Traditional finding:

Helpdesk Group
Has Excessive Permission

Better finding:

Helpdesk Group
       ↓
Can Modify ServerAdmins
       ↓
ServerAdmins Controls SRV01
       ↓
SRV01 Hosts Sensitive Application

Now the business impact is much clearer.

Phase 32 — Review Local Administrators

On an authorized Windows lab system:

Get-LocalGroupMember Administrators

or:

net localgroup administrators

Record:

Local Users

Domain Users

Domain Groups

Service Accounts

Phase 33 — Identify Administrative Overlap

Suppose:

ITSupport

is local administrator on:

WS01
WS02
SRV01

This creates a wider privilege relationship than necessary.

Ask:

Does This Group
Actually Need Administration
Across All Three Systems?

Phase 34 — Review Remote Access Exposure

Assess which identities can remotely access systems through approved mechanisms.

Look for:

Remote Desktop Users

Administrative Groups

Server Management Groups

Support Groups

Document unnecessary access.

Phase 35 — Understand Lateral Movement Risk

Conceptually:

USER
 ↓
WORKSTATION
 ↓
SERVER
 ↓
ADMINISTRATIVE SYSTEM

Lateral movement becomes possible when:

Credentials

Permissions

Administrative Relationships

Trust

overlap unnecessarily.

In this lab, map the relationship rather than attempting uncontrolled movement.

Phase 36 — Review Shared Resources

From an authorized Windows system:

net view

For a known lab server:

net view \\SRV01

Review:

Shared Folders

Purpose

Permissions

Sensitive Data Exposure

Phase 37 — Assess Share Permissions

For each discovered share ask:

Who Can Read?

Who Can Write?

Who Owns It?

Does It Contain Sensitive Data?

Does It Contain Configuration?

Are Permissions Business-Justified?

Phase 38 — Sensitive Information Review

In the controlled training environment, inspect only authorized shares.

Look for intentionally planted examples such as:

Configuration Files

Deployment Scripts

Documentation

Backup Files

Old Administration Notes

Do not collect more data than required to demonstrate the finding.

Phase 39 — Evidence Minimization

If sensitive information is found:

DO NOT:
Copy everything.

Instead:

Capture the minimum evidence
necessary to prove the issue.

Professional penetration testing requires responsible evidence handling.

Phase 40 — Review Group Policy

Group Policy can control:

Security Settings

Authentication

Firewall

Scripts

Software

User Configuration

Computer Configuration

Where authorized and available:

gpresult /r

Review which policies affect the workstation.

Phase 41 — Security Baseline Questions

Ask:

Are Security Policies Consistent?

Are Administrative Settings Centralized?

Are Legacy Exceptions Present?

Are Important Systems Receiving
the Expected Policies?

Phase 42 — Review Delegation Conceptually

Delegation allows services to act in certain contexts on behalf of users.

Incorrect delegation configuration can create dangerous privilege relationships.

Review:

Which Accounts Use Delegation?

Which Computers Use Delegation?

Why Is It Required?

What Systems Are Reachable?

Is the Scope Broader Than Necessary?

Phase 43 — Review Trust Relationships

Large environments may contain multiple domains or forests.

Conceptually:

DOMAIN A
   ↓
TRUST
   ↓
DOMAIN B

A trust does not automatically mean compromise.

But it changes:

Authentication Relationships

Authorization Boundaries

Attack Surface

Phase 44 — Understand Privileged Sessions

Administrative users may authenticate to multiple systems.

This can create risk when privileged identities use lower-trust endpoints.

Conceptually:

DOMAIN ADMIN
     ↓
WORKSTATION

may expose a more sensitive identity to a less trusted system.

Phase 45 — Apply Administrative Tiering

A stronger design separates:

Tier 0
Domain / Identity Infrastructure

Tier 1
Servers / Applications

Tier 2
Workstations / End Users

Privileged identities should not move freely across every tier.

Phase 46 — Build Your AD Attack Graph

Create a diagram from your findings.

Example:

analyst01
    |
    | MemberOf
    v
Helpdesk
    |
    | Excessive Permission
    v
ServerAdmins
    |
    | AdminTo
    v
SRV01
    |
    | Sensitive Application
    v
Business Data

Phase 47 — Prioritize Paths

Rank discovered paths:

CRITICAL

HIGH

MEDIUM

LOW

Consider:

Starting Privilege

Number of Relationships

Reliability

Target Importance

Existing Security Controls

Business Impact

Phase 48 — Validate Safely

A penetration tester should validate enough to prove:

The Relationship Exists

The Permission Is Effective

The Target Is Sensitive

The Path Is Realistic

You do not need to create unnecessary business impact.

Use the minimum level of validation required.

Phase 49 — Build a Finding

Example:

Finding ID:
AD-001

Title:
Excessive Group Management Permission

Affected Object:
ServerAdmins

Source Identity:
Helpdesk

Observation:
The Helpdesk group has unnecessary
management rights over a group associated
with administration of SRV01.

Attack Path:
analyst01
→ Helpdesk
→ ServerAdmins
→ SRV01

Impact:
A compromised helpdesk identity could
potentially gain unintended administrative
control over a sensitive server.

Recommendation:
Remove unnecessary directory permissions
and implement delegated administration
using least privilege.

Phase 50 — Finding: Excessive Privileged Membership

Example:

Finding ID:
AD-002

Title:
Excessive Privileged Group Membership

Observation:
Accounts without a documented requirement
are members of a privileged administrative
group.

Impact:
Compromise of any unnecessary privileged
account increases the likelihood of
domain-level security impact.

Recommendation:
Remove unnecessary membership and
implement periodic privileged-access
reviews.

Phase 51 — Finding: Weak Service Account Governance

Example:

Finding ID:
AD-003

Title:
Weak Service Account Governance

Observation:
A service identity has broad permissions
and lacks evidence of modern password
lifecycle management.

Impact:
Compromise of the service identity could
provide access beyond the requirements
of the associated application.

Recommendation:
Reduce privileges and evaluate managed
service-account capabilities where
appropriate.

Phase 52 — Finding: Excessive Local Administration

Example:

Finding ID:
AD-004

Title:
Broad Local Administrator Assignment

Observation:
A domain support group is configured as
local administrator across systems with
different security classifications.

Impact:
Compromise of a support identity could
increase lateral movement opportunities.

Recommendation:
Limit administrative access according to
system responsibility and administrative
tier.

Phase 53 — Finding: Excessive Share Permissions

Example:

Finding ID:
AD-005

Title:
Overly Permissive File Share

Observation:
A domain-wide group can access information
that should be limited to administrators.

Impact:
Sensitive operational information may be
available to unnecessary identities.

Recommendation:
Apply least-privilege share and NTFS
permissions and perform recurring access
reviews.

Phase 54 — Build a Risk Matrix

Finding	Likelihood	Impact	Priority
Dangerous ACL path	High	Critical	Critical
Excessive admin membership	High	Critical	Critical
Service account weakness	Medium	High	High
Broad local admin	Medium	High	High
Share permissions	Medium	Medium	Medium

Phase 55 — Recommend Identity Hardening

Consider:

Least Privilege

Privileged Access Separation

Administrative Tiering

Dedicated Admin Accounts

Managed Service Accounts

Strong Authentication

Privileged Access Workstations

Periodic Access Reviews

Phase 56 — Recommend Kerberos Hardening

Review:

Service Account Privileges

Service Account Password Management

Legacy Authentication

Delegation

SPN Ownership

Administrative Service Accounts

Phase 57 — Recommend Local Administrator Hardening

Consider:

Unique Local Credentials

Windows LAPS

Restricted Admin Groups

Endpoint Privilege Management

Administrative Tiering

Phase 58 — Recommend AD Monitoring

Important identity events may include:

Account Creation

Account Deletion

Group Membership Changes

Password Resets

Account Lockouts

Privilege Changes

Authentication Failures

Policy Changes

Useful Windows Security Events

Examples include:

Event	Purpose
4624	Successful logon
4625	Failed logon
4720	User created
4726	User deleted
4728	Member added to global group
4732	Member added to local group
4738	User account changed
4740	Account locked
4756	Member added to universal group
4768	Kerberos TGT requested
4769	Kerberos service ticket requested

The SOC should correlate these events rather than evaluate them individually.

Phase 59 — Cleanup

At the end of the authorized lab:

Remove Temporary Files

Remove Test Accounts If Created

Revert Test Changes

Remove Temporary Group Membership

Close Test Sessions

Secure Evidence

Restore VM Snapshots If Required

Never leave a training environment in an unknown state.

Phase 60 — Final Report

Your report should contain:

Executive Summary

Scope

Rules of Engagement

Environment

Methodology

Identity Assessment

Group Assessment

Authentication Assessment

ACL Assessment

Attack-Path Analysis

Findings

Evidence

Risk Ratings

Recommendations

Cleanup Confirmation

Conclusion

Executive Summary Example

The Active Directory assessment identified
multiple identity and authorization
relationships that could allow a
lower-privileged domain identity to gain
access beyond its intended role.

The most significant risks involved
excessive directory permissions,
unnecessary privileged membership,
service-account governance, and broad
administrative relationships.

The primary remediation priority is to
reduce identity privilege, remove
unnecessary control relationships, and
implement stronger privileged-access
governance.

Student Deliverables

Complete all of the following:

• Scope document
• Domain architecture diagram
• User inventory
• Group inventory
• Privileged membership review
• Computer inventory
• Password-policy assessment
• Service-account assessment
• Kerberos assessment
• ACL assessment
• Local administrator assessment
• Share-permission assessment
• Delegation review
• Attack-path diagram
• Risk matrix
• Findings register
• Remediation plan
• Final penetration test report
• Cleanup confirmation

Attack-Path Worksheet

For every important path complete:

Path ID:

Starting Identity:

Initial Privilege:

Relationship 01:

Relationship 02:

Relationship 03:

Target:

Target Importance:

Required Conditions:

Existing Controls:

Potential Impact:

Evidence:

Recommended Remediation:

AD Finding Worksheet

Finding ID:

Title:

Affected Object:

Affected Identity:

Description:

Evidence:

Attack Path:

Security Impact:

Likelihood:

Severity:

Recommendation:

Retest Procedure:

Active Directory Pentest Mental Model

Use this throughout the lab:

SCOPE
  ↓
IDENTITY
  ↓
DOMAIN
  ↓
USERS
  ↓
GROUPS
  ↓
COMPUTERS
  ↓
AUTHENTICATION
  ↓
SERVICE ACCOUNTS
  ↓
PERMISSIONS
  ↓
DELEGATION
  ↓
LOCAL ADMINISTRATION
  ↓
SHARES
  ↓
ATTACK PATHS
  ↓
VALIDATION
  ↓
EVIDENCE
  ↓
RISK
  ↓
REMEDIATION
  ↓
RETEST

Common Mistakes

Avoid:

Immediately Trying Exploits

Ignoring Scope

Only Looking at Domain Admins

Ignoring Nested Groups

Ignoring ACLs

Ignoring Service Accounts

Ignoring Local Administrators

Ignoring Delegation

Treating Every Misconfiguration
as Critical

Collecting Excessive Sensitive Data

Failing to Document Evidence

Ignoring Cleanup

Reporting Without Remediation

Interview Questions

1. What is Active Directory?
2. What is a domain?
3. What is a forest?
4. What is a Domain Controller?
5. Why is DNS important to Active Directory?
6. What is LDAP?
7. What is Kerberos?
8. What is NTLM?
9. What is a TGT?
10. What is a Kerberos service ticket?
11. What is an SPN?
12. Why are service accounts security-sensitive?
13. What is an Active Directory ACL?
14. What is an ACE?
15. Why are nested groups important?
16. What is an Active Directory attack path?
17. Why is Domain Admin membership not the only indicator of privilege?
18. What is delegation?
19. What is administrative tiering?
20. What is lateral movement?
21. Why is local administrator reuse risky?
22. What is Windows LAPS?
23. What is privileged access separation?
24. Why should administrators use separate accounts?
25. Why are file shares important during an assessment?
26. What is least privilege?
27. Why should service accounts avoid unnecessary interactive logon?
28. What is attack-path analysis?
29. Why should penetration testers minimize collected evidence?
30. Why is cleanup part of a professional penetration test?
31. What does Windows event 4624 represent?
32. What does event 4625 represent?
33. What does event 4740 represent?
34. What does event 4768 represent?
35. What does event 4769 represent?
36. How would you prioritize an AD security finding?
37. What makes an ACL relationship dangerous?
38. How would you remediate excessive privileged membership?
39. How would you reduce lateral-movement opportunities?
40. What should an Active Directory penetration test report contain?

Lab Completion Checklist

Environment

• Authorization confirmed
• Scope documented
• Lab isolated
• Evidence location prepared
• VM snapshots available

Discovery

• Current identity identified
• Domain identified
• Domain Controller identified
• Important AD services understood
• Systems classified

Identity

• Users enumerated
• Groups reviewed
• Privileged groups reviewed
• Nested memberships analyzed
• Service accounts identified

Authentication

• Password policy reviewed
• Kerberos concepts validated
• Service identities reviewed
• Authentication exceptions documented
• Legacy risks identified

Authorization

• ACL relationships reviewed
• Group-management permissions reviewed
• Local administrators reviewed
• Remote access reviewed
• Delegation reviewed

Resources

• Shares reviewed
• Permissions assessed
• Sensitive information exposure assessed
• Evidence minimized

Attack Paths

• Identity relationships mapped
• Privilege paths documented
• Critical assets identified
• Paths prioritized
• Findings validated safely

Reporting

• Evidence organized
• Risk matrix completed
• Findings documented
• Recommendations written
• Attack-path diagram created
• Final report completed
• Cleanup confirmed

Final Lab Outcome

By completing this lab, you should understand that Active Directory penetration testing is not simply:

SCAN
 ↓
EXPLOIT
 ↓
ADMIN

A professional methodology is:

UNDERSTAND THE DOMAIN
        ↓
UNDERSTAND THE IDENTITY
        ↓
MAP USERS
        ↓
MAP GROUPS
        ↓
MAP COMPUTERS
        ↓
UNDERSTAND AUTHENTICATION
        ↓
MAP PERMISSIONS
        ↓
MAP ADMINISTRATIVE RELATIONSHIPS
        ↓
BUILD ATTACK PATHS
        ↓
VALIDATE SAFELY
        ↓
MEASURE BUSINESS IMPACT
        ↓
REMEDIATE
        ↓
RETEST

The most important lesson is:

Active Directory Security
Is Relationship Security

A seemingly ordinary identity can become highly significant when:

USER
  ↓
GROUP
  ↓
ACL
  ↓
SERVICE ACCOUNT
  ↓
SERVER
  ↓
PRIVILEGED IDENTITY

relationships are combined.

Your job as a penetration tester is therefore not simply to find a vulnerable account.

Your job is to explain:

Where the Path Starts

Why the Path Exists

Which Relationships Enable It

What Business Asset It Reaches

How the Organization Can Break the Path

What’s Next?

➡️ Lab 02 — Enterprise Pentesting

In the next lab, you will expand from an identity-focused Active Directory assessment into a broader enterprise penetration-testing scenario.

You will work through:

SCOPE
  ↓
NETWORK DISCOVERY
  ↓
ASSET CLASSIFICATION
  ↓
SERVICE ENUMERATION
  ↓
APPLICATION ANALYSIS
  ↓
WINDOWS / LINUX ASSESSMENT
  ↓
IDENTITY ANALYSIS
  ↓
ACTIVE DIRECTORY
  ↓
SEGMENTATION
  ↓
ATTACK-PATH MAPPING
  ↓
CONTROLLED VALIDATION
  ↓
EVIDENCE
  ↓
REPORTING

The goal will be to understand how multiple weaknesses across network, endpoint, application, and identity layers can combine into an enterprise security risk.