Extracting and Cracking NTDS.dit
In previous projects, I have been tasked with auditing Active Directory passwords as well as compromising an Active Directory Domain Controller. In both instances, I used the following methods to extract the ntds.dit file for use on my local system in order to extract and crack the hashes.
Whether obtaining a shell or logging into the Domain Controller (DC), I used the DCs vssadmin application to create a shadow file.
Next, I created a directory (on the DC) of C:\extract and then copied the ntds.dit file from the shadow copy to the newly created directory.
I then copied the SYSTEM file from the shadow copy using the reg SAVE command. In a future step, I needed this key in order to extract the hashes.
I had some issues when I was originally trying to extract the SYSTEM file. In this instance, I was using an exploited shell. So, I killed the session and then established a new shell to get around the error.
After downloading the C:\extract directory to my attacking system, I did a little housekeeping by deleting the C:\extract directory on the DC as well as the shadow copy.
With the files transferred to my local system, I downloaded and installed Impacket. Within Impacket, there was a Python script that I used in order to extract the hashes from the ntds.dit file.
Installing Impacket was easy when utilizing the setup.py within the extracted Impacket directory.
python setup.py install
After Impacket was installed, I used the secretsdump.py Python script to extract the hashes.
python /opt/impacket/examples/secretsdump.py -ntds
/Extract/SYSTEM -hashes lmhash:nthash LOCAL -outputfile ntlm-extract
· -ntds: location and name of the ntds.dit file
· -system: location and name of the SYSTEM hive
· -hashes lmnhash:nthash: NTLM hash
· LOCAL: parse files on the local system
· -outputfile: location and name of the output file. Extensions are automatically added based on content extracted
Note: The size of the ntds.dit file will determine the amount of time it will take to extract the hashes (from a few minutes to a few days).
Next, I used Hashcat to crack the hashes. However, I wanted to add the user information to the cracked hash and cleartext password. To accomplish this, I used two different methods with Hashcat.
The first method cracked the hash and stored the cracked hash to a file named cracked.out as well as to a pot file of hashcat.pot. Since I was dealing with a larger ntds.dit file, I wanted to have one master file with the hashes as well as using a different file names when executing Hashcat with different rules and wordlists.
hashcat -m 1000 -w 3 -a 0 -p : — session=all — username -o
· -m 1000: NTLM hash
· -w 3: workload with tuned profile
· -a 0: straight attack mode
· -p:: separator character for out file
· — session=all: all sessions
· — username: ignore usernames in hash file
· -o: outfile location and name
· — outfile-format=3: out file format of “hash[:salt]:plain”
· — potfile-path: pot file location and name
The second method used the pot file of cracked hashes against the contents of the extracted ntds file and output the data to a new outfile.
hashcat -m 1000 -w 3 -a 0 -p : — session=all — username — show -o
/Extract/ ntlm-extact.ntds — potfile-path
· — show: show cracked password only
In closing, I know there are other automated tools that would help expedite some of these processes. However, I wanted to start off with learning the basics prior to exploring different methods and applications for extracting and cracking NTDS.dit.
Disclaimer:
This article is made available for educational purposes only. In addition, this article provides general information on cyber security topics used for “Ethical Hacking”.
Persons accessing this information assume full responsibility for the use and agree to not use this content for any illegal purpose. Furthermore, the author is not liable for any direct or indirect damages or expense incurred which may result from the use of the information covered within this article.
Information within this article is “as is”, without warranty of any sort.
What is NTDS.DIT
Ntds.dit is the main AD database file. NTDS stands for NT Directory Services. The DIT stands for Directory Information Tree. The Ntds.dit file on a particular domain controller contains all naming contexts hosted by that domain controller, including the Configuration and Schema naming contexts. A Global Catalog server stores the partial naming context replicas in the Ntds.dit right along with the full Domain naming context for its domain.
By default, AD Database is saved in %systemroot%/ntds but we can save in other drive as well. You can see other files also in this folder.
These are the main files controlling the AD structure.
Active Directory’s database engine is the Extensible Storage Engine (ESE ) which is based on the Jet database used by Exchange 5.5 and WINS.
The ESE has the capability to grow to 16 terabytes which would be large enough for 10 million objects. Back to the real world. Only the Jet database can manipulate information within the AD data store.
The Active Directory ESE database, NTDS.DIT, consists of the following tables:
- Schema table
the types of objects that can be created in the Active Directory, relationships between them, and the optional and mandatory attributes on each type of object. This table is fairly static and much smaller than the data table. - Link table
contains linked attributes, which contain values referring to other objects in the Active Directory. Take the MemberOf attribute on a user object. That attribute contains values that reference groups to which the user belongs. This is also far smaller than the data table. - Data table
users, groups,application-specific data, and any other data stored in the Active Directory. The data table can be thought of as having rows where each row represents an instance of an object such as a user, and columns where each column represents an attribute in the schema such as GivenName.
From a different perspective, Active Directory has three types of data
Schema information
Configuration information
Domain information
Although GUIDs are unique, they are large. AD uses distinguished name tag ( DNT ). DNT is a 4-byte DWORD value which is incremented when a new object is created in the store.
The DNT represents the object’s database row number. It is an example of a fixed column. Each object’s parent relationship is stored as a parent distinguished name tag ( PDNT). Resolution of parent-child relationships is optimized because the DNT and PDNT are indexed fields in the database. The size of ntds.dit will often be different sizes across the domain controllers in a domain.
Remember that Active Directory is a multi-master independent model where updates are occurring in each of the ADs with the changes being replicated over time to the other domain controllers. The changed data is replicated between domain controllers, not the database, so there is no guarantee that the files are going to be the same size across all domain controllers.
So, that’s all in this blog. I will meet you soon with next stuff .Have a nice day .