Unveiling the Secrets of Domain Controllers: A Journey into Active Directory Security
8 min read
January 20, 2023
Table of contents
Introduction
In this journey through Active Directory security, we immerse ourselves in the pivotal role of Domain Controllers (DC). Positioned as central servers housing Active Directory Domain Services (AD DS), DCs play a fundamental role in maintaining the New Technologies Directory Services (NTDS) database. Not only do they oversee the database, but they also orchestrate authorization, authentication, and various essential services within the domain.
Domain Controllers
The NTDS database, located at "C:\Windows\NTDS," contains essential domain objects. Infiltrating this fortress through access to the NTDS file presents a substantial threat to the entire domain. It is crucial to comprehend interconnected services like DNS, LDAP, and SMB, among others, to ensure secure access to NTDS data. If these terms are unfamiliar, fret not—we'll delve into them in future articles, providing a comprehensive understanding of their roles and significance
Discovery Domain Controllers
Locating Domain Controllers within a domain is paramount. A non-intrusive method involves a DNS query using the nslookup tool. This query seeks servers with the Lightweight Directory Access Protocol (LDAP) service open, providing vital information about Domain Controllers.
C:\Users\Administrator>nslookup -q=srv _ldap._tcp.dc._msdcs.shadow.local
Server: UnKnown
Address: ::1
_ldap._tcp.dc._msdcs.shadow.local SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = DC-SHADOW.SHADOW.local
DC-SHADOW.SHADOW.local internet address = 192.168.253.130
An alternative, slightly more intrusive, approach involves using nmap to scan for LDAP port 389 openness.
┌──(rsgbengi㉿kali)-[~]
└─$ sudo nmap -sS --open -p389 192.168.253.0/24
Starting Nmap 7.93 ( https://nmap.org ) at 2023-01-15 10:54 CET
Nmap scan report for 192.168.253.130
Host is up (0.00023s latency).
PORT STATE SERVICE
389/tcp open ldap
MAC Address: 42:5A:97:56:1E:F6 (Unknown)
Nmap done: 256 IP addresses (3 hosts up) scanned in 3.86 seconds
For those who have compromised a user account, the nltest tool becomes handy in listing Domain Controllers.
C:\Users\Administrator> nltest /dclist:shadow.local
Get list of DCs in domain 'shadow.local' from '\\DC-SHADOW.SHADOW.local'.
DC-SHADOW.SHADOW.local [PDC] [DS] Site: Default-First-Site-Name
The command completed successfully
Dumping the NTDS: Unlocking the Heart of Active Directory
At the core of Active Directory lies the NTDS. Understanding how to obtain information from it becomes crucial. To dump the domain database, we have two main methods: one from the Domain Controller itself using tools like ntdsutil.exe or vssadmin, and another online using tools like impacket's secretsdump script or mimikatz with the lsadump::dsync command.
Dump from Domain Controller: Utilizing ntds.exe
Utilizing ntdsutil.exe allows us to save a snapshot of the database status, as demonstrated by the following command:
powershell "ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:\temp' q q"
In the screenshot above, the issued command performs a pivotal task: creating a copy of the NTDS and subsequent copies of the SYSTEM and SECURITY registry hives. While I'll delve into the intricacies of the SECURITY hive in forthcoming articles, the focus here is on the SYSTEM hive, housing the indispensable Syskey/BootKey. This key plays a paramount role in the decryption process, which unfolds across multiple levels:
- First Level: Decrypt the Password Encryption Key (PEK). The PEK is initially encrypted with the BootKey using RC4.
- Second Level: Initiate the first phase of decrypting hashes with the PEK using RC4.
- Third Level: Progress to the second phase of decrypting hashes using DES.
Acquiring the BootKey becomes the linchpin in this process. Once obtained, we gain the ability to decrypt the NTDS content, courtesy of accessing the PEK value. Remarkably, the PEK maintains a uniform value across all Domain Controllers. In contrast, the BootKey varies for each computer, underscoring its unique significance in this intricate decryption dance.
To access the Domain Controller, we leverage the smbclient tool from Impacket on our Kali Linux machine within the lab. This tool facilitates seamless file downloads from the remote machine, enhancing our control and maneuverability in the process.
By employing the secretsdump script, we execute an NTDS dump with a focus on the SYSTEM hive. This strategic dump empowers us to harvest valuable information, including domain users, alongside their corresponding NTLM hashes and Kerberos keys.
Copy NTDS using Volume Shadow Copy service: A Stealthy Approach
To duplicate the NTDS database through the Volume Shadow Copy service, we harness the functionalities of VSS—an ingenious service enabling the creation of backup copies of volumes even as applications actively engage with and write to them. For this task, Windows offers the vssadmin tool, a reliable ally in our data replication endeavors. Before embarking on the volume copy operation, it's imperative to ensure the presence of the desired files. Typically, NTDS takes residence in "C:\Windows\NTDS\ntds.dit," while the SYSTEM file finds its abode in "C:\Windows\System32\config\SYSTEM."
vssadmin create shadow /for=C:
This will give us the result shown in the following capture:
Upon the completion of the copy process, we proceed to duplicate the specific files of interest—namely, NTDS.dit and SYSTEM.
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\ntds.dit
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\system C:\system
To transfer the desired files to our Kali Linux machine, we can utilize smbclient once again. Following the file transfer, it is imperative to erase any traces of the intrusion by removing the shadow copy.
vssadmin list shadows
vssadmin delete shadows /Shadow={id}
Remote Credential Dump: The Dcsync Technique
In the realm of cybersecurity, the technique known as "Dcsync" emerges as a potent method for acquiring NTDS credentials, allowing access to hashes for domain accounts without the need for direct interaction with a domain controller or the extraction of the NTDS database.
As we explored in the "Domain Controllers" section, each DC houses a synchronized copy of the NTDS, perpetually updated across all DCs to reflect changes. Leveraging this synchronization capability, the Dcsync technique empowers an attacker to pose as a DC, initiating requests to the Windows API for Active Directory synchronization and replication. Specifically, the DSGetNCChanges function within DRSUAPI plays a pivotal role in this Directory Replication Service (DRS) protocol.
What adds to the intrigue is the fact that it can be executed from virtually any machine, granted the user possesses the requisite permissions—"Replicating Directory Changes All" and "Replicating Directory Change." Typically, this technique finds its prime application in scenarios involving a domain administrator, naturally endowed with these privileges.
However, a note of caution is warranted. Deploying this technique recklessly, especially in expansive domains, may trigger memory overload on the responding DC, potentially resulting in a crash. Prudent execution is key to navigating the power of Dcsync effectively.
Using secretsdump
To employ this technique, the impacket's secretsdump script becomes a valuable ally once again. What sets this script apart is its versatility—you don't necessarily need a compromised Windows machine to execute it. Operating seamlessly from your Kali Linux, the secretsdump script unfolds a treasure trove of critical information. Fear not if the intricacies seem daunting at first; we'll delve into each facet in due course:
- LM and NT password hashes
- Passwords stored with reversible encryption
- Kerberos keys (DES, AES128, and AES256)
- Secrets of the Domain Controller's SAM
- Insights into the Domain Controller's LSA
This arsenal of data, extracted through the secretsdump script, unveils the intricate layers of security measures employed within the Active Directory environment. Stay with me, and we'll demystify each element as we progress.
Mimikatz
Initiating this journey involves logging in with a user endowed with domain administrator privileges. Navigate to the core of your domain control: Tools > Active Directory Users and Computers > Users. Select your chosen user, right-click, and delve into the "Add to a group..." option. In this pivotal juncture, explicitly express your intention to enroll this user into the esteemed Domain Admins group. This strategic move empowers your user with the essential authority for the upcoming tasks. Let's choreograph this ascent to administrator prowess seamlessly.
After successfully granting this group, validate the meticulous modifications to privileges with a command that speaks volumes:
whoami /groups
This insightful command unveils the transformed landscape of privileges, affirming the ascendancy and confirming the strategic enhancements made to bolster your group's authority. Dive into the realm of elevated privileges with confidence, as you navigate the path of administrative empowerment.
Embarking on the journey with Mimikatz requires a crucial step – the upload of this potent tool onto the target machine. In this tactical maneuver, the smbclient script emerges as your ally, wielding the 'put' function to seamlessly transport Mimikatz to its designated destination.
┌──(rsgbengi㉿kali)-[~/Downloads/x64]
└─$ impacket-smbclient [email protected]
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation
Password:
Type help for list of commands
# use C
# cd Users
# cd vaan
# cd Desktop
# put mimikatz.exe
Now that the pieces are in place, the stage is set for the grand unveiling. Execute Mimikatz with the following command:
lsadump::DCSync /domain:shadow.local /user:vaan
With this command, the curtains rise on a spectacle of information, revealing a treasure trove of insights:
- User account information (SAM username, account type, account options...)
- Security ID (SID) and Relative ID (RID)
- Kerberos Keys
- Plaintext password if the account has reversible encryption enabled.
Mimikatz, now in the spotlight, orchestrates this revelation with finesse, extracting critical details that cast a spotlight on the security landscape. The command becomes the key to unlocking a realm of knowledge, offering a panoramic view of the domain's inner workings.
Conclusion
In conclusion, understanding the intricacies of Domain Controllers and the methods employed to extract information from the NTDS database is vital in fortifying Active Directory security. As we navigate through tools and techniques, always remember the ethical implications of these actions and execute them within legal boundaries.
References
Chapters
Previous chapter
Next chapter