ShinyHunters contorna WAF e volta a atacar PeopleSoft

O grupo ShinyHunters retomou a exploração em massa de sistemas Oracle PeopleSoft com uma versão modificada do exploit da falha CVE-2026-35273 que derruba a principal defesa improvisada do mercado: regras de firewall de aplicação web (WAF) bloqueando o endpoint vulnerável. O relatório publicado em 25 de setembro de 2026 pela Mandiant e pelo Google Threat Intelligence Group documenta dezenas de servidores comprometidos no mundo inteiro, com web shells implantados em organizações de educação superior, tecnologia, serviços de TI, saúde, agricultura, transporte e governo. Para quem opera PeopleSoft, a ordem é direta: aplicar o patch da Oracle agora, desativar o Environment Management Hub se o patch não sair hoje e caçar nos logs o caminho codificado que o grupo usou para atravessar o WAF.

A campanha expõe um erro de avaliação comum: tratar bloqueio de caminho no perímetro como se fosse correção. O atacante leu a orientação defensiva publicada em junho, ajustou o exploit e voltou a entrar nos mesmos servidores que as equipes acreditavam protegidas.

O que mudou na campanha

A primeira onda foi registrada entre 27 de maio e 9 de junho de 2026, quando a falha ainda era um zero-day explorado sobretudo contra instituições de ensino; a Oracle publicou um Security Alert fora de ciclo em 10 de junho de 2026. A orientação da época combinava patch, desativação do serviço EMHub e, como paliativo, bloqueio externo do caminho /PSEMHUB/* no perímetro. Segundo a análise da Mandiant e do Google Threat Intelligence Group, houve uma nova onda de exploração em massa da falha CVE-2026-35273, atribuída ao grupo rastreado como UNC6240, com alvos expandidos para múltiplos setores. O grupo passou a procurar exatamente as organizações que implementaram a regra de WAF e ficaram sem o patch.

Esse padrão de adaptação a defesas publicadas muda o cálculo de risco: mitigação documentada em advisory vira material de leitura para o atacante. O caso também ilustra a dinâmica do mercado de corretores de acesso — servidores ERP expostos e sem correção são inventário pronto para quem monetiza acesso inicial, e o PeopleSoft concentra dados de RH e folha de pagamento, ativo típico de extorsão.

Como o bypass do WAF funciona

O truque é simples e eficiente. Regras de WAF e de proxy reverso costumam comparar a string literal do caminho antes da decodificação de URL. O grupo passou a pedir /%50SEMHUB/ em vez de /PSEMHUB/: %50 é a forma codificada da letra P. A regra que casa com /PSEMHUB não vê a variante, mas o WebLogic decodifica o caminho e entrega a requisição ao servlet vulnerável normalmente. O relatório técnico descreve o grupo codificando um único caractere do caminho para atravessar filtros que deveriam conter a exploração.

A consequência operacional: bloqueio de caminho só funciona sobre a forma normalizada. Assuma que qualquer variante com percent-encoding, caixa mista ou não normalizada de /PSEMHUB/ pode ser testada e reforce o bloqueio no caminho decodificado — sem tratar isso como correção. O alerta de segurança da Oracle classifica o problema como explorável de forma remota, com resultado potencial em execução remota de código sem autenticação, nota CVSS 3.1 de 9.8 e versões afetadas 8.61 e 8.62 do PeopleTools. Nenhuma regra de WAF substitui o patch.

TTPs: da sonda ao backdoor

O ciclo observado é consistente entre vítimas e começa antes da exploração. Na verificação do alvo, o servidor recebe de cinco a quinze requisições POST para /%50SEMHUB/hub carregando um objeto Java serializado; o servidor sem correção responde devolvendo o sistema operacional do host, sem gravar arquivos e sem interromper o serviço. É uma sonda silenciosa: hosts validados podem exibir essa assinatura nos logs sem atividade seguinte — o que não significa ausência de risco, significa que o nome do servidor entrou numa lista.

Na exploração, há dois métodos. No primeiro, rajadas de POST criam arquivos JSP no diretório PSEMHUB.war; a repetição garante que todos os nós atrás de um balanceador recebam a cópia do web shell, então inspecione todos os nós WebLogic, não apenas o primeiro suspeito. No segundo, a execução é fileless: a saída do comando volta no corpo da resposta HTTP e, no host, aparecem processos de shell (cmd.exe ou /bin/sh) originados do processo Java do WebLogic. Detecções que dependem de criação de arquivo JSP não enxergam esse caminho.

A persistência usa duas web shells JSP complementares: x.jsp executa comandos multiplataforma recebidos em hexadecimal via POST, com saída prefixada por R:, e reconstrói o /bin/sh a partir de um array de caracteres para escapar de assinaturas estáticas; u.jsp remonta binários em blocos Base64 de 150 KB, contornando limites de tamanho de requisição. A movimentação apoia-se em túneis Neo-reGeorg (tunnel.jsp, tunnel.jspx) e num instalador trojanizado, Ple64.exe, que entrega o backdoor SIDEEYE, além de agente MeshCentral para acesso remoto. O mapa MITRE ATT&CK inclui T1190 (exploração de aplicação exposta), T1505.003 (web shell), T1552.001 (credenciais em arquivos), T1219 (software de acesso remoto) e T1048 (exfiltração por protocolo alternativo). Traduzir esses comportamentos em conteúdo de detecção — no formato que seu SIEM consome, como regras Sigma — fecha o ciclo entre inteligência e operação.

Indicadores para caça nos logs

Os indicadores abaixo vêm do relatório da Mandiant; use-os como ponto de partida de varredura, não como lista exaustiva:

Janela sugerida: varrer os access logs do PIA WebLogic desde 27 de maio de 2026, com atenção a POSTs externos em /hub e chamadas a arquivos.jsp, e monitorar o tráfego de saída dos hosts PeopleSoft para os endereços da tabela.

Ações prioritárias: P1 e P2

P1 — hoje: aplicar o patch do Security Alert (documento CPU187 na Oracle); em configurações multi-servidor, desativar o serviço EMHub e, em servidor único, remover a aplicação PSEMHUB; inspecionar PSEMHUB.war em todos os nós atrás de balanceador; rotacionar credenciais legíveis pela conta de serviço do PeopleSoft — strings de conexão do banco em psappsrv.cfg, credenciais do Integration Broker e qualquer credencial de nuvem alcançável a partir do web tier.

P2 — nesta semana: reescrever bloqueios de perímetro para o caminho normalizado e testá-los contra variantes codificadas; monitorar a saída para os IOCs publicados; revisar endpoints quanto a agentes MeshCentral inesperados; e registrar no plano de resposta que mitigação publicada em advisory não é estado final — é cronômetro para o atacante adaptar o exploit.

Fontes

• Mandiant e Google Threat Intelligence Group — ShinyHunters Renewed Mass Exploitation Campaign Targeting Oracle PeopleSoft (25/09/2026)
• Oracle Security Alert Advisory — CVE-2026-35273 (10/06/2026)