Directory Services Security

1. Active Directory as the Crown Jewel

Why AD is Target #1

Active Directory is present in over 90% of enterprise environments worldwide and manages authentication and authorization for virtually every Windows resource. Compromising AD means compromising everything.

Domain Controllers are the authentication authority for all Windows systems in the forest — every Kerberos ticket, every file share, every application that trusts AD is controlled from there
Ransomware operators have standardized on AD compromise before deployment: encrypt AD replication, domain controllers go offline, nothing can authenticate, entire enterprise freezes
AD attack paths are well-documented, tooled (BloodHound, Impacket, CrackMapExec), and widely available — script-kiddie level attacks on unpatched AD are feasible
Domains: Single administrative boundary. Forests: Collection of domains sharing schema, global catalog, and configuration. Trusts: Relationships allowing cross-domain/forest authentication — often misconfigured and over-permissive.
The "keys to the kingdom" metaphor understates it: Domain Admin doesn't just own the kingdom, they own every copy of every key that has ever existed in it

Active Directory Attack Taxonomy

Understanding the attack surface requires knowing the specific techniques attackers use. Each maps to specific detection opportunities and hardening controls.

Kerberoasting: Request Kerberos service tickets (TGS) for accounts with Service Principal Names (SPNs). TGS is encrypted with the service account's NTLM hash. Crack offline to get plaintext password. Targets: service accounts running as domain users with SPNs.
AS-REP Roasting: Accounts with "Do not require Kerberos pre-authentication" enabled can have their AS-REP response cracked offline without any authentication. Often an oversight on service or legacy accounts.
Pass-the-Hash (PtH): Use captured NTLM hash directly for authentication without knowing the plaintext password. Lateral movement technique enabled by NTLM authentication.
Pass-the-Ticket (PtT): Inject a stolen Kerberos ticket (TGT or TGS) into a Windows session to authenticate as that user without a password.
DCSync: Impersonate a Domain Controller's replication request to extract password hashes for any account in the domain, including krbtgt. Requires Replicating Directory Changes All privilege — often held by AD sync accounts.
Golden Ticket: Forge a TGT using the krbtgt account hash. Valid for any service in the domain without further DC interaction. Persists even after password resets of user accounts.
Silver Ticket: Forge a TGS for a specific service using that service account's hash. Narrower scope than Golden Ticket but requires no DC communication after forging.

BloodHound & Attack Path Visualization

BloodHound is an open-source AD attack path analysis tool used by both attackers and defenders. It ingests AD data and graphs privilege escalation paths using graph theory.

BloodHound collects AD object data via SharpHound (C# collector) and maps relationships: user → group → computer → admin rights → domain admin
Attack path queries: "Find all paths from 'helpdesk' to 'Domain Admins'" — reveals chains of permissions that individually seem low-risk but chain to full compromise
Defenders use BloodHound to find and sever attack paths before attackers can exploit them — most organizations find hundreds of unexpected paths
Common findings: service accounts with local admin rights on many servers (enable DCSync via LSASS), GenericAll rights chains, unconstrained delegation targets
BloodHound Enterprise (commercial): continuous monitoring, attack path tracking over time, remediation prioritization by blast radius

Offensive toolAlso defensive

2. Hardening Active Directory

AD Tiering Model

Microsoft's Active Directory Tier model (0/1/2) prevents privilege escalation by creating administrative isolation between asset classes. A compromise at a lower tier cannot reach higher-tier assets.

Tier 0 (Forest Root): Domain Controllers, PKI/CA servers, AD FS, Azure AD Connect, privileged admin workstations (PAWs) for Tier 0 admins. Compromise = full forest compromise.
Tier 1 (Member Servers): Application servers, file servers, SQL servers, Exchange, web servers. Tier 1 admins manage these but cannot authenticate to Tier 0 systems.
Tier 2 (Workstations & Users): End-user workstations, regular user accounts, help desk accounts. The most exposed tier — faces phishing, malware, and user errors daily.
Authentication Policy Silos enforce tier separation at the Kerberos level: a Tier 2 admin account's TGT will be rejected if used to authenticate to a DC (Tier 0)
Dedicated admin accounts per tier: one user may have a workstation account (Tier 2), a server admin account (Tier 1), and a domain admin account (Tier 0) — used only on appropriate PAWs

Critical Hardening Controls

Beyond tiering, specific AD configurations dramatically reduce the attack surface against common AD attack techniques.

Protected Users Security Group: Membership blocks NTLM auth (eliminates PtH for these accounts), forces Kerberos, prevents RC4/DES encryption (forces AES), blocks credential caching. Add all admin accounts.
Credential Guard: VBS-based LSASS isolation. NTLM and Kerberos credentials are stored in an isolated VM (VSM) inaccessible to kernel-mode attackers. Defeats most Mimikatz variants.
LAPS v2: Random local admin passwords per machine. Eliminates the single-password lateral movement path. Stores passwords in AD with fine-grained access control on who can read them.
Disable Legacy Protocols: Block LM authentication (GPO: LAN Manager authentication level = NTLMv2 only). Disable SMBv1. Disable NTLMv1. Block NTLM where Kerberos is available.
Audit Policy: Enable advanced audit policies for Account Logon, Account Management, Directory Service Access, Logon/Logoff, and Privilege Use. Forward to SIEM.
Privileged Access Workstations (PAWs): Dedicated hardened workstations for Tier 0 and Tier 1 admin tasks. No browsing, no email, no non-admin software. Air-gapped from standard user network where possible.

# Key AD hardening PowerShell commands

# Find accounts vulnerable to Kerberoasting (have SPNs and are not krbtgt)
Get-ADUser -Filter {ServicePrincipalName -ne "$null" -and Enabled -eq $true} `
    -Properties ServicePrincipalName,PasswordLastSet | `
    Select Name, ServicePrincipalName, PasswordLastSet

# Find accounts vulnerable to AS-REP Roasting
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth

# Check password policy (weak policy enables faster offline cracking)
Get-ADDefaultDomainPasswordPolicy

# Find accounts with DCSync rights (Replicating Directory Changes All)
# WARNING: Any non-DC account with this right can run DCSync
$dcSyncRights = @("DS-Replication-Get-Changes-All","DS-Replication-Get-Changes")
# Use AD ACL audit tooling (e.g., BloodHound or AD ACL Scanner) for full review

# Add all privileged accounts to Protected Users group
Add-ADGroupMember -Identity "Protected Users" -Members "DomainAdmin1","ServiceAccountCritical"

# Enable Credential Guard via Group Policy (requires UEFI + Secure Boot + TPM)
# Computer Config > Admin Templates > System > Device Guard
# "Turn On Virtualization Based Security" = Enabled
# "Credential Guard Configuration" = Enabled with UEFI lock

# Check Credential Guard status
Get-ComputerInfo | Select DeviceGuardSecurityServicesRunning

# LAPS v2: Update policy to use Windows LAPS (built into Windows 2022/11)
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=local"
Get-LapsADPassword -Identity "PC001" -AsPlainText

# Disable NTLMv1 via registry (also enforce via GPO)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
    -Name "LmCompatibilityLevel" -Value 5  # NTLMv2 only, refuse LM/NTLMv1

3. Active Directory Attack Detection

Event ID	Description	Attack Relevance	Detection Logic
4769	Kerberos TGS request	Kerberoasting: RC4 (0x17) encryption type requested for SPN	Alert on 4769 with TicketEncryptionType = 0x17 AND ServiceName != krbtgt
4768	Kerberos TGT request	AS-REP Roasting: preauth failure pattern	Alert on account with PreAuthType = 0 (no preauth required)
4624	Successful logon	PtH: LogonType 3 (network) with NTLM auth from unexpected source	Baseline + anomaly: NTLM network logon to DC outside normal pattern
4625	Failed logon	Brute force, spray	Alert on 10+ failures in 5 minutes for same account or same source
4648	Explicit credentials logon	Pass-the-Hash lateral movement	Alert when non-interactive process uses explicit credentials to remote hosts
4662	Object operation on AD object	DCSync: replication rights exercised by non-DC account	Alert on 4662 with Property 1131f968 (Replicating Directory Changes All) from non-DC source
4720	User account created	Persistence: attacker creates backdoor account	Alert on any account created outside business hours or by non-standard admin
4732	Member added to security group	Privilege escalation: adding to Domain Admins, Schema Admins	Alert on any modification to Tier 0 groups (Domain Admins, Enterprise Admins, Schema Admins)
7045	New service installed	Persistence: malicious service or remote code execution via PsExec	Alert on new service created by non-standard account, especially SYSTEM-level services
4776	NTLM credential validation	PtH / NTLM relay: NTLM auth from unexpected location	Alert on NTLM auth to DCs from non-domain-joined or external sources

Microsoft Defender for Identity (MDI)

MDI (formerly Azure ATP) is Microsoft's cloud-based AD threat detection platform. It ingests Windows Event Logs and network traffic from DCs and provides behavioral analytics and attack path detection.

Behavioral Baselining: Learns normal authentication patterns for each user and computer. Anomalies (first-time admin access, unusual service usage, abnormal hours) generate alerts.
Lateral Movement Paths: Identifies and visualizes the same attack paths BloodHound shows — but continuously and with real-time alert when paths change or are exploited.
Built-in Detections: Kerberoasting, AS-REP Roasting, DCSync, Golden/Silver Ticket, Pass-the-Hash, Mimikatz usage, LDAP enumeration, directory service reconnaissance
ITDR (Identity Threat Detection & Response): MDI feeds into Microsoft Defender XDR for correlated attack story across endpoint, identity, email, and cloud
MDI sensor deployed on every Domain Controller — captures authentication events without agent changes to the DC OS

DCSync Detection

DCSync is one of the most dangerous AD attacks — it extracts all password hashes from the domain without touching any individual account. Detecting it requires monitoring AD replication operations.

DCSync works by sending a GetNCChanges RPC request using replication rights — the same mechanism legitimate DCs use to sync with each other
Detection: Event 4662 on Domain Controllers with Object Type = domainDNS and Property GUID 1131f968 (DS-Replication-Get-Changes-All) from any account that is NOT a DC computer account
Legitimate sources: AD Sync (Entra ID Connect), backup solutions — whitelist these. Alert on everything else.
Preventive control: audit and remove Replicating Directory Changes All from any account that doesn't explicitly require it. This permission should exist on DCs and the designated sync account only.
If Entra ID Connect account gets compromised, DCSync is a single API call away — protect and vault the sync account credentials aggressively

4. Azure Active Directory / Entra ID Security

Hybrid Identity Attack Paths

Organizations running Entra ID Connect to sync on-prem AD with Entra ID have created a bidirectional trust that attackers exploit to bridge environments.

On-prem to Cloud: Compromise AD → compromise AD Connect sync account → DCSync the cloud tenant password hashes → full Entra ID compromise
Cloud to On-prem: Compromise Global Admin in Entra ID → modify AD Connect sync service → push malicious attributes or passwords back to on-prem AD
The AD Connect (Entra Connect) server is a Tier 0 asset — it must be protected like a Domain Controller, isolated in the Tier 0 network, with vaulted credentials
The MSOL_xxxxxxxx service account used by AD Connect has DCSync-equivalent rights on-prem by default — monitor it strictly
Staging mode: configure a second AD Connect server in staging — provides recovery but also doubles the attack surface

Entra ID-Specific Attack Vectors

Cloud identity introduces new attack vectors unique to OAuth, device code flows, and app consent frameworks that don't exist in on-prem AD.

Device Code Phishing: Attacker initiates OAuth device code flow, tricks target into entering the code at microsoft.com/devicelogin. No password needed — attacker gets a valid access token.
OAuth App Consent Attacks (Illicit Consent Grant): Malicious OAuth app registered in another tenant requests permissions to access victim's data. User approves, granting the app persistent access.
Service Principal Abuse: Over-permissioned app registrations (client secrets or certificates) can access tenant resources. Leaked client secrets are equivalent to user credentials.
Legacy Authentication Bypass: SMTP, POP3, IMAP, and basic auth protocols bypass MFA. Disable legacy auth via Conditional Access to close this gap.
Entra ID Sign-in logs capture all authentication events — export to SIEM and alert on legacy auth, impossible travel, and unfamiliar locations

Entra ID Hardening Controls

A prioritized set of Entra ID hardening measures that address the most common cloud identity attack vectors.

Disable Legacy Authentication: Create Conditional Access policy blocking legacy auth protocols for all users. This alone blocks the majority of password spray attacks against cloud identities.
Security Defaults or Conditional Access: For small orgs, Security Defaults provides baseline MFA and legacy auth blocking. For enterprise, replace with granular Conditional Access policies.
PIM for Entra Roles: No standing Global Administrator assignments. All Entra admin roles use JIT activation through Azure AD PIM with MFA step-up and approval workflow.
App Consent Policies: Restrict user consent to apps from verified publishers or disable user consent entirely — require admin approval for all OAuth app consent grants.
Risky Sign-in Response: Identity Protection policies: auto-block high-risk sign-ins, require MFA for medium-risk. Review risk detections weekly.
Emergency Access Accounts: Two cloud-only Global Admin accounts with hardware FIDO2 keys, no MFA app dependency, stored offline. Test monthly.

5. LDAP Security

LDAP Protocol Security

LDAP (Lightweight Directory Access Protocol) on port 389 transmits credentials and directory data in cleartext. LDAPS (LDAP over TLS) on port 636 encrypts the connection — its use is mandatory for any production environment.

LDAP (port 389): Unencrypted. Credentials visible on the network. Never use for authentication in production environments.
LDAPS (port 636): TLS tunnel from connection establishment. Certificates required on the server side. Preferred approach.
StartTLS (port 389 + STARTTLS extension): Upgrades cleartext LDAP to TLS mid-connection. Less secure than LDAPS (initial negotiation is cleartext, subject to downgrade attacks). Use LDAPS instead.
Microsoft LDAP Channel Binding and Signing (2020 update): requires signed LDAP connections to DCs. Enable both Channel Binding and LDAP Signing in Domain Controller GPO.
Verify LDAP signing enforcement: any app that breaks after enforcing should be updated, not exempted

LDAP Injection

LDAP injection attacks occur when user-supplied input is incorporated into LDAP filter queries without proper sanitization, allowing attackers to manipulate directory queries.

Vulnerable code concatenates user input into LDAP filter: (&(uid=USER_INPUT)(userPassword=PASS_INPUT))
Attacker input *)(uid=*) transforms query to (&(uid=*)(uid=*)(userPassword=x)) — returns all users regardless of password
Mitigation: Escape special LDAP characters: ( ) * \ NUL in user-supplied input before including in filter strings
Use LDAP libraries that support parameterized queries rather than string concatenation
Input validation: reject inputs containing LDAP filter metacharacters if not explicitly needed
Principle of least privilege for the LDAP bind account: read-only access to only required attributes, not full directory read

LDAP in Applications — Security Best Practices

Applications frequently use LDAP for authentication and directory lookups. Misconfigured LDAP integrations are a common source of credential exposure and over-permission.

Avoid Anonymous Bind: Disable anonymous LDAP binds on the directory server. Applications should authenticate with a dedicated service account before querying.
Dedicated Bind Account: Each application gets its own LDAP service account with only the attributes it needs to read. No write access unless required. Vault the credentials.
Minimal Attribute Access: Bind account should be granted read access only to the OU and attributes the application requires — not the entire directory tree.
LDAPS for All Connections: Every application that authenticates against LDAP must use LDAPS (port 636) or StartTLS. Cleartext LDAP binds expose credentials on the wire.
Detect LDAP Enumeration: Monitor for high-volume LDAP queries (directory enumeration), especially broad searches like (objectClass=*) from unexpected sources — a common pre-attack reconnaissance step.
Log LDAP queries at the directory level and forward to SIEM — attackers enumerate AD via LDAP before launching targeted Kerberoasting or BloodHound collection

Domain Controllers Deserve Physical Security Controls

Active Directory is present in 90%+ of enterprise environments and is the first system ransomware operators enumerate and target for full compromise. Domain Controllers should be treated as critical infrastructure: physical security controls (locked server rooms, camera surveillance), no direct internet access, no browsing or email from DCs, regular patching within 48 hours of critical AD/Windows updates, and network segmentation that prevents workstations from directly reaching DCs on non-standard ports. A Domain Controller that is compromised is not just a server incident — it is a full organizational breach requiring complete AD rebuild to fully remediate.