Auditoría de seguridad con Local Group Policy en entornos Windows

Si administras equipos Windows en un entorno corporativo, tarde o temprano te ves obligado a lidiar con la auditoría de seguridad y las directivas de grupo. No es precisamente lo más divertido del mundo, pero es clave para saber quién hace qué, dónde y cuándo dentro de tu infraestructura. Una buena configuración marca la diferencia entre enterarte de un ataque a tiempo o descubrirlo meses después, revisando logs a la desesperada.

En este artículo vamos a desgranar, paso a paso, cómo plantear una auditoría de seguridad basada en Local Group Policy y GPO en controladores de dominio, servidores y estaciones de trabajo. Verás tanto la parte clásica de Windows (Directiva de auditoría avanzada, SACL, auditpol, etc.) como cómo se integra todo esto con soluciones como Microsoft Defender for Identity y con escenarios híbridos en AWS, además de algunos trucos prácticos y buenas prácticas para no destrozar el rendimiento ni llenarte de eventos inútiles.

Por qué la auditoría de seguridad con Local Group Policy es tan importante

La base de todo esto es entender que la auditoría de seguridad en Windows sirve para registrar acciones relevantes sobre cuentas, inicios de sesión, objetos de Active Directory, ficheros y servicios. Sin esos registros, cualquier incidente de seguridad se convierte en una película a ciegas: no sabes quién cambió un GPO, quién añadió un usuario a Administradores o quién tocó una carpeta sensible.

En entornos grandes, con muchos GPO vinculados a diferentes OU, varios dominios y montones de servidores, seguir la pista a todos esos cambios se vuelve muy complicado si no se habilita correctamente la auditoría desde el principio. De ahí que productos como Microsoft Defender for Identity o soluciones de terceros tipo Semperis DSP se apoyen de lleno en los eventos de seguridad de Windows para detectar comportamiento sospechoso.

La idea es siempre la misma: configurar la auditoría lo suficientemente detallada como para detectar actividades críticas (cambios en GPO, modificaciones de cuentas, abusos de NTLM, movimientos en AD FS o AD CS, accesos a carpetas financieras, etc.), pero sin disparar el consumo de CPU, disco y red ni generar terabytes de logs imposibles de analizar.

Otro punto clave es que muchas de estas configuraciones se aplican mediante Local Group Policy o GPO de dominio, y eso nos permite estandarizar el comportamiento de todos los equipos: controladores de dominio, servidores de archivos, servidores de federación, servidores de certificados, estaciones con datos sensibles (ver guía de seguridad en Windows 11)… todo bajo control desde la misma consola de Administración de directivas de grupo.

Defender for Identity y auditoría de eventos de Windows

Microsoft Defender for Identity se basa de forma intensiva en los eventos de seguridad de Windows para detectar movimientos laterales, cambios sospechosos en cuentas, abusos de NTLM o modificaciones críticas en Active Directory. Si la auditoría está mal configurada, el producto pierde visibilidad y, en consecuencia, capacidad de detección.

Lo primero que recomienda Microsoft es ejecutar un script de PowerShell que revise la configuración actual de auditoría y genere un informe con lo que falta. Para ello se utiliza el módulo de PowerShell de Defender for Identity y el cmdlet New-MDIConfigurationReport, que permite escanear tanto GPO de dominio como la configuración local.

Un ejemplo típico sería lanzar algo como: New-MDIConfigurationReport -Path «C:\\Reports» -Mode Domain -OpenHtmlReport. Con este comando se guarda un informe HTML en la ruta indicada, se lee toda la información desde los GPO de dominio y se abre automáticamente el reporte en el navegador predeterminado para que puedas revisar qué ajustes debes aplicar.

Este informe analiza directivas de auditoría avanzadas, configuración de NTLM, SACL sobre objetos críticos de Active Directory, ajustes de AD FS y demás. La idea es que, una vez revisado, puedas ajustar GPO y políticas locales antes de activar la recopilación de eventos de forma completa en tu entorno.

Si no quieres liarte con la parte manual, Defender for Identity ofrece una opción de auditoría automática de Windows que comprueba la configuración existente cada 24 horas, detecta huecos y aplica las modificaciones necesarias de forma automática sobre los controladores de dominio.

Auditoría automática vs configuración manual

La llamada auditoría automática de Windows dentro de Defender for Identity se encarga de varias tareas que, si no, tendrías que realizar a mano en GPO o en la directiva local del controlador de dominio. Entre otras cosas, revisa la auditoría avanzada de servicios de directorio, la auditoría NTLM, la auditoría de objetos de dominio, la configuración de AD FS y la directiva de auditoría de Windows propiamente dicha.

El sensor de Defender for Identity modifica SACL en el objeto raíz del dominio para registrar cambios relevantes de directorio, actualiza valores de registro para la auditoría NTLM (incluyendo el registro del evento 8004), añade entradas de auditoría en el contenedor de configuración de AD FS y ajusta las directivas de auditoría locales utilizando las APIs de la LSA de Windows.

Además, esta función aplica la configuración de auditoría directamente sobre la directiva de sistema local de los controladores de dominio, envía alertas de estado si detecta configuraciones incorrectas y vuelve a comprobarlo todo cada 24 horas. En muchos entornos es la forma más sencilla de garantizar que la auditoría mínima necesaria está activa sin tener que ir tocando GPO una a una.

Para habilitarla basta con ir al portal de Microsoft Defender, entrar en la sección de Configuración > Identidades > Características avanzadas y activar la opción de configuración de auditoría automática de Windows. Aun así, conviene validar después con el informe de configuración y con herramientas como auditpol.exe que todo se ha aplicado como esperabas.

Si prefieres el enfoque tradicional, siempre puedes optar por configurar manualmente toda la auditoría: directivas avanzadas, SACL en objetos clave de AD, políticas de NTLM, auditoría de AD FS, AD CS, Microsoft Entra Connect y equipos que hagan funciones de servidor de archivos o contención de datos sensibles.

Configurar la auditoría avanzada en controladores de dominio

La pieza central de una buena auditoría suele estar en los controladores de dominio (consulta seguridad avanzada en Windows Server). Desde ellos se gobierna el acceso, la creación de cuentas, los cambios en grupos privilegiados y la mayoría de acciones críticas en Active Directory. Por eso, la directiva de auditoría avanzada (Premium) aplicada a la OU de Domain Controllers es tan relevante.

Para configurarla, se inicia sesión como administrador de dominio en un controlador, se abre el Editor de administración de directiva de grupo y se edita la GPO que aplique a los controladores de dominio (por ejemplo, la Directiva predeterminada de controladores de dominio o una GPO nueva específica para seguridad).

Dentro de la rama de configuración del equipo hay que ir a Configuración de Windows > Configuración de seguridad > Configuración de directiva de auditoría avanzada > Directivas de auditoría. Ahí se habilitan las subcategorías adecuadas y se marcan los eventos de éxito y error donde corresponda.

Algunas subcategorías clave son: Auditar validación de credenciales (evento 4776), distintas opciones de auditoría de administración de cuentas (creación y borrado de cuentas de equipo, grupos de distribución y grupos de seguridad con eventos como 4741, 4743, 4728, 4729, 4730, 4732, 4733, 4756, 4757, 4758 y 4726), auditoría de cambios del servicio de directorio (5136), auditoría de extensiones del sistema de seguridad (7045) y acceso al servicio de directorio (4662).

Después de aplicar los cambios en la GPO, se fuerza la actualización con gpupdate en los controladores de dominio y se comprueba en el Visor de eventos, en el registro de Seguridad, que los nuevos IDs de evento se están generando correctamente. En caso de duda, el comando auditpol.exe /get /category:* te muestra el estado real de la auditoría avanzada a nivel de equipo.

Es importante recordar que, para algunos eventos como el 4662, no basta con habilitar la subcategoría: hace falta configurar SACL específicas en los objetos de dominio para que esos accesos y cambios queden registrados.

Auditoría NTLM y evento 8004

La autenticación NTLM sigue presente en muchos entornos legados, y desde el punto de vista de seguridad conviene vigilar qué equipos se autentican mediante NTLM, hacia dónde y en qué condiciones. Microsoft Defender for Identity utiliza el evento 8004 para enriquecer la visibilidad de actividades relacionadas con NTLM.

Para activar esta auditoría se utilizan GPO que modifican las opciones de seguridad relacionadas con NTLM. Concretamente, se suelen ajustar las directivas «Seguridad de red: Restricción de NTLM: tráfico NTLM saliente a servidores remotos» a «Auditar todo», «Seguridad de red: Restricción de NTLM: Auditar la autenticación NTLM en este dominio» a «Habilitar todo» y «Seguridad de red: Restringir NTLM: Auditar el tráfico NTLM entrante» para que registre las autenticaciones de todas las cuentas.

Estas opciones se encuentran en la rama de Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Directivas locales > Opciones de seguridad. Una vez establecido el valor de auditoría, los controladores de dominio comienzan a generar el evento 8004 cuando se usan autenticaciones NTLM, lo que permite correlacionar esas acciones con el resto de la telemetría de seguridad.

Controlar bien NTLM es especialmente útil para detectar aplicaciones antiguas o configuraciones heredadas que siguen tirando de NTLM en lugar de Kerberos y que pueden abrir la puerta a ataques de relay o a movimientos laterales discretos.

Auditoría de objetos de dominio y configuración

Si lo que te preocupa es saber quién cambia usuarios, grupos, equipos u otros objetos de Active Directory, además de las directivas de auditoría hay que tocar la SACL en el propio directorio. Esto se hace generalmente desde la consola de Usuarios y equipos de Active Directory, activando las características avanzadas para ver la pestaña Seguridad.

El procedimiento típico consiste en seleccionar el dominio, abrir sus Propiedades > Seguridad > Opciones avanzadas > pestaña Auditoría y añadir una entrada de auditoría para «Todos» (Everyone), ajustando el tipo (Correcto/Todo), el alcance (por ejemplo, «Objetos de usuario descendientes» o «Este objeto y todos los objetos descendientes») y los permisos a auditar.

Una práctica habitual es marcar inicialmente Control total y luego desmarcar los permisos de lectura (contenido de lista, leer todas las propiedades, permisos de lectura), dejando activos principalmente los permisos de escritura y modificación que interesan desde el punto de vista de seguridad. Esta configuración provoca que, cuando se modifican objetos relevantes, se generen eventos como el 4662 con la información necesaria.

Este mismo enfoque se puede repetir para distintos tipos de objetos: grupos, equipos, cuentas de servicio administradas (msDS-GroupManagedServiceAccount, msDS-ManagedServiceAccount, msDS-DelegatedManagedServiceAccount) y cualquier otro contenedor crítico. De esta forma, los cambios se reflejan de manera sistemática en los registros de seguridad de los controladores de dominio.

El mismo tipo de SACL se aprovecha cuando hay servicios adicionales en el entorno, como AD FS o Microsoft Exchange, donde existen contenedores de configuración específicos que también conviene auditar, especialmente en organizaciones con alta exposición a Internet o con un fuerte uso de federación.

Auditoría en AD FS, AD CS y Microsoft Entra Connect

Servicios como Active Directory Federation Services (AD FS), Active Directory Certificate Services (AD CS) o Microsoft Entra Connect también se apoyan en eventos de auditoría para ofrecer una visión completa del estado de la identidad y del acceso. Cada uno requiere su propia combinación de GPO y configuraciones locales.

En el caso de AD FS, se suele crear una GPO dirigida a los servidores de AD FS en la que se habilita, dentro de la configuración de directiva de auditoría avanzada, la auditoría de acceso a objetos mediante la opción «Auditar aplicación generada» con éxito y error. Paralelamente, en la consola de Administración de AD FS, se habilitan las casillas de auditorías correctas y de errores dentro de las propiedades del servicio de federación.

Para que los sensores que se ejecutan en los servidores de AD FS tengan la máxima visibilidad, se recomienda ajustar el nivel de auditoría a Verbose mediante el cmdlet Set-AdfsProperties -AuditLevel Verbose, lo que aumenta el detalle de los eventos generados para ese servicio.

En el caso de AD CS, se crea otra GPO específica para los servidores de certificados donde se habilita la auditoría de servicios de certificación dentro de las directivas de auditoría avanzada, marcando igualmente éxito y error. Adicionalmente, se puede recurrir a la herramienta certutil para ajustar el filtro de auditoría de la CA mediante comandos como certutil -setreg CA\AuditFilter 127 y reiniciando el servicio de certificados.

Por su parte, en los servidores de Microsoft Entra Connect (antes Azure AD Connect), lo mínimo recomendable suele ser habilitar la auditoría de inicio de sesión y cierre de sesión (logon/logoff) para ver quién y cuándo accede a estos nodos tan críticos en el flujo de sincronización de identidades. Esto también se hace vía GPO, activando las correspondientes subcategorías de auditoría avanzada de inicio de sesión.

Auditoría de acceso a archivos y carpetas con GPO y SACL globales

Otra necesidad muy común es auditar el acceso a ficheros y carpetas sensibles en servidores de archivos o incluso en estaciones de trabajo. Aquí entran en juego tanto la directiva de auditoría de acceso a objetos como las SACL a nivel de sistema de archivos.

En un ejemplo típico, podrías querer auditar los accesos a una carpeta «Documentos financieros» alojada en un servidor de archivos. Para ello se configura primero la directiva de acceso a objetos global en una GPO aplicada a servidores de archivos, habilitando «Auditar sistema de archivos» con éxito y error, y luego se define una auditoría global de acceso a objetos en la sección «Sistema de archivos».

Dentro de esta política global se añade una entrada de auditoría para «Todos» con Control total y, si se usa clasificación de recursos o acceso central, se puede incluso condicionar la auditoría a atributos del recurso, por ejemplo que el departamento del recurso sea «Finanzas». En ese contexto, cualquier intento de acceso (correcto o fallido) a esos recursos clasificados generará eventos de seguridad relevantes (por ejemplo, 4656 y 4663).

Este enfoque tiene la ventaja de que, aunque no se haya configurado una SACL explícita en cada carpeta o fichero, la auditoría global se encarga de capturar la información necesaria. Lo único que hay que hacer después es actualizar la política con gpupdate /force en el servidor de archivos y comprobar en el Visor de eventos que las operaciones sobre los documentos se registran como se espera.

A nivel de estaciones de trabajo, mucha gente se plantea cómo auditar, por ejemplo, una carpeta C:\\Test en todas las máquinas del dominio. La manera más limpia no es hacerlo una a una, sino definir la SACL vía GPO o usar plantillas de seguridad y scripts que apliquen esos permisos de auditoría de forma masiva, evitando utilizar cuentas de administrador de dominio para tareas rutinarias en cada puesto.

Supervisión de cambios en GPO y herramientas como Semperis DSP

Los GPO en sí mismos son un activo muy sensible: controlan políticas de seguridad, requisitos de contraseña, asignación de derechos de usuario, desactivación de antivirus, restricciones de inicio de sesión y mucho más. Un cambio malintencionado o un error de configuración en el GPO equivocado puede abrir un agujero enorme en la seguridad del dominio.

Herramientas como Semperis Directory Services Protector (DSP) se apoyan en los eventos de auditoría de Active Directory para ofrecer una vista clara de los cambios de GPO. Por ejemplo, pueden detectar si alguien con permisos de edición sobre un GPO ha utilizado utilidades como SharpGPOAbuse para añadir silenciosamente un usuario a Administradores locales a través de la Default Domain Policy.

Estas soluciones permiten comparar versiones anteriores y actuales de un GPO, visualizar exactamente qué se ha modificado (por ejemplo, deshabilitar Microsoft Defender Antivirus, quitar restricciones de inicio de sesión o alterar parámetros de refuerzo) y levantar alertas o notificaciones automáticas cuando esas modificaciones se producen.

La gracia está en que se pueden crear reglas de notificación personalizadas asociadas a GPO especialmente críticos (por ejemplo, los que afectan a servidores de nivel 0, controladores de dominio o servidores de aplicaciones sensibles), de forma que cualquier cambio dispare un correo electrónico o una alerta hacia tu equipo de seguridad.

Además de alertar, DSP y herramientas similares permiten revertir la configuración de un GPO a una versión anterior conocida buena, lo que facilita deshacer cambios sospechosos o errores de administración sin tener que reconstruir a mano toda la política. Esto, por supuesto, se apoya en que la auditoría de cambios en Active Directory y GPO esté bien configurada desde el principio.

Escenarios híbridos: centralizar auditoría en AWS con CloudWatch y OpenSearch

En entornos híbridos donde parte de la infraestructura de Active Directory está on-premises y parte en la nube, es habitual que se busque una plataforma centralizada para recopilar y analizar eventos de auditoría. Un ejemplo típico es el uso de servicios de AWS como Managed Microsoft AD, Amazon FSx para Windows File Server y Amazon OpenSearch.

En estos escenarios, se parte de un bosque de Active Directory local (con algún controlador de dominio en Amazon EC2 si se extiende al cloud) más un directorio administrado de AWS (Managed Microsoft AD) y volúmenes de archivos en Amazon FSx configurados para integrarse con ese directorio.

El primer paso sigue siendo configurar correctamente la auditoría en el dominio local: crear GPO que habiliten las categorías de eventos necesarias (servicio de directorio, acceso a objetos, cambios críticos en cuentas y grupos), aplicar SACL en el árbol de AD mediante ADSIEdit y asegurarse de que los controladores de dominio generan los eventos pertinentes.

Después se despliega y configura el agente de CloudWatch en los controladores de dominio y otros servidores relevantes para reenviar tanto eventos de Windows como métricas al servicio CloudWatch Logs de AWS. Ese agente se configura con un archivo JSON donde se define qué registros, categorías y eventos se van a enviar y a qué región de AWS.

Una vez en CloudWatch Logs, se configura el reenvío de esos logs hacia Amazon OpenSearch Service. Normalmente esto se hace mediante una función AWS Lambda generada automáticamente (con nombres tipo LogsToElasticSearch_loquesea) que actúa como etapa ETL: recibe eventos, los procesa, extrae la información relevante (quién, cuándo, qué, dónde) y los indexa en OpenSearch en un formato homogéneo y optimizado.

Esta función suele necesitar un pequeño ajuste extra: leer un archivo JSON de configuración que describa cómo mapear los distintos tipos de eventos de Windows (que llegan en XML) a los campos del índice final (por ejemplo, @source, @action, @timestamp, usuario, máquina de origen, etc.) y descartar información redundante que no aporte a la auditoría ni al cumplimiento normativo.

Visualización de logs de auditoría con OpenSearch Dashboards

Una vez que los eventos de auditoría están llegando a un índice en Amazon OpenSearch Service, lo normal es construir visualizaciones y paneles de control que permitan interpretar esos datos sin volverse loco. Para ello se utiliza OpenSearch Dashboards (antes Kibana) y se crean patrones de índice, gráficos y listados.

El flujo básico consiste en definir un index pattern (por ejemplo, auditlog*) indicando el campo de tiempo @timestamp, y a partir de ahí crear visualizaciones circulares, de barras, de líneas o tablas, según el tipo de análisis que quieras hacer. En un gráfico circular típico puedes segmentar por origen (@source.keyword) y tipo de acción (@action.keyword) para ver qué fuentes generan más actividad y de qué tipo.

En la parte de Discover puedes elegir los campos que quieres ver (cuentas, equipos, tipo de operación, resultado, origen de red, etc.) y filtrar o excluir valores para centrarte sólo en lo que te interesa: por ejemplo, inicios de sesión fallidos en controladores de dominio, cambios en miembros de grupos privilegiados o accesos a carpetas sensibles en FSx.

La gran ventaja de este enfoque es que concentras la auditoría de un entorno mixto (on-premises y nube) en un único panel, sin necesidad de ir entrando en cada servidor a revisar su Visor de eventos. Además, puedes conservar los datos durante el tiempo que te exijan las normativas internas o externas, dimensionando el clúster de OpenSearch y el volumen de almacenamiento según tus necesidades.

Eso sí, como estos servicios no son gratuitos, es recomendable mapear cuidadosamente los recursos creados (dominio Managed AD, FSx, OpenSearch, instancias EC2, funciones Lambda, etc.) para poder eliminarlos cuando termine la prueba de concepto y así evitar costes innecesarios.

Mejoras puntuales: mostrar el último inicio de sesión y errores de logon

Más allá de la auditoría formal, hay pequeños ajustes de Directiva de Grupo que ayudan a detectar comportamientos sospechosos de un vistazo. Un ejemplo muy práctico es la opción de mostrar al usuario, durante el inicio de sesión interactivo, cuándo fue su último inicio de sesión correcto y cuántos intentos fallidos se han producido desde entonces.

Esta configuración se habilita en una GPO y se aplica normalmente a controladores de dominio o servidores con información muy sensible, no a todo el parque de equipos. En la rama de configuración del equipo, dentro de las plantillas administrativas de Windows Components > Windows Logon Options, se puede activar la directiva «Display information about previous logons during user logons».

Una vez aplicada la GPO y forzada la actualización, tras el siguiente logon se mostrará un mensaje indicando que es la primera vez que se inicia sesión (en ese contexto de auditoría). En inicios posteriores aparecerá un aviso con la fecha y hora del último inicio de sesión correcto y, si ha habido intentos de acceso fallidos, el número de dichos intentos en un formato muy visible (con texto destacado) para que el usuario y el administrador sepan que alguien ha estado probando credenciales.

Hay que tener claro que esto no sustituye a la auditoría de seguridad como tal, pero funciona como una capa adicional de visibilidad para máquinas concretas. Además, sólo aplica a inicios de sesión interactivos con teclado, no a conexiones de red o Escritorio remoto, por lo que su impacto en la experiencia de usuario y la operativa diaria es muy bajo.

En combinación con los eventos de auditoría de seguridad estándar (4624, 4625, etc.), esta función ayuda a reforzar la concienciación y a detectar con rapidez si alguien está intentando forzar credenciales en un servidor clave.

Al final, todo lo visto gira alrededor de una misma idea: definir bien qué quieres auditar, configurarlo mediante Local Group Policy o GPO de forma consistente y centralizar el análisis de los eventos. Con las directivas de auditoría avanzadas correctamente configuradas, SACL bien pensadas en objetos y sistemas de archivos, herramientas como Defender for Identity o soluciones tipo DSP monitorizando cambios y plataformas como AWS OpenSearch centralizando los logs, se consigue un equilibrio razonable entre visibilidad, rendimiento y capacidad real de respuesta ante incidentes.