BYOVD (Bring Your Own Vulnerable Driver): o que é e como se proteger

Seu EDR pode ser desligado por um driver legítimo. Entenda por que isso acontece e o que fazer a respeito.

A maioria das organizações investe pesadamente em soluções de EDR (Endpoint Detection and Response) partindo de uma premissa razoavel: se um processo malicioso tentar executar algo perigoso, o agente de segurança no endpoint vai detectar e bloquear. Essa premissa é válida contra ameaças convencionais. Porém, existe uma classe de ataque que a subverte por completo, explorando a própria arquitetura de confiança do sistema operacional.

BYOVD (Bring Your Own Vulnerable Driver) é uma técnica de ataque em que o adversário instala deliberadamente um driver de kernel legítimo, porém vulnerável, no sistema-alvo para obter privilegios de nível kernel e desativar controles de segurança, incluindo EDR, antivirus e mecanismos de logging. O driver utilizado e assinado digitalmente por um fornecedor reconhecido, o que significa que o Windows o aceita sem questionamento.

Essa técnica não é teórica. Grupos como Lazarus Group, BlackByte e os operadores do Cuba ransomware a utilizaram com sucesso em campanhas reais. O MITRE ATT&CK cataloga BYOVD como subtécnica de Exploitation for Defense Evasion (T1211), é a tendência de adoção por grupos de ameaça e crescente.

Este artigo explica como o ataque BYOVD funciona, por que os controles tradicionais falham, quais grupos o utilizaram em campanhas documentadas e como uma abordagem de gestão de vulnerabilidades combinada com inventário de ativos e varredura de vulnerabilidades reduz drasticamente a superfície de exposição.

---

O que é BYOVD: definição e contexto técnico

Leia também: Gestão de vulnerabilidades no setor financeiro: regulação...

O kernel do Windows opera em camadas de privilegio. Processos de usuário (ring 3) operam com permissões restritas, enquanto drivers de kernel (ring 0) tem acesso irrestrito a memória, hardware e todos os processos em execução, incluindo agentes de segurança. Para garantir que apenas código confiável opere nesse nível, a Microsoft exige que drivers sejam assinados digitalmente. A partir do Windows 10 versão 1607, a Driver Signature Enforcement (DSE) impede a carga de drivers não assinados em sistemas com Secure Boot.

O problema é que a assinatura digital atesta apenas a origem do driver, não a ausência de vulnerabilidades. Um driver assinado pela Dell, Intel ou Realtek pode conter falhas de corrupcao de memória, leitura/escrita arbitraria no kernel ou controles de acesso insuficientes. Essas vulnerabilidades transformam o driver em uma porta de entrada para código malicioso operar no nível mais privilegiado do sistema.

BYOVD (Bring Your Own Vulnerable Driver) é uma técnica de evasão de defesas na qual um atacante traz e instala um driver de kernel legitimamente assinado, porém contendo vulnerabilidades conhecidas, para obter capacidades de leitura e escrita no kernel, permitindo a desativação de mecanismos de segurança é a execução de código arbitrário com privilegios de ring 0.

O nome "Bring Your Own" reflete o fato de que o atacante não depende de drivers já presentes no sistema-alvo. Ele traz o driver vulnerável consigo, como parte do payload, é o instala programaticamente, tornando a técnica altamente portavel.

---

Como o ataque BYOVD funciona: cadeia de ataque passo a passo

Leia também: Como priorizar vulnerabilidades: 8 estratégias baseadas e...

A execução de um ataque BYOVD segue uma cadeia estruturada em oito etapas:

CADEIA DE ATAQUE BYOVD

[1. Acesso Inicial]
       |
       v
[2. Escalação de Privilegio Local (admin)]
       |
       v
[3. Deploy do Driver Vulnerável (.sys)]
       |
       v
[4. Registro do Driver (sc create / NtLoadDriver)]
       |
       v
[5. Exploração da Vulnerabilidade via IOCTL]
       |
       v
[6. Obtenção de Primitivas de Kernel (read/write)]
       |
       v
[7. Desativação do EDR / AV / Logging]
       |
       v
[8. Execução do Payload Final (ransomware, exfiltração)]

Etapas 1-2: Acesso e escalação. O atacante obtém acesso ao sistema por vetores convencionais (phishing, credenciais comprometidas, exploração de serviço exposto) e escala privilegios até administrador local, requisito para instalar drivers de kernel.

Etapas 3-4: Deploy e carga do driver. O arquivo .sys do driver vulnerável, geralmente embutido no malware em base64, e extraido e gravado no disco. O atacante registra o driver como serviço de kernel via sc.exe ou NtLoadDriver. O Windows verifica a assinatura digital, confirma que é válida e carrega o driver em ring 0.

Etapa 5: Exploração da vulnerabilidade. O atacante envia IOCTLs (Device I/O Control Codes) construídos para disparar a vulnerabilidade do driver. As falhas mais exploradas são leitura/escrita arbitraria de memória do kernel, mapeamento de memória física para user-mode e execução de instruções privilegiadas (MSR read/write).

Etapas 6-7: Controle do kernel e desativação de defesas. Com primitivas de kernel, o atacante remove callbacks registrados pelo EDR (ObRegisterCallbacks, PsSetCreateProcessNotifyRoutine), zera handles de minifilters do antivirus, modifica estruturas de processo do agente de segurança é desativa o ETW (Event Tracing for Windows) para eliminar logs.

Etapa 8: Payload final. Com o EDR desativado e sem logging, o atacante executa ransomware, exfiltra dados ou estabelece persistência sem obstáculos.

---

Exemplos reais de ataques BYOVD

Linha do tempo de incidentes documentados

Lazarus Group e o driver Dell dbutil_2_3.sys

O Lazarus Group, APT vinculado a Coreia do Norte, explorou o driver dbutil_2_3.sys da Dell (CVE-2021-21551), uma falha de controle de acesso que permitia leitura e escrita arbitraria na memória do kernel. Com esse acesso, implantaram o rootkit FudModule, que desativava sistemáticamente callbacks de criação de processo, minifilters e ETW, além de limpar rastros da própria instalação.

O ponto crítico: o dbutil_2_3.sys e distribuído pela Dell como parte do pacote BIOS Útility, presente em milhões de máquinas corporativas. A vulnerabilidade foi divulgada em maio de 2021 e a Dell publicou atualização, mas a versão vulnerável permanece disponível publicamente e pode ser instalada em qualquer sistema Windows que aceite drivers assinados.

BlackByte e a desativação massiva de callbacks

O BlackByte utilizou o driver RTCore64.sys da MSI (CVE-2019-16098) para desenvolver um loader que automaticamente enumerava e removia callbacks de kernel de mais de 1.000 drivers de produtos de segurança. A lista de drivers-alvo era mantida em tabela hardcoded, atualizada a cada versão, tornando a ferramenta eficaz contra virtualmente qualquer EDR do mercado.

Cuba ransomware e o loader BurntCigar

Os operadores do Cuba ransomware criaram o BurntCigar, ferramenta modular que explorava diferentes drivers vulneráveis conforme o ambiente-alvo. A campanha causou prejuizos estimados em mais de USD 60 milhões, atingindo infraestrutura crítica, setor financeiro e governo. FBI e CISA emitiram alerta conjunto AA22-335A sobre essa operação.

---

Por que o EDR tradicional falha contra BYOVD

A falha do EDR contra BYOVD não é um bug de implementação, é uma limitação arquitetural.

O paradoxo de confiança do kernel. Agentes de EDR operam no kernel por meio de callbacks e minifilters. Quando um atacante obtém primitivas de leitura e escrita através de um driver vulnerável, ele opera no mesmo ring 0 que o EDR. Não existe hierarquia de privilegio entre os dois, o atacante pode desativar o EDR como desativaria qualquer componente de kernel.

Assinatura digital não é indicador de segurança. A assinatura atesta que o driver foi produzido por um fornecedor identificavel e que o binário não foi alterado. Não atesta ausência de vulnerabilidades, versão atualizada ou que o driver ainda deveria ser confiável. Um driver assinado em 2018 com vulnerabilidade crítica descoberta em 2021 contínua sendo aceito pelo Windows em 2026, a menos que esteja em uma blocklist ativa.

Detecção comportamental tem limites. Como o driver e legítimo e assinado, é a carga de drivers e operação normal do sistema, a taxa de falso positivo e alta. Muitas soluções optam por não alertar sobre carga de drivers assinados para evitar fadiga de alertas.

---

Estratégias de detecção e prevenção

A defesa contra BYOVD requer múltiplas camadas. Nenhuma medida isolada é suficiente.

Driver blocklist: LOLDrivers e Microsoft HVCI

A Microsoft mantém uma lista de drivers conhecidamente vulneráveis bloqueaveis por dois mecanismos: HVCI (Hypervisor-Protected Code Integrity), que usa o hypervisor para impedir a carga de drivers na blocklist, e WDAC (Windows Defender Application Control), que aplica políticas de controle sobre quais drivers são permitidos.

O projeto LOLDrivers (Living Off The Land Drivers) complementa a lista da Microsoft. Mantido pela comunidade de segurança, cataloga mais de 700 drivers vulneráveis com hashes SHA-256, CVEs associadas, tipo de vulnerabilidade e grupos de ameaça que os utilizam. É a referência mais completa para identificar drivers exploráveis.

A blocklist da Microsoft e atualizada periodicamente, mas existe um gap temporal entre a descoberta de um driver vulnerável e sua inclusão. Complementar com hashes do LOLDrivers via WDAC fecha essa lacuna.

Monitoramento e controles adicionais

• Monitoramento de carga de drivers, Configurar auditoria via Sysmon (Event ID 6) e alertar sobre carga de drivers de diretorios incomuns (Temp, ProgramData) ou com hashes do LOLDrivers.
• ASR Rules, Regras de Attack Surface Reduction no Microsoft Defender bloqueiam processos não confiaveis que tentam instalar drivers de kernel.
• Privilegio mínimo, Como BYOVD requer admin local, implementar LAPS e remover usuários desnecessários de grupos de administradores locais interrompe a cadeia de ataque.
• Monitoramento de saúde do EDR, Verificação externa periódica de que o agente está ativo. Endpoint sem telemetria por mais de 15 minutos deve gerar alerta crítico.

---

O papel da gestão de vulnerabilidades na defesa contra BYOVD

A gestão de vulnerabilidades é a camada de defesa mais eficaz contra BYOVD a médio e longo prazo, porque ataca o problema na raiz: a existência de drivers vulneráveis no ambiente.

Inventário de drivers como base de defesa

Defender-se contra BYOVD exige saber quais drivers estão presentes em cada endpoint. Isso vai além do inventário de software convencional, requer visibilidade sobre drivers de kernel carregados, versões exatas, drivers presentes no disco mas não carregados e drivers de hardware sem atualização há anos.

O módulo Inventory da EcoTrust identifica versões de drivers instalados nos endpoints, criando uma base de dados que permite cruzamento com listas de drivers vulneráveis. Sem esse inventário, a organização não sabe quais drivers vulneráveis já estão presentes e disponíveis para um atacante.

Detecção de tecnologias em fim de vida

Drivers de hardware frequentemente pertencem a dispositivos cujo suporte foi encerrado. Uma controladora RAID cujo driver não recebe atualizações desde 2019 representa risco permanente, vulnerabilidades futuras nunca serão corrigidas.

O módulo VulScan da EcoTrust detecta tecnologias em fim de vida (end-of-life), sinalizando ativos com componentes sem suporte. Isso é particularmente relevante para BYOVD: muitos dos drivers explorados em ataques reais pertencem a produtos descontinuados.

Priorização baseada em risco real

Nem todos os drivers vulneráveis representam o mesmo risco. Um driver com vulnerabilidade de read/write no kernel, presente no LOLDrivers e usado em campanhas de ransomware, e crítico. Um driver com denial of service local, sem exploit público, e menos urgente.

O módulo GVul da EcoTrust prioriza vulnerabilidades com base em severidade técnica (CVSS), probabilidade de exploração (EPSS), existência de exploit público, presença no CISA KEV e contexto do ativo. Equipes focam primeiro nos drivers com risco real de BYOVD.

---

Mitigação em 8 passos: checklist para analistas

1. Inventariar todos os drivers de kernel presentes nos endpoints, incluindo versões e hashes. Utilizar o módulo Inventory para visibilidade completa.

2. Cruzar o inventário com o catalogo LOLDrivers e CVEs conhecidas. Quantificar drivers vulneráveis a BYOVD já presentes no ambiente.

3. Ativar HVCI é a Microsoft Vulnerable Driver Blocklist em todos os endpoints compatíveis. Iniciar em modo de auditoria, migrar para bloqueio após validação.

4. Atualizar ou remover drivers vulneráveis, priorizando aqueles com vulnerabilidades de read/write no kernel presentes no LOLDrivers.

5. Restringir privilegios de administrador local com LAPS e remocao de usuários desnecessários. BYOVD requer admin local; sem ele, a cadeia de ataque e interrompida.

6. Configurar monitoramento de carga de drivers via Sysmon (Event ID 6) e correlacionar com hashes de drivers vulneráveis no SIEM.

7. Implementar monitoramento de saúde do EDR que alerte quando agentes param de reportar. Regra sugerida: "endpoint sem telemetria por 15 minutos = alerta crítico".

8. Estabelecer ciclo contínuo de gestão de vulnerabilidades para drivers com GVul para priorização e VulScan para detecção de novas vulnerabilidades.

---

Como a EcoTrust fortalece a defesa contra BYOVD

A EcoTrust é uma plataforma de IA Agêntica para CTEM (Continuous Threat Exposure Management) que aborda BYOVD em múltiplas frentes:

• Inventory, identifica versões de drivers nos endpoints, permitindo cruzamento com listas de drivers vulneráveis e detecção de componentes em fim de vida.

• VulScan, detecta tecnologias em fim de vida e vulnerabilidades em componentes de sistema, incluindo drivers que escapam de programas de patch management focados apenas em aplicações.

• GVul, prioriza vulnerabilidades com base em contexto de ameaça real (EPSS, CISA KEV, exploits públicos) e contexto do ativo, garantindo que drivers exploráveis para BYOVD recebam atenção prioritária.

Conheça o módulo GVul e veja como priorizar vulnerabilidades de drivers com base em risco real ->

---

Perguntas frequentes sobre BYOVD

O que significa BYOVD? BYOVD é a sigla de Bring Your Own Vulnerable Driver. É uma técnica em que o adversário instala um driver de kernel legítimo e assinado, porém vulnerável, para obter privilegios de ring 0 e desativar controles de segurança como EDR e antivirus.

BYOVD funciona apenas no Windows? A técnica e predominantemente associada ao Windows devido ao modelo de assinatura de drivers e ao ecossistema extenso de drivers de terceiros. Variantes conceituais existem em outros sistemas que permitem módulos de kernel de terceiros.

Meu EDR não deveria bloquear a instalação de drivers vulneráveis? A maioria das soluções de EDR não bloqueia drivers assinados por padrão, pois isso causaria falsos positivos em larga escala. Algumas soluções recentes incluem detecção de drivers do LOLDrivers, mas essa proteção não é universal.

Se eu ativar HVCI, estou protegido contra BYOVD? HVCI reduz significativamente a superfície de ataque, mas a blocklist não cobre todos os drivers vulneráveis conhecidos e existe gap temporal até a inclusão de novos drivers. HVCI é essencial, mas não suficiente isoladamente.

Qual a relação entre BYOVD e gestão de vulnerabilidades? A gestão de vulnerabilidades permite identificar e remediar drivers vulneráveis antes que um atacante os explore. Ao manter inventário atualizado de drivers e priorizar a remocao dos que contém vulnerabilidades exploráveis, a organização elimina o recurso que o atacante precisa para executar BYOVD.

---

Para aprofundamento, consulte a referência oficial: CISA — Stop Ransomware.

Conclusão

BYOVD representa uma evolução significativa nas técnicas de evasão de defesas. Ao explorar a cadeia de confiança de drivers assinados do Windows, atacantes operam no nível mais privilegiado do sistema e desativam os controles que deveriam proteger a organização.

A defesa eficaz requer controles preventivos (HVCI, blocklists, restrição de privilegios), controles detectivos (monitoramento de drivers, saúde do EDR) e, fundamentalmente, uma gestão de vulnerabilidades que trate drivers com a mesma seriedade que aplicações e sistemas operacionais.

Organizações que investem em visibilidade completa sobre seus ativos, incluindo drivers de kernel, e priorizam vulnerabilidades com base em risco real estão melhor posicionadas para prevenir ataques BYOVD. A abordagem de CTEM da EcoTrust, integrando Inventory, VulScan e GVul, oferece exatamente essa capacidade.

Agende uma demonstração e veja como a EcoTrust identifica drivers vulneráveis no seu ambiente ->