Um único IP impulsiona a exploração de Ivanti EPMM: vulnerabilidades RCE, bots automatizados e urgência de adesivo

A análise de inteligência sobre ameaças detectou uma campanha concentrada contra Ivanti Endpoint Manager Mobile (EPMM) na qual um único actor parece estar atrás da maior parte das explorações activas de duas falhas críticas identificadas na plataforma. Essas vulnerabilidades, catalogadas nos relatórios como CVE-2026-21962 e CVE-2026-24061, permitem a injeção de código sem necessidade de autenticação e, portanto, podem desembocar na execução remota do código (RCE) sobre sistemas expostos, o que as torna vetores extremamente perigosos se não forem rapidamente atenuados.

A empresa de inteligência da Internet GreyNoise publicou um acompanhamento detalhado da atividade observada entre 1 e 9 de fevereiro: durante esse período, escolheram 417 sessões de tentativa de exploração que vinham de apenas oito endereços IP diferentes, e onde se aprecia um padrão muito claro de automação e foco nos erros mencionados. Você pode ler o relatório de GreyNoise aqui: http://www.greynoise.io/blog/active-ivanti-exploitation.

O mais marcante do trabalho de GreyNoise é que um único endereço IP —193[.]24[.]123[.]42, hospedado no sistema autônomo PROSPERO OOO (AS200593) — concentra mais de 83% do volume total de sessões de exploração detectadas. Censys e outros analistas têm qualificado o AS como de natureza “bulletproof”, ou seja, infra-estruturas tolerantes a abusos, habitualmente utilizadas para operações maliciosas que buscam evitar bloqueios ou retiradas rápidas de recursos por parte de fornecedores legítimos. Para contextos como este convém consultar plataformas de busca de hosts e ASN como Censys Para obter mais sinais sobre a infraestrutura implicada.

A atividade observada mostra picos pontuais muito intensos: em 8 de fevereiro foram registradas 269 sessões em uma única jornada, quase treze vezes mais do que a média diária de cerca de 22 sessões que se veem no resto do período analisado. Além disso, a campanha parece estar totalmente automatizada, com rotações de até trezentos agentes de usuário diferentes para ocultar ou diversificar os pedidos e dificultar a identificação por padrões simples.

Um dado que sugere objetivos comerciais no ataque é que 85% das sessões (354 das 417 registradas) empregaram callbacks DNS em estilo OAST para verificar se o código remoto foi executado corretamente. Esse comportamento é típico de atores que buscam validar acessos iniciais e depois vendê-los ou reutilizá-los, o que se encaixa com a atividade de corretor de acesso inicial.

Em paralelo, os pesquisadores notam discrepâncias entre indicadores de compromisso (IoC) publicados em alguns relatórios e a telemetria observada: por exemplo, endereços ligados a serviços VPN comerciais, como faixas de Windscribe (185[.]212[.]171[.]0/24), apareceram em listados públicos mas na telemetria de GreyNoise esses IPs estavam digitalizando instâncias do Oracle WebLogic, sem evidência de exploração de Ivanti. Isto sublinha uma ideia prática para as equipas de defesa: bloquear apenas os IoC públicos pode deixar fora a fonte mais ativa da campanha, se esta não figura nessas listas.

Além das tentativas contra Ivanti EPMM, o mesmo IP atribuído ao ator explodiu simultaneamente outras vulnerabilidades em diferentes produtos - incluindo instâncias do Oracle WebLogic e GNU Inetutils Telnetd - e também se relacionou à exploração de CVE-2025-24799 em GLPI, segundo o seguimento. No caso do WebLogic, a maior parte da telemetria observada correspondeu precisamente a essa plataforma, com milhares de sessões registradas, o que mostra que um único ponto de origem pode digitalizar e explorar múltiplos objetivos de forma paralela.

Ivanti publicou um aviso de segurança com hotfixes imediatos e recomendações para mitigar as falhas no EPMM; a empresa anunciou também que lançará adesivos completos na versão 12.8.0.0 do EPMM no primeiro trimestre. Até que essa versão esteja disponível, Ivanti aconselha a aplicar versões RPM concretas segundo o ramo de EPMM que se esteja usando e, como medida mais conservadora, construir uma instância EPMM nova e migrar os dados lá. A nota de segurança oficial e as instruções do fornecedor estão aqui: Aviso de segurança de Ivanti e o guia de reconstrução está disponível aqui: Instruções para reconstruir o EPMM.

Para os responsáveis pela segurança e administradores que gerem EPMM, a conclusão é clara: aplicar as correcções fornecidas pelo fabricante sem demoras e, quando possível, seguir a recomendação mais cautelosa de migrar para uma instância reconstruída para eliminar qualquer rastro de compromisso anterior. Também convém ampliar as defesas para além de uma simples lista de IoC e monitorar comportamentos: detecção de callbacks DNS atípicos, picos de tráfego em portos e rotas próprias da plataforma, e alertas por padrões de user-agent incomuns são sinais úteis que podem antecipar tentativas de exploração automatizada.

A campanha deixa outra moral para a comunidade: os atacantes modernos combinam automação massiva, infraestrutura tolerante a abusos e técnicas de verificação remota para maximizar o desempenho das suas operações. Isso obriga a uma resposta defensiva igualmente técnica e proativa: adesivo ágil, segmentação de serviços expostos, e colaboração entre equipes de segurança e fornecedores para compartilhar telemetria real e não depender apenas de IoC divulgados publicamente.

Se você gerencia EPMM ou infraestrutura relacionada, verifique imediatamente as recomendações do fabricante e notas de inteligência pública, e prepara um plano de resposta que contemple reconstrução de instâncias e monitorização contínua. Para aprofundar os achados técnicos e os indicadores observados, revisa a análise de GreyNoise aqui: GreyNoise — Active Ivanti exploitation, e consulta as páginas de suporte de Ivanti para aplicar as correções sugeridas.