PhantomRPC: uma nova técnica de escalonamento de privilégios no RPC do Windows

Introdução

A comunicação entre processos (IPC) é uma das tecnologias mais complexas do sistema operacional Windows. No centro desse ecossistema está o mecanismo de chamada de procedimento remoto (RPC), que pode funcionar como um canal de comunicação independente ou atuar como uma camada de transporte básica para tecnologias mais avançadas de comunicação entre processos. Devido à complexidade e à ampla adoção do RPC, esse mecanismo sempre foi fonte de diversos problemas de segurança. Ao longo dos anos, pesquisadores identificaram diversas vulnerabilidades em serviços que utilizam RPC, desde escalonamento de privilégios local até uma completa execução remota de código.

Nesta pesquisa, apresento os detalhes de uma nova vulnerabilidade na arquitetura RPC que possibilita aplicar uma técnica de escalonamento de privilégios local até então desconhecida, que aparentemente está presente em todas as versões do Windows. Essa técnica permite que processos com privilégios de impersonação elevem seus privilégios até o nível SYSTEM. Ela difere fundamentalmente dos métodos usados na conhecida família de exploits Potato. Embora a Microsoft tenha conhecimento da vulnerabilidade, não havia um patch disponível para sua correção até a publicação deste relatório.

Demonstro cinco vetores de exploração que permitem escalar privilégios a partir de diversos serviços locais ou de rede, até o nível SYSTEM ou até usuários com privilégios elevados. Algumas técnicas se baseiam em coação, outras exigem ações do usuário e outras envolvem serviços que operam em segundo plano. Uma vez que a causa do problema é uma falha na própria arquitetura, o número de vetores de ataque potenciais é praticamente ilimitado: qualquer novo processo ou serviço que dependa do RPC pode se tornar um novo caminho de escalonamento de privilégios. Por isso, também descrevo a metodologia usada para identificar possíveis pontos vulneráveis.

Por fim, apresento possíveis estratégias de detecção, bem como medidas de proteção que ajudam a reduzir os riscos e mitigar o impacto desse tipo de ataque.

Tecnologia MSRPC

A Chamada de Procedimento Remoto da Microsoft (MSRPC) é uma tecnologia usada no Windows para viabilizar a comunicação entre dois processos. Ela permite que um processo chame funções do código de outro processo, mesmo que eles existam em contextos de execução diferentes.

Para compreender melhor o mecanismo, veja o diagrama a seguir.

Suponha que exista um host A com dois processos em execução: A e B. O processo B precisa de uma função que existe dentro do processo A. Para esse tipo de comunicação, o Windows conta com a arquitetura de RPC baseada no modelo cliente-servidor. Nesse modelo, o processo A atua como servidor RPC, disponibilizando parte de suas funções por meio da interface A. Cada interface RPC é identificada de forma exclusiva por um identificador único universal (UUID) de 128 bits. É por meio desses identificadores que o sistema operacional diferencia as interfaces entre si.

A interface define quais funções o cliente RPC, papel desempenhado pelo processo B, pode chamar remotamente. Neste exemplo, a interface disponibiliza duas funções: Fun1 e Fun2.

Para que o cliente RPC troque dados com o servidor, ele precisa estabelecer uma conexão por meio de um endpoint, que funciona como ponto de acesso e garante a comunicação de transporte entre cliente e servidor. Como o RPC oferece suporte a diversos mecanismos de transporte, os tipos de endpoint podem variar de acordo com a camada de transporte usada.

Exemplos:

• para TCP, o endpoint é a porta TCP;
• para SMB, a comunicação ocorre por meio de um pipe nomeado;
• para ALPC, o endpoint é a porta ALPC.

Cada mecanismo de transporte está associado a uma sequência de protocolos RPC correspondente.

Exemplos:

• ncacn_ip_tcp é usado para RPC sobre TCP;
• ncacn_np é usado para RPC sobre pipes nomeados;
• ncalrpc é usado para RPC sobre ALPC.

Nesta pesquisa, meu foco é o ALPC (Advanced Local Procedure Call) como mecanismo de transporte do RPC. O ALPC é um mecanismo de comunicação entre processos do Windows que existia antes do MSRPC. Em sistemas modernos, o ALPC pode ser usado como uma camada de transporte eficiente para o RPC na comunicação entre processos em uma mesma máquina.

Para simplificar, o canal de comunicação baseado em uma porta ALPC pode ser considerado um arquivo no qual os processos enviam (gravam) mensagens e do qual as recebem (leem).

Para chamar uma função remota (por exemplo, Fun1), o cliente elabora uma solicitação RPC. Ela deve conter informações essenciais, como o UUID da interface, a sequência de protocolo, o endpoint e o identificador da função chamada. No RPC, as funções não são chamadas pelo nome, mas por um identificador numérico: o número da operação (OPNUM). A solicitação também pode incluir outras estruturas, como dados relacionados à segurança, de acordo com os requisitos da chamada.

O mecanismo de impersonação no Windows

No Windows, o mecanismo de impersonação permite que um serviço execute operações temporariamente no contexto de segurança de outro usuário. Por exemplo, um serviço pode precisar acessar um arquivo pertencente a um usuário durante a execução de uma determinada operação. Ao atuar em nome do usuário que fez a chamada, o serviço recebe do sistema os privilégios de acesso necessários para esse arquivo, mesmo que não os possua. Para saber mais sobre impersonação, consulte o livro “Windows Security Internals” (“Componentes internos de segurança do Windows”, sem tradução para o português), de James Forshaw.

Esta pesquisa aborda apenas a impersonação no RPC. Neste contexto, os participantes do processo não são um serviço e um usuário, mas um cliente e um servidor. O servidor RPC pode atuar temporariamente em nome do cliente que iniciou a solicitação.

Para realizar essa operação, o servidor RPC pode chamar a função de API RpcImpersonateClient, que faz com que a thread do servidor seja executada no contexto de segurança do cliente.

Em alguns casos, é necessário limitar a capacidade do servidor de agir em nome do cliente. Para isso, o Windows introduziu o conceito de nível de impersonação, que define o escopo de permissões concedidas ao servidor para agir em nome do cliente.

Tais parâmetros fazem parte das configurações SQOS (Security Quality of Service) e são definidos por meio da estrutura SECURITY_QUALITY_OF_SERVICE.

Podemos observar que essa estrutura possui o campo de nível de impersonação (SECURITY_IMPERSONATION_LEVEL), que determina a extensão das permissões do servidor quando ele atua em nome do cliente. Os níveis de impersonação vão desde “anonymous” (anônimo), no qual o servidor não pode agir em nome do cliente, até “impersonation” (impersonação) e “delegation” (delegação), nos quais o servidor pode atuar integralmente em nome do cliente.

No entanto, nem todo processo de servidor pode agir em nome do cliente. Se qualquer aplicativo pudesse usar a impersonação livremente, isso criaria sérios riscos de segurança. Por essa razão, o Windows exige o privilégio especial SeImpersonatePrivilege. Somente processos que possuem esse privilégio podem agir em nome do cliente.

Por padrão, o SeImpersonatePrivilege é concedido a determinadas contas de serviço, como Local Service e Network Service.

Interação entre os serviços Group Policy e TermService

O serviço Group Policy Client (gpsvc) é o principal serviço do Windows responsável pela aplicação e imposição das configurações de política de grupo no sistema. Esse serviço é executado com privilégios de SYSTEM no âmbito do processo svchost.exe.

Para a atualização da política de grupo, o Windows emprega o utilitário gpupdate.exe. Esse utilitário pode ser executado com o parâmetro /force para forçar a atualização de todas as configurações de política de grupo. Durante a sua execução, esse executável se comunica com o serviço Group Policy, responsável por coordenar todo o processo de atualização.

Em um dos estágios da atualização, o serviço Group Policy estabelece comunicação com o serviço TermService via RPC.

O TermService fornece a funcionalidade de área de trabalho remota. Por padrão, esse serviço não se encontra em execução; contudo, o administrador pode iniciá-lo manualmente, ativando o acesso via RDP. Uma vez habilitado, ele implanta um servidor RPC com um conjunto de interfaces e endpoints. O TermService é executado como NT AUTHORITY\Network Service.

Ao executar o comando gpupdate /force, o serviço Group Policy inicia uma chamada RPC ao TermService com os seguintes parâmetros:

• UUID: bde95fdf-eee0-45de-9e12-e5a61cd0d4fe
• Endpoint: ncalrpc:[TermSrvApi]
• Função: void Proc8(int)

Como o TermService está desativado por padrão, a chamada RPC falha e ocorre uma exceção dentro da biblioteca de runtime do RPC (rpcrt4.dll), retornando o seguinte erro:

• 0x800706BA (RPC_S_SERVER_UNAVAILABLE, 1722)

O erro indica que o cliente RPC não conseguiu estabelecer uma conexão com o servidor de destino.

Uma análise mais aprofundada da cadeia de chamadas que resultam nesse erro evidencia que a causa-raiz reside na função NtAlpcConnectPort, usada pelo RPC para estabelecer a conexão ALPC entre os processos.

A função NtAlpcConnectPort é responsável por estabelecer a conexão com uma porta ALPC especificada, retornando um identificador usado pelo cliente para a comunicação subsequente. Essa função recebe múltiplos parâmetros.

Os dois primeiros são:

• um ponteiro para o identificador de porta retornado;
• o nome da porta ALPC como uma string ASCII.

Outro argumento importante é PortAttributes, uma estrutura do tipo ALPC_PORT_ATTRIBUTES. Ela contém a estrutura SECURITY_QUALITY_OF_SERVICE que, como já mencionado, define o nível de impersonação usado na conexão.

O último parâmetro de interesse é RequiredServerSid, que define a identidade esperada do processo servidor de destino. Essa identidade é determinada pelo identificador de segurança (SID).

Ao analisar essa chamada, constata-se que o serviço Group Policy tenta estabelecer conexão com o servidor RPC usando o nível de impersonação “impersonation” e espera que o servidor remoto seja executado como Network Service. Isso não é incomum, visto que o TermService normalmente funciona com a conta Network Service.

Reunindo todas as informações conhecidas até aqui, é possível montar o esquema de interação entre o TermService e o gpsvc.

Até este ponto, o sistema funciona como previsto. O cliente RPC tenta se conectar a um servidor RPC indisponível, o que gera uma exceção tratada pelo runtime do RPC.

Porém surge uma pergunta: quais seriam os desdobramentos caso um invasor comprometesse um serviço em execução como Network Service e tentasse simular o mesmo servidor RPC usado pelo TermService?

Será que o invasor conseguiria implantar um servidor RPC falso com o mesmo endpoint?

Se isso fosse possível, o runtime do RPC autorizaria a conexão do cliente a esse servidor não autorizado?

E quais ações o invasor poderia realizar se a conexão fosse estabelecida com sucesso?

Forçando a interação com o serviço Group Policy

Para compreender melhor as implicações desse comportamento do sistema, vejamos um possível cenário de ataque.

Suponha que um invasor tenha comprometido um serviço em execução no sistema com a conta Network Service, como, por exemplo, um servidor IIS. Com esse nível de acesso, o invasor pode implantar um servidor RPC malicioso.

Esse servidor precisa imitar a interface RPC do serviço de área de trabalho remota (TermService). Especificamente, ele deve usar o mesmo UUID de interface RPC e o mesmo nome de endpoint: TermSrvApi. Depois de implantado, o servidor malicioso passa a escutar as solicitações RPC que, em condições normais, seriam direcionadas ao serviço RDP legítimo.

Em seguida, o invasor inicia uma atualização de política usando o comando gpupdate.exe /force, forçando o serviço Group Policy a realizar a condição necessária. Dessa maneira, o serviço gpsvc, em execução como SYSTEM, faz a chamada RPC descrita anteriormente. Vale lembrar que essa chamada RPC é feita com um nível de impersonação alto: “impersonation”.

Quando o servidor RPC falso do invasor recebe a solicitação, ele chama a função de API RpcImpersonateClient, que permite que a thread do servidor use o contexto de segurança do cliente que fez a chamada, neste caso, SYSTEM.

No fim, o invasor eleva seus privilégios de Network Service para SYSTEM. Nosso exploit de prova de conceito demonstra esse escalonamento de privilégios mediante a inicialização de um prompt de comando com privilégios de SYSTEM.

Quando esse cenário de ataque foi considerado inicialmente, ele tinha caráter puramente teórico. Mas o experimento com o servidor RPC malicioso confirmou que o Windows permite implantar e executar esse tipo de servidor, e que o runtime do RPC habilita a conexão do cliente a um endpoint ilegítimo. Essa técnica permite escalar privilégios do nível Network Service para SYSTEM. Ainda assim, para que o ataque seja bem-sucedido, é necessário que ao menos uma política de grupo esteja aplicada no sistema.

Esquema da arquitetura RPC

Uma análise mais aprofundada mostrou que diversos serviços do Windows tentam acessar o TermService via RPC, e essas chamadas geralmente partem da biblioteca winsta.dll, que atua como cliente RPC.

Os processos do Windows chamam funções de API da winsta.dll cuja implementação interna depende da comunicação RPC com o TermService. Esse padrão é comum no Windows: as chamadas às funções exportadas de muitas DLLs do sistema são, na prática, redirecionadas via RPC para outros componentes do sistema.

Aparentemente, o runtime do RPC (rpcrt4.dll) não realiza nenhuma verificação da legitimidade dos servidores RPC. Mais do que isso, o Windows permite que outro processo implante um servidor RPC com o mesmo endpoint de um serviço legítimo.

Essa arquitetura expõe uma superfície de ataque considerável, já que o RPC é amplamente usado por muitas DLLs do sistema. Com isso, aplicações que executam chamadas de API aparentemente inofensivas podem iniciar comunicações RPC privilegiadas que, em determinadas condições, abrem espaço para escalonamento de privilégios local sem o conhecimento do usuário.

Identificação de chamadas RPC a servidores indisponíveis

Como a causa do problema parece estar em falhas da própria arquitetura, é necessária uma abordagem sistemática para identificar clientes RPC que tentam acessar servidores indisponíveis. Antes de tudo, é preciso uma plataforma capaz de monitorar a atividade RPC e extrair informações relevantes de cada solicitação RPC.

Especificamente, é preciso registrar os seguintes metadados essenciais do RPC:

• UUID da interface, endpoint e identificador OPNUM;
• nível de impersonação e código de status do RPC;

Essas informações são essenciais para reconstruir a comunicação RPC, simular o servidor RPC esperado e entender exatamente como a chamada é iniciada.

Uma plataforma adequada para isso é o Rastreamento de Eventos do Windows (ETW). O ETW é um sistema de registro embutido no Windows que captura eventos em tempo real, tanto no modo kernel quanto no modo usuário.

Para coletar dados do ETW, o Windows conta com a ferramenta logman, que permite criar sessões de rastreamento, selecionar provedores de eventos e configurar o nível de detalhamento do monitoramento. Os resultados são salvos em um arquivo no formato .etl, que pode ser analisado posteriormente com o Visualizador de Eventos ou outras ferramentas de análise de ETW.

O ETW oferece visibilidade detalhada da atividade RPC sem exigir modificação dos aplicativos. Com ele, é possível obter informações detalhadas sobre o RPC, incluindo:

• associações RPC (bindings);
• endpoints;
• UUIDs de interface;
• detalhes de autenticação;
• sequência e tempo das chamadas;
• códigos de status do RPC.

No entanto, meu interesse não está em todos os eventos RPC, mas apenas nas chamadas RPC malsucedidas, em especial as que retornam a exceção RPC_S_SERVER_UNAVAILABLE.

Para que um evento registrado seja considerado relevante para a pesquisa, a exceção precisa atender a duas condições:

• o erro deve vir de um processo altamente privilegiado, já que a capacidade de agir em nome desse processo pode permitir que o invasor escale privilégios para um contexto de segurança mais amplo;
• a chamada RPC deve usar um nível de impersonação alto, que permita ao servidor agir plenamente em nome do cliente após o estabelecimento da conexão.

Essa verificação não pode se basear apenas na saída bruta do ETW: ela contém milhares de eventos, e filtrá-los manualmente com ferramentas padrão não é eficiente. É necessário automatizar esse processo. O fluxo de trabalho apresentado a seguir permite selecionar e extrair de forma eficiente apenas os eventos relevantes para a análise.

Depois de gerados os logs no formato .etl, eles podem ser convertidos em JSON com a ferramenta etw2json ou similar. O formato JSON é muito mais fácil de processar via código. Para isso, pode-se usar um script em Python que filtra e extrai as informações necessárias.

O processo de filtragem começa com a busca do evento de ID 1, que corresponde à conclusão de uma operação RPC. Esse evento indica que o cliente RPC concluiu a chamada e que o resultado já está disponível. Dele é possível extrair as seguintes informações úteis:

• código de status;
• nome do processo do cliente;
• identificador do processo do cliente (PID);
• endpoint.

Após extrair o código de status, aplica-se um filtro pelo valor RPC_S_SERVER_UNAVAILABLE, que indica chamadas RPC nas quais o servidor de destino se encontrava indisponível. São justamente esses eventos que interessam para a análise posterior.

No entanto, o evento de ID 1 não contém todos os metadados RPC necessários. Para a obtenção das informações que faltam, é preciso correlacioná-lo com o evento de ID 5, que corresponde ao início da operação RPC. Esse evento é gerado no momento em que o cliente inicia a chamada RPC.
Ao correlacionar os metadados dos eventos de ID 1 e ID 5, é possível recuperar os detalhes que faltam, incluindo:

• UUID da interface;
• identificador OPNUM;
• nível de impersonação.

Depois da correlação e da filtragem dos eventos, um registro JSON praticamente pronto é gerado para análise. Nessa fase, os dados podem ser enriquecidos com contexto adicional, útil para a engenharia reversa ou a análise do funcionamento do servidor RPC. Especificamente, é possível determinar:

• o nome da DLL na qual a interface RPC está implementada;
• o local dessa DLL;
• o número de procedimentos disponibilizados pela interface.

Para obter essas informações, o UUID é comparado com um banco de dados externo de interfaces RPC. Utilizei um banco de dados que contém uma lista abrangente de interfaces RPC e suas respectivas DLLs.

Ao final do processo, obtenho um conjunto completo de dados JSON pronto para análises posteriores.

É importante destacar que as chamadas RPC de interesse só ocorrem durante determinadas ações do sistema. Além disso, o tipo de exceção pode variar de um sistema para outro, a depender de quais serviços estão ativados ou desativados. Por isso, é necessário um método confiável para reproduzir essas exceções RPC.

Nesta pesquisa, usei diversas abordagens para desencadear esse tipo de evento.

1. Monitoramento da atividade RPC durante a inicialização do sistema
   Monitorei a atividade RPC durante o processo de inicialização do sistema operacional. Nesse momento, diversos serviços são inicializados e executam várias chamadas RPC, o que aumenta a probabilidade de identificar tentativas de acesso a servidores indisponíveis.
2. Execução de operações administrativas
   Desenvolvi scripts do PowerShell que executam tarefas administrativas comuns, como atualização de política de grupo, alteração de configurações de rede ou criação de novos usuários. Este tipo de operação costuma iniciar uma comunicação RPC e pode gerar exceções.
3. Desativação intencional de serviços
   Como o serviço de área de trabalho remota está desativado por padrão, isso me levou a considerar a desativação de outros serviços sucessivamente e repetir os passos anteriores. Dessa forma, é possível identificar clientes RPC que tentam se conectar a serviços já indisponíveis.

Caminhos adicionais de escalonamento de privilégios

Com base no processo de registro e monitoramento descrito anteriormente, foi possível identificar quatro cenários adicionais que podem levar ao escalonamento de privilégios. As seções a seguir examinam cada um desses casos e explicam como um invasor pode agir.

Interação com o usuário: do Edge ao RDP

O navegador Microsoft Edge (msedge.exe) vem instalado por padrão nos sistemas Windows. Ao ser iniciado, o Edge faz uma chamada RPC ao serviço TermService com um nível de impersonação alto.

Como mencionado anteriormente, o serviço de área de trabalho remota vem desativado por padrão. Dessa maneira, o servidor RPC esperado fica indisponível, o que cria as condições propícias para o cenário de ataque mostrado no diagrama a seguir.

O ataque parte da mesma premissa de antes: o invasor já comprometeu um processo em execução. como o Network Service. Neste contexto, o invasor implanta um servidor RPC falso que imita a interface RPC legítima do TermService.

Diferentemente do cenário anterior, que dependia de forçar o serviço Group Policy a realizar determinada ação, aqui isso não é necessário. O invasor só precisa aguardar até que um usuário com privilégios elevados, como um administrador, inicie o Microsoft Edge.

Ao ser iniciado, o cliente RPC do Edge tenta se conectar à interface RPC esperada do TermService. Como o servidor legítimo está inativo, a solicitação é recebida pelo servidor RPC falso do invasor. Como a chamada RPC é feita com um nível de impersonação alto, o servidor malicioso pode chamar a função RpcImpersonateClient e realizar operações em nome do processo do cliente.

Dessa maneira, o invasor passa a agir em nome do cliente com privilégios de administrador, elevando os privilégios de Network Service para o nível de administrator.

Serviços em segundo plano: do WDI ao RDP

Alguns serviços em segundo plano do Windows realizam periodicamente chamadas RPC ao serviço RDP sem intervenção do usuário. Um deles é o WdiSystemHost. O serviço Diagnostic System Host (WDI) é um componente integrado do Windows responsável pelo diagnóstico e pela solução de problemas do sistema. Ele é executado como SYSTEM.

Durante sua execução, o WDI inicia periodicamente chamadas RPC em segundo plano para o serviço de área de trabalho remota (TermService), empregando um nível de impersonação alto. Estas comunicações ocorrem de forma automática em um intervalo de 5 a 15 minutos, sem que seja necessária qualquer intervenção do usuário.

O comportamento desse serviço pode ser explorado de forma maliciosa, de modo semelhante aos cenários de ataque anteriores, como ilustra o diagrama a seguir.

Neste cenário, porém, não é necessária nenhuma ação do usuário nem o uso de técnicas de coação. Depois de implantar o servidor RPC malicioso que imita a interface RPC esperada do TermService, o invasor só precisa aguardar a próxima chamada RPC periódica do WDI. Como a solicitação é feita com um nível de impersonação alto, o servidor malicioso pode chamar a função RpcImpersonateClient para agir em nome do processo que fez a chamada, o que permite escalar privilégios até o nível SYSTEM.

Abuso da conta Local Service: do ipconfig ao DHCP

Outro cenário envolve o serviço DHCP Client, responsável por gerenciar as operações de cliente DHCP nos sistemas Windows. Esse serviço é executado como Local Service e vem ativado por padrão.

Ele disponibiliza um servidor RPC com várias interfaces e endpoints. Essas interfaces costumam ser chamadas por DLLs do sistema, muitas vezes com um nível de impersonação alto.

Neste cenário, em vez de comprometer um processo com privilégios de Network Service, considera-se que o invasor obteve controle sobre um processo em execução como o Local Service. Também se considera que o serviço DHCP Client está desativado, o que torna o servidor RPC legítimo indisponível.

Conforme mostra o diagrama a seguir, o invasor pode tirar proveito dessa situação para escalar seus privilégios.

Depois de obter controle sobre um processo com privilégios de Local Service, o invasor implanta um servidor RPC falso que imita a interface RPC legítima do DHCP Client. Com o servidor malicioso em execução, o invasor aguarda até o momento em que um usuário com privilégios elevados, como um administrador, execute o comando ipconfig.exe.

Ao ser executado, o comando dispara internamente uma solicitação RPC ao serviço DHCP Client. Uma vez que o servidor RPC legítimo está inativo, a solicitação é recebida pelo servidor RPC falso do invasor. Como a chamada RPC é feita com um nível de impersonação alto, o servidor malicioso pode chamar a função RpcImpersonateClient e realizar operações em nome do processo do cliente. Dessa maneira, o invasor consegue escalar privilégios do nível Local Service para Administrator.

Abuso do serviço de horário

O serviço Windows Time (W32Time) é responsável por sincronizar data e hora entre sistemas no ambiente Windows. Esse serviço vem ativado por padrão e é executado como Local Service.

Ele disponibiliza um servidor RPC com dois endpoints:

• \PIPE\W32TIME_ALT
• \RPC Control\W32TIME_ALT

O executável C:\Windows\System32\w32tm.exe se comunica com o serviço Windows Time via RPC. Mas, antes de se conectar aos endpoints RPC corretos desse serviço, ele tenta acessar o pipe nomeado inexistente \PIPE\W32TIME. No serviço legítimo W32Time, esse pipe não está disponível. No entanto, se esse endpoint existisse, o executável w32tm.exe tentaria se conectar a ele.

Um invasor pode explorar essa situação implantando um servidor RPC falso que imita a interface RPC legítima do serviço Windows Time. Em vez dos endpoints legítimos, esse servidor disponibiliza acesso ao endpoint fictício \PIPE\W32TIME, como ilustra o diagrama a seguir.

Assim como nos cenários anteriores, considera-se que o invasor já obteve controle sobre um processo em execução como Local Service. Em seguida, ele precisa implantar um servidor RPC falso que implemente a mesma interface RPC do serviço Windows Time, mas com o endpoint alternativo que o w32tm.exe tenta acessar.

Com o servidor malicioso em execução, o invasor só precisa aguardar que um usuário com privilégios elevados, como um administrador, execute o comando w32tm.exe. Ao ser iniciado, o executável tenta se conectar ao endpoint \PIPE\W32TIME. Como este endpoint está disponível no servidor falso, a solicitação RPC é redirecionada para ele.

Como a chamada RPC é feita com um nível de impersonação alto, o servidor malicioso consegue realizar operações em nome do cliente que fez a chamada. Dessa maneira, o invasor pode escalar privilégios do nível Local Service para Administrator.

É importante destacar que este cenário funciona mesmo que o serviço legítimo Windows Time não esteja desativado. Como o executável tenta se conectar a um endpoint inexistente, basta que o invasor crie esse endpoint em seu servidor RPC malicioso.

Divulgação da vulnerabilidade

Após a descoberta da vulnerabilidade, a equipe da Kaspersky Security Services elaborou um relatório técnico de dez páginas descrevendo o problema e os cenários de exploração apresentados anteriormente. O documento foi encaminhado ao Centro de Resposta da Microsoft (MSRC) para notificar a empresa sobre o problema e solicitar a correção correspondente.

Após 20 dias, a Microsoft respondeu que seus especialistas não consideravam a vulnerabilidade crítica. O problema recebeu uma classificação de gravidade média, razão pela qual não haveria planos de correção imediata e nenhum CVE seria atribuído. Assim, o caso foi encerrado sem acompanhamento adicional.

Para justificar essa avaliação, a Microsoft indicou que a exploração exige que o processo de origem já possua o privilégio SeImpersonatePrivilege. Uma vez que, sem esse privilégio, muitas vezes não é possível realizar um ataque bem-sucedido, a empresa considerou que o problema não exigia correção urgente.
A equipe da Kaspersky Security Services respeita a avaliação da Microsoft. Esta pesquisa está sendo publicada após o término do período de embargo. Em conformidade com os princípios de divulgação coordenada de vulnerabilidades, o relatório exclui quaisquer detalhes que possam facilitar ou acelerar a exploração em larga escala.

A cronologia da divulgação é apresentada a seguir:

• 19 de setembro de 2025: envio do relatório da vulnerabilidade ao Centro de Resposta da Microsoft (caso nº 101749);
• 10 de outubro de 2025: recebimento de resposta do MSRC, classificando a vulnerabilidade como sendo de gravidade média, sem direito a recompensa, sem atribuição de CVE e com o encerramento do caso sem desdobramentos adicionais;
• 24 de abril de 2026: publicação da análise técnica.

Medidas de detecção e proteção

Conforme mencionado anteriormente, a presente vulnerabilidade decorre de deficiências de arquitetura, e sua remediação definitiva depende da disponibilização de uma correção por parte da Microsoft que trate a causa-raiz do problema.

Ainda assim, as organizações podem adotar medidas para detectar e reduzir os riscos associados a uma possível exploração. O monitoramento baseado em ETW, seguindo o processo descrito nesta pesquisa, permite que as equipes de segurança identifiquem exceções RPC em seus ambientes, em especial os casos em que clientes RPC tentam estabelecer uma conexão com servidores indisponíveis.

Também publiquei as ferramentas empregadas nesta pesquisa, para que as organizações possam auditar seus ambientes em busca desse tipo de comportamento. A totalidade das ferramentas encontra-se disponível no repositório da pesquisa.

Ao monitorar esses eventos, os administradores conseguem identificar situações em que servidores RPC legítimos deveriam estar em execução, mas não estão. Em alguns casos, a superfície de ataque pode ser reduzida ativando os serviços correspondentes e garantindo a disponibilidade do servidor RPC legítimo. Essa medida reduz o risco de implantação por parte de invasores de servidores RPC falsos que imitem endpoints legítimos.

Recomendamos ainda limitar o uso do privilégio SeImpersonatePrivilege em processos nos quais ele não é necessário. Embora determinados processos do sistema precisem desse privilégio para operar corretamente, em alguns casos ele é concedido a processos de usuário, o que é considerado uma prática insegura.

Conclusão

Todos os exploits descritos nesta pesquisa foram testados no Windows Server 2022 e no Windows Server 2025, com as atualizações mais recentes disponíveis até a data de submissão do relatório. Os exploits de prova de conceito estão disponíveis no repositório da pesquisa. Ainda assim, é altamente provável que essa vulnerabilidade também afete outras versões do sistema operacional Windows.

Como a vulnerabilidade decorre de uma deficiência arquitetural, podem existir cenários de ataque adicionais além dos demonstrados nesta pesquisa. Os métodos específicos de exploração podem variar entre diferentes sistemas, a depender, por exemplo, dos componentes instalados, das DLLs empregadas nas comunicações RPC e da disponibilidade dos servidores RPC correspondentes.