Problema

Los entornos de Active Directory (AD) a menudo presentan varios puntos débiles que, cuando se combinan, permiten a un atacante pasar de una conexión VPN sin credenciales a control total del dominio. La cadena típica incluye enumeración anónima, extracción de hashes, abuso de permisos delegados y escalada mediante certificados. Cuando cualquiera de esos es explotable, la defensa completa se vuelve imposible; la verdadera dificultad está en detectar y bloquear la secuencia de técnicas, no cada una de forma aislada.

Causa

  1. Preautenticación Kerberos desactivada – Los usuarios que no requieren Kerberos pre‑authentication facilitan el AS‑REP roasting y la obtención de hashes sin interacción previa.
  2. Permisos delegados excesivos – ACLs que conceden GenericAll, GenericWrite, WriteDACL o WriteOwner a cuentas de servicio o grupos de dominio permiten modificar objetos críticos (por ejemplo, el certificado del controlador de dominio).
  3. Servicios que aceptan autenticación NTLM – Cuando los servidores exponen protocolos como SMB, LDAP o HTTP sin forzar Kerberos, el atacante puede lanzar ataques de relay contra recursos internos.
  4. Configuración débil de AD CS – Plantillas de certificado mal protegidas y la ausencia de restricciones de inscripción permiten que un atacante solicite certificados de alta privilegia.
  5. Falta de monitoreo de tickets Kerberos – Solicitudes de tickets de servicio inusuales (por ejemplo, para krbtgt) pasan desapercibidas, lo que permite la extracción del hash de krbtgt y la creación de tickets forjados (Golden Ticket).
  6. Herramientas de descubrimiento sin control – BloodHound y similares pueden ser usados por defensores, pero si los permisos son demasiado permisivos, el mismo descubrimiento revela rutas de ataque críticas.

Solución

Una defensa eficaz se basa en capas que interrumpen la cadena en varios puntos. A continuación se describen medidas que un administrador puede aplicar sin necesidad de re‑architectar toda la infraestructura.

1. Habilitar Kerberos pre‑authentication

# Forzar pre‑authentication en todos los usuarios (excepto cuentas de servicio que lo requieran)
powershell -Command "Get-ADUser -Filter * -Properties DoesNotRequirePreAuth | Where-Object {$_.DoesNotRequirePreAuth -eq $true} | Set-ADUser -DoesNotRequirePreAuth $false"

Esta acción elimina la superficie para AS‑REP roasting. Las cuentas que realmente necesiten desactivar la pre‑auth deben ser revisadas y, de ser posible, migradas a métodos de autenticación más seguros.

2. Auditar y reducir permisos delegados

Utiliza PowerShell para identificar objetos con los privilegios críticos:

powershell -Command "
Import-Module ActiveDirectory
$dangerous = @('GenericAll','GenericWrite','WriteDACL','WriteOwner')
Get-ADObject -Filter * -Properties nTSecurityDescriptor |
  Where-Object {
    $_.nTSecurityDescriptor.Access |
    Where-Object { $dangerous -contains $_.ActiveDirectoryRights }
  } |
  Select-Object Name,DistinguishedName,ObjectClass
"

Una vez listados, revoca los accesos innecesarios mediante Set-ACL o mediante la consola de ADUC. Prioriza la eliminación de GenericAll en objetos de alta criticidad (Controladores de dominio, Plantillas de certificado, Cuentas de servicio).

3. Desactivar autenticación NTLM donde sea posible

  • Configura políticas de grupo (Network security: LAN Manager authentication level) a Send NTLMv2 response only. Refuse LM & NTLM.
  • Aplica RestrictNTLM a servidores que no necesiten NTLM (por ejemplo, servidores de archivos que ya usan Kerberos).
  • Usa Microsoft’s NTLM Blocking Tool o LsaIso para bloquear relays en servidores expuestos.

4. Asegurar AD CS

  • Restringe la inscripción de plantillas: en la consola de AD CS, marca “Enrolar sólo a los usuarios/computadoras especificados”.
  • Deshabilita la emisión de certificados con la plantilla “Domain Controller” a menos que sea estrictamente necesario.
  • Habilita la auditoría de eventos 4886 y 4887 (inscripción y emisión de certificados) y envía los logs a un SIEM.
  • Implementa la política de “Key Archival” para que los certificados de alta prioridad tengan su clave privada archivada y revocable.

5. Monitorear patrones de tickets Kerberos

Configura alertas en el controlador de dominio para los siguientes eventos:

  • 4769 – Solicitud de Ticket Granting Ticket (TGT) con TicketEncryptionType inusual.
  • 4770 – Ticket de servicio (TGS) solicitado para cuentas de alto privilegio (krbtgt, krbtgt$).
  • 4768 – Fallos de pre‑authentication que indican intentos de AS‑REP roasting.

Los SIEM modernos pueden correlacionar estos eventos con cambios de ACL o solicitudes de certificados para detectar una cadena en progreso.

6. Uso defensivo de BloodHound

Ejecuta BloodHound con una cuenta de solo lectura y exporta los caminos críticos (High Value Targets). Luego, compara esos caminos con los que aparecen en los logs de auditoría. Si una ruta aparece en ambos, prioriza su mitigación (p. ej., revocar WriteOwner en la OU que contiene cuentas de servicio).

Cuándo aplicar esta solución

  • Síntomas: detección de hashes de cuentas sin pre‑auth, alertas de tickets Kerberos anómalos, logs de SMB con autenticación NTLM desde hosts externos.
  • Entornos: cualquier dominio Windows Server 2012 R2 o superior que utilice AD CS y permita conexiones VPN sin MFA.
  • Exclusiones: entornos aislados donde no haya exposición a internet y todas las cuentas de servicio están estrictamente controladas pueden omitir la fase de bloqueo NTLM, aunque sigue siendo recomendable.

Código

# 1. Forzar pre‑auth para todos los usuarios
powershell -Command "Get-ADUser -Filter * -Properties DoesNotRequirePreAuth | Where-Object {$_.DoesNotRequirePreAuth -eq $true} | Set-ADUser -DoesNotRequirePreAuth $false"

# 2. Listar objetos con permisos peligrosos
powershell -Command "
Import-Module ActiveDirectory
$dangerous = @('GenericAll','GenericWrite','WriteDACL','WriteOwner')
Get-ADObject -Filter * -Properties nTSecurityDescriptor |
  Where-Object {
    $_.nTSecurityDescriptor.Access |
    Where-Object { $dangerous -contains $_.ActiveDirectoryRights }
  } |
  Select-Object Name,DistinguishedName,ObjectClass
"

# 3. Configurar política de grupo para bloquear NTLM (ejemplo en PowerShell)
powershell -Command "
Import-Module GroupPolicy
Set-GPRegistryValue -Name 'Default Domain Policy' -Key 'HKLM\System\CurrentControlSet\Control\Lsa' -ValueName 'LmCompatibilityLevel' -Type DWord -Value 5
"

Verificación

  1. Pre‑auth: Ejecuta klist purge en una máquina cliente y luego kinit usuario. Si la petición falla sin preauth required, la política está activa.
  2. Permisos: Vuelve a correr el script de auditoría; la salida debe estar vacía o contener solo objetos con permisos justificados.
  3. NTLM: Desde un host que solo soporte Kerberos, intenta acceder a un recurso SMB. Un error NT_STATUS_LOGON_FAILURE indica que NTLM fue rechazado.
  4. AD CS: Solicita un certificado con una plantilla restringida. El intento debe ser denegado y generar eventos 4887 en el controlador de dominio.
  5. Kerberos: En el SIEM, verifica que no haya eventos 4769/4768 con cuentas de alto privilegio sin una causa conocida.

Notas adicionales

  • MFA en VPN: Añadir MFA a la puerta de entrada corta la primera eslabón de la cadena; incluso si un atacante logra enumerar SMB, no podrá pasar a la red interna sin el segundo factor.
  • Actualizaciones de seguridad: Microsoft publica mitigaciones para ESC8 y PKINIT en los últimos parches de Windows Server; mantén los controladores al día.
  • Documentación de cambios: Cada vez que modifiques una ACL crítica, registra el motivo y el responsable. Esto facilita auditorías posteriores y reduce la probabilidad de que un permiso excesivo quede sin revisión.
  • Pruebas de penetración internas: Ejecuta simulaciones de la cadena completa (por ejemplo, con SharpHound y Rubeus) en entornos de pruebas. La evidencia de bloqueo en cada fase confirma la efectividad de las defensas.

Implementar estas capas de control transforma una ruta de ataque “cero‑to‑domain‑admin” en una serie de bloqueos detectables, reduciendo drásticamente el riesgo de compromiso total del dominio.