Problema

En entornos con varios administradores de dominio es habitual ver tráfico LDAP, peticiones SAMR/DCE‑RPC y autenticaciones NTLM. Sin embargo, cuando esos patrones aparecen en forma masiva —por ejemplo, cientos de consultas LDAP a controladores de dominio, ráfagas de 10 + SAMR en un segundo, o enumeraciones de equipos críticos como finanzas o sistemas POS— el ruido puede ocultar una fase de reconocimiento interno. El reto consiste en separar la actividad de soporte (cambio de contraseñas, auditorías programadas) de un posible atacante que está mapeando usuarios, grupos y recursos antes de moverse lateralmente.

Causa

1. Herramientas de administración legítimas

  • PowerShell Remoting / AD PowerShell module: los scripts de inventario generan lotes de LDAP y SAMR.
  • Microsoft Endpoint Configuration Manager o SCCM: recopilan inventario de equipos y usuarios mediante llamadas SAMR.
  • Herramientas de auditoría (ex. Microsoft Advanced Threat Analytics, Defender for Identity) que ejecutan escaneos periódicos.

2. Automatización de help‑desk

  • Cambios masivos de contraseñas o desbloqueos de cuentas pueden disparar múltiples consultas LDAP y SAMR en cortos intervalos.
  • Flujos de trabajo de ticketing (ex. ServiceNow, Jira Service Management) que usan cuentas de servicio con privilegios de dominio.

3. Reconocimiento malicioso

  • BloodHound, SharpHound, PingCastle y scripts de PowerShell de código abierto realizan enumeraciones intensas de SAMR, LDAP y DCE‑RPC para construir grafos de privilegios.
  • Herramientas de movimiento lateral (ex. Mimikatz, Invoke‑TheHash) generan ráfagas de autenticaciones NTLM contra NPS/RADIUS y SMB a controladores de dominio.
  • Uso de credenciales comprometidas para ejecutar “net user /domain” o “**Get-ADComputer -Filter ***” desde máquinas de bajo valor (POS, fábrica) para evitar detección.

Solución

1. Normalizar la línea base de actividad

  • Recolectar 30 días de eventos de Security, System y Microsoft-Windows-AD/Operational en todos los DC.
  • Generar métricas de frecuencia por tipo de evento (LDAP = 4768/4769, SAMR = 4662, SMB = 5140).
  • Identificar picos atípicos usando percentiles (p95 vs p99). La línea base sirve para filtrar “ruido” y resaltar outliers.

2. Correlacionar con cuentas de servicio y scripts programados

  • Listar todas las cuentas con privilegios de dominio (Get-ADUser -Filter {Enabled -eq $true -and (MemberOf -like "*Domain Admins*")}) y sus horarios de uso.
  • Verificar que cada pico coincida con una tarea programada (Get-ScheduledTask) o un job de SCCM. Si no hay correlación, la actividad es sospechosa.

3. Implementar detección basada en patrones de enumeración

  • Regla de detección: > 5 peticiones SAMR a diferentes equipos dentro de 10 s desde la misma cuenta.
  • Regla de detección: > 100 consultas LDAP a más de 50 OU distintas en 1 minuto.
  • Configurar estas reglas en SIEM (ex. Splunk, Elastic, Microsoft Sentinel) y en sensores de detección de identidad (Defender for Identity, Vectra).

4. Aislar y validar la cuenta sospechosa

  1. Desactivar temporalmente la cuenta (no eliminar).
  2. Cambiar su contraseña y revocar tickets Kerberos (klist purge).
  3. Ejecutar un escaneo de credenciales en caché (Invoke-Mimikatz -Command "sekurlsa::logonpasswords" en una máquina de prueba).
  4. Revisar los logs de Kerberos Service Ticket (Event ID 4769) para detectar solicitudes a servicios que la cuenta nunca ha usado.

5. Revisar cambios críticos de pertenencia a grupos

  • Auditar eventos 4728, 4732, 4756 (adición a grupos) y 4729, 4733, 4757 (remoción).
  • Si una cuenta de dominio admin se elimina de Domain Admins sin una orden documentada, es señal de compromiso.

6. Fortalecer la defensa perimetral

  • Habilitar LDAP signing y LDAPS para evitar sniffing.
  • Restringir SMB a puertos 445/139 solo entre servidores críticos y controladores de dominio.
  • Aplicar Network Isolation para sistemas POS y de fábrica: no deben poder iniciar sesiones LDAP directamente.

Cuándo aplicar esta solución

  • Síntomas: ráfagas de SAMR/DCE‑RPC, LDAP o SMB que provienen de cuentas con privilegios elevados y que apuntan a equipos fuera del alcance habitual (finanzas, HR, POS).
  • Entorno: cualquier dominio Windows con al menos un controlador de dominio y una solución de registro centralizado.
  • No aplica: entornos totalmente aislados donde solo se usan cuentas de servicio sin privilegios de dominio o donde la auditoría está deshabilitada. En esos casos, primero habilite la auditoría antes de aplicar las reglas.

Código

# Exportar eventos de enumeración SAMR y LDAP de los últimos 7 días
wevtutil qe Security "/q:*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and (EventID=4662 or EventID=4768 or EventID=4769)]]" /f:text > samr_ldap_events.txt

# Filtrar por cuenta sospechosa (ejemplo: adminsvc) y agrupar por tipo de recurso
grep -i "adminsvc" samr_ldap_events.txt | awk '/ObjectName/ {print $NF}' | sort | uniq -c | sort -nr > enumeration_summary.txt

Verificación

  1. Revisar enumeration_summary.txt: si aparecen más de 10 recursos diferentes en menos de 30 s, la cuenta está realizando reconocimiento.
  2. Comprobar correlación con tareas programadas: Get-ScheduledTask | Where-Object {$_.TaskPath -like "*adminsvc*"}. Si no hay coincidencia, la actividad es anómala.
  3. Validar cambios de grupo: Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4728,4732,4756,4729,4733,4757} | Where-Object {$_.Message -match "adminsvc"}. Cualquier adición o remoción inesperada confirma compromiso.
  4. Confirmar que la cuenta está deshabilitada: Get-ADUser adminsvc -Properties Enabled | Select-Object Name,Enabled. Debe aparecer como Enabled : False.

Notas adicionales

  • Las alertas de USER_ENUMERATION y ENDPOINT_ENUMERATION de Defender for Identity suelen dispararse por la misma actividad que describimos; ajusta los umbrales para evitar falsos positivos en entornos con auditorías automatizadas.
  • En entornos con Azure AD / Entra ID, los inicios de sesión desde IPs externas pueden ser legítimos (VPN, acceso remoto). Correlaciona con la lista de rangos de confianza antes de marcar como sospechoso.
  • Mantén siempre una copia de los logs de auditoría en un almacén inmutable (ex. Azure Blob con retención de 90 días) para poder reconstruir la cadena de eventos en caso de incidentes.