Microsoft Exchange Server Remote Code Execution Vulnerability

Falha de desserialização insegura no Exchange Server que permite a um atacante já autenticado (mesmo com privilégios baixos, como uma conta de caixa de correio comum) executar código remotamente no servidor, explorando validação incompleta de argumentos passados a cmdlets do PowerShell remoto do Exchange. Está no catálogo KEV da CISA com exploração confirmada em campo, o que eleva sua prioridade acima do que o CVSS 8.8 já sugere — mas o pré-requisito de autenticação (PR:L) limita o vetor a quem já tem alguma credencial válida no ambiente, não a um atacante anônimo na internet.

A vulnerabilidade é classificada sob CWE-184 (Incomplete List of Disallowed Inputs) e CWE-502 (Deserialization of Untrusted Data). O mecanismo, segundo a descrição da CISA, envolve validação inadequada de argumentos passados em cmdlets expostos pela interface de gerenciamento remoto do Exchange (o mesmo caminho usado por ECP e pelo PowerShell remoto do Exchange). Um atacante autenticado consegue submeter um argumento cujo conteúdo é desserializado pelo servidor sem checagem suficiente de tipo permitido — daí o CWE-184, lista incompleta de entradas bloqueadas.

O nome que aparece em uma das referências de exploração, 'ChainedSerializationBinder Remote Code Execution', indica relação direta com o componente que a Microsoft introduziu justamente para mitigar desserialização insegura em cmdlets do Exchange após incidentes anteriores (o binder que restringe quais tipos .NET podem ser desserializados). A CVE-2021-42321 aparenta ser um bypass desse controle: o atacante encontra um argumento ou caminho de cmdlet que escapa da lista de tipos permitidos pelo binder, reintroduzindo a classe de falha que o binder deveria ter fechado.

O resultado final é execução de código no contexto do processo do Exchange no servidor, o que em ambiente corporativo típico significa comprometimento total do serviço de e-mail e, dependendo da topologia, pivô para o restante do Active Directory.

Pré-requisito real: o atacante precisa de uma conexão de rede ao Exchange e de uma conta autenticada — não necessariamente privilegiada, uma caixa de correio comum já qualifica dado PR:L no vetor CVSS. Isso muda o perfil de risco: não é um RCE pré-autenticação como o ProxyLogon original, é uma escalada a partir de qualquer usuário legítimo (ou credencial roubada) do ambiente Exchange, o que ainda é um cenário comum em pós-comprometimento de phishing ou credential stuffing.

A exploração passa pelo envio de argumentos manipulados a cmdlets acessíveis remotamente (via interfaces como ECP/PowerShell remoto do Exchange), forçando a desserialização de um objeto que o ChainedSerializationBinder deveria ter bloqueado. A CISA confirma exploração ativa no catálogo KEV, e existem PoC pública e módulo Metasploit, o que reduz a complexidade prática: uma vez com credencial válida, o caminho de ataque está automatizado em ferramentas conhecidas.

Complexidade de ataque é baixa (AC:L) e não exige interação do usuário (UI:N). O impacto é total — confidencialidade, integridade e disponibilidade (C:H/I:H/A:H) — porque a execução ocorre no processo do servidor Exchange, tipicamente com privilégios elevados no host e frequentemente com direitos amplos no Active Directory (delegação do Exchange).

Aplicar as atualizações de segurança da Microsoft para as versões afetadas: Exchange Server 2016 Cumulative Update 21 e 22, e Exchange Server 2019 Cumulative Update 10 e 11. A Microsoft distribui a correção como atualização de segurança sobre essas CUs específicas — como o Exchange só recebe patch sobre as duas CUs mais recentes suportadas de cada versão, é necessário estar em CU21/CU22 (2016) ou CU10/CU11 (2019) antes de aplicar a atualização; instalações em CUs mais antigas precisam primeiro atualizar a CU para depois receber o patch de segurança.

Não há detalhe de número de build de correção nas fontes consultadas aqui — confirme o KB específico do Patch Tuesday de novembro de 2021 no portal do MSRC antes de considerar o ambiente corrigido, pois aplicar apenas a CU sem a atualização de segurança subsequente não resolve a falha.

Como controle compensatório quando a atualização não pode ser aplicada de imediato: reduzir a superfície exposta ao PowerShell remoto/ECP do Exchange restringindo acesso de rede a essas interfaces (segmentação, VPN, allowlist de IPs administrativos) e reforçar monitoramento de contas de e-mail para detectar comprometimento de credenciais, já que o vetor depende de autenticação. Isso não substitui o patch — apenas reduz a chance de uma conta comprometida ser usada para escalar até RCE.

As fontes consultadas não trazem indicadores técnicos específicos (assinaturas de log, padrões de requisição HTTP ou strings de exploração) para esta CVE em particular. Como o vetor passa por cmdlets expostos via ECP/PowerShell remoto do Exchange, revisar logs de autenticação e de uso administrativo dessas interfaces por contas que normalmente não interagem com elas é um ponto de partida razoável, mas não há assinatura confirmada publicamente nas referências analisadas — trate ausência de alerta como ausência de dado, não como ausência de exploração.