Authority

Authority es una máquina Windows de dificultad media que resalta los peligros de las configuraciones incorrectas, la reutilización de contraseñas, el almacenamiento de credenciales en recursos compartidos y demuestra cómo las configuraciones predeterminadas en Active Directory (como la capacidad de todos los usuarios del dominio de agregar hasta 10 computadoras al dominio) se pueden combinar con otros problemas (plantillas de certificado AD CS vulnerables) para apoderarse de un dominio.


Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Authority. Este resultado lo almacenaremos en un archivo llamado allPorts.

A través de la herramienta de extractPorts, la utilizaremos para extraer los puertos del archivo que nos generó el primer escaneo a través de Nmap. Esta herramienta nos copiará en la clipboard los puertos encontrados.

Lanzaremos scripts de reconocimiento sobre los puertos encontrados y lo exportaremos en formato oN y oX para posteriormente trabajar con ellos. Verificamos a través del resultado obtenido de que la máquina se trata de un Domain Controller (DC) por los puertos y servicios que se encuentran expuestos.

Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.

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

A través de la herramienta de nxc y ldapsearch enumeraremos el equipo para localizar más información. Entre la información obtenida, verificamos el hostname, versión del SO y el nombre del dominio.

Añadiremos en nuestro archivo /etc/hosts las entradas correspondientes para que a la hora de hacer referencia al dominio o el equipo, nos responda correctamente a la dirección IP del Domain Controller.

Web Enumeration

Comprobaremos las páginas web que se encuentran expuestas en el Domain Controller. Para empezar, al acceder a http://10.10.11.222 nos encontramos con la página principal de IIS (Internet Internet Information Services).

Al acceder a https://10.10.11.222:8443 se nos muestra la siguiente página web en la cual se trata de PWM, la cual nos ofrece un panel de inicio de sesión para proporcionar credenciales y dos opciones para abrir la configuración.

PWM es una aplicación de autoservicio de contraseñas de código abierto para directorios LDAP.

Al acceder a cualquier de las opciones presentes, se nos requiere también proporcionar credenciales válidas para acceder al PWM. Deberemos de intentar buscar alguna vía para ver si logramos obtener credenciales de acceso o averiguar si hay otro vector de ataque.

Realizaremos una enumeración de directorios y páginas web en la página web del IISy no obtenemos resultado interesante. También probamos en la página del PWMpero tampoco logramos encontrar nada interesante.

SMB Enumeration

Revisaremos el servicio SMB y comprobamos que el usuario guest se encuentra habilitado, por lo tanto tenemos la posibilidad de recopilar información con este usuario, como verificar si dispone de acceso algún recurso compartido, realizar un ataque de RID Cycling Attack, etc.

Comprobamos que a través del usuario guest dispone de acceso a un recurso compartido llamado Development, dado que dispone de permisos de READ.

Montaremos este recurso compartido en nuestro directorio /mnt/shares que tenemos creado en nuestro equipo local previamente.

Verificaremos que la montura a través de cifs se ha realizado correctamente y disponemos del contenido del recurso compartido. Verificando que disponemos del recurso en local, copiaremos el directorio de manera recursvia al directorio de trabajo en el cual nos encontramos trabajando, para no tener problemas de lentitud, etc.

Accederemos al directorio Automation y comprobaremos la estructura del recurso compartido.

Como podemos observar, la estructura del directorio Automation está organizada en varias subcarpetas, entre ellas Ansible, LDAP, PWM, y SHARE. Cada una de estas carpetas contiene varios archivos y subdirectorios que parecen ser parte de configuraciones relacionadas con la automatización y administración de sistemas.

Initial Foothold

Cracking Ansible Vault Secrets with Hashcat

Revisamos los archivos disponibles en el directorio y encontramos uno en particular dentro de Automation/Ansible/PWM/defaults, que contiene varias cadenas cifradas con Ansible Vault. Estas cadenas están relacionadas con contraseñas y configuraciones críticas, como el usuario y contraseña del administrador de PWM y el administrador de LDAP.

Para lograr el formato adecuado de los hashes y poder crackearlos con Hashcat, hemos seguido los siguientes pasos:

  1. Extracción del contenido: Hemos obtenido los tres hashes desde los archivos pwm_admin_login, pwm_admin_password, y ldap_admin_password, los cuales estaban mal formateados debido a espacios y saltos de línea innecesarios.

  2. Formateo adecuado: Hemos utilizado awk y tr para eliminar los espacios y saltos de línea, dejando los hashes en el formato correcto. Cada uno de los archivos ahora contiene solo el hash en formato continuo, como se muestra a continuación:

Para continuar con el proceso de cracking de los hashes obtenidos desde los archivos de Ansible Vault, hemos seguido los siguientes pasos:

  1. Extracción de hashes con ansible2john: Utilizamos el comando ansible2john para convertir los archivos de Ansible Vault en un formato compatible con herramientas como John the Ripper o Hashcat. Esto nos permite obtener los hashes en su forma estructurada para ser crackeados.

  2. Contenido de los hashes: El resultado de la ejecución del comando muestra los hashes extraídos de los tres archivos. A continuación, el contenido de los hashes:

Al crackear los hashes de Ansible Vault con Hashcat, utilizando el siguiente comando:

Nos encontramos con que los tres hashes, correspondientes a pwm_admin_login, pwm_admin_password y ldap_admin_password, fueron descifrados con la misma contraseña:

A través de la herramienta de ansible-vault trataremos de desencriptar las credenciales de Ansible. FInalmente, logramos obtener las credenciales del usuario PWM y credenciales de un usuario de LDAP.

Initial Access

Accesing on PWM (Password Recovery Tool from LDAP)

Verificaremos si con estas credenciales podemos acceder a la página web de PWM (https://10.10.11.222:8443). En este caso, se nos muestra un mensaje de error indicando el siguiente mensaje: Directory unaivailable.

Accederemos a la opción de Configuration Editor (https://10.10.11.222:8443/pwm/private/config/login) e ingresaremos las credenciales del usuario PWMque hemos obtenido de Ansible.

Abusing PWM to modify the LDAP URL to our IP to obtain the saved password

Comprobamos que finalmente hemos logrado acceder al PWM con las credenciales proporcionadas. Estando dentro de la herramienta, comprobamos que en el apartado de LDAP Connection aparece la configuración de la conexión al servidor LDAP (ldaps://authority.htb:636/).

En esta configuración, se aprecia que hay un Value stored en el apartado de LDAP Proxy Password, lo que siguiere que las credenciales del usuario svc_ldap que es el que aparece en el apartado de LDAP Proxy User se encuentran almacenadas en la configuración de PWM.

Probamos de modificar el LDAP URLs y comprobamos que al parecer nos permite editar la URL del servidor LDAP contra el cual se autentica este usuario con las credenciales guardadas. Por lo tanto, si tenemos permisos para editar la URL del servidor LDAP para que apunte a nuestra dirección IP, quizás podamos obtener las credenciales de la autenticación de las credenciales almacenadas.

Por lo tanto, nos pondremos en escucha por el puerto 389 que es el puerto predeterminado de LDAP.

Editaremos la LDAP URLs para indicar nuestro servidor LDAP ficticio de nuestro servidor.

Comprobamos que se ha logrado modificar el servidor LDAP configurado en PWM. Le daremos a la opción de Test LDAP Profilepara comprobar si a nuestro servidor LDAP ficticio nos llega algún tipo de información, como la autenticación de las credenciales almacenadas.

Comprobamos que se ha recibido las credenciales almacenadas del usuario svc_ldap correctamente, esto debido a que hemos logrado modificar el servidor LDAP por el nuestro propio y el usuario almacenadado en la configuración del PWM se ha autenticado en nuestro servidor y no en el del DC.

Obtenemos el mismo resultado capturando el protocolo LDAP a través de Wireshark.

Abusing WinRM - EvilWinRM

Verificamos que las credenciales obtenidas del usuario svc_ldap son válidas y también que nos podemos conectar remotamente al Domain Controller.

Al acceder a través de evil-winrm al DC, hemos logrado acceder y obtener la flag root.txt.

Privilege Escalation

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

Debido que nos encontramos en un Domain Controller, haremos una enumeración a través de adPEAS que es una herramienta automatizada para realizar un escaneo en Active Directory en busca de encontrar alguna de escalar privilegios.

Para ello nos descargaremos en nuestro equipo el adPEAS y lo compartiremos a través de un servidor web.

Desde el Domain Controller, importaremos en memoria el adPEAS y lo invocaremos para realizar el análisis.

En la enumeración con adPEAS, identificamos que la máquina tiene Active Directory Certificate Services (ADCS) habilitado, específicamente con la CA AUTHORITY-CA, que está corriendo en authority.authority.htb (IP 10.10.11.222).

Al revisar los templates disponibles, encontramos varios, entre ellos:

  • CorpVPN

  • AuthorityLDAPS

  • DomainControllerAuthentication

  • KerberosAuthentication

  • User

  • Administrator

  • Y otros más...

Lo interesante es que el template CorpVPN tiene el flag ENROLLEE_SUPPLIES_SUBJECT, lo que indica que permite definir el Subject cuando se solicita un certificado. Además, el grupo HTB\Domain Computers tiene permisos de inscripción sobre este template.

Abusing Active Directory Certificate Services (ADCS)

Confirmamos la existencia de ESC1 (Enrollment Services Configuration #1) en el servicio Active Directory Certificate Services (ADCS) de la CA AUTHORITY-CA.

Usando Certipy, identificamos que el template CorpVPN tiene configurado el flag ENROLLEE_SUPPLIES_SUBJECT y permite autenticación de cliente (Client Authentication). Además, el grupo HTB\Domain Computers tiene permisos de inscripción sobre este template.

ESC1 exploitation case (Machine Account) with certipy-ad

Intentamos explotar ESC1, pero el usuario svc_ldap no tiene permisos de inscripción (enrollment) en el template CorpVPN. Solo las cuentas dentro del grupo HTB\Domain Computers pueden inscribirse y solicitar certificados con este template.

Si podemos comprometer un equipo con una cuenta de máquina (AUTHORITY.HTB\PC$), podríamos usarla para inscribir un certificado y luego abusar de él.

Confirmamos con adPEAS que el template CorpVPN tiene el flag ENROLLEE_SUPPLIES_SUBJECT, lo que permite al solicitante definir el Subject Alternative Name (SAN). Sin embargo, también verificamos que solo las cuentas dentro del grupo HTB\Domain Computers tienen permisos de inscripción (enrollment).

En el resultado de adPEAS, observamos que el MachineAccountQuota está configurado en 10, lo que significa que cualquier usuario autenticado puede agregar hasta 10 equipos al dominio.

Dado que previamente identificamos que solo los Domain Computers tienen permisos de enrollment en el template vulnerable, podemos aprovechar esta configuración para crear una cuenta de máquina controlada por nosotros y así explotar ESC1.

A continuación, realizaremos el ESC1 enfocado a las Machine Account que son las que disponen de permisos de enrollment para realizar la explotación.

Para ello, el objetivo será crear un nuevo Computer para poder realizar el ESC1 con las credenciales de la cuenta de equipo del PC que creemos. A través de la herramienta de PowerView.py nos conectaremos mediante LDAP y crearemos un nuevo Computer llamado Gzzcoo con credenciales Gzzcoo123.

Una vez tengamos el Computer creado, verificaremos desde PowerView.py de que el objeto se ha creado correctamente en el Active Directory.

Una vez que hemos creado una cuenta de equipo, procedemos a realizar el ESC1 utilizando sus credenciales. La solicitud de certificado se completa con éxito, obteniendo un certificado con el UPN administrator@authority.htb, lo que nos permite autenticarnos como este usuario y escalar privilegios en el dominio.

Al intentar autenticarnos con el certificado PFX, obtenemos un error KDC_ERR_PADATA_TYPE_NOSUPP, lo que indica que el KDC no admite el tipo de autenticación proporcionado. Más adelante, exploraremos otras formas de autenticarnos con este certificado para intentar acceder con éxito al dominio.

Authenticating with certificates when PKINIT is not supported (PassTheCert.py)

Nos encontramos con varios blogs que mencionan el error KDC_ERR_PADATA_TYPE_NOSUPP, el cual ocurre cuando el controlador de dominio no soporta PKINIT. Esto impide que autenticarnos directamente con el certificado PFX.

Como alternativa, podemos utilizar PassTheCert para autenticarnos a LDAP a través de SChannel con nuestro certificado. Aunque esto solo nos daría acceso a LDAP, podría ser suficiente si el certificado nos identifica como Administrador de Dominio.

KDC_ERR_PADATA_TYPE_NOSUPP

“…when a domain controller doesn’t have a certificate installed for smart cards…” is probably the most common reason for KDC_ERR_PADATA_TYPE_NOSUPP. If the DC doesn’t have a “Domain Controller”, “Domain Controller Authentication”, or another certificate with the Server Authentication EKU (OID 1.3.6.1.5.5.7.3.1) installed, the DC isn’t properly set up for PKINIT and authentication will fail.

Also, according to Microsoft, “This problem can happen because the wrong certification authority (CA) is being queried or the proper CA cannot be contacted in order to get Domain Controller or Domain Controller Authentication certificates for the domain controller.” At least in some cases we’ve been able to auth via PKINIT to a DC even when the CA is not reachable, so this situation may be hit and miss.

If you run into a situation where you can enroll in a vulnerable certificate template but the resulting certificate fails for Kerberos authentication, you can try authenticating to LDAP via SChannel using something like PassTheCert. You will only have LDAP access, but this should be enough if you have a certificate stating you’re a domain admin.

Lo primero que haremos será extraer la clave privada y el certificado desde el archivo PFX que obtuvimos del usuario Administrator. Para ello, utilizamos Certipy de la siguiente manera. A continuación, haremos uso de la herramienta PassTheCert.py para autentifcarnos con el certificado obtenido.

Con PassTheCert, utilizamos la clave privada y el certificado generado anteriormente para autenticarnos. El resultado confirma que estamos autenticados como HTB\Administrator, lo que significa que podemos conectarnos vía LDAP SChannel y realizar otras acciones para intentar escalar privilegios y obtener acceso completo al sistema.

Nº1 PrivEsc - Adding user to Domain Admins group trough PassTheCert Authentication

El primer método que probamos fue utilizar PassTheCert para conectarnos a una shell de LDAP que ofrece la herramienta. Desde ahí, usamos el comando add_user_to_group para añadir el usuario no privilegiado que teníamos previamente al grupo Domain Admins.

El resultado confirma que el usuario svc_ldap fue agregado con éxito al grupo Domain Admins, lo que nos otorga privilegios elevados en el dominio.

Conectados al DC con el usuario svc_ldap a través de WinRM (ya que verificamos previamente que tenía permisos para hacerlo), revisamos los miembros del grupo Domain Admins y confirmamos que ahora formamos parte de él.

Aunque ya tenemos privilegios de Domain Admin, nuestro objetivo final es convertirnos en el usuario Administrator. Para ello, exploraremos otros ataques que nos permitan obtener acceso directo a esta cuenta.

Como ahora formamos parte de Domain Admins, tenemos permisos para realizar un ataque DCSync, lo que nos permite extraer los hashes de las credenciales del dominio mediante secretsdump.py.

Aquí obtenemos el NT hash del usuario Administrator, lo que nos permitirá realizar un Pass-The-Hash y acceder directamente con su cuenta.

Verificamos que el NT hash obtenido es válido realizando un Pass-The-Hash (PTH) con nxc, lo que nos confirma que la autenticación con el hash NTLM del usuario Administrator es correcta. Luego, utilizamos Evil-WinRM para acceder al DC con privilegios de administrador y, finalmente, verificamos el contenido de la flag root.txt.

Nº2 PrivEsc - Assigning DCSync permissions to a user through PassTheCert Authentication

Otro método que encontramos es asignar permisos de DCSync a un usuario sin necesidad de añadirlo directamente al grupo Domain Admins, lo cual puede ser una acción más evidente. Utilizamos PassTheCert para otorgar estos permisos al usuario svc_ldap, lo que nos permite realizar un secretsdump posteriormente para extraer hashes de contraseñas sin necesidad de ser parte del grupo de administradores.

Con este método, le otorgamos al usuario svc_ldap permisos para realizar un DCSync sin necesidad de comprometer directamente a Domain Admins, lo que lo hace menos detectable. Esto nos permitirá extraer hashes de contraseñas y realizar otras acciones de escalada de privilegios.

En este caso, usamos nxc para realizar el dump del archivo NTDS.dit desde el controlador de dominio. Este es otro método que aprovechamos para obtener los hashes de contraseñas del dominio. En este proceso, conseguimos hacer el dump de los hashes NTDS del controlador de dominio. Entre los resultados obtenidos, encontramos varios hashes relevantes, como los de los usuarios Administrator, Guest, krbtgt, y svc_ldap.

Con esto, podríamos emplear la técnica de PassTheHash para autenticarnos como el usuario Administrator con su hash NTLM.

Nº3 PrivEsc - Resource-based Constrained Delegation (RBCD Attack) trough PassTheCert Authentication

En este caso, implementamos un ataque RBCD (Resource-based Constrained Delegation) para escalar privilegios. A través de PassTheCert, comenzamos creando un nuevo equipo dentro del dominio, lo que nos permite posteriormente aprovechar las delegaciones restringidas de recursos. Para esto, usamos el siguiente comando para añadir un equipo al dominio y asignarle una contraseña:

Este comando añadió con éxito una cuenta de máquina llamada rbcd_gzzcoo$ al dominio authority.htb, lo cual es el primer paso en la explotación de la delegación de recursos. El siguiente paso sería configurar la delegación para que esta máquina pueda ser utilizada en el ataque RBCD, lo que nos permitiría acceder a los recursos del dominio o a los servicios delegados con mayores privilegios.

El siguiente paso en la explotación de Resource-based Constrained Delegation (RBCD) consiste en configurar correctamente los permisos de delegación para que la máquina rbcd_gzzcoo$ pueda actuar en nombre de los usuarios de la máquina AUTHORITY$.

Con este comando, hemos configurado rbcd_gzzcoo$ para que pueda actuar en nombre de los usuarios en AUTHORITY$ mediante el protocolo S4U2Proxy. Esto significa que ahora la máquina rbcd_gzzcoo$ tiene permisos para suplantar identidades de los usuarios de AUTHORITY$, lo que nos proporciona un vector para escalar privilegios aún más.

Al permitir que rbcd_gzzcoo$ actúe en nombre de AUTHORITY$, tenemos acceso a las credenciales y recursos protegidos por las políticas de delegación en la máquina AUTHORITY$. Esto abre la puerta a la obtención de privilegios elevados y al acceso a más recursos dentro del dominio.

Después de configurar la delegación RBCD correctamente, utilizamos impacket-getST para obtener el Ticket Granting Ticket (TGT) del usuario Administrator y luego lo usamos para suplantarlo. Ejecutamos el siguiente comando para obtener el ticket y realizar la suplantación mediante S4U2Proxy.

Este proceso genera el ticket Kerberos necesario y lo guarda en el archivo Administrator@cifs_AUTHORITY.authority.htb@AUTHORITY.HTB.ccache. A continuación, usamos el ticket para ejecutar un comando wmiexec.py y obtener acceso remoto a la máquina AUTHORITY.

Esto nos otorga acceso con privilegios de htb\administrator. Al ejecutar whoami, verificamos que hemos conseguido los permisos de Administrator. También usamos el comando ipconfig para obtener detalles de la red, confirmando que la máquina AUTHORITY tiene la IP 10.10.11.222.

Con esto, logramos una escalada de privilegios exitosa utilizando RBCD a través de PassTheCert y Kerberos.

Última actualización

¿Te fue útil?