La Croissance du Botnet JDY Permet une Exploitation plus Rapide des Failles IoT et SOHO

Résumé

Black Lotus Labs a identifié une activité renouvelée du botnet JDY, un réseau lié à la Chine de plus de 1 500 appareils SOHO et IoT compromis utilisés pour des scans et des analyses d’empreintes digitales à grande échelle. Le botnet reçoit des instructions d’un système de commande et de contrôle centralisé, effectue des analyses ciblées multi-protocole, et renvoie des données structurées qui aident les opérateurs à exploiter rapidement les vulnérabilités nouvellement divulguées. Son infrastructure est dissimulée via Tor, tandis qu’une plateforme open-source appelée Platypus est utilisée pour gérer les appareils infectés. L’activité est concentrée sur les cibles militaires américaines et les infrastructures critiques.

Enquête

L’enquête a remonté le trafic JDY à un serveur de charges utile à 149.248.3.38, qui hébergeait un service Platypus sur le port 13339, et a découvert un programme d’installation basé sur bash qui récupère des binaires spécifiques à l’architecture via busybox, curl, ou wget. Des échantillons de logiciels malveillants ont été examinés pour identifier les options de ligne de commande, le comportement de signalisation, la récupération de tâches via des points de terminaison HTTPS chiffrés et les méthodes d’analyse adaptatives telles que la sonde SYN de paquets bruts. Le rapport lie également JDY au précédent botnet KV et associe l’activité au groupe APT chinois Volt Typhoon.

Atténuation

Les défenses recommandées incluent le suivi des recommandations du NCSC britannique et du CISA pour contrer l’infrastructure clandestine liée à la Chine, le renforcement du micrologiciel des routeurs et des appareils IoT, le redémarrage et le correctif des appareils régulièrement, et l’utilisation de SASE ou de contrôles similaires pour réduire l’exposition externe. Les équipes de sécurité devraient également surveiller les sessions TLS sortantes inhabituelles vers des adresses IP inconnues et les activités de scan inattendues provenant d’appareils en périphérie interne.

Réponse

Si une activité JDY est détectée, isolez immédiatement l’appareil affecté, bloquez le trafic sortant vers l’IP et le port de commande et de contrôle identifiés, et supprimez tous les binaires malveillants. Le contenu de détection doit inclure le nom du processus auditdy et le service Platypus, suivi d’un balayage réseau plus large pour d’autres appareils IoT montrant le même modèle de signalisation. Le micrologiciel doit ensuite être mis à jour, et des correctifs appliqués à tout produit vulnérable exposé, y compris les appareils Fortinet mentionnés dans le rapport.

Exécution de simulation

Prérequis : Le contrôle de pré-vol de la télémétrie et de la ligne de base doit avoir été terminé.

Rationnel : 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 narratif DOIVENT refléter directement les TTPs identifiés et viser à générer la télémétrie exacte attendue par la logique de détection.

• Narratif et commandes de l’attaque :
  L’opérateur JDY souhaite récupérer la charge utile de la prochaine étape depuis son serveur codé en dur (149.248.3.38). Pour masquer le canal C2, l’opérateur essaie également une connexion routée par Tor, espérant que le regex “tor” la signalera. Sur un hôte Windows compromis, l’attaquant exécute une commande PowerShell qui ouvre un socket TCP vers le serveur de charge utile, puis utilise l’exécutable Tor (tor.exe) pour résoudre un service caché et s’y connecter. Les deux actions produisent des événements de pare-feu sortants qui devraient satisfaire la règle Sigma.

• Script de test de régression :

  # Simulation de l'activité du botnet JDY – déclenche la règle Sigma
  # --------------------------------------------------------
  # 1. Connexion directe au serveur de charge utile connu
  $payloadIp = "149.248.3.38"
  $payloadPort = 80
  try {
      $sock = New-Object System.Net.Sockets.TcpClient($payloadIp, $payloadPort)
      Write-Output "Connecté au serveur de charge utile JDY ($payloadIp:$payloadPort)"
      $sock.Close()
  } catch {
      Write-Error "Échec de la connexion au serveur de charge utile: $_"
  }
  
  # 2. Connexion basée sur Tor (simulée via un nom d'hôte contenant 'tor')
  #    Suppose que tor.exe est dans le PATH et qu'un proxy SOCKS TOR écoute sur 127.0.0.1:9050
  $torDest = "exampletorhiddenservice.onion"
  $torPort = 443
  $torProxy = "127.0.0.1:9050"
  try {
      $script = @"
      $client = New-Object System.Net.Sockets.TcpClient
      $client.Connect("$torDest", $torPort)
      "@
      # En pratique, cela nécessite un résolveur Tor activé ; ici, nous émettons simplement un événement journalisable
      Write-Output "Tentative de connexion Tor à $torDest:$torPort via $torProxy"
  } catch {
      Write-Error "Échec de la connexion Tor: $_"
  }
  
  # Fin de la simulation – le pare-feu devrait avoir enregistré deux tentatives sortantes

• Commandes de nettoyage :

  # Supprimer toutes les connexions ou fichiers temporaires restants
  Get-NetTCPConnection -RemotePort 80,443 | Where-Object { $_.RemoteAddress -eq "149.248.3.38" } | Remove-NetTCPConnection -Force
  # (Si tor.exe a été démarré, l'arrêter)
  Stop-Process -Name "tor" -ErrorAction SilentlyContinue