UAT-7810 continue de construire des réseaux ORB en utilisant un nouveau malware

Résumé

Le groupe APT lié à la Chine UAT-7810 continue d’étendre son réseau LapDogs Operational Relay Box avec un ensemble d’outils de malwares personnalisés comprenant LONGLEASH, DOGLEASH et JARLEASH. L’acteur cible les appareils embarqués et le matériel de réseau pour construire une infrastructure proxy pouvant ensuite être utilisée par des acteurs menaçants secondaires. Ces opérations reposent en partie sur l’exploitation de failles connues dans les équipements Ruckus et ASUS.

Enquête

Cisco Talos a examiné l’infrastructure et les malwares liés à UAT-7810 et a identifié des versions mises à jour d’outils précédemment connus ainsi que deux nouvelles familles de malwares. L’analyse a révélé l’utilisation de nœuds VPS spécifiques et une empreinte numérique de certificat TLS personnalisé pour le trafic de commande et contrôle. Les chercheurs ont également relié l’infrastructure de l’acteur à des efforts visant à étendre le réseau ORB dans les environnements de routeurs ASUS AiCloud.

Atténuation

Les organisations devraient donner la priorité à la correction des routeurs sans fil Ruckus contre les problèmes connus tels que CVE-2020-22653, CVE-2020-22658, et CVE-2023-25717. Sécuriser les routeurs ASUS AiCloud contre CVE-2025-2492 est également essentiel. La segmentation du réseau isolant les appareils IoT et embarqués peut également réduire le risque que ces systèmes soient réutilisés comme nœuds de relais.

Réponse

Si les adresses IP identifiées ou le nom interne ff-agent sont détectés, les intervenants en cas d’incident devraient isoler immédiatement les appareils de réseau affectés. Une analyse judiciaire devrait ensuite vérifier la présence d’artefacts LEASHTEST ou de scripts shell non autorisés. La télémétrie réseau devrait également être examinée pour la chaîne d’agent utilisateur Chrome associée à l’implant LONGLEASH.

Exécution de simulation

Prérequis : Le contrôle préalable de télémétrie et de référence doit avoir été réussi.

Raisonnement : Cette section détaille l’exécution précise de la technique de l’adversaire (TTP) conçue pour déclencher la règle de détection. Les commandes et le récit DOIVENT refléter directement les TTP identifiés et viser à générer la télémétrie exacte attendue par la logique de détection. Des exemples abstraits ou non pertinents entraîneront un mauvais diagnostic.

• Narratif & Commandes de l’attaque : L’adversaire a réussi à obtenir un accès initial à la cible Linux via une vulnérabilité web (en exploitant CVE-2023-25717). Pour établir une persistance et un commandement et contrôle (C2), ils téléchargent une backdoor spécialisée depuis leur infrastructure. Suivant les modèles de la famille de malwares UAT-7810, l’attaquant nomme le binaire déposé LEASHTEST pour se fondre dans les scripts de test potentiels, mais la convention de nom elle-même est une signature de cet acteur menaçant spécifique. L’attaquant exécute ensuite ./LEASHTEST pour initier un shell inversé, ce qui devrait déclencher la règle de détection basée sur le nom du processus.

• Script de test de régression :

  #!/bin/bash
  # Script de simulation pour la détection du nom de processus de malware UAT-7810
  
  echo "[+] Démarrage de la simulation : Backdoor de malware UAT-7810"
  
  # 1. Créer un binaire factice pour simuler le malware
  # Dans un scénario réel, ce serait le fichier ELF malveillant réel.
  echo "#!/bin/bash" > LEASHTEST
  echo "echo 'Charge utile de malware simulé exécutée'" >> LEASHTEST
  
  # 2. Rendre le fichier exécutable
  chmod +x LEASHTEST
  
  # 3. Exécuter le 'malware' pour déclencher la règle de détection
  echo "[+] Exécution de LEASHTEST..."
  ./LEASHTEST
  
  echo "[+] Commande de simulation terminée."

• Commandes de nettoyage :

  # Nettoyer les artefacts de simulation
  rm -f LEASHTEST
  echo "[+] Nettoyage terminé."