Driver assinado pela Microsoft é usado para desativar EDR e roubar credenciais
Uma campanha conhecida como Rapuncel demonstra como criminosos podem explorar componentes legítimos do Windows para neutralizar defesas, obter privilégios máximos e capturar informações de autenticação. A operação combina engenharia social, carregamento lateral de DLL, elevação para o contexto SYSTEM e um driver de kernel com assinatura vinculada à Microsoft.
O episódio evidencia uma limitação importante dos mecanismos tradicionais de confiança: uma assinatura digital ajuda a confirmar a origem e a integridade de um arquivo, mas não garante que seu uso seja seguro em todos os contextos. Quando um componente assinado é abusado, a defesa precisa analisar comportamento, origem, finalidade e cadeia de execução – não apenas a reputação do arquivo.
Falsa página do LastPass servia como ponto de entrada
A campanha começou com uma organização fraudulenta criada no GitHub para imitar o LastPass Authenticator. A página reproduzia a identidade visual, a linguagem e os elementos de navegação associados ao aplicativo legítimo. O objetivo era aparecer em buscas realizadas por pessoas que procuravam uma ferramenta de autenticação.
Ao acessar a página, a vítima era encaminhada por uma sequência de redirecionamentos até servidores controlados pelos invasores. A investigação conduzida pela LastPass Threat Intelligence, Mitigation, and Escalation Team em conjunto com a Delphos Labs indicou que a estrutura não era exclusiva de uma marca.
O mesmo kit também era utilizado para falsificar páginas associadas a pelo menos 40 empresas. A infraestrutura permitia trocar os servidores responsáveis pelos payloads sem alterar significativamente as páginas públicas usadas na distribuição. A LastPass informou que seus sistemas, serviços e cofres de clientes não foram invadidos; a marca foi utilizada apenas para aumentar a credibilidade do golpe.
Arquivo grande tentava escapar da análise automatizada
O instalador era distribuído em um arquivo ZIP que podia superar 100 MB. Grande parte desse volume era composta por dados de preenchimento, uma técnica empregada para dificultar a inspeção automática. Algumas soluções de análise limitam o tamanho dos arquivos examinados, e pacotes excessivamente grandes podem atrasar ou impedir a detecção.
Dentro do ZIP havia uma combinação de componentes legítimos e maliciosos. Essa organização ajudava a reduzir suspeitas e a fazer com que a execução parecesse compatível com um programa regular do Windows.
Um dos elementos principais era o `vsdbg.exe`, utilitário legítimo de depuração da Microsoft. No mesmo diretório, porém, havia uma biblioteca `vsdbg.dll` modificada. Como determinados executáveis procuram suas bibliotecas na própria pasta antes de recorrer a outros locais, o programa legítimo acabava carregando o componente controlado pelos criminosos.
Esse método é chamado de DLL side-loading. O processo aparenta ser confiável, mas a biblioteca carregada executa código malicioso. Como consequência, ferramentas de segurança podem observar um processo assinado e conhecido, sem perceber imediatamente que ele está servindo como intermediário para a infecção.
Elevação para SYSTEM abre acesso ao núcleo do Windows
Após a execução inicial, o loader tentava obter privilégios mais altos. O objetivo era alcançar o contexto `SYSTEM`, que oferece permissões superiores às de um usuário administrativo comum.
Com esse nível de acesso, o malware instalava o driver de kernel `Alinubx.sys`. No sistema infectado, o arquivo era armazenado como `nvfsflt64.sys` e registrado com o nome “NVIDIA File System Filter Driver”, uma identificação escolhida para parecer legítima.
O componente tinha uma cadeia de assinatura associada ao programa Microsoft Windows Hardware Compatibility Publisher. Essa característica ajudava a ultrapassar controles baseados exclusivamente em assinaturas, reputação e listas de arquivos conhecidos.
A assinatura, entretanto, não significa que todas as ações executadas pelo driver sejam aprovadas pela Microsoft. Ela demonstra que o arquivo passou por um processo de assinatura e que não foi alterado depois disso. A avaliação de segurança do comportamento continua sendo responsabilidade das ferramentas de proteção e dos administradores.
Driver encerra 145 processos de segurança
De acordo com a análise técnica, o driver continha uma relação com 145 nomes de processos ligados a antivírus e plataformas EDR. A partir do kernel, ele conseguia acessar processos usando o contexto `KernelMode` e encerrá-los por meio de chamadas internas do Windows.
Essa posição oferece uma vantagem significativa ao invasor. Processos executados no modo de usuário dependem de controles que podem ser ignorados por um componente operando no núcleo do sistema. Em determinadas circunstâncias, o driver também consegue contornar mecanismos como o Protected Process Light, utilizado por produtos de segurança para dificultar sua finalização.
O ataque não depende necessariamente de uma vulnerabilidade clássica. Em vez disso, explora uma combinação de confiança operacional, permissões elevadas e abuso de funcionalidades legítimas. Esse tipo de técnica é frequentemente associado a ataques BYOVD, sigla em inglês para “traga seu próprio driver vulnerável ou abusado”.
Depois da desativação do EDR, o alvo passa a ser a identidade
Com antivírus e EDR interrompidos, a campanha avançava para o roubo de credenciais. O malware podia procurar senhas armazenadas, cookies de sessão, tokens de autenticação e outros dados capazes de permitir acesso a serviços corporativos.
O impacto não se limita ao computador inicialmente infectado. Cookies e tokens válidos podem permitir que o criminoso reutilize sessões sem conhecer a senha. Em ambientes corporativos, isso pode resultar no acesso a e-mail, ferramentas de colaboração, painéis administrativos, sistemas em nuvem e repositórios internos.
Por esse motivo, a interrupção do EDR deve ser tratada como um incidente de alta gravidade. Mesmo que não haja evidência imediata de exfiltração, é prudente considerar que credenciais presentes na máquina podem ter sido expostas.
Por que a blocklist não resolve o problema sozinha
A inclusão do driver em uma lista de bloqueio é uma medida importante, mas não elimina todos os riscos. Listas podem demorar a ser atualizadas, variar entre versões do sistema operacional ou não contemplar novas campanhas que utilizem arquivos renomeados e diferentes caminhos de instalação.
Além disso, o atacante pode tentar carregar outros drivers assinados, explorar configurações inadequadas ou utilizar ferramentas legítimas para manter o acesso. Uma defesa eficiente precisa combinar bloqueio de drivers, monitoramento de comportamento e controle rigoroso de privilégios.
Organizações também devem verificar se políticas de integridade de código, isolamento do núcleo, Secure Boot e proteção contra alterações não autorizadas estão habilitadas. Esses recursos não são infalíveis, mas reduzem a possibilidade de que um componente desconhecido seja carregado no kernel.
Medidas para reduzir o risco
O primeiro passo é impedir a instalação de drivers sem necessidade operacional. Ambientes corporativos devem permitir apenas drivers aprovados, provenientes de fontes confiáveis e compatíveis com a função do equipamento.
Também é recomendável restringir privilégios administrativos, aplicar o princípio do menor privilégio e impedir que usuários instalem aplicativos fora dos canais autorizados. A autenticação multifator resistente a phishing, especialmente com chaves de segurança, reduz o impacto do roubo de senhas.
Equipes de segurança devem monitorar eventos como:
– instalação inesperada de novos serviços;
– carregamento de drivers fora dos diretórios habituais;
– execução de binários assinados acompanhados por DLLs recém-criadas;
– interrupção repentina de antivírus ou EDR;
– alterações em políticas de segurança;
– acesso incomum a navegadores, cofres de credenciais e tokens;
– conexões para domínios recém-criados ou infraestrutura desconhecida.
A análise da linha de comando e da árvore de processos também é essencial. Um utilitário legítimo iniciado a partir de uma pasta temporária, acompanhado por uma biblioteca desconhecida e seguido pela instalação de um driver, apresenta um risco muito diferente do mesmo executável instalado em seu diretório oficial.
O que fazer quando houver suspeita de infecção
Ao identificar sinais compatíveis com esse tipo de ataque, o equipamento deve ser isolado da rede sem desligá-lo imediatamente, quando isso for possível e estiver de acordo com os procedimentos de resposta a incidentes. A preservação de evidências pode ajudar a determinar a extensão da invasão.
Em seguida, a organização deve investigar a instalação do driver, os serviços criados, os processos encerrados e os arquivos carregados pelo aplicativo suspeito. As credenciais usadas no equipamento precisam ser revogadas e redefinidas a partir de um dispositivo confiável.
Também é necessário invalidar sessões ativas, renovar tokens, revisar regras de encaminhamento de e-mail e examinar acessos realizados após a infecção. A análise deve incluir contas privilegiadas, pois o roubo de uma sessão administrativa pode ampliar rapidamente o alcance do ataque.
Assinatura digital não substitui análise de comportamento
O caso Rapuncel reforça que a assinatura digital é apenas um dos sinais utilizados na avaliação de um arquivo. Ela não deve ser interpretada como uma certificação permanente de que o componente é seguro, tampouco como autorização para que ele execute qualquer ação no sistema.
A defesa moderna precisa observar a cadeia completa: como o arquivo chegou ao computador, quem o iniciou, quais bibliotecas foram carregadas, que privilégios foram obtidos, quais processos foram encerrados e quais dados foram acessados.
Quando um driver assinado é usado para desativar ferramentas de proteção, o problema deixa de ser apenas a presença de malware. Trata-se de uma violação da confiança do sistema operacional, com possível comprometimento de credenciais, sessões e identidades digitais. Por isso, bloqueio preventivo, telemetria de baixo nível e resposta rápida devem atuar em conjunto.