Cuatro desafíos al monitorear la seguridad de Active Directory

Con los atacantes desarrollando constantemente nuevas tácticas para comprometer credenciales y datos, es cada vez más importante monitorear sistemas críticos como Active Directory (AD) en busca de señales de actividad maliciosa.

Muchas organizaciones recurren a productos de security information and event management (SIEM) para obtener ayuda. Pero aunque estas soluciones pueden ser extremadamente poderosas, en última instancia dependen de los registros de eventos de Windows, que son complicados de manejar y no proporcionan la información necesaria para monitorear varios vectores de ataque clave de AD.

Este blog explora cuatro de los principales desafíos al asegurar Active Directory y explica la limitación de usar registros de eventos para abordarlos.

Desafío 1. Monitoreo de Cambios en la Membresía de Grupos

Los grupos de seguridad de Active Directory son la forma principal en que se otorga acceso a los usuarios a los recursos de TI, incluyendo datos, máquinas y aplicaciones. A medida que los atacantes se mueven lateralmente a través de su entorno, a menudo agregan las cuentas que han comprometido a nuevos grupos de seguridad para obtener privilegios adicionales, por lo que es vital rastrear los cambios en la membresía de los grupos de seguridad.

El seguimiento de los cambios en los grupos que proporcionan acceso privilegiado es especialmente importante. Esto incluye grupos integrados como Domain Admins, Enterprise Admins y Schema Admins, así como cualquier grupo de seguridad que su organización haya creado que otorgue derechos de acceso elevados.

Qué captura el registro de eventos — y sus limitaciones

Active Directory registra los cambios en los grupos de seguridad en el registro de eventos. Por ejemplo, si se agrega un usuario al grupo de Domain Admins, AD generará un evento como el que se muestra a continuación, que incluye los siguientes detalles clave:

• El ID del usuario que realizó el cambio
• El DN y la clase del objeto que fue modificado
• El tipo de cambio (en este caso, que se añadió un miembro)

Figura 1. Evento de muestra que indica que un grupo de seguridad fue modificado

Sin embargo, el registro de eventos tiene varias limitaciones importantes:

• · No hay registro del origen del cambio — Los registros de eventos no registran la fuente de un cambio en la membresía de un grupo. Aunque un cambio en el grupo de Domain Admins desde un servidor de salto o controlador de dominio (DC) puede ser normal, un cambio desde una estación de trabajo no administrativa u otra máquina con acceso a internet puede ser una señal reveladora de un ataque. Sin detalles sobre el origen del cambio, es imposible alertar sobre cambios desde ubicaciones anormales.
• · Sin monitoreo de la membresía efectiva de grupos — Active Directory solo registra cambios en la membresía directa de un grupo. Sin embargo, los grupos pueden contener otros grupos como miembros. Por lo tanto, para monitorear verdaderamente los cambios en la membresía de un grupo, debes monitorear el propio grupo y cada grupo anidado dentro de él.
• · Inconsistencias entre eventos — Los eventos registrados serán diferentes dependiendo de cómo se haya cambiado un grupo. Por ejemplo, si se añade un usuario a un grupo utilizando Active Directory Service Interfaces (ADSI), el registro de eventos mostrará un evento de eliminación por cada miembro existente del grupo, seguido por un evento que añade de nuevo a cada miembro del grupo, seguido por un evento que añade al nuevo usuario; por lo tanto, añadir un usuario a un grupo con 50 miembros generará 101 entradas en el registro de eventos. Y si el cambio se realizó utilizando LDAP, es posible que se liste el GUID del objeto en lugar de su nombre distinguido. Estas inconsistencias pueden causar confusión y desinformación en productos SIEM, y hacer extremadamente difícil construir reglas efectivas que actúen sobre los datos recopilados.

Desafío 2. Monitoreo de Cambios en Group Policy

La configuración de Directiva de grupo afecta a usuarios y computadoras a través del Active Directory domain, incluyendo, por ejemplo, quién tiene acceso administrativo a los sistemas. Un solo cambio en un Group Policy object (GPO) puede tener graves impactos de seguridad o causar interrupciones de producción, por lo que es crítico monitorear estos cambios.

Qué captura el registro de eventos — y sus limitaciones

Cuando se cambia una Directiva de Grupo, se registra un evento como el que se muestra en la Figura 2. Este evento proporciona información útil, como quién realizó el cambio y el identificador del GPO.

Figura 2. Evento registrado por un cambio en la Directiva de Grupo

Sin embargo, a estos eventos les falta la siguiente información crítica:

• · Detalles de qué configuración fue cambiada y sus valores antes y después — Los GPOs admiten cientos de configuraciones predeterminadas y personalizadas. Un cambio podría modificar la página de inicio del navegador predeterminado para los usuarios, o proporcionar a todos los usuarios control administrativo de una máquina crítica. Sin embargo, el registro de eventos no captura la configuración alterada y a qué fue cambiada.
• · Origen del cambio — Al igual que con los cambios en los grupos de seguridad, los eventos que registran cambios en la Política de Grupo no indican de dónde proviene el cambio. La mayoría de los cambios en los GPO deberían provenir de unas pocas ubicaciones seleccionadas, y poder identificar cambios que provienen de ubicaciones anormales es vital para detectar ataques rápidamente.

Desafío 3. Monitoreo de lecturas de Directory Management

Otra tarea clave en la protección de su Active Directory es monitorear cómo las cuentas de usuario leen y enumeran objetos de AD. Los atacantes que buscan obtener un punto de apoyo en su red a menudo enumeran cuentas críticas, grupos y servidores para descubrir caminos de ataque que conducen a privilegios elevados y, en última instancia, a datos sensibles. Al monitorear eventos de lectura sospechosos, puede detectar esta actividad de reconocimiento y detener un ataque antes de que sea demasiado tarde.

Qué captura el registro de eventos — y sus limitaciones

Para ayudarle a ver quién está explorando Active Directory, el registro de eventos captura la actividad de lectura. El evento muestra detalles sobre la cuenta de usuario, el objeto que se está leyendo y el tipo de operación que se está realizando, como se ilustra en la Figura 3:

Figura 3. Un evento que muestra que se leyó una propiedad de Domain Admins

Sin embargo, intentar usar estos eventos para buscar actividades sospechosas tiene múltiples desventajas:

• Demasiado ruido — Registrar eventos de lectura resulta en tanto ruido en el registro de eventos que es casi imposible encontrar información valiosa. De hecho, una sola instancia de un usuario mirando un grupo puede generar docenas o incluso cientos de eventos en el registro, lo que hace que sea casi imposible encontrar actividad sospechosa entre todos los eventos legítimos.
• No hay registro del origen de la lectura — Además, no hay forma de saber de dónde provino el evento de lectura. Como vimos con los cambios en los grupos de seguridad y las GPOs, saber de qué computadora proviene un evento de lectura es información crucial para determinar si se trata de una lectura inofensiva o un acto malicioso de reconocimiento.
• Demasiados eventos de acceso denegado — También es vital detectar a los usuarios que intentan acceder a información a la que no tienen derecho. Por ejemplo, Active Directory puede almacenar contraseñas en texto claro para cuentas administrativas en atributos de computadora, por lo que una cuenta de usuario que intenta leer estos atributos podría estar tratando de comprometer credenciales privilegiadas. Desafortunadamente, cada vez que cualquier cuenta visualiza un objeto por cualquier motivo, la acción genera eventos de fallo de acceso para todos los atributos que no tienen derecho a leer, incluso si no tenían la intención de leer esos atributos. Simplemente no es una estrategia viable intentar encontrar eventos de acceso fallido verdaderamente sospechosos entre el océano de eventos inocentes.
• No hay una manera fácil de monitorear las consultas LDAP — Las consultas LDAP se utilizan comúnmente para explorar Active Directory y descubrir usuarios, grupos y computadoras. Desafortunadamente, Microsoft no ofrece una manera fácil de monitorear las consultas LDAP para ver la consulta emitida y su origen. Debido a este problema, incluso activar el monitoreo LDAP a nivel de diagnóstico tiene poco valor; de hecho, no es recomendado por Microsoft, ya que generará una cantidad enorme de ruido en los registros de eventos.

Desafío 4. Seguimiento de eventos de autenticación

Con el reciente aumento de ataques basados en credenciales, es crítico monitorear los patrones de autenticación para identificar cuentas comprometidas, señales de pass-the-hash y pass-the-ticket attacks, forged Kerberos tickets, u otros exploits utilizados para obtener privilegios y acceso a datos sensibles.

Qué captura el registro de eventos — y sus limitaciones

Active Directory captura eventos para monitorear la actividad de inicio de sesión y autenticación de usuarios en controladores de dominio, servidores miembros y estaciones de trabajo, incluyendo los que se enumeran en la siguiente tabla:

Aunque estos eventos capturan información útil, no ofrecen una forma efectiva de detectar ataques basados en autenticación debido a las siguientes limitaciones:

• Demasiado ruido — Se crean eventos cada vez que un usuario inicia sesión en cualquier computadora, lo que generalmente es una cantidad enorme de actividad. Muchos otros eventos se crean entre bastidores. Por ejemplo, cuando un usuario inicia sesión en un servidor miembro unido a un dominio de AD, el servidor inicia una conexión con un DC que recupera información de la Política de Grupo, lo que resulta en la aparición de eventos de inicio y cierre de sesión en el registro de eventos del DC. No hay forma de desactivar el registro de la actividad normal de inicio de sesión de los usuarios sin ignorar la actividad crítica de inicio de sesión en tus controladores de dominio.
• No hay registro del tipo de inicio de sesión en los DC — Los registros no rastrean el tipo de inicio de sesión para los eventos de inicio de sesión en los DC, un contexto que es invaluable para determinar si las cuentas se están utilizando de manera apropiada. Por ejemplo, no hay una manera fácil de diferenciar entre un usuario que inicia sesión a través de Escritorio Remoto y un inicio de sesión en la red a través de una unidad de red mapeada; es necesario recopilar registros de cada servidor miembro e intentar correlacionarlos con los registros de los DC.
• Falta de detalles específicos del protocolo — Los eventos también carecen de otros detalles valiosos. Por ejemplo, los eventos de autenticación Kerberos no registran las marcas de tiempo de vida útil y renovación del ticket, que son indicadores valiosos de tickets falsificados utilizados en el Golden Ticket exploit. De manera similar, los registros NTLM no especifican la versión de NTLM que se utilizó, información que es valiosa para determinar si puede deshabilitar versiones antiguas de NTLM en favor de protocolos más seguros.

Cómo Netwrix puede ayudar

Como hemos visto, los registros de eventos son insuficientes para detectar ataques de manera oportuna y responder de manera efectiva. Para una protección integral, considere la solución de seguridad de Netwrix Active Directory. Le ayudará a:

• Identifique proactivamente las brechas de seguridad mediante una evaluación de riesgos en profundidad.
• Minimice el costoso tiempo de inactividad y las interrupciones del negocio.
• Detecte rápidamente incluso las amenazas avanzadas a tiempo y responda con rapidez.