Active Directory is the backbone of most corporate networks - and the most common path to complete compromise. In my tests, I see the same misconfigurations in 90% of Slovenian companies. Mistakes that allow an attacker to go from regular user to complete control in hours.
Why Active Directory Always Fails
The problem isn't the technology itself. The problem is years of accumulated technical debt, "temporary" solutions that became permanent, and a lack of understanding of how attackers actually think.
Auditors look at configurations. I look at paths. A configuration can be "correct" by all standards and still allow full compromise. This is the essential difference between a compliance approach and an attacker's approach.
NTLM Relay Attacks
NTLM is a legacy authentication protocol that most environments still use for compatibility. The problem? NTLM authentication can be intercepted and relayed to other systems.
How It Works
When a user attempts to authenticate to an attacker-controlled system (via SMB, HTTP, LDAP), the attacker relays that authentication to a legitimate server. The server thinks the original user is authenticating.
Conditions for Successful Attack
- SMB signing disabled - Disabled by default on most systems except domain controllers
- LLMNR/NBT-NS enabled - Enabled by default in Windows environments, allows query interception
- IPv6 not managed - Attacker becomes DHCPv6 server and redirects traffic
- WebDAV enabled - Enables relay over HTTP, bypasses SMB signing
Relay Targets
- LDAP(S) - Creating users, modifying group memberships, Resource-Based Constrained Delegation (RBCD)
- SMB - Executing commands on remote systems
- ADCS (Active Directory Certificate Services) - Issuing certificates for intercepted users (ESC8)
- HTTP - Exchange, SCCM, other web services
Protection
- Enable SMB signing on all systems (not just DC)
- Disable LLMNR and NBT-NS via GPO
- Implement EPA (Extended Protection for Authentication)
- Disable NTLM where possible, use Kerberos
- Manage IPv6 or disable it completely
Kerberos Attacks
Kerberos is the default authentication protocol in Active Directory. Despite being more secure than NTLM, it has its vulnerabilities - mostly due to misconfigurations and weak passwords.
Kerberoasting
Any domain user can request a TGS (Ticket Granting Service) ticket for service accounts (accounts with SPN - Service Principal Name). This ticket is encrypted with the service account's password.
Attack: I request TGS for all service accounts, take them offline, and crack the passwords. If the service account has a weak password (which most do), I crack it in minutes.
Why it's critical: Service accounts often have Domain Admin privileges or access to critical systems. And they often have passwords that haven't changed in years.
AS-REP Roasting
If a user account has "Do not require Kerberos preauthentication" enabled (DONT_REQUIRE_PREAUTH), an attacker can request an AS-REP without knowing the password. This response is encrypted with the user's password.
Attack: I find accounts without preauthentication, request AS-REP, crack the password offline.
Delegation
Kerberos delegation allows a service to act on behalf of a user. There are three types:
- Unconstrained Delegation - Server can obtain TGT of any user who connects. If I gain access to such a server, I can wait for an administrator and steal their TGT.
- Constrained Delegation - Server can only delegate to specific services. However, an attacker with access to such an account can delegate to any service on the list.
- Resource-Based Constrained Delegation (RBCD) - Configured on the target account. If I can modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, I can configure delegation to that account.
Protection Against Kerberos Attacks
- Use Group Managed Service Accounts (gMSA) - 240-character complex passwords that auto-rotate
- Require Kerberos preauthentication for all accounts
- Avoid unconstrained delegation - use constrained or RBCD
- Monitor SPNs on user accounts
- Implement long, complex passwords for service accounts (25+ characters)
Active Directory Certificate Services (ADCS) Attacks
ADCS is often overlooked but an extremely powerful attack vector. Misconfigured ADCS can allow an attacker to issue certificates for any user - including Domain Admins.
Most Common Vulnerabilities (ESC1-ESC8)
ESC1 - Certificate Template Misconfiguration
Template allows the requester to specify an alternative name (SAN). Attacker requests certificate for Domain Admin.
ESC4 - Vulnerable ACL on Template
Attacker can modify the certificate template and turn it into a vulnerable version (ESC1).
ESC6 - EDITF_ATTRIBUTESUBJECTALTNAME2
This flag allows the requester to add SAN to any request. If enabled, every template is vulnerable.
ESC8 - NTLM Relay to ADCS Web Enrollment
If ADCS web enrollment has HTTP enabled (without HTTPS or EPA), an attacker can relay NTLM authentication and obtain a certificate for the victim.
Consequences
With a valid certificate for Domain Admin, I can:
- Authenticate as Domain Admin via PKINIT
- Use certificate for UnPAC-the-hash and obtain NTLM hash
- Persistence - certificates are valid for years, even if password changes
ADCS Protection
- Audit all certificate templates - remove SAN capability
- Limit enrollment rights to minimum necessary
- Enable Manager Approval for sensitive templates
- Disable EDITF_ATTRIBUTESUBJECTALTNAME2
- Require HTTPS and EPA for web enrollment
Path to Domain Admin - Real Scenario
A typical attack in a Slovenian company goes like this:
- Initial Access - Phishing, VPN with compromised credentials, exposed service
- Enumeration - BloodHound analysis, finding misconfigurations
- Kerberoasting - Obtain hash of service account with local admin rights
- Password cracking - Password "Spring2024!" cracked in 30 seconds
- Lateral movement - Access to server with LSASS dump
- Credential harvesting - Domain Admin NTLM hash in memory
- DCSync - Replication of all hashes from domain controller
- Golden Ticket - Persistent access that survives password changes
The entire process? 2-4 hours from initial access to full domain compromise.
What Actually Works for Protection
Tiered Administration Model
Separate administrative accounts based on system sensitivity:
- Tier 0 - Domain controllers, ADCS, Azure AD Connect
- Tier 1 - Servers, applications
- Tier 2 - Workstations, users
A Tier 0 admin never logs into a Tier 2 system. If they do, an attacker on the workstation obtains Tier 0 credentials.
Local Administrator Password Solution (LAPS)
Unique, random local administrator password on each workstation. Without LAPS, one compromised password allows access to all systems with the same password.
Protected Users Group
Members of this group have additional protections:
- NTLM authentication disabled
- Kerberos delegation disabled
- TGT validity reduced to 4 hours
- Credentials not cached in LSASS
Credential Guard
Isolates LSASS in a virtualized enclave. Even with administrator access, an attacker cannot dump credentials from memory.
My Approach to AD Penetration Testing
I don't just run scans. I simulate a real attacker:
- BloodHound analysis - Visualization of all attack paths to high privileges
- Manual exploitation - I don't rely only on tools, I understand every step
- Proof of Concept - I demonstrate actual impact, not just theoretical vulnerability
- Remediation - Concrete, prioritized recommendations for fixes