Softwares anti-cheat em nível de kernel se tornaram, silenciosamente, uma das maiores superfícies de ataque dos games para PC
Softwares anti-cheat em nível de kernel hoje rodam com os mesmos privilégios do seu antivírus em dezenas de milhões de PCs, e esse acesso se tornou uma das superfícies mais exploráveis da computação doméstica. O Vanguard da Riot Games, o Easy Anti-Cheat (EAC), o BattlEye e o Denuvo Anti-Cheat carregam drivers assinados no anel 0 do kernel do Windows, o mesmo nível de privilégio do próprio sistema operacional, para detectar trapaças por manipulação de memória que ferramentas em modo usuário não conseguem ver. O problema é que um driver confiável o suficiente para inspecionar todos os processos na memória também é confiável o suficiente para desativar ferramentas de segurança, e atacantes vêm explorando discretamente essa confiança desde pelo menos 2022.
Isso não é hipotético. Pesquisadores de segurança e a própria Vulnerable Driver Blocklist (VBL) da Microsoft já sinalizaram repetidamente drivers de anti-cheat e de jogos assinados como um vetor de "bring your own vulnerable driver" (BYOVD): atacantes carregam um driver legitimamente assinado, mas com uma falha conhecida, e usam o acesso ao kernel que ele concede para matar processos de EDR antes de implantar ransomware. Esse padrão já apareceu em incidentes ligados ao BlackByte e a outros grupos de ransomware, que preferem drivers vulneráveis justamente porque carregam uma assinatura válida da Microsoft e passam pelas verificações de assinatura de código que bloqueariam diretamente um módulo de kernel não assinado.
Como um driver confiável se torna uma arma
O mecanismo por trás disso é simples. O Windows exige que drivers em modo kernel sejam assinados, diretamente pela Microsoft ou pelo programa WHQL (Windows Hardware Quality Labs), para impedir a execução de código arbitrário no nível de privilégio mais alto. Fornecedores de anti-cheat precisam desse nível de acesso para ler a memória de processos adversários, interceptar chamadas de sistema e detectar depuradores, tudo o que um processo de trapaça em modo usuário conseguiria esconder. Assim, o fornecedor consegue instalar um driver legitimamente assinado em cada máquina que executa o jogo.
Se esse driver tiver um bug, por exemplo, um manipulador de IOCTL exposto que permite que qualquer processo na máquina envie comandos a ele, um atacante nem precisa do próprio driver malicioso. Ele carrega o driver de anti-cheat já assinado e confiável, conversa com sua interface exposta e usa os privilégios de kernel dele para encerrar processos protegidos, incluindo agentes de EDR da CrowdStrike, SentinelOne ou Microsoft Defender for Endpoint. Foi exatamente isso que aconteceu com o driver mhyprot2.sys da miHoYo, originalmente distribuído com o sistema anti-cheat de Genshin Impact: ele expunha funções que permitiam que qualquer processo local encerrasse arbitrariamente outros processos, e operadores de ransomware o adotaram justamente por ser um binário assinado e limpo, sem assinatura óbvia de malware.
O problema de escala
O driver de anti-cheat da Capcom tinha uma falha semelhante de encerramento arbitrário de processos, revelada em 2020. O driver do Genshin Impact permanecia instalado e em execução em alguns sistemas mesmo depois que o próprio jogo era desinstalado, porque a rotina de instalação nunca incluiu um desinstalador para o componente de kernel, um detalhe que só ganhou mais atenção quando pesquisadores de segurança começaram a mapear quais "LOLDrivers" (living-off-the-land drivers) os grupos de ransomware estavam catalogando para reutilização. A VBL da Microsoft, distribuída via Windows Update e App Control for Business, agora bloqueia por hash dezenas de versões específicas de drivers de anti-cheat e utilitários de jogos, mas a lista continua reativa: um driver precisa ser flagrado sendo abusado antes de ser adicionado, e novas versões de drivers de anti-cheat são lançadas constantemente conforme os fornecedores corrigem os bypasses.
A escala aqui importa mais do que qualquer incidente isolado. Só o Valorant tem mais de 20 milhões de jogadores ativos mensais, e o Vanguard se instala na inicialização, antes mesmo de a interface do sistema carregar, justamente para que ferramentas de trapaça não consigam desativá-lo durante uma partida. EAC e BattlEye juntos cobrem centenas de títulos competitivos. Isso é um binário com privilégios de kernel, controlado por um fornecedor terceiro em vez do fabricante do sistema operacional, instalado em uma base enorme, e, diferente de um fornecedor de antivírus, a maioria dos fornecedores de anti-cheat nunca passou pelo tipo de auditoria de segurança adversarial que produtos de EDR enfrentam rotineiramente, porque seu modelo de ameaça foi construído para pegar trapaceiros, não para resistir a pesquisas de exploração de drivers no nível de um Estado-nação.
Por que isso continua se repetindo
Fornecedores de anti-cheat enfrentam um problema estrutural de incentivos: cada nova capacidade de kernel adicionada para detectar uma trapaça mais sofisticada também é uma nova capacidade que um atacante pode explorar, mas o indicador de desempenho do fornecedor é a taxa de detecção de trapaças, não a minimização da superfície de ataque. Reescrever esses sistemas para rodar em modo usuário com capacidades mais restritas, a direção que a Valve seguiu com o design majoritariamente em modo usuário do VAC para a Steam, aceitando um teto de detecção mais baixo em troca de uma pegada de kernel drasticamente menor, é uma troca real que a maioria das publishers recusou fazer, porque reclamações sobre integridade competitiva movem notas e número de jogadores mais rápido do que uma CVE teórica em um driver.
A Microsoft também vem empurrando fornecedores para seus frameworks Kernel-Mode Hardware-Enforced Stack Protection e HVCI (Hypervisor-Protected Code Integrity), que limitam o que um driver de kernel pode fazer mesmo com uma assinatura de código válida, mas a adoção é opcional e lenta porque pode quebrar a lógica de detecção do anti-cheat, que depende de uma visibilidade ampla da memória. Até que uma contenção no estilo HVCI se torne obrigatória em vez de opcional, o modelo de confiança baseado em drivers assinados que faz o anti-cheat funcionar continuará sendo o mesmo que o torna um alvo duradouro para BYOVD.
O que realmente fazer sobre isso
Para administradores de TI que gerenciam frotas que rodam jogos competitivos, comum em lan houses, organizações de esports e até em imagens corporativas gerais em que funcionários têm direitos de administrador local, a medida prática é manter a VBL da Microsoft ativada e atualizada em vez de desativá-la por motivos de compatibilidade, já que essa lista de bloqueio é o principal mecanismo removendo ativamente drivers de jogos conhecidos por serem exploráveis. Implantações de EDR corporativas deveriam monitorar especificamente eventos de carregamento de drivers de anti-cheat fora dos processos de jogo esperados; um driver do Vanguard ou do EAC carregando em um servidor ou estação de trabalho sem o jogo correspondente instalado já é, por si só, um sinal forte que merece investigação.
Para os jogadores, a conclusão prática é mais específica: desinstalar um jogo competitivo nem sempre remove seu driver de kernel, então verificar a lista de drivers instalados no Windows (via o comando driverquery em um terminal elevado) depois de desinstalar títulos protegidos por anti-cheat vale os trinta segundos que isso leva. Para publishers que ainda estão decidindo como construir a próxima geração de anti-cheat, a troca feita pela Valve com o VAC é a que merece ser estudada com seriedade: um sistema de detecção com um teto mais baixo, mas com uma pegada de kernel pequena o suficiente para deixar de ser o driver assinado favorito de um grupo de ransomware.