Cloud security resource

Zero-day no ivanti connect secure permite invasões de Vpn e roubo de credenciais

5 минут чтения

Zero-day no Ivanti Connect Secure abre caminho para invasões de VPN e roubo de credenciais

Uma cadeia de vulnerabilidades no Ivanti Connect Secure permitiu que invasores contornassem a autenticação, executassem código e alcançassem privilégios de root em appliances VPN. A investigação também apontou o acesso a credenciais de domínio e a dados relacionados ao Active Directory, além de senhas LAPS e chaves BitLocker.

O caso foi identificado em 5 de outubro, quando a equipe de segurança da Volexity analisava atividades suspeitas na rede de um cliente. Os pesquisadores encontraram um equipamento Ivanti Connect Secure comprometido, embora ele estivesse rodando a versão 22.8R2.4, considerada atualizada naquele momento. A análise indicou que a exploração havia começado dois dias antes. O incidente foi divulgado em 13 de outubro, data em que a Ivanti publicou correções para a CVE-2026-104935.

O Connect Secure permite que funcionários remotos acessem recursos corporativos por meio de uma VPN. Como o appliance fica exposto à internet e pode se comunicar com serviços internos de autenticação e diretórios, uma invasão bem-sucedida representa mais do que o comprometimento de um equipamento. Ela pode criar uma ponte para alcançar contas, sistemas e informações da rede corporativa.

A CVE-2026-104935 recebeu pontuação 8,6 no CVSS, classificada como alta. Em 13 de outubro, a agência norte-americana CISA incluiu a falha no catálogo Known Exploited Vulnerabilities (KEV), que reúne vulnerabilidades com exploração confirmada. Para os órgãos federais abrangidos pela determinação, o prazo de correção foi estabelecido para 16 de outubro.

Como a cadeia de falhas foi explorada

A invasão começava com uma inconsistência no processamento de requisições HTTP. Uma solicitação direcionada a uma página pública de autenticação podia incluir, em um cabeçalho específico, o caminho de outro componente CGI, normalmente protegido por autenticação. O appliance verificava o acesso com base no endereço público, mas encaminhava a solicitação ao componente interno indicado no cabeçalho. Essa diferença permitia contornar a barreira de autenticação.

Em seguida, os atacantes abusavam do mecanismo de upload. O arquivo enviado era armazenado temporariamente no sistema antes de ser validado e removido caso não estivesse no formato esperado. Durante esse intervalo, requisições simultâneas tentavam executar o arquivo. A combinação entre o desvio de autenticação e essa condição de corrida possibilitava a execução remota de código no contexto do serviço CGI.

Para elevar o acesso até root, os invasores recorreram a uma terceira vulnerabilidade. O código alterava temporariamente informações na memória associadas a tarefas do serviço privilegiado dsinvoked. Com isso, uma rotina de manutenção era desviada para executar um interpretador controlado pelos atacantes. Após a execução, o código tentava reverter as alterações e apagar vestígios. Segundo os pesquisadores, essa falha de elevação de privilégios ainda não tinha uma correção própria no momento da divulgação. A Ivanti agrupou as falhas de autenticação e execução remota na CVE-2026-104935.

A operação também dificultava a detecção. Os comandos e os resultados eram transmitidos pelas próprias requisições HTTPS usadas na exploração, sem depender necessariamente de um servidor externo de comando e controle. Além disso, parte do código funcionava diretamente na memória, sem criar uma web shell persistente. Por isso, a ferramenta Integrity Checker da Ivanti, projetada para localizar alterações inesperadas em arquivos, poderia não identificar toda a atividade.

A Volexity atribuiu provisoriamente a campanha a um ator identificado como UTA0576, ainda pouco conhecido. A investigação registrou a extração de credenciais guardadas no appliance, entre elas dados de uma conta de serviço, além de informações de domínio e do Active Directory. Também foram considerados expostos mecanismos de autenticação e dados como senhas LAPS e chaves BitLocker, que podem ampliar o impacto caso sejam reutilizados ou permaneçam válidos.

O que fazer após atualizar o appliance

Instalar a correção é uma medida urgente, mas não deve ser tratada como garantia de que o incidente foi encerrado. Se o equipamento foi explorado antes da atualização, os invasores podem ter obtido credenciais ou usado o acesso inicial para avançar por outros sistemas. A resposta precisa incluir a avaliação do período anterior à correção e a busca por sinais de movimentação na rede.

As equipes de segurança devem revisar os registros do appliance, especialmente requisições HTTP incomuns, tentativas de acesso a componentes CGI e atividades relacionadas a uploads. Também é importante verificar conexões com serviços internos, alterações inesperadas em contas e acessos fora do padrão. Como parte do código pode operar apenas em memória, a ausência de arquivos suspeitos não elimina a possibilidade de comprometimento.

Credenciais potencialmente acessíveis pelo equipamento devem ser tratadas como expostas até que se prove o contrário. Isso inclui senhas de contas de serviço, dados de autenticação do Active Directory e chaves usadas para proteger dispositivos. A rotação deve ser planejada para evitar interrupções, priorizando contas privilegiadas e credenciais que permitam acesso remoto ou automação.

A investigação deve abranger outros ativos, não apenas a VPN. É necessário verificar se contas ligadas ao appliance foram usadas para acessar servidores, diretórios ou estações de trabalho, além de identificar mudanças em privilégios e configurações de autenticação. Se houver indícios de persistência ou de acesso a sistemas internos, pode ser necessário isolar o equipamento e reconstruí-lo a partir de uma configuração confiável.

Por fim, organizações que dependem de appliances expostos à internet devem manter um processo de resposta específico para esses dispositivos. Inventário atualizado, aplicação rápida de correções, autenticação forte, restrição de acessos administrativos e monitoramento centralizado reduzem a janela de exposição. Em casos de exploração confirmada, a prioridade não é apenas voltar a operar: é determinar o que foi acessado, revogar credenciais comprometidas e impedir que o invasor mantenha um caminho de retorno.