Ivanti Connect Secure: cadeia de zero-days explorada para obter root, uma das três falhas ainda sem correção

Atacantes encadearam três falhas desconhecidas dos gateways VPN Ivanti Connect Secure para executar comandos como root sem autenticação e depois recolher credenciais do Active Directory. A Ivanti corrigiu duas em 13 de outubro (CVE-2026-104935); a escalada de privilégios continua aberta.

O que aconteceu

Em 13 de outubro de 2026, a Ivanti divulgou a vulnerabilidade CVE-2026-104935 no seu gateway VPN Connect Secure, afirmando ter conhecimento de uma exploração limitada. No mesmo dia, a CISA incluiu-a no seu catálogo de vulnerabilidades exploradas e deu às agências federais norte-americanas até 16 de outubro para agir. A falha foi comunicada pela Volexity, que descobriu a cadeia ao investigar uma intrusão num cliente iniciada em 3 de outubro.

Segundo a Volexity, a cadeia combina três fraquezas: um desvio de autenticação em welcome.cgi, uma escrita de ficheiros que leva à execução remota de código e uma escalada de privilégios até root. As duas primeiras, agrupadas na CVE-2026-104935 (CVSS 8,6), estão corrigidas. A escalada de privilégios ainda não tem correção; a Volexity espera-a nas próximas semanas.

O que os atacantes fizeram

A Volexity acompanha o ator como UTA0576. Não instalou webshell nem backdoor: usou o gateway para recolher credenciais. As suas ferramentas consultavam o Active Directory por LDAP, faziam Kerberoasting e password spraying e capturavam tráfego para extrair logins LDAP, HTTP Basic e NTLM em texto claro. Também visavam senhas LAPS, chaves de recuperação BitLocker e a configuração da VPN. Como as alterações ficavam em memória, o Integrity Checker Tool da Ivanti pode não detetar o comprometimento.

O que fazer agora

  1. Verifique a versão. Segundo a NVD, estão afetados os ramos 22.8R2 a 22.8R2.4 e 25.1 anteriores a 25.1.3.0; a 22.7R2.14 e anteriores não.
  2. Atualize já para 22.8R2.5 ou 25.1.3.0 / 25.1.3.1, conforme o aviso da Ivanti.
  3. Analise os registos à procura de rajadas de pedidos a /dana-na/auth/url_default/welcome.cgi com um cabeçalho X-DSCGI-PATH e de ficheiros inesperados em /tmp/. Não confie apenas no Integrity Checker.
  4. Se o gateway estava exposto desde o início de outubro, trate-o como possivelmente comprometido: mude as senhas das contas de serviço AD usadas pela VPN e das contas com SPN, renove as senhas LAPS e as chaves BitLocker e vigie tentativas de password spraying.
  5. Aplique a terceira correção assim que a Ivanti a publicar.

A nossa opinião

Um gateway VPN vê passar todas as senhas da empresa: o local ideal para roubar um diretório inteiro sem tocar num único posto. A correção fecha a porta, mas as credenciais roubadas antes continuam válidas até serem mudadas. Essa renovação faz parte da resposta, não é opcional.

Fontes

Como escolhemos, verificamos e escrevemos nossas análises →

O seu próprio servidor está exposto? Faça um teste gratuito — apenas informações públicas, sem intrusão:

Verificar um servidor Verificar um site

Preocupado com a exposição dos seus servidores? Nossa equipe audita, corrige e monitora infraestruturas Linux e cloud 24/7.

Fale com um especialista Nossos serviços de gestão de servidores →