Neue Trojaner-Kampagne verbreitet sich über Social Engineering mit missbrauchten Obsidian-Plugins

 (cyber.netsecops.io)
3 Punkte von GN⁺ 2026-05-11 | 1 Kommentare | Auf WhatsApp teilen
  • Es wurde eine hochgradig gezielte Kampagne entdeckt, die auf Beschäftigte der Finanz- und Kryptobranche abzielt, die Shared-Vault-Funktion der Notiz-App Obsidian bewaffnet und einen bislang nicht dokumentierten neuen Remote-Access-Trojaner (RAT) verbreitet
  • Die Angreifer gaben sich auf LinkedIn und Telegram als Venture-Capital-Investoren aus, bauten Vertrauen auf und lockten die Opfer anschließend in einen bösartigen geteilten Obsidian-Vault
  • Wenn das Opfer die Synchronisierung von Community-Plugins manuell bestätigt, wird Schadcode ausgeführt; unter Windows wird über PowerShell, unter macOS über AppleScript der PHANTOMPULL-Loader abgelegt
  • Der PHANTOMPULSE RAT extrahiert die Adresse des C2-Servers dynamisch aus Ethereum-Blockchain-Transaktionsdaten und ist dadurch deutlich widerstandsfähiger gegen herkömmliche Takedown-Methoden
  • Als plattformübergreifender Angriff, der sowohl Windows als auch macOS unterstützt, ermöglicht er umfassende Fernsteuerung einschließlich Tastatureingaben erfassen, Screenshots, Dateiexfiltration und Ausführung beliebiger Befehle

Bedrohungsübersicht

  • Dieser als REF6598 bezeichnete Angriff ist eine mehrstufige Social-Engineering-Kampagne
  • Der Bedrohungsakteur nähert sich den Zielen auf professionellen Networking-Plattformen, indem er sich als Venture-Capital-Investor ausgibt, und verlagert das Gespräch anschließend in eine private Telegram-Gruppe
  • Der zentrale Köder ist eine Einladung zur Zusammenarbeit über einen cloudgehosteten Obsidian Shared Vault
  • Öffnet das Opfer den Shared Vault, wird es dazu verleitet, die Synchronisierungsfunktion für "Installed community plugins" zu aktivieren
    • Diese Bestätigung muss manuell erfolgen und ist der zentrale Auslöser der Infektion
    • Nach der Aktivierung werden bösartig manipulierte Versionen legitimer, im Shared Vault enthaltener Plugins ("Shell Commands", "Hider") ausgeführt

Technische Analyse

  • Die Angriffskette unterscheidet sich unter Windows und macOS leicht, folgt aber demselben Prinzip
  • Initial Access (T1566.002): Durch Social Engineering auf LinkedIn/Telegram werden die Opfer dazu verleitet, einen bösartigen Obsidian Shared Vault zu öffnen
  • Execution (T1204.002): Die Benutzer werden manipuliert, Community-Plugins in Obsidian zu aktivieren; über das manipulierte Plugin "Shell Commands" werden bösartige Skripte ausgeführt
  • Staging: Unter Windows wird ein PowerShell-Skript ausgeführt, das einen Loader namens PHANTOMPULL ablegt; unter macOS läuft ein ähnlicher Prozess über AppleScript
  • Payload Delivery: Der PHANTOMPULL-Loader lädt die endgültige Payload, den PHANTOMPULSE RAT, direkt in den Speicher, um dateibasierte Erkennung zu umgehen (T1055 Process Injection)
  • C2-Kommunikation (T1102.002): PHANTOMPULSE ruft die neueste Transaktion einer fest eincodierten Wallet-Adresse aus der Ethereum-Blockchain ab, um die IP-Adresse des C2-Servers zu extrahieren
    • Die IP-Adresse ist in die Transaktionsdaten eingebettet und ermöglicht damit eine dezentrale und zensurresistente C2-Kommunikation
  • Einmal aktiv, kann PHANTOMPULSE Tastatureingaben erfassen, Screenshots aufnehmen, Dateien exfiltrieren und beliebige Befehle ausführen

Bewertung der Auswirkungen

  • Bei einer erfolgreichen Kompromittierung erhalten die Angreifer vollständigen Zugriff auf das System des Opfers
  • Für Beschäftigte in der Finanz- und Kryptobranche besteht das Risiko, dass sensible Unternehmensdaten, geistiges Eigentum, Trading-Strategien, Schlüssel von Krypto-Wallets und Zugangsdaten zu Börsenplattformen gestohlen werden
  • Durch die plattformübergreifende Natur vergrößert sich das potenzielle Schadensausmaß
  • Das blockchainbasierte C2 zeigt ein hohes Maß an Raffinesse und macht das Unterbinden der Bedrohungsinfrastruktur äußerst schwierig

Cyber-Beobachtungsindikatoren zur Erkennung

  • Prozessüberwachung: Beobachten, ob Obsidian.exe Kindprozesse wie powershell.exe, cmd.exe, osascript usw. erzeugt
  • Befehlszeilenmuster: powershell -ExecutionPolicy Bypass — Erkennung verdächtiger PowerShell-Ausführung, die von einer untypischen Anwendung wie Obsidian gestartet wurde
  • Netzwerkverkehr: Überwachen ausgehender Verbindungen von unerwarteten Prozessen zu Ethereum-Blockchain-Nodes oder Gateways (möglicher Versuch von PHANTOMPULSE, die C2-Adresse abzurufen)
  • Dateipfade: Erstellung oder Änderung von Dateien im Verzeichnis [Vault]/.obsidian/plugins/ überwachen, insbesondere Änderungen außerhalb des offiziellen Plugin-Marketplace

Erkennung und Reaktion

  • Prozessanalyse (D3-PA): EDR-Regeln implementieren, die Alarm schlagen, wenn der Obsidian-Prozess Kommandozeileninterpreter (powershell.exe, cmd.exe, bash, osascript) startet — ein äußerst ungewöhnliches Verhalten
  • Benutzerschulung: Beschäftigte in Hochrisikobranchen über die Risiken von Social Engineering und die Taktik des Missbrauchs von Shared Vaults und Plugin-Funktionen aufklären
  • Application Control (D3-EAL): Wenn möglich, Application-Control-Richtlinien anwenden, die die Installation und Ausführung nicht genehmigter Community-Plugins in Anwendungen wie Obsidian einschränken
  • Netzwerküberwachung (D3-NTA): Beobachten, ob auf Endpunkten, bei denen dies nicht zu erwarten ist, anomale DNS-Abfragen oder direkte IP-Verbindungen zu Blockchain-Diensten auftreten

Maßnahmen zur Risikominderung

  • Prüfung von Community-Plugins: Bei der Aktivierung von Plugins von Drittanbietern oder aus der Community in jeder Anwendung ist äußerste Vorsicht geboten; nur vertrauenswürdige Plugins aus dem offiziellen Marketplace installieren und Berechtigungen unbedingt prüfen
  • Automatische Synchronisierung für nicht vertrauenswürdige Vaults deaktivieren: Beim Verbinden mit Obsidian-Vaults aus unbekannten oder nicht vertrauenswürdigen Quellen keine Plugin-Synchronisierung aktivieren
  • Prinzip der minimalen Rechte: Anwendungen wie Obsidian als Standardbenutzer statt mit Administratorrechten ausführen, um die Auswirkungen einer Kompromittierung zu begrenzen
  • Endpoint-Sicherheit: Aktuelle EDR- und Antivirus-Lösungen einsetzen, um verdächtige Skriptausführung und Process-Injection-Techniken zu erkennen und zu blockieren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-05-11
Hacker-News-Kommentare

  • Ich bin der CEO von Obsidian. Ein großes Update zur Plugin-Sicherheit kommt bald, und ich denke, dass es viele der in diesem Thread geäußerten Bedenken ausräumen wird.
    Es ist ein schwieriges Problem, aber wir arbeiten daran. Allerdings ist der Titel irreführend. In diesem Beitrag geht es um einen Social-Engineering-Angriff, bei dem Nutzer mehrere Sicherheitswarnungen von Obsidian aktiv ablehnen mussten, und soweit ich weiß, handelt es sich um einen Proof of Concept; echte Schadensmeldungen habe ich nicht gesehen

    • Ich sage seit Jahren, dass Plugins unsicher sind. Ich erinnere mich noch gut daran, wie ich auf Discord angegriffen wurde, nachdem ich gesagt hatte, dass Plugins vollen Zugriff auf die gesamte Festplatte haben. Es ist zu spät
    • Wird es jetzt, selbst wenn Plugins aktiviert sind, eine Option geben, den .obsidian-Ordner außerhalb des Vaults zu verschieben und diesen Ordner innerhalb des Vaults standardmäßig zu ignorieren?
    • Ich weiß nicht, wie schwierig das wäre, aber ein Berechtigungsdialog wie unter Android würde sehr helfen. 99 % der Obsidian-Plugins brauchen weder vollen Festplattenzugriff noch Internetzugang
    • Die Offenlegung des Quellcodes des Clients würde ebenfalls viele Bedenken ausräumen
    • Bedeutet „mehrere Sicherheitswarnungen aktiv ablehnen“ so etwas wie Pop-ups? Die meisten Menschen bestätigen so etwas ohne groß nachzudenken.
      Ich finde, Plugins/Erweiterungen sollten standardmäßig etwas schwerer auszuführen sein. Ich verstehe, dass zusätzliche Hürden vor der Nutzung von Plugins Reibung für Nutzer erzeugen, aber ich glaube nicht, dass es in der Praxis irgendeine sichere Möglichkeit gibt, ungeprüften beliebigen Code ohne Sandbox oder andere Einschränkungen auszuführen

  • Das ist ein irreführender Titel. Er lässt es so erscheinen, als sei ein legitimes Plugin kompromittiert worden und hätte in einem weiteren Supply-Chain-Angriff Malware verteilt.
    Tatsächlich wird das Opfer zu einer Zusammenarbeit an einem synchronisierten Vault eingeladen, in dem bereits ein inoffizielles Plugin enthalten ist, das den RAT ausliefert. Das ist eine völlig andere Geschichte

    • Was daran ist irreführend?
      Dort steht: „Novel Campaign Abuses Obsidian Note-Taking App to Target Finance and Crypto Professionals with PHANTOMPULSE RAT“. Das scheint mir zutreffend formuliert zu sein: ein neuer Angriff, der Obsidian missbraucht, auf eine bestimmte Gruppe zielt und einen RAT im Vault unterbringt

  • Ich mag Obsidian wirklich sehr und nutze es täglich, aber Community-Plugins verwende ich nicht, weil das Berechtigungssystem nicht ausreichend ist.
    Ich hoffe auf den Tag, an dem Plugins die benötigten Berechtigungen deklarieren und diese dem Nutzer angezeigt werden. Ich glaube, dass das Obsidian-Team dieses Problem ernst nimmt, und bin gespannt, was sie liefern werden. Ich habe Vertrauen, aber es überrascht mich, dass es von Anfang an ohne besseres Berechtigungssystem und ohne Sandbox entworfen wurde

    • Ich habe angefangen, Obsidian zu nutzen, weil ich es leid war, zum Ansehen von Markdown-Dateien VS Code zu verwenden. Zum Glück musste ich keine Plugins installieren. Auf den ersten Blick wirkt dieser Teil wie ein ziemlich schlechtes Design

  • „Die Opfer werden aufgefordert, die Synchronisierungsfunktion ‚Installed community plugins‘ zu aktivieren“
    Obsidian hat Schutzmechanismen, um genau solche Angriffe zu verhindern, und die Opfer wurden dazu gebracht, diese zu ignorieren. Es ist einfach ein erfolgreicher Social-Engineering-Vorfall. Dieser Angriff nutzt keine Schwachstelle in Obsidian oder im Plugin-System aus, deshalb finde ich es unschön, wenn Obsidian wegen solcher Überschriften in Misskredit gerät

    • Das sehe ich nicht so. https://obsidian.md/help/plugin-security#Plugin+capabilities
      „Aufgrund technischer Einschränkungen kann Obsidian Plugins nicht zuverlässig auf bestimmte Berechtigungen oder Zugriffsebenen beschränken. Daher erben Plugins das Zugriffslevel von Obsidian.“
      Community-Plugins können auf Dateien auf dem Computer zugreifen, sich mit dem Internet verbinden und zusätzliche Programme installieren. Obsidian hat überhaupt keine Schutzmechanismen; ein Plugin zu installieren bedeutet, vollen Zugriff auf den Computer zu gewähren. Dass so etwas passiert, war nur eine Frage der Zeit, und ich halte es seit etwa 2010 für unentschuldbar fahrlässig, überhaupt noch Plugin-Systeme dieser Art zu veröffentlichen
    • Ich nutze und mag Obsidian viel, aber ich denke, der Wert dieser Offenlegung liegt darin, das Bewusstsein für Plugins zu schärfen und den Angriffsweg zu zeigen.
      Weniger erfahrene Nutzer könnten denken: „Es ist doch nur eine Sammlung von Markdown-Dateien. Ich muss mir über Malware wohl keine großen Sorgen machen“

  • Warum sind fast alle Plugin-Systeme so schlampig entworfen? Ich frage mich, ob es daran liegt, dass es kein gutes Framework für die Entwicklung von Plugins mit ordentlicher Isolierung/Berechtigungen gibt und der Aufwand zu groß ist, oder ob die nötigen Anforderungen nicht breit genug bekannt sind und man erst lernt, wenn das eigene System missbraucht wird. Ist es beides, oder gibt es noch andere Gründe?

    • Im Kern ist es ein Trade-off zwischen Funktionalität und Sicherheit. Man kann Nutzern mächtige Fähigkeiten geben und großartige Dinge ermöglichen, oder man kann den Großteil sinnvoller Fähigkeiten entfernen und es sicher machen. Die meisten Menschen bevorzugen Funktionalität gegenüber Sicherheit.
      Ein weiteres Problem ist, dass Sicherheit schwer ist, während es einfach ist, weitreichende Zugriffsrechte zu geben und nur grundlegende Schutzplanken hinzuzufügen
    • Man muss das Sicherheits-Framework und die Komponenten definieren, die alle Plugins benötigen würden, und Zeit in Entwurf, Implementierung, Prüfung und Wartung investieren.
      Es ist viel einfacher, diesen Teil einfach zu überspringen. Ja, der Aufwand ist also tatsächlich zu groß – genauer gesagt braucht es sicherheitsorientierte Führung, die versteht, dass diese Arbeit aufwendig, aber richtig ist
    • Ich vermute, es liegt an fehlenden Ressourcen für den Web-Stack und für die Gestaltung sauberer Schnittstellen. Solche Software wird in hochrangigen JS-Frameworks geschrieben, daher sind die Datenflussmuster von Haus aus oft schlecht, und man folgt häufig einfach dem, was praktisch möglich ist, statt bewusst zu entwerfen.
      Für ein bewusstes Design müsste man möglicherweise in niedrigere Abstraktionsebenen hinabsteigen und einen eigenen Fork des betreffenden Frameworks pflegen. Wahrscheinlich hat man Plugins daher so entworfen, als würde man eine Bibliothek instanziieren und ihr einen Teil des vom Programm genutzten Kontexts übergeben. Letztlich ist das die einfachste Methode, die funktioniert. Der veröffentlichte Hack benennt keine konkrete „Schwachstelle“, aber Obsidian-Plugins sind schon immer God Mode, und die Angreifer haben Menschen nur dazu gebracht, das zu verwenden. Es ist lächerlich, letztlich den Nutzer verantwortlich zu machen, wenn hinter ein paar Pop-ups faktisch Remote Code Execution wartet. Die Entwickler sollten sich schämen
    • Selbst Browser-Plugins für Chrome haben ähnliche Sicherheitsprobleme. Obwohl dort Milliarden Dollar und viele brillante Entwickler investiert werden, ist es nicht besser.
      Es ist ähnlich, als würde man einen App Store innerhalb einer App bauen. Der Apple App Store reduziert bösartige Apps, indem er sehr streng begrenzt, wer was veröffentlichen darf, und zusätzlich bezahlte Hürden einzieht
    • Warum sollte ein Plugin-System automatisch Sandboxing bedeuten?

  • Selbst wenn es Social Engineering ist: Wenn das Plugin-System so entworfen ist, dass so etwas möglich ist, ist diese Plattform als Tool zum Teilen völlig unbrauchbar.
    Gut zu wissen, aber für mich läuft es eher auf „Nimm niemals einen geteilten Obsidian-Vault an und verlange stattdessen einen Plain-Text-Export hinaus“ als auf „Wenn du einen geteilten Obsidian-Vault nutzt, musst du diese Einstellung korrekt gesetzt lassen“

  • Als ich gerade erst mit Obsidian angefangen hatte, empfahlen die YouTube-Videos, die ich sah, die Nutzung von Community-Plugins. Trotz solcher Warnungen hätte ich Community-Plugins wahrscheinlich aktiviert.
    Ein Plugin-Entwickler, der anfangs in guter Absicht handelt, kann später böswillig werden, und der Nutzer kann das nicht wissen. Ich bin Entwickler und kenne diese Risiken, aber selbst ich hätte die Option für Community-Plugins wahrscheinlich aktiviert – vielleicht bin ich einfach besonders risikofreudig. Ich hoffe, ich bin damit in der Minderheit und die meisten Nutzer verhalten sich anders

  • Solche Dinge breiten sich gerade ein wenig wie eine Modeerscheinung aus. Nicht jeder Angriff oder Exploit, insbesondere kein Social-Engineering-Angriff, braucht einen Metal-Gear-artigen Namen oder eine eigene Website

  • Wenn man den Inhalt liest, begann das Problem nicht mit einem Plugin aus dem Obsidian-Store, sondern mit einem bösartigen Vault, den man zum Öffnen bewegen wollte

  • Ich führe Obsidian mit eingeschränkten Rechten aus. Kein Netzwerkzugang, kein Dateisystemzugriff außerhalb des eigenen Verzeichnisses.
    Nur wenn ich Plugins/Themes aktualisiere, aktiviere ich den Netzwerkzugang. Andere Anwendungen, die potenziell nicht vertrauenswürdigen Code ausführen können, betreibe ich genauso

    • Kannst du teilen, wie du das sandboxst?