Ivanti Epmm: 83% dos ataques vieram de um único Ip em hospedagem bulletproof

83% das tentativas de exploração do Ivanti EPMM partiram de um único IP em hospedagem “bulletproof”

Uma campanha intensa de ataques contra o Ivanti Endpoint Manager Mobile (EPMM) vem sendo conduzida, em sua esmagadora maioria, a partir de um único endereço IP ligado a uma infraestrutura de “bulletproof hosting” operada pela empresa PROSPERO. De acordo com dados da GreyNoise, entre 1º e 9 de fevereiro de 2026 foram observadas 417 sessões de exploração originadas de apenas oito endereços distintos. Deste total, 346 sessões – cerca de 83% de toda a atividade maliciosa – saíram do IP 193.24.123[.]42, evidenciando o papel central desse host na campanha.

O foco dos atacantes é a vulnerabilidade crítica CVE-2026-1281, com pontuação 9.8 no CVSS, que permite execução remota de código sem necessidade de autenticação em instâncias vulneráveis do EPMM. Essa falha é uma das duas vulnerabilidades graves que afetam o produto, ao lado da CVE-2026-1340, ambas permitindo que invasores assumam o controle de servidores expostos à internet. A própria Ivanti já havia reconhecido que as brechas estavam sendo exploradas em cenário de zero-day, atingindo inicialmente um conjunto limitado de clientes antes da disponibilidade dos patches.

Desde então, o impacto se ampliou e passou a envolver órgãos governamentais e instituições estratégicas na Europa. Entidades como a Autoridade Holandesa de Proteção de Dados, o Conselho para o Judiciário da Holanda, a Comissão Europeia e a agência governamental finlandesa Valtori reportaram ter sido visadas ou afetadas pelas vulnerabilidades no EPMM. Isso reforça a relevância do produto como alvo: por ser um componente central de gerenciamento de dispositivos móveis (MDM), qualquer comprometimento afeta potencialmente toda a cadeia de endpoints corporativos.

A análise do tráfego malicioso mostra que o mesmo IP envolvido na exploração do Ivanti EPMM estava, em paralelo, atacando pelo menos outras três vulnerabilidades em softwares distintos: CVE-2026-21962 em servidores Oracle WebLogic, CVE-2026-24061 no telnetd do pacote GNU InetUtils e CVE-2025-24799 em instâncias do GLPI. Esse comportamento indica o uso de uma infraestrutura única para varrer a internet em busca de múltiplas superfícies de ataque, priorizando falhas críticas com alto potencial de comprometimento.

Outro dado relevante é a forma como o host se disfarçava. Os pesquisadores identificaram o uso de mais de 300 user-agents diferentes durante as tentativas de exploração, imitando navegadores como Chrome, Firefox e Safari em diversos sistemas operacionais. Esse padrão é típico de frameworks automatizados de varredura em larga escala, que alternam user-agents para dificultar detecção baseada em assinaturas simples e burlar regras básicas de filtro em WAFs e proxies.

A infraestrutura de origem está associada à PROSPERO, vinculada ao sistema autônomo Proton66. Esse AS já havia sido previamente relacionado à difusão de diferentes famílias de malware, incluindo GootLoader, Matanbuchus, SpyNote e SocGholish. Em geral, provedores classificados como “bulletproof hosting” oferecem hospedagem tolerante a abusos, respondem lentamente ou de forma ineficaz a notificações de incidente e, em alguns casos, atuam deliberadamente para proteger a operação de grupos criminosos.

Um dos elementos mais preocupantes dessa campanha foi a identificação do que os analistas classificaram como “sleeper shell”: um carregador Java injetado em memória nas instâncias comprometidas do EPMM, posicionado no caminho “/mifs/403.jsp”. Em vez de instalar de imediato ransomwares ou trojans completos, o atacante implanta um componente leve, capaz de receber comandos futuros ou carregar módulos adicionais sob demanda, mantendo um acesso persistente e discreto ao ambiente.

O comportamento observado combina vários sinais típicos da atuação de “initial access brokers” (IABs) – grupos especializados em comprometer sistemas, validá-los e, posteriormente, vender esse acesso inicial para outros atores maliciosos. De acordo com a GreyNoise, cerca de 85% das sessões registradas se limitaram a realizar callbacks DNS para conferir se os alvos eram vulneráveis, sem instalar imediatamente payloads mais agressivos. Foram usadas técnicas de OAST (Out-of-Band Application Security Testing) para confirmar a exploração por meio de respostas DNS externas, o que sinaliza uma fase de catalogação de ativos comprometidos antes da monetização.

Na prática, isso significa que muitos ambientes podem já estar marcados em “estoque” em mercados clandestinos de acesso inicial, aguardando compra por grupos de ransomware, operadores de espionagem ou outros tipos de cibercriminosos. Em vários incidentes recentes, grandes ataques de ransomware começaram justamente a partir de acessos adquiridos de IABs que exploraram falhas em soluções de VPN, MDM, firewalls ou sistemas de gestão remota.

Diante desse cenário, a Ivanti tem recomendado um conjunto de medidas urgentes para seus clientes. Em primeiro lugar, aplicar imediatamente todos os patches de segurança liberados para o EPMM, com prioridade máxima para servidores expostos à internet. Em seguida, revisar cuidadosamente os logs de DNS em busca de callbacks suspeitos relacionados a tentativas de exploração das vulnerabilidades CVE-2026-1281 e CVE-2026-1340, bem como monitorar qualquer acesso ao caminho “/mifs/403.jsp”, que pode indicar presença de backdoors ou loaders em memória.

Outra ação sugerida é o bloqueio do sistema autônomo AS200593, vinculado à PROSPERO, no perímetro de rede, sempre que possível. Embora bloqueios por AS não sejam uma solução definitiva – já que criminosos podem rapidamente migrar para outros provedores – essa medida reduz a exposição a campanhas específicas conhecidamente maliciosas e força os atacantes a reestruturarem sua infraestrutura.

Especialistas em resposta a incidentes alertam que um comprometimento de EPMM vai muito além de um único servidor vulnerável. Como o produto é usado para gerenciar e controlar dispositivos móveis corporativos, invadir essa camada abre caminho para comandar, espionar ou distribuir malware para uma grande base de smartphones, tablets e outros endpoints móveis. A partir daí, torna-se mais viável realizar movimentação lateral, contornar segmentações de rede tradicionais e atacar aplicações internas que, em tese, não estariam diretamente expostas à internet.

Para organizações que utilizam EPMM ou soluções similares, a recomendação é tratar essas plataformas como ativos de alta criticidade, no mesmo nível de controladores de domínio ou sistemas de autenticação. Isso implica segmentar o acesso, restringir quem pode administrar o produto, aplicar configuração de “least privilege”, integrar logs de EPMM ao SIEM corporativo e acompanhar alertas de forma contínua. Apenas instalar o patch não é suficiente quando já existe a suspeita de exploração prévia: é necessário realizar hunting ativo por indicadores de comprometimento.

Entre as medidas complementares sugeridas por profissionais de segurança, destacam-se: revisão de regras de firewall e WAF que protegem o EPMM; análise de logs HTTP em busca de requisições incomuns para “/mifs/403.jsp” ou outros caminhos suspeitos; verificação de alterações inesperadas em configurações administrativas; e monitoramento de comandos incomuns executados sobre dispositivos gerenciados. Caso sejam encontrados indícios de backdoors ou loaders, recomenda-se considerar o ambiente como potencialmente comprometido em profundidade, acionando um plano formal de resposta a incidentes.

Outro ponto importante é a gestão de exposição externa. Muitas empresas mantêm painéis de administração e consoles de gerenciamento diretamente acessíveis pela internet por conveniência operacional, reduzindo camadas de proteção. Em se tratando de soluções de MDM e EMM, o ideal é publicar apenas os serviços estritamente necessários ao funcionamento dos dispositivos e, sempre que viável, proteger acessos administrativos por meio de VPN, autenticação forte e controles adicionais como MFA e listas de IP permitidos.

A campanha contra o Ivanti EPMM também reforça uma tendência clara no ecossistema de ameaças: vulnerabilidades críticas em softwares voltados à infraestrutura corporativa são exploradas em questão de horas após a divulgação pública. O intervalo entre o anúncio de uma falha, a liberação do patch e a exploração em massa tem diminuído ano após ano. Para equipes de TI e segurança, isso significa que a janela de atualização segura é mínima, exigindo processos de gestão de vulnerabilidades mais ágeis, com priorização baseada em exposição à internet e criticidade do ativo.

Do ponto de vista estratégico, o caso evidencia a importância de combinar correções técnicas com inteligência de ameaças. Não basta saber que uma vulnerabilidade existe: é fundamental acompanhar quem a está explorando, de onde partem as tentativas, quais técnicas são usadas para evasão, e se há indícios de atuação de brokers de acesso inicial. Essas informações permitem ajustar regras de detecção, alimentar sistemas de bloqueio e orientar investigações proativas antes que o ataque chegue à fase de criptografia de dados ou exfiltração massiva.

Para as organizações brasileiras, o episódio serve como alerta direto. Mesmo que os incidentes noticiados até agora envolvam principalmente órgãos europeus, a infraestrutura utilizada pelos atacantes não conhece fronteiras geográficas. Qualquer EPMM ou solução similar exposta globalmente, sem patch e sem monitoramento adequado, pode entrar na mira dos mesmos IPs, ferramentas e campanhas automatizadas. Em um cenário de ataque em escala, o que determina se uma empresa será vítima ou não é, muitas vezes, apenas a rapidez e a maturidade de sua resposta.

Em síntese, a concentração de 83% das tentativas de exploração em um único IP de hospedagem “bulletproof”, aliada ao uso de sleeper shells, callbacks DNS e exploração paralela de outras vulnerabilidades críticas, revela uma operação bem estruturada de mapeamento e venda de acessos. Para reduzir o risco, é indispensável combinar atualização imediata de patches, endurecimento da superfície de ataque, monitoração de indicadores específicos – como o acesso ao caminho “/mifs/403.jsp” – e uma postura de segurança que trate soluções de MDM como pilares centrais da defesa corporativa, e não apenas ferramentas de conveniência operacional.