Relevant

Dificultad: medium - OS: Windows

¯\_( ͡° ͜ʖ ͡°)_/¯ Machine info

El análisis de este entorno Windows se centra inicialmente en la enumeración exhaustiva de la superficie de ataque, identificando servicios expuestos y configuraciones permisivas en protocolos de red estándar. El vector de entrada principal se basa en la revisión del protocolo Server Message Block (SMB) y la detección de puertos no estándar que alojan servicios web (IIS). La investigación revela una severa falla de seguridad por fuga de información y control de acceso discrecional inadecuado, donde recursos compartidos accesibles sin autenticación exponen datos sensibles codificados y permiten la escritura de archivos en directorios que son, simultáneamente, accesibles vía web.

La fase de explotación aprovecha la correlación entre el sistema de archivos compartido y el servicio web para lograr una Ejecución Remota de Código (RCE). Al inyectar payloads en formato ASPX dentro del recurso compartido SMB con permisos de escritura, se habilita la ejecución de scripts maliciosos a través del navegador web o herramientas de solicitud HTTP. Este mecanismo demuestra cómo la falta de segmentación adecuada entre los servicios de almacenamiento y los entornos de ejecución web permite a un atacante establecer una conexión inversa (reverse shell), comprometiendo el servidor con los privilegios de un usuario de servicio web estándar.

Finalmente, la escalada vertical de privilegios hacia el nivel de administrador del sistema (NT AUTHORITY\SYSTEM) se fundamenta en el abuso de privilegios de tokens de Windows asignados a la cuenta comprometida. Específicamente, se detecta la habilitación del privilegio SeImpersonatePrivilege, el cual permite al usuario suplantar tokens de seguridad de otros clientes tras la autenticación. La explotación de esta mala configuración, combinada con vulnerabilidades en el servicio de impresión de Windows, permite secuestrar un token privilegiado y ejecutar comandos con control total sobre el sistema operativo, completando así la cadena de ataque.

Enumeración de puertos/servicios

┌──(root㉿kali)-[/home/kali/Documents/THM/RELEVANT]
└─# nmap -p- -sCV -T4 --open -n -v 10.10.18.112
📌 Parámetros
  • -p- Obliga a Nmap a revisar todo el rango de puertos (1-65535)

  • sCV:

    • -sC → Ejecuta scripts de detección predeterminados → Usa los scripts de nmap ubicados en /usr/share/nmap/scripts/, los cuales buscan información adicional en los puertos abiertos.

    • -sV → Detección de versiones → Intenta identificar el software y su versión en los puertos abiertos.

  • -nNo resuelve nombres de dominio (reduce el tiempo del escaneo).

  • --openMuestra solo puertos abiertos → Filtra la salida para no mostrar puertos cerrados o filtrados.

  • -T4Ajusta la velocidad del escaneo → T4 es un nivel "agresivo" que acelera el escaneo, útil en redes rápidas.

  • -vModo verbose → Muestra más detalles sobre el progreso del escaneo.

Resultado:

En síntesis:

Información clave que nos detectó Nmap

  • Acceso anónimo en SMB: El script de enumeración smb-security-mode reporta account_used: guest. Esto nos está indicando que el servidor permite sesiones nulas o acceso de invitado, lo cual es el vector principal para enumerar recursos compartidos (shares) sin credenciales.

  • Servidor Web IIS 10.0: La presencia del puerto 80 abierto indica una superficie de ataque web. Aquí podríamos realizar fuzzing de directorios para encontrar rutas ocultas o paneles de administración.

  • Servicio RDP disponible: El puerto 3389 está abierto. Aunque requerimos credenciales, nos confirma que si obtenemos un usuario y contraseña (o un hash NTLM válido), podríamos acceder a una interfaz gráfica remota.

  • Nombre del equipo y dominio: Los scripts de RDP y SMB revelan que el nombre de la máquina es RELEVANT y el dominio/grupo de trabajo es WORKGROUP. Esta información es útil para configurar herramientas de ataque como crackmapexec o smbclient.

  • Servicio http en el puerto 49663: en la enumeración aparece una segunda instancia de Microsoft IIS httpd 10.0 ejecutándose en un puerto alto. A diferencia del puerto 80 (que suele ser la página por defecto). Aca tambien podemos realizar un fuzzing de directorios en busca de rutas ocultas.

Enumeración de recursos smb con usuario anónimo

Esta vez usaremos la tool nxc para ver si tenemos permisos de escritura o lectura en la unidad compartida.

📌 Desglose del comando
  • nxc smb → Le dice a nxc que use el módulo SMB (interactuar con compartidos de Windows).

  • 10.66.188.223 → Es la IP de la máquina objetivo (en este caso, la del CTF Relevant).

  • -u 'a' → Especifica el nombre de usuario como 'a' (cualquier cosa, básicamente).

  • -p '' → Especifica una contraseña vacía (sin password).

  • --shares → Le dice que enumere los recursos compartidos (shares) disponibles en ese servidor SMB.

¿Por qué usar un usuario y password así?

  • Porque en SMB a veces se permite una conexión "nula" o "anónima" (sin usuario ni contraseña reales).

  • Poner un usuario inventado (a) y contraseña vacía intenta ver si el servidor permite listar shares sin autenticación o con autenticación muy débil.

¿Qué se puede hacer con nxc sobre SMB?

  • Listar recursos compartidos (--shares).

  • Listar archivos de un directorio (--list).

  • Descargar archivos (--download).

  • Subir archivos (--upload).

  • Eliminar archivos (--delete).

El escaneo con nxc nos reveló un punto crítico: el recurso compartido nt4wrksv tiene permisos de lectura y escritura (Read/Write) habilitados para usuarios no autenticados. Aprovechando esta mala configuración, nos conectamos mediante smbclient para enumerar el contenido y buscar datos sensibles pudieron haber dejado expuestos.

Dentro del recurso dimos con un archivo interesante que contenía credenciales. Al descargarlo e inspeccionarlo, vemos que las cadenas están ofuscadas en Base64 (el formato y el relleno == suelen caracterizar a este tipo de codificaciones). Para revertir la codificación y obtener las contraseñas en texto plano, utilizamos el siguiente comando en la terminal:

Directory Fuzzing

Con estas credenciales podríamos intentar autenticarnos por RDP al equipo objetivo, pero antes de probar eso voy a enumerar directorios con Gobuster en el puerto 49663 que corre el servicio http y ver si existe algún otro vector de acceso hacia ese equipo:

📌 Desglose del comando

-u http://10.67.176.15:49663 → Define la URL objetivo (Target URI). Es fundamental especificar el protocolo (http) y el puerto exacto (49663) donde descubrimos el servicio web alternativo, ya que por defecto buscaría en el puerto 80.

-w /usr/share/.../directory-list-2.3-medium.txt → Señala la ruta absoluta del diccionario (wordlist) que utilizará el programa. Gobuster probará cada palabra de esta lista contra la URL para ver si existe.

-t 50 → Configura el número de hilos (threads) de ejecución simultánea. Al subirlo a 50 (el defecto suele ser 10), realizas más peticiones por segundo, acelerando significativamente el escaneo.

-b 403,404 → Aplica una lista negra (blacklist) de códigos de estado HTTP. Instruye a la herramienta para que oculte y descarte cualquier resultado que devuelva "Prohibido" (403) o "No Encontrado" (404), dejando visible solo lo que es accesible (códigos 200, 301, etc.).

-x txt,aspx,asp,config → Indica las extensiones de archivo específicas a buscar. Por cada palabra del diccionario, Gobuster probará también las variantes con estas terminaciones. Esto es crucial en este CTF porque el servidor es Windows (IIS) y buscamos scripts ejecutables (.aspx, .asp) o archivos de configuración y texto (.config, .txt).

El escaneo arrojó un hallazgo crítico: la existencia del directorio /nt4wrksv accesible vía web (http://10.66.188.223:49663/nt4wrksv). Esto confirma una correlación directa entre el recurso compartido SMB (donde detectamos permisos de lectura/escritura) y el servidor IIS. Esta mala configuración es un vector de acceso más interesante, ya que podríamos probar una Ejecución Remota de Código (RCE) a través de la carga de algún payload y su posterior ejecución desde la web.

Explotación Inicial (RCE)

La estrategia será generar un payload aspx con msfvenom, subirlo mediante smbclient al recurso compartido, levantar un listener en nuestro equipo local y, finalmente, levantar la shell desde la URL http://10.66.188.223:49663/nt4wrksv/payload.aspx

📌 ¿Porque es válido subir un payload '.aspx'?

1. El Lenguaje Nativo del Servidor (Tecnología)

Así como los servidores Linux con Apache o Nginx suelen utilizar PHP (.php) como lenguaje de scripting del lado del servidor, los entornos Windows con IIS utilizan ASP.NET. La extensión .aspx indica que el archivo es una "página extendida de servidor activo". Cuando IIS detecta esta extensión, sabe que no debe mostrar el contenido del archivo como texto plano, sino que debe pasarlo al motor de .NET Framework para que procese y ejecute el código que hay dentro.

2. Permisos de Ejecución de Scripts (La Vulnerabilidad)

Para que esto funcione, el directorio en el servidor debe tener habilitados los permisos de Ejecución de Scripts. Si el administrador hubiera configurado ese directorio solo para contenido estático (imágenes, html), el archivo .aspx daría un error 403 o 404, o se mostraría como texto plano, y el ataque fallaría.

En esta etapa aprovechamos la funcionalidad de una Webshell como vector de lanzamiento (subiendo un archivo .aspx ejecutable vía web) para activar una Reverse Shell.

  1. Fase Webshell (Trigger): El archivo malicioso reside en el servidor web. Al realizar una petición HTTP (navegar al archivo), utilizamos el motor del servidor IIS para ejecutar nuestro código.

  2. Fase Reverse Shell (Payload): El código ejecutado no devuelve una página HTML, sino que inicia un flujo de conexión inverso hacia nuestra máquina atacante, evadiendo las reglas de firewall entrantes y otorgándonos una terminal interactiva.

Ya subimos la shell al servidor ahora levantamos el listener y activamos el payload desde la siguiente URL: http://10.66.188.223:49663/nt4wrksv/payload.aspx

Nota: el listener con Netcat crea un túnel de texto plano, pero no emula una terminal real (TTY). Por eso, cuando hacemos Ctrl+C, en lugar de cancelar el comando remoto, matamos el propio proceso Netcat y se pierde la conexión. Tampoco tenemos historial de comandos ni autocompletado (tabulador). Para solucionar estos problemas te recomiendo usar rlwrap (Readline Wrapper) que básicamente "envuelve" el listener y nos da una shell más interactiva y cómoda para avanzar más rápido.

  • Podes instalarlo con: sudo apt install rlwrap

  • Sintaxis: rlwrap nc -lvnp <Tu_Puerto>

Enumeración local

Una vez que logramos ingresar al equipo objetivo tenemos que iniciar con la etapa de enumeración local para buscar información que nos permita escalar privilegios. Esta etapa se puede realizar de forma manual o automatizada con herramientas como WinPeas o PowerUP.ps1. Para este caso realizaremos una enumeración manual con algunos de los comandos más básicos de recolección de información.

📌Análisis de Enumeración Local y Vectores de Escalada

Vector Principal de Escalada de Privilegios

El hallazgo más crítico sale de la auditoría de privilegios del usuario actual (iis apppool\defaultapppool), donde se confirma que la directiva SeImpersonatePrivilege se encuentra habilitada. En la arquitectura de seguridad de Windows, este permiso permite a la cuenta de servicio suplantar los tokens de seguridad de otros clientes que se autentiquen contra ella. Desde una perspectiva ofensiva, esto constituye una vulnerabilidad de severidad crítica, ya que habilita la explotación mediante técnicas de coacción de autenticación, permitiendo la suplantación de identidad de cuentas privilegiadas como NT AUTHORITY\SYSTEM.

Integridad del Sistema y Superficie de Ataque

La revisión de la configuración del host identifica al objetivo como un Windows Server 2016 Standard Evaluation (x64). Un aspecto determinante es la falta significativa de actualizaciones de seguridad, evidenciada por la presencia de únicamente tres Hotfixes instalados. Esta obsolescencia en el nivel de parches sugiere que el núcleo del sistema operativo (kernel) mantiene vulnerabilidades conocidas que podrían ser explotadas como un vector alternativo de compromiso en caso de fallar la explotación de privilegios, validando el uso de exploits públicos asociados a dicha versión del sistema.

Contexto de la Sesión y Usuarios Locales

La identidad de la sesión confirma que el acceso inicial se obtuvo a través del compromiso del servicio web (IIS), operando bajo una cuenta virtual de Application Pool. Adicionalmente, la enumeración de usuarios locales revela la existencia de la cuenta "Bob", lo cual es relevante para una posible fase de movimiento lateral. La inspección de los directorios personales de este usuario podría arrojar información sensible o credenciales adicionales, útiles para persistir en la red o acceder a otros recursos del dominio o grupo de trabajo.

De toda la información enumerada la que nos interesa es la última que está relacionada directamente con los tokens de privilegios de nuestro usuario. El permiso en cuestión es el SeImpersonatePrivilege, este token es crítico, ya que representa la llave directa para comprometer la cuenta NT AUTHORITY\SYSTEM.

¿Qué es SeImpersonatePrivilege?

En la arquitectura de seguridad de Windows, este privilegio es una característica legítima diseñada para permitir que un servicio actúe en nombre de otro usuario (impersonación). Su función principal es permitir que servicios de red accedan a recursos restringidos (como bases de datos o archivos) utilizando la identidad del cliente que realiza la petición, sin necesidad de conocer o almacenar sus credenciales. Es un mecanismo de flexibilidad esencial para el sistema operativo. Desde una perspectiva ofensiva, la presencia de SeImpersonatePrivilege (o su equivalente SeAssignPrimaryToken) en una cuenta de bajos privilegios es un elemento criticó. Nos permite coaccionar a un proceso privilegiado (generalmente SYSTEM) para que se autentique contra un recurso que controlamos. Al interceptar esta autenticación, podemos 'secuestrar' su token de seguridad y utilizarlo para generar un nuevo proceso con control total sobre el sistema. Para explotar esto, utilizaremos herramientas especializadas en la manipulación de tokens, como PrintSpoofer o PetitPotato.

Escalada de privilegios local

Para avanzar hacia la escalada de privilegios, necesitamos transferir nuestros exploits (PrintSpoofer y PetitPotato) al entorno comprometido. Para ello, aplicaremos una técnica conocida como LOLBAS (Living Off The Land Binaries and Scripts), que consiste en utilizar herramientas nativas del sistema operativo para fines ofensivos. Haremos uso del binario certutil.exe, una herramienta legítima de Windows destinada a la gestión de certificados, para que actúe como un gestor de descargas. El procedimiento será levantar un servidor HTTP temporal con Python en nuestro equipo atacante y utilizar certutil en la máquina víctima para recuperar los archivos. Esta metodología es eficaz en entornos reales para evadir controles de seguridad, ya que el tráfico es generado por un ejecutable firmado y confiable del propio sistema. Para descargar estas herramientas primero me voy a dirigir al directorio C:/Users/Public

  1. Levanto el servidor http desde el directorio donde están las tools

  1. Descargo los ejecutables con certutil:

Ahora que ya tengo los ejecutables de PetitPotato y PrintSpoofer puedo continuar con la escalada de privilegios:

  • Opción 1: PrintSpoofer

Opción 2: también podemos usar PetitPotato para ejecutar una reverse shell con los privilegios de System y mandarla a nuestro equipo:

Nota: para esta reverse shell use un payload hecho en powershell que subí con certutil al mismo directorio donde se encuentran las otras herramientas. El script en cuestión es el siguiente RCA.ps1

Me pongo en escucha y ya soy nt authority\system

Bonus: Técnicas de persistencia

Bonus: Enumeración con PowerUp.ps1