04 — Active Directory Security

Microsoft Active Directory remains one of the most important identity platforms in enterprise environments.

Organisations use Active Directory to centrally manage:

Users
Computers
Servers
Authentication
Authorization
Groups
Administrative privileges
Security policies
Applications
Network resources

This makes Active Directory extremely valuable to attackers.

A compromised workstation may initially appear to be an isolated security incident.

But inside a domain environment, that workstation may provide access to:

User Credential
      ↓
Domain Identity
      ↓
Network Resources
      ↓
Additional Systems
      ↓
Privileged Credentials
      ↓
Administrative Access
      ↓
Domain Control

For an Ethical Hacker, Active Directory testing is therefore not simply about finding vulnerable Windows servers.

It is about understanding identity relationships, permissions, trust, credentials, and attack paths across the enterprise.

Module Mission

Your mission is to learn how to systematically assess an authorised Active Directory environment and determine whether an attacker could progress from limited access toward privileged control.

The core methodology is:

Scope
  ↓
Understand AD Architecture
  ↓
Identify Domain
  ↓
Enumerate Users
  ↓
Enumerate Groups
  ↓
Enumerate Computers
  ↓
Understand Authentication
  ↓
Analyse Permissions
  ↓
Identify Credential Exposure
  ↓
Assess Service Accounts
  ↓
Analyse Group Policy
  ↓
Identify Privilege Paths
  ↓
Evaluate Lateral Movement
  ↓
Analyse Trust Relationships
  ↓
Build Attack Paths
  ↓
Validate Safely
  ↓
Collect Evidence
  ↓
Report

By the end of this module, you should understand how seemingly minor identity weaknesses can combine into major enterprise attack paths.

1. What Is Active Directory?

Active Directory Domain Services provides centralised identity and resource management for Windows enterprise environments.

A simplified environment:

Active Directory Domain
│
├── Users
├── Groups
├── Computers
├── Servers
├── Policies
├── Permissions
└── Applications

Instead of maintaining separate identities on every system, organisations can centrally manage authentication and authorization.

2. Why Active Directory Is Important to Attackers

Active Directory connects identities with resources.

Conceptually:

Identity
   ↓
Permissions
   ↓
Resources

If an attacker compromises an identity, they may gain access to everything that identity can access.

If the attacker later compromises a privileged identity:

Standard User
     ↓
Privilege Path
     ↓
Administrator
     ↓
Domain Resources

the impact can become enterprise-wide.

3. Active Directory Security Is Relationship Security

The most important concept in this module is:

Active Directory security is largely about relationships.

Examples:

User
 ↓
Member Of
 ↓
Group
 ↓
Has Permission
 ↓
Server

or:

Service Account
      ↓
Administrative Rights
      ↓
Application Server
      ↓
Credential Exposure
      ↓
Additional Systems

These relationships create attack paths.

4. Active Directory Architecture

A simplified architecture:

Forest
  ↓
Domain
  ↓
Organisational Units
  ↓
Users / Groups / Computers

Understanding these components is essential before analysing security.

5. Forest

A forest is the highest-level logical Active Directory structure.

Example:

corp.example
     │
     ├── child.corp.example
     │
     └── regional.corp.example

A forest can contain multiple domains.

Security relationships may exist between them.

6. Domain

A domain represents an administrative and identity boundary within Active Directory.

Example:

corp.lab

Objects may include:

corp.lab
│
├── Users
├── Groups
├── Computers
├── Servers
└── Domain Controllers

7. Domain Controllers

Domain Controllers provide critical Active Directory services.

They commonly support:

Authentication
Kerberos
LDAP
Group Policy
Directory replication
Domain information

Conceptually:

User
 ↓
Domain Controller
 ↓
Authentication
 ↓
Domain Resources

Domain Controllers are among the most sensitive systems in the enterprise.

8. Why Domain Controller Compromise Matters

If an attacker obtains sufficient control over a Domain Controller or equivalent domain-level privileges:

Domain Controller
       ↓
Directory
       ↓
Users
Groups
Computers
Policies
Credentials

the attacker may effectively control the domain.

This is why Domain Controllers require strong protection.

9. Organisational Units

Organisational Units help structure directory objects.

Example:

corp.lab
│
├── Employees
│
├── Servers
│
├── Workstations
│
├── Service Accounts
│
└── Administrators

OUs can also be used for:

Delegated administration
Group Policy application
Resource organisation

Improper delegation can create privilege escalation paths.

10. Active Directory Objects

Common AD objects include:

Users

Groups

Computers

Service Accounts

Organisational Units

Group Policies

Trusts

Each object can have attributes and permissions.

11. Users

User accounts represent identities.

Examples:

alice

bob

administrator

svc_backup

Users may be:

Standard users
Administrators
Service identities
Emergency accounts
Application accounts

Account purpose matters during security assessment.

12. Groups

Groups simplify permission management.

Example:

Alice
  ↓
Finance Users
  ↓
Finance Share

Instead of assigning permissions individually, organisations assign permissions to groups.

But excessive group membership can create hidden privilege.

13. Nested Groups

Groups may contain other groups.

Example:

Alice
 ↓
Support Team
 ↓
Server Operators
 ↓
Administrative Access

Alice may not appear obviously privileged.

But nested membership creates an indirect privilege path.

14. Privileged Groups

Important groups may include:

Domain Admins

Enterprise Admins

Administrators

Account Operators

Server Operators

Backup Operators

But do not focus only on obvious privileged groups.

Custom groups may have equally powerful permissions.

15. Computers

Domain-joined computers are also Active Directory objects.

Examples:

WS-001$

APP-01$

DB-01$

DC-01$

Computer accounts have identities and credentials.

This becomes important during enterprise attack-path analysis.

16. Active Directory Authentication

Two major authentication technologies are:

Kerberos

NTLM

Understanding them is essential for Active Directory security testing.

17. Kerberos

Kerberos is the primary authentication protocol used in modern Active Directory environments.

A simplified flow:

User
 ↓
Domain Controller
 ↓
Authentication
 ↓
Ticket
 ↓
Service

Rather than repeatedly sending a password to every service, Kerberos uses tickets.

18. Kerberos Components

Important concepts include:

Client

Key Distribution Center

Ticket Granting Ticket

Service Ticket

Service Principal Name

The Domain Controller typically provides the Key Distribution Center functionality.

19. Kerberos Authentication Flow

Simplified:

User
 ↓
Authentication Service
 ↓
Ticket Granting Ticket
 ↓
Ticket Granting Service
 ↓
Service Ticket
 ↓
Application / Server

Understanding this model makes later Kerberos attack concepts easier to understand.

20. Ticket Granting Ticket

After successful authentication, the user receives a Ticket Granting Ticket.

Conceptually:

User
 ↓
TGT
 ↓
Request Access to Services

The TGT helps the user obtain service tickets.

21. Service Tickets

Suppose a user wants access to a file server.

User
 ↓
TGT
 ↓
Service Ticket
 ↓
File Server

The service ticket allows the user to authenticate to the target service.

22. Service Principal Names

Service Principal Names associate services with Active Directory identities.

Examples may conceptually represent:

HTTP/web01

MSSQLSvc/db01

CIFS/file01

SPNs become particularly important when assessing service accounts.

23. NTLM

NTLM is an older Windows authentication protocol that still exists in many enterprise environments.

Conceptually:

Client
 ↓
Challenge
 ↓
Authentication Response
 ↓
Server

Legacy authentication mechanisms can create additional attack opportunities.

24. Kerberos vs NTLM

At a high level:

Kerberos	NTLM
Ticket based	Challenge-response
Modern AD default	Legacy compatibility
Supports delegated authentication models	Often used when Kerberos cannot be used
Stronger enterprise integration	Larger legacy attack surface

The presence of NTLM is not automatically a vulnerability.

Assess how and where it is used.

25. LDAP

LDAP provides access to directory information.

Common ports:

389 → LDAP

636 → LDAPS

LDAP may allow authorised users to query:

Users
Groups
Computers
OUs
Service accounts
SPNs
Policies
Relationships

Directory enumeration is fundamental to AD testing.

26. DNS and Active Directory

DNS is critical to Active Directory.

Clients use DNS to locate:

Domain Controllers

Kerberos Services

LDAP Services

Domain Resources

If DNS is incorrectly configured, authentication and domain functionality may fail.

For an Ethical Hacker, DNS also provides valuable environment information.

27. Identify the Domain

From an authorised domain-joined Windows lab system, commands such as:

whoami

may reveal the current identity.

Additional system information can help identify domain membership.

For example:

systeminfo

or:

ipconfig /all

Record:

Current User

Computer Name

Domain

DNS Servers

Network

28. Current Identity

Use:

whoami

Then inspect group membership:

whoami /groups

And available privileges:

whoami /priv

This establishes your current security context.

29. Why Security Context Matters

Suppose:

Current User
     ↓
Group Membership
     ↓
Permissions
     ↓
Accessible Resources

Your effective access may be much greater than the username suggests.

Always understand the complete security context.

30. Enumerate Domain Information

Inside an authorised lab, native Windows tools can help understand the domain.

Examples:

net user /domain

and:

net group /domain

These provide initial visibility into directory objects where permitted.

31. Enumerate Domain Users

The objective is to identify:

Normal Users

Administrators

Service Accounts

Disabled Accounts

Legacy Accounts

Special Accounts

Do not assume accounts beginning with svc_ are the only service identities.

Naming conventions vary.

32. User Enumeration Questions

For each interesting account ask:

What Is Its Purpose?

Which Groups?

Which Systems?

Which Privileges?

Interactive Login?

Service Account?

Password Policy?

Last Used?

Still Required?

Security comes from context.

33. Enumerate Groups

Groups reveal privilege relationships.

Build:

Group	Purpose	Members	Privilege
Domain Admins	Domain administration	Admin01	Critical
Server Admins	Server management	Ops Team	High
Helpdesk	User support	Support Team	Medium

Custom groups deserve close attention.

34. Enumerate Computers

Identify:

Domain Controllers

Servers

Workstations

Application Servers

Database Servers

Management Servers

Then begin mapping identities to systems.

35. Build an Active Directory Asset Map

Example:

corp.lab
│
├── DC01
├── FILE01
├── APP01
├── DB01
├── WS01
└── WS02

Now add relationships:

Alice → WS01

APP01 → DB01

Admin01 → DC01

svc_backup → FILE01

This begins the attack-path model.

36. Password Policy

Review domain password controls.

Questions include:

Minimum Length

Complexity

Password History

Lockout Threshold

Lockout Duration

Password Age

Weak password policies can increase credential risk.

37. Password Policy Is Only One Layer

Even a strong password policy does not protect against:

Credential Theft

Phishing

Password Reuse

Exposed Secrets

Weak Service Accounts

Session Theft

Identity security requires multiple controls.

38. Account Lockout

Account lockout policies can reduce certain password attacks.

But poorly designed policies can also create denial-of-service risks.

Testing credential attacks requires explicit authorization and careful rate control.

39. Password Spraying Concept

Traditional guessing may attempt:

One User
  ↓
Many Passwords

Password spraying reverses the pattern:

Many Users
   ↓
Small Number of Candidate Passwords

This can reduce per-account lockout activity.

However, it can still disrupt environments and trigger security controls.

Only perform credential testing when explicitly authorised.

40. Credential Security

Credentials may exist in:

Memory

Configuration Files

Scripts

Scheduled Tasks

Services

Backups

Deployment Systems

Password Stores

Attackers frequently search compromised systems for reusable credentials.

41. Credential Reuse

Consider:

User A Credential
       ↓
Workstation
       ↓
Server
       ↓
Administrative Access

A credential that is low privilege on one system may be highly privileged elsewhere.

This is why credential reuse can dramatically increase attack impact.

42. Local Administrator Accounts

Organisations may accidentally use identical local administrator passwords across multiple systems.

Attack path:

Workstation A
      ↓
Local Admin Credential
      ↓
Workstation B
      ↓
Workstation C

Unique local administrator credentials reduce this risk.

43. Windows LAPS

Windows Local Administrator Password Solution capabilities help organisations manage unique local administrator passwords.

Conceptually:

Computer A → Unique Password A

Computer B → Unique Password B

Computer C → Unique Password C

This helps break credential-reuse attack paths.

44. Service Accounts

Service accounts are identities used by:

Applications
Services
Scheduled tasks
Databases
Automation

They often create significant risk because they may have:

Long-Lived Passwords

High Privilege

Broad Access

Limited Monitoring

45. Service Account Assessment

For each service identity determine:

Purpose

Owner

SPNs

Privileges

Group Membership

Systems Used

Credential Management

Interactive Login

Password Rotation

Service account governance is a major enterprise security concern.

46. Kerberoasting Concept

Some service accounts with SPNs allow authenticated domain users to request Kerberos service tickets.

Conceptually:

Domain User
    ↓
Request Service Ticket
    ↓
Kerberos
    ↓
Ticket Associated With Service Account

In certain circumstances, ticket material can support offline password-strength analysis against the service account.

The defensive concern is particularly important when service accounts use weak passwords.

47. Kerberoasting Risk

Potential attack path:

Standard Domain User
        ↓
Service Account Ticket
        ↓
Weak Service Account Password
        ↓
Service Account Credential
        ↓
Privileged Group Membership
        ↓
Administrative Access

The real risk is the combination of:

Weak Credential
      +
Service Account
      +
Excessive Privilege

48. Kerberoasting Defensive Controls

Important controls include:

Strong service-account passwords
Managed service accounts
Least privilege
Remove unnecessary SPNs
Monitor suspicious ticket activity
Regularly review service identities

Where possible, modern managed identities are preferable to manually managed static credentials.

49. AS-REP Roasting Concept

Kerberos normally requires pre-authentication for user accounts.

If pre-authentication is disabled for certain accounts, authentication material may be obtainable that supports offline password-strength analysis.

Conceptually:

Account
   ↓
Kerberos Pre-Authentication Disabled
   ↓
Authentication Response Material
   ↓
Offline Password Analysis

This is primarily a configuration and password-strength issue.

50. AS-REP Roasting Defensive Controls

Review accounts for:

Pre-Authentication Disabled

Weak Passwords

Excessive Privilege

Legacy Configuration

Enable Kerberos pre-authentication unless a valid requirement exists.

51. SMB in Active Directory

SMB commonly provides:

File sharing
Administrative shares
Remote management support
Domain functionality

SMB is therefore central to many Windows attack paths.

52. Administrative Shares

Windows systems may expose administrative shares such as:

C$

ADMIN$

Access generally requires administrative privilege.

Their presence is not itself a vulnerability.

The important question is:

Which identities can access them?

53. Remote Administration

Common Windows remote administration technologies include:

SMB

RDP

WinRM

PowerShell Remoting

These become potential lateral movement mechanisms when credentials and permissions allow them.

54. Lateral Movement

Lateral movement means moving from one compromised system or identity to another.

Conceptually:

Workstation
    ↓
Credential
    ↓
Application Server
    ↓
Privileged Credential
    ↓
Management Server

The objective of assessment is to determine why this movement is possible.

55. Lateral Movement Requirements

A useful model:

Network Reachability
        +
Valid Identity
        +
Required Permission
        +
Remote Service
        =
Lateral Movement Opportunity

Breaking any one of these conditions may disrupt the path.

56. Pass-the-Hash Concept

Windows authentication can sometimes allow authentication using credential-derived material rather than the original plaintext password.

Conceptually:

Compromised Credential Material
            ↓
Authentication
            ↓
Remote Resource

The defensive lesson is important:

Protecting passwords alone is insufficient if reusable credential material remains exposed.

57. Pass-the-Ticket Concept

Kerberos tickets represent authenticated access.

If valid ticket material is compromised:

Kerberos Ticket
      ↓
Service Authentication

it may potentially be abused during the ticket’s usable lifetime.

This is why credential and session protection matters.

58. Credential Exposure on Administrative Systems

Consider:

Administrator
     ↓
Logs Into Workstation
     ↓
Credential Material
     ↓
Workstation Compromised

Privileged identities should avoid logging into lower-trust systems.

59. Administrative Tiering

A stronger design separates administrative activities.

Conceptually:

Tier 0
Domain / Identity Infrastructure

Tier 1
Servers / Applications

Tier 2
User Workstations

Higher-tier credentials should not be unnecessarily exposed to lower-trust systems.

60. Privileged Access Workstations

Privileged administrators may use dedicated hardened systems.

Administrator
     ↓
Privileged Access Workstation
     ↓
Sensitive Infrastructure

This reduces exposure of privileged credentials.

61. Group Policy

Group Policy centrally configures Windows systems and users.

Examples include:

Password Policies

Security Settings

Firewall Rules

Scripts

Software Configuration

Administrative Controls

Because GPOs can affect many systems, their permissions are security-sensitive.

62. Group Policy Attack Paths

Consider:

User
 ↓
Can Modify GPO
 ↓
GPO Applied to Servers
 ↓
Configuration Changed
 ↓
Privileged Execution

The user’s direct group membership may appear unprivileged.

But control over a GPO may create an indirect path to administrative access.

63. GPO Security Review

Assess:

Who Can Edit?

Where Is It Linked?

Which Systems Receive It?

Which Users Receive It?

Does It Contain Sensitive Information?

Are Permissions Appropriate?

GPO modification rights should be tightly controlled.

64. SYSVOL

Active Directory uses SYSVOL to distribute Group Policy-related information.

Conceptually:

Domain Controller
      ↓
SYSVOL
      ↓
Domain Systems

Reviewing accessible policy content can reveal configuration information.

Historical environments may also contain legacy sensitive data.

65. Active Directory ACLs

Active Directory objects have Access Control Lists.

These determine who can:

Read

Modify

Reset Password

Change Membership

Take Ownership

Modify Permissions

Misconfigured ACLs can create hidden privilege escalation paths.

66. ACL-Based Privilege Escalation

Example:

User A
 ↓
Can Reset Password
 ↓
User B
 ↓
Member of Server Admins
 ↓
Administrative Access

User A is effectively more privileged than their group membership initially suggests.

67. Permission Relationships

Important relationships may conceptually include:

Can Modify

Can Reset Password

Can Add Member

Can Take Ownership

Can Modify Permissions

Has Administrative Access

Graph-based analysis is particularly useful for understanding these relationships.

68. BloodHound

BloodHound is commonly used in authorised Active Directory assessments to analyse relationships between:

Users
Groups
Computers
Sessions
Permissions
Administrative rights

It transforms complex directory relationships into graph-based attack paths.

Conceptually:

User
 ↓
Group
 ↓
Permission
 ↓
Computer
 ↓
Session
 ↓
Privileged User

69. Why Graph Analysis Matters

Without relationship analysis you may see:

500 Users

300 Computers

200 Groups

With relationship analysis you may discover:

Standard User
     ↓
Helpdesk Group
     ↓
Password Reset Permission
     ↓
Server Admin
     ↓
Critical Server

The second view explains the security risk.

70. Do Not Treat BloodHound as an Exploitation Button

BloodHound helps identify relationships and hypotheses.

For each path:

Graph Path
    ↓
Validate Relationship
    ↓
Understand Preconditions
    ↓
Determine Risk
    ↓
Safely Validate If Required

Tool output should be verified.

71. Domain Administrator Paths

A common assessment objective is understanding:

What paths could allow a normal identity to reach highly privileged domain control?

This does not mean you must compromise Domain Admin.

Often demonstrating a credible path is sufficient.

72. Attack Path Example

Standard User
     ↓
Local Admin on APP01
     ↓
APP01
     ↓
Server Admin Session
     ↓
Privileged Credential
     ↓
Server Admin
     ↓
Control of DC Management System

The important issue is the complete chain.

73. Another Attack Path

Standard User
     ↓
Can Modify Group
     ↓
Application Admins
     ↓
Admin on APP01
     ↓
Credential Exposure
     ↓
Domain Privilege

Identity permissions can create indirect privilege escalation.

74. Active Directory Trusts

Trust relationships allow identities from one domain to access resources in another.

Conceptually:

Domain A
   ↓
Trust
   ↓
Domain B

Trusts may be:

One-way
Two-way
Internal
External
Forest-based

Trust configuration affects attack-path scope.

75. Trust Does Not Automatically Mean Compromise

A trust means a security relationship exists.

It does not necessarily mean:

Domain A Compromise
       =
Domain B Compromise

Analyse:

Direction
Authentication
Permissions
Group memberships
Resource access

76. Active Directory Certificate Services

Some enterprises use Active Directory Certificate Services.

Certificates may support:

User Authentication

Machine Authentication

VPN

Web Services

Smart Cards

Certificate infrastructure becomes part of the identity security boundary.

77. Why AD CS Matters

Misconfigured certificate templates or enrolment permissions can sometimes create unintended authentication or privilege paths.

Conceptually:

Low Privilege User
       ↓
Certificate Enrollment
       ↓
Misconfigured Template
       ↓
Privileged Authentication

AD CS should therefore be included when present in authorised assessments.

78. Certificate Template Review

Questions include:

Who Can Enrol?

Which Identity Can Be Requested?

What Authentication Purpose Exists?

Who Controls the Template?

Are Approval Controls Required?

Certificate permissions deserve the same attention as passwords and groups.

79. Delegation

Kerberos supports delegation mechanisms allowing services to act on behalf of users.

Delegation is useful for enterprise applications but can become security-sensitive.

Review:

Which Accounts?

Which Computers?

Which Services?

Which Delegation Type?

Why Required?

Unnecessary delegation should be reduced.

80. Domain Controller Exposure

Domain Controllers should generally not be treated like ordinary servers.

Review:

Who Can Reach Them?

Who Can Log In?

Which Management Paths Exist?

Which Services Are Exposed?

Which Administrators Use Them?

How Are They Monitored?

Reducing unnecessary access helps protect the identity control plane.

81. Active Directory as a Control Plane

Think of Active Directory as:

Enterprise Resources
        ↑
Authorization
        ↑
Identity
        ↑
Active Directory

Compromise of the identity control plane can undermine controls throughout the enterprise.

82. Hybrid Identity

Modern enterprises may connect:

On-Premises Active Directory
           ↓
Identity Synchronisation
           ↓
Microsoft Entra ID
           ↓
Cloud / SaaS

This creates hybrid attack paths.

83. Hybrid Attack Path

Example:

On-Prem Identity
      ↓
Synchronization
      ↓
Cloud Identity
      ↓
Microsoft 365 / Azure / SaaS

Identity compromise may therefore extend beyond the local network.

84. Review Synchronisation Infrastructure

Identity synchronisation systems can be highly sensitive because they bridge identity environments.

Ask:

Where Is It Hosted?

Who Administers It?

Which Credentials Exist?

What Privileges Does It Hold?

How Is It Monitored?

Treat identity bridge systems as high-value assets.

85. Privilege Escalation

Active Directory privilege escalation may arise through:

Group Membership

ACL Misconfiguration

GPO Permissions

Service Accounts

Credential Exposure

Delegation

Certificate Services

Local Administrator Rights

Trust Relationships

Do not search for only one technique.

Analyse relationships.

86. Privilege Is Transitive

Suppose:

User
 ↓
Group A
 ↓
Can Modify Group B
 ↓
Group B Administers Server
 ↓
Privileged Session on Server

The user may have no direct administrative role.

But the chain creates effective privilege.

87. Identity Blast Radius

Ask:

If this identity is compromised, what can the attacker reach?

Example:

svc_deploy
   ├──→ APP01
   ├──→ APP02
   ├──→ APP03
   └──→ Production Deployment

One compromised identity may affect many systems.

88. High-Value Identities

Identify accounts that can control:

Domain Controllers

Identity Systems

Backup Infrastructure

Virtualisation

Security Tools

Cloud Identity

Certificate Services

Deployment Systems

Privilege is not limited to Domain Admin membership.

89. High-Value Systems

Important systems may include:

Domain Controllers

PKI Servers

Backup Servers

Virtualisation Platforms

Management Servers

Identity Synchronisation

PAM Systems

Security Management Systems

Compromise of these systems may create broad control.

90. Backup Infrastructure

Backup administrators may possess powerful access across servers.

Conceptually:

Backup System
   ↓
Many Servers
   ↓
Sensitive Data

Backup infrastructure should be treated as part of the privileged security plane.

91. Virtualisation Infrastructure

A virtualisation administrator may effectively control many servers.

Hypervisor Administrator
        ↓
Virtual Machines
        ↓
Domain / Application / Database Servers

Therefore:

Domain Admin is not the only route to enterprise-level impact.

92. Management Infrastructure

Tools used for:

Software Deployment

Endpoint Management

Remote Administration

Monitoring

Configuration Management

may have broad enterprise permissions.

These systems should be included in attack-path analysis.

93. Identify Privilege Choke Points

Suppose:

User
 ↓
Helpdesk
 ↓
Server Admin
 ↓
Domain Admin

Possible controls that break the path:

Restrict Password Reset Rights

Separate Administrative Tiers

Use MFA

Use JIT Privilege

Use PAWs

Reduce Standing Access

Good findings identify where the attack chain can be broken.

94. Least Privilege

Every identity should have only the permissions required.

Review:

Users

Groups

Service Accounts

Computer Accounts

Administrators

Applications

Excess privilege expands attack paths.

95. Standing Privilege

A permanently privileged account creates ongoing exposure.

Example:

Administrator
      ↓
Permanent Privilege
      ↓
24×7 Attack Opportunity

Modern designs increasingly use temporary elevation.

96. Just-in-Time Privilege

Conceptually:

Normal Account
     ↓
Approved Request
     ↓
Temporary Privilege
     ↓
Administrative Task
     ↓
Privilege Removed

This reduces standing privilege.

97. Separate Administrative Accounts

Administrators should generally avoid using highly privileged accounts for normal activities.

Better:

Normal Account
     ↓
Email / Browsing

Admin Account
     ↓
Administrative Tasks

This reduces privileged credential exposure.

98. MFA for Privileged Access

Privileged identities deserve stronger authentication.

But MFA alone does not solve:

Excessive Privilege

Credential Exposure

Unsafe Admin Workstations

Weak Delegation

Misconfigured ACLs

Use defense in depth.

99. Monitoring Active Directory

Important activity may include:

Authentication

Privilege Changes

Group Membership Changes

Account Creation

Password Resets

GPO Changes

Directory Permission Changes

Certificate Activity

Identity security requires both prevention and detection.

100. Think Like the Defender

During every authorised test ask:

Would this activity be detected?

Example:

Unusual Authentication
       ↓
New Administrative Membership
       ↓
Remote Access
       ↓
Sensitive System

A mature environment should have visibility into important identity events.

101. Active Directory Attack Lifecycle

A simplified attack lifecycle:

Initial Access
     ↓
Domain Discovery
     ↓
Identity Enumeration
     ↓
Privilege Discovery
     ↓
Credential Access
     ↓
Privilege Escalation
     ↓
Lateral Movement
     ↓
Control Plane Access

Real attacks may follow many variations.

102. Initial Access Is Not Domain Compromise

A compromised domain user is often only the beginning.

The Ethical Hacker should ask:

What Does This User Know?

What Can This User Access?

Which Groups?

Which Systems?

Which Credentials?

Which Relationships?

Which Privilege Paths?

This is the transition from host testing to identity attack-path analysis.

103. Build an AD Enumeration Workbook

Create columns such as:

Object	Type	Privilege	Relationship	Risk
alice	User	Standard	Helpdesk	Review
Helpdesk	Group	Delegated	Reset rights	High
APP01	Computer	Server	Admin session	High
svc_sql	Service Account	DB Admin	SPN	Review

This makes complex environments manageable.

104. Build an Attack Path Register

Example:

Path	Entry	Target	Risk
AP-01	Standard User	Server Admin	High
AP-02	Service Account	Domain Admin	Critical
AP-03	Helpdesk	Identity Control	Critical

Then document the relationships forming each path.

105. Evidence Collection

For Active Directory findings capture:

Object

Identity

Group

Permission

Target

Relationship

Relevant Output

Timestamp

Evidence ID

Avoid collecting unnecessary password material or sensitive directory data.

106. Example Evidence

Evidence ID:
AD-EV-014

Source:
LAB\helpdesk01

Relationship:
Can reset password

Target:
LAB\serveradmin01

Observation:
A standard helpdesk identity has delegated password-reset control over an account with server administrative privileges.

This explains the security relationship clearly.

107. Example Finding — Excessive Password Reset Delegation

AD-001 — Helpdesk Accounts Can Reset Privileged Administrator Passwords

Observation

The assessment identified that members of the Helpdesk group possessed delegated password-reset permissions over accounts with privileged server administration rights.

Attack Scenario

An attacker compromising a Helpdesk account could use the delegated permission to obtain control of a privileged server administrator identity.

Impact

Successful exploitation could provide administrative access to critical enterprise servers and enable further credential theft or lateral movement.

Recommendation

Restrict password-reset delegation to appropriate account tiers and prevent lower-trust administrative roles from controlling higher-privilege identities.

108. Example Finding — Weak Service Account Governance

AD-002 — Privileged Service Account Uses a Long-Lived Manually Managed Credential

Observation

A service account with administrative permissions across multiple application servers used a manually managed static password with limited evidence of regular rotation.

Risk

Compromise of the service account credential could provide broad administrative access across application infrastructure.

Recommendation

Reduce the account’s privileges, transition to an appropriate managed service identity where supported, restrict interactive use, and implement lifecycle monitoring.

109. Example Finding — Privileged Accounts Used on Workstations

AD-003 — Domain-Level Administrative Accounts Authenticate to Standard User Workstations

Observation

The assessment identified highly privileged administrative identities authenticating to standard employee workstation systems.

Attack Scenario

Compromise of a workstation could expose privileged authentication material and create a path toward higher-value infrastructure.

Recommendation

Implement administrative tiering, restrict privileged logon locations, use dedicated administrative identities, and require hardened privileged access workstations for sensitive administration.

110. Example Finding — Excessive GPO Control

AD-004 — Non-Privileged Group Can Modify a Server Security GPO

Observation

A non-administrative support group had modification permissions over a Group Policy Object applied to production servers.

Risk

Compromise of a member of the support group could allow unauthorised modification of server configuration and potentially create a privilege escalation path.

Recommendation

Restrict GPO modification rights to approved administrative identities and regularly review delegated Group Policy permissions.

111. Example Finding — Weak Segmentation of Domain Controllers

AD-005 — Domain Controller Management Services Are Broadly Accessible

Observation

Domain Controller administrative services were reachable from standard user network segments beyond documented operational requirements.

Risk

Broad reachability increases opportunities for compromised endpoints to interact directly with critical identity infrastructure.

Recommendation

Restrict Domain Controller administrative access to authorised management networks and systems while maintaining only required domain service connectivity.

112. Findings vs Attack Paths

A single finding:

Weak Service Account Password

may be Medium or High depending on context.

But:

Weak Service Account
       ↓
Server Admin
       ↓
Privileged Server
       ↓
Domain Admin Session
       ↓
Domain Control

can represent a much more serious risk.

Always analyse the chain.

113. Root Cause Analysis

Multiple findings may indicate:

Weak Privileged Access Governance

Excessive Delegation

Legacy Authentication

Poor Service Account Management

Insufficient Administrative Tiering

Weak Credential Hygiene

These themes are more useful to enterprise defenders than dozens of isolated observations.

114. Active Directory Security Themes

Common themes include:

Identity Governance

Who has access and why?

Privileged Access

Who can administer critical systems?

Credential Security

Where can reusable credentials appear?

Authentication

Which authentication mechanisms exist?

Delegation

Who can control other identities?

Trust

Which systems and domains trust each other?

Detection

Can suspicious identity activity be detected?

115. Remediation Priority

Prioritise controls that break important attack paths.

For example:

Standard User
     ↓
Service Account
     ↓
Server Admin
     ↓
Domain Admin

Potential actions:

Fix service-account credential security.
Remove excessive service-account privilege.
Restrict privileged logons.
Segment administrative access.
Improve identity monitoring.

Breaking one relationship may eliminate the complete path.

116. Active Directory Security Checklist

[ ] Scope confirmed
[ ] Domain identified
[ ] Forest structure understood
[ ] Domain Controllers identified
[ ] DNS configuration reviewed
[ ] Current security context documented
[ ] Users enumerated
[ ] Groups enumerated
[ ] Nested memberships analysed
[ ] Computers enumerated
[ ] Privileged identities identified
[ ] High-value systems identified
[ ] Password policy reviewed
[ ] Lockout policy reviewed
[ ] Service accounts reviewed
[ ] SPNs reviewed
[ ] Kerberos configuration considered
[ ] NTLM exposure considered
[ ] Local administrator strategy reviewed
[ ] Credential reuse risks reviewed
[ ] Administrative sessions considered
[ ] Remote management paths reviewed
[ ] Group Policy permissions reviewed
[ ] SYSVOL reviewed
[ ] AD ACL relationships analysed
[ ] Delegated permissions reviewed
[ ] Trust relationships reviewed
[ ] AD CS reviewed where present
[ ] Kerberos delegation reviewed
[ ] Administrative tiering reviewed
[ ] Privileged access workstations considered
[ ] Hybrid identity reviewed where present
[ ] Identity synchronisation reviewed
[ ] Lateral movement paths analysed
[ ] Privilege escalation paths analysed
[ ] Attack paths developed
[ ] Detection capabilities considered
[ ] Evidence collected
[ ] Findings validated
[ ] Root causes identified
[ ] Recommendations developed
[ ] Cleanup completed

117. Build Your Active Directory Security Toolkit

Create:

Active Directory Security Toolkit/
│
├── 01 AD Scope Template
├── 02 Domain Enumeration Checklist
├── 03 User Enumeration
├── 04 Group Enumeration
├── 05 Computer Enumeration
├── 06 Privileged Group Review
├── 07 Password Policy Review
├── 08 Service Account Review
├── 09 Kerberos Review
├── 10 NTLM Review
├── 11 Local Administrator Review
├── 12 GPO Security Review
├── 13 AD ACL Review
├── 14 AD CS Review
├── 15 Delegation Review
├── 16 Trust Review
├── 17 Hybrid Identity Review
├── 18 Lateral Movement Worksheet
├── 19 Attack Path Register
├── 20 Evidence Log
├── 21 Finding Template
└── 22 AD Security Report Template

118. Practical Lab Scenario

Assume the following isolated domain:

Domain:
corp.lab

Domain Controller:
DC01

Servers:
APP01
FILE01

Workstation:
WS01

Users:
alice
helpdesk01
serveradmin01

Service Account:
svc_app

You begin with:

CORP\alice

Your mission:

Determine whether the standard user identity has any indirect path toward privileged server access.

119. Step 1 — Establish Context

Document:

Identity:
CORP\alice

Host:
WS01

Domain:
corp.lab

Review group membership and privileges.

Suppose Alice is only a standard user.

Do not conclude the environment is secure.

120. Step 2 — Enumerate the Environment

Identify:

DC01

APP01

FILE01

Users

Groups

Service Accounts

Create your initial directory map.

121. Step 3 — Analyse Relationships

Suppose you discover:

alice
  ↓
Application Support

The group appears harmless.

Continue analysing.

122. Step 4 — Identify Delegated Rights

Suppose:

Application Support
       ↓
Can Manage
       ↓
svc_app

Now investigate the service account.

123. Step 5 — Analyse the Service Account

Suppose:

svc_app
   ↓
Local Administrator
   ↓
APP01

Your path becomes:

alice
 ↓
Application Support
 ↓
Control of svc_app
 ↓
APP01 Administrator

The relationship is more important than any individual account.

124. Step 6 — Analyse APP01

Suppose APP01 is regularly administered by:

serveradmin01

You now have a potential credential exposure path:

alice
 ↓
svc_app
 ↓
APP01
 ↓
Privileged Administrative Activity

Do not automatically attempt credential theft.

First determine whether sufficient evidence already demonstrates the risk.

125. Step 7 — Build the Attack Path

Document:

CORP\alice
     ↓
Application Support
     ↓
Delegated Control
     ↓
svc_app
     ↓
Local Administrator
     ↓
APP01
     ↓
Privileged Administrative Exposure

This is a meaningful identity attack path.

126. Step 8 — Identify Root Causes

Potential root causes:

Excessive Delegation

Overprivileged Service Account

Weak Administrative Tiering

Three security controls contributed to the path.

127. Step 9 — Develop Recommendations

Possible remediation:

Remove unnecessary control over svc_app.
Reduce svc_app privileges.
Use a managed service identity where appropriate.
Restrict privileged administrator logons.
Separate administrative tiers.
Monitor privileged authentication.
Periodically review AD attack paths.

This breaks the chain at multiple points.

128. Step 10 — Record Evidence

Example:

AD-EV-001 — Alice Group Membership

AD-EV-002 — Application Support Delegation

AD-EV-003 — svc_app Rights

AD-EV-004 — APP01 Administrative Relationship

AD-EV-005 — Attack Path Diagram

Each evidence item supports the final conclusion.

129. Active Directory Hacker Mindset

When you see:

User

do not think only:

Password.

Think:

Which Groups?
   ↓
Which Permissions?
   ↓
Which Systems?
   ↓
Which Sessions?
   ↓
Which Delegated Rights?
   ↓
Which Attack Paths?

When you see:

Service Account

think:

Which SPN?
   ↓
Which Credential?
   ↓
Which Systems?
   ↓
Which Privileges?
   ↓
Interactive Login?
   ↓
Managed Identity?

When you see:

Group

think:

Which Members?
   ↓
Nested Groups?
   ↓
Which Permissions?
   ↓
Which Systems?
   ↓
Can Membership Be Modified?

130. Think in Graphs

Do not think:

User

Computer

Group

Think:

User
 ↓
Member Of
 ↓
Group
 ↓
Admin To
 ↓
Computer
 ↓
Session
 ↓
Privileged User

This mental model is one of the biggest improvements you can make in Active Directory security testing.

131. Common Active Directory Testing Mistakes

Avoid:

Searching Only for Domain Admins

Many indirect paths lead to high privilege.

Focusing Only on Passwords

Permissions and trust are equally important.

Ignoring Service Accounts

Service identities frequently hold excessive privilege.

Ignoring GPO Permissions

Control of policy may equal control of systems.

Ignoring AD ACLs

Directory permissions can create hidden privilege.

Ignoring AD CS

Certificate infrastructure can become part of authentication attack paths.

Ignoring Local Administrators

Local administrative relationships enable lateral movement.

Ignoring Management Infrastructure

Enterprise management platforms may be more powerful than individual servers.

Running Credential Attacks Without Approval

Credential testing can disrupt accounts and trigger operational impact.

Treating Tool Output as Proof

Validate relationships and security impact.

132. The Most Important Active Directory Questions

For every identity ask:

What groups does it belong to?

What can it control?

Where can it log in?

Which systems does it administer?

Which credentials could it expose?

For every system ask:

Who can administer it?

Which privileged users log into it?

Which services run there?

What other systems can it reach?

For every group ask:

Who are the members?

Who can modify membership?

What permissions does the group provide?

For every privileged account ask:

Where is it allowed to authenticate?

Is MFA used where supported?

Is privilege permanent?

Is activity monitored?

133. Think About Attack Paths, Not Techniques

An immature tester thinks:

Kerberoasting

Pass-the-Hash

BloodHound

Password Spraying

A mature Ethical Hacker thinks:

Initial Identity
      ↓
Relationship
      ↓
Privilege Opportunity
      ↓
Security Control Failure
      ↓
Higher-Value Identity
      ↓
Critical Asset
      ↓
Business Impact

Techniques are tools for validating the path.

The attack path is the real security problem.

134. Think Like the Defender

For every discovered attack path ask:

What Preventive Control Should Break It?

What Detective Control Should Identify It?

Who Owns the Control?

How Could the Architecture Be Improved?

Example:

Standard User
     ↓
Weak Service Account
     ↓
Server Admin

Preventive controls:

Managed Service Account

Strong Credential

Least Privilege

Detective controls:

Kerberos Monitoring

Unusual Authentication Detection

Privileged Activity Monitoring

This makes your assessment actionable.

135. Definition of Success

A successful Active Directory assessment is not:

I ran BloodHound.

It is not:

I found Domain Admins.

It is not:

I obtained a password hash.

A successful assessment explains:

Initial Access
     ↓
Identity
     ↓
Permission
     ↓
Trust
     ↓
Credential
     ↓
Privilege
     ↓
Critical System
     ↓
Enterprise Impact

and identifies the controls that should break the path.

Key Takeaways

Active Directory is the identity backbone of many enterprise environments.

Remember:

Active Directory security is relationship security.

A standard user can have indirect privilege through groups, ACLs, delegation, service accounts, or system access.

Domain Admin is not the only high-impact privilege.

Kerberos and NTLM must be understood, not merely memorised.

Service accounts can create major attack paths.

Credential reuse increases lateral movement risk.

Administrative sessions can expose privileged identities to lower-trust systems.

Group Policy permissions can become privilege escalation paths.

AD ACLs can reveal hidden control relationships.

Certificate Services may be part of the authentication security boundary.

Hybrid identity connects on-premises Active Directory with cloud environments.

Graph analysis helps reveal relationships that traditional lists hide.

Attack paths matter more than individual techniques.

The best remediation breaks important attack paths at multiple points.

Your core methodology is:

Scope
  ↓
Understand Domain
  ↓
Enumerate Identities
  ↓
Enumerate Systems
  ↓
Map Groups
  ↓
Analyse Authentication
  ↓
Analyse Permissions
  ↓
Analyse Credentials
  ↓
Analyse Service Accounts
  ↓
Analyse GPO / ACL / AD CS
  ↓
Map Trust
  ↓
Identify Privilege Paths
  ↓
Analyse Lateral Movement
  ↓
Build Attack Paths
  ↓
Validate
  ↓
Evidence
  ↓
Report
  ↓
Recommend

The strongest Active Directory Ethical Hackers understand:

identity, authentication, authorization, permissions, credentials, trust, privilege, systems, and attack paths.

What’s Next?

➡️ 05 — Wireless Security

In the next module, you will move from enterprise directory and identity infrastructure into the security of wireless networks.

You will learn how to assess:

Wireless networking fundamentals
802.11 architecture
Access points
Clients
SSIDs
BSSIDs
Channels
Wireless frames
WPA2
WPA3
Personal vs Enterprise authentication
802.1X
RADIUS
Wireless reconnaissance
Wireless encryption
Authentication security
Guest wireless
Corporate wireless
Rogue access points
Evil twin concepts
Wireless segmentation
Client isolation
Enterprise wireless attack surfaces
Wireless evidence collection
Wireless security findings

The focus will remain on controlled, authorised security assessment.

You will move from asking:

Which identities and permissions create paths through the enterprise?

to asking:

Can an attacker within wireless range obtain network access, compromise trust, or cross wireless security boundaries?