Multimaster
Multimaster es una máquina Windows de una dificultad increíble que presenta una aplicación web que es vulnerable a la inyección SQL. Esta vulnerabilidad se aprovecha para obtener un punto de apoyo en el servidor.
El examen del sistema de archivos revela que está instalada una versión vulnerable de VS Code y se encuentran procesos de VS Code ejecutándose en el servidor.Al explotar la función de depuración, se puede obtener un shell como el usuario cyork. Se encuentra una contraseña en una DLL, que debido a la reutilización de contraseñas, da como resultado un shell como sbauer.
Se descubre que este usuario tiene permisos GenericWrite sobre el usuario jorden. Abusar de este privilegio nos permite obtener acceso al servidor como este usuario. jorden es miembro del grupo Operadores de servidor, cuyos privilegios explotamos para obtener un shell de SISTEMA.
Reconnaissance
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Multimaster. 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.
Web Enumeration
Procederemos a realizar una enumeración sobre el sitio web que hemos encontrado expuesto en el puerto 80. La página principal al principal dispone de varias secciones que deberemos explorar para verificar
Una de las primeras acciones a realizar, será verificar las tecnologías y frameworks que utiliza la aplicación web, esto lo podremos realizar a través del Add-on de Wappalyzer. Entre la información recopilada, podemos verificar que hay un Windows Server como sistema operativo que levanta la aplicación web, utiliza un IIS (Internet Information Services).
Toda esta información hay que contrastarla con otras herramientas para verificar que la información sea válida.
Otra de las herramientas para verificar las tecnologías que utiliza una aplicación web es la herramienta de whatweb.
Revisaremos la página que hemos encontrado http://10.10.10.179/#/login y en este caso al intentar iniciar sesión con credenciales por defecto nos indica que el Login se encuentra en mantenimiento en estos momentos y no se puede utilizar. Intentamos realizar la típica inyección SQL para verificar si es vulnerable el panel de Login, pero también recibimos el mismo mensaje de error.
Procederemos a revisar la página web de http://10.10.10.179/#/gallery y verificamos que al parecer no hay al parecer ningún tipo de información, podríamos también intentar descargarnos las imágenes de esta galería en busca de información sensible en los metadatos, pero después de revisarlos tampoco van por aquí los tiros...
Al revisar el sitio web de http://10.10.10.179/#/app revisamos que al parecer tiene un buscador el cual a medida del input que le introduzcas, el resultado que te muestra son correos electrónicos que posiblemente quedándonos con el nombre del usuario, sean usuarios válidos del dominio.
Enviaremos la solicitud al BurpSuite para analizar como funciona la solicitud que se realiza y la respuesta que se recibe. Verificamos que la respuesta que nos muestra se encuentra en formato JSON.
Por lo tanto, tenemos una vía potencial para enumerar usuarios que parecen formar parte del dominio.
Enumerating users with Python script
Con la ayuda de ChatGPT hemos creado el siguiente script en Python que realizará solicitudes con un payload de la (A-Z) en busca de enumerar correos electrónicos que nos muestre la página web en la respuesta.
Le daremos permisos de ejecución al script creado y procederemos a ejecutarlo, verificamos que ha logrado encontrar los siguientes correos electrónicos en la página web. Estos correos electrónicos deberemos de guardarlo en un archivo por ejemplousers.txt.
Procederemos a trabajar con el archivo users.txt para solamente quedarnos con la parte del nombre de usuario que es lo que realmente nos interesa.
Dado que el DC dispone del puerto 88 (Kerberos) expuesto, podemos validar a través de la herramienta de kerbrute el listado de usuarios que disponemos actualmente para verificar cuáles de ellos son válidos a nivel de dominio.
En el resultado obtenido, verificamos que de los 17 usuarios que disponíamos solamente 14 usuarios son válidos a nivel de usuarios del dominio.
SQL Injection
En la solicitud enviada en el BurpSuite, probamos de añadirle una ' a la query para verificar si es vulnerable a SQL Injection. Verificamos que en la respuesta por parte del servidor recibimos un mensaje de 403 - Forbidden: Access is denied.
Lo que podemos pensar es que detrás del servidor web se encuentra un WAF (Web Application Firewall) que posiblemente nos bloquee estos intentos de inyección SQL.
Bypassing WAFs with JSON Unicode Escape Sequences
Realizando una investigación por Internet, nos encontramos con el siguiente blog que nos explica como intentar realizar un Bypass a las SQLI sobre los resultados JSON a través de realizar un encode de la inyección en formato Unicode Escape.
En este caso, utilizaremos Cyberchef de manera local para lograr mayor privacidad y no utilizar la versión web. Estableceremos que utilice el Escape Unicode Characters y le asignaré que realice el encode sobre '. Verificamos que el resultado obtenido del encode es --> \u0027.
Al enviar la solicitud con la ' encodeada, verificamos que no nos muestra un mensaje de Access Denied, en este caso simplemente desaparece el resultado de la respuesta por parte del servidor, lo cual podríamos llegar a intentar realizar la explotación del SQLI a través de encodear las inyecciones SQL en formato Escape Unicode Characters.
El primer paso a realizar en una inyeccción SQLI es determinar el número total de columnas que dispone la BBDD para posteriormente inyectar correctamente nuestros payloads.
Deberemos a partir de ahora, encodear toda nuestra inyección SQL en el formato anteriormente indicado para lograr realizar el Bypass del supuesto WAF que nos bloqueaba las inyecciones.
En este caso al intentar probar nuestra inyección para determinar si la BBDD dispone de 4 columnas, verificamos que el resultado que nos muestra es null, lo cual podemos verificar que el número de columnas no es correcto.
En intentar realizar la siguiente inyección SQL, verificamos que la BBDD dispone de 5 columnas en total y en la respuesta por parte del servidor nos muestra los números del 2 al 5, por lo tanto, podríamos llegar a inyectar nuestros payloads de SQLI en cualquiera de los campos mencionados.
Una de las primeras inyecciones a realizar, será lograr a determinar la versión exacta de la BBDD y el nombre de la base de datos que se está utilizando actualmente.
Por el resultado obtenido, verificamos que nos enfrentamos ante un Microsoft SQL Server (MSSQL) 2017 y la base de datos que está actualmente en uso se llamada Hub_DB.
A través de la siguiente inyección SQL, verificaremos el nombre de las bases de datos existentes en el servidor SQL. Verificamos que de las 5 BBDDs que hemos encontrado las cuatro primeras se tratan de BBDDs que vienen por defecto en MSSQL, en cambio, la BBDD nombrada Hub_DB no es una base de datos común, deberíamos investigar sobre esta misma.
Revisaremos los nombres de las tablas de la base de datos Hub_DB, en este caso verificamos que nos muestra dos tablas. De las dos tablas mencionadas, la que nos llama más la atención es la mencionada Logins.
Procederemos a investigar más sobre tabla Logins y verificaremos el nombre de las columnas que dispone esta table. En el resultado obtenido nos llama la atención las columnas existentes, parecen almacenar usuarios y contraseñas.
Al revisar las columnas username y password, verificamos que en la respuesta recibida por parte del servidor nos muestran usuarios y lo que parece ser contraseñas hasheadas que posteriormente podríamos intentar crackear.
Almacenaremos todo el resultado JSON obtenido para guardarlo en un archivo TXT. Trabajaremos con el archivo TXT para quedarnos con los nombres de usuarios y contraseñas y almacenarlos en dos archivos correspondientes.
Al revisar los hashes obtenidos, pensamos en primera instancia dada a la longitud del hash, parecía un tipo de hash SHA-384. Cuando ejecutamos hashcat con -m 10800 para SHA-384 con rockyou.txt, no se llegó a crackear nada.
Hay otros dos formatos en la página de hashes de ejemplo de Hashcat: SHA3-384 (-m 17500) y Keccak-384 (-m 17900). Cuando ejecutamos este último, obtuvimos los siguientes resultados:
Una vez obtenida esas 3 credenciales en texto plano, procederemos a realizar unPassword Spraying para validar si estas credenciales son válidas para el listado de usuarios del dominio que disponemos. Verificamos que en este caso, no obtenemos ningunas credenciales válidas.
Active Directory Users enumeration of MSSQL Injection (mssqli-duet)
Buscando más información sobre maneras de explotar un MSSQL, nos encontramos con el siguiente blog que nos indica como podemos intentar explotar este servicio para enumerar usuarios del Active Directory (AD) a través de inyecciones SQL para enumerar usuarios a través del Relative ID (RID).
El primer paso a realizar para revisar si podemos explotar esta vulnerabilidad es buscar el nombre del domain (domain name). En el caso de que no conozcamos el nombre de dominio, a través de la siguiente inyección SQL podemos identificar el nombre del dominio. Tenemos que previamente haber determinado la cantidad de columnas, tipo de columnas y saber que es inyectable a SQLi.
Verificamos que al enviar la solicitud, nos proporciona que el domain name es MEGACORP.
El siguiente paso a realizar es averiguar el Security ID (SID) del dominio. Así que una vez obtenido el nombre del dominio, el siguiente paso será inyectar la siguiente consulta utilizando una cuenta o un grupo integrado conocidos (en este ejemplo se utiliza la cuenta del usuario Administrator) para obtener el valir del SID.
En este caso el formato que nos devuelve en la respuesta, es el SID en formato hexadecimal que posteriormente podremos descodificar para obtener el valor en texto plano.
Hemos creado el siguiente script en Python que lo que realiza es convertir el SID que se encuentra en hexadecimal en el texto original.
Al ejecutar el script y pasarle el SID en formato hexadecimal, nos devolverá el valor original del SID.
Siguiendo el contenido del blog sobre la enumeración de usuarios a través de ataques de RID Cycling Attack a través de inyecciones en MSSQL, nos proporciona la siguiente herramienta para explotar y enumerar a los usuarios a través del RID.
Deberemos de almacenar en un archivo la solicitud POST que se envía desde BurpSuite que la necesitaremos para utilizar la herramienta.
Procederemos a realizar la explotación con la herramienta de mssqli-duet.py, en ella deberemos de especificar el parámetro vulnerable, en nuestro caso name, estableceremos que la inyección sea a' la cual la codificaremos en unicode.
Utilizaremos el archivo request.txt que es el que contiene la solicitud POST que hemos guardado, especificaremos en este caso que haga el RID Cycling Attack del 1000 al 1200 y se realice las solicitudes cada 3 segundos para evitar ser detectados.
En el resultado obtenido verificamos que hemos logrado obtener a 4 usuarios más que forman parte del dominio.
RID Enumeration on MSSQL Injection with Python script
También hemos creado el siguiente script en Python que cumple el mismo funcionamiento.
Al proceder a ejecutar el script creado, revisaremos que nos muestra nombres de usuarios y lo que parecen ser grupos de seguridad.
Initial Access
Password Spraying
Guardaremos estos nuevos usuarios en el archivo que disponíamos users.txt y procederemos a intentar validar nuevamente a través de Password Spraying. Verificamos que hemos logrado obtener credenciales válidas para el usuario tushikikatomo@megacorp.local.
LDAP Enumeration (ldapdomaindump)
Al obtener credenciales válidas de un usuario del dominio, procederemos a realizar un dump del LDAP para obtener más información relevante.
Al revisar los archivos HTML generados por la herramienta de ldapdomaindump, verificamos todos los nombres de usuario del dominio existentes.
Por otro lado, revisando el grupo Remote Management Users, verificamos que el usuario que disponemos actualmente forma parte de dicho grupo, por lo tanto, si el servicio WinRM o RDP se encuentran habilitados podríamos conectarnos al equipo.
Abusing WinRM - EvilWinRM
Procederemos a autenticarnos al WinRM mediante la herramienta de evil-winrm y verificamos el correcto acceso y la flag de user.txt.
Lateral Movement to cyork user
Revisando los directorios donde está montado el IIS (Internet Information Services) verificamos que no disponemos de acceso al directorio wwwroot.
CEF Debugging Background (CVE-2019-1414)
Revisando las aplicaciones que se encuentran instaladas, verificamos que en la máquina se encuentra instalado la aplicación de Microsoft Visual Studio Code.
Revisando la versión del Microsoft VS Code que se encuentra instalada en el equipo, verificamos que se trata de una versión vulnerable al Remote Code Execution (CVE-2019-1414).
Revisando los procesos que se encuentran en ejecución, verificamos que hay procesos sobre la aplicación en funcionamiento, por lo que podríamos llegar a pensar que hay alguien ejecutando estos procesos.
Esta es la descripción del CVE que hemos encontrado, se aprovecha del debug listener para lograr ejecutar comandos y escalar privilegios.
Por lo tanto, procederemos a descargarnos el binario de cefdebug.exe del siguiente repositorio de GitHub.
Una vez tengamos el binario en nuestro equipo atacante, procederemos a levantar un servidor web con Python para compartir este archivo al equipo víctima.
Desde el equipo víctima (Windows), procederemos a descargarnos el binario de cefdebug.exe y lo depositaremos en la siguiente ruta C:\Windows\System32\spool\drivers\color para que el AppLocker no nos impida ejecutarlo.
Por otro lado, lo que probaremos primero de todo es revisar si desde el equipo víctima nos podemos establecer una Reverse Shell con los scripts de Nishang. En este caso, el script que utilizaremos es el de Invoke-PowerShellTcp.ps1.
En una terminal de nuestro equipo atacante, nos pondremos en escucha para recibir la Reverse Shell.
Renombraremos el archivo Invoke-PowerShellTcp.ps1 a rev.ps1 para que nos sea más cómodo trabajar con este archivo y que pase más desapercibido por el AV (Antivirus).
Deberemos de editar el script y añadir al final de este mismo, la línea que nos permite realizar la Reverse Shell, la adaptaremos con nuestra dirección IP de atacante y el puerto por donde nos encontramos en escucha con nc.
Volveremos nuevamente a levantar un servidor web con Python para compartir este archivo con la máquina víctima.
Desde la máquina comprometida, procederemos a ejecutar en memoria la Reverse Shell que estamos compartiendo desde nuestro servidor web. Verificamos que el script ha sido detectado por el AV (Antivirus) y nos lo ha bloqueado.
Para intentar evitar que nos detecte el AV el script de la Reverse Shell, procederemos a modificar el archivo que disponemos rev.ps1para eliminarle las líneas donde hay comentarios y a modificar el nombre de la función para que no sea detectado. Deberemos de cambiar el nombre de la función de la primera y última sentencia por una nueva que pase desapercibida.
Una vez modificado el script rev.ps1, procederemos a ejecutar en memoria nuevamente el Script y en este caso verificamos que hemos logrado obtener la Reverse Shell correctamente.
Por otro lado, para que sea menos detectable la ejecución del IEX para obtener la Reverse Shell, lo que realizaremos es codificar en Base64 de Windows el comando utilizado.
Desde el equipo víctima, procederemos a ejecutar en una PowerShell el comando codificado en Base64.
Verificaremos nuevamente que nos funciona correctamente la ejecución del IEX codificado en Base64.
Una vez comprobado que podemos establecernos una Reverse Shell a través de un comando codificado en Base64, el siguiente paso será intentar realizar la explotación del CVE encontrado.
El primer paso será ejecutar el cef.exe (cefdebug) para realizar un escaneo de la máquina y verificar los servidores que se encuentran abiertos que parecen ser CEF debuggers.
Con el servidor obtenido, procederemos a realizar una ejecución del comando whoami para almacenar el resultado de la ejecución del comando realizado en un archivo TXT y visualizar si hemos logrado ejecutar comandos arbitrarios.
Al verificar el TXT que se nos ha generado, verificamos que el resultado del comando utilizado nos muestra que quien ejecuta el comando es el usuario cyork@megacorp.local.
Sabiendo que quien ejecuta los comandos es otro usuario, la idea será lograr ejecutar una Reverse Shell para obtener acceso como el usuario recién mencionado. Utilizaremos el servidor que hemos encontrado y al ejecutar en una PowerShell el comando IEX anteriormente codificado en Base64 para que a la hora de ejecutar el comando sea descodificado y así lograr obtener la Reverse Shell.
Previamente de la ejecución del comando, deberemos de ponernos en escucha con nc en nuestra Kali.
Verificamos que hemos logrado obtener acceso correctamente como el usuario cyork@megacorp.local.
Lateral Movement to sbauer user
MultimasterAPI.dll
Revisando los privilegios, permisos que disponemos con el usuario cyork, verificamos que disponemos acceso del directorio C:\inetpub\wwwroot\bin en la cual después de una gran revisión verificamos que al parecer hay un DLL nombrado MultimasterAPI.dll.
Este DLL se trata de una API (Application Programming Interface) personalizada de la página web del equipo. Como en máquinas de HTB anteriores, los archivos DLL suelen tener información sensible.
Para compartirnos este archivo de la máquina víctima a nuestra máquina local, desde esta última procederemos a levantar un servidor SMB con smbserver.py.
Al tener nuestro servidor SMB montado, procederemos a realizar una copia al servidor SMB que disponemos.
Verificamos en nuestro equipo local que disponemos del archivo DLL correctamente transferido.
Debugging with dnSpy
Procederemos a depurar el archivo DLL a través de la herramienta de dnSpy que podemos encontrar en el siguiente repositorio de GitHub. En este caso, hemos transferido el archivo en una VM de Windows para realizar el análisis.
Al realizar una enumeración del DLL, revisamos que aparece en texto plano las siguientes credenciales D3veL0pM3nT!.
Password Spraying
Al realizar un Password Spraying sobre la contraseña encontrada y el listado de usuarios del dominio que disponemos, verificamos que esta
BloodHound Enumeration
A continuación, procederemos a realizar 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.
Revisando en BloodHound, verificamos que solamente el usuario Administrator es un Domain Admin.
Revisando si existe algún usuario que sea susceptible a Kerberoasting Attack, es decir, aquellos usuarios que tengan un SPN (ServicePrincipalName) para solicitar posteriormente un TGS (Ticket Granting Service).
En este caso, verificamos que no hay ningún usuario que sea Kerberostable.
Al verificar si algún usuario dispone de la flag (DONT_REQ_PREAUTH) de Kerberos para realizar un AS-REP Roast Attack y así lograr obtener un TGT (Ticket Granting Ticket), verificamos que ningún usuario tiene configurado esa opción.
Enumerando a través de BloodHound, verificamos que el usuario que disponemos actualmente sbauer@megacorp.local dispone de privilegios GenericWrite sobre el usuario jorden@megacorp.local.
Este permiso lo que nos permite es la habilidad de escribir en atributos no protegidos sobre el objeto objetivo. Por ejemplo, podemos asignarle la flag de (DONT_REQ_PREAUTH) para que el usuario objetivo sea susceptible al AS-REP Roast Attack o asignarle un SPN (ServicePrincipalName) fícticio para que el usuario sea Kerberostable y obtener el TGS (Ticket Granting Service) para obtener el hash y posteriormente crackearlo.
Lateral Movement to jorden user
Abusing GenericWrite privileges to assign an SPN for performing a Kerberoasting attack
En esta primera sección, lo que realizaremos es asignarle un SPN (ServicePrincipalName) ficticio al usuario objetivo jorden@megacorp.local para obtener el TGS (Ticket Granting Service), es decir, un hash que posteriormente podremos intentar crackear de manera offline y obtener la contraseña en texto plano.
Antes de la explotación
Tal como habíamos verificado en la enumeración de BloodHound, no había ningún usuario que sea Kerberostable. Esto lo hemos podido comprobar nuevamente tal y como nos indica el resultado del ataque de Kerberoasting Attack realizado.
Después de la explotación
Para realizar la explotación y abusar del privilegio GenericWrite sobre el usuario y asignarle un SPN ficticio, lo podremos hacer a través de las herramientas bloodyAD y impacket-GetUserSPNs.
A través del primer comando, lo que realizamos es asignarle un SPN (ServicePrincipalName) ficticio al usuario. Al volver a lanzar el ataque de Kerberoasting Attack, verificamos que ahora si nos aparece que haya un usuario Kerberoastable y nos devuelve el hash TGS (Ticket Granting Service).
Otra de las herramientas para realizar este tipo de ataques de asignar un SPN ficticio a un usuario el cual dispongamos de privilegios, es a través de la herramienta de targetedKerberoast.
Esta herramienta automatiza el ataque de Kerberoasting Attack, solamente nos hace falta disponer de un usuario que tenga privilegios sobre otro para asignarle el SPN y la propia herramienta buscará a los usuarios objetivos, les asignará un SPN ficticio y nos imprimirá los hashes obtenidos.
Para finalizar, la propia herramienta eliminará el SPN temporal asignado a los usuarios objetivos para evitar dejar rastro.
Abusing GenericWrite privileges to set DONT_REQ_PREAUTH for AS-REP Roasting
En la siguiente sección, lo que realizaremos es asignar al usuario objetivo jorden@megacorp.local la flag (DONT_REQ_PREAUTH) de Kerberos para que sea susceptible a AS-REP Roast Attack para obtener un TGT (Ticket Granting Ticket). Es decir, si logramos asignarle esa opción al usuario, recibiremos un hash que posteriormente podremos intentar crackear de manera offline y obtener la contraseña en texto plano.
Antes de la explotación
Tal como se nos indicaba en BloodHound, ninguno de los usuarios del dominio tenian asignado esa flag, eso lo hemos verificado nuevamente al realizar el ataque de AS-REP Roast Attack.
A través de la herramienta de bloodyAD procederemos a asignarle la flag de (DONT_REQ_PREAUTH) al usuario jorden@megacorp.local. Al asignarle esa flag y realizar nuevamente el ataque, verificamos que recibimos el hash TGT (Ticket Granting Ticket).
Procederemos a crackear con hashcat cualquiera de los dos hashes obtenidos TGT/TGS. Verifiamos que hemos logrado obtener la contraseña en texto plano.
Verificaremos nuevamente que las credenciales obtenidas sean válidas y que nos podamos conectar al equipo mediante evil-winrm ya que el usuario forma parte del grupo Remote Management Users.
Privilege Escalation
Revisando los permiso/grupos del usuario que disponemos actualmente jorden@megacorp.local revisamos que el usuario foma parte del grupo SERVER OPERATORS@megacorp.local.
Windows PrivEsc: Server Operator Group
El grupo Server Operators es un grupo de seguridad integrado en los entornos de Windows Server. A los miembros de este grupo se les otorgan privilegios administrativos específicos que les permiten realizar tareas relacionadas con el servidor sin tener derechos administrativos completos. Este grupo está diseñado principalmente para la administración delegada del servidor. Privilegios clave de los operadores de servidor
Los miembros del grupo Operadores de servidor tienen los siguientes privilegios:
Iniciar y detener servicios:
Pueden iniciar, detener y pausar servicios en el servidor, lo que es crucial para el mantenimiento y la resolución de problemas del servidor.
Administrar recursos compartidos:
Los operadores de servidor pueden crear, modificar y eliminar carpetas compartidas y administrar recursos compartidos de impresoras, lo que les permite administrar recursos compartidos de manera eficaz.
Operaciones de copia de seguridad y restauración:
Los miembros pueden realizar copias de seguridad de archivos y restaurar archivos a partir de copias de seguridad, lo que facilita la administración de los procesos de recuperación de datos.
Iniciar sesión localmente:
Los miembros tienen la capacidad de iniciar sesión localmente en el servidor, lo que les permite administrar directamente el servidor a través de su consola.
Administrar usuarios y grupos locales:
Pueden agregar o eliminar usuarios de grupos locales y administrar cuentas locales, lo que es importante para las tareas de administración de usuarios.
Hemos conseguido más información de lo que trata esta escalada de privilegios desde el siguiente blog donde se detalla la explotación.
Desde el equipo procederemos a revisar los servicios que se encuentran en ejecución.
Después de revisar los servicios que se encuentran en ejecución, el siguiente paso será subir al equipo víctima el binario nc.exe para posteriormente aprovechar de que formamos parte de este grupo, para modificar el binPath del servicio e indicarle que la ruta del servicio es la ejecución de una Reverse Shell utilizando el binario subido de nc.exe.
Verificamos que logramos modificar correctamente el binPath del servicio VMTools, también podemos utilizar el servicio browser.
En una terminal nos pondremos en escucha por el puerto especificado en el punto anterior.
Volveremos a la terminal del equipo víctima y procederemos a parar y volver a iniciar el servicio el cual hemos modificado el binPath para que ejecute la Reverse Shell.
Verificamos que al volver a iniciar el servicio, hemos logrado obtener conexión a través de la Reverse Shell, en este caso, el usuario que arranca el servicio es el usuario NT AUTHORITY\SYSTEM, lo cual tenemos control total sobre el equipo.
ZeroLogon Exploitation to performing DCSync Attack
Durante el análisis realizado, descubrimos que el Domain Controller es vulnerable al exploit ZeroLogon(CVE-2020-1472). Esta vulnerabilidad permite comprometer la seguridad del dominio y elevar privilegios al manipular las credenciales y las conexiones SMB.
Nos descargaremos el siguiente repositorio en nuestro equipo atacante para explotar la vulnerabilidad.
En el PoC del exploit de ZeroLogon, verificamos el uso de la herramienta.
Al realizar la explotación del CVE, lo que realiza esta vulnerabiliadd es dejar las credenciales del Domain Controller (DC) vacías.
Por lo tanto, al proceder a realizar un DCSync Attack con la cuenta del DC sin indicarle credenciales, obtenemos los hashes NTLM de todo el dominio.
Esto compromete gravemente la seguridad, debido que disponemos del acceso a cualquier usuario haciendo ataques como Pass-The-Hash.
Al realizar un dump del NTDS.dit, verificaremos que podemos realizar Pass-The-Hash con el usuario Administrator y conectarnos a través de la herramienta wmiexec.py.
Última actualización
¿Te fue útil?