Ivanti Connect Secure: corrigir o gateway e investigar o acesso são entregas diferentes

A Volexity investigou um ataque que encadeou três falhas do Ivanti Connect Secure e permitiu executar comandos como root sem autenticação.[2] O equipamento estava na versão 22.8R2.4 quando a exploração começou, em 3 de outubro de 2026, e a Ivanti confirmou exploração limitada em ambiente real.[2] O caso mostra por que instalar uma correção e encerrar um incidente não são a mesma operação.

O que muda para quem desenvolve

As duas primeiras falhas, de autenticação e execução remota, são acompanhadas conjuntamente como CVE-2026-104935, com CVSS 8,6.[2] A terceira permite elevar privilégios a root e ainda aguardava correção no retrato da reportagem.[2]

O detalhe mais importante para operação é que o Integrity Checker Tool não detectou essa cadeia no caso analisado.[2] O invasor alterava bibliotecas em memória, restaurava configurações e não deixava uma web shell ou backdoor convencional em disco.[2] Para cada novo comando, repetia a exploração completa.[2]

Minha leitura é que um controle negativo só ajuda quando sua cobertura é conhecida. Se a verificação observa arquivos persistentes, não se deve usá-la como prova suficiente sobre ações transitórias em memória. O desenho da resposta precisa perguntar quais eventos poderiam ter ocorrido sem deixar o artefato procurado.

No incidente investigado houve roubo de credenciais armazenadas, inclusive de domínio LDAP, busca de senhas no Active Directory e tentativas de password spraying.[2] A análise de impacto, portanto, não deveria terminar no appliance: proponha mapear os sistemas alcançáveis por essas identidades.

Como aplicar

Abra duas frentes com critérios de aceite distintos. A primeira comprova versão, linha do produto e aplicação da correção pertinente. A segunda reconstrói a janela de exposição e avalia uso indevido de contas. Preserve evidências antes de ações que possam apagá-las, sob coordenação da equipe responsável pelo incidente.

A reportagem cita excesso de requisições a welcome.cgi, divergência entre o cabeçalho X-DSCGI-PATH e o caminho solicitado, além do diretório /data/.icscap/ como pistas do caso.[2] Em uma investigação autorizada, use esses sinais para correlação com acessos de domínio e registros de rede, não como teste binário de comprometimento.

Um exercício defensivo verificável é montar uma linha do tempo com eventos já disponíveis: acessos ao gateway, autenticações subsequentes e mudanças de privilégio. Marque explicitamente os períodos sem telemetria. A ausência de registro deve aparecer como lacuna, não como confirmação de ausência de ataque.

Cuidados e limites

A lista de versões tem exceções: inclui 22.8R2.5, 25.1.3.0 e 25.1.3.1 como não afetadas pelas duas primeiras falhas e exclui 22.7R2.14 e anteriores da faixa descrita.[2] Não reduza isso a uma comparação numérica única.

O risco isolado da terceira falha após corrigir as outras não é esclarecido, e não há balanço público de clientes atingidos.[2] A atualização pode fechar o caminho de entrada; não a trate como evidência de que credenciais previamente expostas deixaram de representar risco.

Fonte

[2] Fonte: The Hacker News