Les Dossiers Aurora : À l’intérieur d’une Enquête de Haut Niveau sur un Logiciel Malveillant

Résumé

Un affilié russophone du ransomware Aurora a mené des opérations extensives ciblant plus de vingt organisations. L’attaquant utilise des outils assistés par IA tels que Cursor pour la planification des attaques et déploie des chiffreurs personnalisés basés sur Zig dans les environnements Windows et Linux/ESXi. La campagne combine un déplacement latéral sophistiqué, l’exploitation d’ADCS, et un réseau complexe de blanchiment de cryptomonnaies.

Enquête

CloudSEK a découvert un répertoire ouvert exposé associé à l’opérateur qui contenait l’historique des commandes, des outils personnalisés et des informations d’identification. En collaboration avec TRM Labs, les enquêteurs ont retracé les paiements de rançon sur la blockchain et identifié des infrastructures de blanchiment partagées utilisées auprès de plusieurs victimes. L’enquête a également révélé l’utilisation d’un assistant de codage agentique pour générer des plans d’exploitation écrits en russe.

Atténuation

Les organisations devraient désactiver LLMNR/NBT-NS, appliquer la signature SMB, et auditer les modèles ADCS pour les mauvaises configurations ESC1, ESC6 et ESC8. L’infrastructure de sauvegarde doit être isolée de l’Active Directory de production, et krbtgt les informations d’identification doivent être renouvelées après une compromission suspectée. Il est également recommandé de surveiller l’accès à grande échelle aux répertoires de profils de navigateur pour réduire le risque de vol d’informations d’identification.

Réponse

Si une activité Aurora est détectée, les organisations doivent immédiatement isoler les systèmes affectés et segmenter l’infrastructure de sauvegarde. Les répondants aux incidents doivent auditer les services de certificat Active Directory et renouveler les identifiants très privilégiés, y compris le krbtgt compte. Les enquêtes doivent également identifier les modifications non autorisées de la configuration SSH et les redémarrages de services inhabituels sur les hôtes Linux ou ESXi.

Exécution de simulation

Condition préalable : Le contrôle prévol des télémétrie et de la base de référence doit avoir été passé.

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 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 entraîneront des erreurs de diagnostic.

• Récit d’attaque & Commandes : L’adversaire a obtenu un accès root à un environnement Linux de type ESXi. Leur objectif est de maximiser l’impact psychologique en s’assurant que la note de rançon soit la première chose qu’un administrateur système voit. Ils exécutent une séquence en trois étapes : d’abord, ils ajoutent une directive à /etc/ssh/sshd_config pour pointer vers une bannière personnalisée ; ensuite, ils créent le fichier sshd-banner contenant le texte de la rançon ; enfin, ils utilisent le gestionnaire de services init.d pour redémarrer le service SSH, garantissant que les modifications prennent effet. Cette séquence spécifique est conçue pour être « bruyante » dans son intention mais « silencieuse » pour les AV basés sur les signatures qui ne recherchent que les écritures de fichiers.

• Script de test de régression :

  #!/bin/bash
  # Script de simulation Aurora Locker
  # Ce script imite les chaînes de commandes spécifiques requises pour déclencher la règle Sigma.
  
  echo "[+] Démarrage de la simulation de l'Aurora Locker..."
  
  # 1. Modifier sshd_config (Sélection : selection_config)
  echo "Banner /etc/ssh/sshd-banner" >> /etc/ssh/sshd_config
  echo "[*] Modifié /etc/ssh/sshd_config"
  
  # 2. Créer le fichier de la bannière (Sélection : selection_banner_file)
  echo "VOS FICHIERS SONT CHIFFRÉS ! PAYEZ BTC À..." > /etc/ssh/sshd-banner
  echo "[*] Créé sshd-banner"
  
  # 3. Redémarrer SSH en utilisant init.d (Sélection : selection_restart)
  # Remarque : Nous utilisons les chaînes exactes 'init.d', 'SSH', et 'restart' pour satisfaire la condition 'all'.
  /etc/init.d/SSH restart
  echo "[*] Exécuté /etc/init.d/SSH restart"
  
  echo "[+] Simulation complète. Vérifiez les alertes dans le SIEM."

• Commandes de nettoyage :

  #!/bin/bash
  # Script de nettoyage pour restaurer l'état du système
  echo "[+] Nettoyage des artefacts de simulation..."
  
  # Supprimer le fichier de la bannière
  rm -f /etc/ssh/sshd-banner
  
  # Rétablir sshd_config (Note : Dans un véritable environnement, utiliser sed ou un édit manuel)
  # Pour les besoins de la simulation, nous commenterons la ligne de la bannière
  sed -i '/Banner /etc/ssh/sshd-banner/d' /etc/ssh/sshd_config
  
  # Redémarrer normalement le service pour assurer l'accès
  systemctl restart ssh
  
  echo "[+] Nettoyage complet."