Um novo ataque no Windows mostra como um programa confiável pode se tornar um caminho para funções sensíveis do sistema. O método, chamado Bring Your Own Trusted Caller (BYOTC), transforma um aplicativo legítimo em modo de usuário na ferramenta que solicita a um driver privilegiado realizar ações perigosas.
Diferença entre BYOVD e BYOTC
O BYOTC difere do BYOVD (Bring Your Own Vulnerable Driver) de maneira fundamental. Enquanto o BYOVD depende de uma falha em um driver assinado, o BYOTC explora o relacionamento de confiança entre um driver e seu chamador aprovado em modo de usuário. Em efeito, o driver torna-se um deputado confuso, executando uma ação poderosa para um atacante escondido dentro de um processo confiável.
Um caso envolveu um driver de segurança, que aceita um pedido de registro apenas de um aplicativo cuja imagem é assinada por seu fornecedor. O pesquisador lançou o cliente, injetou uma DLL no processo e, em seguida, usou o aplicativo agora confiável para pedir ao driver que terminasse o serviço do Microsoft Defender.
O problema não é uma verificação de assinatura quebrada isoladamente. Uma assinatura identifica o arquivo usado para criar um processo, mas não prova continuamente que código, memória, módulos carregados e fluxo de controle permaneceram inalterados.
Injeção em clientes confiáveis
Um atacante com direitos de administrador pode explorar um cliente confiável após o lançamento e herdar acesso a funções que outros não podem alcançar. Revisões defensivas são, portanto, mais exigentes. Equipes não devem apenas perguntar se um driver executa executáveis não confiáveis; elas devem testar se um cliente confiável pode ser injetado, modificado, depurado ou lançado através de um processo pai hostil.
Essas verificações importam especialmente para drivers que podem parar proteções de endpoint, uma capacidade frequentemente vista em campanhas de abuso de drivers assinados. A pesquisa recomenda ancorar a confiança no Protected Process Light (PPL), quando possível, e tratar a perda de integridade como permanente em vez de restaurar a confiança quando uma condição temporária desaparece.
Estudos de caso e mitigação
Um segundo caso visou o System Informer, cujo driver aplicava múltiplos níveis de integridade e verificava arquivos executáveis, assinaturas, estado de depuração e imagens carregadas. Seus pesquisadores encontraram que a criação de processos do Windows ainda deixava uma abertura estreita. O criador legítimo precisa de alças fortes enquanto prepara seu filho, e o driver permitia que esse criador direitos adicionais de operação e gravação de memória.
Um programa hostil elevado poderia criar uma instância verificada, alterá-la através dessa alça e usá-la para construir um filho que herdou confiança máxima. O System Informer abordou a lacuna exigindo um criador MAXIMUM ou um processo protegido Windows TCB/System na raiz de uma nova cadeia de confiança.
Desenvolvedores devem bloquear drivers conhecidos abusáveis, examinar cada operação de driver privilegiado e validar a integridade de tempo de execução e histórico de criação do chamador. Isso é uma preocupação de design mais ampla do Windows, não simplesmente outra vulnerabilidade de driver de kernel para corrigir.
Impacto na segurança de endpoint
Esse vetor de ataque representa uma mudança significativa na forma como EDRs e AVs devem validar a legitimidade de operações de kernel. A confiança baseada apenas em assinatura de arquivo é insuficiente. A verificação contínua do estado do processo e a restrição de capacidades de criação de processos são essenciais para mitigar riscos de elevação de privilégio e desativação de segurança.