In-Memory Loader bringt ScreenConnect zur Ausführung

Zusammenfassung

ThreatLabz identifizierte eine mehrstufige Angriffskette, die mit einem gefälschten Adobe Acrobat Reader-Download beginnt und in der Bereitstellung des legitimen Fernzugriffstools ScreenConnect gipfelt. Der Angriff verwendet einen stark verschleierten VBScript-Loader, der einen PowerShell-Befehl auslöst, um C#-Quellcode von Google Drive abzurufen, ihn direkt im Speicher zu kompilieren und einen .NET-Loader zu starten, ohne den endgültigen Payload auf die Festplatte abzulegen. Dieser Loader wendet dann Prozessmaskierung an, ändert PEB-Strukturen und missbraucht auto-elevierte COM-Objekte, um höhere Privilegien zu erlangen, bevor ScreenConnect auf dem Opferhost installiert wird.

Untersuchung

Forscher beschrieben, wie das VBScript seine Befehle durch Chr()-Obfuskation zusammenstellt, während PowerShell den Payload vollständig im Speicher abruft und kompiliert, um Festplattenartefakte zu minimieren. Der im Speicher befindliche .NET-Loader verwendet dann Reflection, um ein eingebettetes Assembly auszuführen. Zusätzliche Analysen zeigten, dass die Malware NtAllocateVirtualMemory aufruft, PEB-Felder umschreibt, um winhlp32.exe zu imitieren, und COM-Autoaushöhlung nutzt, um die Benutzerkontensteuerung zu umgehen und die Ausführung mit erhöhten Privilegien fortzusetzen.

Minderung

Verteidiger sollten den Zugriff auf die bösartigen Download-Domains blockieren und strenge Kontrollen für PowerShell- und VBScript-Ausführungen anwenden. Sicherheitsteams sollten auch die Erstellung verdächtiger COM-Objekte, unerwartete PEB-Manipulationen und andere Anzeichen von missbräuchlicher In-Memory-Ausführung überwachen. Der Zugriff auf legitime Fernverwaltungstools wie ScreenConnect sollte streng auf genehmigte Benutzer und vertrauenswürdige Arbeitsabläufe beschränkt werden, um das Risiko einer unbefugten Installation zu verringern.

Reaktion

Wenn diese Aktivität erkannt wird, sollte das betroffene System sofort isoliert, die bösartigen Prozesse gestoppt und alle im Rahmen des Einbruchs installierten ScreenConnect-Komponenten entfernt werden. Führen Sie eine forensische Analyse durch, die sich auf flüchtige Speicher-Artefakte konzentriert, um Beweise für die dateilose Ausführungskette zu sammeln. Setzen Sie möglicherweise betroffene Anmeldeinformationen zurück, prüfen Sie Protokolle auf COM-Autoaushöhlung-Missbrauch und aktualisieren Sie Erkennungen, um die beobachteten Befehlszeilenmuster, Loader-Verhalten und zugehörige Dateibenennungskonventionen zu identifizieren.

Simulationsausführung

Voraussetzung: Der Telemetrie- und Basislinien-Vorabflug-Check muss bestanden werden.

Begründung: Dieser Abschnitt beschreibt die genaue Ausführung der gegnerischen Technik (TTP), die dazu bestimmt ist, die Erkennungsregel auszulösen. Die Befehle und Erzählungen MÜSSEN direkt die identifizierten TTP widerspiegeln und darauf abzielen, die genaue Telemetrie zu erzeugen, die von der Erkennungslogik erwartet wird.

• Angriffserzählung & Befehle:
  Der Angreifer hat das ScreenConnect MSI erhalten (oft über Phishing-Anhang geliefert). Um Benutzerinteraktion zu vermeiden, verwenden sie die vertrauenswürdige msiexec.exe -Binärdatei für eine stille Installation. Sie demonstrieren auch die alternative ShellExec.exe -Proxy, der einfach Argumente an msiexecweiterleitet. Beide Befehle betten den wörtlichen String „ScreenConnect“ in die Befehlszeile ein, was die Bedingung der Regel erfüllt.

  1. Kopiere die MSI auf den Opferhost (Simulation von T1025).

  2. Führen Sie eine stille Installation über msiexec:

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

  3. Führen Sie die gleiche Installation über ShellExec.exe (wenn auf dem Host vorhanden):

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

  Diese Aktionen erzeugen Windows Event 4688-Einträge, bei denen Image is *msiexec.exe or *ShellExec.exe and CommandLine „ScreenConnect“ enthält, was die Sigma-Regel auslöst.

• Regressionstest-Skript:

  #=============================================================
  # ScreenConnect Installationssimulation – löst Sigma-Regel aus
  #=============================================================
  $msiPath = "C:TempScreenConnect.msi"
  
  # Stellen Sie sicher, dass die MSI-Datei vorhanden ist (Platzhalter – in einem echten Test legen Sie die Datei zuerst ab)
  if (-Not (Test-Path $msiPath)) {
      Write-Error "ScreenConnect MSI nicht unter $msiPath gefunden"
      exit 1
  }
  
  # 1. Stille Installation mit msiexec
  Write-Host "[*] Installiere ScreenConnect über msiexec..."
  Start-Prozess -DateiPfad "$env:SystemRootSystem32msiexec.exe" `
                -ArgumentListe "/i `"$msiPath`" /quiet /norestart" `
                -Warte -KeinNeuesFenster
  
  # 2. Stille Installation mit ShellExec (falls vorhanden)
  $shellExec = "$env:ProgramFilesScreenConnectShellExec.exe"
  if (Test-Path $shellExec) {
      Write-Host "[*] Installiere ScreenConnect über ShellExec..."
      Start-Prozess -DateiPfad $shellExec `
                    -ArgumentListe "/i `"$msiPath`" /quiet /norestart" `
                    -Warte -KeinNeuesFenster
  } else {
      Write-Warning "ShellExec.exe nicht gefunden; zweite Installation übersprungen."
  }
  
  Write-Host "[+] Simulation abgeschlossen. Überprüfen Sie Ihr SIEM auf den Alarm."

• Befehle zur Bereinigung:

  # Deinstalliere ScreenConnect (verwendet seine registrierte Produkt-GUID; bei Bedarf anpassen)
  $productGuid = (Get-ItemProperty "HKLM:SoftwareMicrosoftWindowsCurrentVersionUninstall*" |
                  Where-Object { $_.DisplayName -like "*ScreenConnect*" }).PSChildName
  
  if ($productGuid) {
      Write-Host "[*] Deinstalliere ScreenConnect (GUID: $productGuid)..."
      & "$env:SystemRootSystem32msiexec.exe" /x $productGuid /quiet /norestart
  } else {
      Write-Warning "ScreenConnect-Produkt-GUID nicht gefunden; manuelle Bereinigung möglicherweise erforderlich."
  }
  
  # Löschen Sie die kopierte MSI-Datei
  Remove-Item -Path "C:TempScreenConnect.msi" -Force -ErrorAction SilentlyContinue
  Write-Host "[+] Bereinigung abgeschlossen."