Active Directory: 5 Controles Anti-Breach

Active Directory (AD) es el corazón de casi toda infraestructura IT empresarial, actuando como el principal sistema de autenticación y autorización. Su compromiso puede tener consecuencias devastadoras, llevando a interrupciones de servicio, exfiltración de datos sensibles y daños reputacionales. Los atacantes lo saben bien y AD es a menudo su primer objetivo, con estadísticas que indican cómo una parte relevante de los breaches (alrededor del 74% en las pymes fuente: Verizon Data Breach Investigations Report 2024) tiene su origen precisamente en exploits o abusos relacionados con Active Directory. Detectar un compromiso en curso no es solo una cuestión de parchear, sino de monitoreo proactivo y comprensión de las señales que el propio AD nos proporciona.

Cuando se gestionan entornos complejos, con miles de estaciones de trabajo y cientos de servidores, la cantidad de eventos generados puede ser abrumadora. Aun así, entre el ruido de fondo, existen patrones específicos y Event ID que actúan como señales de alarma tempranas. Ignorarlos significa dar a los atacantes el tiempo necesario para establecer persistencia, escalar privilegios y moverse lateralmente en la red. El objetivo no es solo prevenir el ataque, sino reducir al máximo el tiempo medio de detección (MTTD) y el tiempo medio de respuesta (MTTR). En este artículo, exploraremos cinco controles fundamentales, probados en campo, que todo profesional de IT debería implementar para identificar a tiempo un compromiso de Active Directory.

Tested on: Windows Server 2022 Domain Controller · Windows 10/11 Client · Agosto 2026

Requisitos Previos / Entorno de Prueba

Para implementar y probar estos controles, es necesario tener acceso con privilegios de administrador al Domain Controller (DC) y al sistema de centralización de logs (SIEM/EDR) utilizado en el entorno. Es fundamental que la política de auditoría de Active Directory esté configurada correctamente para registrar los eventos de seguridad relevantes. En un entorno de prueba, utilicé un Domain Controller virtual con Windows Server 2022 y varias máquinas cliente Windows 10/11, monitoreando los logs a través de una instancia de Wazuh. Asegúrate de que la política de auditoría esté habilitada para ‘Audit Account Logon Events’, ‘Audit Account Management’, ‘Audit Directory Service Access’ y ‘Audit Policy Change’.

1. Monitoreo de Logs de Seguridad Críticos

El monitoreo continuo de los logs de seguridad es la primera línea de defensa. Eventos específicos pueden indicar actividades sospechosas como intentos de acceso no autorizados, escalada de privilegios o modificaciones a la configuración de seguridad. Es esencial no solo recolectar estos logs, sino también analizarlos activamente, quizás a través de un SIEM que pueda correlacionar los eventos y generar alertas en tiempo real. Los logs deben centralizarse y conservarse por un período adecuado, en conformidad con normativas como la NIS2 art. 21 Lee también: NIS2 Sanidad: Registro Tratamientos Técnico.

Event ID a monitorear prioritariamente:

4624 (An account was successfully logged on): Un inicio de sesión exitoso. Por sí mismo no es un problema, pero un gran número de inicios de sesión de una sola cuenta desde diferentes ubicaciones geográficas en un corto período de tiempo, o inicios de sesión de cuentas de servicio en horarios no laborales, son altamente sospechosos.
4625 (An account failed to log on): Un intento de inicio de sesión fallido. Un alto volumen de estos eventos para una sola cuenta o desde una sola IP puede indicar un ataque de ‘fuerza bruta’ o ‘password spraying’.
4720 (A user account was created): Creación de una nueva cuenta de usuario. Si no está autorizada, podría ser una cuenta backdoor.
4732 (A member was added to a security-enabled global group): Un usuario ha sido añadido a un grupo de seguridad privilegiado (ej. Domain Admins). Esta es una señal de escalada de privilegios.
4740 (A user account was locked out): Una cuenta de usuario ha sido bloqueada. A menudo es consecuencia de ataques de ‘fuerza bruta’.
4768/4769 (A Kerberos authentication ticket (TGT/Service Ticket) was requested): Solicitudes de tickets Kerberos. Pueden indicar ataques ‘Golden Ticket’ o ‘Silver Ticket’ si los patrones son anómalos.

Para filtrar estos eventos en un Domain Controller, puedes usar PowerShell:

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624,4625,4720,4732,4740,4768,4769} | Format-Table -AutoSize

Este comando te dará una visión general inmediata de los eventos más recientes. Para un monitoreo continuo, un SIEM es indispensable.

2. Auditoría de Cuentas Privilegiadas

Las cuentas con privilegios elevados (como Domain Admins, Enterprise Admins, Schema Admins y cuentas de servicio con permisos elevados) son los objetivos principales de los atacantes. Un control riguroso de su uso es crucial. Toda actividad de estas cuentas debe ser justificada y monitoreada. Idealmente, estas cuentas deberían usarse solo para tareas administrativas específicas y no para actividades diarias.

Controles a realizar:

Principio del mínimo privilegio: Asegurarse de que ningún usuario o servicio tenga más permisos de los estrictamente necesarios para sus funciones.
Separación de funciones: Implementar la separación de funciones para reducir el riesgo de que un solo usuario pueda comprometer todo el sistema.
Monitoreo del uso: Rastrear cada inicio de sesión y cada acción realizada por cuentas privilegiadas. Herramientas como LAPS (Local Administrator Password Solution) ayudan a gestionar las contraseñas de los administradores locales de forma segura. Lee también: Honeypot Agosto: 7 Días, 1.200 Ataques SSH

Para listar los miembros del grupo ‘Domain Admins’:

Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select-Object Name, SamAccountName

Esta lista debe ser revisada regularmente. Cualquier cuenta desconocida o no autorizada es una señal de alarma.

3. Robustez de las Políticas de Contraseñas y Monitoreo de ‘Password Spraying’

Contraseñas débiles o políticas insuficientes son un punto de entrada común para los atacantes. La política de contraseñas debería ser compleja, con requisitos de longitud, complejidad y rotación adecuados. Sin embargo, incluso con políticas robustas, ataques como el ‘password spraying’ (intento de acceder a muchas cuentas con una sola contraseña común) pueden tener éxito.

Acciones preventivas y de monitoreo:

Política de bloqueo de cuentas: Implementar una política de bloqueo de cuentas (Account Lockout Policy) para prevenir ataques de ‘fuerza bruta’ dirigidos. Atención, puede ser usada para ataques DoS (Denial of Service) si no se configura con cuidado.
MFA para accesos privilegiados: La autenticación multifactor (MFA) debería ser obligatoria para todas las cuentas administrativas y para los accesos remotos.
Monitoreo del Event ID 4625: Un número elevado de 4625 con diferentes cuentas pero la misma contraseña de origen puede indicar un ataque de ‘password spraying’.

Para visualizar la política de bloqueo de cuentas:

Get-ADDefaultDomainPasswordPolicy | Format-List LockoutThreshold, LockoutDuration, ResetLockoutCount

Estos parámetros deben equilibrarse para prevenir ataques sin bloquear excesivamente a los usuarios legítimos.

4. Control de la Replicación de Active Directory

La replicación de Active Directory es fundamental para la coherencia de los datos entre los Domain Controllers. Las anomalías en la replicación pueden indicar problemas de conectividad, pero también intentos de manipulación por parte de un atacante que busca comprometer un DC sin que los cambios se propaguen (o que se propaguen cambios maliciosos). Un DC comprometido puede ser usado como punto de apoyo para ataques posteriores.

Herramientas y controles:

repadmin /showrepl: Este comando muestra el estado de la replicación entre los DC. Errores persistentes o latencias anómalas deben ser investigados.
dcdiag: Una herramienta de diagnóstico que verifica el estado general de los DC, incluida la replicación.

Ejemplo de uso de repadmin:

repadmin /showrepl

Una salida limpia indica una replicación saludable. Errores como ‘Access Denied’ o ‘RPC server is unavailable’ podrían ser más graves que un simple problema de red.

5. Monitoreo de Cambios en los Objetos de Política de Grupo (GPO)

Los Objetos de Política de Grupo (GPO) son el medio principal para configurar la seguridad y el comportamiento de los usuarios y las computadoras en un dominio AD. Las modificaciones no autorizadas a las GPO pueden ser utilizadas por los atacantes para deshabilitar controles de seguridad, crear nuevas excepciones de firewall o distribuir malware. El monitoreo de estos cambios es, por lo tanto, un control crítico.

Event ID a monitorear:

4662 (An operation was performed on an object): Este evento se genera cuando se modifica un objeto AD. Filtrando por el tipo de objeto ‘Group-Policy-Container’ y ‘Group-Policy-Template’, es posible identificar las modificaciones a las GPO.
5136 (A directory service object was modified): Similar al 4662, proporciona detalles sobre las modificaciones a los objetos del servicio de directorio, incluidas las GPO.

Para un monitoreo eficaz, es aconsejable utilizar herramientas específicas para la gestión y el versionado de las GPO, además del monitoreo de los Event ID. Cualquier modificación no planificada o no aprobada a una GPO debe activar una alerta inmediata.

Errores Comunes y Resolución de Problemas

Sobrecarga de logs: Sin un SIEM o una estrategia de filtrado, el volumen de logs puede ser insostenible. Utiliza filtros específicos y configura la política de auditoría para registrar solo los eventos más relevantes.
Falsos positivos: Las alertas excesivas pueden llevar a la ‘fatiga de alertas’. Afina las reglas de correlación en tu SIEM y crea líneas base de comportamiento normal para reducir los falsos positivos.
Falta de contexto: Un solo Event ID rara vez proporciona el panorama completo. Correlacionar eventos de diferentes fuentes (AD, firewall, EDR) es fundamental para comprender la naturaleza del ataque.
Falta de automatización: Realizar estos controles manualmente es impracticable en entornos empresariales. La automatización mediante scripts de PowerShell, SIEM o EDR es indispensable.

FAQ — Preguntas Frecuentes

¿Con qué frecuencia debería revisar los miembros de los grupos privilegiados?

Idealmente, deberías revisar los miembros de los grupos privilegiados al menos trimestralmente. Para entornos de alta seguridad o con alta rotación, una revisión mensual o incluso más frecuente es recomendada. Además, cada vez que un administrador deja la organización, sus cuentas deben ser deshabilitadas inmediatamente y eliminadas de todos los grupos privilegiados.

¿Es suficiente monitorear solo los Event ID?

No, el monitoreo de los Event ID es un excelente punto de partida, pero no es suficiente por sí solo. Los Event ID proporcionan una pieza del rompecabezas. Es fundamental correlacionarlos con otros datos de seguridad (ej. tráfico de red, actividad de endpoints desde un EDR) y tener un contexto sobre la línea base de comportamiento normal de tu entorno. Un SIEM es esencial para esta correlación.

¿Cuál es el impacto de las políticas de auditoría en los Domain Controllers?

Las políticas de auditoría, si se configuran de forma excesiva, pueden generar un volumen muy elevado de logs, consumiendo espacio en disco y recursos de CPU en el Domain Controller. Es importante equilibrar la granularidad de la auditoría con el rendimiento del DC. Concéntrate en los eventos de seguridad críticos y deshabilita la auditoría para eventos de bajo valor que no contribuyen a la detección de amenazas.

¿Las cuentas de servicio deberían tener contraseñas que caduquen?

Generalmente, para las cuentas de servicio, es preferible utilizar contraseñas largas, complejas y generadas aleatoriamente que no caduquen, en lugar de forzar su caducidad. Las contraseñas que caducan para las cuentas de servicio a menudo conducen a interrupciones del servicio y al uso de contraseñas débiles por comodidad. Es más importante monitorear cuidadosamente la actividad de estas cuentas y protegerlas con el principio del mínimo privilegio y, si es posible, con Managed Service Accounts (MSA) o Group Managed Service Accounts (gMSA).

Conclusiones con Puntos Clave Operativos

La seguridad de Active Directory no es un proyecto de ‘configurar y olvidar’. Requiere un enfoque proactivo, basado en el monitoreo continuo y la comprensión de las señales de alarma. Los cinco controles discutidos — monitoreo de logs críticos, auditoría de cuentas privilegiadas, robustez de las políticas de contraseñas, control de la replicación de AD y monitoreo de las GPO — forman una base sólida para detectar a tiempo un compromiso. Implementar un SIEM eficaz, automatizar los controles y formar al personal sobre los riesgos relacionados con AD son pasos operativos esenciales. Recuerda, el tiempo es un factor crítico: cada minuto ahorrado en la detección de un ataque puede significar la diferencia entre un incidente manejable y un desastre total.

Fuentes

Actualizado: agosto 2026