Hackers vêm adotando uma tática cada vez mais silenciosa e perigosa: o plantio de webshells “adormecidos” em servidores vulneráveis, prontos para serem ativados semanas ou meses depois. Essa estratégia, descrita no relatório “Sleeper Shells: How Attackers Are Planting Dormant Backdoors in Ivanti EPMM”, publicado em 9 de fevereiro de 2026 pela Defused, mostra uma mudança clara no padrão de exploração em massa de falhas críticas.
Segundo os analistas da Defused, uma campanha coordenada iniciada em 4 de fevereiro de 2026 está explorando, de forma automatizada, falhas no Ivanti Endpoint Manager Mobile (EPMM). Mas, ao contrário do habitual, os invasores não executam comandos logo após o comprometimento. Em vez disso, eles implantam um payload e simplesmente abandonam o sistema, deixando apenas uma porta discreta aberta para uso futuro.
Esse comportamento é típico dos chamados corretores de acesso inicial (Initial Access Brokers – IABs). Em vez de explorarem eles mesmos o ambiente comprometido, esses grupos se especializam em garantir o primeiro passo dentro da infraestrutura da vítima e, depois, monetizam esse acesso: vendem ou repassam a outros grupos de cibercrime interessados em ransomware, espionagem, roubo de dados ou fraudes financeiras. O resultado é um mercado clandestino de acessos prontos para uso, onde cada webshell adormecida pode representar a entrada em uma grande organização ou órgão governamental.
No centro da campanha descrita pela Defused estão duas vulnerabilidades críticas no Ivanti EPMM, catalogadas como CVE-2026-1281 e CVE-2026-1340. Essas falhas permitem tanto o desvio de mecanismos de autenticação quanto a execução remota de código, afetando componentes específicos do produto, como os pacotes aftstore e appstore. Em termos práticos, isso significa que um invasor pode interagir com o sistema sem precisar de credenciais válidas e ainda executar código malicioso diretamente no ambiente alvo.
A Ivanti já publicou orientações de correção e mitigação, mas os pesquisadores destacam que a exploração ativa segue em curso, atingindo especialmente grandes empresas e entidades governamentais. Como o vetor de ataque não exige autenticação, basta que o servidor esteja exposto à internet e sem os patches aplicados para se tornar um alvo potencial. A combinação de exploração em massa, webshell adormecida e acesso revendido amplia o alcance e o impacto dessa campanha.
O implante identificado pela Defused, batizado de “base.Info”, é um exemplo de como os atacantes vêm refinando a discrição de suas ferramentas. Trata-se de um carregador de classes Java em memória, projetado não para executar comandos de imediato, mas para servir como um estágio inicial de uma cadeia de ataque. Ele é carregado no caminho /mifs/403.jsp e, sozinho, não realiza ações destrutivas visíveis. Seu papel é, essencialmente, preparar o terreno para uma segunda classe Java, enviada posteriormente via HTTP, que será responsável pela carga útil principal.
Do ponto de vista técnico, o “base.Info” atua como um loader em memória, uma técnica que dificulta a detecção por antivírus tradicionais e algumas soluções de segurança focadas em arquivos. O código utiliza métodos incomuns para carregar e instanciar classes Java dinamicamente, o que ajuda a driblar assinaturas estáticas de ferramentas de proteção. Além disso, ele coleta informações do ambiente do host — como nome e versão do sistema operacional, diretórios de trabalho e detalhes da JVM —, fornecendo ao operador uma visão básica do terreno antes de decidir qual payload secundário enviar.
Um ponto crítico destacado no relatório é a ausência de atividade aparente logo após a invasão. Em muitos incidentes, equipes de segurança acostumadas a buscar sinais claros de movimentação lateral, exfiltração de dados ou instalação visível de malware podem interpretar o silêncio como falso positivo ou incidente pouco relevante. Isso é um erro perigoso: o simples fato de um webshell ou loader em memória ter sido implantado já indica que o perímetro foi rompido e que o ambiente está exposto para futuros ataques.
Por isso, a Defused enfatiza que administradores do Ivanti EPMM devem agir com urgência. A recomendação é aplicar imediatamente os patches disponibilizados pelo fabricante, além de reiniciar os servidores de aplicação para remover implantes que residem apenas em memória RAM. Como o loader não escreve arquivos persistentes em disco em alguns cenários, o simples reboot pode encerrar sua execução — desde que a vulnerabilidade tenha sido corrigida e não possa ser explorada novamente após a volta do serviço.
Em termos de detecção, os pesquisadores sugerem monitorar cuidadosamente as requisições ao caminho /mifs/403.jsp, consideradas um forte indicador de comprometimento. Parâmetros em Base64 que se iniciem com a sequência de bytes “yv66vg” merecem atenção especial, pois esse padrão é característico de classes Java codificadas. Em outras palavras, qualquer tráfego HTTP suspeito contendo esses parâmetros pode estar carregando uma classe maliciosa diretamente para a memória do servidor.
Para entender a gravidade do problema, é importante lembrar o que é um webshell: trata-se, em essência, de uma porta traseira acessível via navegador, que permite a um atacante executar comandos, transferir arquivos, manipular configurações e, em muitos casos, assumir controle completo do servidor. Quando esse webshell é “adormecido” — ou seja, implantado sem uso imediato —, o ambiente parece normal, os serviços continuam funcionando e o atacante ganha o benefício do tempo. Ele pode aguardar um momento mais oportuno, como um fim de semana prolongado, mudança de turno da equipe de TI ou crise interna, para ativar o acesso e minimizar as chances de detecção rápida.
Esse modelo se encaixa perfeitamente na dinâmica dos corretores de acesso inicial. Eles não precisam explorar profundamente o ambiente; basta garantir um ponto de entrada confiável e estável. A partir daí, outros grupos podem usar o acesso para aplicar ransomware, roubar bases de dados sensíveis, comprometer contas privilegiadas ou até usar a infraestrutura da vítima como trampolim para novos ataques contra terceiros. Assim, um simples servidor Ivanti EPMM vulnerável pode se tornar o elo inicial de uma cadeia de incidentes em larga escala.
Do ponto de vista de governança e gestão de risco, o caso reforça a necessidade de tratar soluções de gerenciamento de dispositivos móveis e de endpoints como ativos críticos de infraestrutura. Muitas organizações ainda enxergam esses sistemas como “ferramentas auxiliares”, relegando-os a um plano secundário em termos de prioridade de patching. A campanha descrita pela Defused mostra o oposto: comprometer uma plataforma centralizada de gestão de dispositivos abre um canal privilegiado para todo o ecossistema de endpoints gerenciados por ela.
Uma resposta adequada passa por uma combinação de ações técnicas e processuais. Além da aplicação imediata de correções e da revisão de configurações do Ivanti EPMM, é fundamental:
– Implementar monitoramento contínuo de logs de aplicação e de acesso web, com alertas específicos para padrões anômalos como o uso de /mifs/403.jsp e parâmetros em Base64 fora do comportamento esperado.
– Revisar regras de WAF (firewall de aplicação web) para bloquear tentativas de envio de payloads codificados ou padrões associados a classes Java carregadas remotamente.
– Integrar soluções de EDR/XDR para correlacionar sinais de possível execução de código remoto, mesmo quando não há criação de arquivos em disco.
– Segmentar a rede de forma que o servidor EPMM não tenha acesso irrestrito a outros sistemas críticos, reduzindo o potencial de movimentação lateral.
Outra medida crucial é revisar periodicamente a exposição à internet. Muitos servidores de gerenciamento, por conveniência ou necessidade operacional, acabam acessíveis diretamente a partir da rede externa, ampliando a superfície de ataque. Avaliar se esse acesso realmente precisa ser público, ou se pode ser mediado por VPN, proxies autenticados ou outros mecanismos de controle, é um passo simples que pode reduzir drasticamente o risco de exploração em massa.
Também não se pode negligenciar o fator humano na resposta a incidentes. Equipes de segurança, operações e desenvolvimento devem estar alinhadas quanto à criticidade de vulnerabilidades em produtos como o Ivanti EPMM. Processos internos precisam garantir que alertas de falhas críticas sejam rapidamente priorizados, com janelas de manutenção emergenciais definidas e aprovadas sem burocracia excessiva. Cada dia de atraso na aplicação de um patch em uma vulnerabilidade de execução remota de código representa mais oportunidades para campanhas como a descrita pela Defused.
Por fim, é importante que as organizações revisem seus planos de continuidade de negócio e de resposta a incidentes considerando cenários de comprometimento silencioso. Exercícios de simulação que incluam situações em que o atacante já está presente há semanas, operando com acesso webshell ou loaders em memória, ajudam a testar a maturidade do monitoramento, da correlação de eventos e da capacidade de investigação forense. A realidade demonstrada pelos “sleeper shells” é clara: o fato de não haver atividade ruidosa não significa que o ambiente esteja seguro.
O caso das webshells adormecidas no Ivanti EPMM ilustra uma tendência mais ampla do cibercrime: ataques cada vez mais modulados, especializados e pautados em cadeias de valor dentro do próprio ecossistema criminoso. Entender essa dinâmica — em que um grupo planta o acesso, outro compra, outro explora e outro monetiza os dados — é essencial para desenhar defesas que não se limitem a bloquear o último estágio do ataque, mas que consigam interromper a cadeia desde o primeiro movimento: a exploração de uma vulnerabilidade crítica que, se ignorada, se transforma em uma porta invisível para ataques futuros.