MiniPlasma y cldflt.sys: la carrera de privilegios que podría convertir Windows parcheado en SYSTEM

El investigador conocido como Chaotic Eclipse publicó recientemente un proof‑of‑concept (PoC) que aprovecha una vulnerabilidad de escalada de privilegios en Windows, bautizada como MiniPlasma, que supuestamente permite a un atacante obtener privilegios SYSTEM en máquinas aparentemente totalmente parcheadas. El fallo está localizado en el controlador de filtro de archivos en la nube de Windows, cldflt.sys, en una rutina denominada HsmOsBlockPlaceholderAccess; según el autor, la misma raíz del problema fue reportada originalmente por James Forshaw de Google Project Zero en 2020.

La historia técnica es relevante: en septiembre de 2020 Forshaw describió un problema que Microsoft mitigó en diciembre de ese año bajo CVE‑2020‑17103, pero Chaotic Eclipse afirma que la condición original —una race condition en el código del mini‑filtro— sigue presente en la práctica y que el PoC original funciona sin cambios para producir una consola con privilegios SYSTEM. La naturaleza de las race conditions hace que la explotación sea dependiente de timmings y del entorno, pero precisamente por eso pueden ser difíciles de corregir de forma fiable y permanecer latentes tras parches aparentes; para contexto técnico general se pueden consultar trabajos de Project Zero y los avisos de Microsoft sobre vulnerabilidades: Google Project Zero y Microsoft Security Response Center.

Las implicaciones prácticas son claras y graves: una escalada local a SYSTEM abre la puerta para control total del equipo, persistencia, instalación de backdoors y avance lateral en redes corporativas. Varios investigadores externos, entre ellos Will Dormann, indicaron que la explotación funciona de forma fiable en sistemas Windows 11 con las actualizaciones de mayo de 2026, aunque no en todas las ramas de Insider; esto sugiere que el problema no está limitado a una versión concreta y que su riesgo es significativo en entornos heterogéneos.

Históricamente no es la primera vez que el componente cldflt.sys figura en avisos de seguridad: Microsoft también trató en diciembre de 2025 otra vulnerabilidad de escalada en el mismo driver (CVE‑2025‑62221) identificada como explotada en el campo. Ese antecedente subraya dos puntos: por un lado, que controladores relacionados con la integración de almacenamiento en la nube son objetivos atractivos por su posición en la pila del sistema; por otro, que las mitigaciones pueden requerir revisiones profundas y pruebas para evitar regresiones o parches incompletos.

¿Qué pueden y deben hacer administradores y responsables de seguridad ahora mismo? En primer lugar, no asumir que “parcheado” significa ausencia de riesgo: revisar avisos oficiales y aplicar todas las actualizaciones recomendadas por Microsoft. Complementariamente, conviene reforzar controles compensatorios: reducir privilegios locales al mínimo necesario, aplicar políticas de bloqueo de ejecución y whitelisting, configurar reglas del EDR y del SIEM para detectar procesos inesperados ejecutándose como NT AUTHORITY\\SYSTEM (por ejemplo cmd.exe o powershell.exe iniciados con ese token), y segmentar estaciones con acceso a datos críticos para limitar el impacto de una escalada local. Para la administración centralizada y búsqueda de CVE se puede consultar bases públicas como la NVD: NVD.

Para usuarios finales las recomendaciones son prácticas y sencillas: mantener Windows actualizado, evitar ejecutar código de orígenes no confiables con privilegios elevados y considerar, cuando sea viable, desactivar características de integración de nube que no se utilicen (por ejemplo Files On‑Demand de OneDrive) hasta que haya claridad sobre parches definitivos; estas medidas reducen la superficie de ataque al componente afectado. Las pruebas de explotación deben limitarse a entornos de laboratorio controlados: ejecutar un PoC en producción puede comprometer sistemas y dejar evidencia difícil de limpiar.

Finalmente, es importante recordar que la publicación de PoC públicos acelera la necesidad de respuestas coordinadas: los equipos de respuesta a incidentes deben priorizar la detección de escaladas locales, revisar telemetría histórica en busca de ejecuciones sospechosas como SYSTEM shells y preparar planes de contención. Mantener comunicación con proveedores, seguir el canal oficial de Microsoft para actualizaciones y validar parches en entornos de prueba antes de desplegarlos masivamente son prácticas que hoy resultan más críticas que nunca.