Analyse Technique du MLTBackdoor

Résumé

Zscaler ThreatLabz a identifié une nouvelle famille de malwares, MLTBackdoor, en mai 2026. La menace est délivrée par une chaîne d’infection ClickFix en plusieurs étapes et semble être utilisée par des opérateurs de rançongiciels pour établir un accès initial et faciliter le mouvement latéral. Le malware s’appuie sur une forte obfuscation, un algorithme de génération de domaine, et un chargeur de Beacon Object File (BOF) pour étendre ses capacités après exécution. Ses communications réseau sont cryptées sur TLS et sont conçues pour ressembler au trafic légitime de Microsoft Delivery Optimization, aidant ainsi l’activité à se fondre dans le comportement réseau normal.

Enquête

L’analyse a suivi la chaîne d’infection jusqu’à un conhost.exe wrapper qui a téléchargé une archive compressée depuis un domaine généré par la logique DGA du malware. À l’intérieur de cette archive, endpointdlp.dll a déchiffré une charge utile cryptée RC4 qui a ensuite été chargée en tant que binaire MLTBackdoor. Les chercheurs ont découvert que le malware utilise l’arithmétique booléenne mixte, l’aplatissement du flux de contrôle, les appels système indirects, et un protocole de communication cryptée personnalisé pour empêcher l’analyse et la détection. Le chargeur intégré de BOF permet également aux opérateurs de faire fonctionner des modules supplémentaires de style Cobalt Strike en mémoire.

Atténuation

Les défenseurs devraient bloquer les domaines de commande et de contrôle identifiés et surveiller les motifs DGA associés. La détection devrait également se concentrer sur la chaîne d’agent utilisateur spécifique et le trafic TLS dirigé vers /api/v1/telemetry sur le port 443. Les équipes de sécurité devraient surveiller l’utilisation suspecte de conhost.exe avec les arguments documentés et pour la création de endpointdlp.dll dans les répertoires temporaires. Les détections basées sur le comportement pour le hachage d’API et l’utilisation d’appels système indirects peuvent améliorer davantage la visibilité de l’activité de MLTBackdoor.

Réponse

Si une activité MLTBackdoor est détectée, isolez immédiatement le point d’extrémité affecté, terminez le processus malveillant, et supprimez tous les fichiers déposés dans le répertoire Temp par le chargeur initial. Les enquêteurs devraient ensuite effectuer un examen médico-légal pour des modules BOF supplémentaires ou des charges utiles de suivi. Tout identifiant potentiellement exposé devrait être réinitialisé, et la chasse aux menaces devrait être étendue pour identifier les tentatives de mouvement latéral utilisant le même savoir-faire.

Exécution de Simulation

Condition Préalable : Le Test Préliminaire de Télémétrie & Recueil des Données de Référence doit avoir réussi.

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 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 liés conduiront à un diagnostic erroné.

• Narratif de l’Attaque & Commandes :

  1. Reconnaissance – Résolution du domaine DGA – Le backdoor génère une requête DNS pour hrs2y15sungu.com, un domaine produit par son DGA interne.
  2. Contact C2 – Ouvrir un socket TCP – En utilisant PowerShell, l’adversaire crée une connexion TCP brute à l’IP résolue sur le port 443 (HTTPS) pour se fondre dans le trafic normal.
  3. Récupération de Charge Utile (T1105) – Sur le même socket, le backdoor récupérerait des modules additionnels ; pour le test, nous envoyons simplement une chaîne inoffensive.

  Ces étapes émettent un enregistrement d’Événement Sysmon ID 3 avec DestinationHostname = hrs2y15sungu.com, satisfaisant la règle de Sigma pour la sélection condition.

• Script de Test de Régression :

  # TC-20260610-A7B3Z – Simuler la communication C2 de MLTBackdoor
  # -------------------------------------------------------
  # 1. Résoudre le domaine malveillant (sortie simulée du DGA)
  $malDomain = "hrs2y15sungu.com"
  try {
   $ip = [System.Net.Dns]::GetHostAddresses($malDomain)[0].IPAddressToString
  } catch {
   Write-Error "Échec de la résolution de $malDomain – annulation du test."
   exit 1
  }
  
  # 2. Ouvrir une connexion TCP à l'IP résolue sur le port 443
  $port = 443
  $client = New-Object System.Net.Sockets.TcpClient
  $client.Connect($ip, $port)
  
  # 3. Envoyer une charge utile inoffensive (simulant la récupération de module)
  $stream = $client.GetStream()
  $payload = [System.Text.Encoding]::ASCII.GetBytes("TEST_PAYLOAD")
  $stream.Write($payload, 0, $payload.Length)
  
  # 4. Garder la connexion ouverte brièvement pour garantir la génération de journaux
  Start-Sleep -Seconds 5
  
  # 5. Nettoyage
  $stream.Close()
  $client.Close()
  Write-Output "Simulation terminée – connexion à $malDomain ($ip:$port) fermée."

• Commandes de Nettoyage :

  # Assurez-vous qu'aucun socket persistant ne reste (au cas où le script s'est arrêté)
  Get-NetTCPConnection -RemotePort 443 |
   Where-Object { $_.RemoteAddress -eq (Resolve-DnsName hrs2y15sungu.com).IPAddress } |
   ForEach-Object { Stop-Process -Id $_.OwningProcess -Force }