Obsidian प्लगइन का दुरुपयोग करने वाले social engineering अभियान से नए Trojan का प्रसार

• वित्त और क्रिप्टोकरेंसी उद्योग के पेशेवरों को निशाना बनाकर Obsidian note app की shared vault feature को हथियार बनाया गया, और पहले से प्रलेखित न किया गया नया remote access Trojan (RAT) तैनात करने वाला अत्यधिक targeted अभियान पाया गया
• हमलावर LinkedIn और Telegram पर venture capitalist बनकर भरोसा जीतते हैं, फिर malicious Obsidian shared vault की ओर पीड़ितों को लुभाते हैं
• जब पीड़ित community plugin sync को manually approve करता है, तो malicious code चल जाता है; Windows पर PowerShell और macOS पर AppleScript के जरिए PHANTOMPULL loader drop किया जाता है
• PHANTOMPULSE RAT, C2 server address को Ethereum blockchain transaction data से dynamic तरीके से निकालता है, जिससे पारंपरिक takedown तरीकों के खिलाफ उच्च प्रतिरोध मिलता है
• Windows और macOS दोनों को सपोर्ट करने वाला cross-platform attack होने के कारण, keystroke capture, screenshot, file exfiltration और arbitrary command execution सहित व्यापक remote control संभव है

---

खतरे का अवलोकन

• REF6598 के रूप में नामित यह हमला एक multi-stage social engineering अभियान है
• threat actor पेशेवर networking site पर venture capitalist बनकर target तक पहुंचता है, फिर बातचीत को private Telegram group में ले जाता है
• मुख्य lure, cloud-hosted Obsidian shared vault के जरिए collaboration invite है
• जब पीड़ित shared vault खोलता है, तो उसे "Installed community plugins" sync feature सक्षम करने के लिए प्रेरित किया जाता है
  • यह approval manually किया जाना जरूरी है, और यही infection का मुख्य trigger है
  • सक्षम होते ही shared vault में शामिल वैध plugins के maliciously modified version ('Shell Commands', 'Hider') चलाए जाते हैं

तकनीकी विश्लेषण

• attack chain Windows और macOS पर थोड़ा अलग है, लेकिन वही मूल सिद्धांत अपनाती है
• प्रारंभिक पहुंच (T1566.002): LinkedIn/Telegram पर social engineering के जरिए malicious Obsidian shared vault खोलने के लिए प्रेरित किया जाता है
• निष्पादन (T1204.002): उपयोगकर्ता को Obsidian के भीतर community plugins सक्षम करने के लिए manipulate किया जाता है, और modified 'Shell Commands' plugin के जरिए malicious script execute होती है
• staging: Windows पर PowerShell script चलाकर PHANTOMPULL नाम का loader drop किया जाता है, जबकि macOS पर AppleScript के जरिए समान प्रक्रिया चलती है
• payload delivery: PHANTOMPULL loader अंतिम payload PHANTOMPULSE RAT को सीधे memory में load करता है, जिससे file-based detection से बचा जा सके (T1055 process injection)
• C2 communication (T1102.002): PHANTOMPULSE hardcoded wallet address के सबसे हाल के transactions को Ethereum blockchain पर query करके C2 server IP address निकालता है
  • transaction data में IP address embed होने से decentralized और censorship-resistant C2 communication लागू होती है
• सक्रिय PHANTOMPULSE keystroke capture, screenshot लेना, file exfiltration, arbitrary command execution कर सकता है

प्रभाव आकलन

• सफल compromise होने पर हमलावर को पीड़ित system पर पूर्ण access privilege मिल जाता है
• वित्त और क्रिप्टोकरेंसी उद्योग के पेशेवरों के मामले में sensitive corporate data, intellectual property, trading strategy, क्रिप्टो wallet key और exchange authentication information की चोरी का जोखिम है
• cross-platform विशेषता के कारण संभावित नुकसान का दायरा बढ़ जाता है
• blockchain-आधारित C2 उच्च स्तर की sophistication दिखाता है, और threat infrastructure को block करना बेहद कठिन बनाता है

पहचान के लिए cyber observables

• process monitoring: देखें कि Obsidian.exe क्या powershell.exe, cmd.exe, osascript जैसे child processes बना रहा है
• command line pattern: powershell -ExecutionPolicy Bypass — Obsidian जैसे non-standard application से शुरू होने वाले संदिग्ध PowerShell execution की पहचान
• network traffic: अप्रत्याशित processes से Ethereum blockchain node या gateway की ओर outbound connection पर निगरानी रखें (संभव है कि PHANTOMPULSE C2 address की पुष्टि की कोशिश कर रहा हो)
• file path: [Vault]/.obsidian/plugins/ directory के भीतर file creation या modification पर निगरानी रखें, खासकर official plugin marketplace के बाहर हुए बदलावों पर

पहचान और प्रतिक्रिया

• process analysis (D3-PA): जब Obsidian process command-line interpreter (powershell.exe, cmd.exe, bash, osascript) spawn करे, तब detect और alert करने वाले EDR rules लागू करें — यह बेहद असामान्य व्यवहार है
• user education: high-risk उद्योगों के कर्मचारियों को social engineering के जोखिम और shared vault तथा plugin feature के दुरुपयोग की रणनीति के बारे में शिक्षित करें
• application control (D3-EAL): जहां संभव हो, Obsidian जैसे applications में अनधिकृत community plugins की installation और execution सीमित करने वाली application control policy लागू करें
• network monitoring (D3-NTA): ऐसे endpoints पर blockchain service से जुड़े असामान्य DNS queries या direct IP connections की निगरानी करें, जहां इनकी अपेक्षा नहीं होती

mitigation measures

• community plugin verification: किसी भी application में third-party या community-developed plugins सक्षम करते समय अत्यधिक सावधानी बरतें, केवल official marketplace के trusted plugins install करें और permissions की अवश्य समीक्षा करें
• अविश्वसनीय vault के लिए auto sync अक्षम करें: अज्ञात या अविश्वसनीय source के Obsidian vault से जुड़ते समय plugin sync सक्षम न करें
• least privilege principle: Obsidian जैसे applications को administrator privilege के बजाय standard user के रूप में चलाएं, ताकि compromise की स्थिति में प्रभाव सीमित रहे
• endpoint security: suspicious script execution और process injection technique की पहचान व रोकथाम के लिए नवीनतम EDR और antivirus solutions तैनात करें

[GN⁺]

Hacker News की राय

• मैं Obsidian का CEO हूँ। प्लगइन सुरक्षा पर एक बड़ा अपडेट जल्द आ रहा है, और मुझे लगता है कि यह इस थ्रेड में उठी कई चिंताओं को दूर कर सकेगा
  यह मुश्किल समस्या है, लेकिन हम इस पर काम कर रहे हैं। हालांकि, शीर्षक भ्रामक है। यह पोस्ट एक social engineering attack के बारे में है, जिसमें उपयोगकर्ता को Obsidian की कई सुरक्षा चेतावनियों को खुद अस्वीकार करना पड़ता है, और जहाँ तक मुझे पता है यह proof-of-concept स्तर का मामला है, वास्तविक नुकसान की कोई रिपोर्ट मैंने नहीं देखी

  • मैं कई सालों से कह रहा हूँ कि प्लगइन सुरक्षित नहीं हैं। मुझे साफ़ याद है कि Discord पर मैंने कहा था कि प्लगइन के पास पूरे डिस्क की access होती है, और उस पर मुझ पर हमला हुआ था। बहुत देर हो चुकी है
  • क्या अब ऐसा विकल्प आएगा कि प्लगइन सक्षम होने पर भी .obsidian फ़ोल्डर को vault के बाहर ले जाया जा सके, और vault के भीतर उस फ़ोल्डर को डिफ़ॉल्ट रूप से ignore किया जाए?
  • यह कितना कठिन होगा पता नहीं, लेकिन Android जैसे permission dialogs जोड़ना बहुत मददगार होगा। Obsidian प्लगइन्स के 99% को न पूरे डिस्क की access चाहिए, न इंटरनेट access
  • क्लाइंट का source code खोलना भी बहुत-सी चिंताओं को कम कर सकता है
  • “कई सुरक्षा चेतावनियों को सक्रिय रूप से अस्वीकार करना” क्या popup जैसी चीज़ है? ज़्यादातर लोग ऐसी चीज़ों को बिना ज़्यादा सोचे approve कर देते हैं
    मेरे हिसाब से प्लगइन/extension को डिफ़ॉल्ट रूप से चलाना थोड़ा और कठिन होना चाहिए। मैं समझता हूँ कि प्लगइन इस्तेमाल करने से पहले अतिरिक्त बाधाएँ user friction पैदा करती हैं, लेकिन sandbox या दूसरे प्रतिबंधों के बिना review न किए गए arbitrary code को सुरक्षित तरीके से चलाने का कोई वास्तविक तरीका नहीं है

• यह भ्रामक शीर्षक है। इससे ऐसा लगता है जैसे किसी वैध प्लगइन से छेड़छाड़ कर malware बाँटा गया हो, यानी एक और supply-chain attack
  असल में पीड़ित को synced vault collaboration में invite किया जाता है, और उस vault में RAT देने वाला एक अनौपचारिक प्लगइन पहले से शामिल होता है। यह पूरी तरह अलग कहानी है

  • इसमें भ्रामक क्या है?
    इसमें लिखा है, “Novel Campaign Abuses Obsidian Note-Taking App to Target Finance and Crypto Professionals with PHANTOMPULSE RAT”। यह नया हमला है, Obsidian का दुरुपयोग करता है, एक खास समूह को निशाना बनाता है, और RAT vault में मौजूद है, इसलिए यह सही अभिव्यक्ति लगती है

• मुझे Obsidian बहुत पसंद है और मैं इसे रोज़ इस्तेमाल करता हूँ, लेकिन community plugins का permission system पर्याप्त नहीं है, इसलिए मैं उन्हें इस्तेमाल नहीं करता
  मैं उस दिन की उम्मीद करता हूँ जब प्लगइन यह घोषित करेंगे कि उन्हें कौन-कौन सी permissions चाहिए, और वह उपयोगकर्ता को दिखाई जाएँगी। मुझे भरोसा है कि Obsidian टीम इस समस्या को गंभीरता से लेगी, और मैं देखना चाहता हूँ कि वे क्या लाते हैं। भरोसा तो है, लेकिन यह चौंकाने वाला है कि शुरुआत से ही बेहतर permission system और sandboxing के बिना इसे डिज़ाइन किया गया

  • Markdown फ़ाइलें देखने के लिए VS Code इस्तेमाल करते-करते मैं थक गया था, इसलिए Obsidian इस्तेमाल करना शुरू किया। अच्छा है कि मुझे प्लगइन install करने की ज़रूरत नहीं पड़ी। देखने में यह हिस्सा काफ़ी खराब डिज़ाइन लगता है

• “पीड़ित से ‘Installed community plugins’ sync फीचर चालू करने को कहा जाता है”
  Obsidian में इस तरह के हमले को रोकने के लिए सुरक्षा उपाय हैं, और पीड़ित को उन्हें अनदेखा करने के लिए मनाया गया। यह सिर्फ़ एक सफल social engineering incident है। इस हमले ने Obsidian या plugin system की किसी vulnerability का दुरुपयोग नहीं किया, इसलिए मुझे अच्छा नहीं लगता कि ऐसे शीर्षक की वजह से Obsidian को घसीटा जाए

  • मैं सहमत नहीं हूँ। https://obsidian.md/help/plugin-security#Plugin+capabilities
    “तकनीकी सीमाओं के कारण Obsidian प्लगइन को किसी खास permission या access level तक विश्वसनीय रूप से सीमित नहीं कर सकता। इसलिए प्लगइन, Obsidian के access level को inherit करते हैं।”
    Community plugins आपके कंप्यूटर की फ़ाइलों तक पहुँच सकते हैं, इंटरनेट से जुड़ सकते हैं, और अतिरिक्त प्रोग्राम भी install कर सकते हैं। Obsidian में कोई वास्तविक सुरक्षा उपाय नहीं है, और प्लगइन install करना मतलब कंप्यूटर पर पूर्ण access देना है। यह होना सिर्फ़ समय की बात थी, और मेरे हिसाब से लगभग 2010 के बाद ऐसा plugin system जारी करना बिना किसी बहाने के लापरवाही थी
  • मैं Obsidian का भारी उपयोग करता हूँ और मुझे यह पसंद है, लेकिन मुझे लगता है कि इस खुलासे की अहमियत प्लगइन्स के प्रति जागरूकता फैलाने और attack path दिखाने में है
    कम अनुभवी उपयोगकर्ता सोच सकते हैं, “यह तो बस Markdown फ़ाइलों का संग्रह है। शायद malware की ज़्यादा चिंता नहीं करनी चाहिए”

• लगभग हर plugin system इतना ढीला-ढाला डिज़ाइन क्यों होता है? मैं जानना चाहता हूँ कि क्या ऐसा इसलिए है क्योंकि सही isolation/permission features देने वाले अच्छे plugin development frameworks नहीं हैं, इसलिए काम बहुत ज़्यादा है, या इसलिए कि लोग व्यापक रूप से यह नहीं समझते कि क्या ज़रूरी है और अपनी system के दुरुपयोग के बाद ही सीखते हैं। या दोनों? या कोई और वजह है?

  • इसके मूल में functionality और security के बीच समझौता है। आप users को बहुत शक्तिशाली क्षमताएँ दे सकते हैं और उन्हें शानदार चीज़ें करने दे सकते हैं, या आप ज़्यादातर सार्थक क्षमताएँ हटाकर उसे सुरक्षित बना सकते हैं। आमतौर पर लोग security से ज़्यादा functionality पसंद करते हैं
    दूसरी समस्या यह है कि security कठिन है, जबकि सामान्य access देकर कुछ basic guards जोड़ना आसान है
  • आपको वह security framework और components परिभाषित करने पड़ते हैं जिनकी हर plugin को ज़रूरत होगी, और उन्हें डिज़ाइन, implement, verify और maintain करने में समय लगता है
    उस हिस्से को बस छोड़ देना कहीं आसान है। यानी हाँ, काम बहुत ज़्यादा है, और अधिक सटीक रूप से कहें तो इसके लिए security-focused leadership चाहिए जो समझे कि यह काम ज़्यादा है लेकिन सही काम है
  • मेरा अनुमान है कि वजह web stack और ठीक-ठाक interface डिज़ाइन करने के लिए resources की कमी है। ऐसा software high-level JS frameworks में लिखा जाता है, इसलिए डिफ़ॉल्ट रूप से data flow patterns अच्छे नहीं होते, और लोग जानबूझकर डिज़ाइन करने के बजाय वही अपनाते हैं जो व्यवहार में संभव हो
    अगर आप इसे इरादतन डिज़ाइन करना चाहें, तो आपको abstraction layers के नीचे जाना पड़ सकता है और उस framework के custom forks को maintain करना पड़ सकता है। इसलिए संभवतः उन्होंने plugins को ऐसे डिज़ाइन किया होगा जैसे app जिस context का उपयोग करता है उसका कुछ हिस्सा देकर library instantiate की जाती है। आखिरकार, यही सबसे सरल तरीका है जो काम करता है। सार्वजनिक रूप से बताए गए hack में किसी खास “vulnerability” का ज़िक्र नहीं है, लेकिन Obsidian plugins हमेशा से god mode में रहे हैं, और attacker ने बस लोगों को उसे इस्तेमाल करने के लिए बहकाया। कुछ popups के पीछे मूलतः remote code execution तैयार बैठी है और अंत में user को दोष देना हास्यास्पद है। developers को शर्म आनी चाहिए
  • Chrome browser plugins में भी इससे मिलती-जुलती security समस्याएँ हैं। इसमें अरबों डॉलर और बहुत से होशियार developers लगे हैं, फिर भी ऐसा है
    यह किसी app के भीतर app store बनाने जैसा है। Apple App Store हानिकारक apps को कम करने के लिए इस पर कड़ी सीमाएँ लगाता है कि कौन क्या publish कर सकता है, और paid barriers भी रखता है
  • plugin system का मतलब अपने-आप sandbox क्यों होना चाहिए?

• चाहे यह social engineering ही हो, अगर plugin system का डिज़ाइन ऐसी चीज़ की अनुमति देता है, तो यह platform shared tool के रूप में पूरी तरह अनुपयोगी है
  यह जानना उपयोगी है, लेकिन मेरे लिए बात “shared Obsidian vault इस्तेमाल करने के लिए यह setting सही रखनी होगी” जैसी नहीं, बल्कि “shared Obsidian vault कभी स्वीकार मत करो, और plain text export माँगो” जैसी है

• जब मैंने पहली बार Obsidian इस्तेमाल करना शुरू किया, तब जो YouTube वीडियो मैंने देखे, वे community plugins के इस्तेमाल की सिफारिश करते थे। ऐसी चेतावनियाँ होने पर भी मैं शायद community plugins चालू कर देता
  कोई plugin developer शुरुआत में नेक इरादे वाला हो सकता है और बाद में दुर्भावनापूर्ण बन सकता है, और users को पता नहीं चलेगा। मैं developer हूँ और इस जोखिम को जानते हुए भी शायद community plugins option चालू कर देता, इसलिए हो सकता है मेरी risk tolerance ज़्यादा हो। उम्मीद है कि मैं अल्पसंख्यक हूँ और ज़्यादातर users ऐसा व्यवहार नहीं करते

• इस तरह की चीज़ें थोड़ी महामारी जैसी फैल रही हैं। हर attack या exploit, खासकर social engineering attacks, को Metal Gear जैसी कोई नामकरण शैली या वेबसाइट की ज़रूरत नहीं होती

• अगर आप सामग्री पढ़ें, तो समस्या Obsidian store के plugin से शुरू नहीं हुई थी, बल्कि ऐसे malicious vault से शुरू हुई थी जिसे खोलने के लिए उकसाया गया

• मैं Obsidian को सीमित permissions के साथ चलाता हूँ। कोई network access नहीं, अपनी directory के बाहर filesystem access नहीं
  मैं network access सिर्फ़ plugins/themes update करते समय चालू करता हूँ। जिन दूसरे applications में untrusted code चल सकता है, उन्हें भी मैं इसी तरह चलाता हूँ

  • क्या आप बता सकते हैं कि आप इसे sandbox कैसे करते हैं?