Descripción de Windows Defender reglas de directivas y reglas de archivo de Control de aplicaciones (WDAC)

Nota

Algunas funcionalidades de Windows Defender Application Control solo están disponibles en versiones específicas de Windows. Obtenga más información sobre la disponibilidad de características WDAC.

Windows Defender Control de aplicaciones (WDAC) puede controlar lo que se ejecuta en los dispositivos Windows estableciendo directivas que especifican si un controlador o aplicación es de confianza. Una directiva incluye reglas de directiva que controlan opciones como el modo de auditoría y reglas de archivo (o niveles de reglas de archivo) que especifican cómo identificar las aplicaciones en las que confía su organización.

Reglas de directivas de Control de aplicaciones de Windows Defender

Para modificar las opciones de regla de directiva de un XML de directiva WDAC existente, use el Asistente para directivas WDAC o el cmdlet de PowerShell Set-RuleOption .

Puedes establecer varias opciones de regla dentro en una directiva WDAC. En la tabla 1 se describe cada opción de regla y si las directivas complementarias pueden establecerlas. Algunas opciones de regla se reservan para el trabajo futuro o no se admiten.

Nota

Se recomienda usar Enabled:Audit Mode inicialmente porque permite probar nuevas directivas WDAC antes de aplicarlas. Con el modo de auditoría, las aplicaciones se ejecutan normalmente, pero WDAC registra eventos cada vez que se ejecuta un archivo que no está permitido por la directiva. Para permitir estos archivos, puede capturar la información de directiva del registro de eventos y, a continuación, combinar esa información en la directiva existente. Cuando se elimina el modo Enabled:Audit , la directiva se ejecuta en modo aplicado.

Algunas aplicaciones pueden comportarse de manera diferente incluso cuando la directiva está en modo de auditoría. Cuando una opción puede cambiar los comportamientos en modo de auditoría, esto se indica en la tabla 1. Siempre debe probar las aplicaciones exhaustivamente al implementar actualizaciones significativas en las directivas WDAC.

Tabla 1. Directiva de Control de aplicaciones de Windows Defender: opciones de reglas de directivas

Opción de regla Descripción Opción complementaria válida
0 Enabled:UMCI Las directivas WDAC restringen los archivos binarios en modo kernel y en modo de usuario. De manera predeterminada, solo se restringen los archivos binarios en modo kernel. Al habilitar esta opción de regla, se validan los scripts y los ejecutables del modo de usuario. No
1 Enabled:Boot Menu Protection Esta opción no se admite actualmente. No
2 Required:WHQL De forma predeterminada, los controladores de kernel que no están firmados en Windows Hardware Quality Labs (WHQL) pueden ejecutarse. La habilitación de esta regla requiere que cada controlador esté firmado por WHQL y quite la compatibilidad con controladores heredados. Los controladores de kernel creados para Windows 10 deben estar certificados con WHQL. No
3 Enabled:Audit Mode (Default) Indica a WDAC que registre información sobre aplicaciones, archivos binarios y scripts que se habrían bloqueado si se aplicara la directiva. Puede usar esta opción para identificar el posible impacto de la directiva WDAC y usar los eventos de auditoría para refinar la directiva antes de la aplicación. Para aplicar una directiva WDAC, elimine esta opción. No
4 Disabled:Flight Signing Si está habilitado, los archivos binarios de las compilaciones de Windows Insider no son de confianza. Esta opción es útil para las organizaciones que solo quieren ejecutar archivos binarios publicados, no versiones preliminares de compilaciones de Windows. No
5 Enabled:Inherit Default Policy Esta opción está reservada para su uso futuro y actualmente no tiene ningún efecto. Sí
6 Enabled:Unsigned System Integrity Policy (Default) Permite que la directiva permanezca sin firmar. Cuando se quita esta opción, se debe firmar la directiva y también se deben firmar las directivas complementarias. Los certificados de confianza para futuras actualizaciones de directivas deben identificarse en la sección UpdatePolicySigners. Los certificados de confianza para las directivas complementarias deben identificarse en la sección SupplementalPolicySigners. No
7 Allowed:Debug Policy Augmented Esta opción no se admite actualmente. Sí
8 Required:EV Signers Esta opción no se admite actualmente. No
9 Enabled:Advanced Boot Options Menu El menú de prearranque de F8 está deshabilitado de manera predeterminada para todas las directivas WDAC. Al activar esta opción, se permite que aparezca el menú de F8 ante los usuarios presentes físicamente. No
10 Enabled:Boot Audit on Failure Se usa cuando la directiva WDAC está en modo de aplicación. Cuando se produce un error en un controlador crítico para el arranque durante el inicio, la directiva WDAC se coloca en modo de auditoría para que Windows se cargue. Los administradores pueden validar el motivo del error en el registro de eventos CodeIntegrity. No
11 Cumplimiento de Disabled:Script Esta opción deshabilita las opciones de cumplimiento de scripts, que abarcan PowerShell, Host de script basado en Windows (wscript.exe), Host de script basado en consola de Windows (cscript.exe), archivos HTA ejecutados en microsoft HTML Application Host (mshta.exe) y MSXML. Algunos hosts de script pueden comportarse de manera diferente incluso cuando la directiva está en modo de auditoría. Para obtener más información sobre la aplicación de scripts, vea Aplicación de scripts con WDAC.
NOTA: Esta opción no se admite en Windows Server 2016 o Windows 10 1607 LTSB y no se debe usar en esos sistemas operativos.		 No
12 Aplicaciones de Store Required:Enforce Si esta opción de regla está habilitada, las directivas WDAC también se aplican a las aplicaciones universales de Windows. No
13 Instalador de Enabled:Managed Use esta opción para permitir automáticamente las aplicaciones instaladas por un instalador administrado. Para obtener más información, consulte Autorización de aplicaciones implementadas con un instalador administrado de WDAC. Sí
14 Autorización de gráficos de seguridad Enabled:Intelligent Use esta opción para permitir automáticamente aplicaciones con una reputación "conocida buena" según lo definido por Intelligent Security Graph (ISG) de Microsoft. Sí
15 EA en reinicio Enabled:Invalidate Cuando se usa la opción Gráfico de seguridad inteligente (14), WDAC establece un atributo de archivo extendido que indica que se ha autorizado la ejecución del archivo. Esta opción hace que WDAC revalide periódicamente la reputación de los archivos autorizados previamente por el ISG. No
16 Directiva sin reinicio Enabled:Update Usa esta opción para permitir la aplicación de futuras actualizaciones de directivas WDAC sin necesitar un reinicio del sistema.
NOTA: Esta opción solo se admite en Windows 10, versión 1709 y posteriores o Windows Server 2019 y versiones posteriores.		 No
17 Habilitado:Permitir directivas complementarias Use esta opción en una directiva base para permitir que las directivas complementarias la expandan.
NOTA: Esta opción solo se admite en Windows 10, versión 1903 y posteriores o Windows Server 2022 y versiones posteriores.		 No
18 Disabled:Runtime FilePath Rule Protection Esta opción deshabilita la comprobación en tiempo de ejecución predeterminada que solo permite reglas de FilePath para rutas de acceso que solo un administrador puede escribir.
NOTA: Esta opción solo se admite en Windows 10, versión 1903 y posteriores o Windows Server 2022 y versiones posteriores.		 Sí
19 Enabled:Dynamic Code Security Habilita la aplicación de directivas para aplicaciones .NET y bibliotecas cargadas dinámicamente.
NOTA: Esta opción solo se admite en Windows 10, versión 1803 y posteriores o Windows Server 2019 y versiones posteriores.
NOTA: Esta opción siempre se aplica si alguna directiva WDAC UMCI la habilita. No hay ningún modo de auditoría para la protección de la seguridad de código dinámico de .NET.		 No
20 Enabled:Revoked Expired as Unsigned (20 Habilitado:Revocado expirado como sin firmar) Use esta opción para tratar los archivos binarios firmados con certificados revocados o certificados expirados con el EKU de firma de duración en la firma, como "archivos binarios sin firmar" para procesos o componentes en modo de usuario, en escenarios de firma empresarial. No
Enabled:Developer Mode Dynamic Code Trust Usa esta opción para confiar en las aplicaciones para UWP que se depuran en Visual Studio o se implementan a través del portal de dispositivos cuando el modo de desarrollador está habilitado en el sistema. No

Niveles de reglas de archivos de Control de aplicaciones de Windows Defender

Los niveles de reglas de archivo permiten a los administradores especificar el nivel en el que quieran confiar en las aplicaciones. Este nivel de confianza podría ser tan granular como el hash de cada binario o tan general como un certificado de entidad de certificación. Los niveles de regla de archivo se especifican al usar el Asistente para WDAC o los cmdlets de PowerShell WDAC para crear y modificar directivas.

Cada nivel de regla de archivo tiene ventajas y desventajas. Use la tabla 2 para seleccionar el nivel de protección adecuado para los recursos administrativos disponibles y el escenario de implementación de WDAC.

Nota

Las reglas basadas en firmante WDAC solo funcionan con criptografía RSA. No se admiten algoritmos ECC, como ECDSA. Si intenta permitir archivos por firma basados en firmas ECC, verá VerificationError = 23 en los eventos de información de firma 3089 correspondientes. Los archivos se pueden permitir en su lugar mediante reglas hash o de atributo de archivo, o mediante otras reglas de firmante si el archivo también está firmado con firmas mediante RSA.

Tabla 2. Directiva de Control de aplicaciones de Windows Defender: niveles de reglas de archivos

Nivel de regla Descripción
Hash Especifica valores hash de imagen authenticode/PE individuales para cada binario detectado. Este nivel es el nivel más específico y requiere más esfuerzo para mantener los valores hash de las versiones de producto actuales. Cada vez que se actualiza un binario, el valor de hash cambia, por lo que es necesario actualizar la directiva.
FileName Especifica el nombre de archivo original de cada binario. Aunque los valores de hash de una aplicación se modifican al actualizarse, los nombres de los archivos no suelen hacerlo. Este nivel ofrece una seguridad menos específica que el nivel hash, pero normalmente no requiere una actualización de directiva cuando se modifica cualquier binario. De forma predeterminada, este nivel usa el atributo OriginalFileName del encabezado de recurso del archivo. Use -SpecificFileNameLevel para elegir un atributo alternativo, como ProductName.
FilePath A partir de Windows 10 versión 1903, este nivel permite que los archivos binarios se ejecuten desde ubicaciones de ruta de acceso de archivo específicas. Las reglas de FilePath solo se aplican a los archivos binarios en modo de usuario y no se pueden usar para permitir controladores de modo kernel. Puede encontrar más información sobre las reglas de nivel de FilePath más adelante en este artículo.
SignedVersion Este nivel combina la regla del publicador con un número de versión. Permite que cualquier cosa se ejecute desde el publicador especificado con una versión en o por encima del número de versión especificado.
Publicador Este nivel combina el nivel PcaCertificate (normalmente un certificado debajo de la raíz) y el nombre común (CN) del certificado hoja. Puede usar este nivel de regla para confiar en un certificado emitido por una ca determinada y emitido a una empresa específica en la que confíe (como Intel, para controladores de dispositivos).
FilePublisher Este nivel combina el atributo "FileName" del archivo firmado, más "Publisher" (certificado PCA con CN de hoja), además de un número de versión mínimo. Esta opción confía en archivos concretos del editor especificado (con una versión de archivo igual o superior al número de versión especificado). De forma predeterminada, este nivel usa el atributo OriginalFileName del encabezado de recurso del archivo. Use -SpecificFileNameLevel para elegir un atributo alternativo, como ProductName.
LeafCertificate Agrega firmantes de confianza al nivel de certificado de firma individual. La ventaja de usar este nivel frente al nivel hash individual es que las nuevas versiones del producto tienen valores hash diferentes, pero normalmente el mismo certificado de firma. Cuando se usa este nivel, no se necesitaría ninguna actualización de directiva para ejecutar la nueva versión de la aplicación. Sin embargo, los certificados hoja suelen tener períodos de validez más cortos que otros niveles de certificado, por lo que la directiva WDAC debe actualizarse siempre que estos certificados cambien.
PcaCertificate Agrega el certificado disponible más elevado en la cadena de certificados proporcionada a los firmantes. Este nivel suele ser un certificado debajo de la raíz porque el examen no resuelve la cadena de certificados completa a través de los almacenes raíz locales o con una comprobación en línea.
RootCertificate No se admite.
WHQL Solo confía en los archivos binarios enviados a Microsoft y firmados por el Laboratorio de calificación de hardware (WHQL) de Windows. Este nivel se aplica principalmente a los archivos binarios del kernel.
WHQLPublisher Este nivel combina el nivel WHQL y el CN en el certificado hoja, y es principalmente para los archivos binarios del kernel.
WHQLFilePublisher Este nivel combina el atributo "FileName" del archivo firmado, más "WHQLPublisher", además de un número de versión mínimo. Este nivel se aplica principalmente a los archivos binarios del kernel. De forma predeterminada, este nivel usa el atributo OriginalFileName del encabezado de recurso del archivo. Use -SpecificFileNameLevel para elegir un atributo alternativo, como ProductName.

Nota

Al crear directivas WDAC con New-CIPolicy, puede especificar un nivel de regla de archivo principal, incluyendo el parámetro -Level . Para los archivos binarios detectados en los que no se pueda confiar según los criterios de la regla de archivo principal, usa el parámetro -Fallback . Por ejemplo, si el nivel de regla de archivo principal es PCACertificate, pero también quiere confiar en las aplicaciones sin firmar, el uso del nivel de regla hash como reserva agrega los valores hash de los archivos binarios que no tenían un certificado de firma.

Nota

  • WDAC solo admite reglas de firmante para claves de firma de certificados RSA con un máximo de 4096 bits.
  • El código usa CN para los campos CertSubject y CertIssuer de la directiva. Puede usar el certutil de bandeja de entrada para examinar el formato subyacente para asegurarse de que UTF-8 no se usa para el CN. Por ejemplo, puede usar cadenas imprimibles, IA5 o BMP.

Nota

Cuando corresponda, se hace referencia a los números de versión mínimo y máximo de una regla de archivo como MinimumFileVersion y MaximumFileVersion, respectivamente, en el XML de directiva.

  • Se especifican MinimumFileVersion y MaximumFileVersion: para las reglas Allow, se permite el archivo con una versión mayor o igual que MinimumFileVersion y menor o igual que MaximumFileVersion. En el caso de las reglas Deny, se deniega el archivo con una versión mayor o igual que MinimumFileVersion y menor o igual que MaximumFileVersion.
  • MinimumFileVersion especificado sin MaximumFileVersion: para las reglas Allow, el archivo con una versión mayor o igual que la versión especificada puede ejecutarse. En el caso de las reglas deny, se bloquea el archivo con una versión menor o igual que la versión especificada.
  • MaximumFileVersion especificado sin MinimumFileVersion: para las reglas Allow, el archivo con una versión menor o igual que la versión especificada puede ejecutarse. En el caso de las reglas deny, se bloquea el archivo con una versión mayor o igual que la versión especificada.

Ejemplo de los niveles de regla de archivo en uso

Por ejemplo, considere la posibilidad de un profesional de TI en un departamento que ejecuta muchos servidores. Solo quieren ejecutar software firmado por las empresas que proporcionan su hardware, sistema operativo, antivirus y otro software importante. Saben que sus servidores también ejecutan una aplicación escrita internamente que no está firmada y que rara vez se actualiza. Ellos permiten que esta aplicación se ejecute.

Para crear la directiva WDAC, crean un servidor de referencia con el hardware estándar e instalan todos los softwares que saben que se ejecutan en sus servidores. A continuación, ejecutan New-CIPolicy con -Level Publisher (para permitir que se ejecute el software de sus proveedores de software, los "editores") y -Fallback Hash (para permitir la aplicación interna y sin firmar). Implementan la directiva en modo de auditoría para determinar el posible impacto de la aplicación de la directiva. Con la ayuda de los datos de auditoría, actualizan sus directivas WDAC para incluir cualquier otro software que quieran ejecutar. A continuación, habilitan la directiva WDAC en modo de aplicación para sus servidores.

Como parte de las operaciones normales, finalmente instalarán actualizaciones de software o quizás agregarán software de los mismos proveedores de software. Dado que el "publicador" sigue siendo el mismo en esas actualizaciones y software, no es necesario actualizar su directiva WDAC. Si se actualiza la aplicación interna sin signo, también debe actualizar la directiva WDAC para permitir la nueva versión.

Orden de precedencia de la regla de archivo

WDAC tiene una lógica de conflicto de reglas de archivo integrada que se traduce en orden de precedencia. Primero procesa todas las reglas de denegación explícitas que encuentra. A continuación, procesa las reglas de permiso explícitas. Si no existe ninguna regla de denegación o de permiso, WDAC comprueba si la directiva permite una notificación del instalador administrado . Por último, WDAC vuelve al ISG si lo permite la directiva.

Nota

Para que sea más fácil razonar sobre las directivas WDAC, se recomienda mantener directivas ALLOW y DENY independientes en versiones de Windows que admitan varias directivas WDAC.

Usar -SpecificFileNameLevel con reglas de nivel FileName, FilePublisher o WHQLFilePublisher

De forma predeterminada, los niveles de regla FileName, FilePublisher y WHQLFilePublisher usan el atributo OriginalFileName del encabezado de recurso del archivo. Puede usar un atributo de encabezado de recurso alternativo para las reglas estableciendo -SpecificFileNameLevel. Por ejemplo, un desarrollador de software podría usar el mismo ProductName para todos los archivos binarios que forman parte de una aplicación. Con -SpecificFileNameLevel, puede crear una sola regla para cubrir todos esos archivos binarios de la directiva en lugar de reglas individuales para cada archivo.

En la tabla 3 se describen las opciones de atributo de encabezado de recurso disponibles que puede establecer con -SpecificFileNameLevel.

Tabla 3. Opciones de -SpecificFileNameLevel

Valor specificFileNameLevel Descripción
FileDescription Especifica la descripción del archivo proporcionada por el desarrollador del archivo binario.
InternalName Especifica el nombre interno del binario.
OriginalFileName Especifica el nombre de archivo original, o el nombre con el que se creó por primera vez el archivo, del binario.
PackageFamilyName Especifica el nombre de familia del paquete binario. El nombre de la familia del paquete consta de dos partes: el nombre del archivo y el identificador del publicador.
Productname Especifica el nombre del producto con el que se envía el binario.
Filepath Especifica la ruta de acceso del archivo binario.

Más información sobre las reglas de ruta de archivo

Las reglas de ruta de archivo no proporcionan las mismas garantías de seguridad que las reglas de firmante explícitas, ya que se basan en permisos de acceso mutables. Las reglas de ruta de archivo son más adecuadas para entornos en los que la mayoría de los usuarios se ejecutan como estándar en lugar de como administrador. Las reglas de ruta de acceso son más adecuadas para permitir rutas de acceso que espera que solo se puedan escribir mediante el administrador. Es posible que quiera evitar reglas de ruta de acceso para directorios en los que los usuarios estándar pueden modificar las ACL en la carpeta.

Rutas de archivo que se pueden escribir por el usuario

De forma predeterminada, WDAC realiza una comprobación de capacidad de escritura del usuario en tiempo de ejecución que garantiza que los permisos actuales en la ruta de acceso de archivo especificada solo permiten el acceso de escritura para los usuarios administradores.

Hay una lista definida de SID que WDAC reconoce como administradores. Si una ruta de acceso de archivo permite permisos de escritura para cualquier SID que no esté en esta lista, se considera que la ruta de archivo puede escribirse por el usuario, incluso si el SID está asociado a un usuario administrador personalizado. Para controlar estos casos especiales, puede invalidar la comprobación de escritura del administrador en tiempo de ejecución de WDAC con la opción Disabled:Runtime FilePath Rule Protection descrita anteriormente.

La lista de SID de administración conocidos de WDAC son:

S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-143048594-2639229838-973813799-439329657-1197984847-4069167804-127792394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.

Cuando se generan reglas de ruta de archivo mediante New-CIPolicy, se genera una regla de ruta de acceso única y completa para cada archivo detectado en las rutas de acceso examinadas. Para crear reglas que permitan en su lugar todos los archivos de una ruta de acceso de carpeta especificada, use New-CIPolicyRule para definir reglas que contengan caracteres comodín mediante el modificador -FilePathRules .

Uso de caracteres comodín en reglas de ruta de archivo WDAC

Los siguientes caracteres comodín se pueden usar en las reglas de ruta de archivo WDAC:

Carácter comodín Significado Sistemas operativos compatibles
* Coincide con cero o más caracteres. Windows 11, Windows 10 y Windows Server 2022
? Coincide con un solo carácter. solo Windows 11

También puede usar las macros siguientes cuando el volumen exacto puede variar: %OSDRIVE%, %WINDIR%, %SYSTEM32%. Estas macros se pueden usar en combinación con los caracteres comodín anteriores.

Nota

En Windows 11, puede usar uno o varios caracteres comodín en cualquier lugar dentro de una regla de ruta de archivo.

En todas las demás versiones de Windows y Windows Server, solo se permite un carácter comodín por regla de ruta de acceso y debe estar al principio o al final de una regla de ruta de acceso.

Reglas de ruta de archivo de ejemplo con caracteres comodín

Ejemplos Descripción Sistemas operativos compatibles
C:\windows\*
D:\EnterpriseApps\MyApp\*
%OSDRIVE%\Windows\*		 Los caracteres comodín colocados al final de una ruta de acceso autorizan todos los archivos de la ruta de acceso inmediata y sus subdirectorios de forma recursiva. Windows 11, Windows 10 y Windows Server 2022
*\bar.exe Los caracteres comodín colocados al principio de una ruta de acceso permiten el nombre de archivo especificado exacto en cualquier ubicación. Windows 11, Windows 10 y Windows Server 2022
C:\*\CCMCACHE\*\7z???? -x64.exe
%OSDRIVE%\*\CCMCACHE\*\7z???? -x64.exe		 Los caracteres comodín usados en medio de una ruta de acceso permiten todos los archivos que coinciden con ese patrón. Considere detenidamente todas las coincidencias posibles, especialmente si la directiva deshabilita la comprobación que se puede escribir por el administrador con la opción Disabled:Runtime FilePath Rule Protection . En este ejemplo, ambas rutas de acceso hipotéticas coincidirían:
C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe
C:\USERS\WDACUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe		 solo Windows 11

Sin un carácter comodín, la regla de ruta de archivo solo permite un archivo específico (por ejemplo, C:\foo\bar.exe).

Nota

Al crear directivas WDAC con Configuration Manager, hay una opción para crear reglas para archivos y carpetas especificados. Estas reglas no son reglas de ruta de archivo WDAC. En su lugar, Configuration Manager realiza un examen único de los archivos y carpetas especificados y compila reglas para los archivos binarios que se encuentran en esas ubicaciones en el momento de ese examen. Los cambios de archivos en esos archivos y carpetas especificados después de ese examen no se permitirán a menos que se vuelva a aplicar la directiva de Configuration Manager.

Más información sobre los hashes

WDAC usa el algoritmo hash de imagen Authenticode/PE al calcular el hash de un archivo. A diferencia del hash de archivo plano más conocido, el cálculo hash authenticode omite la suma de comprobación del archivo, la tabla de certificados y la tabla de certificados de atributo. Por lo tanto, el hash Authenticode de un archivo no cambia cuando se modifican las firmas y marcas de tiempo del archivo o cuando se quita una firma digital del archivo. Con la ayuda del hash Authenticode, WDAC proporciona seguridad adicional y menos sobrecarga de administración, por lo que los clientes no necesitan revisar las reglas hash de directiva cuando se actualiza la firma digital en el archivo.

El hash de imagen Authenticode/PE se puede calcular para los archivos firmados digitalmente y sin signo.

¿Por qué el examen crea cuatro reglas hash por archivo XML?

El cmdlet de PowerShell genera un hash Authenticode Sha1, hash Sha256, hash de página Sha1, hash de página Sha256. Durante la validación, WDAC selecciona qué hashes se calculan en función de cómo se firma el archivo y del escenario en el que se usa el archivo. Por ejemplo, si el archivo está firmado con hash de página, WDAC valida cada página del archivo y evita cargar todo el archivo en memoria para calcular el hash de autenticación sha256 completo.

En los cmdlets, en lugar de intentar predecir qué hash se usará, precalculamos y usamos los cuatro hashes (sha1/sha2 authenticode y sha1/sha2 de la primera página). Este método también es resistente a los cambios en la forma en que se firma el archivo, ya que la directiva WDAC ya tiene más de un hash disponible para el archivo.

¿Por qué el examen crea ocho reglas hash para determinados archivos?

Se crean reglas independientes para UMCI y KMCI. Si los cmdlets no pueden determinar que un archivo solo se ejecuta en modo de usuario o en el kernel, se crean reglas para ambos escenarios de firma con mucha precaución. Si sabe que un archivo determinado solo se carga en modo de usuario o kernel, puede quitar de forma segura las reglas adicionales.

¿Cuándo usa WDAC el valor hash de archivo plano?

Hay algunos casos poco frecuentes en los que el formato de un archivo no se ajusta a la especificación authenticode y, por lo tanto, WDAC vuelve a usar el hash de archivo plano. Este comportamiento puede producirse por muchos motivos, como si se realizan cambios en la versión en memoria del archivo en tiempo de ejecución. En tales casos, verá que el hash que se muestra en el evento de información de firma 3089 correlacionado coincide con el hash de archivo plano del evento de bloque 3076/3077. Para crear reglas para archivos con un formato no válido, puede agregar reglas hash a la directiva para el hash de archivo plano mediante el Asistente para WDAC o editando directamente el XML de directiva.