Authority | HackTheBox

Introducción

Authority es una máquina de dificultad media de HackTheBox basada en Windows.

En esta máquina se tocan conceptos de enumeración del protocolo SMB, donde encontraremos playbooks de Ansible, en estos playbooks se contiene "vaults" encriptados donde conseguiremos crackear cual es la contraseña y conseguir credenciales para una instancia de PWM que se está ejecutando en el puerto 8443.

Luego, conseguiremos credenciales válidas a nivel de dominio viendo las credenciales configuradas en este servicio para el protocolo LDAP en texto claro, accederemos al usuario en cuestión con evil-winrm ya que pertenece al grupo de "Remote Management Users".

La escalada de privilegios se basa en explotar ESC1 ya que detectamos con certipy que existe un certificado el cual podemos explotar y escalar privilegios, el problema es que en vez de permitir al usuario poder emitir certificados con esta plantilla, se permite emitir certificados al equipo, por lo cual, crearemos un equipo falso en el dominio y utilizaremos este para mediante LDAP añadir al usuario "svc_ldap" al grupo de Administradores de dominio.

Enumeración

Primero, con rustscan vamos a ver que puertos están abiertos por TCP.

Vemos algunos puertos comunes en entorno de directorio activo como el puerto 53/TCP que es el servicio de resolución de dominios (DNS), el puerto 88/TCP, kerberos, puerto 5985/TCP WinRM, puerto 389/TCP LDAP...

Vamos a realizar un escaneo un poco mas exhaustivo de los servicios de estos puertos con nmap para ver que servicio y versiones se están ejecutando por detrás, y vemos un servicio HTTP, vemos también un domino "authority.htb" y un servicio HTTP que no es común (8443), puerto que se utiliza alternativamente para servicios web con SSL.

Vamos a añadir este domino a nuestro /etc/hosts, cabe destacar que no se encuentra nada después de enumerar un poco mas a fondo el servicio DNS e intentar realizar un ataque de fuerza bruta para conseguir subdominios.

Este es el servicio en ejecución en el puerto 8443, es un PWM

Podemos buscar en Google y vemos que es un proyecto de código abierto para gestionar el servicio de LDAP.

Vemos que necesitamos una credencial para poder acceder a el y también vemos que se está leakeando un usuario que quizás sea válido a nivel de sistema, "svc_pwm".

Vamos a enumerar el servicio SMB, vemos que tenemos permiso de lectura haciendo uso de una Null Session para un recurso compartido a nivel de red llamado "Development".

Con mount -t cifs, voy a montar este recurso en /mnt/montura para que así me sea mas cómodo operar y realizar la enumeración.

Vemos muchos archivos, a parte de LDAP, vemos también un directorio llamado ADCS (Active Directory Certificate Services), esto mas el uso de algunos servicios web con SSL nos lleva a deducir que probablemente en la máquina víctima esté en ejecución el servicio ADCS.

Esto es algo a tener en cuenta ya que también, deberíamos comprobar con certipy o con Certify.exe si existen plantillas de certificados vulnerables para poder aprovecharnos y escalar privilegios o realizar un movimiento lateral.

Consiguiendo credenciales para el servicio PWM

Filtrando por los archivos .yml de los playbooks del directorio PWM, podemos ver datos encriptados haciendo uso de los vaults de Ansible, recordemos que para poder leer esta información, necesitaremos la passphrase con la que se han cifrado los bloques encriptados.

El comando "ca" en mi máquina es el comando "cat" original, ya que utilizo batcat como herramienta principal para visualizar datos y la tengo renombrada como "cat"

Sanitizamos los vaults para poder con ansible2john pasarlo a un formato crackeable.

Ahora, podemos utilizar hashcat o john para poder intentar crackear este hash.

Y podemos descubrir una contraseña para ambos vaults, excepto para el de LDAP.

Con ansible-vault decrypt podemos desencriptar los vaults utilizando la passphrase que hemos crackeado previamente.

Con kerbrute, voy a comprobar si ese usuario es válido a nivel de dominio y podemos comprobar que no.

Enumerando mas archivos de los recursos compartidos encontramos esta passphrase para una clave de la CA, la pongo en el writeup porque no me ha servido de nada ;)

También podemos ver la contraseña del servicio de PWM supuestamente.

Y podemos intentar iniciar sesión y comprobamos que efectivamente, esas credenciales son válidas para el servicio.

Consiguiendo las credenciales utilizadas para la autenticación por LDAP.

Si nos dirigimos a "Configuration Editor" y posteriormente introducimos la contraseña del usuario.

Podemos ver una sección de LDAP, recordemos que PWM se utiliza para gestionar LDAP, y nos damos cuenta de que la contraseña configurada está guardada pero no la podemos visualizar.

También podemos darnos cuenta de que está puesto una URL para la autenticación por LDAP pero podemos modificar este campo...

Si le damos al botón de "Test LDAP Profile" vemos que la conexión ha fallado.

Voy a modificar la URL y voy a poner la dirección IP de mi máquina atacante y voy a ponerme en escucha con netcat por el puerto 636.

Y los datos están cifrados, esto es porque me he equivocado al poner la URL y he especificado el uso de ldaps y no de ldap, por lo cual los datos viajan de manera cifrada.

Modificamos de nuevo la URL..

Y tenemos las supuestas credenciales para LDAP y un usuario nuevo.

Enumerando un nuevo recurso compartido y consiguiendo acceso a la máquina

Podemos comprobar que son credenciales válidas a nivel de dominio con nxc , el sucesor de crackmapexec y podemos comprobar que tenemos acceso de lectura a un nuevo recurso compartido a nivel de red por SMB.

Al inspeccionar este recurso vemos que no contiene nada..

Y al comprobar si tenemos acceso remoto a la máquina a través de WinRM vemos que efectivamente, podemos conseguir una shell.

Con evil-winrm conseguimos una consola interactiva en la máquina víctima.

Aquí estaría la flag de usuario.

Post-Explotación, detectando la vulnerabilidad ESC1

Podemos ver en la raíz del sistema un directorio llamado "Certs", lo cual me recuerda que debo de comprobar las plantillas para detectar si existe alguna vulnerabilidad con la que poder escalar privilegios.

Encontramos un certificado .pfx

Me lo llevo a mi máquina e intento comprobar la contraseña SuP3rS3creT encontrada anteriormente pero no hay suerte.

También intento crackearla con john pero no consigo nada.

Enumerando los grupos y los privilegios de este usuario, podemos ver que pertenece al grupo de "Certificate Service DCOM Access", esto sería otro indicio de que se está utilizando ADCS por detrás.

Con Certify.exe , compruebo si existen plantillas vulnerables y vemos una plantilla vulnerable llamada CorpVPN.

También podríamos haberla detectado con certipy.

Y vemos que es vulnerable a ESC1 pero el permiso para poder emitir certificados con esta plantilla es dirigido a los equipos del dominio, y no a los usuarios del dominio.

Os dejo un par de sitios interesantes hablando sobre este caso en concreto.

https://viperone.gitbook.io/pentest-everything/everything/everything-active-directory/adcs/esc1

https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4

Creando un nuevo equipo en el dominio

Por defecto, en entornos de directorio activo se permite a todos los usuarios del dominio añadir hasta a 10 equipos en el dominio.

Esto con WinPEAS lo podemos detectar fácilmente también.

Podemos ver que el atributo cachedlogonscount es 10.

Este atributo significa cuantos inicios de sesión son cacheados de forma local, este atributo por defecto también vale 10, y no siempre es así, pero cuando este atributo vale 10, normalmente el ms-DS-MachineAccountQuota también vale 10.

Por supuesto que podemos comprobar manualmente cuantos equipos podemos añadir al dominio.

Ahora con addcomputer.py de la suite de impacket, podemos crear un nuevo PC y añadirlo al dominio, en mi caso lo voy a llamar POINTEDPC y le voy a asignar la contraseña pointedsec123

PassTheCert

Ahora debemos de apuntar el nombre de la CA y el DNS Name del DC para poder solicitar con certipy el certificado vulnerable suplantando el UPN del usuario administrador para poder hacer PassTheCert y ganar acceso como administrador a la máquina.

Apuntamos el nombre de la CA y el DNS Name.

Y ahora con certipy, solicitamos el certificado vulnerable "CorpVPN" utilizando el nombre y la contraseña del falso equipo que hemos creado en el dominio y especificando de UPN el de administrator.

A la hora de hacer PassTheCert pasa lo siguiente...

KDC has no support for padata type

Este error me lleva a una entrada del blog de AlmondConsulting, donde explica muy bien el porqué ocurre este error y como conseguir acceso a la víctima.

Este error ocurre ya que el controlador de dominio no soporta PKINIT, y bien, ¿qué es PKINIT?

Primero hay que entender que es PKINIT, es un mecanismo de Kerberos que utiliza certificados X.509 como método de pre-autenticación. Estos certificados pueden ser utilizados para solicitar TGT's e incluso el hash NT de la cuenta de usuario.

También hay que entender que es el EKU, el EKU (Enhanced Key Usage) es una extensión en un certificado digital que especifica los propósitos para los que puede ser usado. En el contexto de un Controlador de Dominio, el EKU de "Inicio de Sesión con Tarjeta Inteligente" (Smart Card Logon) indica que el certificado puede ser utilizado para autenticar el inicio de sesión de usuarios que usan una tarjeta inteligente.

Sin el EKU de "Smart Card Logon", los Controladores de Dominio no pueden usar PKINIT (Public Key Cryptography for Initial Authentication) para autenticarse con tarjetas inteligentes. Esto puede llevar a fallos en los intentos de inicio de sesión que dependan de este método.

Y como el DC no tiene el EKU que necesitamos, no podemos hacer PassTheCert de manera convencional. No hay que alarmarse ya que protocolos como LDAP permiten la autenticación por TLS/SSL, además, antes nos hemos dado cuenta que en el servicio PWM, la URL que estaba pre-configurada utilizaba el protocolo LDAPS el cual utiliza certificados.

Agregando al usuario svc_ldap al grupo de administradores de dominio

Una vez explicado todo esto, podemos utilizar la herramienta de AlmondConsulting.

https://github.com/AlmondOffSec/PassTheCert/

Utilizando su herramienta en Python, podemos con -action ldap-shell ganar una consola para interactuar con el LDAP. Una vez la tengamos, añadimos al usuario svc_ldap al grupo de Administradores del Dominio.

Ahora simplemente cerramos la shell con evil-winrm que teníamos con el usuario svc_ldap y la volvemos a ejecutar y podemos ver que ahora este usuario es administrador.

Y ya podríamos visualizar la flag de superusuario.