Ativos Ivanti EPMM são explorados para implantar backdoors 'adormecidos'
Pesquisadores e equipes de resposta detectaram exploração ativa em appliances Ivanti Endpoint Manager Mobile (EPMM) após a divulgação de duas falhas críticas. A campanha prioriza implante de um carregador Java em memória que permanece inativo até receber uma segunda etapa.
Descoberta e escopo
Relatos públicos (Defusedcyber, Shadowserver e fontes de deteção) vinculam intrusões recentes à exploração de duas vulnerabilidades divulgadas pela Ivanti: CVE-2026-1281 (bypass de autenticação) e CVE-2026-1340 (execução remota de código). A exploração comprovada resultou, de forma consistente, na presença do artefato /mifs/403.jsp em dispositivos comprometidos.
Vetor técnico e comportamento do implant
Ao contrário de webshells interativos tradicionais, o artefato observado implementa um loader Java em memória. O payload inicial é enviado codificado em Base64 via parâmetros HTTP e, ao ser decodificado, contém bytecode Java válido (assinatura CAFEBABE). O nome de classe relatado é base.Info (compilado de Info.java).
O loader funciona como um "sleeper": ele não expõe imediatamente capacidade de execução de comandos ou navegação de arquivos. Em vez disso, aguarda uma requisição de ativação que entregue uma segunda classe Java. O carregamento da segunda etapa é feito por reflexão usando ClassLoader#defineClass, carregando o código diretamente em memória sem gravar no disco.
Evasão e portabilidade
O implante usa equals(Object) como ponto de entrada, ao invés dos métodos de servlet usuais (doGet/doPost), potencialmente evitando detecções simples que buscam padrões de servlet. O loader é capaz de extrair objetos de servlet como HttpServletRequest e HttpServletResponse, com alternativas para PageContext ou wrappers de servlet, o que aumenta a portabilidade entre contêineres Java.
Telemetria e indicadores
Defusedcyber reportou que, apesar da implantação e verificação do loader, não observaram requisições subsequentes com a segunda etapa — padrão consistente com operadores de acesso inicial que estabelecem pontos de presença para uso posterior por outros atores. Shadowserver identificou 56 IPs com sinais de comprometimento em varreduras realizadas em 6 de fevereiro de 2026.
Indicadores de compromisso divulgados incluem:
- Arquivo:
/mifs/403.jsp - Parâmetro HTTP de ativação:
k0f53cf964d387(padrão observado:GET /mifs/403.jsp?...k0f53cf964d387=<2 chars><base64>) - Delimitadores na resposta:
3cd3dee60537 - Assinatura de classe Java na carga útil decodificada:
CAFEBABE - SHA-256 relacionado a um artefato:
097b051c9c9138ada0d2a9fb4dfe463d358299d4bd0e81a1db2f69f32578747a
O que fazer agora (conselhos das fontes)
As orientações públicas convergem para ações imediatas: aplicar as correções e mitigações publicadas pela Ivanti e reiniciar servidores de aplicação afetados para expulsar implantes em memória, uma vez que o loader não precisa tocar disco. Caçar requisições para /mifs/403.jsp, procurar o parâmetro k0f53cf964d387 em logs e detectar respostas contendo os delimitadores reportados também são passos indicados.
Limites das evidências
As investigações documentadas mostram implantação e verificação do loader, mas não demonstram execução da segunda etapa em ambientes observados. Falta, portanto, evidência pública de operações de pós-exploração amplas a partir desses implantes específicos — embora a presença do mecanismo de ativação torne a situação sensível e com potencial de escalonamento.
Implicações para operações de segurança
Analistas devem tratar qualquer evidência dessa atividade como compromisso ou tentativa de compromisso. A característica "implant now, operate later" reforça a necessidade de caçar sinais de presença inicial, mesmo na ausência de atividade visível de comando e controle.
Referências
Relatos e indicadores foram publicados por Defusedcyber e Shadowserver; Ivanti divulgou advisory técnico com orientações de patch e mitigação.