Análise de exploração mostra como objetos de dispositivo, rotinas AddDevice e fluxos Plug and Play influenciam a viabilidade de abuso BYOVD a partir do modo usuário.
| Componente | drivers de modo kernel do Windows, especialmente drivers Plug and Play que expõem device objects, rotinas AddDevice e manipuladores IRP_MJ_PNP ou IRP_MJ_DEVICE_CONTROL. |
| Vetor | interação a partir do modo usuário com objetos de dispositivo acessíveis, inclusive por chamadas que geram IRPs como DeviceIoControl, quando a vulnerabilidade permanece alcançável sem a presença do hardware físico original. |
| Impacto | em falhas exploráveis, o abuso pode permitir elevação local de privilégio ou uso BYOVD para afetar componentes de segurança resistentes a adulteração, incluindo leitura ou escrita arbitrária de memória, execução de código, sobrescrita de arquivos, fechamento de handles ou término de processos. |
| Prioridade | validar se o driver cria ou mantém objetos de dispositivo sem hardware, se inicializa estado interno suficiente para alcançar o caminho vulnerável e se pode ser carregado sob demanda por um atacante com privilégios locais adequados. |
| Versões | os testes descritos foram conduzidos no Windows 11 23H2, versão 10.0.22631.3007. |
| Artefatos | os elementos técnicos centrais são DRIVER_OBJECT, DRIVER_EXTENSION, DeviceObject, extensão de dispositivo, DriverEntry, AddDevice, IoCreateDevice, IoDeleteDevice, IoAttachDeviceToStack, IRP_MJ_PNP e IRP_MJ_DEVICE_CONTROL. |
A superfície de ataque analisada está no comportamento de drivers de modo kernel do Windows quando são carregados em sistemas que não possuem o hardware para o qual foram originalmente desenvolvidos. O ponto principal não é uma classe específica de bug, mas a condição de alcançabilidade: uma vulnerabilidade em driver só se torna interessante para exploração local ou para abuso BYOVD quando o código vulnerável pode ser exercitado a partir do modo usuário. Em muitos casos, essa condição depende da existência de um objeto de dispositivo, da inicialização correta de estruturas internas e do caminho de execução criado pelo gerenciador Plug and Play. O problema prático é que a ausência do hardware pode impedir essas etapas, mas nem sempre bloqueia completamente a interação com o driver.
O cenário é particularmente importante para BYOVD, técnica em que um invasor traz ou carrega um driver vulnerável para obter capacidades privilegiadas no núcleo. O valor ofensivo de um driver nessa categoria depende de dois critérios técnicos: a exploração precisa permitir uma ação relevante contra o sistema, como leitura ou escrita arbitrária de memória, execução de código, abuso de recursos, sobrescrita de arquivos, fechamento de handles ou término de processos; e a exploração não pode depender de uma condição rara, como a instalação de um dispositivo físico específico. Quando um driver vulnerável continua alcançável sem o hardware, ele se torna um candidato mais forte para uso pós-exploração contra mecanismos de defesa, incluindo componentes de EDR, antivírus, monitoramento e autenticação reforçada que operam com proteção contra adulteração.
Em drivers simples, especialmente não Plug and Play, a criação do objeto de dispositivo pode ocorrer diretamente em DriverEntry ou em uma função chamada por essa cadeia inicial. Nessa arquitetura, o driver pode ser carregado como serviço de kernel sob demanda e já expor um objeto de dispositivo após a execução da rotina de entrada. Um fluxo desse tipo reduz as barreiras para interação a partir do modo usuário, porque o atacante não precisa convencer o gerenciador Plug and Play a montar uma pilha de dispositivo. O ciclo também tende a ser direto: o driver cria o objeto com uma chamada como IoCreateDevice, processa requisições por rotinas de despacho e remove o objeto apenas no descarregamento, por exemplo com IoDeleteDevice durante DriverUnload.
A situação muda em drivers compatíveis com Plug and Play, que representam grande parte dos drivers associados a hardware real. Neles, DriverEntry normalmente registra ponteiros de rotinas no DRIVER_OBJECT, mas não executa automaticamente toda a inicialização operacional. O ponteiro para AddDevice fica em DriverObject->DriverExtension->AddDevice, enquanto rotinas de despacho como a de IRP_MJ_DEVICE_CONTROL são gravadas em posições específicas do objeto de driver e só rodam quando o driver recebe uma requisição compatível. A rotina AddDevice é acionada pelo gerenciador Plug and Play depois da descoberta de um nó de dispositivo e da decisão de que aquele driver controlará o dispositivo ou atuará como filtro na pilha. Sem essa chamada, objetos funcionais de dispositivo, objetos de filtro, filas de I/O em KMDF e variáveis internas necessárias podem nunca ser criados.
A criação do objeto de dispositivo é uma fronteira crítica porque muitos caminhos vulneráveis dependem dele para receber IRPs vindos do modo usuário. Em uma implementação típica de AddDevice, o driver cria um FDO ou um objeto de filtro com IoCreateDevice, aloca uma extensão de dispositivo com tamanho definido pelo próprio driver, inicializa estado residente em espaço de sistema e pode anexar o objeto à pilha por IoAttachDeviceToStack. A extensão de dispositivo não deve ser confundida com a extensão do driver: a primeira é individual por objeto de dispositivo e armazena estado operacional, travas, filas e recursos; a segunda está associada ao DRIVER_OBJECT e inclui o ponteiro para AddDevice. Se a extensão de dispositivo não for inicializada, o objeto existir sozinho pode não bastar para alcançar o comportamento vulnerável.
Há dois bloqueios frequentes na exploração de drivers instalados sem hardware: o objeto de dispositivo pode nunca ser criado, ou o objeto pode existir, mas o estado interno não permite acionar a lógica vulnerável. Drivers de segurança também podem verificar chaves e valores de registro criados durante a instalação completa do produto antes de inicializar componentes de kernel. Já drivers de hardware podem não criar objetos sem a enumeração do dispositivo correspondente ou podem criar e remover rapidamente esses objetos quando detectam a falta do equipamento, o que abre uma janela curta de corrida. Essa janela não equivale automaticamente a exploração, mas altera a análise de alcançabilidade porque o objeto pode existir temporariamente enquanto um processo em modo usuário tenta abrir um handle ou enviar uma requisição.
A superfície exposta é formada por drivers de modo kernel que podem ser carregados em uma máquina sem o dispositivo original e ainda assim criar objetos acessíveis, registrar rotinas de despacho úteis ou manter estado suficiente para processar requisições. Drivers não Plug and Play, por criarem seus objetos durante a inicialização do serviço de kernel, tendem a ser mais simples de avaliar. O comando de implantação de um driver de kernel sob demanda com sc.exe create exemplifica esse modelo operacional, no qual o binário pode ser colocado em um caminho de drivers e iniciado como serviço. Essa facilidade de carga não prova vulnerabilidade, mas remove a dependência de enumeração física do hardware.
Nos drivers Plug and Play, a superfície é condicionada por nós de dispositivo, pilhas de dispositivo, objetos PDO fornecidos por drivers de barramento, objetos FDO criados pelo próprio driver e objetos de filtro quando o driver atua sobre uma pilha existente. Como AddDevice recebe parâmetros fornecidos pelo gerenciador Plug and Play, a ausência do caminho normal de enumeração pode impedir a montagem completa da pilha. Ainda assim, a análise precisa verificar se existe algum caminho alternativo de inicialização, se objetos são criados e apagados em sequência, se rotinas de despacho ficam registradas após DriverEntry e se o driver permite comunicação por nomes de dispositivo ou interfaces expostas ao usuário.
A presença de um objeto de dispositivo não encerra a avaliação. Um driver pode aceitar abertura de handle, mas rejeitar operações porque campos da extensão de dispositivo não foram preenchidos, filas WDF não foram criadas ou o manipulador PnP não colocou o dispositivo em estado operacional. Também é necessário considerar produtos de segurança que validam entradas de registro específicas antes de habilitar rotinas sensíveis. Para operadores defensivos, isso significa que a exposição real combina binário carregável, objeto alcançável, controle de acesso sobre o objeto, sequência de inicialização e capacidade de acionar o caminho vulnerável por IRPs ou outros mecanismos de chamada a partir do modo usuário.
- Drivers não Plug and Play que criam objetos de dispositivo durante
DriverEntryou em chamadas diretas da rotina de entrada. - Drivers Plug and Play cuja lógica sensível depende de
AddDevice,IRP_MJ_PNP, filas KMDF ou estado armazenado na extensão de dispositivo. - Drivers que criam objetos temporariamente e depois chamam
IoDeleteDevicequando o hardware esperado não está presente. - Componentes de segurança de kernel que exigem chaves de registro ou configuração de produto antes de expor comportamento operacional.
A detecção deve começar pela observação de carregamento de drivers de kernel que não fazem parte do inventário esperado do host. Em um cenário BYOVD, o atacante precisa tornar o driver disponível e carregá-lo, frequentemente como serviço de kernel sob demanda. O comando sc.exe create SampleDrv type= kernel start= demand binPath= System32\drivers\SampleDrv.sys ilustra a forma de implantação discutida tecnicamente, e operações semelhantes devem ser correlacionadas com criação de serviço, escrita de binário em diretórios de drivers, tentativa de início do serviço e eventos de carregamento de imagem de kernel. A telemetria deve separar instalação legítima de produto, atualização controlada e carregamento manual incomum.
Depois do carregamento, a investigação precisa buscar interações do modo usuário com objetos de dispositivo. Isso inclui abertura de handles para nomes de dispositivo, chamadas que resultem em IRP_MJ_DEVICE_CONTROL, sequências repetidas de DeviceIoControl e falhas de inicialização seguidas de remoção do objeto com comportamento de corrida. Em drivers Plug and Play, sinais de interesse incluem ausência do hardware esperado, criação parcial de pilha, execução de AddDevice, falhas em IRP_MJ_PNP e estado de dispositivo que não progride para operação normal. Quando disponível, a telemetria de EDR ou do próprio sistema deve associar o processo chamador, o driver carregado, o serviço criado e o tempo entre criação e exclusão do objeto.
Para pesquisa de vulnerabilidade e validação defensiva, a inspeção estática do binário também é relevante. A análise deve localizar DriverEntry, identificar a escrita de ponteiros em DRIVER_OBJECT, verificar se DriverExtension->AddDevice é preenchido, mapear rotinas de despacho como IRP_MJ_DEVICE_CONTROL e observar chamadas a IoCreateDevice, IoDeleteDevice e IoAttachDeviceToStack. Em seguida, a análise dinâmica deve confirmar se esses caminhos são executados em uma instalação sem hardware. O objetivo não é apenas confirmar que o driver carrega, mas determinar se o estado interno necessário para alcançar a vulnerabilidade existe em condições reproduzíveis.
- Criação ou início de serviço de kernel sob demanda para um binário de driver fora do inventário autorizado.
- Escrita de driver em caminho de sistema seguida de carregamento e comunicação por handle de dispositivo.
- Chamadas de modo usuário que acionam
IRP_MJ_DEVICE_CONTROLcontra objetos de dispositivo recém-criados. - Criação e remoção rápida de objetos de dispositivo em máquinas sem o hardware correspondente.
- Execução de
AddDeviceou falhas deIRP_MJ_PNPassociadas a pilhas de dispositivo incompletas.
A resposta defensiva deve tratar drivers vulneráveis como ativos executáveis de alto impacto, não apenas como arquivos auxiliares de hardware. O primeiro passo é inventariar drivers de kernel permitidos, restringir a carga de binários não aprovados e monitorar a criação de serviços do tipo kernel. Quando houver suspeita de abuso BYOVD, a contenção deve preservar evidências de criação de serviço, caminho do binário, processo responsável, horário de carregamento, interações com objetos de dispositivo e efeitos sobre componentes de segurança. Se o driver foi usado para interferir em EDR, antivírus ou monitoramento, a validação precisa confirmar se processos foram terminados, handles foram fechados, arquivos foram sobrescritos ou memória de kernel foi manipulada.
Na engenharia de produto e na pesquisa de vulnerabilidades, a mitigação passa por reduzir a alcançabilidade desnecessária. Drivers devem evitar criar objetos acessíveis antes de validar estado essencial, devem aplicar controle de acesso rigoroso aos objetos expostos e devem falhar de maneira limpa quando o hardware ou a configuração esperada não existe. Em drivers Plug and Play, a lógica sensível deve depender de inicialização completa e estados verificáveis, e não apenas da presença de um objeto. Para drivers de segurança, verificações de configuração e registro precisam ser robustas o suficiente para impedir inicialização parcial que exponha rotinas privilegiadas sem o produto instalado corretamente.
Em ambientes corporativos, a medida prática é combinar política de bloqueio de drivers vulneráveis, controle de aplicação, telemetria de carregamento de kernel e revisão contínua de exceções. A análise de alcançabilidade sem hardware deve fazer parte da priorização de vulnerabilidades em drivers: um bug com impacto alto, mas dependente de hardware raro, tem perfil operacional diferente de uma falha que pode ser acionada em qualquer estáção onde o driver possa ser carregado. A validação deve reproduzir o carregamento em sistema sem o dispositivo, verificar a criação do objeto, testar se as rotinas de despacho aceitam requisições e confirmar se o caminho vulnerável é alcançado sem preencher lacunas por suposição.
- Bloquear ou restringir drivers de kernel não autorizados e revisar exceções de allowlist.
- Monitorar criação de serviços
type= kernel, gravação de binários de driver e início sob demanda. - Auditar objetos de dispositivo expostos ao modo usuário e seus descritores de segurança.
- Validar se drivers vulneráveis permanecem exploráveis sem hardware antes de definir prioridade de correção.
- Projetar drivers para não expor rotinas sensíveis sem inicialização completa, estado interno válido e controles de acesso adequados.
0 Comentários