Feb 12 2013

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:

backtrack-installmodule

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:

runexploitsuccess

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:
  • disableVSSGPO

  • 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:

enablevss

When this configuration is applied the ntdsgrab.rb module will fail on every domain controller:

runexploitfailed2

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:

events

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:

scheduled

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

No Comments

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

*

WordPress Themes

Blossom Icon Set

Software Top Blogs