LokiBot Après une Décennie : Analyse d’une Campagne Récente

Résumé

LokiBot est un voleur d’informations de longue date conçu pour collecter des identifiants à partir de navigateurs, de portefeuilles de cryptomonnaies et d’autres applications sensibles. Cette récente campagne repose sur une chaîne d’exécution en plusieurs étapes qui commence par une pièce jointe JScript obfusquée, livrée par le biais de spam malveillant. Le logiciel malveillant utilise l’injection de processus et le hashage des API pour réduire la visibilité tout en envoyant les données volées à son infrastructure de commande et de contrôle.

Enquête

L’enquête a examiné un échantillon de LokiBot en plusieurs étapes et a retracé sa progression depuis une pièce jointe JScript jusqu’à un chargeur PowerShell, puis vers un injecteur .NET, et enfin vers la charge utile de LokiBot. Les analystes ont identifié l’utilisation de la protection ConfuserEx, du déchiffrement basé sur XOR et des techniques de chargement réflexif tout au long de la chaîne. L’étude a également décrit l’approche personnalisée de hachage des API du logiciel malveillant et une méthode de persistance défectueuse basée sur le registre.

Atténuation

Les organisations doivent déployer un filtrage d’e-mails puissant pour bloquer les pièces jointes JScript malveillantes et le spam avant la livraison. Surveiller les processus enfants suspects créés par wscript.exe and powershell.exe est également essentiel. De plus, restreindre l’exécution d’assemblages .NET non fiables et surveiller les modifications inhabituelles dans les clés Run de Windows peut aider à réduire l’exposition.

Réponse

Si LokiBot est détecté, isolez immédiatement le point de terminaison affecté pour arrêter le vol de données supplémentaire et la communication de commande et de contrôle. Les enquêteurs doivent effectuer une analyse médico-légale pour déterminer le point d’entrée initial et évaluer l’étendue de la compromission des identifiants. Tous les comptes accédés depuis l’hôte infecté doivent faire l’objet d’une réinitialisation complète du mot de passe, et l’environnement doit être analysé à la recherche d’artefacts JScript et PowerShell associés.

Exécution de la simulation

Prérequis : Le contrôle préalable de la télémétrie et de la ligne de base doit être passé.

Justification : 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 TTPs 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 liés mèneront à un mauvais diagnostic.

• Récit et commandes d’attaque : L’adversaire a réussi à obtenir un accès initial via un fichier JScript. Pour éviter de déposer un .dll fichier détectable sur le disque, ils exécutent une commande PowerShell qui contient une chaîne codée en Base64. Ce script, une fois décodé, utilise la réflexion .NET capacité pour appeler [System.Reflection.Assembly]::Load afin de tirer une charge utile malveillante directement dans la mémoire du processus en cours. Cette approche « sans fichier » est une caractéristique de LokiBot.

• Script de test de régression :

  # Script de simulation LokiBot
  # Ce script est conçu pour correspondre exactement aux chaînes définies dans la règle de détection.
  
  # 1. Simuler le composant Base64
  $encodedCommand = "Script PowerShell codé en Base64"
  $dummyPayload = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes("FausseCharge"))
  
  # 2. Simuler le chargement de l'assemblage en utilisant exactement la chaîne de la règle de détection
  # Nous utilisons un try/catch car il s'agit d'une simulation et la "charge utile" n'est pas un véritable assemblage.
  try {
      Write-Host "Exécution de l'étape encodée..."
      Write-Output $encodedCommand
  
      # Cette ligne est le déclencheur principal de la règle de détection
      $trigger = "[System.Reflection.Assembly]::Load"
      Write-Host "Tentative de chargement de l'assemblage via : $trigger"
  
      # Nous l'appelons via Invoke-Expression pour s'assurer qu'il apparaît dans le ScriptBlockText
      Invoke-Expression "Write-Host 'Déclenchement : $trigger'"
  }
  catch {
      Write-Error "La simulation n'a pas réussi à exécuter la chaîne de déclenchement."
  }

• Commandes de nettoyage :

  # Aucune modification permanente n'est faite par le script de simulation.
  # Simplement effacer la console et s'assurer qu'aucun processus persistant n'existe.
  Clear-Host
  Write-Host "Nettoyage de la simulation terminé. Aucun fichier déposé."