athenasec16/cve-2026-29923Exploit de prova de conceito para CVE-2026-29923, uma escalada de privilégio BYOVD no pstrip64.sys. Demonstra leitura/escrita de memória física via IOCTL para roubar token de SYSTEM e gerar shell elevado.
Aviso: Este código é fornecido apenas para fins educacionais e de pesquisa defensiva. Foi escrito para aprofundar o conhecimento sobre exploração de kernel e ajudar defensores a se protegerem contra vulnerabilidades semelhantes. Qualquer uso não autorizado, ilegal ou malicioso deste projeto é estritamente proibido.
Hash: ab01485bb7c8bc1a9c86096eeea6d31d8fad557bf4d44072b46373d2203faa6e
Nome do Driver: pstrip64.sys
CVE: CVE-2026-29923
Um ataque "Bring Your Own Vulnerable Driver" (BYOVD) é uma técnica antiga, mas altamente eficaz, para invasores contornarem as proteções modernas de segurança do Windows, usando um driver legado que o sistema operacional ainda considera oficialmente confiável. Uma vez que o driver é carregado, o invasor utiliza suas falhas para preencher a lacuna entre um processo padrão sem privilégios e o controle total do sistema.
No início desta semana, uma nova vulnerabilidade foi divulgada no driver pstrip64.sys, registrada como CVE-2026-29923. Esta publicação detalha todo o ciclo de vida do exploit: desde minha pesquisa inicial de vulnerabilidade e o desenvolvimento da Prova de Conceito (PoC) até estratégias práticas de mitigação para defensores que protegem seus ambientes.
O driver pstrip64.sys é um componente legado em modo kernel associado ao EnTech Taiwan PowerStrip (até a versão 3.90.736). Embora seu propósito legítimo seja permitir ajustes avançados em placas gráficas, seus profundos privilégios de sistema o tornam um alvo altamente atraente para invasores.
Quando a vulnerabilidade foi divulgada pela primeira vez, comecei analisando sua função DriverEntry. Esta serve como a rotina principal de inicialização do driver do kernel, criando o objeto de dispositivo \Device\PSTRIP64 e expondo-o a aplicativos em modo de usuário através do link simbólico \DosDevices\PSTRIP64. Mais importante ainda, ela configura a tabela de despacho do driver. A entrada que imediatamente chamou minha atenção foi o índice 14 (IRP_MJ_DEVICE_CONTROL), que roteia todas as requisições IOCTL fornecidas pelo usuário diretamente para a função manipuladora sub_11340, nossa área principal de interesse.
A função sub_11340 atua como o despachante principal de IOCTLs, interpretando requisições do modo de usuário.
Dentre todos os IOCTLs expostos, o 0x80002008 é sem dúvida o mais interessante. Enquanto os casos padrão lidam com interações menores de portas de E/S, o 0x80002008 funciona como uma porta de entrada para sub_11000, passando o SystemBuffer diretamente para esta função.
Esta rotina sub_11000 é a prova do crime. Primeiro, ela usa HalTranslateBusAddress para pegar o endereço fornecido pelo usuário e traduzi-lo em um endereço físico de sistema válido. Em seguida, abre \Device\PhysicalMemory e o mapeia usando ZwMapViewOfSection. Ao codificar o identificador do processo alvo como (HANDLE)0xFFFFFFFFFFFFFFFFLL (que representa ZwCurrentProcess()), o driver mapeia esta memória física diretamente no espaço de endereço virtual do nosso processo de chamada. Crucialmente, ele então escreve este endereço virtual recém-mapeado de volta no SystemBuffer para retornar ao usuário, entregando oficialmente ao nosso aplicativo um ponteiro direto para ler e escrever na memória física.
Com a vulnerabilidade totalmente compreendida e uma primitiva de leitura/escrita física estabelecida, tenho todas as peças necessárias. Agora, é hora de começar a escrever a Prova de Conceito.
Nota: Esta PoC foi especificamente desenvolvida e testada em um ambiente Windows 10 22H2. Como o exploit depende de manipulação bruta de memória física, os offsets das estruturas do kernel e os limites da memória física estão atualmente codificados para minha configuração. Para testar em sua própria máquina, você deve atualizar os offsets do kernel do Windows e ajustar os intervalos de varredura de endereços físicos para corresponder à sua versão específica do sistema operacional e configuração de RAM.
O primeiro passo no meu exploit é estabelecer comunicação com o driver. Fiz isso chamando CreateFileA no link simbólico do driver (\\.\PSTRIP64). Assim que obtive um identificador válido, precisava de uma maneira limpa de abusar do IOCTL 0x80002008 que analyzei anteriormente. Criei uma função wrapper chamada MapPhysicalMemory(). Esta função preenche minha estrutura personalizada PSTRIP_MAP_REQUEST com o endereço físico alvo e o comprimento do bloco de memória que quero ler.
Em seguida, envio esta estrutura diretamente ao driver via DeviceIoControl. Se for bem-sucedido, o driver mapeia aquela memória física diretamente no meu aplicativo em modo de usuário e retorna o endereço virtual base no campo OutputResult. Agora posso converter este endereço retornado em um ponteiro C++ padrão, dando-me acesso bruto e sem privilégios à RAM física do sistema.
Com minha primitiva de leitura/escrita física totalmente operacional, meu objetivo era encontrar as estruturas de dados do kernel que contêm os privilégios dos processos. No Windows, cada processo em execução é representado por uma estrutura EPROCESS.
O Windows aloca estruturas EPROCESS no pool do kernel usando um identificador de 4 bytes chamado Pool Tag. Para processos, esta tag é a string Proc (que se traduz em 0x636F7250 em hexadecimal). Ao escanear a RAM física do sistema, pude pesquisar por esta string exata.
Meu exploit percorre o espaço de memória física de 0x10000000 a 0x140000000, mapeando a memória em chunks de 2MB (STEP_SIZE = 0x200000). Convierto cada chunk mapeado em um array bruto de bytes e o escaneio em chunks de 16 bytes (sizeof(_POOL_HEADER)).
No entanto, simplesmente encontrar a tag Proc na memória física não é suficiente. A memória é bagunçada; essa tag pode ser um artefato residual de um processo encerrado, ou apenas dados aleatórios que coincidem com o valor hexadecimal. Se eu assumisse cegamente que toda tag Proc era uma estrutura EPROCESS válida e começasse a modificar a memória, causaria imediatamente uma BSOD.
Para garantir estabilidade, tive que validar a estrutura usando heurísticas. Primeiro, calculo o início da estrutura EPROCESS (que fica ligeiramente deslocada da tag do pool). A partir daí, verifico algumas constantes conhecidas para um processo em execução:
0x2 (Prioridade Normal).0x0.Se todas essas heurísticas passarem, posso ter alta confiança de que estou olhando para um processo válido e ativo. Então leio seu Identificador Único de Processo (PID). Se o PID corresponder ao meu próprio processo de exploit, salvo o endereço físico do seu ponteiro de token. Se o PID for 4 (o processo System do Windows), extraio e salvo o valor real do seu token altamente privilegiado.
Finalmente, alinho o endereço físico salvo do ponteiro de token do meu processo para o limite de 4KB mais próximo e uso MapPhysicalMemory() uma última vez para mapear apenas aquela página específica.
Em seguida, navego até o offset exato e sobrescrevo meu token com o valor do token do System. Instantaneamente, o kernel do Windows trata meu processo de exploit como NT AUTHORITY\SYSTEM.
Após desmapear a página para garantir estabilidade do sistema, simplesmente chamo CreateProcessA para gerar cmd.exe. Como meu processo atual está elevado, o novo prompt de comando herda esses privilégios de alto nível, completando com sucesso o ataque!
Nota: Um detalhe crítico que descobri durante minha fase inicial de depuração é como o driver lida com o ponteiro mapeado. Ao executar SystemBuffer->LowPart = (unsigned int)BaseAddress;, o driver converte o endereço virtual base de 64 bits para um valor de 32 bits antes de retorná-lo. Essa truncagem perde os bits altos do endereço, o que resultou em violações de acesso imediatas quando tentei dereferenciá-lo no meu exploit de 64 bits. Para contornar esse problema de forma limpa, simplesmente compilei minha PoC em modo de usuário como um aplicativo de 32 bits, garantindo que o ponteiro retornado permanecesse perfeitamente válido.
Nota: Durante meus testes iniciais, encontrei um caso extremo fascinante: minha PoC localizou com sucesso meu processo de exploit na memória, mas falhou ao encontrar o processo System (PID 4).
Para entender o motivo, precisei inspecionar a memória física diretamente. Anexei um depurador de kernel (WinDbg) e usei comandos para recuperar o endereço virtual e a base de diretório do processo System. Em seguida, usei !vtop para traduzir aquele endereço virtual em seu endereço físico exato na RAM.
Voltei para meu depurador em modo de usuário anexado à minha PoC. Configurei um breakpoint condicional no meu loop de varredura de memória, instruindo-o a pausar a execução no momento em que minha função MapPhysicalMemory() capturasse o chunk de 2MB contendo o endereço físico do processo System.
Quando o breakpoint foi atingido, comecei a inspecionar manualmente os bytes brutos da memória mapeada. Foi aqui que descobri um detalhe crucial sobre as alocações do pool do kernel do Windows.
Quando o Windows aloca memória para um processo, ele começa com um _POOL_HEADER (contendo nossa tag Proc), seguido por um _OBJECT_HEADER e, finalmente, pela própria estrutura EPROCESS. Para aplicativos padrão em modo de usuário, esses cabeçalhos contêm dados de rastreamento adicionais, o que significa que a estrutura EPROCESS real começa 0x80 bytes após a tag do pool.
No entanto, ao inspecionar a memória do processo System, um layout diferente foi revelado. O processo System carece de alguns desses cabeçalhos de rastreamento padrão. O offset da tag Proc até o início da estrutura EPROCESS era de apenas 0x40 bytes!
A correção foi direta. Atualizei minha PoC para lidar com ambos os tamanhos de cabeçalho de pool, percorrendo um array de offsets possíveis (0x40 e 0x80) sempre que encontra uma tag Proc.
A segurança cibernética é um jogo infinito de gato e rato entre atacantes e defensores. Enquanto os atacantes caçam constantemente por drivers vulneráveis, os produtos de segurança modernos e as equipes azuis têm várias maneiras robustas de detectar e bloquear exatamente esta operação.
A maneira mais eficaz de impedir um ataque BYOVD (Bring Your Own Vulnerable Driver) é evitar que o driver seja carregado em primeiro lugar.
Se o driver já estiver carregado, os produtos de segurança ainda podem detectar o exploit durante a fase de manipulação de tokens.
NT AUTHORITY\SYSTEM sem uma cadeia de autenticação legítima é um enorme sinal de alerta.cmd.exe), especialmente quando o processo pai não tem nenhuma razão para estar executando como SYSTEM.