Hardening de Windows:

ASR rules, AppLocker y WDAC contra la ejecución no deseada

Serie Blue Team / Windows  |  unfantasmaenelsistema.com

La mayoría de los compromisos de un puesto Windows no empiezan con un exploit sofisticado, sino con algo que el usuario ejecuta sin querer: una macro dentro de un documento, un instalador falso, un acceso directo que en realidad lanza PowerShell. A partir de ahí la cadena es casi siempre la misma: un binario legítimo del sistema (rundll32, mshta, regsvr32) descarga y ejecuta la siguiente fase. Firmar reglas de detección para cada paso es agotador. Impedir que esos pasos se puedan dar es mucho más eficaz.

Windows trae de serie tres controles que atacan justo ese problema, cada uno con un coste de despliegue distinto: las reglas de reducción de superficie de ataque (ASR), AppLocker y Windows Defender Application Control (WDAC, ahora «App Control for Business»). Este artículo explica qué hace cada uno, en qué orden conviene adoptarlos y cómo desplegarlos sin dejar la empresa sin poder trabajar el lunes por la mañana.

1. El problema: LOLbins y por qué el allowlisting es la respuesta

Un LOLbin (Living Off the Land binary) es un ejecutable que ya viene firmado por Microsoft y presente en cualquier Windows, pero que puede usarse para algo distinto de su función original: descargar un fichero, ejecutar código, saltarse una restricción. rundll32.exe puede ejecutar una función exportada de una DLL arbitraria; mshta.exe interpreta HTML con VBScript o JScript embebido; regsvr32.exe puede cargar un scriptlet remoto con la técnica conocida como «Squiblydoo». Ninguno es malware, así que un antivirus basado en firmas no los va a bloquear por sí mismos.

La detección por comportamiento ayuda, pero siempre va por detrás: alguien tiene que haber visto antes esa combinación concreta de proceso padre, proceso hijo y argumentos. El allowlisting invierte el planteamiento: en lugar de enumerar lo que está prohibido —una lista infinita y siempre incompleta— se define lo que está permitido ejecutar, y todo lo demás se deniega por defecto. En un parque de equipos corporativos, donde el software legítimo es un conjunto conocido y estable, esa lista es abarcable.

2. ASR rules: el control de menor coste y mayor retorno

Las reglas de reducción de superficie de ataque son parte de Microsoft Defender y funcionan como bloqueos puntuales de comportamientos concretos, no como una lista de aplicaciones. Se activan una a una, cada una en modo auditoría (solo registra) o bloqueo (impide y registra). Requieren que Defender Antivirus sea el motor activo y con protección en tiempo real. Se despliegan por GPO, Intune, PowerShell o Configuration Manager.

Su gran ventaja es que no necesitan un inventario previo de software: cada regla ataca una técnica que casi ninguna aplicación legítima usa. Su límite es que son un catálogo cerrado —no puedes escribir las tuyas— y que algunas generan falsos positivos con software de nicho, por lo que el modo auditoría antes de forzar no es opcional.

2.1 Las reglas que más cadenas cortan

2.2 Cómo se registra y se mide

Cada disparo de una regla ASR queda en el canal Microsoft-Windows-Windows Defender/Operational. Los Event ID que interesan:

El flujo correcto es: activar todas las reglas candidatas en auditoría, dejarlas una o dos semanas, recoger los 1122 con el nombre de regla y el proceso implicado, decidir regla por regla si el ruido es asumible, crear exclusiones muy concretas para el software legítimo afectado y solo entonces pasar esas reglas a bloqueo.

# Ver el estado actual de las reglas ASR (ID y accion: 0=off 1=block 2=audit 6=warn)
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions
 
# Poner una regla en AUDIToria (ejemplo: hijos de Office)
Set-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a `
                 -AttackSurfaceReductionRules_Actions AuditMode
 
# Recoger lo que se HABRIA bloqueado en los ultimos 7 dias (Event ID 1122)
Get-WinEvent -FilterHashtable @{
  LogName='Microsoft-Windows-Windows Defender/Operational'; Id=1121,1122;
  StartTime=(Get-Date).AddDays(-7) } |
  Select-Object TimeCreated, Id, Message | Format-List

3. AppLocker: allowlisting clásico y sus grietas

AppLocker es el mecanismo de control de aplicaciones que Windows arrastra desde 2009. Define reglas sobre cinco colecciones —ejecutables, instaladores (MSI), scripts, DLL y aplicaciones empaquetadas— y se aplica a usuarios o grupos. Se gestiona por GPO y depende del servicio Application Identity (AppIDSvc), que debe estar en arranque automático.

3.1 Los tres tipos de regla

El planteamiento recomendado por Microsoft parte de las reglas por defecto: permitir todo lo que esté en \Windows y \Program Files (rutas que un usuario estándar no puede modificar) más lo que necesite cada aplicación de negocio, preferiblemente por editor. Todo lo que quede fuera —el perfil del usuario, %TEMP%, descargas, unidades USB— deja de poder ejecutarse.

3.2 Modo auditoría primero, siempre

Como con ASR, AppLocker tiene un modo «solo auditar» por colección. En auditoría, cada ejecución que se habría bloqueado genera un evento en Microsoft-Windows-AppLocker/EXE and DLL (y los canales hermanos MSI and Script, etc.):

# Generar un juego de reglas base a partir de lo instalado en un equipo de referencia
Get-AppLockerFileInformation -Directory C:\Windows -Recurse -FileType Exe,Script |
  New-AppLockerPolicy -RuleType Publisher,Hash -User Everyone `
                      -Xml -Optimize | Out-File .\base-applocker.xml
 
# Ver que se HABRIA bloqueado (Event ID 8003) en la ultima semana
Get-WinEvent -FilterHashtable @{
  LogName='Microsoft-Windows-AppLocker/EXE and DLL'; Id=8003;
  StartTime=(Get-Date).AddDays(-7) } |
  Select-Object TimeCreated,
    @{n='File'; e={$_.Properties[10].Value}},
    @{n='User'; e={$_.Properties[7].Value}} | Sort-Object File -Unique

3.3 Bypass conocidos: por qué AppLocker no es el final del camino

• Rutas escribibles dentro de \Windows. Carpetas como \Windows\Tasks, \Windows\System32\spool\drivers\color o \Windows\Temp son escribibles por un usuario estándar y quedan permitidas por la regla por defecto de \Windows. Hay que excluirlas explícitamente
• LOLbins que ejecutan código sin ser el binario. Si rundll32, mshta, regsvr32, InstallUtil o msbuild están permitidos (lo están por la regla de \Windows), pueden interpretar código que AppLocker no evalúa como «fichero a ejecutar». La lista de LOLBAS documenta decenas
• DLL sin aplicar la colección de DLL. Si no se activa el control de DLL (está desactivado por defecto por su coste de rendimiento y mantenimiento), una aplicación permitida puede cargar una DLL arbitraria del perfil del usuario
• Scripts en intérpretes no cubiertos. La colección Script cubre .ps1, .bat, .cmd, .vbs y .js, pero no un intérprete de terceros (Python, AutoIt) que se haya permitido como ejecutable

4. WDAC / App Control for Business: el control fuerte

WDAC (rebautizado App Control for Business en Windows 11) es la evolución del concepto. A diferencia de AppLocker, no es una directiva que se aplica a usuarios, sino una política de integridad de código que se evalúa en el arranque y afecta a todo el sistema, incluido el kernel y las DLL, sin coste extra de configuración para cubrirlas. Puede anclarse al hardware con arranque seguro para que ni un administrador local pueda desactivarla sin más.

4.1 En qué se apoya para decidir

• Firma y editor, igual que AppLocker pero de forma más granular (por EKU, por versión mínima)
• Atributos del fichero y catálogos firmados que la propia organización genera para software sin firmar
• Identidad de la aplicación empaquetada y reputación mediante el Intelligent Security Graph (ISG), que permite «confiar en lo que Microsoft considera de buena reputación» como punto de partida
• Reglas de ruta, admitidas pero desaconsejadas por los mismos motivos que en AppLocker

4.2 Por qué su curva de despliegue es más dura

WDAC deniega por defecto de forma mucho más estricta, así que un modelo incompleto deja el equipo sin arrancar aplicaciones —o sin arrancar—. El proceso realista es: partir de una de las plantillas base de Microsoft (por ejemplo la política «Windows works» o la recomendada para bloquear los binarios de doble uso), desplegarla en modo auditoría (la política lleva la opción «Audit Mode»), recoger los eventos de Microsoft-Windows-CodeIntegrity/Operational, y usar herramientas como el WDAC Wizard o `ConvertFrom-CIPolicy` para ir ampliando el modelo con lo que la organización realmente usa antes de quitar el modo auditoría.

5. Cómo elegir y en qué orden desplegar

Para casi cualquier organización el camino sensato es incremental:

• Fase 0 — base. Usuarios sin permisos de administrador local, Defender Antivirus activo con protección en la nube, y el registro de eventos dimensionado y reenviado (ver el artículo de logs de eventos de Windows)
• Fase 1 — ASR en auditoría. Activar todas las reglas candidatas en modo auditoría, medir dos semanas, crear exclusiones concretas y forzar primero las de bajo impacto
• Fase 2 — AppLocker en auditoría. Generar reglas base por editor sobre un equipo de referencia, desplegar en auditoría, revisar los 8003, añadir el bloqueo explícito de LOLbins y de rutas escribibles, y forzar por colecciones (EXE y MSI antes que Script)
• Fase 3 — WDAC si procede. En los endpoints que lo justifiquen, plantilla base + auditoría prolongada + ampliación guiada con el WDAC Wizard antes de forzar
• Siempre. Todo cambio pasa por auditoría antes que por bloqueo; nada se fuerza el mismo día que se diseña

Conclusión

Detectar cada eslabón de una cadena de macro a LOLbin es un trabajo sin fin. Impedir que esos eslabones se puedan encadenar —que Office no lance procesos hijo, que no se ejecute nada desde el perfil del usuario, que los binarios de doble uso estén bloqueados— corta la mayoría de los ataques de puesto antes de que el EDR tenga que opinar.

Los tres controles están incluidos en Windows y se despliegan de menos a más esfuerzo: ASR rules el primer día, AppLocker cuando el inventario de software es estable, y WDAC donde el riesgo lo justifica. La regla de oro es la misma para los tres: auditoría primero, medición honesta del ruido, exclusiones quirúrgicas y solo entonces el modo bloqueo, siempre por anillos y siempre con una vía de vuelta.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)