It has been far too long since I have covered something directly relating to IT Security, but today we will briefly go over a sometimes overlooked risk to a Windows Domain Controller's database file (NTDS.DIT), along with covering a potential mitigation for this risk.
What is NTDS.DIT and Why Should You Care?
To quote Microsoft, "Active Directory data is stored in the Ntds.dit ESE database file." This, unfortunately, doesn't really get the point across as to how important this file is both from a functionality perspective, but also that of security. Essentially, almost everything that is referenced by Active Directory is stored within this file. This includes User Objects, Groups, password hashes, etc. Yes, password hashes are stored in this file. Typically, this file is constantly locked by the SYSTEM user when the Operating System is running, and is not accessible by any other user whatsoever.
There are, however, a handful of ways for an attacker to obtain access to this file and its contents. Doing so allows them to copy down the file to a portable device, with which they can later extract and crack the password hashes stored within. One way would be for an attacker to boot the Domain Controller into a Linux environment, which allows the file to be easily accessed as it is no longer locked. This, however, would likely be noticed VERY quickly by an administrator of the system. Another way would be for the attacker to upload and run an application which would allow them to negate the file lock, but this might also be caught fairly easily by an administrator. There is, however, a fairly simple method, which is quite effective, that would allow the attacker to utilize a built-in feature in order to obtain the Active Directory database file... Volume Shadow Copy.
For sake of time, we will assume that the attacker has already obtained access to a Domain Administrator account, or some other account with the necessary permissions. Once they are able to log into the Domain Controller, they would essentially need to utilize the vssadmin utility to create a Shadow Copy of the C: Drive. Like so:
vssadmin create shadow /for=c:
Once the Shadow Copy is complete, they would merely need to copy the NTDS.DIT file and the Registry SYSTEM hive from within it. Using these, they could easily leverage one of the many freely-available tools in order to begin cracking all of the password hashes at their leisure.
How to Mitigate This Risk?
Fortunately, it isn't too incredibly difficult to provide a certain level of mitigation against this risk. In essence, you will need to remove the ability to start/stop the Volume Shadow Copy service from ALL users on the system(s), and to remove the ability to modify the security settings of the Volume Shadow Copy service from ALL users except for SYSTEM. In order to do so, you will need to follow the steps outlined below.
First, you will need a way with which you can easily deploy these changes and ensure that they remain in-place. For this, it is recommended to utilize a Group Policy. This should be a simple task for an administrator, and will therefore not be explained in detail. You will, however, need to do the following:
1. Create a Domain Group that this GPO will be applied to
2. Add your Domain Controllers into this Domain Group
3. Create a new Group Policy that will be applied ONLY to members of this Domain Group
Now that you have a Group Policy created, you can begin configuring the risk's mitigation. For this, you will first need to drill-down into the following location within your new Group Policy, Right-Click, and select Properties.
Computer Configuration -> Windows Settings -> Security Settings -> System Services -> VSS
Within the initial properties for VSS, you need to ensure that Define this policy setting is checked, and that the startup mode is set to Manual. Next, click Edit Security.
Within the Security for VSS screen, remove all Groups/Usernames from the list except for SYSTEM. After this, click Advanced in order to open the Advanced Security Settings options.
You will now need to ensure that SYSTEM has all permissions configured for DENY, except for Read Permissions and Change Permissions. After this, you can close out of the Permission Entry for VSS screen and return to the previous one.
Back in the Advanced Security Settings for VSS screen, you will need to click on the Auditing tab. From here, you will need to ensure that logging is enabled on ALL failures, and enabled for Successful starts of the service. Once this is complete, you can close out and save your changes.
After having done all of this, you may be wondering how exactly this all mitigates the risk that was previously presented. Essentially, what you have done is to force the Volume Shadow Copy service to only start manually, which prevents reboots of the Domain Controller from starting this service. You have also removed permission to start this service from ALL user accounts, including SYSTEM. This ensures that if an account happens to be compromised by an attacker, they cannot start the service. Auditing has also been enabled on this service, and will log any failures against it (e.g. someone attempting to start the service).
While the Volume Shadow Copy service is now restricted from being started by anyone, you did leave the ability to modify security permissions on this service to the SYSTEM account. This allows you, in the event that you utilize VSS for backups, to use the SYSTEM account to change the security permissions on the Volume Shadow Copy service to allow the service to be started by it. By doing this, you still retain a small risk, as someone could compromise the SYSTEM account and modify the security permissions, which is why Auditing was also enabled for any successful starts of the Volume Shadow Copy service.
At this point, you have greatly reduced the risk of someone obtaining your Active Directory database by leveraging the Volume Shadow Copy service, while retaining the ability to use it for your own Domain Controller backups.
What is NTDS.DIT and Why Should You Care?
To quote Microsoft, "Active Directory data is stored in the Ntds.dit ESE database file." This, unfortunately, doesn't really get the point across as to how important this file is both from a functionality perspective, but also that of security. Essentially, almost everything that is referenced by Active Directory is stored within this file. This includes User Objects, Groups, password hashes, etc. Yes, password hashes are stored in this file. Typically, this file is constantly locked by the SYSTEM user when the Operating System is running, and is not accessible by any other user whatsoever.
There are, however, a handful of ways for an attacker to obtain access to this file and its contents. Doing so allows them to copy down the file to a portable device, with which they can later extract and crack the password hashes stored within. One way would be for an attacker to boot the Domain Controller into a Linux environment, which allows the file to be easily accessed as it is no longer locked. This, however, would likely be noticed VERY quickly by an administrator of the system. Another way would be for the attacker to upload and run an application which would allow them to negate the file lock, but this might also be caught fairly easily by an administrator. There is, however, a fairly simple method, which is quite effective, that would allow the attacker to utilize a built-in feature in order to obtain the Active Directory database file... Volume Shadow Copy.
For sake of time, we will assume that the attacker has already obtained access to a Domain Administrator account, or some other account with the necessary permissions. Once they are able to log into the Domain Controller, they would essentially need to utilize the vssadmin utility to create a Shadow Copy of the C: Drive. Like so:
Once the Shadow Copy is complete, they would merely need to copy the NTDS.DIT file and the Registry SYSTEM hive from within it. Using these, they could easily leverage one of the many freely-available tools in order to begin cracking all of the password hashes at their leisure.
How to Mitigate This Risk?
Fortunately, it isn't too incredibly difficult to provide a certain level of mitigation against this risk. In essence, you will need to remove the ability to start/stop the Volume Shadow Copy service from ALL users on the system(s), and to remove the ability to modify the security settings of the Volume Shadow Copy service from ALL users except for SYSTEM. In order to do so, you will need to follow the steps outlined below.
First, you will need a way with which you can easily deploy these changes and ensure that they remain in-place. For this, it is recommended to utilize a Group Policy. This should be a simple task for an administrator, and will therefore not be explained in detail. You will, however, need to do the following:
1. Create a Domain Group that this GPO will be applied to
2. Add your Domain Controllers into this Domain Group
3. Create a new Group Policy that will be applied ONLY to members of this Domain Group
Now that you have a Group Policy created, you can begin configuring the risk's mitigation. For this, you will first need to drill-down into the following location within your new Group Policy, Right-Click, and select Properties.
Within the initial properties for VSS, you need to ensure that Define this policy setting is checked, and that the startup mode is set to Manual. Next, click Edit Security.
Within the Security for VSS screen, remove all Groups/Usernames from the list except for SYSTEM. After this, click Advanced in order to open the Advanced Security Settings options.
You will now need to ensure that SYSTEM has all permissions configured for DENY, except for Read Permissions and Change Permissions. After this, you can close out of the Permission Entry for VSS screen and return to the previous one.
Back in the Advanced Security Settings for VSS screen, you will need to click on the Auditing tab. From here, you will need to ensure that logging is enabled on ALL failures, and enabled for Successful starts of the service. Once this is complete, you can close out and save your changes.
After having done all of this, you may be wondering how exactly this all mitigates the risk that was previously presented. Essentially, what you have done is to force the Volume Shadow Copy service to only start manually, which prevents reboots of the Domain Controller from starting this service. You have also removed permission to start this service from ALL user accounts, including SYSTEM. This ensures that if an account happens to be compromised by an attacker, they cannot start the service. Auditing has also been enabled on this service, and will log any failures against it (e.g. someone attempting to start the service).
While the Volume Shadow Copy service is now restricted from being started by anyone, you did leave the ability to modify security permissions on this service to the SYSTEM account. This allows you, in the event that you utilize VSS for backups, to use the SYSTEM account to change the security permissions on the Volume Shadow Copy service to allow the service to be started by it. By doing this, you still retain a small risk, as someone could compromise the SYSTEM account and modify the security permissions, which is why Auditing was also enabled for any successful starts of the Volume Shadow Copy service.
At this point, you have greatly reduced the risk of someone obtaining your Active Directory database by leveraging the Volume Shadow Copy service, while retaining the ability to use it for your own Domain Controller backups.
