## 1 Introdução Este artigo fornece uma análise técnica de como muitos drivers em modo kernel do Windows podem ser interagidos a partir do modo de usuário sem o hardware para o qual foram desenvolvidos. Este trabalho foi motivado pela pesquisa de vulnerabilidades orientadas a drivers e pela necessidade de avaliar a explorabilidade de descobertas individuais, que frequentemente afetam código cuja alcançabilidade é controlada por hardware. A metodologia apresentada aqui deve ajudar qualquer pessoa a determinar se uma vulnerabilidade particular de driver em modo kernel do Windows permanece alcançável - e, portanto, potencialmente explorável - mesmo na ausência do hardware para o qual o driver foi desenvolvido. Espera-se que o leitor tenha conhecimento básico de drivers do Windows, especialmente em relação a objetos de dispositivo. O restante deste artigo é escrito com a suposição de que o leitor já está familiarizado com os conceitos descritos no artigo introdutório: [Anatomy of Access: Windows Device Objects from a Security Perspective](https://atos.net/en/lp/cybershield/anatomy-of-access-windows-device-objects-from-a-security-perspective). Assim como o artigo introdutório, este recurso não se concentra em nenhuma classe específica de bug, mas sim na superfície de ataque e, em certa medida, na arquitetura Plug and Play do Windows. Todos os testes demonstrados aqui foram realizados no **Windows 11 23H2** (winver 10.0.22631.3007). >Para mais pesquisas de ameaças e avisos de vulnerabilidade mais recentes como esta, por favor, inscreva-se nos [blogs do **Atos Cyber Shield**](https://atos.net/en/lp/cybershield#subscription-form). ## 2 O valor ofensivo de drivers em modo kernel Além do potencial óbvio de Escalada de Privilégios Local, drivers vulneráveis são frequentemente abusados em ataques BYOVD - uma técnica pós-exploração utilizada por atacantes para interromper defesas do sistema, como componentes EDR. Dois critérios principais determinam se uma vulnerabilidade de driver é um forte candidato para ataques BYOVD: 1. A exploração permite uma interrupção significativa de um componente de segurança que, de outra forma, seria resistente a adulterações. Exemplos incluem vulnerabilidades em nível de kernel que concedem acesso arbitrário de leitura/escrita de memória, execução arbitrária de código ou abuso arbitrário de recursos (por exemplo, sobrescrever arquivos, fechar handles ou encerrar processos). 2. Sua explorabilidade é independente de condições raras do sistema, como a presença de hardware específico. Embora ataques do tipo BYOVD tenham sido bem documentados por anos, com inúmeros relatórios públicos e artigos de pesquisa sobre o tema (por exemplo, [https://www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf), [https://blackpointcyber.com/blog/qilin-ransomware-and-the-hidden-dangers-of-byovd/](https://blackpointcyber.com/blog/qilin-ransomware-and-the-hidden-dangers-of-byovd/), [https://www.sophos.com/en-us/blog/itll-be-back-attackers-still-abusing-terminator-tool-and-variants](https://www.sophos.com/en-us/blog/itll-be-back-attackers-still-abusing-terminator-tool-and-variants)), nenhum deles examina especificamente o papel do bloqueio de hardware na alcançabilidade de vulnerabilidades de driver. ## 3 Criação e manutenção de objetos de dispositivo - padrões comuns A análise fornecida neste recurso é estruturada em torno de objetos de dispositivo, pois eles são o vetor de ataque mais viável. No entanto, as técnicas demonstradas aqui impactam praticamente a alcançabilidade do código do driver a partir do userland em geral, não apenas via IRP. Os obstáculos mais comuns ao atacar um driver através de seu objeto de dispositivo são: 1. O objeto de dispositivo não é criado. 2. O estado interno do driver não permite o exercício do comportamento vulnerável, apesar de o objeto de dispositivo ser acessível. Ambos os cenários são muito comuns ao lidar com um driver de dispositivo implantado em um sistema sem o hardware físico correspondente. No restante do artigo, refiro-me frequentemente a [device stacks e device nodes](https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/device-nodes-and-device-stacks). Cobri device stacks de forma bastante ampla em meu [artigo introdutório](https://atos.net/en/lp/cybershield/anatomy-of-access-windows-device-objects-from-a-security-perspective). Embora um device node e um device stack não sejam a mesma coisa, os termos são frequentemente usados de forma intercambiável, pois cada device node possui exatamente um device stack. ### 3.1 Criação incondicional ao carregar o driver Muitos drivers, especialmente drivers não-PnP, criam seus objetos de dispositivo diretamente de sua função `DriverEntry`, ou de alguma outra função que é invocada na cadeia de chamadas direta originada de `DriverEntry`. O [**driver de demonstração Multidev_WDM**](https://github.com/Atos-TRC/Atos-TRC-public-samples-and-code/windows-kernel-mode/kernel/multidev_WDM/) exemplifica este padrão. Podemos ver a criação do dispositivo invocada imediatamente em `DriverEntry`:  Criação de CDO invocada diretamente de `DriverEntry` O driver também remove o objeto de dispositivo chamando `IoDeleteDevice`, mas isso só acontece quando `DriverUnload` é chamado (quando o driver está sendo descarregado):  Limpeza de CDO de `DriverUnload` Drivers construídos dessa forma podem ser interagidos após uma implantação simples que consiste em apenas duas etapas: 1. Crie a entrada de serviço do driver: sc.exe create SampleDrv type= kernel start= demand binPath= System32\drivers\SampleDrv.sys * Inicie o serviço (o driver será carregado): sc.exe start SampleDrv Se olharmos para um driver escolhido aleatoriamente em [https://loldrivers.io/](https://loldrivers.io/), veremos que seu comando de implantação corresponde a este padrão:  Implantação do LOL drivers - zam64.sys Mas a maioria dos drivers de dispositivo não se enquadra nesta categoria, como veremos nas seções seguintes deste artigo. ### 3.2 Criação e manutenção condicional de dispositivo Frequentemente, as rotinas de inicialização de drivers realizam verificações adicionais. Por exemplo, componentes em modo kernel de software de segurança (**EDR**, antivírus, monitoramento, autenticação aprimorada etc.) tendem a verificar chaves e entradas de registro específicas do produto, que são criadas e inicializadas durante a implantação normal do produto. Drivers de dispositivo reais (criados para controlar hardware físico) tendem a criar seus objetos de dispositivo apenas na presença desse hardware. Sem ele, eles: * não tentam criar nenhum objeto de dispositivo, * removem quaisquer objetos de dispositivo logo após sua criação, chamando `IoDeleteDevice`. Vamos focar em como essa lógica é implementada e avaliar se e como ela pode ser contornada, especialmente da perspectiva BYOVD - operando unicamente a partir do userland (sem acesso físico/hypervisor). A propósito, o segundo cenário, em que um objeto de dispositivo é primeiro criado e depois excluído logo em seguida, cria uma situação que pode ser considerada uma condição de corrida, pois há uma pequena janela de tempo em que o objeto de dispositivo existe. ### 3.3 Callbacks específicos de PnP como o local principal da lógica de inicialização de drivers PnP Em drivers compatíveis com PnP (que compõem a maior parte dos drivers de dispositivo