Guía completa de Windows Defender Application Control WDAC

Windows Defender Application Control (WDAC) se ha convertido en una de las piezas clave de la estrategia de endurecimiento de Windows para empresas que quieren ir más allá del simple antivirus y aplicar un control inteligente de aplicaciones en Windows 11. No estamos hablando solo de “no ejecutar malware”, sino de decidir con precisión milimétrica qué binarios, scripts, drivers y aplicaciones están autorizados a arrancar en cada equipo. Bien configurado, WDAC puede frenar muchas técnicas de ataque modernas, pero también puede dar más de un susto si se aplica sin una buena planificación.

En las siguientes líneas vas a encontrar una guía muy completa sobre qué es WDAC, cómo funciona, en qué se diferencia de AppLocker, cuáles son sus formatos de directiva, cómo se firma y despliega, qué problemas típicos presenta y cómo se usa tanto en escenarios tradicionales de Windows como en dispositivos específicos como HoloLens 2. Iremos hilando todos los conceptos que has visto repartidos por distintas fuentes de Microsoft y de la comunidad, pero explicados con otras palabras y con un enfoque práctico, para que puedas decidir si WDAC encaja en tu entorno y, si es así, cómo meterle mano sin romper nada.

Qué es Windows Defender Application Control (WDAC)

WDAC es una tecnología de control de aplicaciones introducida con Windows 10 diseñada para definir exactamente qué código puede ejecutarse en un dispositivo. Las reglas se aplican a nivel de sistema, no de usuario, de modo que afectan a cualquiera que inicie sesión en la máquina. La idea de fondo es simple: todo lo que no esté explícitamente permitido, se bloquea.

Para decidir si algo se permite o se deniega, WDAC puede basarse en múltiples atributos del archivo o del contexto:

• Características del certificado de firma de código (CA emisora, sujeto, etc.).
• Metadatos firmados del binario (nombre de archivo original, versión) o directamente el hash del fichero.
• Reputación del archivo según el Microsoft Intelligent Security Graph (ISG).
• Origen de la instalación, usando el concepto de “managed installer” (por ejemplo, software desplegado por Intune o SCCM).
• Ruta de lanzamiento del ejecutable o DLL, disponible desde Windows 10 1903.
• Proceso padre que ha lanzado el binario.

Las políticas WDAC actúan tanto en modo usuario (UMCI) como en modo kernel, por lo que pueden controlar no solo EXE y scripts, sino también drivers y algunos componentes muy sensibles del sistema. Esta profundidad es precisamente lo que hace que WDAC sea mucho más robusto que enfoques puramente de superficie como AppLocker.

Diferencias entre WDAC y AppLocker

AppLocker existe desde hace muchos años y sigue siendo útil, pero Microsoft lo considera más una capa adicional de defensa que la solución principal para control de aplicaciones. WDAC está pensado como una barrera de seguridad “dura”, mientras que AppLocker es más flexible y permisivo.

Las diferencias clave entre WDAC y AppLocker son:

• Ámbito de aplicación: WDAC se aplica al dispositivo completo; AppLocker permite políticas distintas por usuario o grupo.
• Profundidad de control: WDAC puede afectar a drivers, DLL y componentes de kernel; AppLocker se centra en EXE, scripts, instaladores y poco más.
• Modelo de confianza: WDAC está pensado para un enfoque de lista blanca “cero confianza” (lo no autorizado se bloquea), mientras que AppLocker a menudo se usa como lista negra.
• Compatibilidad: AppLocker es útil si tienes un entorno mixto con versiones antiguas de Windows; WDAC brilla en Windows 10/11 y Server modernos.

Microsoft recomienda WDAC como solución principal de control de aplicaciones, pero no plantea que AppLocker vaya a desaparecer. De hecho, una combinación muy habitual en empresas maduras es usar WDAC como base dura de seguridad y añadir AppLocker para matizar restricciones por usuario o para controlar comportamientos concretos (por ejemplo, bloquear PowerShell para usuarios estándar).

Formatos de política WDAC: única vs. múltiple

Una política WDAC no es más que un fichero XML que después se compila a un binario firmado (.cip o .p7b) y que Windows interpreta en el arranque o al refrescar directivas. La manera en que se estructuran estas políticas ha ido evolucionando, y hoy conviven dos formatos:

1. Formato de política única (Single Policy Format)

En este modelo solo hay una política activa por dispositivo. Es el enfoque más antiguo y el que mejor compatibilidad ofrece:

• Funciona en cualquier Windows 10 y en Windows Server 2016 y 2019.
• El archivo final se llama SiPolicy.p7b y se almacena en:
  <EFI System Partition>\Microsoft\Boot\SiPolicy.p7b
<OS Volume>\Windows\System32\CodeIntegrity\SiPolicy.p7b
• Es el formato que usa Group Policy de forma nativa.

2. Formato de políticas múltiples (Multiple Policy Format)

Con este modelo puedes tener varias políticas simultáneas que se combinan para formar el conjunto de reglas efectivo. Ofrece mucha más granularidad, pero exige sistemas modernos:

• Requiere Windows 10/11 a partir de la versión 1903.
• Antes de la actualización de abril de 2024 había un límite práctico de unas 32 políticas activas; a partir de esa fecha, el límite se eleva.
• Los ficheros se guardan como {PolicyId GUID}.cip en:
  <OS Volume>\Windows\System32\CodeIntegrity\CiPolicies\Active\
<EFI System Partition>\Microsoft\Boot\CiPolicies\Active\

En este esquema hay dos tipos de políticas:

• Base policies: son el “cimiento” sobre el que se apoya todo lo demás. Definen el marco general (por ejemplo, solo Windows + Store + drivers firmados).
• Supplemental policies: amplían o refinan una base policy sin modificarla. Sirven para añadir excepciones, reglas específicas para un departamento, etc.

La lógica es que siempre gana la política más restrictiva. Si una base permite algo pero una suplementaria lo niega, se bloquea. Esto hace posible construir arquitecturas muy flexibles pero también más complejas de mantener.

Plantillas básicas de WDAC y modos de confianza

Para no arrancar desde cero, Windows incluye varias plantillas de política en la ruta %windir%\schemas\CodeIntegrity\ExamplePolicies. Herramientas como el WDAC Wizard también permiten seleccionarlas de forma visual. Las más usadas son:

• Default Windows Mode: autoriza binarios del sistema operativo, aplicaciones de Microsoft Store, Office 365, OneDrive, Teams y drivers compatibles con Windows Hardware.
• Allow Microsoft Mode: incluye todo lo anterior y además todo el software firmado por Microsoft.
• Signed and Reputable Mode: suma a lo anterior los archivos con buena reputación según el ISG de Microsoft.

Según el nivel de seguridad que busques, puedes elegir una plantilla más estricta (Default Windows Mode) o más cómoda (Signed and Reputable). En entornos empresariales muy sensibles, suele preferirse empezar con Default Windows Mode en modo auditoría e ir añadiendo reglas de confianza a medida que se identifican necesidades reales.

WDAC en HoloLens 2 y nombres de familia de paquetes

HoloLens 2 utiliza WDAC de forma muy similar a un Windows 10 tradicional, pero con matices. Uno de los puntos clave es que muchos controles se basan en los Package Family Name (PFN) de las apps UWP instaladas.

En HoloLens WDAC se usa, por ejemplo, para bloquear el lanzamiento de aplicaciones concretas manteniéndolas visibles en la interfaz. A diferencia del modo quiosco (kiosk), donde la UI esconde las apps no permitidas, en WDAC puedes seguir viendo sus iconos, pero al intentar ejecutarlas simplemente no arrancan.

Listas de apps y Package Family Names en HoloLens 2

En muchos despliegues corporativos se editan manualmente políticas como newPolicy.xml para añadir reglas basadas en PFN de aplicaciones que solo existen en HoloLens. Algunos ejemplos típicos de apps integradas son:

• Visor 3D / 3D Viewer: Microsoft.Microsoft3DViewer_8wekyb3d8bbwe
• App Installer: Microsoft.DesktopAppInstaller_8wekyb3d8bbwe (bloquearla solo impide usar esa app, no las instalaciones desde Store o MDM)
• Calendario y Correo: microsoft.windowscommunicationsapps_8wekyb3d8bbwe
• Cámara: HoloCamera_cw5n1h2txyewy
• Cortana: Microsoft.549981C3F5F10_8wekyb3d8bbwe
• Dynamics 365 Guides: Microsoft.Dynamics365.Guides_8wekyb3d8bbwe
• Dynamics 365 Remote Assist: Microsoft.MicrosoftRemoteAssist_8wekyb3d8bbwe
• Feedback Hub: Microsoft.WindowsFeedbackHub_8wekyb3d8bbwe
• Explorador de archivos: c5e2524a-ea46-4f67-841f-6a9465d9d515_cw5n1h2txyewy
• Microsoft Store: Microsoft.WindowsStore_8wekyb3d8bbwe
• Fotos: Microsoft.Windows.Photos_8wekyb3d8bbwe
• Configuración: HolographicSystemSettings_cw5n1h2txyewy
• Consejos / Tips: Microsoft.HoloLensTips_8wekyb3d8bbwe

Estas cadenas se usan dentro de la política WDAC para crear reglas de autorización o denegación de apps UWP en HoloLens. En un entorno gestionado con Intune, es habitual exportar estos PFN desde un dispositivo de prueba y después aplicarlos masivamente.

Cómo encontrar el Package Family Name de una app

Si una aplicación no aparece en las listas de referencia, puedes obtener su PFN mediante Windows Device Portal conectado a un HoloLens 2 que tenga la app instalada:

1. Instala la app en el HoloLens 2 de pruebas.
2. En el dispositivo, ve a Configuración > Actualizaciones y seguridad > Para desarrolladores y activa Modo desarrollador y Portal de dispositivos.
3. Conéctate al Device Portal desde un navegador en la misma red y entra en la sección Views > Apps.
4. En el panel de apps instaladas, elige la aplicación en el desplegable.
5. Localiza el campo PackageRelativeID.
6. Copia todo lo que aparece antes del carácter “!”; esa porción es el Package Family Name que usarás en la política WDAC.

Uso de PowerShell para localizar paquetes y procesos

PowerShell es la navaja suiza para preparar políticas WDAC, especialmente cuando necesitas encontrar nombres de paquetes UWP en un PC Windows 10 “normal”. Un patrón habitual para localizar apps es:

Comando ejemplo: $package1 = Get-AppxPackage -name *<NombreApp>*

Si no recuerdas el nombre exacto del paquete, puedes ir probando con comodines hasta dar con él. Por ejemplo, para localizar Microsoft Edge moderno:

Comando: Get-AppxPackage -name *edge*

El comando puede devolver varios resultados, pero entre ellos verás el nombre completo del paquete que luego puedes reutilizar en reglas WDAC o en scripts de auditoría.

Bloqueo específico de aplicaciones: ejemplo con Microsoft Edge

En ocasiones, el objetivo no es definir toda una estrategia de lista blanca, sino bloquear un ejecutable concreto que consideras problemático. Un ejemplo típico es el nuevo Microsoft Edge en entornos donde se quiere forzar el uso de otro navegador corporativo.

En esos casos, y para evitar errores con aplicaciones no comprobadas, se puede añadir una regla de denegación directa sobre el binario, por ejemplo:

Regla XML de ejemplo: <Deny FriendlyName="C:\Data\Programs FileRule" PackageVersion="65535.65535.65535.65535" FileName="msedge.exe" />

Esta instrucción, integrada en el XML de la política, indica que cualquier archivo llamado msedge.exe que coincida con el contexto de esa regla será bloqueado, independientemente del resto de permisos que pudieran derivarse de otras reglas más genéricas.

Firmar políticas WDAC: cuándo y por qué

Firmar una política WDAC es el paso que la convierte en “casi intocable”. Una vez que una política firmada se ha aplicado y está protegida por Secure Boot, no basta con borrar el fichero del disco para desactivarla. Eso es bueno para la seguridad, pero peligroso si no tienes muy atado el procedimiento de actualización y retirada.

Al firmar, te aseguras de que:

• La política no puede ser modificada sin usar un certificado autorizado en la propia política (UpdatePolicySigners).
• Solo se cargan binarios de política que Windows puede validar criptográficamente.
• Un atacante con privilegios de administrador local lo tiene mucho más difícil para desactivar WDAC.

A cambio, si se produce un error grave (por ejemplo, se borra la política firmada de la partición EFI), puedes acabar con equipos que no arrancan hasta que se reinyecta manualmente una política válida. Por eso se insiste tanto en probarlo antes en laboratorio.

Requisitos previos para firmar

Requisitos previos para firmar políticas WDAC:

• Equipos configurados con UEFI y Secure Boot habilitado.
• Un certificado de firma de código (adquirido a una CA pública o emitido por tu PKI interna).
• Definir en la política reglas <UpdatePolicySigner> que autoricen ese certificado a firmar nuevas versiones de la política.
• Herramientas como SignTool.exe y los cmdlets de WDAC en PowerShell (ConvertFrom-CIPolicy, Add-SignerRule, etc.).

El flujo típico es: crear el XML, ajustar reglas, añadir el firmante en UpdatePolicySigner, eliminar la opción de política sin firmar, convertir a binario, firmar con SignTool y renombrar el resultado a {GUID}.cip usando el PolicyId del XML.

Despliegue de WDAC: GPO, Intune, scripts y herramientas

Desplegar WDAC es casi tan importante como diseñar bien la política. La misma política puede gestionarse de formas distintas según tus herramientas de gestión.

Group Policy Objects (GPO)

Si usas Active Directory clásico, la vía más directa es una GPO de equipo apuntando a un fichero de política en formato único:

• Ruta de la directiva: Equipo > Plantillas administrativas > Sistema > Device Guard > Deploy Windows Defender Application Control.
• Ahí se habilita la opción y se indica la ruta del fichero de política (se convertirá a SiPolicy.p7b automáticamente).
• Tras aplicar la GPO, es necesario reiniciar para que la política se active.

La pega es que solo soporta formato de política única. Para arquitecturas con múltiples políticas, tienes que recurrir a scripts o herramientas específicas.

Intune y el uso de CSPs

En entornos modernos, lo más habitual es desplegar WDAC vía Intune, ya sea con perfiles de Endpoint Protection o mediante el CSP ApplicationControl. La opción más flexible es esta última:

• Se crea una directiva de configuración personalizada con un OMA-URI del estilo:
  ./Vendor/MSFT/ApplicationControl/Policies//Policy
• Se sube el fichero .bin/.cip generado desde el XML.
• Es recomendable que la política incluya la opción “Update Policy without rebooting” (Option 16) para evitar reinicios forzados en actualizaciones futuras.

La plantilla de Endpoint Protection de Intune también permite habilitar WDAC de forma rápida, activando “Application Control Code Integrity policy” y, opcionalmente, “Trust apps with good reputation”. Esa configuración se apoya en el ISG, pero tiene dos inconvenientes: fuerza un reinicio y suele generar muchos bloqueos imprevistos si no se complementa con reglas adicionales.

Scripts, CiTool y otros métodos

Cuando no tienes MDM o GPO a mano, o cuando quieres hacer despliegues muy personalizados, siempre te quedan los scripts y herramientas específicas:

• CiTool.exe (Windows 11 22H2+): permite aplicar y eliminar políticas WDAC por GUID desde línea de comandos.
• WMI: puede usarse para aplicar políticas en formato único en sistemas más antiguos.
• Copias directas a las rutas de CodeIntegrity y la partición EFI: método más manual, habitualmente envuelto en scripts de PowerShell.

Supervisión, prueba y solución de problemas

Antes de imponer WDAC en modo de bloqueo, hay que vivir en modo auditoría y supervisar procesos conflictivos como compattelrunner.exe. No es una recomendación “blanda”: desplegar una política estricta sin haber observado primero qué rompe puede tumbar aplicaciones críticas… o directamente provocar que la máquina no arranque.

Comprobar si WDAC está activo

Hay varias formas de verificar el estado de WDAC:

• MSINFO32: en “Información del sistema” aparece un campo “Windows Defender Application Control status” indicando si está deshabilitado, en auditoría o aplicado.
• Carpeta CodeIntegrity: en C:\Windows\System32\CodeIntegrity\ puedes ver si hay un SiPolicy.p7b (política única) o ficheros .cip bajo CiPolicies\Active.
• Registro de eventos: el log Microsoft-Windows-CodeIntegrity/Operational centraliza los eventos de WDAC.
• PowerShell: con
  Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | FL *codeintegrity*
  puedes comprobar, entre otros, UserModeCodeIntegrityPolicyEnforcementStatus (valor 2 = aplicado).

Eventos clave en el visor de eventos

El log de CodeIntegrity es tu mejor amigo para saber qué está pasando. Los IDs más importantes son:

• 3076: el archivo habría sido bloqueado, pero se ha permitido porque la política está en modo auditoría.
• 3077: el archivo ha sido bloqueado en modo de aplicación.
• 3089 y otros códigos: informan de la carga de políticas, errores, etc.

Filtrar por 3076 cuando estás probando en auditoría es una forma muy eficiente de ver qué romperías si pasaras a modo enforcement en ese momento.

Pruebas con ejecutables firmados e internos

En muchos escenarios se quiere que aplicaciones internas firmadas con un CA corporativo estén permitidas por WDAC. El flujo típico sería:

• Generar un certificado de firma de código interno (y mantenerlo a buen recaudo).
• Firmar el ejecutable con SignTool.exe o herramientas equivalentes.
• En el WDAC Wizard, añadir una regla de tipo Publisher usando ese binario como referencia y seleccionando atributos como Emisor y Publicador.
• Si el wizard avisa de que no puede obtener algunos atributos, permite que cree una regla de hash como fallback.
• Generar la política en modo auditoría, desplegarla, verificar en el log que el EXE firmado se permite y su versión sin firmar se registraría como bloqueo potencial.

Creación de políticas a medida: baseline, escaneos y “golden image”

No siempre es buena idea partir solo de las plantillas de Microsoft. En entornos con mucho software heredado o muy específico, puede ser más práctico construir una política a partir de un “golden image”: un equipo de referencia con todo el software corporativo instalado.

Un enfoque muy habitual es:

• Preparar un equipo limpio con todas las apps necesarias ya instaladas.
• Ejecutar comandos como:
  New-CIPolicy -MultiplePolicy -FilePath C:\temp\wdacpolicybaseline.xml -ScanPath C: -Level FilePublisher -UserPEs -Fallback Hash
• Esperar (puede tardar bastante, según el volumen de archivos).
• Abrir el XML resultante con el WDAC Wizard, revisar opciones (asegurarse de tener Audit Mode al principio y Update without reboot activado) y limpiar reglas duplicadas o absurdas.

Este tipo de políticas tienden a ser muy grandes y algo “sucias”, por lo que en muchos casos acaba resultando más práctico apoyarse en las plantillas oficiales (Default Windows Mode, etc.) y añadir reglas de confianza específicas o escaneos parciales de Program Files y Program Files (x86):

Comandos: New-CIPolicy -FilePath .\ProgramFiles.xml -ScanPath $env:ProgramFiles -Level Publisher -UserPEs -Fallback Hash
New-CIPolicy -FilePath .\ProgramFiles86.xml -ScanPath ${env:ProgramFiles(x86)} -Level Publisher -UserPEs -Fallback Hash

Luego se pueden fusionar XML (por ejemplo, baseline de Microsoft + reglas de drivers bloqueados + reglas de apps internas) usando el propio WDAC Wizard o cmdlets específicos.

Uso combinado de Managed Installer, ISG y AppLocker

WDAC no vive en una isla. Lo ideal es aprovechar la integración con otros componentes de Windows para no convertirte en esclavo de la actualización manual constante y para integrar estrategias de Application Security Posture Management.

• Managed Installer (opción 13): si marcas esta opción y defines correctamente un “instalador gestionado” (por ejemplo, el servicio de Intune Management Extension acompañado de una política AppLocker asociada), WDAC permitirá automáticamente lo que despliegue ese instalador.
• Intelligent Security Graph (opción 14): permite que WDAC consulte la reputación de archivos. Lo que el ISG considere “conocido y bueno” podrá ejecutarse incluso si no hay una regla explícita, lo que reduce fricción pero también baja ligeramente el listón de seguridad.
• AppLocker: se puede usar en paralelo para refinar el comportamiento por usuario, bloquear determinadas apps UWP como Netflix o Spotify, o limitar PowerShell a administradores.

Hay que tener en cuenta que, aunque los ejemplos de plantilla de Microsoft permiten Store Apps por defecto, bloquear completamente la Microsoft Store o ciertas apps de la Store mediante WDAC puro puede ser delicado y fácil de romper. En la práctica, se suele usar AppLocker o políticas específicas de Store para ese tipo de control fino.

Revertir y eliminar políticas WDAC

Quitar WDAC mal planteado puede ser tan delicado como ponerlo, especialmente si las políticas están firmadas. La recomendación de Microsoft es siempre:

• Desplegar primero una política de reemplazo (por ejemplo, basada en AllowAll.xml) que active la opción “Unsigned System Integrity Policy” y ponga el modo en auditoría.
• Verificar que esa política nueva se ha aplicado correctamente antes de retirar la original.
• Eliminar después la política desde el mecanismo de despliegue (GPO, MDM, scripts), evitando que se vuelque de nuevo sobre los equipos.

Para políticas sin firmar, desde Windows 11 22H2 se puede usar CiTool.exe para desinstalar por GUID, o bien borrar manualmente los ficheros:

• Formato múltiple:
  <EFI System Partition>\Microsoft\Boot\CiPolicies\Active\{PolicyId}.cip
<OS Volume>\Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyId}.cip
• Formato único:
  <EFI System Partition>\Microsoft\Boot\SiPolicy.p7b
<OS Volume>\Windows\System32\CodeIntegrity\SiPolicy.p7b

En todos los casos, es obligatorio reiniciar para que el equipo deje de aplicar la política eliminada. En muchos entornos se opta por “desarmar” primero la política (permitir todo, modo auditoría) y luego retirarla con calma.

WDAC es una herramienta potentísima para controlar qué se ejecuta en Windows, desde HoloLens hasta estaciones de trabajo avanzadas, pero también es exigente: obliga a conocer bien el entorno, a probar en auditoría, a mantener un ciclo de vida de políticas (firmadas o no) y a combinarlo con otras piezas como AppLocker, ISG o Managed Installer. Si se usa con cabeza, reduce de manera drástica la superficie de ataque; si se enciende a lo loco, el que se rebela no es el malware sino tus usuarios… y tu propio equipo de IT.