El software anti-cheat a nivel de kernel se ha convertido silenciosamente en una de las mayores superficies de ataque del gaming en PC
El software anti-cheat a nivel de kernel se ejecuta hoy con los mismos privilegios que tu motor antivirus en decenas de millones de PC, y ese acceso se ha convertido en una de las superficies más explotables de la informática de consumo. Vanguard de Riot Games, Easy Anti-Cheat (EAC), BattlEye y Denuvo Anti-Cheat cargan todos un controlador firmado en el anillo 0 del kernel de Windows, el mismo nivel de privilegio que el propio sistema operativo, para detectar trucos de manipulación de memoria que las herramientas en modo usuario no pueden ver. El problema es que un controlador con suficiente confianza para inspeccionar cada proceso en memoria también tiene suficiente confianza para desactivar herramientas de seguridad, y los atacantes han estado explotando silenciosamente esa confianza desde al menos 2022.
Esto no es hipotético. Los investigadores de seguridad y la propia Vulnerable Driver Blocklist (VBL) de Microsoft han señalado repetidamente a controladores de anti-cheat y de videojuegos firmados como un vector de «bring your own vulnerable driver» (BYOVD): los atacantes cargan un controlador legítimamente firmado pero con una vulnerabilidad conocida, y luego usan el acceso al kernel que este otorga para matar procesos EDR antes de desplegar ransomware. Este patrón ha aparecido en incidentes vinculados a BlackByte y otros grupos de ransomware, que prefieren controladores vulnerables precisamente porque llevan una firma válida de Microsoft y superan las comprobaciones de firma de código que bloquearían directamente un módulo de kernel sin firmar.
Cómo un controlador de confianza se convierte en un arma
El mecanismo subyacente es simple. Windows exige que los controladores en modo kernel estén firmados, ya sea directamente por Microsoft o mediante el programa WHQL (Windows Hardware Quality Labs), para evitar que se ejecute código arbitrario en el nivel de privilegio más alto. Los proveedores de anti-cheat necesitan ese nivel de acceso para leer la memoria de procesos rivales, interceptar llamadas al sistema y detectar depuradores, todo lo que un proceso de trucos en modo usuario ocultaría. Así que el proveedor consigue que un controlador legítimamente firmado se instale en cada máquina que ejecuta el juego.
Si ese controlador tiene un error, por ejemplo un manejador IOCTL expuesto que permite a cualquier proceso de la máquina enviarle comandos, un atacante ni siquiera necesita su propio controlador malicioso. Carga el controlador anti-cheat ya firmado y confiable, se comunica con su interfaz expuesta, y usa sus privilegios de kernel para terminar procesos protegidos, incluidos agentes EDR de CrowdStrike, SentinelOne o Microsoft Defender for Endpoint. Esto es exactamente lo que ocurrió con el controlador mhyprot2.sys de miHoYo, incluido originalmente con el sistema anti-cheat de Genshin Impact: exponía funciones que permitían a cualquier proceso local terminar arbitrariamente otros procesos, y operadores de ransomware lo adoptaron precisamente porque era un binario firmado y limpio, sin firma de malware evidente.
El problema de escala
El controlador anti-cheat de Capcom tenía una falla similar de terminación arbitraria de procesos, revelada en 2020. El controlador de Genshin Impact seguía instalado y en ejecución en algunos sistemas incluso después de desinstalar el propio juego, porque la rutina de instalación nunca incluyó un desinstalador para el componente de kernel, un detalle que solo atrajo mayor atención cuando investigadores de seguridad comenzaron a catalogar qué «LOLDrivers» (living-off-the-land drivers) estaban reutilizando los grupos de ransomware. La VBL de Microsoft, distribuida mediante Windows Update y App Control for Business, ahora bloquea por hash decenas de versiones específicas de controladores anti-cheat y utilidades de juego, pero la lista sigue siendo reactiva: un controlador debe ser atrapado siendo explotado en el mundo real antes de añadirse, y nuevas versiones de controladores anti-cheat se lanzan constantemente mientras los proveedores corrigen los bypasses.
La escala importa aquí más que cualquier incidente aislado. Valorant por sí solo supera los 20 millones de jugadores activos mensuales, y Vanguard se instala al arrancar, antes de que cargue la interfaz del sistema operativo, precisamente para que las herramientas de trucos no puedan desactivarlo durante una partida. EAC y BattlEye cubren juntos cientos de títulos competitivos. Eso es un binario con privilegios de kernel, controlado por un proveedor externo en lugar del fabricante del sistema operativo, instalado en una base enorme, y a diferencia de un proveedor de antivirus, la mayoría de los proveedores de anti-cheat nunca han pasado por el tipo de auditoría de seguridad adversarial que enfrentan rutinariamente los productos EDR, porque su modelo de amenazas se diseñó para atrapar tramposos, no para resistir investigación de explotación de controladores de nivel estatal.
Por qué esto sigue repitiéndose
Los proveedores de anti-cheat enfrentan un problema de incentivos estructural: cada nueva capacidad de kernel que añaden para detectar un truco más sofisticado es también una nueva capacidad que un atacante puede explotar, pero el indicador clave del proveedor es la tasa de detección de trucos, no la minimización de la superficie de ataque. Rediseñar estos sistemas para que funcionen en modo usuario con capacidades más limitadas, la dirección que Valve ha tomado con el diseño mayormente en modo usuario de VAC para Steam, aceptando un techo de detección más bajo a cambio de una huella de kernel drásticamente menor, es un compromiso real que la mayoría de los editores se ha negado a asumir, porque las quejas sobre integridad competitiva mueven las valoraciones y el número de jugadores más rápido que una CVE teórica de un controlador.
Microsoft también ha estado empujando a los proveedores hacia sus marcos Kernel-Mode Hardware-Enforced Stack Protection y HVCI (Hypervisor-Protected Code Integrity), que restringen lo que un controlador de kernel puede hacer incluso con una firma de código válida, pero la adopción es opcional y lenta porque puede romper la lógica de detección del anti-cheat, que depende de una amplia visibilidad de la memoria. Hasta que la contención tipo HVCI se vuelva obligatoria en lugar de opcional, el modelo de confianza basado en controladores firmados que hace funcionar al anti-cheat seguirá siendo el mismo que lo convierte en un objetivo duradero de BYOVD.
Qué hacer realmente al respecto
Para los administradores de TI que gestionan flotas que ejecutan juegos competitivos, algo común en cibercafés, organizaciones de esports, e incluso en imágenes corporativas generales donde los empleados tienen derechos de administrador local, la medida práctica es mantener activa y actualizada la VBL de Microsoft en lugar de desactivarla por razones de compatibilidad, ya que esa lista de bloqueo es el principal mecanismo que elimina activamente controladores de videojuegos conocidos por ser explotables. Los despliegues de EDR empresarial deberían vigilar específicamente los eventos de carga de controladores anti-cheat fuera de los procesos de juego esperados; que un controlador de Vanguard o EAC se cargue en un servidor o una estación de trabajo sin el juego correspondiente instalado es, por sí solo, una señal fuerte que merece investigarse.
Para los jugadores, la conclusión práctica es más acotada: desinstalar un juego competitivo no siempre elimina su controlador de kernel, así que revisar la lista de controladores instalados en Windows (mediante el comando driverquery en una terminal elevada) tras desinstalar títulos protegidos por anti-cheat merece los treinta segundos que toma. Para los editores que todavía deciden cómo construir la próxima generación de anti-cheat, el compromiso de VAC de Valve es el que merece estudiarse en serio: un sistema de detección con un techo más bajo, pero con una huella de kernel lo bastante reducida como para dejar de ser el controlador firmado favorito de un grupo de ransomware.