PoC explora suposta falha no Kaspersky Endpoint Security
Um pesquisador conhecido como MSNightmare divulgou um código de prova de conceito, chamado HardBreacher, que supostamente explora uma falha de escalonamento local de privilégios no Kaspersky Endpoint Security para Windows. A alegação envolve sistemas Windows 11 com as atualizações mais recentes instaladas, mas ainda não foi confirmada publicamente pela Kaspersky nem recebeu um identificador CVE.
De acordo com a descrição disponível no projeto, o código foi testado no Windows 11 versão 25H2, utilizando o Kaspersky Endpoint Security 14.0.0.504. O funcionamento aparente do PoC estaria relacionado à comunicação entre uma conta local e um processo responsável pela interface do produto de segurança.
Caso o comportamento descrito seja reproduzível, um usuário com permissões limitadas poderia interferir em operações protegidas do sistema. O autor afirma que a exploração pode criar o arquivo `C:WindowsSystem32MY_SNAKE_IS_SOLID.dll` e conceder à conta em uso controle total sobre esse arquivo. Em condições normais, a gravação e a alteração de arquivos nesse diretório são restritas justamente para impedir que processos ou usuários de baixo privilégio modifiquem componentes críticos do Windows.
A possibilidade de controlar um arquivo dentro de `System32` é relevante porque esse diretório concentra bibliotecas essenciais do sistema operacional. Dependendo da forma como o arquivo fosse carregado, um invasor local poderia tentar executar código com permissões superiores, alterar componentes utilizados por processos confiáveis ou preparar uma etapa posterior de comprometimento.
Entretanto, o próprio desenvolvedor descreve o HardBreacher como instável. O código pode apresentar erros, falhar durante a execução e exigir várias tentativas até produzir o resultado esperado. Os testes também teriam envolvido uma reinicialização do sistema, fator que dificulta avaliar se o comportamento é consistente ou se depende de condições específicas do ambiente.
Outra alegação importante diz respeito ao possível controle do processo de interface do Kaspersky. Se essa interação realmente permitir interferir no funcionamento do produto, o resultado poderia incluir interrupções da proteção, decisões inesperadas de permissão ou bloqueios incorretos. Em uma rede corporativa, qualquer instabilidade dessa natureza merece atenção, mesmo quando não há confirmação de exploração completa.
Por que a suspeita é relevante
Soluções de endpoint normalmente operam com privilégios elevados para monitorar processos, arquivos, memória, conexões de rede e políticas de segurança. Esse nível de acesso é necessário para detectar ameaças, mas também aumenta o impacto potencial de uma vulnerabilidade no próprio agente de proteção.
Uma falha local de elevação de privilégios não permite necessariamente um ataque remoto imediato. Em geral, o criminoso ainda precisa obter algum tipo de acesso inicial ao computador, como por meio de malware, credenciais comprometidas, execução de arquivo malicioso ou acesso físico. Depois disso, entretanto, a vulnerabilidade pode ajudar a escapar das restrições da conta comprometida e ampliar o controle sobre o dispositivo.
Também é importante diferenciar uma prova de conceito de um exploit operacional. Um PoC demonstra uma hipótese técnica, mas pode depender de versões específicas, configurações incomuns, permissões previamente obtidas ou etapas manuais. Isso não significa que o risco deva ser ignorado, mas impede concluir, sem validação independente, que todos os equipamentos estejam vulneráveis.
Como as empresas devem agir
Organizações que utilizam o Kaspersky Endpoint Security devem classificar o caso como uma alegação em investigação, e não como uma vulnerabilidade confirmada. Ainda assim, é recomendável acompanhar os comunicados oficiais do fabricante, verificar a existência de atualizações do produto e manter o Windows atualizado.
A equipe de segurança pode começar levantando quais versões do Endpoint Security estão instaladas, quais máquinas utilizam Windows 11 versão 25H2 e se há estações fora do ciclo normal de atualização. Esse inventário ajuda a identificar rapidamente os ativos mais próximos do cenário descrito pelo autor do PoC.
Até que haja esclarecimentos, o acesso administrativo local deve ser limitado ao mínimo necessário. Contas comuns não devem possuir privilégios elevados sem justificativa, e credenciais administrativas precisam ser protegidas contra reutilização, exposição em scripts e armazenamento inseguro.
Também é aconselhável reforçar o monitoramento de eventos relacionados à criação ou alteração de arquivos em `C:WindowsSystem32`. A geração inesperada de uma DLL nesse diretório, especialmente por um processo de usuário ou por um executável desconhecido, deve ser tratada como um indicador de possível comprometimento.
Indicadores para monitorar
Além da criação do arquivo mencionado no PoC, os defensores podem procurar tentativas incomuns de manipulação dos processos do Kaspersky, encerramentos inesperados do agente, falhas recorrentes na interface e mudanças não autorizadas nas políticas de proteção.
Logs do Windows, telemetria do EDR, registros de controle de aplicações e eventos de gerenciamento de privilégios podem ajudar a reconstruir a sequência de atividades. É importante preservar evidências antes de reiniciar ou limpar uma máquina suspeita, pois a reinicialização pode eliminar informações úteis para a investigação.
O bloqueio preventivo de DLLs desconhecidas em diretórios críticos, quando compatível com a política da organização, também pode reduzir o risco. Essa medida deve ser testada cuidadosamente para evitar impactos em componentes legítimos do Windows e do próprio software de segurança.
Atualização e resposta a incidentes
Se a Kaspersky publicar uma correção, a atualização deve ser validada primeiro em um grupo controlado de dispositivos. Depois dos testes, a distribuição pode ser ampliada conforme o nível de criticidade dos ativos. Ambientes com dados sensíveis, acesso a sistemas financeiros ou funções administrativas devem receber prioridade.
Caso sejam encontrados sinais de exploração, a máquina afetada deve ser isolada da rede, sem desligá-la imediatamente quando houver necessidade de preservar evidências. A equipe responsável deve coletar registros, verificar alterações em arquivos protegidos, revisar processos executados e procurar movimentação lateral para outros dispositivos.
A investigação também deve considerar o vetor inicial. Mesmo que a falha do endpoint seja confirmada, o ataque pode ter começado com phishing, software pirata, credenciais roubadas ou serviço remoto exposto. Corrigir apenas o componente vulnerável sem eliminar a origem do acesso pode deixar a organização sujeita a novos incidentes.
Até o momento, o HardBreacher representa uma indicação técnica que precisa ser reproduzida e analisada por especialistas. A postura mais adequada é combinar cautela, atualização, controle de privilégios e monitoramento contínuo, evitando tanto o alarmismo quanto a negligência diante de uma possível falha em um software executado com permissões elevadas.