Abyssos : Analyse Technique d’un Nouveau RAT Modulaire
Detection stack
- AIDR
- Alert
- ETL
- Query
Résumé
Abyssos est un outil d’administration à distance (RAT) modulaire récemment découvert, développé en C++. Il offre des capacités avancées telles que le vol d’informations d’identification, l’exfiltration de fichiers et l’accès à distance via VNC. Le malware utilise également des méthodes sophistiquées d’obfuscation, y compris des passes IR basées sur LLVM, pour compliquer l’analyse et la détection de sécurité.
Enquête
Zscaler ThreatLabz a effectué une analyse technique de la version 2.4F d’Abyssos, examinant ses mécanismes d’antianalyse, son protocole réseau et son architecture de commande. L’enquête a révélé une communication TCP personnalisée, un chiffrement AES-GCM et de multiples composants modulaires récupérés à partir de serveurs C2. Les chercheurs ont également identifié des vérifications anti-hyperviseur dédiées ainsi que des schémas de dénomination de mutex distinctifs.
Atténuation
Les organisations devraient déployer des contrôles de sécurité des terminaux capables d’identifier l’obfuscation basée sur LLVM et un comportement de processus anormal. Les équipes de sécurité devraient surveiller les sessions VNC non autorisées et l’activité suspecte des fichiers dans les répertoires temporaires de Windows. Il est également recommandé de restreindre les connexions sortantes vers des adresses IP C2 inconnues et de détecter des arguments de ligne de commande inhabituels tels que --elevated est également conseillé.
Réponse
Si une activité Abyssos est détectée, les intervenants en cas d’incident devraient isoler immédiatement l’hôte affecté pour interrompre la communication C2 et limiter le mouvement latéral. Des analyses de la mémoire devraient être effectuées pour récupérer les modules déchiffrés et déterminer quelles commandes ont été exécutées. Les journaux réseau devraient également être vérifiés pour les adresses IP C2 connues afin d’évaluer l’étendue de la violation et d’identifier une éventuelle exfiltration de données.
Flux d’Attaque
Détections
Utilisation possible de PING pour retarder l’exécution (via cmdline)
IOC (HashSha256) pour détecter : Abyssos : Analyse technique d’un nouveau RAT modulaire
IOC (SourceIP) pour détecter : Abyssos : Analyse technique d’un nouveau RAT modulaire
IOC (DestinationIP) pour détecter : Abyssos : Analyse technique d’un nouveau RAT modulaire
Détection d’antianalyse Abyssos [Création de processus Windows]
Exécution de la simulation
Prérequis : La vérification de télémétrie et de base doit avoir été réalisée avec succès.
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 la narration DOIVENT refléter directement les TTP identifiés et viser à générer la télémétrie exacte attendue par la logique de détection. Les exemples abstraits ou non liés entraîneront un mauvais diagnostic.
-
Narratif de l’attaque et commandes : L’adversaire vise à déployer le RAT Abyssos. Pour garantir que le malware ne s’exécute qu’une seule fois et pour identifier son environnement, le charge utile exécute une commande qui imite le comportement du malware. Premièrement, l’attaquant simule la présence d’un service VM en référenciant
vmtoolsd.exe. Deuxièmement, l’attaquant tente de déclencher la logique secondaire de détection en créant un Mutex Global unique au format UUID tout en passant simultanément le--elevateddrapeau via un argument de ligne de commande. Cela simule la tentative du malware d’établir un verrou d’instance unique pendant sa phase d’antianalyse. -
Script de test de régression :
# Script de simulation Abyssos # Ce script simule deux chemins de détection : # 1. Correspondance du nom de processus (vmtoolsd.exe) # 2. Modèle de mutex + commande '--elevated' Write-Host "[+] Début de la simulation Abyssos..." -ForegroundColor Cyan # Chemin 1 : Simuler la détection du processus VM (Remarque : Cela suppose que nous puissions déclencher un événement de création de processus # qui 'se termine par' vmtoolsd.exe. Dans un vrai test, nous pourrions renommer un outil bénin à cette fin.) # À des fins de simulation, nous utilisons un fichier fictif pour déclencher la logique 'Image' si la règle le permet. # Comme nous ne pouvons pas facilement 'créer' un vrai vmtoolsd.exe sans admin/installation, nous simulons la logique de la ligne de commande. # Chemin 2 : Simuler la logique Mutex + Commande $uuid = [guid]::NewGuid().ToString() $mutexName = "Global$uuid" $commandLine = "malware_payload.exe --elevated" Write-Host "[+] Création du Mutex : $mutexName" -ForegroundColor Yellow # Nous utilisons un petit extrait de code C# via PowerShell pour créer le Mutex Global spécifique requis $code = @" using System; using System.Threading; public class CreateMutex { public static void Run(string name) { Mutex m = new Mutex(true, name); Console.WriteLine("Mutex créé : " + name); // Gardez-le en vie brièvement pour la capture de télémétrie Thread.Sleep(5000); m.ReleaseMutex(); } } "@ Add-Type -TypeDefinition $code # Déclenchement de la logique de ligne de commande (Simulé via un processus qui transporterait cette ligne) # Dans un environnement réel, la détection observe la création du processus. # Ici, nous simulons la création d'un processus avec la chaîne cible. Write-Host "[+] Simulation de l'exécution du processus avec le drapeau '--elevated'..." -ForegroundColor Yellow Start-Process "cmd.exe" -ArgumentList "/c echo $commandLine" -WindowStyle Hidden # Exécution de la création de Mutex Write-Host "[+] Simulation terminée." -ForegroundColor Green -
Commandes de nettoyage :
# Nettoyage : Aucun fichier permanent n’a été créé, mais nous nous assurons de fermer tous les processus orphelins. Stop-Process -Name "cmd" -ErrorAction SilentlyContinue Write-Host "[+] Nettoyage terminé." -ForegroundColor Cyan