Zero-Day no Ivanti Connect Secure: aplique patch, investigue

Por que esta campanha é diferente de um ciclo de patches comum? Porque os invasores estavam à frente do fabricante e porque as redes de segurança habituais não os detectaram.

Segundo a análise da Volexity, o equipamento da vítima estava totalmente atualizado e, mesmo assim, os invasores obtiveram root. Três detalhes se destacam para quem defende:

• Não há malware para encontrar. A Volexity não encontrou web shell nem backdoor de primeiro estágio. Os invasores simplesmente repetiam a cadeia de exploração completa sempre que precisavam executar um comando e liam o resultado na resposta HTTP.
• O verificador de integridade não enxerga. A cadeia opera em grande parte na memória, e a Volexity afirma que a ferramenta Integrity Checker da Ivanti não detecta as modificações. A CISA também alerta que ela pode deixar passar a evidência. Uma varredura limpa não prova que o equipamento está limpo.
• Evidências foram apagadas. Os invasores removeram seletivamente entradas dos logs de depuração e auditoria e apagaram seus próprios payloads.

O segundo desafio é o que eles buscavam. A Volexity descreve o ator coletando as credenciais de domínio armazenadas no equipamento, consultando o Active Directory por senhas LAPS e chaves de recuperação do BitLocker, tentando Kerberoasting e password spraying e executando uma ferramenta de captura de pacotes renomeada para coletar material LDAP, HTTP Basic e NTLM em texto claro. Ou seja, a VPN serviu de plataforma de lançamento para obter segredos que abrem o restante do ambiente.

Por fim, a etapa de elevação de privilégios não tinha CVE nem patch quando o relatório foi publicado. A Ivanti afirmou que a correção virá em uma próxima versão, de modo que aplicar o patch hoje fecha a porta de entrada, mas não aposenta toda a cadeia.

Como funciona a cadeia de exploração do Ivanti Connect Secure? A Volexity descreve quatro etapas. Primeiro, uma requisição manipulada à página welcome.cgi, com o cabeçalho X-DSCGI-PATH alterado, contorna a autenticação e chega a um manipulador interno de uploads. Segundo, uma condição de corrida nesse manipulador permite que um script Perl enviado seja executado antes da validação do arquivo, resultando em execução de código com a conta do serviço web. Terceiro, scripts em estágios são entregues e executados na memória. Quarto, os invasores modificam o processo em execução e abusam de uma tarefa agendada para executar código como root, restaurando depois as alterações para esconder o que fizeram.

O que fazer agora? Trate isto como um incidente até que se prove o contrário:

1. Aplique o patch. Segundo o SecurityWeek, as correções da Ivanti para o bypass de autenticação e a RCE estão nas versões 22.8R2.5, 25.1.1.2, 25.1.3.0 e 25.1.3.1. Confirme o caminho de atualização exato da sua versão no aviso da Ivanti antes de agendar a mudança.
2. Investigue. Procure volumes altos de requisições a welcome.cgi e requisições em que o caminho da URL e o cabeçalho X-DSCGI-PATH não coincidem. Verifique /tmp e /home/runtime/tmp em busca de scripts ou arquivos JSON inesperados, procure um processo chamado dsstatmond ou um diretório oculto .icscap em /data e revise lacunas nos logs de depuração e auditoria.
3. Faça forense, não apenas varreduras. Se algo parecer suspeito, capture evidências de memória e de rede. Não dependa do Integrity Checker.
4. Recupere corretamente. A orientação da CISA em caso de suspeita de comprometimento é restaurar o equipamento para o padrão de fábrica e reinstalar a versão mais recente, e reconstruir implantações em nuvem e virtuais antes de restaurar a configuração.
5. Troque tudo o que o equipamento alcançava. Redefina senhas de domínio, de administrador e de contas locais, emita novamente certificados e substitua chaves de API e credenciais de contas de serviço armazenadas. Segredos roubados continuam roubados depois do patch.

Planeje também o longo prazo: a Volexity e outras fontes apontam que a linha 22.8 chega ao fim de vida em 31 de janeiro de 2027, portanto a migração para a linha 25.1 já deve estar no seu roadmap.

Por que as empresas precisam repensar a VPN tradicional? Porque o padrão se repete: um gateway exposto à internet com acesso profundo à rede, uma falha explorada antes de existir patch e invasores que passam da borda ao diretório em poucas horas.

Migrar do acesso VPN amplo em nível de rede para o acesso à rede com confiança zero (ZTNA) muda a economia do invasor. Em vez de cair em uma rede interna plana, um usuário, ou um invasor com credenciais roubadas, recebe acesso a uma aplicação por vez, após verificações de identidade e de dispositivo. Há menos o que roubar em um único equipamento e o raio de impacto do próximo zero-day é menor. Combinando isso com uma rede gerenciada e multioperadora, obtém-se conectividade resiliente sem deixar um grande concentrador exposto como única porta de entrada.

Os benefícios para o negócio são concretos:

• Menor impacto de uma violação. O acesso segmentado por aplicação limita o que um gateway comprometido pode revelar.
• Detecção mais rápida. O monitoramento contínuo de equipamentos de borda e da atividade do diretório identifica a coleta de credenciais que vem depois de um exploit, e não só o exploit.
• Menos trabalho emergencial. Menos equipamentos expostos significam menos maratonas de patches no fim de semana e menos reconstruções forçadas.
• Melhor postura de auditoria. Inventário documentado, SLAs de patches e procedimentos de troca de credenciais são exatamente o que reguladores e seguradoras de risco cibernético pedem.

A HIT Communications tem mais de 30 anos de experiência construindo e operando redes corporativas na América Latina, nos Estados Unidos e na Europa, e vemos a mesma prioridade em todas as regiões: o acesso remoto precisa ser rápido e, ao mesmo tempo, defensável.

Nossos serviços gerenciados de cibersegurança incluem um SOC 24/7 com SIEM e detecção e resposta gerenciadas (MDR), de modo que atividades suspeitas em equipamentos de borda, como requisições de autenticação incomuns ou consultas de credenciais ao Active Directory, sejam investigadas por analistas, e não fiquem em um log que ninguém lê. Ajudamos você a construir os playbooks de caça e resposta a incidentes descritos acima e apoiamos arquiteturas de confiança zero que reduzem a dependência de um único gateway de VPN.

Na rede, nossas soluções de conectividade multioperadora e SD-WAN combinam internet dedicada, SD-WAN e segurança no estilo SASE para que usuários remotos e de filiais cheguem às aplicações por caminhos controlados e redundantes. E, com nossos serviços gerenciados de TI, assumimos o trabalho pouco glamoroso que evita emergências: inventário de ativos, gestão de patches com SLAs claros, backup e planos de recuperação.

Se o seu equipamento Ivanti ficou exposto entre o início de outubro e a publicação do patch, podemos ajudar a avaliar se é caso de investigar, reconstruir e trocar credenciais, e depois desenhar um modelo de acesso remoto mais difícil de violar.

O zero-day do Ivanti Connect Secure mostra que uma VPN totalmente atualizada não é necessariamente uma VPN segura. Os invasores exploraram uma falha desconhecida, não deixaram malware, apagaram logs e foram direto às credenciais que abrem o Active Directory. As ações imediatas são claras: aplicar o patch, procurar os indicadores documentados, usar forense e não apenas o verificador de integridade, reconstruir se houver suspeita de comprometimento e trocar todos os segredos que o equipamento alcançava.

A ação estratégica é reduzir a quantidade de confiança concentrada em um único dispositivo exposto à internet. Faça o inventário dos seus equipamentos de borda, defina SLAs de patches medidos em dias, monitore-os como servidores críticos e avance para o acesso por aplicação.

Se quiser uma visão especializada da sua exposição em acesso remoto, fale com a equipe da HIT Communications e ajudaremos você a transformar este aviso em um plano concreto.