Directiva efectiva AppLocker: probar las reglas del usuario

¿Qué es una directiva efectiva AppLocker?

Una directiva efectiva AppLocker es la directiva que se aplica en un equipo Windows concreto mediante Group Policy, combinando su directiva AppLocker local con las directivas AppLocker del dominio que se le aplican. Revisarla ayuda a determinar qué reglas deberían afectar a un archivo para el usuario previsto. Una GPO denominada «AppLocker» es una etiqueta administrativa; no establece esas reglas, su modo ni el bloqueo de una ejecución. Referencia de Get-AppLockerPolicy

Para un equipo de Active Directory que investiga un hallazgo de control de aplicaciones, el resultado útil es un registro de evidencias vinculado a un dispositivo, un usuario y una carga de trabajo. Identifique el canal de despliegue, conserve la directiva efectiva, revise sus colecciones, evalúe archivos representativos y prepare una prueba de ejecución controlada. Mantenga visibles las mediciones pendientes hasta que un administrador pueda recopilarlas.

Este procedimiento utiliza documentación primaria comprobada el 4 de octubre de 2026 y la implementación del recopilador que se describe a continuación. Los comandos PowerShell son ejemplos basados en la documentación para administradores autorizados. No se ejecutaron en un equipo para este artículo; no se afirma ningún resultado de prueba ni ninguna corrección satisfactoria.

Funcionamiento: identificar el canal de despliegue y las colecciones

Paso 1: distinguir el despliegue mediante Group Policy del despliegue CSP

Pregunte al responsable de la gestión del dispositivo si AppLocker llega mediante Group Policy o mediante el proveedor de servicios de configuración AppLocker (CSP). La referencia de Get-AppLockerPolicy de Microsoft indica expresamente que la cmdlet solo entiende los despliegues GP y puede devolver datos incorrectos cuando la directiva se ha aplicado mediante CSP. Una exportación GP vacía no permite resolver la cuestión del CSP.

La referencia del CSP AppLocker documenta las restricciones de inicio de aplicaciones con nodos de directiva específicos de cada colección. Para un dispositivo gestionado mediante CSP, conserve el perfil de gestión responsable, las cargas de configuración de las colecciones y las evidencias de aplicación al dispositivo obtenidas por ese canal. Defina cómo establecerá el equipo de gestión el estado aplicado del dispositivo antes de afirmar que existe cobertura. El procedimiento de exportación GP de este artículo no puede proporcionar esas evidencias para CSP.

Registre lo siguiente antes de elegir la vía de verificación:

Estos campos son una propuesta de registro de revisión. Complételos con observaciones reales; el nombre de una directiva o una asignación sin confirmar no bastan para cerrar una fila.

Paso 2: registrar las colecciones y los modos de aplicación

Microsoft define cinco colecciones de reglas AppLocker: archivos ejecutables, archivos Windows Installer, scripts, DLL y aplicaciones empaquetadas con sus instaladores. Una prueba limitada a ejecutables deja sin examinar otras colecciones aplicables. La colección DLL no está habilitada de forma predeterminada; revise sus implicaciones de compatibilidad y rendimiento antes de incorporarla al piloto.

Para cada colección pertinente, conserve sus reglas, los SID de usuarios o grupos, las condiciones, las excepciones y el modo configurado. El esquema XML de la referencia CSP incluye los valores AuditOnly, Enabled y NotConfigured para la aplicación de las colecciones. Conserve el valor exacto observado, junto con el ajuste de la consola y la fuente de despliegue; no resuma toda la directiva como «habilitada» porque se apliquen las reglas de una colección.

El procedimiento Audit only de Microsoft distingue la evaluación de reglas y el registro de decisiones de la aplicación de esas reglas. Una colección en auditoría puede identificar archivos que se denegarían mientras esos archivos siguen ejecutándose. Registre una colección ausente o un modo ambiguo como una cuestión de revisión independiente, en lugar de inferir protección a partir de otra colección.

Si el entorno también utiliza WDAC, nuestra guía de verificación de la identidad y activación de las directivas App Control explica el inventario CiTool y las evidencias de directivas Code Integrity. Nuestra guía de verificación de GUID y acciones Defender ASR en los equipos comprueba la configuración de reglas de comportamiento con Get-MpPreference. Conserve las evidencias propias de cada control cuando coexistan.

Detección: exportar, evaluar y correlacionar evidencias de ejecución

Paso 1: exportar la directiva efectiva desplegada mediante GP

En el equipo evaluado y gestionado mediante GP, el procedimiento de prueba de Microsoft utiliza una sesión administrativa de Windows PowerShell para exportar la directiva:

Get-AppLockerPolicy -Effective -XML > C:\Effective.xml

Elija una ubicación autorizada para las evidencias y conserve la exportación original con los detalles del equipo, la hora y el canal de despliegue. Revise todas las colecciones aplicables antes de probar archivos. Un fallo de exportación es un fallo de recopilación; una exportación con contenido inesperado requiere investigar su relación con la configuración prevista. Ninguno de estos resultados se convierte en conforme por omitir el dispositivo.

Utilice esta exportación para evaluar el estado GP observado. Si en su lugar se evalúa una directiva propuesta, identifíquela como candidata y consérvela por separado. Probar un archivo XML candidato no establece que un dispositivo haya recibido esa directiva candidata.

Paso 2: probar archivos representativos para el usuario previsto

El mismo procedimiento de Microsoft proporciona este ejemplo, con un directorio de Office y un usuario de muestra:

Get-ChildItem 'C:\Program Files\Microsoft Office\' -filter *.exe -Recurse | Convert-Path | Test-AppLockerPolicy -XMLPolicy C:\Effective.xml -User contoso\zwie -Filter Denied,DeniedByDefault | Export-CSV C:\BlockedFiles.csv

Sustituya el directorio, la identidad y la ubicación de salida por valores aprobados para la evaluación. Este comando evalúa archivos frente a la directiva especificada y exporta decisiones filtradas. Su nombre de archivo no convierte el CSV en un registro de bloqueos de ejecución. El filtro de ejecutables del ejemplo tampoco prueba scripts, instaladores, dependencias DLL ni aplicaciones empaquetadas.

La referencia de Test-AppLockerPolicy enumera Allowed, AllowedByDefault, Denied y DeniedByDefault como filtros de decisión. Conserve una evaluación sin filtrar además de cualquier informe centrado en archivos denegados. De lo contrario, un informe vacío limitado a las denegaciones no permite saber qué archivos se evaluaron ni confirmar que se incluyeron los casos prohibidos previstos.

Especifique una cuenta individual representativa para las reglas con grupos anidados, tal como recomienda la referencia de la cmdlet. Probar un nombre de grupo o al administrador que recopiló la exportación puede responder a una cuestión de autorización diferente del acceso del usuario previsto. Repita la evaluación para poblaciones de usuarios sustancialmente diferentes y conserve sus identidades con los resultados.

Construya un conjunto finito de pruebas con los responsables de las aplicaciones. Incluya, cuando corresponda, flujos aprobados de inicio, instalación, actualización y ejecución de scripts, además de archivos inocuos situados deliberadamente fuera del conjunto de aplicaciones aprobado. Para cada caso, registre la decisión esperada, la identidad del archivo o paquete, la colección aplicable, el usuario y el resultado de la evaluación. Los archivos ausentes y los errores de evaluación siguen siendo carencias explícitas. No fabrique un resultado satisfactorio a partir de un análisis limitado a un directorio.

Paso 3: revisar los registros AppLocker correctos

El procedimiento de supervisión de Microsoft sitúa los registros AppLocker en Applications and Services Logs → Microsoft → Windows → AppLocker. Revise EXE and DLL para esos tipos de archivos y MSI and Script para instaladores y scripts; incluya Packaged app-Deployment y Packaged app-Execution cuando esas colecciones estén dentro del alcance.

La referencia de eventos AppLocker documenta estas distinciones útiles:

La documentación de Microsoft sobre reglas de script matiza los eventos de bloqueo de scripts: el host del script implementa la aplicación de las reglas. Los scripts PowerShell notificados como bloqueados pueden seguir ejecutándose en Constrained Language Mode; los scripts autorizados se ejecutan en Full Language Mode. En una prueba de script, registre el host, el modo de lenguaje y las operaciones observadas, en lugar de considerar el evento 8007 por sí solo como prueba de que no se ejecutó ningún código del script.

Conserve los detalles completos de los eventos, incluidos el archivo, la hora, el contexto de la regla y la identidad, junto con el registro de la prueba. Un evento correspondiente a un archivo cuya ejecución se intentó no puede establecer la cobertura de todas las cargas de trabajo o usuarios. Antes de interpretar unos registros sin actividad, compruebe la actividad ejercida, los permisos de recopilación y la retención.

Corrección: validar un piloto recuperable de auditoría a aplicación de reglas (Remediation)

Paso 1: aprobar el comportamiento esperado antes de modificar las reglas

Resuelva tres decisiones operativas: qué evidencias cubren el canal de despliegue, qué colecciones y modos afectan al usuario previsto y qué escenarios permitidos y prohibidos se validarán en el laboratorio. Designe al responsable de la directiva, a los aprobadores de aplicaciones y al operador de recuperación. Conserve la directiva actual y un procedimiento de recuperación aprobado antes de distribuir un cambio.

Utilice equipos piloto recuperables y material de prueba inocuo. Acuerde qué flujos de trabajo necesarios deben seguir disponibles y qué casos prohibidos deben fallar tras la aplicación de las reglas. Un fallo en un flujo de administración o de negocio necesario detiene la ampliación hasta que su responsable revise la regla. Un resultado inesperado de autorización para un caso prohibido también requiere investigación; el uso satisfactorio de las aplicaciones de negocio por sí solo no establece la restricción prevista.

Paso 2: configurar Audit only y probar el piloto

Para una directiva gestionada mediante GPO, utilice Group Policy Management Console para gestionar la GPO responsable. El procedimiento Audit only de Microsoft indica a los administradores que abran AppLocker → Properties → Enforcement, seleccionen Configured para cada colección elegida, escojan Audit only y confirmen. Local Security Policy es la herramienta correspondiente para gestionar directivas locales.

Antes de probar el piloto, verifique que Application Identity (AppIDSvc) está en ejecución. Microsoft indica que detener este servicio impide la aplicación de las reglas AppLocker. Para un despliegue mediante Group Policy, configure el inicio automático en al menos una GPO que aplique reglas AppLocker, en Computer Configuration → Windows Settings → Security Settings → System Services → Application Identity. Conserve el estado observado del servicio junto con la exportación de la directiva. Procedimiento del servicio Application Identity

Después de la aplicación, recopile de nuevo la directiva y repita las evaluaciones para el usuario previsto. Ejecute los escenarios aprobados en el piloto y revise los eventos de auditoría frente a las decisiones esperadas. Pida a los responsables de las aplicaciones que expliquen las dependencias y las excepciones propuestas. Vincule cada excepción a un requisito específico, un aprobador y una decisión de revisión. No convierta cada archivo auditado en una regla de autorización solo para eliminar el ruido de auditoría.

Paso 3: aplicar las colecciones aprobadas y validar la ejecución

El procedimiento Enforce rules de Microsoft utiliza la misma pestaña Properties → Enforcement: seleccione Configured para la colección que se va a modificar y elija Enforce rules. Realice ese cambio a través del responsable y del canal establecidos después de revisar el piloto. Un despliegue CSP requiere su propio procedimiento de gestión aprobado.

Vuelva a exportar la directiva GP después de su aplicación, compare las colecciones y los modos y repita la evaluación de reglas. A continuación, realice las pruebas de ejecución aprobadas como el usuario previsto en el piloto. Registre el comportamiento real y los eventos correspondientes tanto para los escenarios necesarios como para los prohibidos. Si el comportamiento difiere de la evaluación, investigue el artefacto de directiva, el estado de la aplicación, el contexto del usuario y la colección aplicable antes de ampliar el despliegue.

Avance a otras poblaciones solo cuando los revisores designados acepten las evidencias y la preparación para la recuperación. Conserve los dispositivos desconocidos y las cargas de trabajo sin probar en el registro del cambio. El criterio de finalización es el comportamiento aprobado observado en la población evaluada, con sus limitaciones y excepciones registradas.

Cómo detecta EtcSec este problema

El etc-collector de EtcSec incluye ANSSI_R37_APPLOCKER_NOT_ENFORCED. En el commit 0423094759d50002457031317098417993e19510, Detect() en public/internal/audit/detectors/ad/compliance/anssi/anssi-r37-applocker-not-enforced.go:41 convierte a minúsculas el DisplayName de cada GPO recopilada y busca applocker, wdac, code integrity o srp. Un solo nombre coincidente basta para dejar Count 0; la ausencia de nombres coincidentes produce Count 1, con severidad Medium. Este recuento no es un recuento de equipos sin protección.

El predicado no lee reglas XML AppLocker, modos de colección ni autorizaciones específicas del usuario. No establece la aplicación de una GPO a un dispositivo. Un nombre sugerente puede suprimir la señal sin que se apliquen las reglas; una directiva real con otro nombre puede dejar la señal presente. Cambiar el nombre de una GPO modifica esta heurística sin demostrar ninguna mejora de seguridad.

El proveedor LDAP en public/internal/providers/ldap/client.go:1007 recupera metadatos de GPO. Su fallo de búsqueda devuelve un error, pero public/internal/audit/engine.go:521 descarta el error de GetGPOs al asignar las GPO devueltas. Por tanto, esta señal por sí sola no puede distinguir una recopilación fallida de GPO de una recopilación satisfactoria sin indicios en los nombres. Establezca la calidad de la recopilación de forma independiente antes de interpretarla.

R37 es un identificador histórico del detector, no el número de la recomendación normativa de AppLocker. El código asocia esta comprobación con ANSSI PA-099 R11. La guía PA-099, de fecha 2 de octubre de 2023, página 28 recomienda el endurecimiento del sistema y del software que contribuye al aislamiento de Tiers. Esta recomendación amplia no convierte la heurística de nombres en una prueba de conformidad específica de AppLocker.