O alerta da CISA de 13 de outubro sobre o Ivanti Connect Secure não era uma precaução contra uma falha hipotética. Invasores já haviam encadeado desvio de autenticação e execução contra um appliance que estava atualizado para sua ramificação naquele momento. A agência adicionou CVE-2026-104935 ao catálogo de vulnerabilidades exploradas e fixou 16 de outubro como prazo de remediação para órgãos civis federais.
A correção imediata e o incidente não esclarecido são problemas distintos. A investigação da Volexity descreve exploração repetida, mudanças temporárias na memória, coleta de credenciais e exclusão seletiva de logs, sem um web shell persistente convencional. Atualizar fecha a entrada documentada, mas não revoga segredos roubados nem prova que não houve acesso anterior.
O prazo e as versões afetadas
A falha tem CVSS 8,6. Permite execução remota de comandos com baixa complexidade, sem conta prévia ou interação do usuário. O Connect Secure fica entre internet, aplicativos internos e serviços de identidade. Uma falha de autenticação nesse ponto concede uma posição confiável e valiosa ao invasor.
Os relatos concluídos identificam como afetadas 25.1.1.1 e anteriores nessa linha, 25.1.2.2 e anteriores e 22.8R2.4 e anteriores. Entre as correções estão 25.1.1.2, 25.1.3.0, 25.1.3.1 e 22.8R2.5. Isso não autoriza trocar ramificações livremente: a instalação e o caminho de atualização suportado precisam ser confrontados com o comunicado da Ivanti.
A exceção das versões antigas aparece com precisão diferente: o texto principal diz 22.7.x e anteriores; o material incorporado, baseado no CVE, cita 22.7R2.14 e anteriores. Nenhuma formulação garante a segurança geral nem justifica um downgrade. Versões antigas podem conter outras falhas ou estar fora de suporte.
A atualização KEV de 13 de outubro incluiu também Windows Shell CVE-2026-96951. É um problema separado que exige interação do usuário, diferentemente da entrada direta e não autenticada da Ivanti. Os dois receberam prazo de 16 de outubro para os órgãos Federal Civilian Executive Branch sob os requisitos BOD 26-04 citados. Empresas privadas não herdam automaticamente a obrigação da diretiva, mas enfrentam a mesma exposição técnica. Windows é contexto aqui, não uma segunda falha Ivanti.
A inclusão no KEV comprova exploração observada, não que todo aparelho exposto tenha sido invadido nem que a campanha tenha escala massiva. O campo de ransomware era desconhecido, não uma associação confirmada. A declaração da Ivanti sobre exploração limitada conhecida também descreve sua visibilidade, não um limite confiável de vítimas.
Um gateway então atualizado foi atacado antes da divulgação
A Volexity iniciou a investigação em 5 de outubro e rastreou exploração desde 3 de outubro no Connect Secure 22.8R2.4, Build 19097, atualizado para aquela linha. Outro provedor de inteligência teria visto sinais relacionados desde 1º de outubro. São observações distintas; a data anterior não deve ser atribuída como confirmação da Volexity.
A empresa acompanha a atividade desconhecida como UTA0576. É um rótulo analítico, não uma identidade real ou patrocínio estatal comprovado. Com baixa confiança, avaliou motivação criminosa em vez de espionagem. A operação foi interrompida antes de se determinar o objetivo final.
A Ivanti disse ter encontrado parte da falha no programa de segurança do produto e corrigido no lançamento 25.1.3.0 de julho de 2026. A exploração ocorreu durante a adaptação da correção a outras versões suportadas. Houve uma lacuna real de proteção entre linhas, mas o relato público não estabelece quando a empresa entendeu a cadeia inteira ou soube dos ataques. Trabalho de adaptação e compatibilidade não justifica uma acusação sem evidências de atraso deliberado.
O histórico inclui CVE-2025-0282, estouro de buffer na pilha explorado em janeiro de 2025, e CVE-2025-22457, depois associada à espionagem ligada à China. Esses casos não identificam UTA0576 nem provam que todo aparelho seja inseguro. A Volexity também comparou a extração de credenciais de capturas de pacotes com ataques contra acesso remoto SonicWall, mostrando a atratividade mais ampla da infraestrutura confiável de borda.
Três fraquezas transformaram acesso público em root
A cadeia reconstruída começou com uma divergência entre autorização e roteamento. Uma solicitação ao componente público de login welcome.cgi podia indicar outro destino no cabeçalho X-DSCGI-PATH. O appliance verificava a URL pública, mas encaminhava a solicitação ao manipulador protegido de upload wu.cgi.
Esse manipulador escrevia o arquivo antes de verificar se era um ZIP válido. Um script Perl disfarçado pela extensão existia brevemente antes de rejeição e exclusão. Requisições paralelas disputavam essa janela de limpeza e permitiam execução como a conta restrita cgi-server. Trata-se de uma falha temporal no tratamento de arquivos, não de prova de que ZIPs comuns sejam inerentemente executáveis.
A Ivanti agrupou o desvio de autenticação e a execução remota em CVE-2026-104935. Uma escalada separada envolvia um serviço privilegiado que confiava em configuração manipulada e uma alteração de biblioteca na memória. Uma tarefa legítima de manutenção era redirecionada a um script malicioso executado como root. O operador testava o acesso a informações protegidas de senha e depois restaurava configuração e instrução de memória.
Na publicação dos relatos concluídos, a Ivanti planejava corrigir depois essa escalada. Isso não significa que o update de 13 de outubro deixe aberta a entrada não autenticada documentada: bloquear entrada e execução interrompe aquela cadeia específica. Ainda assim, os lançamentos seguintes continuam relevantes.
O operador repetia o canal de exploração para trocar comandos e resultados por HTTPS, em vez de deixar uma backdoor inicial. Algumas etapas existiam só na memória, incluindo uma carga Python comprimida e codificada. Registros selecionados de depuração e auditoria Linux eram removidos; arquivos temporários e resultados, apagados; estados alterados, restaurados.
A Volexity constatou que a técnica evitou o Integrity Checker Tool da Ivanti. A ferramenta busca mudanças inesperadas em arquivos. Alterações temporárias de memória e configuração restaurada ultrapassam o que um resultado limpo orientado ao disco pode excluir. Isso limita a conclusão da verificação, sem torná-la inútil.
Dados de identidade ampliaram o impacto
O acesso de diretório do gateway permitiu consultar um controlador de domínio interno do Active Directory. Investigadores recuperaram ferramenta LDAP própria e scripts Python voltados a credenciais de administrador local LAPS, recuperação BitLocker, atributos contendo senhas, metadados de usuários e caminhos de scripts de logon. Registros de autenticação também forneceram nomes válidos.
Credenciais LAPS podem abrir acesso administrativo local; dados BitLocker podem desbloquear unidades criptografadas. A Volexity avaliou com alta confiança que informações disponíveis nas consultas de diretório visadas foram exfiltradas. Isso não estabelece que todo segredo pedido existia nem que todo comprometimento posterior funcionou.
O operador também procurou nas capturas credenciais LDAP em texto claro, material HTTP Basic e hashes de desafio-resposta NTLM. Um utilitário renomeado em diretório oculto monitorava protocolos como LDAP, HTTP, FTP e Telnet com oito arquivos rotativos. Abuso de hashes e ataques offline dependem de configuração e força das senhas. Ainda assim, coletar esses dados cria um problema que atualizar a VPN não desfaz.
Outras atividades incluíram reconhecimento DNS e de nomes internos, busca em configurações VPN e logs de autenticação e password spraying contra contas de diretório. Em conjunto, sustentavam preparação para movimentação lateral e acesso mais amplo. O objetivo final e o sucesso de cada técnica não foram estabelecidos.
A afirmação de IA do relato incorporado exige cautela. A Volexity avaliou com confiança média uso de grandes modelos de linguagem no desenvolvimento do exploit ou após a invasão, citando scripts adaptados, credenciais fixas, repetição do canal de comandos e complexidade. É inferência, não prova direta. Iteração humana ou ferramentas privadas existentes podem gerar padrões semelhantes; não comprova uma invasão autônoma por IA.
O que um encerramento defensável precisa estabelecer
Após a divulgação, a Shadowserver contou mais de 5.500 instâncias aparentemente expostas do Connect Secure. É observação de exposição, não contagem de clientes vulneráveis ou invadidos. Pode incluir honeypots, duplicações e sistemas atualizados. O inventário deve cobrir gateways ativos e reserva, nós de recuperação e testes esquecidos, verificando a compilação real.
A Ivanti recomendou atualização imediata e verificações regulares; a Rapid7 enfatizou ainda buscar comprometimento depois da correção. Datas de exposição, conexões originadas no gateway, logs de identidade e diretório, telemetria de firewall e DNS e memória preservada respondem a questões que a versão não resolve. Volume anormal em welcome.cgi e divergência URL/cabeçalho são indícios, mas os atacantes podem mudar padrões. Ausência de indicadores publicados não é liberação universal.
Contenção e preservação de provas podem conflitar. Reiniciar ou reconstruir destrói vestígios voláteis; atrasar o isolamento pode prolongar o acesso do invasor. Risco ativo, redundância e capacidade forense definem a sequência. Respondedores devem coordenar coleta sem estender desnecessariamente o acesso e registrar ações e horários.
A rotação de credenciais deve seguir integrações, segredos acessíveis e atividade observada. Contas de serviço, senhas administrativas locais, chaves de recuperação, tokens e segredos reutilizáveis de usuários merecem análise separada. Redefinições cegas podem interromper dependências e esquecer credenciais menos visíveis. Conexões posteriores vindas do gateway confiável também exigem investigação própria.
No longo prazo, convém limitar exposição externa e administrativa desnecessária, centralizar logs, reduzir privilégios das contas de diretório, segmentar a rede e retirar autenticação em texto claro quando possível. Isso não elimina zero-days, mas limita o alcance de uma máquina comprometida e as provas que ela pode apagar.
Os próximos sinais são novas explorações ou vítimas, cobertura comprovada entre versões suportadas, a correção da escalada separada e uso posterior de credenciais roubadas. A Volexity reteve código pronto para ataque, mas a análise técnica ainda pode ajudar imitadores. Ausência de novos casos públicos não prova ausência de invasões.
Encerrar exige respostas separadas sobre versão vulnerável, exposição durante a janela de exploração, evidências de acesso e sistemas ou segredos alcançáveis depois. A correção concluída responde à primeira pergunta. É um marco necessário, não substitui as outras três.