GlassWorm attaque Mac : Nouvelle infrastructure, nouvelles astuces

Résumé

L’acteur malveillant derrière GlassWorm a pivoté d’une activité axée sur Windows à macOS, distribuant des extensions malveillantes pour VS Code qui récupèrent des charges utiles JavaScript chiffrées grâce à des pointeurs C2 dérivés de la blockchain Solana. Cette vague étend les capacités en ajoutant la trojanisation de portefeuilles matériels tout en continuant de voler un large éventail d’identifiants à travers les navigateurs, les outils de développement et le Trousseau macOS. L’infrastructure inclut une adresse de portefeuille Solana et une IP réutilisée d’opérations précédentes de GlassWorm, suggérant une continuité dans les outils et l’hébergement de l’opérateur. Les chercheurs ont observé plus de 50 000 téléchargements avant que les extensions ne soient supprimées, indiquant une exposition significative dans les environnements de développement.

Enquête

Koi Security a identifié trois extensions malveillantes pour VS Code sur le marché Open VSX et a relié leur flux de commandement et de contrôle à un portefeuille Solana en plus d’une adresse IP partagée précédemment associée à GlassWorm. Les implants intègrent un délai d’exécution de 15 minutes, puis déchiffrent et exécutent une charge utile JavaScript AES-256-CBC. Sur macOS, la persistance est établie via LaunchAgents. Les cibles de collecte incluent les portefeuilles de navigateurs et les données de portefeuilles de bureau, les jetons d’accès aux développeurs, les clés SSH, et le matériel du Trousseau macOS. Le logiciel malveillant organise les données volées sous /tmp/ijewf/ avant leur exfiltration vers un chemin de serveur ressemblant à /p2p. Il tente également de remplacer les applications légitimes de compagnons de portefeuilles matériels—comme Ledger Live et Trezor Suite—par des versions trojanisées pour capturer des secrets et transactions de grande valeur.

Atténuation

Renforcez les contrôles entourant les outils de développement en appliquant une liste blanche d’extensions et en exigeant un examen de sécurité pour les extensions VS Code, notamment celles provenant de marchés ouverts. Déployez des détections à l’exécution pour les modèles d’exécution différée et la création ou modification suspecte de LaunchAgents. Surveillez et bloquez l’activité sortante suspecte associée aux recherches C2 dérivées de Solana, et ajoutez des détections de réseau pour les connexions inhabituelles à l’IP réutilisée identifiée. Exigez une authentification multi-facteurs pour les comptes de développeurs et de cloud et mettez en œuvre des vérifications d’intégrité des portefeuilles matériels (validation de l’éditeur, notarisation/vérification des signatures, et canaux de mise à jour logicielle contrôlés).

Réponse

Déclenchez des alertes sur les nouveaux ou modifiés LaunchAgents, l’accès anormal aux magasins de Trousseau, et les tentatives de récupération des points d’extrémité C2 référencés par Solana. Mettez en quarantaine et supprimez les extensions malveillantes pour VS Code, puis éradiquer toute persistance associée à LaunchAgent. Réalisez une analyse médico-légale ciblée sur /tmp/ijewf/ pour déterminer l’échelle de la mise en scène des identifiants et confirmer quelles données ont été collectées. Validez l’intégrité des applications de portefeuilles matériels (Ledger Live, Trezor Suite) et réinstallez à partir de sources fiables si l’on soupçonne une altération. Réinitialisez les identifiants touchés, faites tourner les clés SSH et les jetons de développeur, invalidez les sessions, et élargissez la chasse à travers les points d’extrémité pour les mêmes IDs d’extensions, chemins de fichiers, et artefacts de persistance.

Exécution de simulation

Prérequis : Vérification préliminaire de la télémétrie et de la base doit être réussie.

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 exactement la télémétrie attendue par la logique de détection. Des exemples abstraits ou non pertinents entraîneront un mauvais diagnostic.

• Récit de l’attaque & Commandes :
  Un attaquant qui a déjà compromis un compte utilisateur macOS aux privilèges faibles souhaite récupérer un mot de passe de compte de service stocké dans le Trousseau sous l’étiquette pass_users_for_script. Pour éviter de déposer un binaire séparé, l’attaquant écrit un AppleScript en une seule ligne qui invoque l’outil intégré security via do shell script. Le script est exécuté directement dans la session de l’utilisateur, produisant un événement de création de processus avec la ligne de commande exacte que la règle Sigma correspond.

  # Crée un élément de test dans le Trousseau (uniquement pour la démonstration; le véritable attaquant viserait un élément existant)
  security add-generic-password -a attacker -s pass_users_for_script -w SuperSecret123
  
  # Exécute l'AppleScript qui lit le mot de passe
  osascript -e 'do shell script "security find-generic-password -s '''pass_users_for_script''' -w"'

• Script de test de régression :

  #!/usr/bin/env bash
  set -euo pipefail
  
  # Étape 1 : S'assurer que l'entrée de Trousseau cible existe (idempotente)
  if ! security find-generic-password -s pass_users_for_script -w >/dev/null 2>&1; then
      security add-generic-password -a attacker -s pass_users_for_script -w SuperSecret123
  fi
  
  # Étape 2 : Exécuter l'AppleScript qui déclenche la règle de détection
  echo "[+] Exécution de l'AppleScript pour lire l'entrée du Trousseau..."
  osascript -e 'do shell script "security find-generic-password -s '''pass_users_for_script''' -w"'

• Commandes de nettoyage :

  # Supprimer l'élément de test du Trousseau pour laisser le système propre
  security delete-generic-password -s pass_users_for_script
  echo "[+] Nettoyage terminé : entrée de test du Trousseau supprimée."