Ivanti Connect Secure: por que o patch de 13/10 não bastou

Por Equipe Técnica HD Doctor

Resposta direta

Se a sua empresa usa Ivanti Connect Secure, a correção de 13/10 não basta: aplique também a de 29/10, que fecha as outras duas falhas da cadeia usada para obter root no appliance. Atualizar não desfaz um acesso anterior. Antes de qualquer reset, preserve os registros; depois, troque as credenciais que a VPN usa no Active Directory e avalie rotacionar senhas LAPS e chaves de recuperação do BitLocker, guardando cópia das chaves fora do AD.

O que se sabe sobre a cadeia e por que ela chega ao AD

Em 13/10/2026, a Ivanti corrigiu a CVE-2026-104935, um desvio de autenticação no Connect Secure que permite a um atacante remoto, sem login, executar comandos. A CISA incluiu a falha no catálogo KEV no mesmo dia. Também em 13/10, a Volexity publicou a investigação que deu origem ao alerta: o grupo que ela chama de UTA0576 explorava o appliance de um cliente desde 03/10/2026, encadeando essa falha a outras ainda sem correção para executar comandos como root. Em reportagem de 02/11, a BleepingComputer relata que a Defused viu os primeiros sinais de exploração em 1º/10. Fonte: https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/. As outras duas peças da cadeia ficaram abertas até 29/10, quando a Ivanti publicou nova correção, segundo a atualização da Volexity e a BleepingComputer. A CVE-2026-118527 permite gravar arquivos com conteúdo do atacante em local previsível do disco; a CVE-2026-111357 leva à escalada de privilégio até root. Pelas descrições oficiais, ambas exigem autenticação: a correção de 13/10 tirou da cadeia a entrada sem login, mas não o restante. A CISA incluiu as duas no KEV em 30/10 e revisou o alerta, que lista como afetadas as versões 25.1.1.2 e anteriores, 25.1.2.2 e anteriores e 22.8R2.5 e anteriores. O registro da CVE-2026-118527, publicado pela Ivanti, aponta 25.1.1.3 e 22.8R2.6 como corrigidas; confirme no advisory da Ivanti o build da sua linha. Fontes: https://www.cisa.gov/news-events/alerts/2026/10/13/cisa-urges-patching-newly-exploited-vulnerability-ivanti-connect-secure e https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-CVE-2026-104935. Nenhuma das correções desfaz o que já ocorreu. A Volexity relata que o grupo não instalou malware nem web shell: reexplorava o appliance a cada comando e apagava entradas recentes do log de depuração e do log de auditoria do Linux. A Integrity Checker Tool (ICT), ferramenta da Ivanti que procura alterações em disco, não detectou nada, porque a modificação ficava na memória. A CISA confirma que a ICT pode não detectar a exploração e recomenda forense de rede e de memória; no KEV, marcou a CVE-2026-104935 e a CVE-2026-111357 com exigência de triagem forense para os órgãos federais americanos. Na prática, um resultado limpo da ICT não prova que o appliance não foi usado, e reiniciar ou resetar antes da coleta apaga o que estava só na memória. Depois de obter root, segundo a Volexity, o grupo extraiu credenciais guardadas no appliance, como as de domínio usadas no LDAP, e usou a própria conta de serviço da VPN no Active Directory para procurar atributos de alto valor, entre eles senhas LAPS e informações de recuperação do BitLocker. Também levou ao appliance uma ferramenta capaz de Kerberoasting. A Volexity não afirma que essas senhas e chaves foram obtidas, diz que o alcance de cada operação não foi totalmente estabelecido e descreve a atividade como preparação para movimento lateral. Nossa leitura: se a conta de serviço da VPN podia ler esses atributos, trate-os como expostos. A senha LAPS é a do administrador local de cada computador Windows; a senha de recuperação do BitLocker abre o volume cifrado fora da máquina original. A chave de recuperação tem dois lados. Nas mãos de um atacante, abre notebooks, discos ou cópias de discos virtuais de máquinas cifradas. Para a empresa, é o que permite ler um disco cifrado que falhou ou precisou sair da máquina original, onde o TPM já não destrava o volume. Se a única cópia das chaves fica no AD e o AD se perde num incidente, recuperar os setores de um disco com falha não basta para ler o conteúdo. Por isso, ao rotacionar as chaves, guarde uma cópia fora do AD, offline e com acesso restrito. Se discos, RAID, VMs ou bancos ficarem inacessíveis, a HD Doctor pode avaliar a recuperação conforme o material preservado. Essa avaliação não substitui a resposta a incidentes, não certifica a segurança do ambiente e não garante recuperar conteúdo perdido.

Três decisões que deixam a porta aberta

1.
Encerrar o caso porque o patch de 13/10 foi aplicado. A correção de 13/10 não cobre as duas falhas corrigidas em 29/10, e nenhuma atualização desfaz um acesso anterior. Confirme a versão atual e investigue o período em que o appliance ficou exposto.
2.
Resetar o appliance antes de preservar registros e memória. O reset de fábrica faz parte da recuperação indicada pela CISA, mas apaga o que só existia na memória e o que restou dos logs. Combine com a equipe de segurança o que coletar antes, sem adiar a contenção de um ataque em andamento.
3.
Rotacionar as chaves do BitLocker e guardá-las só no AD. Se o AD foi consultado pelo atacante ou vier a ser perdido num incidente, a única cópia das chaves fica comprometida ou inacessível. Mantenha uma cópia fora do domínio, offline e com acesso restrito.

Cinco passos para fechar a cadeia e proteger o AD

Roteiro editorial para coordenar TI, segurança e o responsável pela VPN. Não rode exploits públicos para testar se o seu appliance é vulnerável.

1
Confirme a versão e aplique as duas correções
Liste todos os appliances Connect Secure, físicos e virtuais, com a versão de cada um. Confirme no advisory da Ivanti o build corrigido para a sua linha e aplique-o. Na linha 22.8, planeje a migração: a CISA indica fim da vida em 31/01/2027.
2
Preserve evidências antes de reset ou reconstrução
Exporte os logs para fora do appliance, salve a configuração e, quando possível, a memória ou uma cópia da VM. Para suspeita de comprometimento, a CISA orienta salvar a configuração, fazer reset de fábrica, atualizar e restaurar a configuração; em instâncias virtuais, reconstruí-las. Siga essa ordem depois da coleta.
3
Procure sinais fora do appliance
Como os logs locais podem ter sido editados, confira o que ficou registrado em outros pontos: firewall, controladores de domínio e SIEM. Procure consultas LDAP feitas pela conta de serviço da VPN, pedidos de tickets de serviço Kerberos fora do padrão e tentativas de acesso a outros servidores partindo do appliance.
4
Troque credenciais e segredos que a VPN alcançava
A CISA recomenda trocar as senhas de todas as contas, inclusive de domínio, administrativas e locais, revogar e reemitir certificados armazenados e trocar chaves de API e credenciais do servidor de licenças. Inclua a conta de serviço da VPN, reduzindo suas permissões, as contas de serviço sujeitas a Kerberoasting e as senhas LAPS.
5
Rotacione as chaves do BitLocker e guarde cópia fora do AD
Se a conta da VPN podia ler as informações de recuperação, gere novas senhas de recuperação para os volumes e remova as antigas. Exporte as novas para um cofre fora do domínio, com acesso restrito, e confira por amostragem se o ID registrado corresponde ao protetor de cada volume.

Perguntas sobre a falha do Ivanti e a proteção dos dados

Apliquei a correção de 13/10. Ainda preciso fazer algo?

Sim. A CVE-2026-118527 e a CVE-2026-111357 só foram corrigidas em 29/10. E, se o appliance ficou exposto antes das correções, atualizar não desfaz um acesso que já ocorreu: credenciais copiadas continuam válidas até serem trocadas.

A Integrity Checker Tool não encontrou nada. Posso considerar o appliance limpo?

Não com base apenas nela. A Volexity relata que a ICT não detectou essa intrusão, porque a modificação ficava na memória, e a CISA alerta que a ferramenta pode não detectar a exploração. Combine o resultado com forense de rede e de memória e com os registros de outros sistemas.

Por que trocar as chaves do BitLocker se nenhum disco foi roubado?

Porque a senha de recuperação abre o volume em qualquer lugar, inclusive em notebooks, discos descartados ou cópias de discos virtuais. Se a conta da VPN podia lê-la no AD, considere-a exposta. Depois da troca, guarde a nova chave também fora do AD.

Quando faz sentido pedir recuperação profissional de dados?

Quando discos, volumes, VMs ou bancos ficarem inacessíveis após o incidente, ou quando um disco cifrado apresentar falha física. Preserve as mídias, localize a chave de recuperação do BitLocker e registre o que já foi tentado. Para suspeita de acesso indevido sem dano aos dados, a prioridade é a resposta a incidentes.

Algum disco, volume ou VM ficou inacessível?

Preserve as mídias, localize a chave do BitLocker e informe as tentativas já realizadas.