Une nouvelle campagne de social engineering exploitant des plugins Obsidian diffuse un nouveau cheval de Troie

• Découverte d’une campagne hautement ciblée visant les professionnels de la finance et des cryptomonnaies, qui détourne la fonctionnalité de coffre partagé de l’application de notes Obsidian pour déployer un nouveau cheval de Troie d’accès à distance (RAT) jusqu’ici non documenté
• Les attaquants se font passer pour des capital-risqueurs sur LinkedIn et Telegram afin d’établir une relation de confiance, puis attirent leurs victimes vers un coffre partagé Obsidian malveillant
• Si la victime approuve manuellement la synchronisation des plugins communautaires, le code malveillant s’exécute et dépose le loader PHANTOMPULL via PowerShell sur Windows et via AppleScript sur macOS
• Le RAT PHANTOMPULSE extrait dynamiquement l’adresse du serveur C2 à partir des données de transaction de la blockchain Ethereum, ce qui lui confère une forte résistance aux méthodes classiques de démantèlement
• Il s’agit d’une attaque multiplateforme prenant en charge Windows et macOS, avec des capacités complètes de contrôle à distance incluant capture des frappes, captures d’écran, exfiltration de fichiers et exécution de commandes arbitraires

---

Aperçu de la menace

• Cette attaque, désignée REF6598, repose sur une campagne de social engineering en plusieurs étapes
• L’acteur de la menace approche ses cibles sur des plateformes de réseautage professionnel en se faisant passer pour un capital-risqueur, puis déplace la conversation vers un groupe Telegram privé
• Le principal leurre est une invitation à collaborer via un coffre partagé Obsidian hébergé dans le cloud
• Lorsque la victime ouvre le coffre partagé, elle est incitée à activer la fonctionnalité de synchronisation des "Installed community plugins"
  • Cette approbation doit être effectuée manuellement, et constitue le principal déclencheur de l’infection
  • Une fois activée, des versions malveillamment modifiées de plugins légitimes inclus dans le coffre partagé (Shell Commands, Hider) sont exécutées

Analyse technique

• La chaîne d’attaque diffère légèrement entre Windows et macOS, mais repose sur le même principe
• Accès initial (T1566.002) : les victimes sont amenées, via du social engineering sur LinkedIn/Telegram, à ouvrir un coffre partagé Obsidian malveillant
• Exécution (T1204.002) : l’utilisateur est manipulé pour activer des plugins communautaires dans Obsidian, ce qui lance des scripts malveillants via le plugin Shell Commands compromis
• Staging : sous Windows, un script PowerShell est exécuté pour déposer un loader nommé PHANTOMPULL ; sous macOS, un processus similaire s’exécute via AppleScript
• Livraison de la charge utile : le loader PHANTOMPULL charge directement en mémoire la charge utile finale, le RAT PHANTOMPULSE, afin d’éviter la détection basée sur les fichiers (injection de processus T1055)
• Communication C2 (T1102.002) : PHANTOMPULSE interroge les dernières transactions sur la blockchain Ethereum d’une adresse de portefeuille codée en dur afin d’en extraire l’adresse IP du serveur C2
  • L’adresse IP est intégrée dans les données de transaction, mettant en œuvre une communication C2 décentralisée et résistante à la censure
• Une fois activé, PHANTOMPULSE peut capturer les frappes, prendre des captures d’écran, exfiltrer des fichiers et exécuter des commandes arbitraires

Évaluation de l’impact

• En cas de compromission réussie, les attaquants obtiennent un accès complet au système de la victime
• Pour les professionnels de la finance et des cryptomonnaies, cela expose au vol de données d’entreprise sensibles, de propriété intellectuelle, de stratégies de trading, ainsi que de clés de portefeuilles crypto et d’identifiants de plateformes d’échange
• Son caractère multiplateforme élargit l’étendue potentielle des dommages
• Le C2 fondé sur la blockchain témoigne d’un haut niveau de sophistication et rend le blocage de l’infrastructure de menace extrêmement difficile

Indicateurs d’observation cyber pour la détection

• Surveillance des processus : observer si Obsidian.exe crée des processus enfants tels que powershell.exe, cmd.exe, osascript
• Motifs de ligne de commande : powershell -ExecutionPolicy Bypass — détecter les exécutions PowerShell suspectes lancées depuis une application non standard comme Obsidian
• Trafic réseau : surveiller les connexions sortantes vers des nœuds ou passerelles de blockchain Ethereum depuis des processus inattendus (possible tentative de résolution de l’adresse C2 de PHANTOMPULSE)
• Chemins de fichiers : surveiller la création ou la modification de fichiers dans le répertoire [Vault]/.obsidian/plugins/, en particulier les changements intervenant hors de la marketplace officielle de plugins

Détection et réponse

• Analyse des processus (D3-PA) : mettre en œuvre des règles EDR qui détectent et alertent lorsqu’un processus Obsidian lance des interpréteurs de ligne de commande (powershell.exe, cmd.exe, bash, osascript) — un comportement très inhabituel
• Sensibilisation des utilisateurs : former les employés des secteurs à haut risque aux dangers du social engineering et aux tactiques d’abus des coffres partagés et des plugins
• Contrôle applicatif (D3-EAL) : lorsque c’est possible, appliquer des politiques de contrôle applicatif qui limitent l’installation et l’exécution de plugins communautaires non approuvés dans des applications comme Obsidian
• Supervision réseau (D3-NTA) : surveiller l’apparition de requêtes DNS anormales liées à des services blockchain ou de connexions IP directes sur des endpoints où ce type de trafic n’est pas attendu

Mesures d’atténuation

• Vérification des plugins communautaires : faire preuve d’une extrême prudence lors de l’activation de plugins tiers ou communautaires dans toute application ; n’installer que des plugins fiables issus de la marketplace officielle et examiner systématiquement les autorisations
• Désactivation de la synchronisation automatique pour les coffres non fiables : lors de la connexion à des coffres Obsidian provenant de sources inconnues ou non fiables, ne pas activer la synchronisation des plugins
• Principe du moindre privilège : exécuter des applications comme Obsidian en tant qu’utilisateur standard et non administrateur afin de limiter l’impact en cas de compromission
• Sécurité endpoint : déployer des solutions EDR et antivirus à jour afin de détecter et bloquer les exécutions de scripts suspectes et les techniques d’injection de processus

[GN⁺]

Avis sur Hacker News

• Je suis le CEO d’Obsidian. Une grosse mise à jour concernant la sécurité des plugins arrive bientôt, et je pense qu’elle pourra répondre à une grande partie des inquiétudes exprimées dans ce fil
  C’est un problème difficile, mais nous y travaillons. Cela dit, le titre est trompeur. Cet article parle d’une attaque d’ingénierie sociale dans laquelle l’utilisateur doit lui-même refuser plusieurs avertissements de sécurité d’Obsidian, et à ma connaissance cela reste au niveau de la preuve de concept, sans signalement de dommages réels

  • Je dis depuis des années que les plugins ne sont pas sûrs. Je me souviens très bien m’être fait attaquer sur Discord après avoir dit que les plugins avaient un accès complet au disque. C’est trop tard
  • Est-ce que cela signifie qu’à l’avenir, même si les plugins sont activés, il y aura une option pour déplacer le dossier .obsidian hors du vault et ignorer par défaut ce dossier à l’intérieur du vault ?
  • Je ne sais pas à quel point ce serait difficile, mais ajouter des boîtes de dialogue de permissions comme sur Android aiderait énormément. 99 % des plugins Obsidian n’ont besoin ni d’un accès complet au disque, ni d’un accès à Internet
  • Rendre le code source du client public aiderait aussi à dissiper beaucoup d’inquiétudes
  • Que signifie exactement « refuser activement plusieurs avertissements de sécurité » ? Des pop-ups, par exemple ? La plupart des gens les valident sans trop réfléchir
    À mon avis, il faudrait rendre l’exécution des plugins/extensions un peu plus difficile par défaut. Je comprends que des barrières supplémentaires avant d’utiliser un plugin créent de la friction, mais je ne pense pas qu’il existe en pratique de moyen sûr d’exécuter du code arbitraire non vérifié sans sandbox ni autres restrictions

• C’est un titre trompeur. Il donne l’impression qu’un plugin légitime a été compromis pour distribuer un malware, comme dans une nouvelle attaque de supply chain
  En réalité, la victime est invitée à collaborer sur un vault synchronisé, dans lequel se trouve déjà un plugin non officiel servant à livrer le RAT. Ce n’est pas du tout la même histoire

  • En quoi est-ce trompeur ?
    Le titre dit : « Novel Campaign Abuses Obsidian Note-Taking App to Target Finance and Crypto Professionals with PHANTOMPULSE RAT ». Il s’agit bien d’une nouvelle attaque, qui détourne Obsidian, cible un groupe précis, et où le RAT se trouve dans le vault ; la formulation me semble donc correcte

• J’aime beaucoup Obsidian et je l’utilise tous les jours, mais je n’utilise pas les plugins communautaires parce que le système de permissions n’est pas suffisant
  J’espère qu’un jour les plugins devront déclarer les permissions dont ils ont besoin et que cela sera affiché à l’utilisateur. Je pense que l’équipe d’Obsidian prend ce problème au sérieux et j’ai hâte de voir ce qu’elle va proposer. J’ai confiance, mais il est surprenant que le produit ait été conçu dès le départ sans meilleur modèle de permissions ni sandbox

  • J’ai commencé à utiliser Obsidian parce que j’en avais assez d’utiliser VS Code pour consulter des fichiers Markdown. Heureusement, je n’ai jamais eu besoin d’installer de plugin. À première vue, cette partie du design semble vraiment mauvaise

• « Il est demandé à la victime d’activer la synchronisation des “Installed community plugins” »
  Obsidian dispose déjà de garde-fous pour empêcher ce type d’attaque, et la victime a été persuadée de les ignorer. Ce n’est rien d’autre qu’un cas réussi d’ingénierie sociale. Cette attaque n’exploite ni une faille d’Obsidian ni une faille du système de plugins, donc je n’aime pas voir Obsidian traîné dans la boue à cause de ce titre

  • Je ne suis pas d’accord. https://obsidian.md/help/plugin-security#Plugin+capabilities
    « En raison de limitations techniques, Obsidian ne peut pas restreindre de manière fiable les plugins à des permissions ou niveaux d’accès spécifiques. Les plugins héritent donc du niveau d’accès d’Obsidian. »
    Les plugins communautaires peuvent accéder aux fichiers de l’ordinateur, se connecter à Internet et même installer des programmes supplémentaires. Obsidian n’a absolument aucun garde-fou, et installer un plugin revient à lui accorder un accès total à l’ordinateur. Ce genre de chose devait arriver tôt ou tard, et à partir d’environ 2010, sortir un système de plugins de ce type relevait déjà d’une négligence injustifiable
  • J’utilise beaucoup Obsidian et je l’apprécie, mais je pense que l’intérêt de cette divulgation est de sensibiliser les gens aux plugins et de montrer le vecteur d’attaque
    Les utilisateurs moins expérimentés peuvent se dire : « Ce ne sont que des fichiers Markdown, je n’ai probablement pas trop à m’inquiéter des malwares. »

• Pourquoi presque tous les systèmes de plugins sont-ils conçus de manière aussi laxiste ? Je me demande s’il n’existe pas de bon framework de développement de plugins offrant une isolation et des permissions correctes, ce qui rendrait le travail trop lourd, ou si c’est simplement que les gens ne savent pas vraiment ce qu’il faudrait faire et n’apprennent qu’après que leur système a été détourné. Ou les deux, ou autre chose ?

  • Au fond, c’est un compromis entre fonctionnalités et sécurité. Soit on donne aux utilisateurs des capacités puissantes pour faire des choses impressionnantes, soit on retire l’essentiel de ces capacités pour rendre le système sûr. En général, les gens préfèrent les fonctionnalités à la sécurité
    L’autre problème, c’est que la sécurité est difficile, alors qu’accorder un accès générique et ajouter quelques garde-fous basiques est facile
  • Il faut définir le framework de sécurité et les composants dont tous les plugins auront besoin, puis passer du temps à les concevoir, les implémenter, les vérifier et les maintenir
    Il est beaucoup plus simple de sauter cette étape. Donc oui, cela représente trop de travail — et plus précisément, cela demande un leadership centré sur la sécurité qui comprenne qu’il s’agit d’un travail important, mais nécessaire
  • Je suppose que c’est à cause d’un manque de ressources pour concevoir une interface correcte avec une web stack. Ce type de logiciel est écrit avec des frameworks JS de haut niveau, ce qui conduit souvent à de mauvais schémas de circulation des données, et l’on finit par suivre ce qui est simplement possible en pratique plutôt qu’un design intentionnel
    Pour concevoir les choses de manière volontaire, il faudrait peut-être descendre d’un niveau d’abstraction et maintenir un fork personnalisé du framework concerné. Ils ont donc probablement conçu les plugins comme on instancie une bibliothèque en lui passant une partie du contexte utilisé par l’application. Au final, c’est la méthode la plus simple qui fonctionne. Le piratage publié ici ne décrit pas une « vulnérabilité » précise ; les plugins Obsidian ont toujours été en mode dieu, et les attaquants se sont contentés de tromper les gens pour qu’ils les utilisent. C’est risible de rejeter au final la faute sur l’utilisateur alors qu’après quelques pop-ups, on se retrouve en pratique avec de l’exécution de code à distance. Les développeurs devraient avoir honte
  • Même les plugins du navigateur Chrome ont des problèmes de sécurité comparables. Et pourtant, il y a des milliards de dollars et beaucoup de développeurs très intelligents derrière
    C’est un peu comme créer un App Store dans une application. L’Apple App Store réduit les applications malveillantes en imposant des restrictions très strictes sur qui peut publier quoi, ainsi qu’une barrière payante
  • Pourquoi un système de plugins devrait-il impliquer automatiquement un sandboxing ?

• Même si c’est de l’ingénierie sociale, si le système de plugins est conçu de manière à permettre cela, alors cette plateforme est totalement inadaptée comme outil de partage
  C’est bon à savoir, mais pour moi on n’est pas dans « pour utiliser un vault Obsidian partagé, il faut conserver correctement ce réglage », mais plutôt dans « il ne faut jamais accepter de vault Obsidian partagé et il faut exiger une exportation en texte brut »

• Quand j’ai commencé à utiliser Obsidian, les vidéos YouTube que j’ai vues recommandaient d’utiliser les plugins communautaires. Même avec ce genre d’avertissements, je pense que j’aurais probablement activé les plugins communautaires
  Un développeur de plugin peut être de bonne foi au départ puis devenir malveillant plus tard, et l’utilisateur n’a aucun moyen de le savoir. Même en étant développeur et en connaissant ces risques, je pense que j’aurais activé l’option des plugins communautaires ; c’est peut-être simplement que ma tolérance au risque est élevée. J’espère être un cas minoritaire et que ce ne soit pas le comportement de la majorité des utilisateurs

• Ce genre de chose est un peu en train de devenir une épidémie. Toutes les attaques ou tous les exploits, en particulier les attaques d’ingénierie sociale, n’ont pas besoin d’un nom façon Metal Gear ou d’un site web

• À lire le contenu, le problème ne vient pas d’un plugin de la boutique Obsidian, mais d’un vault malveillant que l’on a incité la cible à ouvrir

• J’exécute Obsidian avec des permissions restreintes. Pas d’accès réseau, pas d’accès au système de fichiers en dehors de son propre répertoire
  Je n’active l’accès réseau que pour mettre à jour les plugins/thèmes. J’exécute de la même façon d’autres applications capables d’exécuter du code non fiable

  • Peux-tu expliquer comment tu le sandboxes ?