Microsoft Exchange Server Remote Code Execution Vulnerability
Corrija agora. Ela está sob exploração confirmada pelo CISA, tem exploit funcional público e 1 grupo(s) de ameaça a utilizam.
Grupos conhecidos por explorar esta vulnerabilidade (atribuição MITRE ATT&CK).
Apply updates per vendor instructions.
Resumo
CVE-2022-41082 é o componente de execução remota de código da dupla conhecida como ProxyNotShell, que afeta Microsoft Exchange Server on-premises (2013, 2016 e 2019). Isoladamente exige autenticação, mas encadeada com o SSRF do CVE-2022-41040 permite que um atacante execute PowerShell arbitrário no servidor sem credenciais válidas prévias — foi explorada em ataques reais antes de existir patch, o que a colocou no catálogo KEV da CISA com exploração confirmada.
Detalhamento técnico
A vulnerabilidade está classificada como CWE-502 (deserialização insegura de dados não confiáveis). O vetor de exploração passa pelo serviço Autodiscover do Exchange, que desde a versão 2016 roda integrado ao IIS no papel de Mailbox server junto com outros serviços privilegiados, ao invés de ficar isolado em um Client Access server. Um atacante autenticado consegue acionar deserialização de objetos controlados que resulta em execução de código no contexto da conta do serviço do Exchange.
O mecanismo completo documentado pela GTSC (empresa vietnamita que descobriu a exploração ativa em agosto de 2022) e confirmado pela Microsoft combina duas falhas distintas: CVE-2022-41040 é um SSRF que permite a um atacante autenticado forjar requisições internas contra o próprio servidor Exchange, driblando restrições de rede; CVE-2022-41082 é o componente de RCE, acionado depois que o SSRF já deu ao atacante acesso a um contexto interno privilegiado, permitindo execução de PowerShell arbitrário.
O CVSS 8.0 informado (AV:A) reflete que o vetor de ataque é de rede adjacente/local no contexto de exploração encadeada — mas a exploração documentada publicamente ocorre via rede, através de requisições HTTP ao endpoint Autodiscover. PR:L indica que privilégios baixos (uma conta de usuário do Exchange válida, mesmo sem privilégios administrativos) já bastam como pré-requisito de autenticação.
Como é explorada
Na prática, a exploração observada em campo (batizada ProxyNotShell pela comunidade) segue o padrão: o atacante autenticado envia uma URL manipulada ao serviço Autodiscover para acionar o SSRF do CVE-2022-41040, obtendo acesso a um contexto interno do servidor; a partir desse ponto, aciona a deserialização vulnerável do CVE-2022-41082 para executar comandos PowerShell arbitrários no contexto da conta de serviço do Exchange. O pré-requisito de autenticação é o detalhe que a manchete de "RCE crítico" costuma esconder: não é um ataque anônimo pré-autenticação — exige uma credencial válida de usuário do Exchange, o que reduz drasticamente a superfície em ambientes sem contas expostas ou comprometidas por phishing/credential stuffing.
A GTSC observou essa cadeia sendo usada ativamente desde agosto de 2022, antes de qualquer patch estar disponível, o que motivou a inclusão imediata no catálogo KEV da CISA (adicionado em 30/09/2022, prazo de correção 21/10/2022) e o rótulo "exploração confirmada". Existem módulo Metasploit e provas de conceito públicas, o que baixa a barreira técnica para replicar o ataque uma vez obtida uma credencial.
O resultado final é execução de código com privilégios da conta de serviço do Exchange no servidor Mailbox, abrindo caminho para escalonamento de privilégios e movimento lateral dentro do Active Directory e do ambiente Exchange — não é limitado à leitura de e-mails, é controle do host.
Versões
Como se proteger
A correção definitiva são as atualizações de segurança do Patch Tuesday de novembro de 2022 (8 de novembro), que corrigem tanto CVE-2022-41082 quanto CVE-2022-41040 para Exchange Server 2013 CU23, 2016 CU22/CU23 e 2019 CU11/CU12. As atualizações de outubro de 2022 (11/10) explicitamente NÃO corrigiam essas duas falhas — administradores que aplicaram apenas o patch de outubro e assumiram estar protegidos permaneceram vulneráveis.
Enquanto o patch não é aplicado, a Microsoft publicou uma regra de bloqueio de URL via IIS (mitigação de URL Rewrite) para filtrar padrões de requisição associados ao ataque contra o Autodiscover — a expressão regular recomendada foi revisada mais de uma vez (a versão atualizada usa o padrão .*autodiscover\.json.*Powershell.* sem o símbolo @, e recomenda trocar a Condition Input de {URL} para {UrlDecode:{REQUEST_URI}} para cobrir variantes com URL-encoding). Essa mitigação reduz o vetor conhecido publicamente mas não fecha a falha de deserialização em si — variantes de bypass do filtro ("ProxyNotShell bypass") foram reportadas depois. Restringir conexões de saída do servidor Mailbox via proxy com allowlist específica é um controle compensatório adicional citado pelo CERT/CC.
O que não funciona como mitigação suficiente: aplicar apenas os patches de outubro de 2022, ou confiar unicamente na regra de URL Rewrite sem plano de patch — a própria Microsoft e o CERT/CC deixam claro que mesmo com o workaround em vigor o ambiente on-premises permanece em risco até o patch de novembro ser aplicado. Clientes de Exchange Online recebem mitigação automática da infraestrutura gerenciada pela Microsoft, mas isso não se aplica a instalações on-premises.
Como detectar
Nos logs do IIS/Exchange, procurar requisições ao endpoint Autodiscover contendo padrões associados ao ataque, especialmente variações de "autodiscover.json" combinadas com referências a PowerShell na cadeia de URL (incluindo variantes com URL-encoding, que passam a ser capturadas apenas com a condição {UrlDecode:{REQUEST_URI}}). A GTSC e outros pesquisadores publicaram indicadores de comprometimento associados às campanhas observadas em agosto/setembro de 2022, incluindo web shells depositados após a exploração — presença de arquivos .aspx anômalos em diretórios do Exchange é sinal de comprometimento pós-exploração, não de tentativa isolada. Não há um único log definitivo de "tentativa de exploração falha" documentado publicamente; a ausência de sinal claro em ambientes que não monitoram logs do IIS com granularidade é um risco real — a detecção depende de correlação entre acesso ao Autodiscover, execução anômala de processos PowerShell pela conta de serviço do Exchange, e presença de web shells.