auditoria AD de privilegios sensibles: fallos y éxitos

¿Qué es la auditoría AD de privilegios sensibles?

La auditoria AD de privilegios sensibles es una comprobación de visibilidad por host: ¿registra Windows las solicitudes de privilegios sensibles en cada controlador de dominio, servidor miembro o estación de trabajo del alcance? Una exportación de GPO del dominio puede sugerir una respuesta, pero las pruebas necesarias para cerrar la revisión son la directiva de auditoría que informa el host de destino y los eventos que llegan a la plataforma de supervisión.

Esta guía se comprobó el 4 de octubre de 2026 con Microsoft Learn y el commit del código fuente de etc-collector 20268a321609c193b79c5da6764f3f56950449cb. Su punto de partida es una limitación concreta: el control de EtcSec AUDIT_PRIVILEGE_USE_DISABLED acepta únicamente Failure. Por tanto, un resultado sin hallazgos contabilizados no demuestra que estén habilitados tanto Success como Failure.

Microsoft recomienda ambos resultados para esta subcategoría en controladores de dominio, servidores miembros y estaciones de trabajo. Success registra los intentos correctos; Failure registra los intentos fallidos. Consulte la recomendación de Microsoft para Sensitive Privilege Use. Revise su configuración de referencia aprobada y documente las excepciones, en lugar de tratar el umbral del producto como el requisito completo de la directiva.

Cómo funciona la verificación

Comience con los equipos que pretende cubrir. Enumere los controladores de dominio, los servidores miembros pertinentes y las estaciones de trabajo privilegiadas, junto con el responsable de la directiva de cada conjunto. Una consulta correcta en un DC no demuestra el estado de otro DC ni de un servidor miembro. Registre la identidad del host y la hora de observación junto a cada resultado.

La distinción entre configuración y estado del host se explica en nuestra guía para comparar la configuración de auditoría de las GPO con los ajustes efectivos del host. Ese artículo se centra en Account Logon, Account Management y Policy Change. Aquí la decisión afecta al bit Success de Sensitive Privilege Use y a la telemetría que se deriva de él.

La verificación consta de tres puntos de validación. Primero, identifique la configuración de referencia esperada y cualquier excepción aprobada. Segundo, consulte la directiva de auditoría del sistema en el host real. Tercero, relacione los eventos locales pertinentes con sus copias centrales y verifique los campos que necesita un analista. Cierre cada punto con sus propias pruebas: la aprobación de una excepción no sustituye una comprobación de recopilación fallida, y un registro de eventos con datos no sustituye la consulta de la directiva.

Cuando las pruebas discrepen, conserve esa discrepancia. Por ejemplo, una GPO recopilada puede contener solo Failure mientras que un host informa de ambos resultados. El siguiente paso útil es identificar cómo se administra ese host y si el estado es duradero. Cambiar una GPO únicamente para que una exportación parezca coherente puede eliminar un ajuste local legítimo o dejar sin resolver el verdadero problema de configuración.

Detección: leer la directiva en cada host

Ejecute la siguiente consulta de solo lectura en cada destino, con una cuenta autorizada para leer su directiva de auditoría. Estos comandos aplican la sintaxis por nombre o GUID documentada en la referencia de Microsoft de auditpol get; se comprobaron con esa referencia, sin ejecutarlos en un entorno AD para este artículo.

auditpol /get /subcategory:"Sensitive Privilege Use"

En hosts con otro idioma de visualización, consulte mediante el GUID de Sensitive Privilege Use documentado por Microsoft, que también utiliza el recopilador:

auditpol /get /subcategory:"{0cce9228-69ae-11d9-bed3-505054503030}" /r

Sin /user, auditpol consulta la directiva del sistema. Conserve la salida, el host, la marca de tiempo, el comando y cualquier error. Un error de permisos es un resultado desconocido que requiere acceso autorizado; no indica que la directiva esté deshabilitada. Investigue por separado la directiva por usuario cuando sea pertinente para una cuenta concreta o un resultado de evento inesperado.

Mantenga el resultado de la directiva separado de la muestra de eventos. Los eventos antiguos pueden persistir tras un cambio de directiva, por lo que un evento observado antes de la consulta no demuestra el ajuste actual. A la inversa, una ventana de observación sin actividad puede no contener ninguna operación pertinente. Registre la ventana y la actividad esperada antes de decidir si la ausencia de eventos indica un problema de generación o de recopilación.

Detección: validar 4673/4674 a través de la cadena de recopilación

Microsoft documenta 4673 como una llamada a un servicio privilegiado y 4674 como un intento de operación sobre un objeto privilegiado. Ambos también pueden pertenecer a Non Sensitive Privilege Use. Examine el privilegio y el contexto de la operación; el número de evento por sí solo no identifica la subcategoría sensible.

Utilice esta consulta local del registro Security para examinar el XML. Aplica las opciones de consulta, orden inverso y formato de salida de la referencia de Microsoft de wevtutil:

wevtutil qe Security /q:"*[System[(EventID=4673 or EventID=4674)]]" /rd:true /f:xml

Elija una ventana de observación delimitada y adecuada para su revisión al buscar en el sistema central. Relacione los registros locales con sus copias recibidas mediante la identidad del host, la hora, el ID de evento y el ID de registro cuando se conserve. Verifique la normalización del resultado de auditoría y de los nombres de privilegios realizada por el conector frente al XML original, especialmente cuando la vista central combine campos o elimine valores vacíos.

La guía complementaria sobre recopilación central de eventos y validación de analizadores respalda este trabajo de transporte y correspondencia de campos. Conserve un ejemplo de cada tipo de evento pertinente realmente observado. Si no dispone de un ejemplo requerido, documente el caso no probado en lugar de afirmar que la cobertura es completa.

Esa distinción aparece explícitamente en la documentación de Microsoft de 4672. Utilice 4672 por su contexto de inicio de sesión, manteniendo separadas las comprobaciones de generación y reenvío de 4673/4674. Evalúe las cuentas, los privilegios y los procesos inesperados frente a la actividad administrativa aprobada antes de escalar un evento como posible abuso.

Corrección: verificar Failure y Success tras el despliegue (Remediation)

1. Corregir la subcategoría administrada

Cuando la configuración de referencia aprobada exija ambos resultados, configure Audit Sensitive Privilege Use en Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Privilege Use. Seleccione Success y Failure en la GPO o el sistema de configuración que realmente administra el conjunto de equipos de destino.

Documente el responsable del cambio, los hosts de destino, la lista de excepciones, la configuración anterior y la decisión de reversión. Pruebe el cambio en equipos representativos antes de extenderlo al resto del alcance. El despliegue debe seguir el conjunto de hosts y los límites de administración identificados, sin suponer que todos los equipos pertinentes están controlados por la misma directiva predeterminada.

2. Comprobar la prioridad frente a la auditoría heredada y volver a leer el estado del host

Revise Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Microsoft recomienda mantener este ajuste habilitado y documenta que SCENoApplyLegacyAuditPolicy impide aplicar la directiva a nivel de categoría. Consulte la referencia de Microsoft de la directiva de prioridad frente a la auditoría heredada al conciliar los ajustes de auditoría básicos y avanzados.

Una vez que el cambio administrado haya llegado a cada host, repita la consulta auditpol basada en GUID anterior. Compare las salidas antes y después. Si un host sigue presentando diferencias, investigue la fuente de administración aplicable y el procesamiento de la directiva; no declare completada la corrección solo por lo que muestra el editor de GPO.

3. Mantener Backup/Restore como una decisión independiente

La auditoría del uso de los privilegios Backup y Restore depende además de Audit: Audit the use of Backup and Restore privilege. Microsoft desaconseja habilitar ese ajuste independiente porque puede producir un volumen considerable de eventos. No lo habilite en todas partes como atajo para cerrar esta revisión. Registre la visibilidad requerida, la carga de trabajo, la capacidad operativa y la decisión del responsable para cualquier excepción a esa recomendación.

4. Confirmar la recepción antes de cerrar la revisión

Vuelva a comprobar la generación local y el análisis central tras el despliegue mediante una actividad aprobada y controlada, pertinente para el privilegio previsto. Acuerde el evento esperado con el responsable de supervisión antes de la prueba. Una acción administrativa genérica no garantiza que aparezcan ambos ID de evento ni ambos resultados.

Si existen eventos locales pero faltan sus copias centrales, investigue la suscripción de reenvío, los filtros del agente, los errores de ingesta y la configuración del analizador. Si faltan los eventos locales, verifique primero la operación, el ajuste de auditoría y la ventana de observación. Son fallos diferentes con responsables distintos. Fije una fecha de seguimiento para los casos sin resolver y vuelva a comprobarlos después de reconstruir hosts o cambiar la directiva que los administra.

Cómo detecta EtcSec este problema

En el commit del código fuente revisado aquí, AUDIT_PRIVILEGE_USE_DISABLED lee advancedAuditLevel. Esta función auxiliar utiliza un mapa seleccionado de GPO de auditoría avanzada o recurre a los datos heredados de EventAudit. Con un valor conocido inferior a 2, el detector emite un hallazgo de gravedad Medium con Count 1. El valor 2 significa solo Failure y el valor 3 significa Success y Failure: ambos superan su umbral. Este detector no exige Success.

Cuando ninguna de las dos fuentes seleccionadas proporciona el ajuste, ok=false devuelve Count 0, conserva la gravedad Medium inicializada e incluye detalles que explican que no está configurado mediante GPO. La directiva efectiva del host sigue siendo desconocida; esto no prueba ni el cumplimiento ni la deshabilitación de la auditoría.

La selección de fuentes tiene otras limitaciones:

• La selección de auditoría avanzada da prioridad a Default Domain Controllers Policy, después a Default Domain Policy y luego a la primera entrada disponible del mapa. La selección de EventAudit heredado da prioridad a Default Domain Policy, después a Default Domain Controllers Policy y luego a la primera entrada disponible. Estas prioridades difieren.
• La ausencia de una subcategoría en el mapa avanzado seleccionado no desencadena una búsqueda en otros mapas avanzados. La función auxiliar puede recurrir en su lugar a la categoría heredada seleccionada.
• El proveedor SMB ignora los fallos de lectura de GptTmpl.inf y audit.csv durante la recopilación de directivas. Una sección EventAudit que contenga otro campo puede dejar el campo Privilege Use ausente con su valor cero.
• El analizador de audit.csv extrae pares GUID/valor; no acredita que una directiva se haya aplicado a un host ni conserva un registro completo de la procedencia de su aplicación.

Esta ruta no calcula el Windows Resultant Set of Policy ni tiene plenamente en cuenta SCENoApplyLegacyAuditPolicy. Tampoco demuestra la generación, el reenvío ni el análisis de eventos. Utilice el hallazgo para priorizar la investigación y cierre después la revisión con la salida auditpol de cada host y las pruebas de recopilación.

Registro de revisión

Conserve la decisión sobre la configuración de referencia, el inventario de hosts del alcance, la salida de la directiva por host, las excepciones aprobadas, la comparación antes/después y las muestras de eventos locales relacionadas con sus copias centrales. Asigne un responsable a cada resultado desconocido. La revisión se completa cuando cada host del alcance dispone de un resultado documentado y se ha verificado la telemetría requerida, con cualquier excepción pendiente aceptada explícitamente por su responsable.