Vulnerabilidade no Ivanti Connect Secure leva a alerta da CISA, mas aplicar patches não é suficiente
A Ivanti enfrenta uma resposta de emergência após invasores explorarem uma vulnerabilidade no Ivanti Connect Secure contra appliances totalmente atualizados antes de sua divulgação em 13 de outubro. A CISA adicionou a CVE-2026-104935 ao seu catálogo de Vulnerabilidades Exploradas Conhecidas no mesmo dia. A falha permite que um invasor remoto ignore a autenticação e execute comandos arbitrários sem interação do usuário.
A instrução imediata é simples: instale a versão corrigida da Ivanti. O problema mais difícil é determinar se os invasores já entraram, roubaram credenciais e removeram as evidências mais óbvias. Investigadores descobriram que o operador observado explorava repetidamente os appliances em vez de instalar uma backdoor convencional.
Esse comportamento desafia a resposta habitual de aplicar patches e realizar varreduras. Um patch fecha o caminho de entrada divulgado, mas não revoga segredos roubados nem comprova que o appliance estava limpo antes disso. Para gateways de VPN expostos, a remediação agora exige tanto manutenção de software quanto investigação de incidente.
CISA transforma a vulnerabilidade do Ivanti Connect Secure em emergência
O alerta da CISA transforma a CVE-2026-104935 de uma fraqueza teórica de software em uma prioridade confirmada de resposta a incidentes.
O alerta federal da agência, de 13 de outubro, afirma que agentes de ameaça estão explorando a vulnerabilidade para roubo de credenciais e exfiltração de dados. A CISA também incluiu a falha em seu catálogo de Vulnerabilidades Exploradas Conhecidas, geralmente chamado de KEV.
Uma entrada no KEV tem mais peso operacional do que um aviso de vulnerabilidade comum. Ela significa que a CISA possui evidências de que invasores estão usando a falha fora de um laboratório. Agências civis federais devem corrigir entradas do KEV conforme requisitos federais vinculantes.
Os produtos afetados ocupam um ponto especialmente sensível nas redes corporativas. O Ivanti Connect Secure é um gateway de acesso remoto que conecta usuários a aplicações internas e recursos de nuvem. Ele precisa aceitar tráfego da internet enquanto mantém conexões confiáveis com sistemas internos de identidade.
Esse posicionamento torna um bypass de autenticação bem-sucedido particularmente grave. O invasor não começa a partir de uma estação de trabalho comum de funcionário. Ele começa a partir de um dispositivo projetado para mediar o acesso entre a internet e serviços protegidos.
A CVE-2026-104935 tem pontuação CVSS de 8,6. Ela é classificada como um bypass de autenticação por spoofing, o que significa que o appliance confia incorretamente em informações usadas para encaminhar uma solicitação. A exploração exige baixa complexidade, nenhuma conta existente e nenhuma interação da vítima.
A Ivanti afirma que as versões afetadas são:
Versão 25.1.1.1 e anteriores nessa linha de código
Versão 25.1.2.2 e anteriores nessa linha de código
Versão 22.8R2.4 e anteriores nessa linha de código
As versões corrigidas disponíveis incluem 25.1.1.2, 25.1.3.0, 25.1.3.1 e 22.8R2.5. Os administradores devem corresponder a atualização ao branch implantado e confirmar as orientações atuais no aviso de segurança.
A Ivanti afirma que as versões 22.7.x e anteriores não são afetadas por esta vulnerabilidade específica. Essa declaração não deve ser interpretada como garantia geral de suporte ou segurança para softwares mais antigos. As organizações devem revisar separadamente o status de ciclo de vida e outras vulnerabilidades que afetam a versão instalada.
A empresa disse ter conhecimento de exploração limitada quando divulgou a falha. “Limitada” descreve os casos conhecidos pela Ivanti, não o número total de appliances comprometidos. Operadores sofisticados frequentemente minimizam artefatos, enquanto muitas organizações não possuem telemetria completa de appliances de rede.
A exposição à internet aumenta a urgência. A Shadowserver rastreava mais de 5.500 instâncias aparentes do Connect Secure online após a divulgação. Essa contagem pode incluir honeypots, observações duplicadas e sistemas que já receberam uma atualização.
Ainda assim, a contagem ilustra a superfície de ataque acessível. Quando o conhecimento técnico se dissemina, invasores podem procurar gateways vulneráveis muito mais rapidamente do que muitas empresas conseguem programar manutenção. Portanto, um appliance exposto enfrenta risco tanto do operador original quanto de imitadores posteriores.
É por isso que a CISA usou a palavra “imediatamente”. Os ciclos normais mensais de patches pressupõem que os defensores têm tempo para testar, programar e implantar uma atualização. A exploração confirmada de zero-day elimina essa premissa.
Ainda assim, atualizar é apenas a primeira decisão. A campanha observada começou antes da divulgação pública e teve como alvo um appliance que executava a versão mais recente disponível. Portanto, cada organização afetada deve perguntar quando a exposição começou, não apenas quando seu patch foi instalado.
Os invasores obtiveram acesso root sem fazer login
O exploit funcionou porque três fraquezas formaram uma cadeia, transformando uma solicitação pública de login em execução de comandos no nível root.
A Volexity descobriu a atividade durante uma investigação iniciada em 5 de outubro. Seus pesquisadores rastrearam o comportamento suspeito até um appliance Ivanti Connect Secure executando a versão 22.8R2.4, Build 19097. Essa versão estava totalmente atualizada na época.
A empresa encontrou exploração datada de 3 de outubro. Outro provedor de inteligência de ameaças teria observado sinais relacionados a partir de 1º de outubro. A divulgação pública e as correções chegaram em 13 de outubro, deixando um período significativo de exposição desconhecida.
A Volexity rastreia o operador não identificado como UTA0576. Esse rótulo identifica um agrupamento de atividade, não uma organização confirmada ou um patrocinador governamental. A empresa avaliou, com baixa confiança, que a operação observada teve motivação criminosa, e não espionagem.
A primeira etapa abusou do roteamento de solicitações em torno de welcome.cgi, um componente público que atende a página de login do appliance. Os invasores forneceram outro caminho no cabeçalho X-DSCGI-PATH. O appliance verificava a URL pública quanto à autorização, mas usava o cabeçalho para selecionar o destino.
Essa divergência encaminhava uma solicitação não autenticada para wu.cgi, um manipulador de upload protegido. O resultado foi um bypass de autenticação. Um componente que deveria ficar atrás dos controles de login tornou-se acessível por meio de uma solicitação pública.
A segunda etapa explorou uma breve condição de corrida no tratamento de arquivos. Uma condição de corrida ocorre quando a segurança depende de qual de duas operações termina primeiro. Neste caso, o manipulador de upload gravava um arquivo fornecido antes de verificar se ele era um arquivo ZIP válido.
O invasor enviou um script Perl com extensão .zip. O manipulador eventualmente rejeitava e excluía o arquivo inválido. No entanto, o arquivo existia brevemente no disco antes da exclusão.
A UTA0576 enviou solicitações paralelas que tentavam executar o arquivo temporário durante essa janela. Repetir essas solicitações aumentava a chance de que uma chegasse antes da limpeza. A sincronização bem-sucedida produzia execução de código sob a conta restrita cgi-server.
A Ivanti agrupou as etapas de bypass de autenticação e execução remota de código sob a CVE-2026-104935. Suas versões de 13 de outubro corrigem essas partes da cadeia. A terceira etapa, que elevava o acesso a root, está sendo tratada separadamente.
Para escalonamento de privilégios, o operador manipulou a forma como um serviço de segundo plano privilegiado confiava em dados de configuração. O exploit modificou uma biblioteca da Ivanti na memória do processo. Em seguida, redirecionou uma tarefa legítima de manutenção para um script Perl malicioso.
O serviço privilegiado executou esse script como root. O acesso root dá a um operador o mais alto controle prático sobre o appliance subjacente. O exploit verificava seu sucesso testando se conseguia ler /etc/shadow, que armazena informações protegidas de senhas em sistemas Linux.
Em seguida, o operador restaurou a configuração alterada e a instrução de memória. Também removeu entradas selecionadas dos logs de depuração da Ivanti e dos logs de auditoria do Linux. Essas ações reduziram as evidências deixadas após cada comando.
A reconstrução técnica completa mostra que o ataque não foi uma única solicitação com uma carga permanente. O operador executava novamente a cadeia de exploração sempre que precisava de outro comando.
Esse método é trabalhoso, mas oferece uma vantagem defensiva ao invasor. Os investigadores não encontraram uma backdoor de primeiro estágio nem um web shell convencional no appliance comprometido. Os comandos e suas saídas trafegavam pelas solicitações HTTPS do exploit.
Alguns estágios da carga existiam apenas na memória. Um estágio descompactava um script Python comprimido e codificado em Base64 e o executava sem preservar o script bruto no disco. A execução apenas em memória limita o que varreduras comuns baseadas em arquivos podem recuperar posteriormente.
A Volexity afirmou que a cadeia também evitava a Integrity Checker Tool da Ivanti. Essa ferramenta procura alterações inesperadas em arquivos, mas o ataque alterava temporariamente dados de memória e configuração. O exploit restaurava essas alterações após obter acesso root.
Essa distinção é importante para todas as organizações afetadas. Uma verificação de integridade que não retorna modificações inesperadas em arquivos não prova que a exploração nunca ocorreu. Ela apenas responde à questão mais restrita para a qual a ferramenta foi projetada.
Roubo de credenciais transformou a VPN em ponto de partida
A UTA0576 usou o gateway comprometido para acessar dados de identidade, transformando uma falha no appliance em um problema mais amplo de acesso corporativo.
A atividade pós-exploração do operador concentrou-se em credenciais, informações de diretório, reconhecimento de rede e remoção de dados. Essas ações sugerem preparação para movimentação além do appliance de VPN. A Volexity afirmou que a campanha foi interrompida antes que o objetivo final do invasor se tornasse claro.
O Active Directory foi um alvo principal. O Active Directory é o serviço de diretório da Microsoft para gerenciar identidades corporativas, computadores, permissões e autenticação. Um appliance de VPN frequentemente se conecta a ele por meio de uma conta de serviço para que usuários remotos possam ser verificados.
A UTA0576 usou o acesso do appliance para consultar um controlador de domínio interno. Os investigadores recuperaram uma ferramenta LDAP personalizada e scripts Python relacionados. LDAP é um protocolo usado para pesquisar e gerenciar informações de diretório.
O operador procurou diversos tipos valiosos de dados:
Credenciais do Local Administrator Password Solution
Informações de recuperação do BitLocker
Atributos que contêm valores de senha armazenados
Metadados de contas de usuário e caminhos de scripts de logon
Nomes de usuário válidos encontrados em registros de autenticação
O Local Administrator Password Solution, ou LAPS, gerencia senhas de administrador local para dispositivos Windows. As informações de recuperação do BitLocker podem desbloquear unidades Windows criptografadas. O roubo de qualquer um deles pode ampliar o acesso muito depois de a VPN vulnerável ter recebido patches.
O invasor comprimiu e codificou os resultados de diretório antes de movê-los pelo canal do exploit. A Volexity avaliou com alta confiança que o operador exfiltrou informações disponíveis por meio das consultas direcionadas ao Active Directory.
A UTA0576 também examinou capturas de pacotes armazenadas no appliance. O operador executou um analisador projetado para encontrar credenciais e material para quebra de senhas dentro do tráfego de rede registrado. Seus alvos incluíam credenciais LDAP em texto simples, credenciais de HTTP Basic Authentication e hashes de desafio-resposta NTLM.
Hashes NTLM podem permitir ataques offline a senhas ou outras técnicas de abuso de credenciais. O risco depende da configuração da organização, da qualidade das senhas e dos controles de autenticação. Sua coleta ainda cria uma carga de remediação que vai além da atualização de um único dispositivo.
Investigadores encontraram um utilitário de captura de pacotes renomeado sendo executado a partir de um diretório oculto. Ele filtrava tráfego associado a protocolos em texto simples, incluindo LDAP, HTTP, FTP e Telnet. Oito arquivos de captura rotativos limitavam o armazenamento enquanto substituíam continuamente o tráfego mais antigo.
A campanha também incluiu consultas DNS internas e reconhecimento de nomes de host. O operador usou um script auxiliar para ataques de password spraying contra contas do Active Directory. O password spraying testa um pequeno conjunto de senhas prováveis em várias contas para evitar falhas repetidas contra um mesmo nome de usuário.
Essas atividades mostram por que um appliance de borda pode se tornar uma posição valiosa de inteligência. Ele processa fluxos de autenticação e vê tráfego de rede que endpoints comuns talvez nunca recebam. Comprometê-lo fornece tanto um ponto de entrada quanto uma plataforma para observar relacionamentos internos.
O operador observado também pesquisou diretórios de configuração de VPN e logs de autenticação. Esses registros podem revelar métodos de autenticação, nomes de usuário, domínios internos e serviços conectados. Até pesquisas malsucedidas podem ajudar um invasor a mapear a próxima etapa.
Essa é a inversão central do alerta da CISA. As organizações compram um gateway de acesso remoto para impor limites de identidade. Neste incidente, o gateway tornou-se uma rota para contornar a autenticação e, depois, uma fonte de material adicional de autenticação.
Esse risco não se limita às contas locais do appliance. Os administradores devem considerar cada segredo que o dispositivo armazenou, transmitiu, capturou ou poderia acessar por meio de uma conta de serviço integrada. O escopo relevante pode incluir credenciais de diretório, chaves de recuperação, tokens e senhas de usuários.
A rotação de credenciais deve seguir as evidências e a arquitetura. Redefinir todas as contas sem um plano pode interromper as operações e, ao mesmo tempo, deixar passar credenciais de serviço menos visíveis. As equipes devem identificar as integrações do appliance e priorizar segredos com acesso privilegiado ou reutilizável.
As organizações também devem revisar a atividade originada no gateway. Uma exploração bem-sucedida pode fazer com que conexões maliciosas pareçam vir de um dispositivo de rede confiável. Sistemas posteriores podem tratar essas conexões de maneira diferente do tráfego comum da internet.
A Volexity encontrou indícios de preparação para movimento lateral, isto é, a passagem do dispositivo inicial para outros sistemas. Ela não afirmou que todas as técnicas observadas foram bem-sucedidas. Também não determinou o objetivo final do operador.
Essa incerteza deve limitar as conclusões, não atrasar a contenção. Os defensores têm evidências verificadas de roubo de credenciais e exfiltração de dados em pelo menos um ambiente investigado. Eles devem evitar supor que um appliance atualizado elimina todas as consequências de um acesso anterior.
A aplicação de patches fecha o ponto de entrada, não a investigação
O principal conflito agora é entre aplicar patches e obter provas: instalar software corrigido é necessário, mas não pode estabelecer se uma exploração anterior foi bem-sucedida.
A Ivanti aconselha os clientes a atualizar imediatamente e executar regularmente sua Integrity Checker Tool. Essas medidas reduzem a exposição e podem identificar algumas formas de adulteração. Elas não abrangem todas as técnicas documentadas neste incidente.
A Volexity descobriu que o operador excluiu entradas selecionadas de logs e reverteu alterações temporárias. O invasor também removeu scripts e resultados de execução após utilizá-los. Vários componentes importantes foram executados apenas na memória.
Esse comportamento antiforense altera o valor de uma verificação limpa. Um resultado esperado pode significar que o appliance está limpo. Também pode significar que o invasor evitou os artefatos medidos pela ferramenta selecionada.
A análise de resposta da Rapid7 recomenda, portanto, procurar indícios de comprometimento após aplicar a atualização. Organizações que identificarem atividade suspeita devem seguir as orientações de recuperação da Ivanti e preservar evidências úteis.
A telemetria de rede pode fornecer pistas quando os logs do appliance não conseguem. A Volexity recomenda procurar volumes incomuns de solicitações para o caminho público welcome.cgi. Os defensores também podem examinar incompatibilidades entre a URL solicitada e o cabeçalho X-DSCGI-PATH.
Esses indicadores são valiosos, mas não completos. Os invasores podem adaptar caminhos, horários, infraestrutura e comandos pós-exploração. A ausência de um padrão publicado nunca deve se tornar um teste universal de liberação.
A aquisição de memória pode expor artefatos voláteis que verificações de disco não detectam. No entanto, coletar memória de um gateway de produção exige procedimentos e conhecimento adequados. Uma reinicialização ou reconstrução descuidada pode destruir evidências necessárias para compreender o incidente.
Isso cria uma compensação operacional. As equipes querem remover rapidamente o dispositivo vulnerável de serviço. Os investigadores querem preservar estado suficiente para determinar o que aconteceu e quais credenciais exigem substituição.
A sequência correta depende da exposição, das necessidades do negócio, da redundância e do suporte forense disponível. As organizações devem envolver equipes de resposta a incidentes cedo quando encontrarem indicadores ou conexões inexplicadas provenientes do appliance. Devem documentar cada ação de contenção e seu horário.
Uma resposta defensável geralmente separa quatro perguntas:
A versão instalada é vulnerável?
O appliance estava acessível durante a janela de exploração?
Há evidências de tentativa ou de exploração bem-sucedida?
Quais sistemas e credenciais estavam acessíveis após o comprometimento?
A aplicação de patches responde apenas à primeira pergunta. Registros de exposição, logs de rede, evidências de memória, logs de identidade e telemetria de sistemas posteriores abordam as demais. Tratar essas perguntas como intercambiáveis cria uma falsa sensação de segurança.
A vulnerabilidade de escalonamento de privilégios ainda não resolvida acrescenta outra complicação. A Ivanti corrigiu os componentes de desvio de autenticação e execução remota de código em 13 de outubro. A Volexity afirmou que a Ivanti planejava uma versão posterior para a falha separada de escalonamento de privilégios.
Isso não significa que a cadeia documentada permaneça utilizável após as correções de outubro. Fechar suas etapas de entrada não autenticada e execução deve interromper essa rota específica. Ainda assim, os administradores devem acompanhar a versão adicional e instalá-la quando a Ivanti a disponibilizar.
As organizações também precisam verificar se as atualizações foram realmente concluídas. Clusters de appliances, nós em espera, sistemas de recuperação de desastres e gateways de teste esquecidos podem permanecer vulneráveis após a alteração do dispositivo principal. Os registros de ativos devem ser comparados com dados reais de versão.
A descoberta externa pode ajudar a revelar exposição não gerenciada. O painel de exposição da Shadowserver oferece uma visão externa, mas nenhum conjunto de dados externo fornece um inventário perfeito. Registros internos de propriedade continuam sendo essenciais.
Uma resposta completa deve incluir controles de identidade. As equipes devem examinar padrões de autenticação, uso de contas de serviço, consultas privilegiadas a diretórios, sinais de password spraying e acesso incomum a chaves de recuperação. Segredos relevantes devem ser rotacionados depois que as equipes entenderem suas dependências.
Os sistemas posteriores merecem revisão separada. Conexões do appliance de VPN podem ter herdado confiança ou contornado controles aplicados a clientes comuns. Os investigadores devem identificar tráfego incomum originado no gateway durante a janela suspeita.
A conclusão mais segura também é a menos conveniente: não existe um único botão de “tudo certo” para este incidente. Software corrigido, resultados limpos de integridade e ausência de indicadores publicados fornecem evidências. Nenhum deles prova, de forma independente, que um dispositivo nunca foi comprometido.
Os zero-days anteriores da Ivanti aumentam a pressão
CVE-2026-104935 surge após explorações repetidas de produtos de borda, portanto os clientes estão avaliando a maturidade da resposta, além de um único patch.
O Ivanti Connect Secure enfrentou diversas vulnerabilidades graves exploradas ativamente nos últimos anos. No início de 2024, invasores encadearam CVE-2023-46805 com CVE-2024-21887. Essa combinação fornecia desvio de autenticação e injeção de comandos contra gateways expostos à internet.
A CISA respondeu de forma agressiva durante esse episódio. Agências federais receberam instruções para aplicar mitigações, executar verificações de integridade e, por fim, desconectar dispositivos afetados sob condições específicas. Análises posteriores alertaram que invasores poderiam manter o acesso apesar de algumas ações de recuperação.
Em janeiro de 2025, a Ivanti divulgou a exploração ativa da CVE-2025-0282, um estouro de buffer baseado em pilha que afetava o Connect Secure. Mais tarde naquele ano, outra falha do Connect Secure, CVE-2025-22457, foi vinculada à exploração por um grupo de espionagem associado à China.
O novo incidente não prova que todos os appliances da Ivanti estejam comprometidos ou sejam exclusivamente inseguros. Produtos corporativos de borda de vários fornecedores atraem pesquisa intensiva e interesse contínuo de invasores. Sua posição torna uma exploração bem-sucedida especialmente valiosa.
A Volexity fez uma comparação direta com a exploração recente de appliances SonicWall Secure Mobile Access. Em ambos os casos, invasores com acesso root inspecionaram capturas de pacotes para recuperar credenciais. A sobreposição sugere uma estratégia mais ampla contra sistemas confiáveis de borda de rede.
Gateways de VPN compartilham várias características que favorecem invasores. Eles são acessíveis pela internet, muitas vezes operam continuamente e se conectam diretamente à infraestrutura de identidade. Também executam ambientes operacionais especializados que muitos produtos de segurança de endpoint não conseguem monitorar normalmente.
Uma estação de trabalho pode ter detecção de endpoint, controles de aplicações e telemetria detalhada de processos. Um appliance de segurança costuma expor menos ferramentas de investigação ao seu proprietário. Invasores podem explorar essa lacuna de visibilidade enquanto operam a partir de uma posição de rede altamente confiável.
O padrão repetido pressiona tanto fornecedores quanto clientes. Os fornecedores devem encurtar o período entre descobrir uma falha parcial e proteger todas as ramificações compatíveis. Os clientes devem reduzir a dependência de avisos de emergência como seu principal mecanismo de detecção.
A Ivanti afirmou que parte da CVE-2026-104935 foi descoberta por meio de seu programa de segurança de produtos. Esse componente foi corrigido na versão de julho de 2026 da versão 25.1.3.0. A exploração ocorreu enquanto a empresa retroportava a correção para outras versões compatíveis.
Essa cronologia merece escrutínio, mas não sustenta uma acusação simples. Retroportar alterações de segurança entre ramificações de versões pode exigir engenharia e testes de compatibilidade. Os detalhes públicos não estabelecem quando a Ivanti compreendeu a cadeia completa de exploração ou seu uso no mundo real.
O resultado ainda expôs uma lacuna de patch. Alguns clientes em outras ramificações compatíveis permaneceram vulneráveis depois que uma ramificação recebeu uma correção relevante. Invasores atuaram durante esse intervalo e comprometeram uma versão considerada atual para sua linha.
Isso levanta uma questão prática de aquisição. Compradores devem perguntar como os fornecedores propagam correções de segurança entre ramificações compatíveis. Também devem perguntar se as orientações de detecção chegam junto com a correção e como os appliances preservam evidências forenses.
Os clientes podem reduzir a exposição futura sem esperar outro aviso. Podem minimizar a acessibilidade direta pela internet, restringir interfaces administrativas e monitorar tráfego originado no gateway. Também podem centralizar logs para que um invasor não consiga apagar todos os registros úteis localmente.
A segmentação também importa. Um appliance de acesso remoto não deve receber acesso irrestrito apenas por desempenhar uma função confiável. Suas contas de serviço devem ter apenas as permissões necessárias, enquanto protocolos de autenticação em texto simples devem ser removidos sempre que possível.
Essas medidas não eliminam o risco de vulnerabilidades zero-day. Elas limitam o valor que os invasores obtêm depois que um dispositivo falha. A lição recorrente de incidentes envolvendo Ivanti, SonicWall, Citrix e outros sistemas de borda é que os appliances de perímetro também precisam de contenção interna.
Portanto, a pressão sobre a Ivanti irá além do lançamento de atualizações. Os clientes acompanharão a rapidez com que a correção restante para escalonamento de privilégios será disponibilizada. Também avaliarão se as novas versões aprimoram a coleta de evidências e resistem a adulterações feitas apenas na memória.
Três Sinais Mostrarão se a Resposta Funcionou
A próxima fase depende do crescimento da exploração, da correção restante da Ivanti e de evidências de comprometimento além dos ambientes inicialmente investigados.
O primeiro sinal é se as varreduras e explorações se expandem após a divulgação pública. Os detalhes técnicos já estão disponíveis, embora a Volexity tenha retido código de exploração funcional. Outros atores ainda podem estudar a falha de roteamento, reproduzir a condição de corrida e desenvolver sua própria implementação.
Um aumento acentuado em solicitações envolvendo welcome.cgi ou valores suspeitos de X-DSCGI-PATH reforçaria a necessidade de contenção emergencial. Relatos de empresas de resposta a incidentes mostrarão se o UTA0576 permaneceu como o principal operador ou se tornou apenas um entre muitos.
O segundo sinal é a correção prometida pela Ivanti para a vulnerabilidade separada de escalonamento de privilégios. Os administradores devem acompanhar o aviso da empresa, as notas de versão e as orientações sobre versões compatíveis. Eles devem verificar todos os nós ativos e em espera após a implantação.
Uma disponibilização oportuna eliminaria outra rota local de escalonamento documentada na cadeia. Um atraso deixaria os clientes lidando com incertezas adicionais, mesmo depois de o CVE-2026-104935 ter sido corrigido.
O terceiro sinal é a descoberta de comprometimento subsequente. Novos relatos envolvendo credenciais de diretório roubadas, acesso não autorizado à recuperação do BitLocker ou movimentação lateral ampliariam o impacto conhecido do incidente. Também confirmariam que uma remediação focada apenas no appliance foi excessivamente limitada.
As organizações não devem esperar por esses relatos antes de verificar seus próprios ambientes. O operador observado buscou segredos de identidade imediatamente após obter acesso root. Esse comportamento define o escopo mínimo de investigação para sistemas expostos.
Os defensores devem preservar logs de gateway, firewall, identidade, DNS e diretório que cubram toda a janela de exposição. Devem procurar conexões originadas no appliance que não correspondam ao comportamento normal de acesso remoto. Contas de serviço relevantes e segredos reutilizáveis exigem atenção especial.
A vulnerabilidade no Ivanti Connect Secure também oferece um teste mais amplo para os programas de gestão de vulnerabilidades. A velocidade de inventário importa tanto quanto a velocidade de aplicação de correções. Uma organização não consegue proteger um gateway em espera, um dispositivo de laboratório esquecido ou um appliance herdado que ninguém possui.
O alerta da CISA deve, portanto, acionar um fluxo de trabalho coordenado. Operações de segurança, engenharia de rede, equipes de identidade e equipes de resposta a incidentes precisam trabalhar com a mesma linha do tempo e a mesma lista de ativos. Cada equipe enxerga uma parte diferente do caminho do ataque.
A aplicação de correções continua sendo urgente, mas é apenas o primeiro movimento. A pergunta mais importante é se sua organização consegue provar o que o appliance acessou antes da chegada da correção. Revise o aviso, confirme todas as versões implantadas, preserve as evidências e investigue agora atividades originadas no gateway. Se o dispositivo tinha acesso a dados valiosos de identidade, vocês estão tratando isso como manutenção de rotina ou como uma possível violação?
