Ataques de PaperCut Asistidos por IA Exponen una Segunda RCE y una Red Global de Víctimas

Resumen

Un actor de amenazas de habla rusa llevó a cabo una campaña dirigida contra la infraestructura ucraniana, con un enfoque particular en el ecosistema de intercambio de datos y los servidores de registro Graylog. El atacante utilizó una cadena de inyección JNDI basada en Log4Shell para lograr la ejecución remota de código e implementar shells inversos. Aunque se intentaron múltiples explotaciones contra los sistemas MikroTik y Fortinet, el acceso exitoso principal dependía de una cadena de deserialización reutilizable CommonsBeanutils2.

Investigación

La investigación comenzó después de que los investigadores descubrieran un directorio de preparación del operador expuesto en una dirección IP pública durante aproximadamente 17 horas. Los analistas recuperaron los archivos de trabajo del atacante, incluidos los scripts de explotación, los constructores de carga útil, el historial de shells y los resultados de reconocimiento. Esta exposición permitió reconstruir toda la cadena de ataque, desde el reconocimiento inicial con masscan hasta la ejecución exitosa de código en instancias de Graylog.

Mitigación

Las organizaciones deben priorizar el parcheo de las implementaciones de Graylog y garantizar que las búsquedas JNDI estén deshabilitadas o restringidas rigurosamente a través de controles de seguridad de Java apropiados. Debería aplicarse un filtrado estricto de salida para bloquear conexiones LDAP y RMI no autorizadas desde los servidores de aplicaciones. Los equipos de seguridad también deben monitorear procesos secundarios inusuales generados por servicios basados en Java y aplicar protecciones CSRF en endpoints API sensibles.

Respuesta

Cuando se detecta actividad JNDI sospechosa o procesos secundarios inesperados originados en servicios web, aísle el host afectado de inmediato. Revise los registros de la aplicación en busca de patrones de explotación exitosos, con especial atención al /api/system/sessions endpoint. Realice un análisis forense a nivel de host en busca de claves SSH no autorizadas, shells inversos o túneles persistentes que puedan haber sido utilizados para pivotar.

Ejecución de Simulación

• Narrativa del Ataque & Comandos: El adversario está intentando explotar una vulnerabilidad en una aplicación web de intercambio estatal. Para camuflarse con el tráfico administrativo, utilizan un encabezado específico X-Requested-By: cli. Apuntan al endpoint de gestión de sesiones /api/system/sessions e intentan desencadenar la ejecución de un script de shell malicioso llamado fire3.sh. La presencia de la cadena UXP Verifier en la respuesta es una característica conocida del kit de herramientas específico utilizado por este actor de amenazas. El objetivo es lograr la ejecución remota de código a través del servidor web.

• Script de Prueba de Regresión:

  #!/bin/bash
  # Script de simulación para activar la regla de detección
  # Esto simula una solicitud que coincide con los cuatro criterios de detección
  
  TARGET_URL="http://localhost/api/system/sessions"
  
  echo "[+] Simulando la solicitud de ataque dirigida..."
  
  # Usamos curl para imitar exactamente los encabezados y la ruta de la solicitud.
  # Nota: Ya que no podemos controlar fácilmente el 'ResponseBody' de un servidor real 
  # sin alojar un servidor falso, esta simulación asume que los registros son 
  # generados por un proxy de interceptación o un servicio web falso que 
  # devuelve 'UXP Verifier'.
  
  curl -X POST "$TARGET_URL" 
       -H "X-Requested-By: cli" 
       -H "Content-Type: application/json" 
       -d '{"filename": "fire3.sh", "payload": "echo "UXP Verifier""}' 
       --verbose
  
  echo "[+] Comando de simulación enviado."

• Comandos de Limpieza:

  # No se hicieron cambios persistentes en el sistema, pero si se inició un servidor falso:
  # pkill -f "python3 -m http.server"
  echo "[+] Limpieza completa."