Pesquisas recentes destacam uma tendência clara em ambientes Windows: ataques locais de elevação de privilégio (LPE) explorando drivers de kernel e named pipes. Essas superfícies de ataque permitem a escalada de privilégios de usuários comuns para SYSTEM quando há validações insuficientes.
Descoberta e escopo
Relatórios públicos descrevem duas linhas principais de investigação — drivers de modo kernel (WDM/mini-filters) e named pipes usados por serviços executados como SYSTEM — que têm sido exploradas por pesquisadores e, em alguns casos, por atores maliciosos. A análise foca em falhas de validação de entrada nas rotinas de IOCTL dos drivers e em ACLs (Access Control Lists) demasiado permissivas em named pipes.
Vetor e exploração
Em drivers que utilizam o modo METHOD_BUFFERED, o I/O Manager aloca buffers no kernel, e diversos vendors falham em validar corretamente dados fornecidos por usuário antes do processamento. Isso permite que um atacante crafteie requisições IOCTL contendo ponteiros e tamanhos que o kernel interpreta no seu espaço de endereço, potencialmente resultando em primitivas de leitura/escrita arbitrária.
Sequência de exploração observada
- Descoberta de dispositivo: identificação de nomes de dispositivo expostos acessíveis a partir do modo usuário.
- Análise de IOCTL: engenharia reversa de rotinas de dispatch com ferramentas estáticas (ex.: IDA Pro) para mapear parâmetros vulneráveis.
- Identificação da vulnerabilidade: localização de falta de validação que permite mapeamento de ponteiros para espaço kernel.
Named pipes: confiança implícita e ACLs fracas
Named pipes, amplamente usados para comunicação entre processos, são frequentemente implicitamente confiáveis por serviços de alto privilégio. Pesquisadores documentam casos em que pipes de propriedade do SYSTEM tinham ACLs que concediam acesso "Everyone" em leitura/escrita, ou onde o serviço não fazia checagens explícitas de autorização sobre operações sensíveis.
Essa combinação pode permitir que usuários não privilegiados invoquem operações administrativas no serviço — incluindo modificações no registro (HKLM) — ou configurem Image File Execution Options (IFEO) para executar código em contexto SYSTEM.
Evidências públicas e casos
Um estudo citado incluiu um caso concreto em que um produto antivírus comercial expôs um named pipe mal protegido que possibilitou manipulação não autorizada de chaves de registro. Pesquisadores recomendam inventariar pipes expostos e remover ACLs permissivas ou aplicar listas de controle mais restritivas.
Mitigações e recomendações
- Auditar drivers de terceiros quanto a permissões excessivas em IOCTLs e validar todas as entradas antes do processamento em kernel.
- Inventariar named pipes expostos e revisar ACLs — remover permissões amplas como "Everyone" e aplicar checagens explícitas de autorização no protocolo da pipe.
- Aplicar princípios de menor privilégio em serviços e revisar a superfície de dispositivos acessíveis por usuários comuns.
- Monitorar tentativas de acesso a dispositivos e pipes sensíveis com EDR/telemetria e regras de detecção focadas em chamadas IOCTL anômalas ou emcruzilhadas de autenticação.
Limites e lacunas
Os relatórios públicos descrevem vetores e casos de prova de conceito, mas não sistematizam métricas de impacto global (número de sistemas afetados) nem listam CVEs específicos com exploração pública generalizada. Em muitos casos, a exploração depende de drivers ou serviços de terceiros — portanto o alcance varia conforme o software instalado no endpoint.
Observações finais
Com a persistência do modelo Windows corporativo e a presença de drivers e serviços legados, as superfícies de kernel e named pipes continuarão a atrair atenção de atacantes. Times de segurança devem priorizar auditorias de drivers, revisão de ACLs e telemetria para detectar tentativas de escalada local.