Chargeur en mémoire installe ScreenConnect

Résumé

ThreatLabz a identifié une chaîne d’attaque en plusieurs étapes qui commence par un faux téléchargement d’Adobe Acrobat Reader et se termine par le déploiement de l’outil légitime d’accès à distance ScreenConnect. L’opération repose sur un chargeur VBScript fortement obscurci qui déclenche une commande PowerShell pour récupérer le code source C# depuis Google Drive, le compiler directement en mémoire, et lancer un chargeur .NET sans déposer la charge utile finale sur le disque. Ce chargeur applique ensuite un masquage de processus, modifie les structures du PEB, et utilise des objets COM auto-élévés pour obtenir des privilèges plus élevés avant d’installer ScreenConnect sur l’hôte victime.

Enquête

Les chercheurs ont décrit comment le VBScript assemble ses commandes par l’obfuscation Chr(), tandis que PowerShell récupère et compile la charge utile entièrement en mémoire pour minimiser les artefacts disque. Le chargeur .NET en mémoire utilise alors la réflexion pour exécuter un assembly intégré. Une analyse supplémentaire a montré que le malware appelait NtAllocateVirtualMemory, réécrivait les champs du PEB pour usurper winhlp32.exe, et exploitait l’auto-élévation COM pour contourner le contrôle de compte d’utilisateur et continuer l’exécution avec des privilèges élevés.

Atténuation

Les défenseurs devraient bloquer l’accès aux domaines de téléchargement malveillants et appliquer des contrôles stricts sur l’exécution de PowerShell et VBScript. Les équipes de sécurité devraient également surveiller la création suspecte d’objets COM, les modifications inattendues du PEB, et d’autres signes d’abus d’exécution en mémoire. L’accès aux outils d’administration à distance légitimes tels que ScreenConnect devrait être strictement limité aux utilisateurs approuvés et aux flux de travail de confiance pour réduire le risque d’installation non autorisée.

Réponse

Si cette activité est détectée, isolez immédiatement le système affecté, stoppez les processus malveillants, et supprimez toute composante ScreenConnect installée dans le cadre de l’intrusion. Réalisez une analyse forensique axée sur les artefacts de mémoire volatile pour récupérer des preuves de la chaîne d’exécution sans fichier. Réinitialisez les identifiants potentiellement exposés, examinez les journaux pour des abus d’auto-élévation COM, et mettez à jour les détections pour identifier les modèles de lignes de commande observés, le comportement des chargeurs, et les conventions de nommage de fichiers associées.

Exécution de simulation

Prérequis : Le vérificateur prévol de télémétrie et d’étalonnage doit avoir été validé.

Justification : Cette section détaille l’exécution précise de la technique (TTP) de l’adversaire 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 exactement la télémétrie attendue par la logique de détection.

• Récit de l’attaque et commandes :
  L’adversaire a obtenu le MSI ScreenConnect (souvent livré via une pièce jointe de phishing). Pour éviter l’interaction utilisateur, ils utilisent le binaire msiexec.exe de confiance pour effectuer une installation silencieuse. Ils démontrent également les alternatives ShellExec.exe proxy, qui transfère simplement les arguments à msiexec. Les deux commandes intègrent la chaîne littérale « ScreenConnect » dans la ligne de commande, satisfaisant la condition de la règle.

  1. Copier le MSI sur l’hôte victime (en simulant T1025).

  2. Effectuer une installation silencieuse via msiexec:

      msiexec.exe /i "C:TempScreenConnect.msi" /quiet /norestart

  3. Exécuter la même installation via ShellExec.exe (si présent sur l’hôte) :

      ShellExec.exe /i "C:TempScreenConnect.msi" /quiet /norestart

  Ces actions génèrent des entrées Windows Event 4688 où Image is *msiexec.exe or *ShellExec.exe and CommandLine contient « ScreenConnect », provoquant le déclenchement de la règle Sigma.

• Script de test de régression :

  #=============================================================
  # Simulation d'installation de ScreenConnect – déclenche la règle Sigma
  #=============================================================
  $msiPath = "C:TempScreenConnect.msi"
  
  # Assurez-vous que le MSI existe (espace réservé - dans un vrai test, déposez d'abord le fichier)
  if (-Not (Test-Path $msiPath)) {
      Write-Error "MSI ScreenConnect non trouvé à $msiPath"
      exit 1
  }
  
  # 1. Installation silencieuse à l'aide de msiexec
  Write-Host "[*] Installation de ScreenConnect via msiexec..."
  Start-Process -FilePath "$env:SystemRootSystem32msiexec.exe" `
                -ArgumentList "/i `"$msiPath`" /quiet /norestart" `
                -Wait -NoNewWindow
  
  # 2. Installation silencieuse à l'aide de ShellExec (si présent)
  $shellExec = "$env:ProgramFilesScreenConnectShellExec.exe"
  if (Test-Path $shellExec) {
      Write-Host "[*] Installation de ScreenConnect via ShellExec..."
      Start-Process -FilePath $shellExec `
                    -ArgumentList "/i `"$msiPath`" /quiet /norestart" `
                    -Wait -NoNewWindow
  } else {
      Write-Warning "ShellExec.exe non trouvé ; deuxième installation ignorée."
  }
  
  Write-Host "[+] Simulation terminée. Vérifiez votre SIEM pour l'alerte."

• Commandes de nettoyage :

  # Désinstaller ScreenConnect (utilise son GUID de produit enregistré ; ajuster si nécessaire)
  $productGuid = (Get-ItemProperty "HKLM:SoftwareMicrosoftWindowsCurrentVersionUninstall*" |
                  Where-Object { $_.DisplayName -like "*ScreenConnect*" }).PSChildName
  
  if ($productGuid) {
      Write-Host "[*] Désinstallation de ScreenConnect (GUID : $productGuid)..."
      & "$env:SystemRootSystem32msiexec.exe" /x $productGuid /quiet /norestart
  } else {
      Write-Warning "GUID du produit ScreenConnect non trouvé ; un nettoyage manuel peut être requis."
  }
  
  # Supprimer le fichier MSI copié
  Remove-Item -Path "C:TempScreenConnect.msi" -Force -ErrorAction SilentlyContinue
  Write-Host "[+] Nettoyage terminé."