Attaques PaperCut assistées par IA révèlent une deuxième RCE et un réseau mondial de victimes

Résumé

Un acteur de menace russophone a mené une campagne ciblée contre l’infrastructure ukrainienne, en se concentrant particulièrement sur l’écosystème d’échange de données et les serveurs de journalisation Graylog. L’attaquant a utilisé une chaîne d’injection JNDI basée sur Log4Shell pour atteindre l’exécution de code à distance et déployer des shells inversés. Bien que plusieurs exploits aient été tentés contre les systèmes MikroTik et Fortinet, l’accès principal réussi reposait sur une chaîne de désérialisation réutilisable de CommonsBeanutils2.

Enquête

L’enquête a commencé après que des chercheurs ont découvert un répertoire de mise en scène de l’opérateur exposé sur une adresse IP publique pendant environ 17 heures. Les analystes ont récupéré les fichiers de travail de l’attaquant, y compris les scripts d’exploitation, les constructeurs de charge utile, l’historique des shells et les résultats de la reconnaissance. Cette exposition a permis de reconstituer toute la chaîne d’attaque, depuis la reconnaissance initiale avec masscan jusqu’à l’exécution réussie de code sur les instances Graylog.

Atténuation

Les organisations devraient prioriser la mise à jour des déploiements de Graylog et s’assurer que les recherches JNDI sont désactivées ou strictement restreintes via des contrôles de sécurité Java appropriés. Un filtrage strict des sorties doit être appliqué pour bloquer les connexions LDAP et RMI non autorisées depuis les serveurs d’applications. Les équipes de sécurité devraient également surveiller les processus enfants inhabituels générés par les services basés sur Java et appliquer des protections CSRF sur les points d’extrémité d’API sensibles.

Réponse

Lorsqu’une activité JNDI suspecte ou des processus enfants inattendus provenant de services Web sont détectés, isolez immédiatement l’hôte affecté. Examinez les journaux d’application pour les modèles d’exploitation réussie, en accordant une attention particulière au /api/system/sessions point d’extrémité. Effectuez une analyse médico-légale au niveau de l’hôte pour les clés SSH non autorisées, les shells inversés ou les tunnels persistants qui peuvent avoir été utilisés pour pivoter.

Exécution de simulation

• Récit de l’attaque et commandes : L’adversaire tente d’exploiter une vulnérabilité dans une application web d’échange d’État. Pour se fondre dans le trafic administratif, ils utilisent un en-tête spécifique X-Requested-By: cli. Ils ciblent le point d’extrémité de gestion de session /api/system/sessions et tentent de déclencher l’exécution d’un script shell malveillant nommé fire3.sh. La présence de la chaîne UXP Verifier dans la réponse est une caractéristique connue de l’outil spécifique utilisé par cet acteur de menace. L’objectif est d’obtenir l’exécution de code à distance via le serveur web.

• Script de test de régression :

  #!/bin/bash
  # Script de simulation pour déclencher la règle de détection
  # Cela simule une requête qui correspond aux quatre critères de détection
  
  TARGET_URL="http://localhost/api/system/sessions"
  
  echo "[+] Simulation de requête d'attaque ciblée en cours..."
  
  # Nous utilisons curl pour imiter exactement les en-têtes et le chemin de la requête.
  # Note : Comme nous ne pouvons pas facilement contrôler le 'ResponseBody' d'un vrai serveur
  # sans héberger un serveur factice, cette simulation suppose que les journaux sont
  # générés par un proxy intercepteur ou un service web factice qui
  # renvoie '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 "[+] Commande de simulation envoyée."

• Commandes de nettoyage :

  # Aucune modification persistante effectuée sur le système, mais si un serveur factice a été démarré :
  # pkill -f "python3 -m http.server"
  echo "[+] Nettoyage terminé."