GlassWorm auf dem Mac: Neue Infrastruktur, neue Tricks

Zusammenfassung

Der Bedrohungsakteur hinter GlassWorm hat sich von Windows-zentrierter Aktivität auf macOS umorientiert und verteilt bösartige VS Code-Erweiterungen, die verschlüsselte JavaScript-Nutzlasten über Solana-Blockchain-abgeleitete C2-Zeiger abrufen. Diese Welle erweitert die Fähigkeiten durch das Trojanisieren von Hardware-Wallets und setzt den umfassenden Diebstahl von Zugangsdaten über Browser, Entwicklerwerkzeuge und den macOS-Schlüsselbund fort. Die Infrastruktur umfasst eine Solana-Wallet-Adresse und eine IP, die aus früheren GlassWorm-Operationen wiederverwendet wurde, was auf eine Kontinuität der Betreiberwerkzeuge und des Hostings hindeutet. Forscher beobachteten über 50.000 Downloads, bevor die Erweiterungen entfernt wurden, was auf eine bedeutende Verbreitung in Entwicklerumgebungen hinweist.

Untersuchung

Koi Security identifizierte drei bösartige VS Code-Erweiterungen auf dem Open VSX-Marktplatz und verknüpfte deren Command-and-Control-Workflow mit einer Solana-Wallet sowie einer gemeinsam genutzten IP-Adresse, die zuvor mit GlassWorm in Verbindung gebracht wurde. Die Implantate beinhalten eine Ausführungsverzögerung von 15 Minuten, um dann eine AES-256-CBC-JavaScript-Nutzlast zu entschlüsseln und auszuführen. Auf macOS wird die Persistenz über LaunchAgents hergestellt. Ziel der Sammlung sind Wallet-Daten und Desktop-Wallet-Daten, Entwicklerzugangstoken, SSH-Schlüssel und Materialien aus dem macOS-Schlüsselbund. Die Malware speichert gestohlene Daten unter /tmp/ijewf/ vor der Exfiltration zu einem Serverpfad, der /p2p ähnelt. Sie versucht auch, legitime Hardware-Wallet-Begleit-Apps wie Ledger Live und Trezor Suite durch trojanisierte Nachbildungen zu ersetzen, um wertvolle Geheimnisse und Transaktionen zu erfassen.

Minderung

Verstärken Sie die Kontrollen rund um Entwicklerwerkzeuge, indem Sie die Zulassung von Erweiterungen durchsetzen und eine Sicherheitsüberprüfung von VS Code-Erweiterungen verlangen, insbesondere solchen, die aus offenen Marktplätzen stammen. Implementieren Sie Laufzeit-Erkennungen für verzögerte Ausführungsmuster und verdächtige Erstellung oder Änderung von LaunchAgents. Überwachen und blockieren Sie verdächtige ausgehende Aktivitäten im Zusammenhang mit Solana-abgeleiteten C2-Suchen und fügen Sie Netzwerkerkennungen für ungewöhnliche Verbindungen zur identifizierten wiederverwendeten IP hinzu. Verlangen Sie MFA für Entwickler- und Cloud-Konten und implementieren Sie Integritätsprüfungen für Hardware-Wallets (Verlagsvalidierung, Notarisierung/Signaturüberprüfung und kontrollierte Software-Update-Kanäle).

Reaktion

Lösen Sie Warnungen bei neuen oder modifizierten LaunchAgents, anomalen Zugriffen auf Schlüsselbundspeicher und Abrufversuchen von Solana-referenzierten C2-Endpunkten aus. Quarantäne und entfernen Sie die bösartigen VS Code-Erweiterungen, dann beseitigen Sie jede zugehörige LaunchAgent-Persistenz. Führen Sie gezielte forensische Untersuchungen auf /tmp/ijewf/ durch, um das Stadium der Zugangsdaten zu bestimmen und zu bestätigen, welche Daten gesammelt wurden. Validieren Sie die Integrität von Hardware-Wallet-Anwendungen (Ledger Live, Trezor Suite) und installieren Sie sie von vertrauenswürdigen Quellen neu, wenn eine Manipulation vermutet wird. Setzen Sie betroffene Zugangsdaten zurück, rotieren Sie SSH-Schlüssel und Entwickler-Token, stornieren Sie Sitzungen und erweitern Sie die Jagd über Endpunkte für dieselben Erweiterungs-IDs, Dateipfade und Persistenzartefakte.

Simulationsausführung

Voraussetzung: Der Telemetrie- & Basislinien-Pre-Flight-Check muss bestanden sein.

Begründung: Dieser Abschnitt beschreibt die genaue Ausführungstechnik des Gegnerverfahrens (TTP), die entwickelt wurde, um die Erkennungsregel auszulösen. Die Befehle und die Erzählstruktur MÜSSEN direkt die identifizierten TTPs widerspiegeln und darauf abzielen, die genaue Telemetrie zu erzeugen, die von der Erkennungslogik erwartet wird. Abstrakte oder nicht verwandte Beispiele führen zu Fehldiagnosen.

• Angriffs-Narrativ & Befehle:
  Ein Angreifer, der bereits ein kompromittiertes macOS-Benutzerkonto mit niedrigen Berechtigungen besitzt, möchte ein Dienstkonto-Passwort ernten, das im Schlüsselbund unter dem Label gespeichert ist pass_users_for_script. Um das Ablegen eines separaten Binaries zu vermeiden, schreibt der Angreifer ein Einzeilen-AppleScript, das das eingebaute security Tool über do shell scriptaufruft. Das Skript wird direkt in der Sitzung des Nutzers ausgeführt und erzeugt ein Prozess-Erstellungsereignis mit der genauen Befehlszeile, die die Sigma-Regel erfüllt.

  # Ein Test-Schlüsselbund-Element erstellen (nur zur Demonstration; echter Angreifer würde ein bestehendes Ziel anvisieren)
  security add-generic-password -a attacker -s pass_users_for_script -w SuperSecret123
  
  # Das AppleScript ausführen, das das Passwort ausliest
  osascript -e 'do shell script "security find-generic-password -s '''pass_users_for_script''' -w"'

• Regressionstest-Skript:

  #!/usr/bin/env bash
  set -euo pipefail
  
  # Schritt 1: Sicherstellen, dass der Ziel-Schlüsselbundeintrag existiert (idempotent)
  if ! security find-generic-password -s pass_users_for_script -w >/dev/null 2>&1; then
      security add-generic-password -a attacker -s pass_users_for_script -w SuperSecret123
  fi
  
  # Schritt 2: Das AppleScript ausführen, das die Erkennungsregel auslöst
  echo "[+] AppleScript ausführen, um den Schlüsselbundeintrag zu lesen..."
  osascript -e 'do shell script "security find-generic-password -s '''pass_users_for_script''' -w"'

• Bereinigung-Befehle:

  # Das Test-Schlüsselbund-Element entfernen, um das System sauber zu hinterlassen
  security delete-generic-password -s pass_users_for_script
  echo "[+] Bereinigung abgeschlossen: Test-Schlüsselbundeintrag entfernt."