Analyse Technique des Emails Suspects Ciblant l’Industrie Hôtelière

Résumé

Une campagne de logiciels malveillants sophistiquée à plusieurs étapes cible le secteur hôtelier via des emails déguisés en notifications Booking.com. La chaîne d’intrusion combine des fichiers LNK malveillants, des scripts PowerShell et un cheval de Troie d’accès à distance basé sur Node.js connu sous le nom de TonRAT. L’un des aspects les plus remarquables de l’opération est son utilisation de l’API de The Open Network (TON) pour obtenir dynamiquement les domaines de commande et de contrôle, ce qui rend le blocage traditionnel basé sur les domaines moins fiable.

Enquête

L’enquête a révélé un flux d’exécution en couches dans lequel une archive ZIP initiale contient un fichier LNK qui lance PowerShell pour récupérer un script secondaire. Ce script décrypte une charge utile JavaScript identifiée comme TonRAT en utilisant AES et l’exécute via un runtime Node.js légitime téléchargé depuis nodejs.org. Une fois actif, le logiciel malveillant initie des communications de commande et de contrôle basées sur WebSocket en utilisant des informations de domaine extraites des requêtes API blockchain de TON.

Atténuation

Les défenses recommandées incluent la restriction de l’exécution de PowerShell, la surveillance étroite de l’utilisation non autorisée du runtime Node.js (node.exe), et la détection de trafic WebSocket anormal. Les organisations devraient également surveiller les connexions à l’API de TON, y compris tonapi.io, et renforcer le filtrage des emails pour intercepter les domaines falsifiés, les pièces jointes suspectes et les appâts de phishing destinés au personnel hôtelier.

Réponse

Si une compromission est suspectée, les équipes de sécurité doivent isoler immédiatement le point de terminaison affecté pour empêcher le trafic de commande et de contrôle supplémentaire et la possible exfiltration de données. Les journaux opérationnels de PowerShell et les enregistrements d’exécution des processus doivent être examinés pour rechercher des node.exe activités non autorisées. Une analyse médico-légale doit également être réalisée pour les hachages JavaScript connus de TonRAT, ainsi qu’une investigation sur toutes les connexions à l’infrastructure de commande et de contrôle identifiée.

Exécution de Simulation

Prérequis : Le contrôle pré-vol de Télémétrie & Base de référence doit être passé.

Raison : 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 exactement la télémétrie attendue par la logique de détection. Les exemples abstraits ou non liés conduiront à un mauvais diagnostic.

• Narrative & Commandes de l’Attaque : L’adversaire vise à établir un canal de Commande et Contrôle (C2) basé sur WebSocket. Pour se fondre dans le trafic légitime, le logiciel malveillant interroge d’abord le tonapi.io service pour résoudre son infrastructure C2. Une fois l’interaction « légitime » avec l’API établie, le logiciel malveillant initie une poignée de main WebSocket (wss://) vers le domaine malveillant codé en dur zloapobikahy23.bond. Cette séquence est conçue pour exploiter la réputation de l’API de TON pour masquer la connexion malveillante suivante.

• Script de Test de Régression :

  # Simulation de Communication C2 WebSocket TonRAT
  # Étape 1 : Simuler l'interaction avec l'API de TON
  Write-Host "[+] Simulation de l'interaction avec tonapi.io..."
  $api_url = "https://tonapi.io/v2/blockchain/accounts/EQ..."
  Invoke-WebRequest -Uri $api_url -Method Get -UseBasicParsing
  
  # Étape 2 : Simuler la connexion WebSocket au domaine C2 malveillant
  # Note : Nous utilisons un client PowerShell pour initier une requête WSS pour déclencher la logique 'wss://' et de domaine
  Write-Host "[+] Simulation de la connexion WebSocket au domaine malveillant..."
  $c2_url = "wss://zloapobikahy23.bond/control"
  
  # Utilisation d'un client WebSockets .NET pour garantir que 'wss://' est présent dans la télémétrie
  $ws = New-Object System.Net.WebSockets.ClientWebSocket
  $cts = New-Object System.Threading.CancellationTokenSource
  $uri = New-Object System.Uri($c2_url)
  
  try {
      $task = $ws.ConnectAsync($uri, $cts.Token)
      # Une connexion réussie n'est pas nécessaire, juste la tentative pour générer le log
      $task.Wait(5000) 
  } catch {
      Write-Host "[!] Échec de la connexion comme prévu (le domaine n'existe pas), mais la télémétrie devrait être générée."
  } finally {
      $ws.Dispose()
  }

• Commandes de Nettoyage :

  # Aucun artéfact persistant n'est créé par ce script, mais nous vidons la console
  Clear-Host
  Write-Host "Nettoyage de simulation terminé."