Driver assinado pela Microsoft vira arma para desativar EDR e roubar credenciais

Uma campanha descoberta pelo LastPass Threat Intelligence, Mitigation, and Escalation Team em parceria com a Delphos Labs mostra como um atacante pode combinar engenharia social, DLL side-loading, elevação de privilégio e um driver de kernel com cadeia de assinatura da Microsoft para neutralizar ferramentas de segurança antes de roubar credenciais. O caso Rapuncel expõe uma fragilidade estrutural: confiança criptográfica e reputação de arquivo ajudam a reduzir risco, mas não substituem análise de comportamento, controle de drivers e proteção da identidade.

Uma cadeia de ataque construída sobre sinais de confiança

O ataque começou fora da infraestrutura da LastPass. Em agosto de 2026, pesquisadores identificaram uma organização fraudulenta no GitHub que imitava o LastPass Authenticator e aparecia em resultados de busca para usuários procurando pelo aplicativo. A página usava marca, descrições e elementos visuais legítimos para conduzir a vítima até uma sequência de redirecionamentos que terminava em servidores controlados pelos atacantes.

A análise conjunta da LastPass e da Delphos Labs mostrou que a operação era maior do que uma única imitação de marca. O mesmo kit de distribuição era usado para reproduzir páginas falsas associadas a pelo menos 40 empresas, com infraestrutura capaz de alterar servidores de payload sem modificar as páginas públicas usadas como isca. A LastPass ressalta que nenhum sistema, serviço ou cofre de clientes foi comprometido; o nome da empresa foi explorado como elemento de confiança.

O arquivo entregue às vítimas era um ZIP que podia ultrapassar 100 MB. O tamanho não era acidental: arquivos de preenchimento aumentavam o volume do pacote para tentar escapar de mecanismos automatizados de análise que impõem limites de tamanho. Dentro do arquivo, os pesquisadores encontraram componentes legítimos e maliciosos organizados para reduzir a percepção de risco.

DLL side-loading abre caminho para o nível SYSTEM

Uma das peças centrais era o vsdbg.exe, ferramenta legítima de depuração da Microsoft, acompanhada por uma biblioteca vsdbg.dll maliciosa. Ao executar o binário, o Windows carregava a DLL presente no mesmo diretório, permitindo que o código do atacante fosse executado sob a aparência de um componente legítimo. A técnica é conhecida como DLL side-loading e explora a forma como determinados aplicativos procuram bibliotecas necessárias à execução.

Depois dessa etapa, o loader tentava diferentes métodos de elevação até alcançar o contexto SYSTEM, um dos níveis mais altos de privilégio do Windows. É nesse momento que o incidente deixa de ser apenas um caso de infostealer e passa a atingir o plano de confiança do sistema operacional: com privilégios suficientes, o malware instala um driver de kernel chamado Alinubx.sys, salvo como nvfsflt64.sys e registrado como “NVIDIA File System Filter Driver”.

O driver assinado que encerra 145 ferramentas de segurança

O Alinubx.sys possuía uma cadeia de assinatura do programa Microsoft Windows Hardware Compatibility Publisher. Para o Windows e para diversos controles de segurança, isso representa um sinal importante de confiança. O problema é que a assinatura atesta a origem do processo de assinatura e integridade do binário, não que todo comportamento futuro do driver seja seguro.

Segundo a análise técnica, o driver carregava 145 nomes de processos associados a antivírus e soluções de Endpoint Detection and Response (EDR). A partir do kernel, ele podia abrir processos usando contexto de KernelMode e terminá-los por meio de chamadas internas do Windows. Essa posição privilegiada permite contornar verificações aplicadas a processos em modo de usuário e pode derrotar mecanismos como Protected Process Light usados por produtos de segurança.

O caso é relevante porque não depende de uma vulnerabilidade clássica de corrupção de memória. A Delphos descreve o comportamento como abuso de uma funcionalidade exposta por uma linha de drivers associada ao software CnCrypt/CcProtect, da Henan Dafeng Software. O driver observado na campanha teria sido renomeado e reaproveitado, mantendo a capacidade de encerrar processos enquanto alterava elementos de identidade suficientes para reduzir detecções baseadas em nomes e hashes.

Depois do EDR, o alvo passa a ser a identidade

Com as ferramentas de segurança encerradas, o Rapuncel passa a coletar credenciais e outros ativos de alto valor. A campanha analisada buscava senhas armazenadas em mais de 25 navegadores, dados de carteiras de criptomoedas, tokens do Discord, sessões do Steam e Telegram, dados do Windows Credential Manager, capturas de tela e documentos com palavras como “password”, “seed”, “wallet” e “recovery”.

O malware também empregava uma técnica específica contra a proteção App-Bound Encryption de navegadores Chromium. Em vez de tentar quebrar a criptografia diretamente, injetava código no processo do navegador para solicitar a descriptografia a partir de um contexto que se parecia com o próprio aplicativo legítimo. Isso mostra como a cadeia não depende de um único bypass: ela combina confiança de marca, confiança em binários legítimos, privilégios elevados, confiança no kernel e contexto de processo para chegar às credenciais.

Para uma organização, o efeito pode ir muito além do endpoint inicialmente comprometido. Senhas e tokens roubados podem abrir acesso a SaaS, e-mail, VPN, repositórios de código, ambientes de nuvem e sistemas corporativos. Mesmo quando MFA está presente, tokens de sessão válidos ou credenciais recuperadas de aplicações podem permitir abuso até que sejam revogados. Por isso, a recuperação precisa tratar a identidade como parte central do incidente.

Por que a blocklist não resolve o problema sozinha

No momento em que os pesquisadores verificaram a campanha, o Alinubx.sys não estava presente na Microsoft Vulnerable Driver Blocklist. A própria Microsoft alerta que a lista não garante cobertura de todos os drivers vulneráveis e que a proteção precisa combinar diferentes mecanismos. Desde o Windows 11 2022 Update, a blocklist é habilitada por padrão em cenários específicos e também é aplicada quando recursos como Memory Integrity/HVCI, Smart App Control ou S mode estão ativos.

A Microsoft recomenda ainda o uso do App Control for Business e da regra de Attack Surface Reduction Block abuse of exploited vulnerable signed drivers. Essa regra ajuda a impedir que aplicações gravem drivers vulneráveis assinados no disco. Há, contudo, uma limitação importante: ela não bloqueia o carregamento de um driver que já esteja presente no sistema. Isso reforça a necessidade de combinar ASR com blocklist, política de controle de aplicação e monitoramento de carregamento de drivers.

Para ambientes corporativos, uma política baseada apenas em “assinatura válida” é insuficiente. Drivers de kernel devem ser tratados como componentes de alto risco, principalmente quando aparecem fora do inventário esperado, são instalados por processos incomuns ou surgem junto a eventos de elevação de privilégio e encerramento em massa de agentes de segurança.

Controles técnicos que reduzem o risco

A primeira camada é impedir que a cadeia chegue ao estágio de execução. Softwares corporativos devem ser distribuídos por canais oficiais e repositórios gerenciados, reduzindo a dependência de downloads encontrados por mecanismos de busca. Controles de navegação e DNS podem bloquear domínios recém-criados, páginas de GitHub inesperadas e infraestrutura conhecida da campanha, mas esses indicadores devem ser tratados como temporários porque a operação demonstrou capacidade de rotação.

No endpoint, organizações devem manter HVCI/Memory Integrity ativo onde compatível, aplicar a Microsoft Vulnerable Driver Blocklist atualizada e avaliar App Control for Business em modo de auditoria antes de enforcement. A regra ASR para abuso de drivers assinados vulneráveis complementa essa abordagem, assim como políticas que limitem a instalação de serviços e drivers a processos e identidades administrativas autorizadas.

O SOC deve correlacionar sinais de comportamento. Entre os artefatos observados estão a criação do serviço NvFsFilter, escrita em C:\Windows\System32\drivers\nvfsflt64.sys, presença de .Alinubx, ProtectR3.dll e vsdbg.dll em contexto suspeito. Mais valioso do que um IOC isolado é detectar a sequência: execução de um binário legítimo a partir de diretório incomum, DLL side-loading, elevação a SYSTEM, instalação de driver e encerramento simultâneo de múltiplos produtos de segurança.

Quando houver execução, a resposta deve presumir comprometimento de credenciais

A orientação mais importante da investigação é operacional: uma máquina que executou o instalador falso deve ser tratada como potencialmente comprometida no nível de kernel e de identidade. Credenciais armazenadas no navegador, tokens de aplicação, sessões, carteiras e dados do Credential Manager devem ser considerados expostos. Trocas de senha e revogações de sessão precisam ocorrer a partir de um dispositivo conhecido como limpo, não a partir do endpoint afetado.

A resposta também deve preservar evidências antes da limpeza sempre que o contexto permitir. Como o driver atua abaixo das ferramentas convencionais de usuário, o processo de remoção pode exigir inicialização em modo seguro ou ambiente externo de recuperação. Em ambientes corporativos, o reimage completo do endpoint costuma oferecer maior garantia do que uma tentativa de limpeza pontual após comprometimento de kernel.

Depois da contenção, a organização deve revisar acessos posteriores realizados com as identidades expostas, incluindo SaaS, nuvem, e-mail, VPN e aplicações administrativas. Em outras palavras, o incidente não termina quando o driver é removido: é necessário confirmar que os ativos de identidade utilizados pelo atacante também foram invalidados.

Assinatura digital é um sinal de confiança, não uma garantia de segurança

A campanha Rapuncel evidencia um problema que tende a ganhar importância à medida que atacantes investem em cadeias cada vez mais “legítimas”. Binários oficiais, GitHub, certificados válidos, drivers assinados e reputação limpa podem ser combinados para reduzir a percepção de risco de usuários e controles automatizados. Cada elemento, isoladamente, parece confiável; a ameaça aparece quando o comportamento da cadeia é observado como um todo.

Para as organizações, a resposta mais madura é reduzir decisões binárias do tipo “assinado = seguro” e adotar políticas que considerem procedência, contexto de execução, privilégio, comportamento e impacto potencial. No kernel, essa postura é ainda mais importante: um driver autorizado a operar no nível mais profundo do sistema precisa ser tratado como parte crítica da superfície de ataque.

Referências

Hackers Use Microsoft-Signed Driver to Disable 145 Security Tools and Steal Passwords
Threat Intel | One Kit, Forty Companies: How a Malware-as-a-Service Platform Used GitHub as a Distribution Network for its Campaign
Microsoft recommended driver block rules
Attack surface reduction rules reference