1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Die Kampagne REF6598 verbreitet den RAT PHANTOMPULSE über geteilte Obsidian-Vaults
  • Ziele sind Finanz- und Krypto-Beschäftigte unter Windows und macOS; die Anlockung erfolgt über LinkedIn und Telegram
  • Die Infektion beginnt, wenn die Synchronisierung von Community-Plugins in einem geteilten Vault manuell aktiviert wird
  • Die bösartigen Plugins Shell Commands und Hider führen Skripte aus, und PHANTOMPULL lädt den RAT
  • PHANTOMPULSE prüft die C2-Adresse über Ethereum-Transaktionen, was eine Blockierung erschwert

Angriffsablauf

  • Initialzugang und Ausführung

    • Die Kampagne REF6598 missbraucht die Notiz-App Obsidian, um den bislang nicht dokumentierten Remote-Access-Trojaner (RAT) PHANTOMPULSE zu verbreiten
    • Die Angreifer geben sich als Venture-Capital-Kontakte aus, sprechen ihre Ziele auf professionellen Networking-Plattformen an und verlagern das Gespräch anschließend in private Telegram-Gruppen
    • Unter dem Vorwand der Zusammenarbeit werden die Opfer dazu gebracht, einem in der Cloud gehosteten geteilten Obsidian-Vault beizutreten
    • Der Initialzugang entspricht MITRE ATT&CK T1566.002 Spearphishing Link
    • Die Infektion beginnt, wenn das Opfer in Obsidian die Synchronisierungsfunktion für „Installed community plugins“ manuell aktiviert
    • Der geteilte Vault enthält manipulierte Versionen der legitimen Obsidian-Plugins Shell Commands und Hider; die Aktivierung von Community-Plugins führt dadurch zur Codeausführung
    • Das kompromittierte Plugin Shell Commands führt ein bösartiges Skript aus
    • Diese Phase, in der Benutzerinteraktion zur Ausführung einer schädlichen Datei verleitet, entspricht T1204.002 Malicious File
  • Infektionsschritte unter Windows und macOS

    • Unter Windows führt das bösartige Plugin ein PowerShell-Skript aus, das den Loader PHANTOMPULL ablegt
    • Unter macOS läuft ein ähnlicher Ablauf über AppleScript
    • Anschließend entschlüsselt und startet PHANTOMPULL die finale Payload, den RAT PHANTOMPULSE
    • PHANTOMPULSE führt die finale Payload direkt im Speicher aus, um dateibasierte Erkennung zu vermeiden; das steht im Zusammenhang mit T1055 Process Injection

Funktionen von PHANTOMPULSE und C2-Methode

  • Nach der Aktivierung kann PHANTOMPULSE Tastatureingaben mitschneiden, Screenshots erstellen, Dateien exfiltrieren und beliebige Befehle ausführen
  • Die C2-Kommunikation ist als Verfahren umgesetzt, das T1102.002 Bidirectional Communication entspricht
  • PHANTOMPULSE fragt die neuesten Ethereum-Transaktionen einer fest eincodierten Wallet-Adresse ab
  • Die IP-Adresse des C2-Servers ist in den Transaktionsdaten enthalten; die Malware ermittelt darüber den Server, von dem sie Befehle empfängt
  • Dieses Verfahren bietet einen dezentralen und zensurresistenten Mechanismus zur Ermittlung der C2-Adresse und erschwert so die Abschaltung der Bedrohungsinfrastruktur

Auswirkungen

  • Bei erfolgreicher Infektion erhalten die Angreifer vollen Zugriff auf das System des Opfers
  • Beschäftigte im Finanz- und Kryptobereich können den Diebstahl sensibler Unternehmensdaten, geistigen Eigentums, Handelsstrategien, Schlüsseln von Krypto-Wallets und Zugangsdaten zu Börsen erleiden
  • Da sowohl Windows als auch macOS angegriffen werden, ist der Kreis potenzieller Opfer groß
  • Die Nutzung eines blockchainbasierten C2 zeigt ein hohes Maß an Raffinesse und erschwert die Störung der Bedrohungsinfrastruktur

Erkennungsindikatoren

  • Prozesse

    • Obsidian.exe
    • Es sollte überwacht werden, ob Obsidian Kindprozesse wie powershell.exe, cmd.exe oder osascript erzeugt
  • Befehlszeilenmuster

    • powershell -ExecutionPolicy Bypass
    • PowerShell-Ausführungen, die von untypischen Anwendungen wie Obsidian gestartet werden, sind ein Warnsignal
  • Netzwerkverkehr

    • Ausgehende Verbindungen von unerwarteten Prozessen zu Ethereum-Blockchain-Knoten oder Gateways sollten überwacht werden
    • Solche Verbindungen können darauf hindeuten, dass PHANTOMPULSE die C2-Adresse abfragt
  • Dateipfade

    • [Vault]/.obsidian/plugins/
    • Es sollte geprüft werden, ob Dateien im Obsidian-Plugin-Verzeichnis außerhalb des offiziellen Plugin-Marktplatzes erstellt oder verändert werden

Erkennung und Reaktion

  • Prozessüberwachung: Es werden EDR-Regeln benötigt, die erkennen und alarmieren, wenn der Obsidian-Prozess Befehlszeileninterpreter wie powershell.exe, cmd.exe, bash oder osascript startet
  • Benutzerschulung: Anwender in Hochrisikobranchen sollten sich der Risiken von Social Engineering und des Missbrauchs von Funktionen in Kollaborationstools wie geteilten Vaults und Plugins bewusst sein
  • Application Control: Wo möglich, sollten Richtlinien zur Anwendungskontrolle die Installation und Ausführung nicht genehmigter Community-Plugins in Apps wie Obsidian einschränken
  • Netzwerküberwachung: Auf Endpunkten, auf denen solche Aktivitäten nicht zu erwarten sind, sollten ungewöhnliche DNS-Anfragen zu Blockchain-Diensten oder direkte IP-Verbindungen überwacht werden

Maßnahmen zur Risikominderung

  • Prüfung von Community-Plugins: Beim Aktivieren von Plugins von Drittanbietern oder aus der Community in beliebigen Anwendungen ist besondere Vorsicht geboten; sie sollten nur aus offiziell vertrauenswürdigen Marktplätzen installiert und ihre Berechtigungen geprüft werden
  • Automatische Synchronisierung für nicht vertrauenswürdige Vaults deaktivieren: Beim Verbinden mit Obsidian-Vaults aus unbekannten oder nicht vertrauenswürdigen Quellen sollte die Plugin-Synchronisierung nicht aktiviert werden
  • Prinzip der geringsten Rechte: Anwendungen wie Obsidian sollten mit Standardbenutzerrechten statt mit Administratorrechten ausgeführt werden, um die Auswirkungen einer Kompromittierung zu begrenzen
  • Endpoint Security: Aktuelle EDR- und Antiviren-Lösungen sollten eingesetzt werden, um verdächtige Skriptausführung und Process-Injection-Techniken zu erkennen und zu blockieren

MITRE ATT&CK-Mapping für Gegenmaßnahmen

  • User Training
    • Die Schulung von Anwendern, Social-Engineering-Taktiken zu erkennen und unaufgeforderte Einladungen zur Zusammenarbeit kritisch zu hinterfragen, ist eine zentrale Verteidigungsmaßnahme gegen diesen Angriffsvektor
  • Execution Prevention
    • Durch Application Control kann verhindert werden, dass Apps wie Obsidian Skripte wie PowerShell ausführen, wodurch sich die Angriffskette unterbrechen lässt
    • D3FEND-Mapping: D3-EAL
  • Software Configuration
    • Wenn Anwendungen so konfiguriert werden, dass die Installation von Drittanbieter-Plugins deaktiviert oder nur nach strenger Freigabe erlaubt ist, verringert sich die Angriffsfläche
    • D3FEND-Mapping: D3-ACH

Referenzmaterial

1 Kommentare

 
GN⁺ 4 시간 전
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?