Runbook 01 — Active Directory Pentest

Active Directory remains one of the most important security components in enterprise environments.

It commonly controls:

Users

Computers

Authentication

Authorization

Administrative Access

Group Membership

Service Accounts

Enterprise Applications

File Servers

Windows Servers

Security Policies

Trust Relationships

A weakness in Active Directory can therefore affect much more than a single account or server.

The purpose of this runbook is to provide a repeatable methodology for conducting an authorized Active Directory penetration test.

Use this runbook only in the GoHackersCloud lab, systems you own, purpose-built security training environments, or environments where you have explicit authorization.

Runbook Information

Runbook: 01 — Active Directory Pentest
Track: OffSec
Category: Penetration Testing Runbook
Difficulty: Intermediate → Advanced
Primary Role: Penetration Tester / Security Consultant
Environment: Enterprise Windows / Active Directory
Primary Goal: Identify Active Directory security weaknesses and privilege relationships
Primary Deliverable: Active Directory Penetration Testing Report

When to Use This Runbook

Use this runbook when performing:

Internal Penetration Testing

Active Directory Security Assessment

Identity Security Review

Enterprise Security Assessment

Purple Team Validation

Security Architecture Review

Post-Compromise Impact Analysis

Privilege Path Assessment

Active Directory Pentest Workflow

Use the following sequence:

AUTHORIZE
    ↓
UNDERSTAND THE ENVIRONMENT
    ↓
IDENTIFY DOMAIN CONTEXT
    ↓
DISCOVER DOMAIN CONTROLLERS
    ↓
MAP USERS
    ↓
MAP GROUPS
    ↓
MAP COMPUTERS
    ↓
REVIEW AUTHENTICATION
    ↓
REVIEW SERVICE ACCOUNTS
    ↓
REVIEW PERMISSIONS
    ↓
REVIEW DELEGATION
    ↓
REVIEW GROUP POLICY
    ↓
REVIEW TRUSTS
    ↓
MAP ADMINISTRATIVE RELATIONSHIPS
    ↓
BUILD ATTACK PATHS
    ↓
VALIDATE SAFELY
    ↓
COLLECT EVIDENCE
    ↓
ASSESS BUSINESS IMPACT
    ↓
RECOMMEND REMEDIATION
    ↓
RETEST

01 — Confirm Authorization

Before performing any technical activity, confirm:

Who Authorized the Assessment?

Which Domain Is In Scope?

Which Forests Are In Scope?

Which Domain Controllers Are In Scope?

Which Workstations Are In Scope?

Which Servers Are In Scope?

Which Test Accounts Are Provided?

Which Techniques Are Allowed?

Which Activities Are Prohibited?

What Is the Testing Window?

Who Is the Emergency Contact?

Scope Record

Document:

Customer / Lab:

Assessment Name:

Domain:

Forest:

Authorized Networks:

Authorized Systems:

Authorized Accounts:

Excluded Systems:

Allowed Techniques:

Restricted Techniques:

Testing Window:

Emergency Contact:

Cleanup Requirements:

02 — Establish Rules of Engagement

Define allowed activities such as:

Domain Enumeration

User Enumeration

Group Enumeration

Computer Enumeration

Permission Analysis

Authentication Review

Group Policy Review

Service Account Review

Trust Analysis

Attack-Path Mapping

Controlled Validation

Avoid unless specifically authorized:

Destructive Testing

Service Disruption

Account Lockout Testing

Mass Password Attempts

Persistence

Production Credential Extraction

Malware Deployment

Security-Control Evasion

03 — Prepare the Evidence Workspace

Create:

AD-Pentest/
|
+-- 01-Scope/
|
+-- 02-Domain/
|
+-- 03-Users/
|
+-- 04-Groups/
|
+-- 05-Computers/
|
+-- 06-Authentication/
|
+-- 07-Service-Accounts/
|
+-- 08-Permissions/
|
+-- 09-GPO/
|
+-- 10-Delegation/
|
+-- 11-Trusts/
|
+-- 12-Attack-Paths/
|
+-- 13-Evidence/
|
+-- 14-Findings/
|
+-- 15-Report/
|
+-- 16-Retest/

Evidence Standard

For every important observation, capture:

Timestamp

Source Host

Current Identity

Domain

Target Object

Method

Result

Security Significance

Screenshot / Output

Finding Reference

04 — Establish Current Identity

From an authorized Windows system:

whoami

Then:

whoami /all

Record:

Username

Domain

SID

Groups

Privileges

Integrity Level

05 — Identify Domain Context

Check:

$env:USERDOMAIN

and:

$env:USERDNSDOMAIN

You can also review:

systeminfo

Document:

Computer Name

Domain Name

DNS Domain

Current User

Current Groups

06 — Identify the Domain Controller

Use:

nltest /dsgetdc:<DOMAIN>

Example lab format:

nltest /dsgetdc:corp.novatech.local

Record:

Domain Controller

IP Address

Site

Domain

Forest

Authentication Services

07 — Validate DNS

Active Directory depends heavily on DNS.

Use:

nslookup <DOMAIN>

Example:

nslookup corp.novatech.local

Then identify domain controllers and related records.

Document:

DNS Servers

Domain Controllers

Internal Domains

Hostnames

08 — Build the Domain Architecture

Create a diagram:

FOREST
  |
  +-- DOMAIN
        |
        +-- DOMAIN CONTROLLERS
        |
        +-- ORGANIZATIONAL UNITS
        |
        +-- USERS
        |
        +-- GROUPS
        |
        +-- COMPUTERS
        |
        +-- SERVICE ACCOUNTS
        |
        +-- GPOs

09 — Enumerate Domain Users

Where authorized:

net user /domain

If Active Directory PowerShell tools are available:

Get-ADUser -Filter *

Build:

User	Enabled	Role	Privilege	Notes
analyst01	Yes	Analyst	Standard
helpdesk01	Yes	Support	Elevated	Review
svc_app	Yes	Service	Service	Review
admin01	Yes	Administrator	High	Critical

10 — Prioritize Interesting Accounts

Focus on:

Administrators

Help Desk

Service Accounts

Backup Accounts

Deployment Accounts

Application Accounts

Security Operations

Database Accounts

Legacy Accounts

Dormant Accounts

11 — Review User Attributes

Where authorized, inspect attributes relevant to security.

Examples:

Account Enabled

Password Settings

Group Membership

Description

ServicePrincipalName

Administrative Roles

Account Age

Password Age

Do not treat every unusual attribute as a vulnerability.

12 — Identify Disabled and Dormant Accounts

Look for:

Disabled Users

Dormant Users

Former Employee Accounts

Unused Administrative Accounts

Unused Service Accounts

Security concern:

OLD ACCOUNT
   +
UNNECESSARY PRIVILEGE
   =
UNNECESSARY ATTACK SURFACE

13 — Enumerate Domain Groups

Use:

net group /domain

or:

Get-ADGroup -Filter *

Document:

Group Name

Purpose

Members

Nested Groups

Administrative Rights

14 — Review Domain Admins

Use:

net group "Domain Admins" /domain

Record:

Direct Members

Nested Membership

Account Purpose

Business Requirement

15 — Review Other Privileged Groups

Depending on environment, review:

Enterprise Admins

Schema Admins

Administrators

Account Operators

Server Operators

Backup Operators

DNSAdmins

Group Policy Administrators

Custom Administrative Groups

Do not assume:

Not Domain Admin
=
Not Privileged

16 — Analyze Nested Group Membership

A common privilege relationship is:

USER
 ↓
GROUP A
 ↓
GROUP B
 ↓
ADMINISTRATIVE GROUP

Example:

helpdesk01
    ↓
HelpDesk
    ↓
ServerSupport
    ↓
Local Administrator

Map nested membership carefully.

17 — Build the Group Relationship Map

Create:

USER
   ↓
GROUP
   ↓
NESTED GROUP
   ↓
RESOURCE
   ↓
PERMISSION

This often reveals hidden privilege.

18 — Enumerate Computers

If AD PowerShell is available:

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

Document:

Computer	OS	Role	Criticality
DC01	Windows Server	Domain Controller	Critical
APP01	Windows Server	Application	High
FILE01	Windows Server	File Server	High
WS01	Windows	Workstation	Medium

19 — Classify Systems

Classify assets as:

Domain Controllers

Administrative Workstations

Application Servers

Database Servers

File Servers

User Workstations

Jump Servers

Management Servers

20 — Review Domain Controllers

Document:

Domain Controller Name

Operating System

Site

Network Location

Administrative Access

Security Controls

Logging

Domain controllers should receive the highest security priority.

21 — Review Authentication Architecture

Understand:

Kerberos

NTLM

LDAP

LDAPS

SMB

DNS

RPC

Conceptually:

USER
 ↓
AUTHENTICATION
 ↓
DOMAIN CONTROLLER
 ↓
ACCESS TOKEN / TICKET
 ↓
ENTERPRISE RESOURCE

22 — Review Kerberos Context

From an authenticated training system:

klist

Document:

Current Tickets

Domain

Authentication Context

The goal is to understand the environment, not to extract or forge authentication material.

23 — Review Password Policy

Use:

net accounts /domain

Document:

Minimum Length

Maximum Age

Minimum Age

Lockout Threshold

Lockout Duration

Assess the policy in context.

24 — Review Account Lockout

Ask:

Is Lockout Enabled?

Is the Threshold Appropriate?

Could Normal Users Trigger
Operational Disruption?

Are Privileged Accounts
Protected Differently?

Do not intentionally trigger lockouts without explicit authorization.

25 — Review Administrative Accounts

Determine whether administrators use:

Separate Admin Accounts

Dedicated Workstations

MFA

Privileged Access Management

Administrative Tiering

A common secure pattern is:

NORMAL ACCOUNT
      ↓
Daily Work

ADMIN ACCOUNT
      ↓
Privileged Administration

26 — Review Service Accounts

Identify accounts used by:

Windows Services

Applications

Databases

Backup Systems

Scheduled Tasks

Monitoring

Automation

If AD tools are available:

Get-ADUser -Filter {ServicePrincipalName -like "*"} `
-Properties ServicePrincipalName

27 — Build the Service Account Inventory

Account	Service	Host	Privilege	Owner	Review
svc_app	Application	APP01	Medium	App Team	Yes
svc_backup	Backup	FILE01	High	Infra	Yes

28 — Assess Service Account Governance

Review:

Privilege

Password Management

Interactive Logon

Group Membership

Host Access

Application Access

Account Ownership

Rotation

Ask:

Does This Account
Have More Access
Than Its Service Requires?

29 — Prefer Managed Service Identities

Where possible, recommend:

Managed Service Accounts

gMSA

Automatic Password Management

Restricted Host Usage

Least Privilege

30 — Review Active Directory Permissions

Active Directory objects have access control lists.

Conceptually:

IDENTITY
   ↓
PERMISSION
   ↓
AD OBJECT

Relevant permissions may include the ability to:

Read

Write

Modify Membership

Reset Password

Modify Attributes

Modify Permissions

Take Ownership

31 — Build the AD Permission Matrix

Identity	Object	Permission	Business Need	Risk
HelpDesk	Users OU	Reset Password	Yes	Medium
DevOps	Service Group	Modify Members	Review	High
LegacyAdmin	Server OU	Full Control	No	Critical

32 — Review Delegated Administration

Delegation is common and often necessary.

Review:

Help Desk Delegation

Server Administration

Password Reset Rights

Group Membership Management

OU Administration

Application Administration

The question is not:

Does Delegation Exist?

It is:

Is Delegation
Limited to What the Role Needs?

33 — Identify Excessive Delegation

Example:

HELP DESK
    ↓
Reset Password
    ↓
Privileged Administrator

If unintended, this could create a dangerous relationship.

34 — Review Object Ownership

Ownership may grant the ability to change permissions.

Map:

IDENTITY
   ↓
OWNS
   ↓
AD OBJECT

Check whether ownership aligns with business responsibilities.

35 — Review ACL Inheritance

Understand whether permissions were:

Explicit

Inherited

Nested Through Groups

Misconfigured inheritance can unintentionally spread privilege.

36 — Review Group Membership Control

Determine:

Who Can Add Members?

Who Can Remove Members?

Who Owns Privileged Groups?

Are Changes Monitored?

37 — Review Administrative Paths

An administrative path might look like:

USER
  ↓
SUPPORT GROUP
  ↓
LOCAL ADMIN ON SERVER
  ↓
ADMINISTRATIVE SESSION
  ↓
HIGHER-VALUE SYSTEM

The goal is to understand these relationships.

38 — Review Local Administrator Relationships

On authorized Windows systems:

net localgroup administrators

or:

Get-LocalGroupMember Administrators

Document:

Domain Users

Domain Groups

Local Users

Service Accounts

39 — Identify Administrative Overlap

Example:

ADMIN A
  ↓
SERVER 1

ADMIN B
  ↓
SERVER 1
  ↓
SERVER 2

PRIVILEGED ADMIN
  ↓
SERVER 2

Administrative overlap can create indirect attack paths.

40 — Review Administrative Tiering

A strong model may separate:

Tier 0
Domain Controllers / Identity

Tier 1
Servers / Applications

Tier 2
Workstations

Ideally:

Tier 0 Admin
       X
Normal Workstation Logon

41 — Review Privileged Sessions

Determine whether highly privileged accounts routinely authenticate to:

Workstations

Application Servers

Shared Admin Systems

Lower-Trust Servers

Such activity can expand credential and privilege exposure.

42 — Review Group Policy

Group Policy can control:

Security Settings

Firewall

Audit Policy

User Rights

Software

Scripts

Local Groups

Administrative Configuration

Use:

gpresult /r

to understand applicable policy from the current host.

43 — Review GPO Architecture

Build:

DOMAIN
  ↓
OU
  ↓
GPO
  ↓
COMPUTERS / USERS

Document:

GPO Name

Scope

Purpose

Owner

Security Filtering

44 — Review Privileged GPO Management

Ask:

Who Can Create GPOs?

Who Can Edit GPOs?

Who Can Link GPOs?

Who Can Modify GPO Permissions?

Because GPOs can influence many systems, these rights can be highly sensitive.

45 — Review Logon Scripts

If GPOs deploy scripts, review:

Script Location

Ownership

Permissions

Execution Context

Business Purpose

A privileged process should not depend on files writable by unauthorized users.

46 — Review Delegation

Kerberos delegation enables services to act on behalf of users in specific scenarios.

Review conceptually:

Unconstrained Delegation

Constrained Delegation

Resource-Based Constrained Delegation

The security question is:

Is Delegation Necessary?

Is It Restricted?

Which Systems Participate?

Which Identities Control It?

47 — Build Delegation Inventory

System / Account	Delegation Type	Purpose	Owner	Risk
APP01	Constrained	Application	App Team	Review
Legacy01	Legacy configuration	Unknown	Unknown	High

48 — Review Domain Trusts

Enterprise environments may contain:

Parent / Child Domains

Multiple Forests

Acquired Companies

Legacy Domains

Partner Trusts

Map:

DOMAIN A
    ↓
TRUST
    ↓
DOMAIN B

49 — Trust Assessment Questions

Ask:

What Type of Trust Exists?

What Direction?

Is It Transitive?

Why Does It Exist?

Which Identities Can Cross It?

Is Selective Authentication Used?

Who Owns the Trust?

50 — Review SMB and File Services

Active Directory users often receive access through groups.

Map:

USER
 ↓
GROUP
 ↓
FILE SHARE
 ↓
DATA

Review only authorized shares.

51 — Identify Sensitive Shares

Look for:

Deployment

Administration

Software

Backups

Scripts

Documentation

Application Configuration

Avoid unnecessary collection.

52 — Minimum Evidence Principle

Do not:

Copy All Files

Instead:

Demonstrate the Permission

Capture Minimal Evidence

Redact Sensitive Data

Document Business Impact

53 — Review Password and Secret Exposure

Operational environments may accidentally place secrets in:

Scripts

Configuration

Documentation

Deployment Files

Backups

Shared Folders

If discovered:

Document Exposure

Do Not Reuse Outside Scope

Do Not Include Full Secrets
in Reports

54 — Review Administrative Workstations

High-privilege administration should ideally occur from hardened systems.

Assess:

Who Uses Them?

Which Roles?

Which Networks?

Which Security Controls?

Which Accounts Can Log On?

55 — Review Remote Administration

Common technologies include:

RDP

WinRM

PowerShell Remoting

Administrative Shares

Management Platforms

Determine:

Who Can Use Them?

From Which Networks?

To Which Systems?

Is MFA Used?

Is Access Logged?

56 — Review Network Segmentation

Identity security and network security should reinforce each other.

Example:

USER NETWORK
      X
DOMAIN CONTROLLER
MANAGEMENT PORTS

but:

ADMIN NETWORK
      ↓
DOMAIN CONTROLLER
MANAGEMENT PORTS

57 — Build the Access Matrix

Source	Destination	Service	Expected
User subnet	DC01	Admin service	Deny
Admin subnet	DC01	Admin service	Allow
App server	DC01	Required AD	Allow

58 — Identify Active Directory Attack Paths

You are now ready to connect findings.

Example:

LOW-PRIVILEGE USER
       ↓
HELPDESK GROUP
       ↓
PASSWORD RESET RIGHT
       ↓
SERVER ADMIN
       ↓
CRITICAL SERVER

Another:

USER
 ↓
CUSTOM GROUP
 ↓
LOCAL ADMIN
 ↓
APPLICATION SERVER
 ↓
PRIVILEGED ADMIN SESSION

59 — Attack Paths Are Relationships

Do not report only:

Misconfigured Group

Weak Permission

Excessive Local Admin

Ask:

HOW DO THEY CONNECT?

60 — Create Attack Path AP-01

Attack Path ID:
AD-AP-01

Starting Identity:
helpdesk01

Relationship 01:
Member of HelpDesk

Relationship 02:
HelpDesk can reset passwords for
ServerAdmins

Target:
Server Administrator Identity

Potential Impact:
A compromised HelpDesk account could
influence a higher-privileged
administrative identity.

Recommended Path Break:
Limit delegated reset rights to
non-privileged user populations.

61 — Create Attack Path AP-02

Attack Path ID:
AD-AP-02

Starting Identity:
support01

Relationship:
Support group has local administrative
rights on APP01.

Relationship:
Privileged administrators regularly
use APP01.

Target:
Higher-value administrative context.

Impact:
Administrative overlap increases the
security significance of APP01.

Recommended Path Break:
Implement administrative tiering and
remove unnecessary local administrator
rights.

62 — Validate Paths Safely

Before validation:

REVIEW SCOPE
     ↓
CONFIRM IMPACT
     ↓
IDENTIFY MINIMUM PROOF
     ↓
VALIDATE
     ↓
COLLECT EVIDENCE
     ↓
STOP

Do not continue simply because additional impact might be possible.

63 — Do Not Over-Exploit

Professional validation should answer:

Does the Permission Exist?

Can the Starting Identity Use It?

Does It Reach the Identified Target?

What Control Should Break the Path?

Once demonstrated, unnecessary expansion of access is not required.

64 — Create the Findings Register

ID	Finding	Severity	Attack Path
AD-001	Excessive delegated privileges	High	AP-01
AD-002	Broad local administrator rights	High	AP-02
AD-003	Weak service-account governance	High	AP-03
AD-004	Privileged GPO management	Critical	AP-04
AD-005	Sensitive share exposure	Medium	AP-05

65 — Finding AD-001

Title:
Excessive Password Reset Delegation

Observation:
A support group can reset passwords for
accounts with administrative access.

Impact:
Compromise of a support account could
provide a path toward privileged
identities.

Recommendation:
Restrict password-reset delegation and
exclude privileged administrative
accounts from general support scope.

66 — Finding AD-002

Title:
Broad Local Administrator Assignment

Observation:
A general support group has local
administrator access across multiple
servers.

Impact:
Compromise of one support identity could
increase access across many enterprise
systems.

Recommendation:
Use server-specific administrative roles
and remove broad local administrator
assignments.

67 — Finding AD-003

Title:
Excessive Service Account Privilege

Observation:
A service identity is assigned privileges
beyond documented application
requirements.

Impact:
Compromise of the application or service
identity could provide unnecessary access
to additional resources.

Recommendation:
Apply least privilege and migrate to
managed service identities where possible.

68 — Finding AD-004

Title:
Excessive Group Policy Management Rights

Observation:
A non-Tier-0 administrative group can
modify a GPO applied to sensitive
systems.

Impact:
Unauthorized modification of security
policy could affect multiple privileged
assets.

Recommendation:
Restrict GPO administration to dedicated
authorized identities and monitor all
policy changes.

69 — Finding AD-005

Title:
Sensitive Administrative Information
Exposed Through File Share

Observation:
Operational files containing sensitive
configuration are accessible to more
users than required.

Impact:
The information could support additional
reconnaissance and privilege-path
analysis.

Recommendation:
Restrict access according to business
need and move secrets to approved secret
management systems.

70 — Risk Prioritization

Consider:

Starting Access Required

Privilege Gained

Target Criticality

Number of Affected Systems

Number of Affected Users

Ease of Abuse

Existing Monitoring

Attack-Path Position

Risk Matrix

Severity	Typical Meaning
Critical	Direct or near-direct path to Tier-0 / identity control
High	Major privilege expansion or sensitive administrative path
Medium	Meaningful weakness requiring additional conditions
Low	Limited security exposure
Informational	Hardening or governance observation

71 — Identity Hardening Recommendations

Prioritize:

Least Privilege

Administrative Tiering

Dedicated Admin Accounts

MFA

Privileged Access Management

Regular Access Reviews

Removal of Dormant Accounts

72 — Group Hardening

Review:

Privileged Group Membership

Nested Membership

Group Ownership

Membership Change Rights

Temporary Access

Approval Process

73 — Service Account Hardening

Prefer:

gMSA

Managed Password Rotation

Non-Interactive Accounts

Restricted Host Usage

Minimal Group Membership

Minimal Network Access

74 — Domain Controller Hardening

Protect DCs with:

Restricted Administration

Dedicated Admin Networks

No Normal User Activity

Tier-0 Accounts

Strong Monitoring

Secure Baselines

Patch Management

75 — GPO Hardening

Apply:

Restricted Editors

Restricted Link Rights

Change Monitoring

Backup

Version Control

Regular Review

76 — Delegation Hardening

Review all delegation for:

Business Need

Scope

Target Services

Controlling Identity

Legacy Configuration

Remove configurations that are no longer required.

77 — Trust Hardening

For each trust:

Confirm Business Need

Restrict Authentication

Review Direction

Review Transitivity

Monitor Cross-Domain Activity

Remove Legacy Trusts

78 — Monitoring Strategy

Active Directory monitoring should cover:

Authentication

User Creation

User Modification

Group Membership Changes

Privilege Assignment

GPO Changes

Service Account Changes

Trust Changes

Administrative Logons

79 — Important Windows Security Events

Examples:

Event ID	Meaning
4624	Successful logon
4625	Failed logon
4672	Special privileges assigned
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 out
4756	Member added to universal group
4768	Kerberos TGT request
4769	Kerberos service ticket request

80 — Monitor Privileged Group Changes

High-value groups should receive increased monitoring.

Examples:

Domain Admins

Enterprise Admins

Administrators

Custom Tier-0 Groups

Changes should generate:

Alert

Context

Approval Validation

Investigation

81 — Monitor Administrative Logons

Ask:

Where Are Tier-0 Accounts
Authenticating?

Are Privileged Users
Logging Into Workstations?

Are Administrators Using
Shared Servers?

Unexpected administrative logons may expose privilege paths.

82 — Cleanup

After completing the assessment:

Remove Test Accounts

Remove Temporary Memberships

Restore Permissions

Restore Test Objects

Remove Temporary Files

Terminate Test Sessions

Verify Domain Health

Secure Evidence

83 — Retesting

After remediation:

ORIGINAL PATH
     ↓
REPEAT ENUMERATION
     ↓
VERIFY PERMISSION REMOVED
     ↓
VERIFY MEMBERSHIP REMOVED
     ↓
VERIFY ACCESS DENIED
     ↓
CONFIRM ATTACK PATH BROKEN

Retest Example

Before:

helpdesk01
   ↓
Reset Password
   ↓
ServerAdmin

After:

helpdesk01
   ↓
X
   ↓
ServerAdmin

84 — Reporting Structure

Use:

01 Executive Summary

02 Scope

03 Rules of Engagement

04 Active Directory Architecture

05 Identity Assessment

06 Group Assessment

07 Computer Assessment

08 Authentication Assessment

09 Service Accounts

10 AD Permissions

11 Administrative Delegation

12 Group Policy

13 Kerberos Delegation

14 Domain Trusts

15 Administrative Paths

16 Findings

17 Attack Paths

18 Risk Prioritization

19 Remediation

20 Retest

21 Cleanup

Executive Summary Example

The Active Directory penetration test
identified security weaknesses involving
delegated permissions, administrative
group relationships, service-account
privileges, and administrative access
patterns.

Several findings created indirect paths
from lower-privileged identities toward
higher-value systems and administrative
roles.

The primary remediation priority is to
reduce excessive privilege, implement
administrative tiering, strengthen
service-account governance, restrict
delegated permissions, and improve
monitoring of privileged identity
activity.

Active Directory Finding Template

Finding ID:

Title:

Affected Domain:

Affected Identity:

Affected Object:

Starting Privilege:

Permission / Relationship:

Description:

Attack Path:

Evidence:

Security Impact:

Likelihood:

Severity:

Root Cause:

Recommendation:

Retest Procedure:

Attack Path Worksheet

Attack Path ID:

Starting Identity:

Initial Privilege:

Group Membership:

Delegated Permission:

Controlled Resource:

Intermediate System:

Administrative Relationship:

Target Identity:

Target Asset:

Business Impact:

Existing Security Control:

Control Gap:

Recommended Path Break:

Active Directory Pentest Checklist

Scope

Domain

Domain context identified
Domain controllers identified
DNS reviewed
Domain architecture mapped

Users

Groups

Computers

Authentication

Service Accounts

Permissions

Delegated rights reviewed
Object ownership reviewed
ACL inheritance reviewed
Privileged-object permissions reviewed

Administration

Local administrators reviewed
Administrative overlap reviewed
Tiering reviewed
Privileged logon patterns reviewed

GPO

Delegation

Delegation inventoried
Business need validated
Controlling identities reviewed
Legacy configurations reviewed

Trusts

Attack Paths

Relationships correlated
Starting identities identified
Intermediate privileges identified
Critical targets identified
Paths validated safely
Path-breaking controls documented

Reporting

30 Active Directory Pentest Review Questions

What is Active Directory?
What is the difference between a domain and a forest?
What is a domain controller?
Why is DNS important to Active Directory?
What is Kerberos?
What is LDAP?
Why should privileged groups be reviewed?
What is nested group membership?
Why can nested groups hide privilege?
What is delegated administration?
Why can excessive password-reset rights be risky?
What is an Active Directory ACL?
Why is object ownership security-sensitive?
What is a service account?
What is a gMSA?
Why should service accounts use least privilege?
What is Group Policy?
Why are GPO modification rights highly sensitive?
What is administrative tiering?
What is Tier 0?
Why should privileged users avoid standard workstations?
What is Kerberos delegation?
What is an Active Directory trust?
Why should old trusts be reviewed?
Why are local administrator relationships important?
What is an Active Directory attack path?
Why should individual findings be correlated?
What does controlled validation mean?
Why should privileged identity events be monitored?
How do you confirm remediation broke an attack path?

Final Active Directory Pentest Mental Model

Remember:

DOMAIN
   ↓
IDENTITIES
   ↓
GROUPS
   ↓
PERMISSIONS
   ↓
COMPUTERS
   ↓
ADMINISTRATION
   ↓
AUTHENTICATION
   ↓
SERVICE ACCOUNTS
   ↓
GPO
   ↓
DELEGATION
   ↓
TRUSTS
   ↓
RELATIONSHIPS
   ↓
ATTACK PATHS
   ↓
BUSINESS IMPACT

Do not think only:

Who Is Domain Admin?

Think:

WHO CAN CONTROL
SOMETHING THAT CONTROLS
SOMETHING ELSE?

For example:

USER
 ↓
GROUP
 ↓
DELEGATED PERMISSION
 ↓
SERVER ADMIN
 ↓
CRITICAL SERVER

or:

USER
 ↓
CUSTOM ADMIN GROUP
 ↓
APPLICATION SERVER
 ↓
PRIVILEGED ADMIN ACTIVITY
 ↓
HIGHER-VALUE IDENTITY

A strong Active Directory penetration tester should be able to explain:

WHERE THE PATH STARTS

WHICH IDENTITY RELATIONSHIP
CREATES THE RISK

WHICH SECURITY BOUNDARY FAILS

WHAT THE FINAL BUSINESS
IMPACT COULD BE

WHICH CONTROL SHOULD
BREAK THE PATH

What’s Next?

➡️ Runbook 02 — Enterprise Pentest

The next runbook expands beyond Active Directory into the complete enterprise environment.

You will use a repeatable methodology covering:

SCOPE
  ↓
NETWORK DISCOVERY
  ↓
ASSET INVENTORY
  ↓
SERVICE ENUMERATION
  ↓
WINDOWS
  ↓
LINUX
  ↓
WEB APPLICATIONS
  ↓
IDENTITY
  ↓
ACTIVE DIRECTORY
  ↓
SEGMENTATION
  ↓
ATTACK-PATH MAPPING
  ↓
CONTROLLED VALIDATION
  ↓
EVIDENCE
  ↓
REPORTING

The objective will be to turn individual technical assessments into a complete enterprise penetration-testing methodology.