Verificación de políticas App Control: WDAC más allá del marcador GPO

¿Qué es la verificación de políticas App Control?

La verificación de políticas App Control establece qué políticas App Control for Business tiene un dispositivo Windows, cómo llegaron a él y si su comportamiento observado coincide con las reglas de aplicaciones aprobadas. Un objeto de directiva de grupo (GPO) que contiene una ruta de despliegue describe la intención de configuración. No demuestra que el destino haya obtenido el binario, cargado la versión prevista o aplicado la política.

Para un equipo de Active Directory que investiga un hallazgo de despliegue de WDAC, el resultado útil es un registro de evidencias específico de cada dispositivo. Identifique la política y al responsable de su distribución, pruebe los flujos de trabajo requeridos en modo auditoría, revise las reglas propuestas y apruebe la aplicación con una vía de recuperación. Mantenga visibles los dispositivos inaccesibles y las mediciones ausentes como casos sin resolver.

Esta guía utiliza documentación de Microsoft Learn consultada el 4 de octubre de 2026 y la implementación del colector identificada más abajo. Los comandos son ejemplos documentados para un administrador de Windows autorizado; no se ejecutaron en un parque Windows para este artículo. No se afirma ningún despliegue satisfactorio, cobertura de dispositivos, exposición a CVE ni cumplimiento de ANSSI.

Nuestra guía de integridad de memoria HVCI explica el aislamiento en memoria de la integridad del código del kernel y la compatibilidad de los controladores. Este procedimiento verifica las políticas de autorización de aplicaciones, su formato y sus eventos. Registre ambas protecciones cuando corresponda, con evidencias independientes para cada una.

Cómo funciona: el formato de la política debe corresponder a su distribución

El procedimiento de despliegue mediante GPO de Microsoft admite únicamente el formato de política única. Su ajuste se encuentra en Computer Configuration → Administrative Templates → System → Device Guard → Deploy App Control for Business. El ajuste habilitado indica una ruta de despliegue local o UNC; un recurso compartido debe ser accesible para las cuentas de equipo. El procedimiento termina con el reinicio de un equipo de prueba.

La misma página indica a los administradores que despliegan una nueva política base firmada con la integridad de memoria habilitada que utilicen el despliegue mediante scripts y la activen mediante un reinicio. No sustituya esa instrucción por una actualización en caliente simplemente porque una herramienta de administración la ofrezca. El procedimiento mediante scripts de Microsoft identifica el caso afectado de Windows 11 anterior a 24H2 y las copias necesarias en las ubicaciones del sistema y EFI, seguidas de un reinicio. Compruebe la compilación de destino y el procedimiento correspondiente antes de elegir un mecanismo de activación.

La descripción general del despliegue de Microsoft distingue el XML con un PolicyID para el formato de múltiples políticas del caso de política única. Describe la conversión a binario y el despliegue mediante MDM, Configuration Manager, scripts o Group Policy. La ausencia de un marcador GPO no permite descartar estos otros métodos de distribución.

Antes de modificar nada, cree un registro para cada población piloto:

Estos campos son una propuesta de registro de investigación, no mediciones de un entorno de cliente. Resuelva las responsabilidades ausentes antes de emitir cambios: un administrador debe poder explicar qué fuente distribuirá la siguiente versión y qué operador podrá retirarla.

Detección: inventariar el destino y correlacionar los eventos

Paso 1: identificar las políticas en el dispositivo piloto

La referencia técnica de CiTool documenta --list-policies, con el alias -lp, como un listado de políticas tanto activas como inactivas. CiTool se incluye a partir de Windows 11 22H2 y Windows Server 2025. En un destino compatible, conserve la salida completa:

CiTool --list-policies

La salida documentada incluye Policy ID, Base Policy ID, nombre descriptivo, versión, estado de firma, presencia del archivo y estado de activación. Compare las identidades y versiones con el artefacto aprobado. La referencia define Is Currently Enforced como la indicación de si el archivo de política está activo; no utilice solo esa etiqueta para decidir si sus opciones de reglas están en modo Audit o Enforcement.

Para los sistemas donde esa herramienta no esté disponible, utilice el procedimiento de despliegue correspondiente al sistema operativo y los artefactos de política conservados. Un comando no disponible es una limitación del inventario, no una prueba de que App Control esté ausente. Distinga una recopilación fallida de un inventario correcto sin la política esperada.

Paso 2: leer los registros correctos

En el Visor de eventos, examine Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational y Applications and Services Logs → Microsoft → Windows → AppLocker → MSI and Script. La referencia de eventos de Microsoft documenta estas señales:

El registro MSI and Script no está disponible en Windows Server Core. App Control tampoco suele registrar cada binario permitido. Por tanto, unos registros sin actividad no constituyen un inventario completo de ejecución ni una prueba de que todas las aplicaciones estén autorizadas.

Conserve los detalles de los eventos con el dispositivo, la hora, la identidad de la política cuando se proporcione, las opciones observadas y el flujo de trabajo probado. Compare la observación de la política cargada con la identidad, versión y modo previstos. Investigue los identificadores inesperados y explique cualquier cambio de versión antes de atribuir actividad posterior al despliegue.

Paso 3: probar el trabajo requerido en modo auditoría

Ejecute los flujos autorizados de instalación, inicio, actualización y administración en el piloto. Pida a los responsables de aplicaciones que identifiquen las dependencias y los resultados esperados. Registre lo que se probó realmente; una máquina inactiva aporta pocas evidencias de compatibilidad. Conserve las lagunas de recopilación y los límites de retención de registros junto con la revisión.

Nuestra guía de reglas Defender ASR mediante GPO compara los GUID, las acciones y las exclusiones de reglas de comportamiento con la configuración de los dispositivos. Aquí, la revisión se refiere a la identidad y el formato de la política App Control y a las decisiones sobre binarios y scripts. Una observación de configuración ASR no puede cerrar esta investigación de App Control.

Remediación: revisar las evidencias de auditoría antes de la aplicación (Remediation)

Paso 1: aprobar un piloto recuperable

Designe al responsable del despliegue, al aprobador de las reglas de aplicaciones y al operador de recuperación. Defina qué dispositivos entran en el piloto, qué flujos de trabajo deben completarse correctamente y qué fallos detienen la ampliación. Pregunte explícitamente: qué formato y método de distribución se utilizan, si las nuevas bases firmadas se combinan con integridad de memoria y quién aprueba las excepciones y la reversión.

Microsoft recomienda anillos de despliegue y evaluación en auditoría antes de la aplicación en su descripción general del despliegue. Elija el método a partir del registro de sistema operativo, formato y firma anterior. Conserve los artefactos previos y un procedimiento de recuperación probado antes de distribuir la versión candidata.

Paso 2: generar propuestas y revisar después cada regla

El flujo de trabajo con eventos de auditoría de Microsoft requiere una política en modo auditoría ya desplegada. Ejecute su comando documentado en una sesión de PowerShell elevada para generar reglas candidatas a partir de los eventos de auditoría:

$EventsPolicy=$env:userprofile+"\Desktop\EventsPolicy.xml"
$EventsPolicyWarnings=$env:userprofile+"\Desktop\EventsPolicyWarnings.txt"
New-CIPolicy -FilePath $EventsPolicy -Audit -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat 3> $EventsPolicyWarnings

Este ejemplo produce el formato de múltiples políticas; no es un binario que pueda desplegarse mediante el ajuste GPO de política única. Revise el XML generado y las advertencias. Conserve solo las reglas para aplicaciones, binarios y scripts aprobados y después fusiónelas en la política base o utilice una política suplementaria permitida. Los archivos que ya no están en disco no reciben reglas generadas automáticamente mediante este proceso.

Vuelva a ejecutar los flujos de trabajo requeridos una vez desplegada la política de auditoría revisada. Mantenga prohibida la actividad no permitida; un evento de auditoría no es una instrucción para confiar en su origen. Investigue los eventos sin explicación y las advertencias sin resolver antes de avanzar.

Paso 3: preparar el artefacto de aplicación

El procedimiento de aplicación de Microsoft parte de políticas de auditoría revisadas. Copia el XML de auditoría en un archivo de aplicación independiente y permite cambiar opcionalmente la identidad de la política para un despliegue en paralelo. Decida de forma deliberada si sustituirá la política existente o usará una identidad nueva; las relaciones con políticas suplementarias deben seguir esa elección.

Con $EnforcedPolicyXML apuntando a la copia preparada, el cambio de modo documentado es:

Set-RuleOption -FilePath $EnforcedPolicyXML -Option 3 -Delete

El mismo procedimiento recomienda considerar las opciones 9 y 10 para el primer anillo de aplicación: una opción previa al arranque para desactivar la aplicación durante una sesión de arranque y un retorno al modo auditoría cuando se bloquea un controlador crítico para el arranque. Convierta el XML revisado a binario, aplique el proceso de firma requerido y despliegue mediante el método compatible elegido. Conserve la identidad del artefacto y el modo esperado en el registro de cambios.

Tras la activación, repita el inventario, la revisión de la política cargada y las pruebas funcionales. Examine los eventos de aplicación frente a las expectativas aprobadas. Avance al siguiente anillo solo después de que los revisores designados acepten las evidencias, las excepciones y la preparación para la recuperación; la edición de la GPO en sí no es el criterio de cierre.

Paso 4: probar la retirada y la recuperación

El procedimiento de eliminación de políticas de Microsoft exige primero desactivar el método de distribución para que la política no vuelva a desplegarse. Para una base firmada, despliegue un reemplazo firmado con la opción 6, el mismo PolicyId, una versión igual o superior y una sección UpdatePolicySigners. Fírmelo con un certificado incluido en la sección UpdatePolicySigners de la política original y reinicie antes de eliminarlo. No suponga que una eliminación local retira una base firmada de forma segura.

En un sistema compatible, tras cumplir esos requisitos previos, ejecute el ejemplo de eliminación documentado desde una ventana de comandos elevada:

CiTool.exe -rp "{PolicyId GUID}" -json

Sustituya el marcador de posición por el identificador de política aprobado. Los requisitos de reinicio varían según la versión de Windows y la firma de la política; utilice el procedimiento enlazado para el destino. El procedimiento operativo también debe cubrir un dispositivo que no arranca, el acceso autorizado al firmware y la disponibilidad de claves de recuperación. Pruebe esa vía en equipos recuperables antes de la aplicación.

Cómo detecta EtcSec este caso

El etc-collector de EtcSec incluye BP039_CCI_NOT_DEPLOYED. En el commit revisado 6a04c34b5ce01d3abf747c1d1c2f671eaa1d5e85, su Detect() en bp039-cci-not-deployed.go recorre cada entrada recopilada de GPOPolicies y omite los objetos de política o ajustes ausentes. Cualquier cadena DeviceGuardConfigCIPolicyFilePath no vacía devuelve nil, es decir, ningún hallazgo. En caso contrario, devuelve severidad Low, Count 1, incluso cuando no se recopiló ninguna política.

Esa rama comprueba un único marcador. No valida el archivo referenciado ni su formato binario, firma, versión, ámbito de destino o estado de aplicación. Un valor positivo en una GPO no relacionada basta para suprimir el hallazgo; el código no calcula la directiva resultante para cada dispositivo. Count 1 es un recuento de hallazgos, no de equipos desprotegidos.

El registrypol_parser.go revisado requiere una clave que contenga codeintegrity para mapear ConfigCIPolicyFilePath. El ajuste GPO real utiliza la rama DeviceGuard, por lo que esta ruta no rellena el marcador esperado. Por separado, CollectGPOPolicies en smb/client.go inserta un objeto de política incluso cuando sus archivos no se leyeron correctamente. Por tanto, un objeto en el mapa no demuestra una recopilación correcta de los ajustes.

Adjunte a la investigación el inventario independiente de dispositivos, los artefactos de política aprobados, los eventos pertinentes y las decisiones de revisión de reglas. Resuelva explícitamente los fallos de recopilación. Cierre la cuestión operativa a partir de esas evidencias y los criterios de aceptación acordados, en vez de editar una GPO únicamente para silenciar una comprobación de marcador.