SlowMist: Udesk का दुर्भावनापूर्ण JS डेटा चुराता है और ट्रांसफ़र पते बदल देता है

iconMetaEra
साझा करें
AI summary iconसारांश
SlowMist ने Udesk सिस्टम में एक दुर्भावनापूर्ण JS स्क्रिप्ट का पता लगाया, जो mgbx.com और bitxex.io जैसे दुर्भावनापूर्ण प्लेटफॉर्म के बारे में ऑन-चेन समाचार से जुड़ी हुई है। यह स्क्रिप्ट, udeskApi.2026-10-16.cached.js और deeps.js के माध्यम से लोड की जाती है, जो सत्र डेटा चुरा लेती है और पुनर्भरण पते बदल देती है। हमलावर एक रिमोट लोडर का उपयोग करके कोड इंजेक्ट करते हैं, जिससे धन चोरी का खतरा होता है। मुद्रास्फीति के डेटा और बाजार की अस्थिरता प्रभावित उपयोगकर्ताओं के नुकसान को बढ़ा सकती है। यह ब्रीच कई एक्सचेंजों में सुरक्षा की तत्काल चिंताओं को उजागर करता है।
एक स्क्रिप्ट पॉइजनिंग के माध्यम से, उपयोगकर्ता डेटा और ट्रांसफर की गई राशि दोनों को एक साथ कैसे लक्षित किया जा सकता है?

लेखक, स्रोत: मानवु टेक्नोलॉजी

बैकग्राउंड

हाल ही में, मैन वु सुरक्षा टीम ने दैनिक खतरा सूचना खोज के दौरान उडेस्क कस्टमर सर्विस सिस्टम से संबंधित स्क्रिप्ट्स को जहरीला बनाए जाने की एक हमले की निगरानी की। टीम ने बाद में udeskApi.2026-10-16.cached.js और deeps.js दो JavaScript नमूने प्राप्त किए और विश्लेषण किया कि दुर्भावनापूर्ण कोड कैसे कस्टमर सर्विस स्क्रिप्ट के माध्यम से पेज में प्रवेश करता है और यह उपयोगकर्ता डेटा और व्यापारिक कार्रवाइयों पर क्या प्रभाव डालता है।

सैंपल की जांच धीरे-धीरे दो प्रकार के जोखिमों को उजागर करती है: एक दुष्ट स्क्रिप्ट वेबपेज में सेशन डेटा और उपयोगकर्ता द्वारा सबमिट की गई संवेदनशील जानकारी को एकत्रित करते हुए, साथ ही साइट के नियमों के अनुसार रिचार्ज एड्रेस और कॉपी कंटेंट को बदल देती है। पहला जोखिम हमलावर को लॉगिन सेशन का दुरुपयोग करने या खाते पर कब्जा करने की अनुमति दे सकता है, जबकि दूसरा जोखिम उपयोगकर्ता को बदले हुए प्राप्ति पते पर रिचार्ज धनराशि भेजने के लिए प्रेरित कर सकता है। हम कस्टमर सपोर्ट स्क्रिप्ट के लोडिंग पॉइंट से शुरू करते हुए, डेटा पढ़ने, नेटवर्क पर भेजने और पेज मॉडिफिकेशन के तर्क के साथ-साथ, इन दोनों प्रकार की गतिविधियों के कार्यान्वयन और ट्रिगर स्थितियों को पुनः स्थापित करते हैं।

MistEye प्रतिक्रिया

MistEye, SlowMist द्वारा स्वयं विकसित एक Web3 खतरा सूचना और गतिशील सुरक्षा मॉनिटरिंग सिस्टम है, जो सुरक्षा मॉनिटरिंग और सूचना संग्रह क्षमताओं को एकीकृत करता है और उपयोगकर्ताओं को वास्तविक समय में जोखिम चेतावनी और संपत्ति संरक्षण प्रदान करता है।

MistEye ने जानकारी पुश और ग्राहक चेतावनी चैनल के माध्यम से जोखिम को तुरंत समन्वित किया है।

Malicious loader and remote payload loading mechanism

udeskApi.2026-10-16.cached.js खोलने पर, आप कस्टमर सपोर्ट बटन, चैट iframe, विज़िटर ट्रैकिंग और मैसेजिंग कम्युनिकेशन जैसे फ़ंक्शन्स का कोड देख सकते हैं। फ़ाइल के अंत की जांच करते समय, मुख्य कोड के बाद एक स्वतंत्र फ़ंक्शन होता है: यह _ud() के माध्यम से दो स्ट्रिंग्स को डिकोड करता है, एलिमेंट बनाता है और वर्तमान दस्तावेज़ के head में डालता है।

इस अनुच्छेद में टैग का नाम और रिमोट URL सीधे नहीं लिखा गया है। यदि केवल प्लेन टेक्स्ट डोमेन की खोज की जाए, तो लोडिंग एंट्री को छूट सकता है। हमने _ud() के कार्यान्वयन का अनुसरण किया, जिसमें पाया गया कि यह प्रत्येक बार दो हेक्साडेसिमल अक्षर लेता है और उन्हें वर्ण में बदलता है; स्थिरांक को विस्तारित करने के बाद, लोडिंग लक्ष्य स्पष्ट हो गया।

736372697074 को script के रूप में डिकोड किया जाता है, दूसरी जगह स्थिरांक को https[:]//udeskqlobal[.]com/deeps.js के रूप में डिकोड किया जाता है। डोमेन में qlobal अक्षर q से शुरू होता है, खोज के दौरान इस वर्तनी को बनाए रखा जाना चाहिए। लोडर स्क्रिप्ट को असिंक्रोनस के रूप में सेट करता है, फिर पेज में डालता है; जब तक यह स्थिति तक पहुँचा जाता है और ब्राउज़र की नीति और नेटवर्क अनुमति देते हैं, तब तक दूरस्थ कोड वर्तमान दस्तावेज़ में प्रवेश कर सकता है।

इस URL के संगत लोड होने वाला कंटेंट deeps.js है। जांच का ध्यान कस्टमर सपोर्ट SDK से लोड कंटेंट पर स्थानांतरित हो गया है। तीसरे पक्ष के पारंपरिक स्क्रिप्ट डॉक्यूमेंट के कॉन्टेक्स्ट में निष्पादित होते हैं, और वे उन डेटा तक पहुंच सकते हैं जो वास्तविक रूप से चल रहे पेज या iframe में लोड हुए हों। कस्टमर सपोर्ट चैट विंडो iframe का उपयोग करती है, और यह स्वचालित रूप से होस्ट पेज में लोड हुए स्क्रिप्ट्स को अलग नहीं करती है।

वेब पेज डेटा कलेक्शन मैकेनिज्म और प्रभाव क्षेत्र

deeps.js पहले window.location.hostname को पढ़ता है और तीन साइट नियमों के आधार पर कॉन्फ़िगरेशन C बनाता है। यह निर्धारित करने के लिए कि कौन से पेज एकत्रित किए जाएंगे, इस कॉन्फ़िगरेशन को देखना ही पर्याप्त नहीं है: यह पूरे स्क्रिप्ट को सीमित करता है या केवल किसी एक मॉड्यूल को, इसका पता लगाने के लिए बाहर निकलने के निर्णय स्थान का पता लगाना आवश्यक है।

नियंत्रण प्रवाह के नीचे जांचने पर, हम देखते हैं कि कुकी और वेब स्टोरेज पढ़ना, स्टार्ट स्नैपशॉट भेजना, और फॉर्म और प्रमाणीकरण अनुरोध हुक्स सभी if (!C) return; के पहले आते हैं। नीचे स्रोत कोड के क्रम में स्नैपशॉट भेजने का बयान और अंतिम XHR हुक दिया गया है; टिप्पणियों ने मध्यवर्ती छोड़े गए कोड को चिह्नित किया है, जो फॉर्मेटेड व्यू D:L100, D:L151–L166 के संगत हैं।

निकास निर्णय की स्थिति को स्पष्ट किया गया है: भले ही hostname तीन साइटों के नियमों से मेल न खाए, स्क्रिप्ट पहले डेटा संग्रह पथ में प्रवेश करेगा और हुक स्थापित करेगा, फिर ही एड्रेस मॉड्यूल से बाहर निकलेगा। प्रकट पृष्ठों की जांच करते समय, आपको केवल इन तीन साइटों के कॉन्फ़िगरेशन के आसपास ही खोज नहीं करनी चाहिए।

शुरू होने पर, लोड वर्तमान वेब पृष्ठ तक पहुँचने योग्य कुकी, localStorage और sessionStorage को पढ़ता है। ये स्थान लॉगिन स्थिति, उपयोगकर्ता प्रोफ़ाइल और व्यावसायिक डेटा सहेज सकते हैं; यदि इनमें से कोई भी अभी भी वैध और पुनः उपयोग के योग्य लॉगिन टोकन शामिल है, तो हमलावर इसे प्राप्त करके उपयोगकर्ता सत्र का दुरुपयोग कर सकता है। स्क्रिप्ट साथ ही टॉप-लेवल पेज URL और वर्तमान दस्तावेज़ का origin भी संलग्न करता है, ताकि ये डेटा मूल पृष्ठ के साथ सबमिट किए जा सकें।

संग्रह प्रक्रिया प्रत्येक आइटम के लिए त्रुटि सहिष्णु है। जब स्रोत से टॉप-लेवल URL पढ़ने में विफल होता है, तो स्क्रिप्ट x का उपयोग करती है और अन्य क्षेत्रों को संसाधित करना जारी रखती है; दो प्रकार की वेबसाइट स्टोरेज को JSON में सीरियलाइज़ किया गया है। कुकी का दायरा document.cookie द्वारा पठनीय सामग्री तक सीमित है, HttpOnly कुकीज़ इसमें शामिल नहीं हैं।

स्क्रिप्ट भविष्य में जमा किए गए डेटा के लिए भी एक एंट्री बनाए रखता है। जब उपयोगकर्ता फॉर्म जमा करता है, तो यह input, select और textarea को आवर्तित करता है, खाली नहीं होने वाली सामग्री को कॉपी करता है, और मूल जमा प्रक्रिया को जारी रखता है। खाता, पासवर्ड, कैप्चा आदि पेज पर वास्तविक रूप से भरे गए क्षेत्र अतिरिक्त डेटा प्रेषण पथ में शामिल हो सकते हैं, जिससे उनका उपयोग खाते में प्रवेश करने या खाते पर कब्जा करने के लिए किया जा सकता है।

यह पथ HTMLFormElement.prototype.submit को लपेटकर और कैप्चर चरण में submit इवेंट को सुनकर लागू किया गया है। डेटा को सीधे इंटरफ़ेस के माध्यम से सबमिट करने वाले पृष्ठों के लिए, स्क्रिप्ट fetch और XHR को भी लपेटती है: जब अनुरोध में शरीर होता है और URL login|signin|auth|register|signup|password जैसे कीवर्ड्स को हिट करता है, तो संबंधित सामग्री की प्रतिलिपि बनाई जाती है और मूल अनुरोध कॉल बनाए रखा जाता है। fetch शाखा में अतिरिक्त आवश्यकता है कि URL स्ट्रिंग हो, और शरीर अनुरोध विकल्पों से आता हो; FormData जैसे ऑब्जेक्ट्स को सीधे JSON सीरियलाइज़ करने पर, संग्रहीत सामग्री में वास्तविक क्षेत्रों की कमी हो सकती है।

डेटा लीक मैकेनिज्म और बैकअप चैनल

उपरोक्त डेटा संग्रह एंट्री अंततः एक ही _send() को कॉल करती है। इस फ़ंक्शन का अनुसरण करते हुए, आप देख सकते हैं कि निर्धारित रिसीविंग एंडपॉइंट https[:]//udeskqlobal[.]com/c.php है। स्नैपशॉट शुरू करने पर s, o, c, l, ss फील्ड क्रमशः पेज एड्रेस, वर्तमान स्रोत, पठनीय कुकी और दो प्रकार के वेब स्टोरेज को संभालते हैं; बाद के फॉर्म और प्रमाणीकरण अनुरोध अपने-अपने ट्रिगर होने पर भेजे जाते हैं।

फ़ंक्शन URL के प्रश्नवाचक चिह्न के बाद के पैरामीटर्स को अलग करता है और उन्हें एसिंक्रोनस POST बॉडी में डालता है, Content-Type: application/x-www-form-urlencoded सेट करता है। नीचे पूर्ण रूप से भेजने वाला फ़ंक्शन (D:L45–L60) बरकरार रखा गया है:

प्रेषण पथ में चित्र अनुरोध के लिए बैकअप भी शामिल है: जब XHR में त्रुटि आती है या प्रेषण प्रक्रिया में समन्वयित असामान्यता होती है, तो स्क्रिप्ट एक Image ऑब्जेक्ट बनाती है और पैरामीटर के साथ URL को src में असाइन करके डेटा को फिर से GET के माध्यम से भेजने का प्रयास करती है। URL को 8,000 JavaScript वर्णों तक काट दिया जाता है, इसलिए लंबी सामग्री अपूर्ण हो सकती है।

इस पथ को समझते समय, "अनुरोध भेजना" और "प्रतिक्रिया पढ़ना" के बीच अंतर करना आवश्यक है। स्क्रिप्ट c.php की प्रतिक्रिया नहीं पढ़ती है; सरल अनुरोध की शर्तों को पूरा करने वाला क्रॉस-ओरिजिन POST पहले भेजा जा सकता है, और फिर ब्राउज़र द्वारा प्रतिक्रिया पढ़ने को सीमित किया जा सकता है, इसलिए CORS त्रुटि और अनुरोध भेजना एक साथ हो सकते हैं। निदान रिकॉर्ड में POST शरीर और चित्र GET पैरामीटर दोनों की जांच करनी चाहिए, जबकि आउटगोइंग नीति connect-src और img-src को अलग-अलग जांचनी चाहिए। सामान्य फॉर्म यदि दस्तावेज़ नेविगेशन को प्रेरित करता है, तो असमानांतर अनुरोध के पूरा होने पर प्रभाव डाल सकता है।

अब तक, वेबसाइट सत्र डेटा और आगे के सबमिशन की दिशा स्पष्ट हो चुकी है। हालांकि, लोड के बाद साइट एग्जिट जांच के बाद एक अन्य सेट ऑपरेशन्स बनी हुई हैं: पते के फॉर्मेट की पहचान, पेज के टेक्स्ट को बदलना, और कॉपी पाथ पर कब्जा करना। ये कोड जांच को डिपॉजिट बिजनेस की ओर आगे ले जाते हैं।

Deposit address replacement and clipboard hijacking mechanism

if (!C) return; के बाद, स्क्रिप्ट पता मॉड्यूल में प्रवेश करती है। प्रारंभिक तीन hostname नियमों का अब स्पष्ट उद्देश्य है: mgbx[.]com, bikingex[.] और bitxex[.]io को मैच करना, ताकि विभिन्न पृष्ठों के लिए पता और कॉपी बटन के एलिमेंट सिलेक्टर्स का चयन किया जा सके।

इन नियमित अभिव्यक्तियों में शुरुआत और अंत के एंकर नहीं हैं, इसलिए मिलान का दायरा सटीक डोमेन नाम तुलना से अधिक है। पेज नियम अतिरिक्त रूप से पूर्ण location.href, क्वेरी पैरामीटर या फ्रैगमेंट में deposit, recharge, assets आदि कीवर्ड की जांच करते हैं। पेज, तत्व और पते के प्रारूप में मिलान होने पर, स्क्रिप्ट प्रत्येक 200 मिलीसेकंड में स्कैन करती है और पहचाने गए रीचार्ज पते को कॉन्फ़िगरेशन मान से बदल देती है। यदि उपयोगकर्ता बदले गए पते का उपयोग करके एक मान्य ट्रांसफर पूरा करता है, तो प्राप्ति लक्ष्य उस पते में बदल जाएगा।

तीन साइट ब्रांच छह कॉन्फ़िगरेशन मानों का उपयोग करते हैं, जिन्हें कोड के रूप में BTC, EVM, TRON, Solana, LTC और DOGE चिह्नित किया गया है। पता पहचान केवल वर्णों के रूप और मेल के क्रम पर निर्भर करती है, उपयोगकर्ता द्वारा चुने गए नेटवर्क या पता चेकसम की जांच नहीं की जाती है, और यह सामान्य व्यावसायिक पहचानकर्ताओं को भी गलती से पहचान सकती है।

प्रतिलिपि से संबंधित कोड की जांच जारी रखें, जिससे आप देख सकते हैं कि नमूना एक साथ पृष्ठ प्रदर्शन और क्लिपबोर्ड सामग्री को प्रभावित करता है। इस प्रकार, यहां तक कि यदि उपयोगकर्ता पृष्ठ पते और प्रतिलिपि परिणाम की तुलना करता है, तो भी वे समान रूप से विकृत मान प्राप्त कर सकते हैं। तीन मार्ग हैं:

  • पैकेज क्लिपबोर्ड API। navigator.clipboard.writeText पहले R() को कॉल करके पैरामीटर को बदलता है, फिर मूल विधि को सौंपता है। यह पथ केवल hostname कॉन्फ़िगरेशन से सीमित है, भुगतान पृष्ठ की शर्तों की पुनः जांच नहीं करता है और DOM स्कैनिंग पर निर्भर नहीं करता है।
  • कॉपी बटन को बदलें। स्क्रिप्ट मिलान वाले बटन को क्लोन करती है, एक नया क्लिक लिसनर इंस्टॉल करती है और मूल नोड को प्रतिस्थापित करती है। नया लिसनर डिफ़ॉल्ट कार्रवाई और घटना प्रसार को रोकता है, और साझा चर _cur में सहेजे गए पते को कॉपी करने का प्रयास करता है।
  • कॉपी घटना को अवरुद्ध करें। जब _cur खाली नहीं है और पृष्ठ नियम सत्य है, तो document पर लिसनर कॉपी किए गए सामग्री को _cur में बदल देता है, और उपयोगकर्ता द्वारा चयनित पाठ को पते के रूप में जांचे बिना।

इसमें, क्लिपबोर्ड API वैपर और कॉपी लिसनर सोर्स कोड में पास-पास हैं (D: L260–L275), लेकिन ट्रिगर कंडीशन अलग हैं:

_cur संग्रहित करता है अंतिम वास्तविक प्रतिस्थापित पता। एक ही स्क्रीन पर कई पते होने पर, अगला प्रतिस्थापन पिछली प्रविष्टि को ओवरराइट कर देता है, और कई बटन एक ही मान कॉपी कर सकते हैं। यदि पृष्ठ प्रारंभिक रूप से कॉन्फ़िगर किए गए पते को दर्शा रहा है, तो स्कैनिंग _cur को प्रारंभ नहीं करेगी, और नवीन बटन लिसनर भी कोई सामग्री नहीं लिखेगा; क्लोन किए गए संग्रहित HTML इनलाइन इवेंट गुण अभी भी इवेंट प्रोसेसिंग में शामिल हो सकते हैं।

विश्लेषण में एक ऐसी कार्यान्वयन दोष भी मिली है जो व्यवहार के निर्णय को प्रभावित करती है: स्क्रिप्ट Element.prototype से textContent के स्वामित्व वाले गुण विवरण को पढ़ने का प्रयास कर रही है, जबकि मानक गुण Node.prototype पर परिभाषित हैं। मानक प्रोटोटाइप संबंध के अनुसार, .set के बाद के संपर्क से अपवाद फेंका जाएगा। इस शाखा की विफलता के बाद, catch अपवाद को निगल लेता है; इसके पहले और बाद के कोड की जांच करने पर पता चलता है कि पोलिंग पहले से ही दर्ज है, और बाद में कॉपी हुक्स अपनी-अपनी शर्तों के अनुसार स्थापित किए जाएंगे। एकल शाखा की त्रुटि ने पता हस्तांतरण मॉड्यूल को समाप्त नहीं किया।

Summary

कस्टमर सपोर्ट स्क्रिप्ट के अंत में लोडर का अनुसरण करने के बाद, हमने नमूने के हमले के लक्ष्य को स्पष्ट किया: सत्र या खाते का दुरुपयोग करने के लिए उपयोग किए जाने वाले डेटा को इकट्ठा करना, और रीचार्ज पेज और कॉपी ऑपरेशन में प्राप्ति पते को कॉन्फ़िगरेशन मान में बदलना। पहला तीन साइटों के कॉन्फ़िगरेशन से प्रतिबंधित नहीं है, जबकि दूसरा साइट और विशिष्ट कॉपी पथ के आधार पर सक्षम है, और निदान के दौरान विभिन्न प्रकट होने की स्थितियों को कवर करना आवश्यक है।

अभी भी संबंधित स्क्रिप्ट लोड कर रहे बिजनेस को वितरण बंद कर देना चाहिए, प्रकट हुए पासवर्ड का निपटान करना चाहिए, और भर्ती लक्ष्य की जांच के लिए विश्वसनीय बैकएंड और लेन-देन के रिकॉर्ड का उपयोग करना चाहिए।

सुझाव

  1. संक्रमित संसाधनों को सुरक्षित करें और उनका वितरण रोकें। यदि उत्पादन में अभी भी संबंधित स्क्रिप्ट्स लोड हो रहे हैं, तो वास्तविक प्रतिक्रिया, अनुरोध श्रृंखला, कैश सूचना और संग्रहण समय को सहेजें और जल्द से जल्द ब्लॉक कर दें; एक स्वतंत्र रूप से सत्यापित विश्वसनीय संस्करण से पुनर्स्थापित करें और साइट होस्टिंग, CDN, बिल्ड और टैग प्रबंधन कॉन्फ़िगरेशन की जांच करें।
  2. एक्सटेंशन रिकॉर्ड्स के साथ लोडिंग का पता लगाएं। दुष्ट डोमेन, दो पथ और फाइल हैश के लिए जॉइन क्वेरी करें; एक्सटेंशन रिकॉर्ड्स में POST बॉडी और GET पैरामीटर्स की जांच करें। संपीड़ित स्क्रिप्ट्स की जांच के दौरान लोडर में हेक्साडेसिमल URL का भी पता लगाएं, ताकि केवल प्लेन टेक्स्ट के कारण कोई लापता न हो।
  3. संक्रमित दस्तावेज़ को समाप्त करें और उजागर हुए पारित्रों को निपटाएं। संबंधित पृष्ठ या WebView दस्तावेज़ को पूरी तरह से बंद करें, ताकि पुराने संसाधनों को पुनः लोड न किया जा सके। उजागर के वास्तविक दायरे के आधार पर, स्वच्छ परिवेश से सत्र रद्द करें, टोकन और पासवर्ड बदलें; script टैग हटाने से पहले स्थापित हुए हुक और टाइमर रद्द नहीं होते।
  4. अपने जमा पते और लेनदेन की स्वतंत्र रूप से जांच करें। लोड निष्पादित करने वाले पेज के लिए, विश्वसनीय स्रोतों से मूल जमा पता, संबंधित लेनदेन और वास्तविक ट्रांसफर लक्ष्य की पुष्टि करें, और लेनदेन रिकॉर्ड के आधार पर प्रभाव का मूल्यांकन करें।
  5. स्क्रिप्ट वेरिफिकेशन और डेटा एक्सपोर्ट लिमिटेशन। बिजनेस सेटिंग्स के साथ स्क्रिप्ट सोर्स और इंटेग्रिटी कंट्रोल को जोड़ें, connect-src, img-src आदि पॉलिसीज की अलग-अलग वेरिफिकेशन करें, udeskqlobal[.]com के लिए स्क्रिप्ट लोडिंग और डेटा एक्सट्रैक्शन को सीमित करें।

IOC

Domain

udeskqlobal[.]com

URL

https[:]//udeskqlobal[.]com/deeps[.]js

https[:]//udeskqlobal[.]com/c[.]php

Wallet address

BTC: bc1qhzppfj69ywp22swj50jwcfxdamg3ym245srng9

EVM: 0x9B6EcD0023a28E1391c5124eCe578A9751A337b2

TRON: TH4L5YAhhxtC8qALbZKbPZZgausbGi25nF

सोलाना: AFmCUe3nNbjTaC585CcdA3vvC9iWVR8YunooFKpaQx2Z

LTC: ltc1qwz0zp39ywl34kahvn9lyk7j5x63wsy9tcxhm3w

DOGE: DAoy2w8uvFtZ92q87s9qKEoHbWgV7mVThj

मैलिशियस फाइल

फाइलनाम: udeskApi.2026-10-16.cached.js

SHA256: 45b4e8f160d8d5177819f6c1dc67acc7abbdc65eeaffc909e668799dc778bcf6

फाइलनाम: deeps.js

SHA256: 57c1441c4f5bb3260981a2df64f9ff35f117abde0d8667c8c66a047880074c59

MistEye के बारे में

MistEye, SlowMist द्वारा स्वयं विकसित एक Web3 खतरा सूचना और गतिशील सुरक्षा मॉनिटरिंग प्लेटफॉर्म है, जो API के माध्यम से ओपन सोर्स पैकेज इकोसिस्टम के लिए दुर्भावनापूर्ण गतिविधि का पता लगाने और सप्लाई चेन जोखिम की चेतावनी प्रदान करता है।

इस अभियान में शामिल सभी दुर्भावनापूर्ण पैकेज और IOC को MistEye खतरा पता लगाने वाले इंजन में एकीकृत कर दिया गया है, जिससे डेवलपर्स API के माध्यम से प्रोजेक्ट निर्भरताओं की स्वचालित जांच कर सकते हैं और त्वरित रूप से ज्ञात दुर्भावनापूर्ण पैकेज के साथ मेल खाने की पहचान कर सकते हैं तथा उपचार सुझाव प्राप्त कर सकते हैं।

डिस्क्लेमर: इस पेज पर दी गई जानकारी थर्ड पार्टीज़ से प्राप्त की गई हो सकती है और यह जरूरी नहीं कि KuCoin के विचारों या राय को दर्शाती हो। यह सामग्री केवल सामान्य सूचनात्मक उद्देश्यों के लिए प्रदान की गई है, किसी भी प्रकार के प्रस्तुतीकरण या वारंटी के बिना, न ही इसे वित्तीय या निवेश सलाह के रूप में माना जाएगा। KuCoin किसी भी त्रुटि या चूक के लिए या इस जानकारी के इस्तेमाल से होने वाले किसी भी नतीजे के लिए उत्तरदायी नहीं होगा। डिजिटल संपत्तियों में निवेश जोखिम भरा हो सकता है। कृपया अपनी वित्तीय परिस्थितियों के आधार पर किसी प्रोडक्ट के जोखिमों और अपनी जोखिम सहनशीलता का सावधानीपूर्वक मूल्यांकन करें। अधिक जानकारी के लिए, कृपया हमारे उपयोग के नियम और जोखिम प्रकटीकरण देखें।