SharePoint CVE-2026-58644: resposta do SOC ao KEV crítico

A execução remota de código no SharePoint Server via CVE-2026-58644 — uma falha de desserialização de dados não confiáveis com CVSS 9.8 — entrou no catálogo Known Exploited Vulnerabilities da CISA em 16 de julho de 2026, com confirmação de exploração ativa pela Microsoft no dia anterior e prazo federal em 19 de julho sob a diretriz BOD 26-04. Para um SOC, o enquadramento no KEV significa que há evidência de exploração no mundo real, não risco teórico: o servidor exposto pode já estar sob ataque ativo, e a resposta deve priorizar detecção de persistência antes de qualquer rotação.

O que muda no SOC

A diferença entre um patch comum e uma entrada no KEV é a evidência concreta de ataque em ambiente real. O NVD atribuiu CVSS 9.8 com vetor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, explorável pela rede sem interação do usuário e com impacto total em confidencialidade, integridade e disponibilidade, e atualizou o campo de exploração para ativo a partir de 16 de julho de 2026. Isso quer dizer que há operadores testando payloads contra instâncias acessíveis, e não apenas prova de conceito em laboratório. A janela de três dias entre a inserção no KEV e o prazo final comprime o triage contra o tempo real do adversário.

A falha e as versões

O SharePoint Online, gerenciado pela Microsoft dentro do Microsoft 365, não está no escopo do alerta e já recebeu tratamento centralizado pela fabricante. O risco se concentra nos farms on-premises, onde a responsabilidade pelo patch é do cliente e a exposição à internet costuma ser maior do que o inventário admite.

As versões afetadas e suas builds corrigidas são:

Versão do SharePoint	Build corrigida
Enterprise Server 2016	16.0.5556.1005
Server 2019	16.0.10417.20153
Server Subscription Edition	16.0.19725.20384

Confirmar o número de build instalado em cada servidor do farm é o primeiro passo de qualquer verificação de conformidade com o prazo do KEV, porque farms multi-servidor parcialmente atualizados permanecem expostos mesmo durante o processo de remediação.

Detecção com AMSI e Defender

A orientação da Microsoft e da CISA concentra-se em habilitar a Antimalware Scan Interface (AMSI) para cada aplicação web do SharePoint, com o modo Full Request Body Scan ativo, de forma que o Defender inspecione cargas maliciosas no corpo das requisições POST recebidas pelo servidor. Sem AMSI, a recomendação é desconectar da internet os produtos afetados até a aplicação da mitigação oficial.

Para acelerar o turno, a Microsoft publica assinaturas de detecção para identificar a exploração: Exploit:Script/SuspSignoutReqBody.A inspeciona o corpo da requisição, Exploit:Script/ToolPaneAuthBypass.A e .C cobrem cabeçalho e RCE, e Backdoor:MSIL/LeakFang.A!dha sinaliza acesso a segredos protegidos pelo processo do IIS. Cruzar esses alertas com logs de autenticação e de worker do SharePoint sustenta um triage que separa ruído de intrusão real.

Cadeia de exploração no SharePoint

O CVE-2026-58644 raramente opera isolado. A CISA já rastreava uma cadeia ativa formada por CVE-2026-32201 (bypass de autenticação), CVE-2026-45659 (execução remota autenticada) e CVE-2026-56164 (elevação de privilégio), combinada para roubar machine keys do IIS, estabelecer persistência por desserialização e instalar malware. As três falhas foram adicionadas ao KEV entre abril e julho de 2026, o que reforça o SharePoint como alvo de plataforma, não de bug pontual.

A persistência por roubo de machine key é o ponto mais crítico: com a chave criptográfica em mãos, o atacante forja tokens de autenticação válidos e mantém acesso mesmo depois de patches e trocas de senha. Por isso, a contenção não termina no patch — ela só termina quando a persistência é removida e as chaves são rotacionadas.

O relatório de análise de malware da CISA sobre a campanha ToolShell de 2025 documenta o mecanismo: as DLLs empregadas recuperam configurações de machine key do ASP.NET e as devolvem no cabeçalho HTTP, criando um canal de exfiltração que sobrevive à rotação se não for removido antes. Esse padrão explica por que a ordem das ações de resposta importa tanto quanto a velocidade.

Sequência de resposta segura

A sequência recomendada pela CISA para SharePoint comprometido é rotate, patch, rotate: rotacionar as machine keys do ASP.NET, aplicar a atualização de segurança, depois rotacionar as chaves novamente e reiniciar o IIS. O objetivo é fechar a janela de persistência antes e depois da correção, e não apenas empilhar o patch sobre um servidor invadido.

A ordem importa porque rotacionar chaves sem antes caçar artefatos de intrusão apenas entrega as novas chaves ao invasor. Antes de qualquer rotação, o SOC deve buscar webshells, módulos maliciosos em applicationHost.config e web.config, e arquivos .aspx ou .ashx recém-criados nos diretórios virtuais do SharePoint; a caça precede a rotação, sempre.

A CISA recomenda implantar proteções de EDR e acionar contenção rápida contra atividade de pós-exploração; isolamento de host, suspensão de conta e revogação de sessão devem ser caminhos de ação pré-aprovados no SOAR, e não decisões que esperam aprovação em reunião.

Exposição e hardening

O inventário de ativos é o primeiro gargalo. O Censys observa cerca de 1.500 hosts SharePoint on-premises acessíveis, com concentração relevante em infraestrutura de nuvem sob responsabilidade do cliente; boa parte da população exposta roda em cloud, mas o patch continua sendo dever do cliente. Mapear proxy, VPN e URLs externas de colaboração é o que revela a exposição real, e não o pressuposto de que o SharePoint é só interno.

A recomendação de hardening da CISA é não expor o SharePoint diretamente à internet; quando o acesso externo for inevitável, colocá-lo atrás de um proxy reverso de camada 7 com autenticação, bloquear acesso externo à Central Administration e restringir o tráfego entre farm e banco de dados. Restringir a superfície administrativa reduz drasticamente o número de caminhos que o atacante precisa testar.

Checklist para o turno

O checklist resume a resposta em etapas mensuráveis e auditáveis no ticket:

Inventariar todo SharePoint on-premises e registrar versão e exposição à internet.
Aplicar a atualização de julho de 2026 e validar o número de build em cada servidor.
Confirmar AMSI habilitada com Full Request Body Scan em cada aplicação web.
Caçar webshells, módulos maliciosos e artefatos de machine key antes de qualquer rotação.
Rotacionar as machine keys do ASP.NET e reiniciar o IIS com iisreset.exe.
Bloquear acesso externo à Central Administration e revisar logs de exploração.

A documentação limpa do cronograma, dos indicadores e das ações sustenta a melhoria contínua do playbook e transforma cada incidente em regra de detecção nova. Quem caça persistência antes de rotacionar chaves e aciona contenção automatizada nos primeiros minutos contém o incidente; quem só aplica o patch limpa a vulnerabilidade, mas não necessariamente o invasor.