HackTheBox : BlackField

0liverFlow
11 min readFeb 15, 2025

--

Blackfield is a great windows machine with interesting AD attack vectors. To get an initial access, we performed an AS REP Roasting attack after finding that one user had Kerberos pre-authentication disabled. This allowed us to retrieve a hash that we successfully cracked offline. With this new access, we downloaded the domain data and enumerated the Access Control Lists. This is where we noticed that our compromised user had the privilege to change another user’s password. After changing that user’s password, we’ve been able to access an SMB share containing forensics artefacts, including an lsass process dump. This contains a username and a NT hash for a user who was also a member of the Backup Operators group. The privileges conferred by this privileged group allowed us to dump the Active Directory database, and retrieve the hash of the primary domain administrator.

Reconnaissance

Nmap

Full tcp scan

DNS — TCP/53

In this section, we will try to retrieve all dns entries and perform a dns zone transfer to see if we can obtain more information

Requesting all queries to the dns server
Performing a dns zone transfer

As you can see, the dns zone transfer failed and we did not get any entry while requesting all queries. That being said, let’s move on with SMB enumeration.

SMB — TCP/445

Let’s start with a simple enum4linux-ng scan

Running enum4linux-ng

Null session is allowed as we can see on the image above.

Let’s confirm that by running nxc :

Checking null session

The magenta color in nxc means that the authentication failed but the password provided is correct (source: nxc documentation). Let’s try to authenticate using the guest user as our username :

Checking guest session

Great ! The authentication succeeded and we have been able to list the shares with their respective permissions.

Here, we have read access on IPC$ and profiles$. Let’s take a look at the latter one.

💡Good to know : Shares that end with $ are hidden shares on Windows.

Let’s take a look at the content of profiles$ :

profiles$ share content

This contains empty directories. However, the directories’ names seem to be usernames. Let’s download them using smbclient :

Downloading profiles$ share content

Let’s look for non empty files and directories using the find command :

We will need to save the usernames in a file using this bash one-liner :

Saving usernames in users.txt

Initial Access

We have so far a list of potential usernames. A legitimate question, we can ask ourselves is : what can we do with that ?

For instance, we could try an AS-Rep roasting or password spraying attack. Let’s do it ! Shall we ?

AS-Rep Roasting

Prior performing this attack, it’s good practice to always enumerate the valid usernames. To do that, I used kerbrute but you could use another tool of your choice :

Enumerating valid usernames

See that we have a list of valid usernames, we can then proceed with AS-REP Roasting attack using impacket’s GetNPUsers :

AS-REP Roasting

We can then try to crack the hash offline using hashcat :

Hash cracked successfully

Fantastic ! The hash was successfully cracked ! Let’s check where we can authenticate using the obtained credentials :

Checking authentication against smb

The creds work fine. Nevertheless, we do not get a shell. Let’s check the authentication against other open ports :

Checking authentication against other open ports

It only works for ldap. No shell so far.

Let’s keep our enumeration. When I get a valid pair of credentials, I generally follow these steps :

1/ Enumerating the shares permission for the new user

Enumerating shares
Sysvol share

Note : The sysvol did not contain any useful information that could enable us to move laterally. I then checked the netlogon share :

Netlogon share is empty

2/ Enumerating other users

Users enumeration

When enumerating usernames, it’s important to take a look at the description field also in addition to the BadPw field because it sometimes stores sensitive information.

Well we got new usernames. Nevertheless, apart from that nothing really stunning.

Let’s now collect the domain information :

Collecting domain information

After that, we can export the data in bloodhound :

Exporting domain information in bloodhound

Lateral Movement (support -> svc_backup)

Once the data ingested, we can visualize it :

Visualizing domain information

After some enumeration, I found that the user support has ForceChangePassword ACL on the audit2020 user. This simply means that support can change audit2020 ‘s password without knowing his current password. To change audit2020’s password, we can use the linux built-in’s net command as follows :

Changing audit2020’s password

Fantastic ! Let’s check if the password was successfully changed :

Checking if audit2020’s password was successfully changed

As illustrated on the image above, the password was successfully changed.

As usual, let’s check if we can authenticate to other open ports :

Checking authentication against other open ports

Here again, we got no shell :(

No worries, let’s continue our enumeration by taking a look at audit2020' s shares :

Enumerating audit2020’s shares

Interesting ! We now have access to the forensics share. We can take a quick look at its content :

Forensics share content

Let’s download the content of the share to dig deep in it :

Downloading forensic share content

Once the content downloaded, I explored commands_output directory’s files :

domain_admins.txt
domain_groups.txt

There is also a systeminfo.txt file that we may use in later steps of our pentest. Let’s now take a look at the memory_analysis directory.

Lsaas dump found

Among all the files above, the lsass.zip caught my eye. As you may notice, it contains a dump of the lsass process which may provide us with NT hashes and even sometimes plaintext credentials.

That said, let’s first unzip the zip file :

Unzipping lsass.zip

Once the file unzipped, we can analyze the lsaas memory dump using a tool called pypykatz which is python implementation of mimikatz. Here is how to use it :

Source : The Hacker Recipes (THR)
svc_backup NT hash
DC01$ NT hash
Administrator NT hash

Wonderful ! We found NT hashes from various users such as Administration, DC01$ and svc_backup. Let’s check if these hashes are still valid by performing a pass the hash :

Checking authentication for Administrator user
Checking authentication for DC01$
Checking authentication for svc_backup

Fantastic ! We found a valid login ! Let’s check the other authentication methods :

Checking other authentication methods

As you can see, this time we got a shell when authenticating to WinRM.

Let’s connect to it :

WinRM authentication succeeded

From here, we can take a quick look at svc_backup’s folders :

Great ! We found the user.txt flag.

user.txt

Privilege Escalation (svc_backup -> Administrator)

In this section, we are going to enumerate the target until we find a way to escalate our privileges.

Enumerating group memberships
Enumerating group memberships with Bloodhound

As you can see, svc_backup is part of the Backup Operators group. Users of that group can back up and restore all files on a computer, regardless of the permissions that protect those files. This includes files such as ntds.dit which means that we could potentially be able to retrieve the administrator’s NT hash.

Furthermore, we have the SeBackupPrivilege enabled :

SeBackupPrivilege Enabled

There are different ways of exploiting this privilege. Here is a great blog post that sums up all these techniques.

I decided to use a technique that relies on built-in windows tools (diskshadow and robocopy). This is called living-off the land.

Here are the steps to escalate your privileges :

1/ Create a distributed file shell (dsh) and enter the following commands :

set context persistent nowriters
add volume c: alias blackfield
create
expose %blackfield% z:

2/ Convert the dsh file into a file compatible with the Windows Machine :

3/ Copy the distributed file shell to the target machine :

Downloading blackfield.dsh

Once the file downloaded, you can use diskshadow with the dsh file to create a a shadow copy (backup) of the C:\ drive.

Creating a shadow copy of C:\ using diskshadow

Note : As you can notice on the image above, diskshadow executed the same commands that we entered in the dsh file sequentially.

After that, you can use robocopy to extract the ntds.dit database from the the backup generated by diskshadow :

Extracting ntds.dit from the shadow copy

Let’s now extract the system from the registry using the reg command. Simply put, the system file contains a decryption key that we will use to decrypt the ntds.dit database :

Extracting system from the registry

Great ! We can now transfer the ntds.dit and system files to our attacker machine :

Transferring ntds.dit and system to the attacker machine

Finally, we can extract secrets from ntds.dit using secretsdump as follow :

Extracting secrets from ntds.dit

Hoorah \0/ ! We got the administrator’s hash. Let’s check if we can authenticate to his account :

Authentication succeeded

Well, let’s authenticate to the administrator’s account :

Last but not least, let’s retrieve the root flag :

root.txt

Key Techniques Used

Here are the following techniques we used to solve this box :

  • Users and shares enumeration using nxc and smbmap
  • AS-Rep Roasting attack and hash cracking
  • Analyzing and extracting of secrets from lsass memory dump using pypykatz
  • Creation of a volume shadow copy and extraction of the ntds.dit database
  • Extracting secrets from ntds.dit using secretsdump and the system file.

Lessons Learned

1/ To get an initial access, we performed a successful AS-REP Roasting attack against the user support account. This was feasible because the user have the “Do not require kerberos preauthentication” enabled. To fix that, we recommend to disable this option.

2/ Using our initial access, we have been able to move laterally from support to audit2020 and from audit2020 to svc_backup account. Indeed, we leveraged the “force change password” ACL which allowed our compromised user (support) to change audit2020’s password without the need to know his current password at that time. After changing audit2020’s password, we got access to the forensic share where we found a lsass memory dump file. We then downloaded this file on our machine and extracted the NT hashes of multiple users such as svc_backup. Using this hash, we have been able to access his account. To fix that, we recommend to regularly review and remove the unnecessary ACLs in the domain.

3/ Finally, after some enumeration we noticed that svc_backup was part of the Backup Operators group. This gave us the privileges to perform a shadow copy of the C:\ drive and be able to extract the ntds.dit database which stores the domain’s secrets. Once the ntds.dit and system files extracted, we used secretsdump to extract the secrets which provided us the keys to the kingdom. To mitigate that, we recommend to apply the least privilege principle by giving users only the privileges required to conduct their tasks properly.

Wrap Up

That’s it guys. Congrats on having made it so far 👏

I hope you enjoyed the writeup. As far as I’m concerned, I was enthusiastic to write this writeup and found the challenge pretty interesting and realistic.

That said, do not forget to click on the little clap icon below to support me and subscribe to my newsletter to keep up with my latest articles !

--

--

0liverFlow
0liverFlow

Written by 0liverFlow

Pentester | Enjoy breaking and building stuffs

No responses yet