Exploit protection: mitigaciones de sistema y por aplicación

Exploit protection (protección contra vulnerabilidades) es la parte de Windows que dificulta convertir los errores de corrupción de memoria en ejecución de código. Es el sucesor integrado de EMET (Enhanced Mitigation Experience Toolkit), incluido en Windows 10 1709 y posteriores, Windows 11 y Windows Server 2019 y posteriores. Mientras que las reglas ASR bloquean comportamientos sospechosos (Word lanzando PowerShell), exploit protection bloquea las técnicas que usa un exploit para llegar hasta ahí: ejecutar datos, saltar a través de una cadena de programación orientada al retorno, cargar una DLL sin firmar en un proceso endurecido.

El pilar de ASR solo lo menciona de pasada. Esta guía cubre el trabajo completo: lo que ya te dan los valores predeterminados, qué mitigaciones por aplicación merece la pena añadir, cómo probarlas en modo de auditoría y cómo distribuir una única configuración a todo el parque. Para la visión de conjunto del área, consulta Reducción de la superficie de ataque.

Cómo se organiza la configuración

Exploit protection tiene dos capas:

• La configuración del sistema se aplica a todos los procesos salvo que una configuración de aplicación la reemplace.
• La configuración de programas se aplica a un ejecutable concreto (opcionalmente con su ruta completa) y puede activar mitigaciones que serían demasiado disruptivas para todo el sistema.

Cada mitigación puede estar activada, desactivada o en usar predeterminado, y varias admiten un estado de auditoría que registra lo que se habría bloqueado. La misma configuración aparece en Seguridad de Windows > Control de aplicaciones y navegador > Configuración de Protección contra vulnerabilidades, pero en los dispositivos administrados debes controlarla con un archivo XML distribuido por directiva, no a golpe de clic.

La primera tarea es simplemente asegurarse de que nada las haya desactivado. Scripts de imagen antiguos, ajustes para juegos y guías de "rendimiento" desactivan a veces DEP o CFG.

Paso 1: capturar el estado actual

En una máquina de referencia, revisa la configuración efectiva del sistema y por aplicación:

# Mitigaciones de todo el sistema
Get-ProcessMitigation -System

# Una aplicación
Get-ProcessMitigation -Name winword.exe

# Todas las aplicaciones que tienen configuración por programa
Get-ProcessMitigation | Where-Object { $_.ProcessName } |
  Select-Object ProcessName -Unique

Windows ya incluye algunas configuraciones por aplicación, y una instalación limpia es la mejor referencia. Expórtala para poder compararla más adelante:

Get-ProcessMitigation -RegistryConfigFilePath C:\Temp\ep-baseline.xml

Si todavía tienes una directiva de EMET de hace años, conviértela y trátala como una lista de ideas, no como una configuración que aplicar:

ConvertTo-ProcessMitigationPolicy -EMETFilePath C:\Temp\emet.xml -OutputFilePath C:\Temp\ep-from-emet.xml

Paso 2: elegir las mitigaciones por aplicación

Las mitigaciones por aplicación son donde exploit protection demuestra su valor, pero también donde rompe cosas. Céntrate en las aplicaciones que procesan entradas no fiables y que no están ya muy aisladas en un sandbox: lectores de documentos, clientes de negocio heredados que abren archivos del correo, reproductores multimedia, herramientas de compresión y componentes de servidor antiguos expuestos a Internet que todavía no puedes sustituir.

Los navegadores y Office de Microsoft ya habilitan internamente muchas de ellas, y los navegadores basados en Chromium gestionan su propio sandbox. No añadas ACG o CIG encima de Edge o Chrome; configura el navegador (consulta endurecimiento de Edge). Microsoft también advierte de que EAF, IAF y las mitigaciones ROP pueden entrar en conflicto con productos EDR y antitrampas que enganchan las mismas funciones, así que prueba en dispositivos que ejecuten tu pila de seguridad real.

Paso 3: probar en modo de auditoría

Construye la configuración por aplicación en una máquina de prueba, empezando en auditoría cuando la mitigación lo admita:

# Auditar ACG y la creación de procesos hijos para un visor heredado
Set-ProcessMitigation -Name "C:\Program Files\Contoso\Viewer\viewer.exe" `
  -Enable AuditDynamicCode, AuditChildProcess

# Imponer directamente las mitigaciones de bajo riesgo
Set-ProcessMitigation -Name viewer.exe -Enable BlockRemoteImages, BlockLowLabel

Los nombres de parámetros corresponden a las opciones de mitigación (por ejemplo DisallowChildProcessCreation, AuditChildProcess, DynamicCode, AuditDynamicCode, MicrosoftSignedOnly, ForceRelocateImages). La auditoría de EAF, IAF y las mitigaciones ROP no está disponible a través de los cmdlets de PowerShell; configúrala en la aplicación Seguridad de Windows y exporta el XML. Ejecuta Get-Help Set-ProcessMitigation -Full en tu compilación para ver la lista que admite, porque las versiones nuevas añaden opciones.

Exploit protection escribe en dos registros bajo Applications and Services Logs > Microsoft > Windows > Security-Mitigations: KernelMode y UserMode. Cada mitigación auditada tiene un evento de auditoría y otro de imposición; por ejemplo, ACG registra el 1 (auditoría) y el 2 (bloqueado), y la creación de procesos hijos registra el 3 (auditoría) y el 4 (bloqueado). Consulta la referencia de eventos de exploit protection de Microsoft para ver la correspondencia completa en tu compilación.

Get-WinEvent -LogName "Microsoft-Windows-Security-Mitigations/UserMode",
                       "Microsoft-Windows-Security-Mitigations/KernelMode" -MaxEvents 200 |
  Select-Object TimeCreated, LogName, Id, Message

Usa la aplicación con normalidad durante una o dos semanas: abre los archivos poco habituales, imprime, ejecuta la búsqueda de actualizaciones, usa los complementos. Si no hay eventos de auditoría, la mitigación se puede imponer. Si hay eventos en un flujo de trabajo real, deja esa mitigación desactivada o pide una corrección al proveedor.

Paso 4: exportar y desplegar el XML

Cuando la máquina de prueba se comporte bien, exporta la configuración completa. El archivo contiene a la vez la configuración del sistema y la de las aplicaciones:

Get-ProcessMitigation -RegistryConfigFilePath \\corp.example\NETLOGON\ExploitProtection\ep-settings.xml

Directiva de grupo. Coloca el XML en un recurso compartido que los equipos puedan leer y establece Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Defender Exploit Guard > Exploit Protection > Use a common set of exploit protection settings en Enabled con la ruta UNC. Los archivos ADMX recientes pueden mostrar la carpeta como Microsoft Defender Exploit Guard. La directiva guarda la ruta en HKLM\SOFTWARE\Policies\Microsoft\Windows Defender ExploitGuard\Exploit Protection y el dispositivo aplica el archivo en la siguiente actualización.

Intune. Usa Endpoint security > Attack surface reduction > Create policy > Exploit Protection y pega o carga el XML. El CSP subyacente es ExploitGuard/ExploitProtectionSettings.

Bloquéalo. Impide los cambios locales desde la aplicación Seguridad de Windows con Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Security > App and browser protection > Prevent users from modifying settings (en Intune, la configuración Disallow Exploit Protection Override del mismo perfil).

Trata el XML como código: mantenlo en control de versiones, cámbialo mediante una pull request y despliégalo por anillos, como harías con las reglas ASR o una línea base de seguridad.

Qué se rompe

• El ASLR obligatorio en todo el sistema es la clásica interrupción autoinfligida: los instaladores y DLL antiguos sin datos de reubicación se bloquean al cargarse. Mantenlo por aplicación.
• CIG y ACG en aplicaciones con complementos o un JIT fallan en silencio o se bloquean al usar el complemento por primera vez.
• Do not allow child processes impide que la aplicación abra un navegador para los enlaces de ayuda, lance su actualizador o llame a una impresora PDF.
• Disable extension points rompe los métodos de entrada de Asia oriental y algunas herramientas de accesibilidad.
• EAF/IAF y las mitigaciones ROP pueden chocar con los enlaces del EDR. El síntoma es un bloqueo en la DLL del producto de seguridad, no en la aplicación.
• Hardware-enforced stack protection solo funciona en CPU compatibles con CET y, en modo estricto, bloqueará las DLL incompatibles cargadas en el proceso.

Cuando algo se rompe tras el despliegue, Get-ProcessMitigation -Name app.exe en el dispositivo afectado te dice qué se aplica realmente, y los registros Security-Mitigations te dicen qué mitigación se activó.

Verificarlo

En una muestra de dispositivos, tras la actualización de directivas:

# Valores predeterminados del sistema intactos
Get-ProcessMitigation -System | Format-List DEP, ASLR, CFG, SEHOP, Heap

# Tu configuración por aplicación aplicada
Get-ProcessMitigation -Name viewer.exe

# Ruta de la directiva presente
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender ExploitGuard\Exploit Protection" -ErrorAction SilentlyContinue

Reenvía ambos registros Security-Mitigations a tu SIEM. Un pico repentino de eventos de imposición en un host es o una actualización rota o un intento de explotación, y ambos merecen una revisión.

Dónde encaja

Exploit protection es una capa de la seguridad de memoria. En el lado del kernel, la integridad de memoria (HVCI) y VBS protegen el kernel frente a la misma clase de ataques, y en Windows 11 con HVCI y una CPU compatible con CET también puedes activar la protección de pila aplicada por hardware en modo kernel desde Seguridad de Windows > Seguridad del dispositivo > Aislamiento del núcleo. Por encima, el control de aplicaciones decide qué puede ejecutarse. Para el término en sí, consulta la entrada del glosario sobre exploit protection.

Lista de comprobación

• Mitigaciones del sistema (DEP, CFG, ASLR ascendente y de alta entropía, SEHOP, integridad del montón) verificadas como activadas en todo el parque
• Aplicaciones heredadas expuestas identificadas y mitigaciones por aplicación elegidas
• Mitigaciones probadas en modo de auditoría, eventos Security-Mitigations revisados
• XML exportado, versionado y desplegado por GPO o Intune
• Reemplazo local bloqueado con Prevent users from modifying settings
• Registros Security-Mitigations reenviados y con alertas