Falhas críticas CVE-2026-1281 e CVE-2026-1340 em infraestrutura MDM exposta vêm sendo usadas para validar alvos vulneráveis, com forte concentração de tráfego em 193.24.123[.]42.
| Componente | Ivanti Endpoint Manager Mobile, plataforma de gerenciamento de dispositivos móveis exposta à internet. |
| Vetor | Exploração remota não autenticada das falhas críticas CVE-2026-1281 e CVE-2026-1340, descritas como vulnerabilidades relacionadas de injeção de código em componentes distintos do EPMM. |
| Impacto | Execução remota de código sem autenticação e possibilidade de obtenção de posição inicial em infraestrutura MDM; parte relevante da atividade observada validou explorabilidade por DNS sem instalação imediata de malware. |
| Prioridade | Aplicar os patches do EPMM, auditar instâncias MDM expostas, revisar callbacks DNS com padrão OAST, monitorar o caminho /mifs/403.jsp e bloquear o AS200593 quando compatível com a política de rede. |
| Artefatos | 193.24.123[.]42 concentrou 346 de 417 sessões observadas entre 1 e 9 de fevereiro de 2026; o caminho /mifs/403.jsp foi associado a carregador Java em memória dormente. |
| Infraestrutura | O IP foi associado a infraestrutura bulletproof oferecida pela PROSPERO, vinculada por avaliação técnica ao ecossistema Proton66. |
A exploração recente contra o Ivanti Endpoint Manager Mobile mostra um padrão concentrado e automatizado de varredura e validação de alvos vulneráveis. Entre 1 e 9 de fevereiro de 2026, foram registradas 417 sessões de exploração vindas de oito IPs únicos. Desse total, 346 sessões partiram de 193.24.123[.]42, o que representa 83% da atividade observada. O endereço foi relacionado a infraestrutura de hospedagem bulletproof da PROSPERO, elemento relevante para defesa porque esse tipo de provedor costuma ser usado para manter operações abusivas resilientes a remoções, bloqueios e denúncias operacionais.
A atividade mira duas falhas críticas no Ivanti EPMM: CVE-2026-1281 e CVE-2026-1340. Ambas foram descritas como vulnerabilidades relacionadas de injeção de código em componentes diferentes do produto e podem permitir execução remota de código sem autenticação. A exploração já havia afetado um número limitado de clientes antes da correção, e várias entidades europeias informaram terem sido alvo por atores ainda não identificados. A principal leitura defensiva é que instâncias MDM expostas à internet devem ser tratadas como ativos de alto risco quando falhas críticas surgem, porque concentram controle administrativo sobre dispositivos corporativos.
O fluxo observado não se limita a tentativas isoladas contra um único produto. O mesmo host associado ao endereço 193.24.123[.]42 também explorava simultaneamente três outras CVEs em softwares não relacionados, sem que os identificadores dessas falhas tenham sido detalhados. Essa simultaneidade, combinada com a rotação por mais de 300 cadeias distintas de agente de usuário cobrindo Chrome, Firefox, Safari e variantes de sistemas operacionais, aponta para automação de exploração e mascaramento de fingerprinting básico. Para operações de detecção, isso significa que filtros simples baseados em user agent terão baixa confiabilidade se usados isoladamente.
Cerca de 85% das sessões observadas fizeram callbacks via DNS para confirmar que o alvo era explorável, sem evidência de implantação imediata de malware ou coleta de dados nesses casos. Esse comportamento é compatível com validação fora de banda, na qual o operador confirma que a requisição alcançou o ponto vulnerável e produziu efeito observável em infraestrutura controlada. A ausência de payload subsequente em grande parte das sessões não reduz a criticidade: ela indica que o objetivo inicial pode ser catalogar alvos, criar lista de oportunidades e reservar acesso para uso posterior por outro operador ou por uma cadeia de intrusão diferente.
Outro artefato técnico relevante é a campanha descrita como uso de um shell dormente em instâncias EPMM comprometidas, com carregador de classe Java em memória associado ao caminho /mifs/403.jsp. O ponto defensivo é a persistência potencial sem comportamento ruidoso imediato. Um carregador residente em memória pode existir como mecanismo de preparação para execução futura, dificultando a confirmação por varreduras superficiais de arquivos e exigindo correlação entre logs HTTP, comportamento do processo Java, alterações na aplicação e histórico de requisições ao caminho suspeito.
A superfície principal é composta por instâncias do Ivanti Endpoint Manager Mobile acessíveis pela internet, especialmente quando usadas como infraestrutura de MDM para grandes ambientes corporativos. Como o EPMM administra dispositivos móveis e políticas de acesso, a exposição de sua interface vulnerável cria risco maior do que uma aplicação periférica comum. O comprometimento do servidor de gerenciamento pode oferecer ao invasor uma posição privilegiada para observar, alterar ou preparar ações relacionadas à gestão de dispositivos, mesmo que a atividade descrita tenha se concentrado em validação de explorabilidade e acesso inicial.
A exposição também atinge organizações que mantêm MDM, concentradores de VPN e outras tecnologias de acesso remoto diretamente acessíveis. O padrão relatado mostra que vulnerabilidades críticas nesses componentes recebem exploração poucas horas ou dias após divulgação e disponibilização de detalhes suficientes para automação. A presença de infraestrutura PROSPERO e a associação avaliada com Proton66 ampliam o interesse defensivo, pois esse ecossistema já foi relacionado à distribuição de famílias como GootLoader, Matanbuchus, SpyNote, Coper, também conhecido como Octo, e SocGholish. Essa relação não prova que essas famílias foram usadas no caso do EPMM, mas reforça a necessidade de monitorar o mesmo perímetro para estágios posteriores.
- Instâncias Ivanti EPMM expostas à internet e ainda sem correção para
CVE-2026-1281eCVE-2026-1340. - Ambientes MDM que aceitam tráfego externo sem segmentação, inspeção ou política de bloqueio para infraestrutura de alto risco.
- Servidores EPMM com requisições ao caminho
/mifs/403.jspou histórico de callbacks DNS de validação OAST. - Perímetros que observem tráfego vindo de
193.24.123[.]42ou de blocos associados ao AS200593.
A investigação deve começar pela reconstrução temporal das requisições recebidas pelo EPMM no período próximo à divulgação e antes da aplicação dos patches. Logs HTTP, reverse proxies, WAFs, balanceadores e telemetria do próprio appliance devem ser correlacionados por origem, rota, método, código de resposta, tamanho de resposta e variações de user agent. Como a automação observada alterna muitas cadeias de agente de usuário, a correlação por IP, ASN, padrão de rota e sequência de tentativas tende a ser mais útil do que qualquer assinatura isolada de navegador.
A telemetria DNS é particularmente importante porque a maior parte das sessões observadas usou callbacks para confirmar explorabilidade. A defesa deve procurar consultas incomuns originadas do servidor EPMM ou de componentes próximos, especialmente domínios com padrão de teste fora de banda, nomes randômicos, baixa reputação, resolução rara no ambiente e proximidade temporal com requisições externas ao appliance. Em paralelo, a presença do caminho /mifs/403.jsp deve ser tratada como sinal de triagem prioritária, sobretudo quando combinada com alterações inesperadas em memória, comportamento anômalo do processo Java ou ausência de mudança legítima associada.
- Requisições para rotas do EPMM vindas de
193.24.123[.]42, de oito origens incomuns ou de blocos relacionados ao AS200593. - Alta diversidade de user agents em sequência curta contra a mesma instância, com alternância entre navegadores e sistemas operacionais.
- Consultas DNS originadas do appliance ou de segmentos adjacentes para domínios de validação OAST ou nomes raros após tentativas HTTP suspeitas.
- Acesso, criação ou referência ao caminho
/mifs/403.jspem servidores EPMM. - Indícios de carregamento Java em memória sem alteração operacional autorizada no appliance.
A resposta deve priorizar a aplicação dos patches disponibilizados para o Ivanti EPMM. A correção é o controle central porque indicadores como IPs, domínios e user agents mudam rapidamente quando há automação e infraestrutura bulletproof. Após corrigir, a equipe deve assumir que exploração pode ter ocorrido antes do patch e executar revisão retroativa do appliance, cobrindo logs de acesso, DNS, processos, arquivos inesperados, alterações de configuração e qualquer indicação do caminho /mifs/403.jsp. A validação não deve se limitar a verificar a versão, pois a correção impede novas explorações, mas não remove necessariamente artefatos criados antes dela.
No perímetro, o bloqueio do AS200593 e do endereço 193.24.123[.]42 pode reduzir ruído e impedir novas conexões relacionadas à infraestrutura descrita, desde que a organização valide impacto operacional e aplique a regra em camadas adequadas. Em ambientes críticos, a exposição pública do MDM deve ser reavaliada com segmentação, controle de origem, inspeção e monitoramento contínuo. Para instâncias com sinais de exploração, a contenção deve incluir preservação de evidências, isolamento controlado, coleta de artefatos de memória quando viável e revisão de contas, tokens, certificados e integrações usadas pelo EPMM, sem presumir comprometimento de dados quando a telemetria disponível não sustentar essa conclusão.
- Aplicar imediatamente os patches do Ivanti EPMM para
CVE-2026-1281eCVE-2026-1340. - Auditar todas as instâncias MDM expostas à internet, inclusive appliances corrigidos após a janela de exploração.
- Revisar DNS em busca de callbacks OAST e correlacionar consultas com requisições HTTP ao EPMM.
- Monitorar e investigar qualquer evidência relacionada ao caminho
/mifs/403.jsp. - Bloquear
193.24.123[.]42e avaliar bloqueio do AS200593 no perímetro quando compatível com a política da organização. - Revisar políticas de exposição de MDM, VPN e demais serviços remotos para reduzir dependência de acesso público irrestrito.
0 Comentários