Infiltrator
Reconnossaince
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Infiltrator. 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.
Procederemos a transformar 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 netexec y ldapsearch procederemos a enumerar 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.
Procederemos a añadir 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 equipo.
Por otro lado, para trabajar con el protocolo de Kerberos y no tener problemas durante la explotación de la máquina, deberemos de sincronizar nuestro reloj con la del Domain Controller.
Además, deberemos de informar en el archivo /etc/resolv.conf la dirección IP del DC para no tener problemas posteriormente.
Web Enumeration
Nuestro primer objetivo será la página web de http://infiltrator.htb, en la cual a simple vista no vemos ningún dato interesante que nos pueda servir.
Information Leakage
Revisando en el apartado de About, verificamos que aparecen nombres de los empleados. Esta información nos puede servir.
Guardaremos los nombres completos de los empleados que aparecían en la página. A través del script de namenash.py procederemos a crear un listado de usuarios a través del listado de empleados que disponemos.
A través de la herramienta de Kerbrute, enumeraremos el listado de usuarios que nos ha generado el script anterior. En el resultado obtenido, verificamos que de los 78 usuarios posibles que teníamos, solamente 7 usuarios son válidos a nivel de dominio.
Procederemos a guardarnos los usuarios válidos del dominio en el archivo users.txt.
AS-REP Roast Attack (GetNPUsers)
Dado que disponemos de un listado potencial de usuarios, realizaremos el ataque de AS-REP Roast Attack. Al realizar el ataque revisará si alguno de los usuarios que disponemos dispone de la flag (DONT_REQ_PREAUTH) de Kerberos, para así obtener un hash TGT (Ticket Granting Ticket) que posteriormente podremos intentar crackear.
En este caso, verificamos que hemos logrado obtener el hash TGT del usuario l.clark@infiltrator.htb, este hash lo almacenaremos en un archivo.
Intentaremos crackear el hash obtenido a través de la herramienta hashcat, en este caso, logramos obtener la contraseña en texto plano del usuario l.clark@infiltrator.htb.
Verificaremos a través de la herramienta nxc de validar las credenciales obtenidas, comprobamos que son válidas para dicho usuario.
LDAP Enumeration (ldapdomaindump)
Dado que disponemos de credenciales válidas, procederemos a realizar una enumeración de LDAP a través de la herramienta de ldapdomaindump.
Al revisar el archivo domain_users, verificamos el listado de usuarios del dominio. También notamos que el usuario k.turner@infiltrator.htb en su campo Description aparece lo que parece ser una contraseña.
Probaremos de validar si esas credenciales encontradas en el LDAP son válidas para el usuario. Verificamos que no podemos autenticarnos con estas credenciales, alomejor nos pueden servir para más adelante...
NTLM is disabled? Testing Kerberos authentication
Al realizar un Password Spraying de una de las credenciales que disponemos, verificamos que en dos cuentas nos aparece el mensaje de STATUS_ACCOUNT_RESTRICTION, lo cual nos llama bastante la atención.
Al volver a ejecutar el mismo comando anterior pero indicando que se autentique mediante Kerberos y no NTLM, verificamos que las credenciales también son válidas para el usuario d.anderson@infiltrator.htb.
Esto nos lleva a la siguiente pregunta: es posible que la autenticación NTLM esté deshabilitada para algunos usuarios, por ese motivo nos marca como STATUS_ACCOUNT_RESTRICTION.
Si realizamos nuevamente el Password Spraying desde la herramienta de Kerbrute, verificamos que obtenemos el mismo resultado anterior.
Validaremos que con el usuario d.anderson@infiltrator.htb a través de autenticación NTLM no podemos autenticarnos, en cambio, a través de la autenticación de Kerberos si.
Procederemos a solicitar un TGT (Ticket Granting Ticket) para el usuario, para poder utilizarlo para autenticarnos con este usuario. El ticket obtenido d.anderson.ccache lo almacenaremos en la variable KRB5CCNAME y verificaremos a través de klist -e de que el ticket TGT está correctamente configurado.
BloodHound Enumeration
A continuación, realizaremos una enumeración del dominio entero a través de BloodHound. El siguiente comando nos creará un archivo .zip el cual contendrá toda la información del dominio. Lo que buscamos en realizar esta enumeración es buscar posibles vectores de ataque para escalar nuestros privilegios.
En este caso hemos utilizado al usuario d.anderson y nos autenticamos mediante Kerberos -k, pero podríamos haber utilizado el usuario l.clark dado que esta usuaria se puede autenticar mediante NTLM.
Revisando en BloodHound, verificamos que solamente el usuario Administrator es un Domain Admin.
Verificando posibles vías potenciales para escalar nuestros privilegios actuales, nos encontramos con el siguiente path que parece ser el más adecuado para llegar a conectarnos al Domain Controller.
Initial Access
Abuse of GenericAll privileges on an OU to gain full control of objects
Verificamos que el usuario que disponemos actualmente, dispone de privilegios GenericAll sobre la Organizational Unit (OU) llamada MARKETING DIGITAL.
Esto indica que tiene el control total sobre la OU, un privilegio peligroso debido que podemos tener el control total de esta OU y de los objetos que se encuentren en esta misma.
A través de la herramienta de bloodyAD nos convertimos en propietarios de la OU y nos otorgamos permisos de genericAll para tener control de la OU y de los objetos que se encuentren en esta.
En un principio, deberíamos de disponer de control sobre los objetos que se encuentren en esta OU. Durante el proceso al tratar de modificar algún objeto que se encontraba en esta nos indicaba que no disponíamos de privilegios suficientes.
Realizando una búsqueda nos encontramos con el siguiente blog, el cual nos indica que para tener un control total sobre las Organizational Units (OUs) debíamos de modificar el siguiente DACL.
A través del primer comando, nos proporcionamos el control total de la OU y objetos que se encuentran en esta misma y mediante el segundo comando verificamos que el paso anterior se haya realizado correctamente.
Volviendo a revisar en el BloodHound, verificamos que en la OU MARKETING DIGITAL se encontraba el usuario e.rodriguez@infiltrator.htb.
Por lo tanto, dado que nos hemos otorgado el control total sobre la OU y los objetos secundarios, por ende, deberíamos de tener control total con el usuario d.anderson@infiltrator.htb sobre el usuario e.rodriguez@infiltrator.htb.
A través de bloodyAD realizamos el cambio de contraseña del usuario mencionado. Posteriormente a través de nxc,verificamos que el cambio se realizó correctamente.
Abusing AddSelf privileges to add myself on a group
Revisando nuevamente en la ruta que encontramos en BloodHound, verificamos que el usuario que disponemos actualmente tiene permisos de AddSelf sobre el grupo CHIEFS MARKETING.
Por lo tanto, el usuario dispone de permisos para añadirse a sí mismo al grupo mencionado.
Lo primero de todo será solicitar un TGT (Ticket Granting Ticket) del usuario e.rodriguez@infiltrator.htb. Almacenaremos el ticket TGT en la variable KRB5CCNAME y validaremos que esté correctamente configurada.
A través de bloodyAD, nos añadiremos a nosotros mismos al grupo CHIEFS MARKETING. Verificamos que nos aparece que nos hemos añadido correctamente a través de ldapsearch.
Abuse ForceChangePassword privileges to change a user's password
En BloodHound verificamos que los miembros del grupo CHIEFS MARKETING disponen del permiso ForceChangePassword sobre el usuario m.harris@infiltrator.htb, pudiendo modifcarle la contraseña sin disponer de la actual del usuario.
Realizaremos el cambio de contraseña del usuario m.harris@infiltrator.htb a través de la herramienta de bloodyAD, verificaremos que se ha modificado correctamente las credenciales.
Abuse CanPSRemote privileges to connect with machine
Revisando nuevamente en BloodHound, verificamos que el usuario que disponemos tiene privilegios de CanPSRemote sobre el Domain Controller DC01. Esto nos proporciona el privilegio de acceder remotamente al equipo, mediante WinRM o RDP.
Procederemos a solicitar el TGT (Ticket Granting Ticket) del usuario actual, verificaremos que se encuentra correctamente configurado el TGT.
Nos conectaremos mediante evil-winrm al DC y verificaremos la flag de user.txt.
En esta máquina por x motivos no funciona correctamente WnRM, al menos en mi caso se quitaba la conexión cada x tiempo.
Por lo tanto, lo que hicimos fue utilizar la Reverse Shell del repositorio de Nishang. Renombramos el archivo Invoke-PowerShellTcp.ps1 a rev.ps1. Deberemos modificar el archivo para que realice el Invoke de la Reverse Shell al final del script. En este caso, modificamos un poco el script para que el AV no lo detecte tan facilmente.
Nos ponemos en escucha por el puerto indicado en el script rev.ps1.
Codificamos en Base64 de Windows el comando que desde el equipo DC01 ejecutaremos y levantaremos un servidor web con Python.
Desde la consola donde hemos iniciado sesión con evil-winrm, ejecutaremos el comando encodeado en Base64 para otorgarnos la Reverse Shell.
Verificamos que hemos logrado obtener el acceso correctamente al equipo, desde esta terminal no tendremos problemas de desconexión al equipo.
Output Messenger
En la enumeración inicial del equipo, nos encontramos que se encontraba instalado una aplicación llamada Output Messenger, algo inusual en máquinas de HTB.
Realizamos una búsqueda por internet sobre la aplicación. Al parecer, es una aplicación bastante parecida a Microsoft Teams.
Para buscar posibles vectores de escalar nuestros privilegios en la máquina víctima, decidimos hacer uso de la herramienta de winPEAS.exe. Este binario lo deberemos de disponer en nuestro equipo local, lo compartiremos a través de un servidor web.
Desde el equipo comprometido, procederemos a descargar el binario en una ruta que el AppLocker no lo detecte.
Ejecutaremos el winPEAS.exe y el output lo almacenaremos en un archivo llamado result.txt.
Para compartirnos este resultado en nuestro equipo local, decidimos en levantar un servidor SMB en nuestra Kali.
Copiaremos el archivo result.txt en el recurso compartido SMB que hemos levantado desde Kali.
Revisando el resultado obtenido del escaneo de winPEAS, verificamos que existen varios puertos en escucha sobre la aplicación de Output Messenger. Lo cual nos hace pensar que la aplicación está en ejecución en el DC actualmente.
Performing a Windows port forwarding to my Kali machine
Disponemos de los siguientes puertos que utiliza la aplicación Output Messenger, nuestro objetivo será compartir estos puertos internos del DC hacía nuestra Kali Linux mediante Port Forwarding.
14118 14119 14121 14122 14123 14125 14126 14127 14128 14130 14406
En nuestra Kali, deberemos de disponer de los binario de chisel para UNIX y Windows. El binario de chisel.exe lo dberemos de compartir en el Domain Controller a través de un servidor web.
Desde el equipo víctima, descargaremos el binario chisel.exe en la ruta donde el AppLocker no nos lo detecte.
Configuraremos el chisel como servidor en nuestra máquina Kali, el puerto de servidor que utilizaremos es el 1234.
Desde la máquina víctima, la configuaremos como cliente para que se conecte al servidor de nuestra Kali. Compartiremos todos los puertos internos que utiliza la aplicación Output Messenger para que sean los mismos puertos en nuestra Kali Linux.
Desde Kali revisaremos que disponemos de los puertos en LISTEN, significando que se ha realizado el Port Forwarding correctamente y ya los tenemos accesibles desde nuestro equipo.
Sharing the OpenVPN Connection from Linux with Windows so we can have two boxes connected simultaniously
La aplicación de Output Messenger, al parecer desde Linux no funciona, por lo cual decidimos probar de utilizarla en una máquina Windows que disponíamos.
El problema aquí es que los puertos que hemos realizado el Port Forwarding se encuentran en nuestra máquina Kali, podríamos realizar nuevamente el Port Forwarding con chisel para compartir los puertos de Kali hacía nuestro otro equipo Windows.
En este caso, optamos por compartir nuestra conexión de OpenVPN de Kali Linux con la máquina Windows para tener ambas máquinas conectadas simulteanamente.
Primero de todo, deberemos de habilitar el reenvío de paquetes. Después configuramos las reglas de las tablas de filtrado iptables para permitir el tráfico entrante y saliente desde la interfaz tun0 (OpenVPN) hacia eth0 (la interfaz de red física).
Verificamos la dirección IP que disponemos en Kali Linux para realizar el MASQUERADE y poder compartir la conexión de Kali Linux, usamos una regla en la tabla NAT.
Desde nuestra máquina Windows (atacante) verificamos que no disponemos de conexión al equipo del Domain Controller aún.
Por lo tanto, tuvimos que agregar manualmente las rutas necesarias para que Windows pueda comunicarse correctamente con las redes detrás de la VPN. Verificamos que disponemos de conexión con el DC y con la IP de nuestra Kali de la interfaz tun0.
Logging in as k.turner in Output Messenger
Descargaremos la aplicación de Output Messenger desde el siguiente enlace, deberemos de descargar la versión de Cliente Windows.
Si bien recordamos, en la enumeración de LDAP, encontramos en el campo Description lo que parecía ser una contraseña.
Abriremos la aplicación de Output Messenger y procederemos a iniciar sesión con las credenciales k.turner/MessengerApp@Pass!. La dirección IP que especificaremos es la que disponemos en nuestra máquina Kali de la interfaz física eth0.
Perfecto, hemos podido iniciar sesión en la aplicación con el usuariok.turner. A continuación, deberemos explorar los diferentes chats y funciones para intentar buscar algún tipo de información interesante.
En el chatroom Dev_chat encontramos la siguiente conversación, donde se discute el desarrollo de una herramienta llamada UserExplorer.exe para recuperar información de usuarios desde un servidor LDAP. Aquí algunos puntos clave y lo más interesante:
Desarrollo de la herramienta: Se está creando una aplicación que permitirá obtener detalles de los usuarios de LDAP, como nombre, correo electrónico y teléfono, utilizando el protocolo LDAP.
Seguridad en las credenciales: Se ha implementado el uso del descifrado AES para manejar las contraseñas, garantizando así la confidencialidad de los datos sensibles.
Opciones de entrada: La herramienta admitirá argumentos de línea de comandos para el nombre de usuario, la contraseña y el usuario buscado, ofreciendo una opción predeterminada para facilitar el uso.
Estado actual: Actualmente, la aplicación está en fase de pruebas exhaustivas realizadas por el equipo de control de calidad, y se están refinando los mensajes de error para asegurar una experiencia fluida para el usuario.
Information leakage (password filtered in notices)
Si nos dirigimos al apartado de Notices, vemos una noticia que habla sobre una alerta sobre la autenticación previa se encuentra deshabilitada en Kerberos para algunos usuarios. Esto nos confirma el motivo por el cual algunos usuarios aparecían como restringidos.
Por otro lado, también vemos que en las noticias aparecen lo que parecen ser las credenciales de acceso del usuario m.harris@infiltrator.htb.
Probaremos de realizar un Password Spraying para verificar si estas credenciales son válidas para algún usuario.
Logging in as m.harris in Output Messenger
Probaremos de autenticarnos en la aplicación de Output Messenger en busca de ver si con este usuario tenemos más información interesante que nos pueda servir.
Vemos que disponemos de un chat con el usuario Admin, el cual nos comparte el binario de la aplicación UserExplorer.exe que anteriormente estuvieron hablando en el chat de Dev_Chat. Nos descargaremos el binario accediendo a través de la opción de Open Folder.
Dispondremos del binario de UserExplorer.exe, el cual realizaremos una copia en nuestro Desktop.
Debugging with dnSpy
Al analizar el binario, nos encontramos que aparecen las credenciales cifradas del usuario winrm_svc. Si bien recordamos en la conversación del chatroom de Dev_Chat, estaban intentando cifrar esta contraseña en cifrado AES.
A través del siguiente script, lo que realizaremos es descodificar la contraseña cifrada para obtenerla en texto plano.
Al ejecutar el script y pasarle el valor de la contraseña cifrado, verificamos que nos devolvío un string parecido a Base64. Al intentar descodificar el contenido en Base64 no nos devolvió un resultado legible.
Por lo que volvimos a ejecutar el script pero indicándole este nuevo valor obtenido. Al parecer pudimos desencriptar la contraseña cifrada y obtener la contraseña en texto plano.
Validamos que efectivamente estas credenciales son válidas para el usuario winrm_svc@infiltrator.htb.
Logging in winrm_svc in Output Messenger
Probaremos de acceder a Output Messenger con las credenciales recién obtenidas.
Revisando los chats, O. Martínez reportó que recibe ventanas emergentes de sitios web al azar todos los días a las 09:00 a. m. Durante la conversación, mencionó que no ha compartido su contraseña, salvo con el grupo Chiefs_Marketing_chat.
Esto nos interesa, ya que revisar las conversaciones de ese grupo podría revelar detalles sobre la contraseña del usuario, permitiéndonos verificar su validez y potencialmente utilizarla para realizar ataques de pivoting o escalar privilegios.
Por otro lado, en la sección de notas, verificamos que nos aparece una API Key, deberemos investigar si podemos hacer uso de esta API Key en algún servicio.
Using Output Messenger API to retrieve conversations logs on a group
Buscamos por internet información sobre la API de Output Messenger, en la cual nos encontramos con la siguiente página en donde nos informa como poder utilizar la API de la aplicación.
Revisando más información sobre las posibilidades del uso del API, verificamos que hay un apartado en el cual a través de la API, podemos visualizar los logs de un chat room.
Esto nos interesa bastante, debido que si bien recordamos, el usuario O.martinez compartió sus credenciales en el chat Chiefs_marketing_chat.
Para poder comprobar los logs del chat room, necesitaríamos los siguientes datos:
[roomkey]- Chat Room Key.[fromdate] - Start Date.
[todate]- End Date.
Nos faltaría saber cual es la roomkey del chat room que queremos revisar los logs.
Para empezar, primero revisaremos como funciona la API, en este ejemplo, se nos muestra como authenticarnos a través de nuestra API-KEY.
Desde nuestra máquina Kali, interceptaremos la solicitud con FoxyProxy y BurpSuite sobre la dirección http://127.0.0.1:14125/api/users, lo realizamos desde localhost (127.0.0.1) ya que anteriormente nos compartimos los puertos internos del DC a nuestra Kali Linux.
Al tener la solicitud interceptada en BurpSuite, le indicaremos la API-KEY que encontramos anteriormente. Verificamos que hemos podido consultar los usuarios correctamente tal y como nos indicaba el ejemplo de Authentication.
Ya sabemos como utilizar el API-KEY para utilizar la API, ahora lo único que nos queda es saber cual es el roomkey del chat room de Chiefs_Marketing_chat.
Después de una larga búsqueda, decidimos revisar si en el AppData del usuario winrm_svc había algún dato interesante.
Revisando los grupos a los que formaba parte el usuario winrm_svc, verificamos que formaba parte del grupo Remote Management Users, por lo tanto nos podremos conectar en remoto al equipo.
Para ello, primero deberemos de solicitar un TGT (Ticket Granting Ticket) del usuario, almacenarlo en la variable KRB5CCNAME y verificar que el ticket TGT esté correctamente configurado.
Al proceder a conectarnos al equipo mediante evil-winrm y, revisando el directorio AppData nos encontramos con dos archivos .db3 que quizás podríamos llegar a encontrar información interesante. Nos descargamos ambos archivos para tenerlos localmente en nuestro equipo.
Al revisar el archivo OM.db3 con la herramienta de sqlite3, verificamos que hemos logrado obtener la roomkey del chat Chiefs_Marketing_chat.
Ya disponemos de lo que parece ser la roomkey del chat room que queremos ver sus logs.
Por lo tanto, siguiendo el API Helper de la documentación del Output Messenger que nos encontramos, procederemos a ver los logs de las fechas recientes. En la conversación con O.martinez, la conversación que mantienen es el 20 de Febrero de 2024.
En este caso, buscaremos los logs entre las fechas del 19 al 20 de febrero utilizando la roomkey. Verificamos que hemos logrado al parecer leer los logs de este chat.
Revisando los logs del chat, verificamos lo que parece ser el mensaje que decía O.martinez en el cual compartía su contraseña en este grupo.
Procederemos a verificar si estas credenciales siguen siendo válidas a nivel de dominio. En este caso, al parecer, la usuaria debió cambiar sus credenciales por seguridad después de recibir varias alertas de SPAM.
Logging in O.martinez in Output Messenger
De casualidad, probamos de autenticarnos con estas credenciales al Output Messenger, para verificar si el usuario había cambiado también las credenciales en esta aplicación de mensajería.
Logramos acceder con el usuario O.martinez, además logramos visualizar el grupo Chiefs_Marketing_chat en el cual efectivamente, había compartido sus credenciales de acceso.
Running a malicious binary to get a Reverse Shell with a Calendar "Run application" function on Output Messenger
Revisando las funciones de la aplicación, nos encontramos que a través de crear un nuevo evento en el calendario, eramos capaces de ejecutar una aplicación.
Por lo tanto, lo que se probó a realizar es a crear un payload malicioso de una Reverse Shell. En este caso se utilizó msfvenom para crear un binario .exe malicioso que al ejecutarse nos proporcionaría una Reverse Shell. Compartiremos este binario malicioso a través de un servidor web.
Desde otra terminal, nos pondremos en escucha para recibir la Reverse Shell.
Desde el equipo Windows (atacante) el cual hemos instalado el Output Messenger, procederemos a descargar el binario malicioso y lo ejecutaremos.
Vemos que funciona la reverse.exe, pero al ejecutarlo nosotros manualmente, el usuario que recibimos es el de nuestra máquina Windows (atacante).
Por lo tanto, el objetivo será crear un nuevo evento para intentar y verificar si el usuario O.martinez es capaz de ejecutar el binario malicioso reverse.exe correctamente y obtener una Shell con ese usuario.
Verificamos que se ha creado correctamente el evento. Deberemos de esperar a que el tiempo transcurra y verificar si funciona o no.
Después de diversas pruebas, logramos obtener una Shell como usuario O.martinez@infiltrator.htb.
Privilege Escalation
Analyzing a Wireshark PCAP File
Revisamos en el directorio AppData del usuario actual si había algún tipo de información interesante. Comprobando en varios directorios, nos encontramos con un archivo de una captura de Wireshark.
Nos volveremos a montar un servidor SMB en nuestra Kali para compartirnos este archivo encontrado.
Copiaremos el archivo mencionado al recurso compartido SMB que tenemos en nuestra Kali.
Abriremos la captura de Wireshark obtenida, verificaremos el siguiente resultado.
En el resultado obtenido, verificamos que hay una solicitud que se descarga a través del métoddo GET, un archivo llamado BitLocker-backup.7z. Lo que intentaremos es recuperar el archivo original. Para ello, en la solicitud donde se confirmó la descarga con un 200 OK, haremos click derecho e ingresaremos a Seguir < HTTP Stream.
Indicaremos que muestra la Conversación completa y que el resultado se muestre en formato Raw, guardaremos el archivo en nuestro directorio de trabajo.
Verificaremos que disponemos del archivo BitLocker-backup.raw, procederemos a revisar el archivo a través de la herramienta de hexedit.
Recovering original file obtained in Wireshark capture (hexedit)
El objetivo será recuperar el archivo original obtenido de la captura de Wireshark. Para ello, lo primero será localizar en que sección de la memoria empieza el archivo 7z. Según ChatGPT, las cabeceras de archivos 7z empiezan normalmente por 37 7A BC AF 27 IC.
Revisando el archivo en hexadecimal y situándonos en la cabecera de donde empieza el archivo, vemos que en la parte inferior nos muestra que el archivo empieza por los valores 0x3A5/0x33554.
El siguiente paso será eliminar toda la parte superior del archivo raw. Para ello, crearemos dos variables de entorno que nos indique la posición exacta del byte y que a partir de ahí sobreescriba el archivo .raw.
Verificamos que hemos logrado obtener el archivo original sobreescribiendo el raw obtenido anteriormente.
Descromprimiremos el archivo BitLocker-backup.7z y vemos que requiere de credenciales para acceder al archivo, credenciales que no disponemos.
A través de 7z2john lo que realizamos es obtener el hash de la contraseña del archivo y almacenarlo en un archivo llamado hash7z.
Al intentar crackear este hash obtenido con john, verificamos que hemos logrado crackear el hash y obtener su contraseña.
Al volver a descomprimir el archivo 7z, verificamos que nos ha descomprimido correctamente el archivo.
Decrypting BitLocker-encrypted disk via obtained recovery key and obtaining a backup of NTDS.dit
Revisando el resultado obtenido del archivo 7z, verificamos que hay un archivo HTML. Procederemos a montar un servidor web con Python para revisar el contenido del archivo.
Al acceder al servidor web de nuestro equipo, logramos verificar que se trata de una clave de recuperación de BitLocker.
Revisando nuevamente el archivo de Wireshark obtenido, verificamos que el usuario O.martinez realizó un cambio de credenciales y estas aparecen en texto plano.
Verificaremos si estas nuevas credenciales obtenidas nos permiten acceder al sistema, efectivamente hemos logrado autenticarnos correctamente.
Revisamos en BloodHound de que el usuario O.martinez@infiltrator.htb dispone de privilegios CanRDP sobre el equipo DC01. Por lo cual podríamos conectarnos por RDP al Domain Controller.
Nos conectaremos mediante xfreerdp3 al DC para tener acceso remoto por RDP y tener entorno gráfico.
Verificamos que disponemos del disco C: y de una unidad cifrada con BitLocker E:.
Al intentar acceder a la unidad E:, verificamos que nos requiere de credenciales para acceder. Entre las opciones nos aparece la opción de Enter recovery key para introducir una clave de recuperación de BitLocker.
Ingresaremos la clave de recuperación de BitLocker que obtuvimos anteriormente para desbloquear la unidad cifrada.
Conseguimos tener acceso a la unidad E:, entre los directorios de la unidad, verificamos que en el directorio E:\Windows Server 2012 R2 - Backups\Users\Administrator\Documents disponía de un archivo de backup llamado Backup_Credentials.7z.
Deberemos de compartir este archivo a nuestro equipo local. Para ello, montaremos un servidor SMB que utilice las credenciales del usuario O.martinez.
Conectaremos esta unidad en el DC y copiaremos el archivo de Backup en nuestro recurso compartido.
Verificaremos que logramos tener el archivo de Backup, al proceder a descomprimir el archivo, verificamos que logramos disponer lo que parece ser de un Backup de los archivos NTDS.dit, SYSTEM y SECURITY.
Exportaremos los hashes NTLM del archivo NTDS.dit, verificamos que logramos obtener los hashes de todos los usuarios del AD, entre ellos las del usuario Administrator.
Al intentar validar si podemos realizar Pass-The-Hash con este hash NTLM del usuario Administrator, comprobamos que este hash ya no es válido y no podemos autenticarnos como él.
Transforming a NTDS.dit file to SQLite file (ntdsdotsqlite)
Dado que no logramos extraer ningún tipo de información ni ninguna credencial válida en el NTDS.dit. Descubrimos la siguiente herramienta que nos transforma el NTDS.dit en un archivo DB para abrirlo con sqlitebrowser.
Al revisar en los diferentes campos, logramos verificar que aparece lo que parecen ser unas credenciales para el usuario lan_managment@infiltrator.htb.
Validaremos si estas credenciales siguen siendo válidas para el usuario encontrado. Efectivamente estas credenciales nos sirven correctamente.
Abusing ReadGMSAPassword Rights
Al revisar nuevamente en BloodHound, verificamos que el usuario que disponemos, tiene privilegios de ReadGMSAPassword sobre el objeto infiltrator_svc$@infiltrator.htb.
A través de la herramienta de bloodyAD, procederemos a leer la contraseña del GMSA. Logramos obtener el hash NTLM del objeto en cuestión.
Validamos si podemos hacer un Pass-The-Hash con este hash NTLM y el usuario, verificamos que logramos validar las credenciales correctamente.
ESC4 exploitation case with certipy-ad
Buscando vías potenciales de elevar nuestros privilegios, verificamos que este usuario, forma parte del grupo Certificate Service DCOM Access, lo cual nos replantea investigar si podemos abusar de los ADCS (Active Directory Certificate Services).
Con la herramienta de certipy-ad buscaremos si existe algún template que sea vulnerable. En este caso nos muestra que podemos efectuar el ESC4.
Realizaremos la explotación del ESC4 de los ADCS (Active Directory Certificate Services).
Configuraremos la template obtenida para que sea vulnerable.
Revisaremos nuevamente que la Template se ha modificado correctamente.
Abusaremos de la template vulnerable para que el usuario Administrator utilice la template vulnerable y se nos proporcione el certificado administrator.pfx.
Con este certificado, procederemos a utilizarlo para obtener el hash NTLM del usuario Administrator o obtener el ticket TGT administrator.ccache.
Validaremos que el hash NTLM obtenido es correctamente válido para el usuario Administrator.
Procederemos a conectarnos al Domain Controller realizando Pass-The-Hash, logramos obtener la flag de root.txt.
También podemos hacer uso del ticket TGT administrator.ccache para autenticarnos y conectarnos al Domain Controller mediante wmiexec por ejemplo.
Última actualización
¿Te fue útil?