Problema

Los entornos de Active Directory (AD) son objetivo frecuente de ataques de movimiento lateral y recolección de credenciales. Los equipos de detección suelen depender de firmas estáticas (Event IDs) y, cuando el atacante usa técnicas conocidas, la señal llega tarde o se pierde entre ruido. La necesidad es disponer de “trampas” dentro del propio dominio que generen eventos claros y de alto valor sin requerir mantenimiento constante. En la práctica, muchos laboratorios de detección carecen de honeypots que cubran los vectores más explotados: Kerberoasting, AS‑REP Roasting, acceso a SYSVOL y extracción de LSASS. Sin esas trampas, los analistas pueden pasar horas revisando logs sin encontrar la pista que indique que un atacante está probando credenciales falsas.

Causa

  1. Ausencia de objetos falsos con atributos atractivos – Los atacantes buscan cuentas de servicio con SPN o cuentas sin pre‑auth. Si el dominio no contiene dichos objetos, el atacante no genera los eventos esperados.
  2. Falta de auditoría granular – Los SACLs no están aplicados a recursos críticos como SYSVOL, por lo que el acceso legítimo y el malicioso se registran con la misma severidad, diluyendo la señal.
  3. No hay indicadores de “uso de credenciales ficticias” – Cuando se crean credenciales falsas, no se implementa una forma de detectar su uso posterior (por ejemplo, logon con una cuenta que solo existe para la trampa).
  4. Integración limitada con el SIEM – Sin reglas personalizadas que correlacionen eventos específicos (ID 4769, 4768, 4663, 4624) con los objetos de trampa, la alerta nunca se dispara.

Estos factores se combinan para que la detección de movimiento lateral sea lenta o inexistente.

Solución

Diseñar un conjunto de honeypots reutilizable que cubra los vectores de ataque más comunes y que emita eventos de alta fidelidad listos para ser ingeridos por Wazuh (o cualquier SIEM). La solución se divide en cuatro pilares:

1. Cuentas de servicio “cebo” para Kerberoasting

  • Crear una cuenta de servicio con un SPN que parezca valiosa (p. ej. svc-mssql-admin).
  • Asignar una contraseña compleja para que el hash sea atractivo.
  • Registrar el SPN en AD y habilitar la cuenta.

2. Cuentas sin pre‑auth para AS‑REP Roasting

  • Crear una cuenta de automatización (p. ej. backup-automation) y desactivar Do not require Kerberos pre‑authentication.
  • No asignar privilegios reales; la cuenta solo sirve para generar el ticket AS‑REP.

3. Carpeta SYSVOL “trampa”

  • Añadir un directorio ficticio dentro de \\domain.com\SYSVOL\domain\Policies\{GUID} con un archivo Groups.xml que contenga credenciales de ejemplo.
  • Aplicar un SACL que audite Read y ReadData y genere Event ID 4663.
  • Asegurarse de que el permiso de lectura está restringido a “Authenticated Users” para que cualquier acceso legítimo sea raro y, por tanto, señalable.

4. Inyección de credenciales falsas en memoria

  • Utilizar un script de inicio de GPO que escribe una cadena con formato de credencial (Domain-Admin-Bkp) en la memoria del proceso explorer.exe o powershell.exe.
  • La cadena no corresponde a una cuenta real; su único propósito es que, si un atacante la extrae con Mimikatz, el intento de logon fallará y generará Event ID 4625 con Logon Type 3.

Implementación paso a paso (PowerShell)

# 1. Crear cuenta de servicio para Kerberoasting
New-ADUser -Name "svc-mssql-admin" -SamAccountName "svc-mssql-admin" -AccountPassword (ConvertTo-SecureString "P@ssw0rd!Complex123" -AsPlainText -Force) -Enabled $true
Set-ADUser -Identity "svc-mssql-admin" -ServicePrincipalNames "MSSQLSvc/sqlserver.domain.com:1433"

# 2. Crear cuenta sin pre‑auth para AS‑REP Roasting
New-ADUser -Name "backup-automation" -SamAccountName "backup-automation" -AccountPassword (ConvertTo-SecureString "Another$tr0ngPwd!" -AsPlainText -Force) -Enabled $true
Set-ADUser -Identity "backup-automation" -DoesNotRequirePreAuth $true

# 3. Crear carpeta SYSVOL trampa y aplicar SACL
$sysvolPath = "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies\{FAKE-GPO-GUID}"
New-Item -Path $sysvolPath -ItemType Directory -Force
Set-Content -Path "$sysvolPath\Groups.xml" -Value "<Groups><Group name='FakeGroup'><Member>user1</Member></Group></Groups>"
# Aplicar SACL (requiere privilegios de auditoría)
$acl = Get-Acl $sysvolPath
$rule = New-Object System.Security.AccessControl.FileSystemAuditRule("Authenticated Users","ReadData","Success")
$acl.AddAuditRule($rule)
Set-Acl -Path $sysvolPath -AclObject $acl

# 4. Inyección de credencial falsa en memoria mediante GPO startup script
$script = @"
Add-Type -AssemblyName System.Runtime.InteropServices
[DllImport("kernel32.dll")] public static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);
[DllImport("kernel32.dll")] public static extern bool VirtualFree(IntPtr lpAddress, uint dwSize, uint dwFreeType);
"@
# Guardar como \\domain.com\SYSVOL\domain\Scripts\InjectFakeCred.ps1 y enlazar al GPO

5. Correlación en Wazuh

  • Crear reglas que disparen cuando se detecte:
    • Event ID 4769 con svc-mssql-admin como TargetUserName.
    • Event ID 4768 con backup-automation y PreAuthType=0.
    • Event ID 4663 en la ruta del GPO falso.
    • Event ID 4625 con Logon Type 3 y Account Name = Domain-Admin-Bkp.

Estas reglas deben asignar una prioridad alta y generar alertas inmediatas.

Cuándo aplicar esta solución

  • Entornos de detección de amenazas donde el objetivo es identificar movimiento lateral antes de que el atacante alcance recursos críticos.
  • Laboratorios de red team/blue team que requieren señales reproducibles y de bajo mantenimiento.
  • Dominios con auditoría ya habilitada (SACL, log de Kerberos) pero sin objetos de trampa.

No es necesario (y puede ser contraproducente) en dominios extremadamente pequeños donde la sobrecarga de cuentas falsas genera confusión operativa. Tampoco se recomienda en entornos donde la política de contraseñas impide crear cuentas con contraseñas complejas sin uso real, ya que rompería la normativa interna.

Verificación

  1. Comprobar existencia de cuentas 
    Get-ADUser -Filter {SamAccountName -eq "svc-mssql-admin"} | ft SamAccountName,Enabled,ServicePrincipalNames
Get-ADUser -Filter {SamAccountName -eq "backup-automation"} | ft SamAccountName,Enabled,DoesNotRequirePreAuth
  2. Validar SACL en SYSVOL 
    Get-Acl -Path "\\domain.com\SYSVOL\domain\Policies\{FAKE-GPO-GUID}" | Format-List
  3. Generar tráfico de prueba
    • Desde una máquina cliente, ejecutar klist -k -t -K -p -c para solicitar tickets Kerberos contra svc-mssql-admin.
    • Ejecutar kinit [email protected] para forzar AS‑REP Roasting.
    • Navegar a la ruta del GPO falso y observar en el visor de eventos el ID 4663.
  4. Revisar alertas en Wazuh
    • Verificar que los eventos anteriores aparecen en el dashboard con la prioridad configurada.

Si todas las pruebas generan los eventos esperados y aparecen en Wazuh, la trampa está operativa.

Notas adicionales

  • Rotación de credenciales falsas: Cambiar la contraseña de las cuentas de cebo cada 30‑60 días evita que un atacante reutilice hashes antiguos.
  • Impacto en replicación: Las cuentas y objetos creados se replican como cualquier otro objeto AD; monitorizar la replicación para asegurarse de que no se generan retrasos.
  • Evitar conflictos de nombres: Use prefijos claros (svc-, backup-) y GUIDs únicos para los GPO falsos; de lo contrario, podrían colisionar con objetos reales.
  • Documentación interna: Mantenga una lista de todas las trampas creadas y sus propósitos; así el equipo de operaciones no las elimina accidentalmente durante limpiezas rutinarias.
  • Ajuste de umbrales: En entornos con mucho tráfico legítimo, afine la regla de correlación para que solo se dispare cuando el mismo Event ID se repita en un corto intervalo (p. ej. 2 eventos en 5 min).

Con estos pasos, cualquier laboratorio o entorno de producción puede incorporar honeypots de AD que generen señales claras y accionables, reduciendo el tiempo de detección de técnicas de movimiento lateral y mejorando la postura de seguridad global.