À l’intérieur d’un Proxy et RAT basé sur Deno
Detection stack
- AIDR
- Alert
- ETL
- Query
Résumé
Un attaquant a déployé un cheval de Troie d’accès à distance (RAT) modulaire et un cadre proxy exploitant le runtime JavaScript Deno. L’attaque a utilisé le bombardement de courriels et l’usurpation de Microsoft Teams pour faciliter le téléchargement d’une archive malveillante. L’implant fonctionne via plusieurs fichiers JavaScript modulaires qui utilisent des indicateurs de permission Deno spécifiques pour effectuer la communication C2, l’exécution de commandes locales et le pivotement du réseau.
Enquête
L’enquête a révélé une phase d’accès initial consistant en un inondation de courriels et une ingénierie sociale via Microsoft Teams. Le malware a été identifié comme un système non traditionnel, modulaire basé sur Deno, divisé en quatre scripts : app.js, back.js, helper.js et webui.js. La détection a eu lieu lors des activités de reconnaissance post-exploitation plutôt qu’à l’exécution initiale.
Atténuation
Les organisations devraient surveiller l’exécution de runtimes de script comme Deno à partir de répertoires accessibles en écriture par les utilisateurs et alerter sur les indicateurs de permission suspects tels que –allow-run ou –allow-net. La mise en œuvre d’une surveillance des services HTTP en boucle locale et la corrélation des alertes d’usurpation d’identité Teams avec les anomalies de courriel est recommandée. De plus, restreindre la capacité à exécuter des runtimes non signés ou non approuvés peut réduire la surface d’attaque.
Réponse
À la détection, les intervenants devraient isoler les hôtes affectés et enquêter sur la source de l’usurpation de Teams. L’analyse devrait se concentrer sur la lignée des processus Deno et tout service local lié aux ports en boucle 10021 ou 10022. Examiner les journaux d’audit unifié Microsoft 365 pour les événements TeamsImpersonationDetected est crucial pour déterminer l’étendue de la campagne d’ingénierie sociale.
Flux d’attaque
Détections
Points de persistance possibles [ASEPs – Software/NTUSER Hive] (via registry_event)
Voir
Points de persistance possibles [ASEPs – Software/NTUSER Hive] (via cmdline)
Voir
Tentative possible d’abus de Deno Runtime (via process_creation)
Voir
Découverte possible de la configuration réseau du système (via cmdline)
Voir
LOLBAS Conhost (via cmdline)
Voir
IOCs (HashSha256) à détecter : Anatomie d’un proxy et RAT basés sur Deno
Voir
Détecter l’exécution de commandes Shell par Deno [Windows Sysmon]
Voir
Détecter l’exécution de RAT basé sur Deno avec des indicateurs de permission suspects [Création de processus Windows]
Voir
Exécution de la simulation
Prérequis : La vérification télémétrique et de base doit avoir été 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 la narration DOIVENT directement refléter les TTPs 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 mèneront à un diagnostic erroné.
-
Narration d’attaque et commandes : L’adversaire a réussi à livrer un RAT malveillant basé sur Deno sur la machine de la victime via une pièce jointe de spearphishing (T1566.004). Pour échapper à l’antivirus basé sur les signatures traditionnelles, l’attaquant cache le binaire Deno dans un sous-répertoire profond et non standard du profil de navigation de l’utilisateur :
C:Usersuser.nameAppDataRoamingDenoJSEnv. L’attaquant exécute ensuite le binaire en utilisant les--allow-runand--allow-netindicateurs. Cela permet au malware basé sur JavaScript d’exécuter des commandes shell arbitraires pour la découverte du système (T1082) et de communiquer avec un serveur C2 externe sur HTTPS (T1071.001). -
Script de test de régression :
# Remarque : Ce script simule l'existence du répertoire et du binaire # pour déclencher la logique de la règle. Dans un vrai test, le fichier doit exister exactement à ce chemin. $targetDir = "C:Usersuser.nameAppDataRoamingDenoJSEnv" $targetExe = "$targetDirdeno.exe" # 1. Créez la structure de répertoire spécifique requise par la règle de détection if (!(Test-Path $targetDir)) { New-Item -ItemType Directory -Force -Path $targetDir } # 2. Créez un fichier factice pour agir comme le 'deno.exe' # Dans une simulation réelle, ce serait le binaire Deno réel. New-Item -ItemType File -Force -Path $targetExe # 3. Exécuter la commande 'malveillante' # Nous utilisons Start-Process pour garantir qu'il apparaît comme un processus enfant dans les journaux Sysmon. # Étant donné que 'deno.exe' est factice, nous appellerons 'cmd.exe' mais masquerons la chaîne de commande # pour correspondre à la logique, OU si vous testez la règle ACTUELLE, assurez-vous que le binaire # est réel et appelez-le. Pour cette simulation, nous supposons que l'utilisateur fournit un # binaire Deno réel à ce chemin. Write-Host "[!] Simulation de l'exécution de $targetExe avec des indicateurs malveillants..." Start-Process -FilePath "cmd.exe" -ArgumentList "/c echo Simulation Triggering Rule..." # Remarque : Pour déclencher réellement la règle, le deno.exe réel doit être présent. # Si la règle recherche strictement le chemin de l'image, le binaire DOIT être là. # Pour le bien d'un script de simulation fonctionnel, nous appelons le chemin : # Start-Process -FilePath $targetExe -ArgumentList "--allow-run --allow-net" -
Commandes de nettoyage :
# Supprimer le répertoire et les fichiers malveillants simulés Remove-Item -Path "C:Usersuser.nameAppDataRoamingDenoJSEnv" -Recurse -Force Write-Host "[+] Nettoyage terminé."