DCsync Attack
Last updated
Last updated
Active Directory is a centralized directory service in Microsoft Windows Server environments, comprised of Domain Controllers responsible for managing the AD infrastructure. Each Domain Controller contains information related to users, objects, and more. In large organizations, additional Domain Controllers are created and connected to domains within a common forest.
When a new domain is established, it requires its own domain controller. The Domain Controller automatically receives a copy of the Active Directory database from an existing Domain Controller through Active Directory replication. This replication process ensures that all Domain Controllers within the domain or forest have consistent and up-to-date information.
Replication is the process of synchronizing all Active Directory data to all Domain Controllers within the same domain or across different forests. Active Directory replication ensures that any changes made in the directory, such as modifying user accounts, group memberships, security policies, and directory information, are consistently propagated across all domains.
By leveraging replication, Active Directory maintains the following things.
High Availability and Fault Tolerance: Active Directory replication ensures that multiple Domain Controllers (DCs) within the same domain or forest have copies of the same directory data. If one DC becomes unavailable due to hardware failure, maintenance, or other reasons, users can still authenticate and access resources using another available DC.
Redundancy: Having multiple copies of the directory data on different DCs provides redundancy, which is critical for ensuring the availability of AD services.
Load Balancing: Active Directory replication distributes the directory access and authentication load across multiple DCs, preventing any single DC from becoming overwhelmed with authentication requests.
Site Resilience: In larger AD environments with multiple sites, replication ensures that changes made in one site's domain are replicated to other sites' DCs, maintaining consistent directory data across the organization.
Consistency and Integrity: Replication ensures that any changes made to directory objects, such as creating new users or modifying group memberships, are propagated to all DCs within the domain, ensuring data consistency and integrity.
Now that we understand a bit about replication, let's delve into how attackers exploit this feature to harvest password credentials. To perform a DCsync attack, the attacker requires certain privileges in the Active Directory environment:
Replicating Directory: This privilege allows a user or group to replicate directory data to and from a Domain Controller. It is necessary for DCs to communicate and synchronize directory changes with each other.
Replicating Directory Changes All: The "Replicating Directory Changes All" privilege is a powerful permission that grants a user or group the ability to replicate all directory changes across the entire domain or forest. Users or groups with this privilege can request and retrieve any directory data from any Domain Controller within the domain or forest. This includes sensitive information, such as user password hashes and other security-related data. Consequently, it is a highly privileged permission that should be carefully assigned to trusted administrators who need to perform AD replication tasks.
Replicating Directory Changes In Filtered Set [Optional]: The "Replicating Directory Changes In Filtered Set" privilege is a more restrictive version of the "Replicating Directory Changes All" privilege. With this privilege, users or groups can still replicate directory changes, but only within a specific filtered set of data. This filtered set is defined by an LDAP filter and restricts the data that can be replicated to a subset of the entire directory. This privilege is often used in scenarios where specific data subsets need to be synchronized between DCs while ensuring other data remains restricted.
Typically, the Administrators, Domain Admins, and Enterprise Admins groups possess the above-mentioned privileges, and as we know, these are privileged accounts in the Active Directory environment. Therefore, attackers aim to gain access to these highly privileged accounts to perform the DCsync attack and extract sensitive data, including password hashes, from the active directory database.
In conclusion, the DCsync attack can only be executed when the attacker gains access to privileged accounts with the necessary permissions mentioned earlier. Obtaining such accounts is not a straightforward task and may require a considerable amount of time and effort, which makes the DCsync attack a late-stage attack.
It is worth mentioning that these permissions are typically granted to specific administrative accounts, but there is a possibility, although rare, that ordinary user accounts might have been manually assigned these permissions. In such cases, these ordinary accounts could also be exploited to perform the DCsync attack. However, it is important to note that granting such high privileges to ordinary accounts is not a standard practice and should be avoided to maintain the security and integrity of the Active Directory environment.
Whenever you got these permissions then many tools are available that can perform the DCsync attack so let's talk about some of these here.
Mimikatz is an incredibly powerful tool that serves a wide range of purposes in the realm of Active Directory pentesting. However, for now, our primary focus is on executing the DCsync attack using Mimikatz. I assume that you have already obtained and uploaded Mimikatz to the target environment and can safely run it without triggering antivirus or other security measures.
To perform the DCsync attack with Mimikatz, utilize the following command syntax:
lsadump::dcsync: This part of the command indicates that the DCsync attack module in Mimikatz is being used.
/domain:[DOMAIN HERE]: Replace [DOMAIN HERE] with the name of the target domain you want to extract password hashes from. For example, if the target domain is "example.com," you would replace [DOMAIN HERE] with example.com.
/all: This option instructs Mimikatz to retrieve the password hashes of all user accounts in the specified domain. If you omit this option, Mimikatz will only retrieve the password hash of the user account running the Mimikatz process.
/csv: This is an optional argument that specifies the output format for the retrieved password hashes. In this case, it is set to CSV (Comma-Separated Values), which means the password hashes will be saved to a CSV file. If you omit this option, the output will be displayed on the screen.
If you want to get the password hash from a specific user then you use the /user: [USERNAME HERE] option in the above command instead of /all. So by adding all together our command example in mimikatz will look like the following.
This is how you perform a DCsync attack using mimikatz but we know mimikatz will flag by antivirus and uploading that into the target system is a pain so let's see some other method that can do DCsync without being caught by any antivirus.
In previous instances, we have employed various Impacket scripts for different attacks. Today, we are utilizing Impacket once again, specifically, its script named secretsdump.py, to execute the DCsync attack. Impacket is a rich library comprising multiple scripts, each serving a distinct purpose. For the DCsync attack, we leverage the secretsdump.py script.
To use the secretsdump.py script for DCsync, the syntax is as follows:
$ python: This part of the command invokes the Python interpreter to run the secretsdump.py script.
secretsdump.py: This is the name of the script that will be executed.
[Domain Here]: Replace this placeholder with the name of the target Windows domain.
[Username HERE]: Replace this placeholder with the username of a valid account on the target system that has replication permissions.
[Password Here]: Replace this placeholder with the password of the specified username.
[Machine Name Here/ IP Address Here]: Replace this placeholder with either the hostname or the IP address of the target Windows machine that you want to extract secrets from, for a DCsync attack it must be the Domain Controller machine hostname or IP.
Following the syntax provided earlier, our complete impacket secretsdump.py command will appear as follows:
or
As observed in the example output above, we were able to obtain some password hashes. However, in this specific command, I did not include the hostname, resulting in the dumping of only the local SAM file hashes. To retrieve domain hashes, you can include the hostname parameter, such as dc.dcell.local or any relevant domain name, and the output will appear as follows:
In the command shown above, we successfully obtained the password hash for the krbtgt account. This hash can be utilized for various attacks, including the golden ticket and silver ticket attacks, both of which will be discussed in detail in later modules.
In the Impacket command shown above, we supply the user's password to execute the DCsync attack. However, there may be instances where you don't possess the compromised user's password. In such cases, you have alternative options like using Mimikatz. Nevertheless, if you prefer utilizing Impacket, it offers other functionalities as well.
The secretsdump.py in Impacket allows you to leverage hashes or Kerberos tickets if you have access to them but lack the actual password information. These hashes or tickets can be obtained from tools like Mimikatz or other methods. By exploring these possibilities, you can successfully execute a DCsync attack without needing the user's password directly.
I encourage readers to delve further into these techniques and research the other approaches available for performing a DCsync attack.
Now that you understand what the DCsync attack is and how to perform it, let's delve into the inner workings of tools like Impacket and how they operate in the background. Are you familiar with these details?
In the DCsync attack, the replication requests are managed by the Microsoft Directory Replication Service (MS-DRS) remote protocol. When domain controllers need to replicate data, they forward their replication requests to the MS-DRSR server. The MS-DRSR server is an essential component that utilizes Remote Procedure Call (RPC) based protocols for data replication and management in Active Directory. If you're interested in learning more about MS-DRSR, you can explore additional details in the MS-DRSR documentation.
The tools mentioned earlier, such as Impacket, interact with the MS-DRSR server by sending GetNCChanges requests to replicate Naming Context which contains the user's credentials and retrieves sensitive information.
Intro of Naming Context (NC) Active Directory is composed of one or more naming contexts (NCs) or partitions, each representing a contiguous sub-tree of the directory. A naming context serves as a unit of replication within the Active Directory environment. Specifically, each domain controller always maintains at least three NC replicas:
Schema: The Schema NC defines the types of objects (e.g., users) and their associated attributes (e.g., telephone numbers) that can be created and stored in the Active Directory. It also establishes the rules governing the creation and manipulation of these objects.
Configuration: The Configuration NC contains information about the replication topology and related metadata. It is crucial for ensuring the consistency and proper functioning of the replication process within the Active Directory infrastructure.
Domain Naming Context: The Domain Naming Context includes the actual objects present in the Active Directory. It represents domain-specific data and is responsible for holding objects like users, groups, and computer accounts.
In the Impacket script, you can find the following functions that are creating a GetNCChanges request to retrieve the information.
Let's break down the above function code:
DRSGetNCChanges: This function represents the DRSGetNCChanges operation, which is a Directory Replication Service (DRS) method used for obtaining changes in the Naming Context (NC) of the Active Directory.
self.__drsr: The self.__drsr variable represents the DRSUAPI object, which is used for communication with the Directory Replication Service Remote Protocol (DRS-R) server.
userEntry: This parameter represents the user entry for which changes are to be retrieved. It is typically in the form of a distinguished name (DN) or GUID.
The function prepares a request message (request) with the necessary parameters for the DRSGetNCChanges operation.
The request object is populated with the following information:
hDrs: A handle to the DRS object used for communication.
dwInVersion: The version of the input message (set to 8 in this case).
pmsgIn: The input message structure that contains various information related to the DRSGetNCChanges operation.
The function sets up the pmsgIn input message with specific attributes:
uuidDsaObjDest and uuidInvocIdSrc: Identifiers of the destination and source NTDS-DSA objects (Domain Controller).
pNC: The Naming Context (NC) object for which changes are to be retrieved (specified using the user entry DN or GUID).
usnvecFrom: The starting USN (Update Sequence Number) vector, is set to 0 to retrieve all changes from the beginning.
pUpToDateVecDest: Set to NULL, indicating that there is no specific update vector for this request.
ulFlags: Flags used to control the DRSGetNCChanges operation, such as DRS_INIT_SYNC and DRS_WRIT_REP.
cMaxObjects and cMaxBytes: Limits on the number of objects and bytes to be returned (set to 1 and 0 respectively).
ulExtendedOp: An extended operation identifier for replication (set to EXOP_REPL_OBJ).
If the ppartialAttrSet is not already set, the function initializes it and populates it with partial attribute information, indicating which attributes are to be included in the returned data.
The function sends the request to the DRS-R server using self.__drsr.request(request) and returns the response.
The whole GetNCChanges Method is documented by Microsoft and you can learn about it from this link.
In the above screenshot, you can view the Microsoft documentation for the GetNCChanges request structure. The highlighted section is of particular significance. The DRS_MSG_GETCHGREQ represents the primary request message that is transmitted to the IDL_DRSGetNCChanges method.
For detailed information about the DRS_MSG_GETCHGREQ structure, you can access the official Microsoft documentation by following this link.
If you compare the message structure shown above with the Impacket function code, you may notice some similarities. However, it's important to acknowledge that comprehending all the intricacies of these structures is not mandatory, especially for those who are new to this topic.
The purpose of showcasing these details is to provide a glimpse into what occurs in the background during the DCsync attack. Understanding the precise technicalities of the structures may require specialized knowledge, but having an awareness of their existence can help in appreciating the underlying mechanisms of the attack.
In conclusion, the DCsync attack proves highly valuable in AD pentesting as it allows the extraction of password hashes, which can be utilized for subsequent attacks. In today's module, we covered several aspects of this attack, but I encourage readers not to stop here and continue researching Replication and DCsync attacks further. To aid your research, I've included additional resources below that personally helped me learn about these topics. If you come across any errors in any of the modules, please don't hesitate to inform me so I can rectify them promptly. Your feedback is valuable in enhancing the quality of the content.
More Learning Resources
