Ataques ao PaperCut Auxiliados por IA Revelam um Segundo RCE e Rede Global de Vítimas

Resumo

Um agente de ameaça de língua russa realizou uma campanha direcionada contra a infraestrutura ucraniana, com foco particular no ecossistema de troca de dados e servidores de log Graylog. O atacante usou uma cadeia de injeção JNDI baseada no Log4Shell para alcançar a execução remota de código e implantar shells reversos. Embora várias explorações tenham sido tentadas contra sistemas MikroTik e Fortinet, o acesso bem-sucedido primário se baseou em uma cadeia de desserialização reuseable CommonsBeanutils2.

Investigação

A investigação começou após pesquisadores descobrirem um diretório de preparação de operador exposto em um endereço IP público por aproximadamente 17 horas. Analistas recuperaram os arquivos de trabalho do atacante, incluindo scripts de exploração, construtores de payloads, histórico de shell e saída de reconhecimento. Essa exposição possibilitou reconstruir a cadeia de ataque completa, desde o reconhecimento inicial com masscan até a execução de código bem-sucedida em instâncias do Graylog.

Mitigação

As organizações devem priorizar a aplicação de patches nas implantações do Graylog e garantir que as pesquisas JNDI sejam desativadas ou estritamente restritas por meio de controles de segurança Java adequados. Um filtro de saída rigoroso deve ser imposto para bloquear conexões LDAP e RMI não autorizadas dos servidores de aplicativos. As equipes de segurança também devem monitorar processos filhos incomuns gerados por serviços baseados em Java e aplicar proteções contra CSRF em endpoints de API sensíveis.

Resposta

Quando atividades suspeitas de JNDI ou processos filhos inesperados originados de serviços web forem detectados, isole imediatamente o host afetado. Revise os logs de aplicação para padrões de exploração bem-sucedida, com atenção especial para o /api/system/sessions endpoint. Realize análise forense no nível do host para chaves SSH não autorizadas, shells reversos ou túneis persistentes que possam ter sido usados para pivotar.

Execução de Simulação

• Narrativa de Ataque & Comandos: O adversário está tentando explorar uma vulnerabilidade em uma aplicação web de troca de estado. Para se misturar com o tráfego administrativo, eles usam um cabeçalho específico X-Requested-By: cli. Eles almejam o endpoint de gerenciamento de sessão /api/system/sessions e tentam acionar a execução de um script de shell malicioso chamado fire3.sh. A presença do verificador UXP string na resposta é uma característica conhecida do conjunto de ferramentas específico usado por esse agente de ameaça. O objetivo é obter execução remota de código através do servidor web.

• Script de Teste de Regressão:

  #!/bin/bash
  # Script de simulação para acionar a regra de detecção
  # Esta simula uma solicitação que corresponde a todos os quatro critérios de detecção
  
  TARGET_URL="http://localhost/api/system/sessions"
  
  echo "[+] Simulando solicitação de ataque direcionado..."
  
  # Usamos curl para imitar os cabeçalhos e o caminho de solicitação exatos.
  # Nota: Como não podemos controlar facilmente o 'ResponseBody' de um servidor real 
  # sem hospedar um servidor simulado, esta simulação assume que os logs são 
  # gerados por um proxy interceptador ou um serviço web simulado que 
  # retorna 'Verificador UXP'.
  
  curl -X POST "$TARGET_URL" 
       -H "X-Requested-By: cli" 
       -H "Content-Type: application/json" 
       -d '{"filename": "fire3.sh", "payload": "echo "Verificador UXP""}' 
       --verbose
  
  echo "[+] Comando de simulação enviado."

• Comandos de Limpeza:

  # Nenhuma alteração persistente feita no sistema, mas se um servidor simulado foi iniciado:
  # pkill -f "python3 -m http.server"
  echo "[+] Limpeza completa."