Active Directory Security Audit: Finding and Closing Attack Paths in AD

"We've been compromised—the attacker had Domain Admin privileges." This is the conclusion of most Windows network compromises. Active Directory isn't just the heart of the Windows infrastructure—it's the primary target. An attacker who gains Domain Admin privileges controls all systems, all passwords, and all data across the entire Windows environment.

Why AD Is the Preferred Target

Domain Admin is the master key: whoever possesses it can administer all Windows systems in the domain, extract all hashes from NTDS.DIT (DCSync), create Kerberos tickets for any account (Golden Ticket), and exploit trusts to other domains (Forest Compromise).

The numbers speak for themselves: 80% of all incidents used Active Directory as an entry point or a path to Domain Admin. According to CrowdStrike, the average time from initial compromise to gaining Domain Admin privileges is just 1.5 hours. The most common attack vectors are Kerberoasting (60%), LLMNR Poisoning (50%), and AS-REP Roasting (30%).

The typical AD attack lifecycle follows a clear pattern:

1. Initial Access (phishing, exploit)
2. Local Privilege Escalation (local admin)
3. Credential Harvesting (Mimikatz, LSASS)
4. Lateral Movement (Pass-the-Hash, Pass-the-Ticket)
5. Domain Privilege Escalation (Kerberoasting, AS-REP, DCSync)
6. Persistence (Golden Ticket, DCSync Backdoor, Skeleton Key)

Phase 1: Audit Preparation and Scoping

An AD audit covers the following core objects:

• Domain Structure: Number of domains, trusts, functional levels
• Privileged Accounts: Domain Admins, Enterprise Admins, Schema Admins, Account Operators
• Kerberos Configuration: Encryption types, delegation
• Password Policies: Length, complexity, history, lockout
• GPOs: Critical GPO configurations
• LDAP Configuration: LDAP signing, LDAP channel binding
• Service Accounts: SPNs, password age, permissions
• Inactive Accounts: Users/computers inactive for > 90 days
• Local Admin Accounts: LAPS implemented?

The following tools are available for the audit:

Tool	Purpose	Cost
BloodHound + SharpHound	Attack path visualization	Free
PingCastle	AD Healthcheck Score	Free
Semperis Purple Knight	Free AD Assessment Tool	Free
Microsoft Defender for Identity	Real-time detection of AD attacks	License required
ADACLScanner	ACL analysis for all AD objects	free
PowerView (PowerSploit)	AD enumeration (for testers)	free

PingCastle is ideal for a quick assessment: After downloading from pingcastle.com, running pingcastle.exe --healthcheck --server dc01.company.com generates an HTML report with a score from 0 to 100 (100 = best result) and prioritized findings in the categories Privileged Accounts, Trusts, and Account Anomalies.

Phase 2: Analyze Privileged Accounts

The following PowerShell command lists all Domain Admins along with their relevant attributes:

Get-ADGroupMember "Domain Admins" -Recursive |
  Get-ADUser -Properties LastLogonDate, PasswordLastSet, Enabled |
  Select-Object Name, SamAccountName, LastLogonDate,
                PasswordLastSet, Enabled |
  Sort-Object LastLogonDate

The following findings are critical during the analysis:

• More than 5 members in the Domain Admins group (Best Practice: max. 2-3 genuine DA accounts)
• DA accounts with passwords older than 90 days
• DA accounts without a LastLogonDate (never used, but active)
• DA accounts used as mailbox accounts (spear-phishing risk)
• DA accounts used daily for normal work

The Enterprise Admins and Schema Admins groups should generally be empty. Enterprise Admins are only temporarily populated during forest changes, and Schema Admins only during schema extensions.

Get-ADGroupMember "Enterprise Admins"
Get-ADGroupMember "Schema Admins"

The Protected Users group (starting with Windows Server 2012 R2) offers additional protection: Members use only Kerberos (no NTLM, no CredSSP, no Digest), only AES encryption, and no credential caching on endpoints. DA, EA, and Schema Admins must be members of this group. Important: Test before adding them, as legacy apps may break.

Get-ADGroupMember "Protected Users"

Phase 3: Kerberoasting Attack Surface

Kerberoasting enables the offline cracking of service account passwords. How it works: Any authenticated domain user can query SPNs (Service Principal Names). An SPN identifies an account as a service account. The Kerberos service ticket (TGS) is encrypted with the service account hash and can then be cracked offline.

Kerberoastable accounts are identified using the following PowerShell command:

Get-ADUser -Filter {ServicePrincipalName -ne "$null" -and Enabled -eq $true} `
  -Properties ServicePrincipalName, PasswordLastSet, AdminCount |
  Select-Object SamAccountName, ServicePrincipalName, PasswordLastSet, AdminCount

Critical findings during the analysis:

• Service accounts with AdminCount=1 (privileged and Kerberoastable = most critical combination)
• Service accounts with passwords older than 1 year
• Service accounts that are members of the Domain Admins group
• SPNs on user accounts instead of computer accounts

As a countermeasure, all Kerberoastable accounts should be assigned passwords with more than 25 random characters. Even better are Group Managed Service Accounts (gMSA): Windows automatically manages the password with 240 characters and rotates it every 30 days. Since no one knows the password, Kerberoasting is practically impossible.

New-ADServiceAccount -Name "svc-webapp" -DNSHostName app.company.com `
  -PrincipalsAllowedToRetrieveManagedPassword "Server-Group"

For AS-REP Roasting, the following applies: Accounts with the "Kerberos pre-authentication not required" flag set can be attacked without a valid password. This flag is almost always misconfigured and should be set to $false.

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
  Select-Object SamAccountName, DistinguishedName

Phase 4: Kerberos Delegation Risks

Unconstrained Delegation is the most critical delegation scenario: The account can impersonate any user on any service. The attack works by forcing a domain controller to authenticate against a server with unconstrained delegation, thereby allowing the DA hash to be obtained.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties * |
  Select-Object Name, TrustedForDelegation
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties * |
  Select-Object Name, TrustedForDelegation

The expected result: Domain controllers only. Any other result is a critical finding.

Constrained Delegation (medium risk): The account is only allowed to impersonate a user for specific services. If the account is compromised, all permitted services are compromised.

Get-ADUser -Filter {msDS-AllowedToDelegateTo -ne "$null"} `
  -Properties 'msDS-AllowedToDelegateTo' |
  Select-Object Name,'msDS-AllowedToDelegateTo'

Each account found should be reviewed to determine whether the permission is actually necessary.

Resource-Based Constrained Delegation (RBCD): In the newer RBCD model, the target resource determines who is allowed to delegate. An attack using GenericWrite permissions on a computer object enables an RBCD attack. BloodHound finds these paths using the query "Principals with GenericWrite to computers".

Phase 5: BloodHound Analysis

BloodHound (Community Edition) is launched via Docker and is accessible at http://localhost:8080:

git clone https://github.com/SpecterOps/BloodHound
docker compose up -d

SharpHound collects data from Active Directory:

.\SharpHound.exe -c All -d firma.de

The most important BloodHound Cypher queries:

Shortest Paths to Domain Admin shows how many hops a compromised user needs to reach the Domain Admin:

MATCH p=shortestPath((n:User {name: "TESTUSER@FIRMA.DE"})-[*1..]->(m:Group {name: "DOMAIN ADMINS@FIRMA.DE"})) RETURN p

Users with DCSync Rights lists all accounts that can run DCSync and thus extract all password hashes:

MATCH (n1)-[:MemberOf|GetChanges*1..]->(u:Domain) RETURN n1
MATCH (n1)-[:MemberOf|GetChangesAll*1..]->(u:Domain) RETURN n1

Kerberoastable Admins - a Kerberoastable account that is also a Domain Administrator (DA) is the most critical finding possible:

MATCH (u:User {hasspn:true})-[:MemberOf*1..]->(g:Group {name:"DOMAIN ADMINS@FIRMA.DE"}) RETURN u

Computers with Unconstrained Delegation (outside DCs):

MATCH (c:Computer {unconstraineddelegation:true}) WHERE c.name <> "DC01.FIRMA.DE" RETURN c

The standard queries in BloodHound ("Find all Domain Admins", "Shortest Paths to Domain Admins from Owned Principals", "Find Principals with DCSync Rights", "Find Computers where Domain Users are Local Admin") cover the most important attack vectors.

Phase 6: Credential Theft Prevention

Credential Guard isolates LSASS in a separate process via Hyper-V, causing Mimikatz attacks (lsadump::lsa) to fail. Prerequisites are UEFI Secure Boot and Virtualization-based Security.

GPO path: Computer Configuration → Administrative Templates → System → Device Guard

• "Turn on Virtualization Based Security": Enabled
• Platform Security Level: Secure Boot and DMA Protection
• Credential Guard Configuration: Enabled with UEFI lock

PPL (Protected Process Light) protects LSASS at the kernel level:

• Registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1
• Alternatively via GPO: Security Options → Run LSASS as a protected process

Disable WDigest: WDigest stores plaintext passwords in LSASS and should be disabled in all modern environments:

• HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential = 0

Restrict NTLM: NTLM enables pass-the-hash attacks. Before restricting it, an audit should be performed to determine which systems still use NTLM:

Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
  Where-Object {$_.Id -eq 8004} |
  Select-Object TimeCreated, @{N="WorkstationName";E={$_.Properties[0].Value}},
                @{N="TargetName";E={$_.Properties[1].Value}}

GPO settings: Security Options → Network Security: Restrict NTLM → Incoming NTLM traffic: Deny all accounts; NTLM authentication in this domain: Deny all.

AD Audit Checklist

Critical - Fix immediately

• Unconstrained delegation on non-DCs
• Kerberoastable Domain Admins
• AS-REP roasting on privileged accounts
• DCSync permissions outside of DA/EA
• Direct pass-the-hash paths to Domain Admin (BloodHound)
• WDigest enabled (plaintext passwords)
• Enterprise/Schema Admins not empty
• Default Domain Admin (Administrator) used daily

High - within 30 days

• Domain Admins with more than 5 members
• DA accounts used as regular user accounts
• Protected Users Group empty (DA/EA not included)
• LAPS not implemented (local admin passwords not managed)
• NTLM not restricted
• Password policy with a minimum length of less than 12 characters
• Credential Guard not enabled
• Inactive accounts: more than 90 days without login (but active)

Moderate - within 90 days

• Service accounts without gMSA (manually managed passwords)
• Inactive computer objects (> 90 days)
• GPO delegation not documented
• Domain functional level < 2016
• LDAP signing not enforced
• LDAP channel binding not configured
• Tiered administration not implemented
• Privileged Access Workstations (PAWs) missing

Hardening Recommendations

For structured security, the Tiered Admin Model is recommended, with Tier 0 (Domain Admins), Tier 1 (Server Admins), and Tier 2 (Workstation Admins). Microsoft ESAE (Enhanced Security Admin Environment) provides a proven framework for this. Separate admin accounts for privileged tasks and JIT access for domain admins via Privileged Identity Management (PIM) round out the concept.

---

Active Directory security is not a one-time project—configurations change, new service accounts are created, and delegations are forgotten. AWARE7 conducts regular AD security audits and helps systematically reduce attack surfaces—from BloodHound analysis to tiered admin implementation.

Request an AD security audit | Network penetration test