Después de la actualización acumulativa de febrero KB5051989, numerosos administradores han descubierto que los kioscos de Windows 11 23H2 dejan de aplicar correctamente las reglas de AppLocker, permitiendo la ejecución de scripts y ejecutables renombrados que antes eran bloqueados. Este artículo explica el origen del fallo, su impacto real, las mitigaciones inmediatas y los pasos a seguir hasta que Microsoft publique un parche oficial.
Contexto y síntomas observados
El escenario más habitual se da en dispositivos configurados como kiosco de aplicaciones múltiples. En este modo, el sistema carga automáticamente un conjunto limitado de aplicaciones aprobadas y, mediante AppLocker, bloquea cualquier ejecutable no autorizado. Tras instalar la KB5051989:
- Las reglas basadas en ruta (
Path) o nombre (File Name) dejan de interceptar archivos que se copian y se renombran en carpetas de usuario. - Ejecutables clásicos como
cmd.exeopowershell.exe, rebautizados comomsedge.exeo cualquier otro nombre permitido, se inician sin restricciones. - El visor de eventos (Event Viewer) ya no registra la denegación (
Audit Fail) que estaba presente antes del parche.
Análisis técnico del fallo
AppLocker evalúa en cascada cuatro tipos de reglas: Publisher, Path, File Hash y Package App. El problema radica en la segunda capa (Path), que compara la ruta y el nombre contra los patrones definidos por el administrador. Desde la KB5051989, el mecanismo de verificación:
- Permite que un ejecutable herede implícitamente la reputación del nombre bajo el que se ejecuta, ignorando su binario real.
- No reevalúa el hash cuando la regla de tipo Path coincide, por lo que la entrada no pasa a la capa de comprobación de File Hash.
- Asume que el kiosco ejecuta solo aplicaciones UWP, reduciendo la vigilancia sobre los procesos Win32 en rutas de usuario.
El resultado es un bypass por renombrado: basta con copiar cualquier ejecutable prohibido a una ubicación controlada por el usuario y renombrarlo con un nombre autorizado (p. ej. msedge.exe), para que el sistema lo ejecute sin restricciones.
Comparativa antes y después de la KB5051989
| Acción | Estado antes (Enero 2025) | Estado después (Febrero 2025) |
|---|---|---|
Copiar cmd.exe a C:\Kiosk\ | Bloqueado | Bloqueado |
Renombrar cmd.exe a msedge.exe en C:\Users\Public\ | Bloqueado | Permitido |
Ejecutar msedge.exe renombrado | Error de AppLocker (ID 8007) | Ejecución sin evento de denegación |
Impacto en entornos de kiosco
Un kiosco de aplicaciones múltiples suele encontrarse en entornos de autoservicio: salas de espera, quioscos de información turística, terminales de check‑in, etc. El propósito fundamental es limitar drásticamente la superficie de ataque. Con este fallo:
- Se abre la puerta a una escalada de privilegios local: basta con lanzar
cmd.exeopowershell.exepara manipular servicios, drivers o incluso descargar malware. - Se rompe la premisa de confianza cero que guía la estrategia de kiosco; el usuario final obtiene un intérprete de comandos con acceso al sistema de archivos.
- Los controles de auditoría pierden visibilidad, ya que AppLocker no registra la omisión.
Escalada y respuesta oficial
El incidente ya ha sido escalado a Microsoft mediante Feedback Hub (ID interno compartido por los ingenieros de soporte) y replicado en el foro de Microsoft Learn (sección Windows — Microsoft Q&A). A día de hoy no existe un parche correctivo ni una fecha pública para su publicación. El hilo original en la comunidad permanece cerrado a la espera de respuesta, lo cual confirma que Microsoft reconoce la regresión y la investiga.
Acciones provisionales sugeridas
Mientras llega la actualización de corrección, los administradores pueden:
- Bloquear o aplazar la KB5051989 en entornos de producción sensibles. Si se usa WSUS, Intune o directivas de grupo (WUSA /hide), marque el parche como no aprobado. Para lotes pequeños, emplee el solucionador de problemas de Windows Update.
- Cambiar reglas de Path a File Hash o Publisher. Estas últimas comprueban la firma digital y el hash, dificultando el bypass por renombre.
- Evaluar la migración a Windows Defender Application Control (WDAC), cuya validación está más vinculada al binario y no al nombre de archivo.
- Implementar un riguroso laboratorio de pruebas para validar cada Patch Tuesday antes de desplegarlo en los kioscos.
- Monitorizar continuamente los log de Microsoft‑Windows‑AppLocker/EXE and DLL en modo
AuditOnlypara detectar actividad anómala.
Estrategia de mitigación paso a paso
- Crear una política de grupo (GPO) adicional con reglas AppLocker actualizadas (hash/publisher) y vincularla solo a la OU de pruebas.
- Activar el modo “Solo auditoría” durante 48 horas para registrar todos los ejecutables lanzados sin bloquearlos. Esto ayuda a detectar programas legítimos que quedarían fuera.
- Analizar los eventos con un script de PowerShell:
Get-WinEvent -LogName ‘Microsoft-Windows-AppLocker/EXE and DLL’ ` | Where-Object {$_.Id -eq 8003} ` | Select-Object TimeCreated, Message - Ajustar excepciones e incorporar firmas de editor válidas para las aplicaciones permitidas.
- Conmutar a modo “Enforcement” y medir la tasa de errores durante otra ventana de observación.
- Desplegar gradualmente la nueva GPO a los kioscos en producción, conservando un plan de reversión que incluya snapshots o medios de recuperación.
Ventajas de WDAC frente a AppLocker
| Característica | AppLocker | WDAC |
|---|---|---|
| Enfoque | Lista blanca de rutas/nombres | Validación de firma y código |
| Protección contra renombrados | Baja | Alta |
| Soporte en modo kiosco | Nativo pero flexible | Incluye managed installer |
| Manejo por Intune | Sí | Sí (plantillas CSP) |
| Complejidad de despliegue | Baja | Media/Alta |
Preguntas frecuentes
¿Qué versiones exactas están afectadas?
Solo Windows 11 23H2 con la actualización KB5051989 instalada. Versiones 22H2 y 21H2 no muestran el problema en pruebas internas.
¿Es necesario desinstalar completamente el parche?
No. Si el kiosco no ejecuta aplicaciones Win32 sensibles o ya usa reglas por hash, puede mantenerse. Solo desinstale si depende de reglas de Path.
¿Microsoft recomienda WDAC sobre AppLocker?
Desde 2022 Microsoft posiciona WDAC como la solución de seguridad moderna. No obstante, AppLocker sigue siendo compatible; no hay anuncio de retirada.
Próximos pasos recomendados
- Vigilar el hilo en Microsoft Learn y el Feedback Hub para recibir noticias sobre el parche oficial.
- Documentar el hallazgo en la base de conocimiento interna y avisar a otros equipos de TI responsables de kioscos.
- Mantener un procedimiento de reversión listo por si la vulnerabilidad reaparece tras actualizaciones mensuales.
- Programar revisiones trimestrales de la estrategia de control de aplicaciones, evaluando la adopción gradual de WDAC.
Conclusión
El fallo introducido por la KB5051989 supone una regresión crítica para quienes confían en AppLocker en modo kiosco. Microsoft ya investiga el problema, pero la solución aún no está disponible. A corto plazo, las organizaciones deben aplazar la actualización o reforzar sus reglas mediante hash o publisher y considerar el salto paulatino hacia WDAC. Con una estrategia de auditoría continua y despliegues escalonados, es posible mantener la integridad de los kioscos mientras se aguarda el parche oficial.