Microsoft Exchange Server Elevation of Privilege Vulnerability

CVE-2022-41040 é uma falha de Server-Side Request Forgery (SSRF) no Microsoft Exchange Server, parte da dupla conhecida como 'ProxyNotShell'. Isolada, ela permite a um atacante autenticado forjar requisições internas no servidor; o risco real aparece quando ela é encadeada com CVE-2022-41082, que transforma essa SSRF em execução remota de código via PowerShell. Foi explorada in-the-wild como zero-day antes de qualquer patch existir, o que a colocou no catálogo KEV da CISA com prazo de correção de 21/10/2022.

A falha está classificada como CWE-918 (Server-Side Request Forgery). O serviço Autodiscover do Exchange — que desde a versão 2016 roda integrado ao IIS no próprio Mailbox server, e não mais como componente separado do Client Access — expõe endpoints que podem ser manipulados via URL malformada para fazer o servidor emitir requisições internas arbitrárias, de forma similar ao que já havia sido explorado na cadeia ProxyShell (2021). O atacante controla a URL requisitada ao endpoint (padrão observado envolvendo /autodiscover.json), forçando o backend a atuar como proxy para chamadas internas que deveriam ser inacessíveis externamente.

Por si só, CVE-2022-41040 concede elevação de privilégio/acesso interno, não execução de código. O impacto crítico surge da cadeia: a SSRF é usada para alcançar o Remote PowerShell backend do Exchange, e então CVE-2022-41082 (deserialização/validação insuficiente no contexto do PowerShell remoto) permite executar código arbitrário no contexto da conta do serviço Exchange. A pesquisadora vietnamita GTSC foi quem primeiro documentou o abuso em agosto de 2022, publicando a análise que levou o MSRC a reconhecer a falha.

O vetor CVSS informado (AV:N/AC:L/PR:L/UI:N) confirma que a exploração é remota, sem interação do usuário, mas exige privilégio baixo (PR:L) — ou seja, autenticação válida no ambiente Exchange, ainda que com conta de baixo privilégio.

Pré-requisito central, frequentemente omitido em manchetes: o atacante precisa de credenciais autenticadas válidas contra o Exchange (mailbox de usuário comum já basta) para disparar a SSRF. Isso reduz o universo de exploração a atacantes com algum ponto de apoio prévio — credenciais vazadas, phishing bem-sucedido, ou acesso via outra falha — mas não exige acesso administrativo nem configuração não padrão do servidor; instalações padrão de Exchange on-premises com Autodiscover exposto à internet já satisfazem o cenário.

Na prática documentada por GTSC e pela Microsoft, o ataque observado usa a SSRF (CVE-2022-41040) para acessar o backend de PowerShell remoto do servidor e então explora CVE-2022-41082 para executar comandos, tipicamente resultando em web shells depositados no servidor Exchange — dando ao atacante execução de código no contexto da conta de serviço, acesso a caixas de correio e possibilidade de movimento lateral dentro do Active Directory, já que o Exchange normalmente possui privilégios elevados no domínio.

A exploração ativa começou antes de qualquer correção oficial (zero-day), com PoCs públicas e módulo Metasploit disponíveis logo depois da divulgação, o que elevou rapidamente o volume de tentativas em massa contra servidores Exchange expostos.

A correção definitiva veio no Patch Tuesday de novembro de 2022 (8/11/2022), com atualizações de segurança cobrindo Exchange Server 2013 CU23, 2016 CU22/CU23 e 2019 CU11/CU12 — as mesmas linhas de Cumulative Update listadas como afetadas. Não há KB específico confirmado nas fontes consultadas para citar aqui; administradores devem aplicar a atualização de segurança de novembro de 2022 correspondente à sua CU exata via Windows Update/catálogo Microsoft, e confirmar a CU vigente antes de aplicar, pois o Exchange exige estar em CU suportada para receber o patch.

Entre a divulgação (29/09/2022) e o patch (08/11/2022), a única mitigação real era o bloqueio via regra de URL Rewrite no IIS recomendada pela Microsoft, com regex bloqueando padrões como .*autodiscover\.json.*Powershell.* (excluindo o caractere @) nas requisições ao Autodiscover, e ajuste do Condition Input de {URL} para {UrlDecode:{REQUEST_URI}} para capturar variantes com encoding. Essa regra foi revisada mais de uma vez pela própria Microsoft porque a versão inicial tinha bypasses. WAFs de terceiros podem implementar filtro equivalente, e restringir conexões de saída do servidor Mailbox a uma allowlist no proxy reduz a superfície de SSRF, mas isso é mitigação, não correção — servidores permanecem vulneráveis até o patch de novembro ser aplicado.

O que não funciona: aplicar apenas as atualizações anteriores a novembro de 2022 (inclusive as de 11 de outubro) não corrige a falha — isso foi explicitamente confirmado pelo CERT/CC. Manter Exchange Online não exige ação do cliente, pois a Microsoft aplicou mitigação na infraestrutura gerenciada; isso não se aplica a instalações on-premises.

Nos logs do IIS do Exchange, procurar requisições anômalas envolvendo /autodiscover.json com parâmetros incomuns ou tentativas de encoding não padrão na URL, especialmente combinadas com chamadas subsequentes a endpoints de PowerShell remoto (/powershell). A presença de web shells recém-criados em diretórios do Exchange (padrão observado nos incidentes documentados pela GTSC) é indicador forte de exploração bem-sucedida da cadeia completa, não apenas da SSRF isolada.

Como a exploração exige autenticação válida, atividade anômala originada de contas de usuário comuns acessando Autodiscover/PowerShell fora do padrão de uso normal (horário, volume, IP de origem) é outro sinal a correlacionar. Não há assinatura de rede única e confiável, porque os padrões de URL usados evoluíram para escapar dos primeiros filtros de bloqueio publicados pela Microsoft — logs históricos anteriores à atualização das regras podem não capturar variantes mais recentes do ataque.