Cuatro desafíos para la seguridad de Active Directory y los registros de eventos

Dado que los atacantes desarrollan constantemente nuevas tácticas para comprometer las credenciales y los datos, es cada vez más importante monitorear sistemas críticos como Active Directory (AD) en busca de signos de actividad maliciosa.

Muchas organizaciones recurren a productos de gestión de eventos e información de seguridad (SIEM) en busca de ayuda. Pero si bien estas soluciones pueden ser extremadamente poderosas, en última instancia dependen de los registros de eventos de Windows, con los que es complicado trabajar y no brindan la información necesaria para monitorear varios vectores clave de ataque de AD.

Este blog explora cuatro de los principales desafíos a la hora de proteger Active Directory y explica la limitación del uso de registros de eventos para abordarlos.

Desafío 1. Monitorear los cambios en la membresía del grupo

Los grupos de seguridad de Active Directory son la forma principal en que los usuarios obtienen acceso a los recursos de TI, incluidos 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 realizar un seguimiento de los cambios en la membresía del grupo de seguridad.

Es especialmente importante realizar un seguimiento de los cambios en los grupos que brindan acceso privilegiado. Esto incluye grupos integrados como administradores de dominio, administradores empresariales y administradores de esquema, así como cualquier grupo de seguridad que su organización haya creado y que proporcione derechos de acceso elevados.

Lo que captura el registro de eventos y sus limitaciones

Active Directory realiza un seguimiento de los cambios en los grupos de seguridad en el registro de eventos. Por ejemplo, si se agrega un usuario al grupo de administradores de dominio, 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 se cambió.
• El tipo de cambio (en este caso, que se agregó un miembro)

Figura 1. Evento de muestra que muestra que se modificó un grupo de seguridad

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

• · No hay registro de dónde provino el cambio: los registros de eventos no registran el origen de un cambio en la membresía del grupo. Aunque un cambio al grupo de administradores de dominio desde un servidor de salto o un 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 en ubicaciones anormales.
• · Sin supervisión de la pertenencia efectiva a un grupo: Active Directory solo registra los cambios en la pertenencia 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, debe monitorear el grupo en sí y todos los grupos anidados dentro de él.
• · Incoherencias entre eventos: los eventos registrados serán diferentes dependiendo de cómo se cambió un grupo. Por ejemplo, si se agrega un usuario a un grupo mediante Interfaces de servicio de Active Directory (ADSI), el registro de eventos mostrará un evento de eliminación para cada miembro del grupo existente, seguido de un evento que agrega nuevamente a cada miembro del grupo, seguido de un evento que agrega el Nuevo Usuario; por lo tanto, agregar un usuario a un grupo con 50 miembros generará 101 entradas de registro de eventos. Y si el cambio se realizó mediante LDAP, es posible que aparezca el GUID del objeto en lugar de su nombre completo. Estas inconsistencias pueden causar confusión y desinformación en los productos SIEM y hacer que sea extremadamente difícil crear reglas efectivas que actúen sobre los datos recopilados.

Desafío 2. Monitorear los cambios en la política de grupo

La configuración de la política de grupo afecta a los usuarios y computadoras en todo el dominio de Active Directory, incluido, por ejemplo, quién tiene acceso administrativo a los sistemas. Un solo cambio en un objeto de política de grupo (GPO) puede tener graves impactos en la seguridad o provocar interrupciones en la producción, por lo que monitorear estos cambios es fundamental.

Lo que captura el registro de eventos y sus limitaciones

Cuando se cambia una política de grupo, se registrará 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 para un cambio en la Política de grupo

Sin embargo, estos eventos carecen de la siguiente información crítica:

• · Detalles de qué configuración se cambió y sus valores antes y después: los GPO admiten cientos de configuraciones personalizadas y listas para usar. Un cambio podría modificar la página de inicio predeterminada del navegador 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 modificada ni a qué se cambió.
• · Fuente 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 provino el cambio. La mayoría de los cambios de GPO deben 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 directorio

Otra tarea clave para proteger su Active Directory es monitorear cómo las cuentas de usuario leen y enumeran los objetos AD. Los atacantes que buscan afianzarse en su red a menudo enumeran cuentas, grupos y servidores críticos para descubrir rutas de ataque que conducen a privilegios elevados y, en última instancia, a datos confidenciales. Al monitorear eventos de lectura sospechosos, puede detectar esta actividad de reconocimiento y detener un ataque antes de que sea demasiado tarde.

Lo que 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 lee y el tipo de operación que se realiza, como se ilustra en la Figura 3:

Figura 3. Un evento que muestra que se leyó una propiedad de los administradores de dominio

Sin embargo, intentar utilizar estos eventos para detectar actividades sospechosas tiene múltiples inconvenientes:

• Demasiado ruido: el registro de eventos de lectura genera tanto ruido en el registro de eventos que es casi imposible encontrar información valiosa. De hecho, una sola instancia de un usuario que observa un grupo puede generar docenas o incluso cientos de eventos en el registro, lo que hace casi imposible encontrar actividad sospechosa entre todos los eventos legítimos.
• No hay registro de dónde provino la lectura: además, no hay forma de saber dónde se originó el evento de lectura. Como vimos con los cambios tanto en los grupos de seguridad como en los GPO, 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 de reconocimiento malicioso.
• Demasiados eventos de acceso denegado: también es fundamental detectar a los usuarios que intentan acceder a información que no tienen derecho a ver. Por ejemplo, Active Directory puede almacenar contraseñas de texto sin cifrar para cuentas administrativas en atributos de computadora, por lo que una cuenta de usuario que intente leer estos atributos podría estar intentando comprometer credenciales privilegiadas. Desafortunadamente, cada vez que una cuenta ve un objeto para cualquier propósito, la acción genera eventos de falla de acceso para todos los atributos que no tienen derechos de lectura, incluso si no tenían intención de leer esos atributos. Simplemente no es una estrategia viable tratar de encontrar eventos de acceso fallidos verdaderamente sospechosos entre el océano de eventos inocentes.
• No hay una manera fácil de monitorear las consultas LDAP: las consultas LDAP se usan comúnmente para explorar Active Directory y descubrir usuarios, grupos y computadoras. Desafortunadamente, Microsoft no proporciona una manera sencilla de monitorear las consultas LDAP para ver la consulta emitida y su procedencia. Debido a este problema, incluso activar la supervisión LDAP a nivel de diagnóstico proporciona poco valor; de hecho, Microsoft no lo recomienda, ya que generará una enorme cantidad 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, monitorear los patrones de autenticación es fundamental para identificar cuentas comprometidas, señales de ataques pass-the-hash y pass-the-ticket, tickets Kerberos falsificados u otros exploits utilizados para obtener privilegios y acceso a información confidencial. datos.

Lo que captura el registro de eventos y sus limitaciones

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

Si bien estos eventos capturan información útil, no proporcionan una forma efectiva de detectar ataques basados en autenticación debido a las siguientes deficiencias:

• Demasiado ruido: se crean eventos cada vez que el usuario inicia sesión en cualquier computadora, lo que suele representar una enorme cantidad de actividad. Muchos otros eventos se crean detrás de escena. Por ejemplo, cuando un usuario inicia sesión en un servidor miembro unido a un dominio AD, el servidor inicia una conexión a un DC que recupera información de Política de grupo, lo que da como resultado eventos de inicio y cierre de sesión que aparecen en el registro de eventos del DC. No hay forma de desactivar el registro de la actividad normal de inicio de sesión del usuario sin ignorar la actividad de inicio de sesión crítica en sus 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 la manera adecuada. Por ejemplo, no existe 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 de red a través de una unidad de red asignada; debe recopilar registros de cada servidor miembro e intentar correlacionarlos con los registros del DC.
• Falta de detalles específicos del protocolo: a los eventos también les faltan otros detalles valiosos. Por ejemplo, los eventos de autenticación Kerberos no registran las marcas de tiempo de vida del ticket y de renovación, que son indicadores valiosos de tickets falsificados utilizados en el exploit Golden Ticket. De manera similar, los registros NTLM no especifican la versión NTLM que se utilizó, información que es valiosa para determinar si se pueden deshabilitar versiones NTLM anteriores en favor de protocolos más seguros.

Cómo puede ayudar Netwrix

Como hemos visto, los registros de eventos son inadecuados para detectar ataques rápidamente y responder de manera efectiva. Para una protección de extremo a extremo, considere la solución de seguridad Netwrix Active Directory. Esto te ayudará:

• Identifique proactivamente brechas de seguridad a través de una evaluación de riesgos en profundidad.
• Minimice los costosos tiempos de inactividad y las interrupciones comerciales.
• Detecte rápidamente incluso amenazas avanzadas a tiempo y responda rápidamente.