- Los atacantes alteran WDAC (SiPolicy.p7b y DeviceGuard) para silenciar EDR y Defender.
- Indicadores clave: cambios en claves WDAC y hashes asociados a campañas activas.
- Mitigación: control de cambios, firmas, Tamper Protection, telemetría y parches.
- WDAC bien gestionado protege HoloLens/WAC; mal gestionado abre la puerta a fileless/LOLBins.
Los ataques que manipulan Windows Defender Application Control (WDAC) se han convertido en una vía muy seria para silenciar defensas como EDR y Microsoft Defender en entornos corporativos. Esta tendencia no es ciencia ficción: investigadores han observado cómo grupos de amenazas alteran la integridad de código para impedir que se carguen controladores y servicios de seguridad desde el arranque.
Más allá del titular, entender cómo funcionan y qué señales dejan es clave para que los SOC y equipos de respuesta no se queden a ciegas. En este análisis ponemos foco en las técnicas de manipulación de WDAC, indicadores prácticos y medidas de mitigación, pero también en el uso legítimo de WDAC (por ejemplo, en HoloLens 2 o Windows Admin Center), así como en su relación con amenazas fileless y el abuso de PowerShell y LOLBins.
Qué son los ataques que manipulan WDAC
WDAC es la tecnología de control de aplicaciones de Windows que restringe qué binarios, scripts, instaladores MSI y hasta código a nivel kernel están autorizados a ejecutarse. En esencia, establece políticas de integridad de código basadas en firmas, editores, hashes, rutas, catálogos, etc., con un enfoque de lista de permitidos.
Los adversarios han aprendido a darle la vuelta a esa lógica: cuando consiguen privilegios suficientes, alteran o despliegan políticas WDAC para bloquear específicamente componentes de seguridad (drivers y binarios de EDR, incluido Microsoft Defender), reduciendo así la visibilidad y la capacidad de respuesta defensiva antes de mover ficha con cargas útiles adicionales.
Qué está pasando y cómo operan
La técnica observada pasa por modificar la política de integridad de código para que no se carguen servicios y controladores de seguridad durante el arranque. El punto neurálgico suele ser el archivo de política SiPolicy.p7b, que Windows ubica en ‘C:\\Windows\\System32\\CodeIntegrity\\’.
Al alterar ese archivo o forzar el uso de una política alternativa, el atacante puede introducir reglas de bloqueo contra rutas y drivers de EDRs conocidos (p. ej., CrowdStrike, SentinelOne, Symantec, Tanium) y contra el propio Microsoft Defender Endpoint. Esto baja drásticamente el listón defensivo, abriendo una ventana de oportunidad para moverse con menor probabilidad de detección.
Además de tocar archivos, hay señales en el registro que conviene vigilar. En particular, cambios en Windows DeviceGuard sobre las claves ‘ConfigCIPolicyFilePath’ y ‘DeployConfigCIPolicy’ pueden delatar un despliegue no autorizado de políticas WDAC o su manipulación con fines maliciosos.
Otra vía operativa habitual es el uso de señuelos: se han observado documentos aparentemente inocuos (como supuestos ‘PDF’) que en realidad son binarios WDAC diseñados para aplicar políticas maliciosas en silencio, logrando persistencia y desactivación progresiva de defensas.
Del proyecto Krueger a la amenaza DreamDemon
En esta evolución destaca el salto de una prueba de concepto llamada Krueger, escrita en .NET, a una familia más madura bautizada DreamDemon, reimplementada en C++ para ganar eficacia y resiliencia. Mientras Krueger mostraba la viabilidad, DreamDemon automatiza y endurece las técnicas de modificación de políticas WDAC en entornos reales.
El objetivo de DreamDemon es claro: modificar WDAC para impedir la carga de servicios y drivers de múltiples proveedores de seguridad, incluido el ecosistema Microsoft Defender. Con los sensores deshabilitados, el atacante reduce la fricción antes de ejecutar payloads adicionales, moverse lateralmente o exfiltrar datos con menos probabilidades de ser detectado.
Indicadores y señales a vigilar
En la telemetría asociada a esta actividad se han compartido hashes SHA-256 que los equipos de seguridad pueden usar como puntos de búsqueda e inteligencia operacional. Estos son dos ejemplos de IoC relevantes vinculados:
- 90937b3a64cc834088a0628fda9ce5bd2855bedfc76b7a63f698784c41da4677
- a795b79f1d821b8ea7b21c7fb95d140512aaef5a186da49b9c68d8a3ed545a89
Más allá de los IoC, conviene supervisar eventos de ‘Code Integrity’ y DeviceGuard, y poner alertas sobre cambios en ‘ConfigCIPolicyFilePath’ y ‘DeployConfigCIPolicy’. La detección de despliegues de políticas WDAC fuera de proceso de cambio, o en momentos atípicos, es una señal roja.
También vale la pena prestar atención a adjuntos o descargas de supuestos documentos que en realidad aplican políticas WDAC maliciosas. Este patrón encaja con campañas que buscan persistencia y silenciamiento de defensas para preparar el terreno a amenazas mayores, como ransomware.
Repercusiones para empresas y administraciones
Si un atacante logra impedir la carga del EDR y de Defender, el entorno cae en una especie de penumbra operativa: se reduce la visibilidad, se debilitan las correlaciones y las capacidades de respuesta, y sube el riesgo de movimiento lateral, exfiltración y cifrado. Para un SOC, esto supone, literalmente, un cambio de juego.
El salto de Krueger a DreamDemon demuestra que las técnicas contra WDAC han madurado y se han industrializado. Por eso hoy es crítico elevar la observabilidad sobre la cadena de confianza del endpoint, instrumentar la telemetría de integridad de código y cerrar grietas de gestión de políticas.
Recomendaciones y mitigación
A nivel preventivo, el primer paso es reforzar el control de cambios sobre WDAC y Defender, y conocer cómo blindar Windows. Procura versionar, revisar y validar firma/autoría antes de aplicar cualquier SiPolicy.p7b o política complementaria, y custodia el pipeline de despliegue para que solo se usen orígenes confiables.
- Restringir privilegios de administrador y exigir MFA para tareas de seguridad y despliegue de políticas, reduciendo la superficie de abuso de credenciales privilegiadas.
- Auditar y alertar sobre modificaciones en DeviceGuard (especialmente ‘ConfigCIPolicyFilePath’ y ‘DeployConfigCIPolicy’) y eventos de integridad de código.
- Activar y verificar la Protección contra alteraciones (Tamper Protection) de Microsoft Defender en todos los endpoints para evitar manipulaciones locales.
- Endurecer EDR/AV: listas de permitidos controladas, bloqueo de controladores no firmados y revisión recurrente de reglas.
- Priorizar actualizaciones de Windows y aplicaciones: parches y detecciones mejoran la resistencia frente a técnicas emergentes.
- Formación al usuario: especial cautela con adjuntos y supuestos ‘PDF’ inesperados; verificar siempre el origen.
WDAC en HoloLens 2: control de apps sin confundirlo con modo quiosco
En HoloLens, WDAC permite bloquear el inicio de aplicaciones. A diferencia del modo quiosco (que oculta apps pero permite iniciarlas), con WDAC puedes verlas pero no ejecutarlas. Además, un dispositivo puede tener varias políticas WDAC y, si coinciden, prevalece la más restrictiva.
Para crear reglas, muchos administradores usan PowerShell y Microsoft Intune. Un primer paso típico es localizar el paquete de la app con algo como ‘Get-AppxPackage -name *nombre*’. Por ejemplo, para Edge, ejecutar ‘Get-AppxPackage -name *edge*’ puede devolver varios resultados, y en esa lista identificas el nombre exacto.
En casos donde el nombre del paquete no es obvio, conviene repetir la consulta con distintas aproximaciones hasta dar con la cadena correcta. Una vez identificado, se añade la regla correspondiente a la política (newPolicy.xml) o vía asistente.
Para apps preinstaladas y de uso común en HoloLens 2, estos son ejemplos de nombres de familia de paquetes que se suelen incluir en reglas (extracto representativo):
| Aplicación | PackageFamilyName |
|---|---|
| Visor 3D | Microsoft.Microsoft3DViewer_8wekyb3d8bbwe |
| App Installer | Microsoft.DesktopAppInstaller_8wekyb3d8bbwe |
| Calendario / Correo | microsoft.windowscommunicationsapps_8wekyb3d8bbwe |
| Cámara | HoloCamera_cw5n1h2txyewy |
| Feedback Hub | Microsoft.WindowsFeedbackHub_8wekyb3d8bbwe |
| Microsoft Store | Microsoft.WindowsStore_8wekyb3d8bbwe |
| Películas y TV | Microsoft.ZuneVideo_8wekyb3d8bbwe |
| OneDrive | microsoft.microsoftskydrive_8wekyb3d8bbwe |
| Fotos | Microsoft.Windows.Photos_8wekyb3d8bbwe |
| Configuración | HolographicSystemSettings_cw5n1h2txyewy |
Si quieres bloquear el nuevo Microsoft Edge específicamente, puedes añadir una regla de denegación por nombre de archivo, por ejemplo: <Deny FriendlyName='C:\\Data\\Programs FileRule' PackageVersion='65535.65535.65535.65535' FileName='msedge.exe' />. Esta directiva impedirá la ejecución del binario indicado.
Cuando no tienes la app en la lista, Device Portal es un recurso útil. Conecta el HoloLens 2, entra en Vistas > Aplicaciones, selecciona la app y localiza el PackageRelativeID. Copia lo que hay antes del signo ‘!’ para obtener el PackageFamilyName que podrás usar en WDAC.
Windows Admin Center y entornos aplicados a WDAC
WDAC también sirve para restringir scripts y activar ConstrainedLanguage en PowerShell, algo que afecta a Windows Admin Center (WAC). Al conectarte a un servidor o clúster con WDAC, WAC muestra el estado en la página de Información general, por ejemplo si el lenguaje de PowerShell está en modo restringido.
Requisitos clave: instalación estándar en el host, derechos de administrador local en host y nodos administrados, configuración de red adecuada (WinRM HTTP 5985, HTTPS 5986) y acceso SMB por el puerto TCP 445. Es recomendable que WAC y nodos estén en el mismo dominio o con confianza, sobre todo para autenticación y administración.
Respecto a políticas, hay casos comunes a contemplar. Caso 1: solo los nodos administrados aplican WDAC; basta con autorizar el firmante de Microsoft en la política del nodo. Caso 2: tanto el host de WAC como el nodo aplican WDAC; deberás incluir firmantes adicionales (por ejemplo, Microsoft 3rd Party Application Component y .NET) en el host de WAC.
Ejemplos de reglas de firmante (se pueden generar con el asistente o PowerShell y después revisarlas): <Signer Name='Microsoft Code Signing PCA 2011'><CertRoot Type='TBS' Value='F6F717A43AD9ABDDC8CEFDDE1C505462535E7D1307E630F9544A2D14FE8BF26E' /><CertPublisher Value='Microsoft Corporation' /></Signer>. Para el caso 2, agrega además: <Signer Name='Microsoft Code Signing PCA 2011'><CertRoot Type='TBS' Value='F6F717A43AD9ABDDC8CEFDDE1C505462535E7D1307E630F9544A2D14FE8BF26E' /><CertPublisher Value='Microsoft 3rd Party Application Component' /></Signer> y <Signer Name='Microsoft Code Signing PCA 2011'><CertRoot Type='TBS' Value='F6F717A43AD9ABDDC8CEFDDE1C505462535E7D1307E630F9544A2D14FE8BF26E' /><CertPublisher Value='.NET' /></Signer>.
Si usas versiones de WAC anteriores a la 2410, puede que no necesites la regla de ‘.NET’, pero sí reglas de archivo o hash específicas en el host de WAC. Por ejemplo, permitir librerías de WiX: <FileRules><Allow FriendlyName='WiX wixca.dll' Hash='9DE61721326D8E88636F9633AA37FCB885A4BABE' /><Allow FriendlyName='WiX wixca.dll' Hash='B216DFA814FC856FA7078381291C78036CEF0A05' /><Allow FriendlyName='WiX wixca.dll' Hash='233F5E43325615710CA1AA580250530E06339DEF861811073912E8A16B058C69' /><Allow FriendlyName='WiX wixca.dll 2' Hash='EB4CB5FF520717038ADADCC5E1EF8F7C24B27A90' /><Allow FriendlyName='WiX wixca.dll 2' Hash='6C65DD86130241850B2D808C24EC740A4C509D9C' /><Allow FriendlyName='WiX firewall.dll' Hash='2F0903D4B21A0231ADD1B4CD02E25C7C4974DA84' /><Allow FriendlyName='WiX firewall.dll' Hash='868635E434C14B65AD7D7A9AE1F4047965740786' /><Allow FriendlyName='WiX firewall.dll' Hash='5C29B8255ACE0CD94C066C528C8AD04F0F45EBA12FCF94DA7B9CA1B64AD4288B' /></FileRules>. Esto facilita instalaciones y módulos que WAC necesita.
Sobre la directiva de ejecución de PowerShell, la predeterminada suele ser suficiente. Si se cambia, establece el ámbito ‘LocalMachine’ en ‘RemoteSigned’ para permitir la carga de scripts firmados. Haz cambios solo cuando sea imprescindible y documentando el riesgo.
Problemas conocidos y troubleshooting
Existen algunas limitaciones con WDAC aplicado. Por ejemplo, la implementación de Azure Kubernetes Service en Azure Local y el puente de recursos de Azure Arc vía WAC no están soportadas en entornos con WDAC. También hay restricciones en RBAC en servidor único y en algunas operaciones de la herramienta de certificados.
Si WAC muestra ‘módulo no encontrado’ o ‘no se pudo conectar’, comprueba si los módulos ‘Microsoft.SME.*’ se han transferido al nodo (directorio ‘%PROGRAMFILES%\\WindowsPowerShell\\Modules’). Si no están, reintenta la conexión. Además, verifica que el host WAC tiene acceso al puerto TCP 445 del nodo para la comunicación SMB.
Fileless malware, PowerShell y LOLBins: el contexto perfecto para abusar de WDAC
El malware sin archivos (fileless) no necesita escribir artefactos persistentes en disco para causar estragos: ejecuta todo en memoria o abusa de herramientas integradas, lo que complica su detección. Hubo casos sonados como el compromiso del DNC en 2016, y se han observado campañas (por ejemplo, del grupo Lazarus) con documentos de Word que ejecutan código en memoria usando LOLBins tanto en Windows como en macOS.
Tipos frecuentes de ataques sin archivo incluyen documentos y scripts maliciosos, abuso de ‘Living off the Land Binaries’ (LOLBins) y técnicas de inyección en memoria. La memoria es volátil, así que los atacantes suelen buscar mecanismos de persistencia para sobrevivir a reinicios.
PowerShell y WMI/CIM son favoritos. PowerShell es potentísimo y flexible, y si no se controla la entrada pueden colarse inyecciones de prompt que deriven en ejecución remota, exfiltración o escalado de privilegios. WMI da una capa de administración y suscripciones que también puede explotarse para persistir y moverse.
Entre las herramientas invocadas por atacantes para scripts están ‘powershell.exe’, ‘wscript.exe’, ‘cscript.exe’, ‘cmd.exe’ o ‘mshta.exe’. También se abusa de binarios nativos como ‘regsvr32.exe’, ‘rundll32.exe’, ‘certutil.exe’, ‘schtasks.exe’, ‘bitsadmin.exe’, ‘wmic.exe’, ‘cmstp.exe’, ‘msbuild.exe’, ‘csc.exe’, ‘netsh.exe’, ‘curl.exe’ o incluso utilidades como MpCmdRun.exe del propio Defender. Su combinación sirve para descargar, ejecutar, evadir UAC, moverse lateralmente o intentar sortear controles como WDAC.
En inyección en memoria, llamadas de API como ‘VirtualAllocEx’ y ‘WriteProcessMemory’ permiten que un proceso escriba código en otro. Para ofuscar, hay marcos como Invoke-Obfuscation o Invoke-DOSfuscation en PowerShell. En Linux también existen herramientas de ofuscación para bash (p. ej., Bashfuscator, SHC, etc.).
Para mitigarlo: no abrir adjuntos sospechosos, endurecer RDP, activar logging avanzado de PowerShell (módulos, script block, transcription), auditar WMI en busca de suscripciones raras, deshabilitar macros de Office por directiva cuando aplique, y apostar por seguridad en capas con detección en red y memoria, además de mantener el software actualizado.
Escenarios reales: cuando WDAC bloquea apps legítimas (caso de centro educativo)
Una consulta habitual: un equipo de TI quiere bloquear navegadores portátiles y apps no instaladas ‘como Dios manda’, pero al desplegar una política de prueba en modo auditoría, ve que software educativo legítimo aparece como violación y, si aplicaran la política, quedaría bloqueado. Aun añadiendo reglas de permiso (por ejemplo, permitir todo en ‘C:\\Math’), el visor de eventos muestra bloqueos.
Qué está pasando: WDAC es, por diseño, una tecnología de lista de permitidos, y la precedencia de reglas es relevante (las denegaciones suelen ganar). Además, si hay varias políticas, la más restrictiva prevalece. Por eso, reglas de permiso pueden parecer ignoradas si hay otra capa más restrictiva o si el origen de confianza no está bien establecido.
¿Se puede usar WDAC solo en modo lista de denegados, dejando pasar todo lo demás? No es el enfoque nativo de WDAC y, a largo plazo, es difícil de mantener. Para un arranque más controlado, usa modo auditoría, genera inventario con eventos, refina con reglas por editor (cuando exista), por hash o catálogos para apps sin editor, y evalúa políticas complementarias o el uso de Managed Installer/Intune para establecer confianza.
Si la app no tiene editor ni identificadores firmados, plantéate reglas por carpeta con controles compensatorios (ACL estrictas, control de cambios), aunque lo ideal es migrar hacia reglas por firma y catálogos. Revisa también que el asistente no incluya plantillas demasiado restrictivas para tu escenario; a veces partir de una base más laxa y endurecer iterativamente ayuda a no romper producción.
Ataques de prompt injection en PowerShell y su relación con WDAC
Los ataques de prompt injection manipulan entradas o contextos para inducir a intérpretes a ejecutar comandos maliciosos. En PowerShell esto puede derivar en ejecución remota, exfiltración o compromisos de cuentas de servicio, con especial gravedad si WDAC ha sido neutralizado previamente.
Buenas prácticas: principio de mínimo privilegio, cuentas dedicadas y JEA (Just Enough Administration); evitar ‘Invoke-Expression’, construir argumentos tipados, validar y sanear entradas con listas blancas, exigir firma de scripts, activar AMSI y logging avanzado, y usar AppLocker o WDAC para restringir ejecución. En arquitectura, separar entornos, aislar procesos críticos, controles de red y auditoría centralizada integrada con SIEM.
En pipelines CI/CD, añade SAST, revisiones de código y pruebas de penetración orientadas a inyección. Automatiza validaciones que bloqueen despliegues que no cumplan políticas. Existen empresas especializadas que ofrecen servicios para diseñar defensas, hardening, configuración de AppLocker/WDAC, logging avanzado y respuestas automatizadas integradas con SIEM, además de inteligencia de negocio para visualizar riesgos.
Toda esta foto dibuja un escenario en el que WDAC es a la vez objetivo y aliado: cuando los atacantes lo manipulan para acallar sensores, la organización pierde visibilidad; cuando se administra con cabeza, se convierte en una barrera sólida. La clave está en reforzar la cadena de confianza (políticas firmadas y verificadas), vigilar SiPolicy.p7b y DeviceGuard, endurecer Defender y EDR, mejorar la higiene de PowerShell y reducir superficie de ataque frente a fileless y LOLBins, apoyándose en telemetría y controles de cambio rigurosos.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.