CWPdoor और cPGuard हमले: ट्रोजनाइज़्ड सॉफ़्टवेयर और दुर्भावनापूर्ण अपडेट के ज़रिए Linux सर्वर निशाने पर

बैकडोर वाला Control Web Panel बाइनरी और हाईजैक किया गया cPGuard अपडेट चैनल दो अलग घटनाएं हैं। होस्टिंग एडमिनिस्ट्रेटर के लिए हर एक का क्या मतलब है, यह यहां बताया गया है।

Linux होस्टिंग एनवायरनमेंट को प्रभावित करने वाली दो घटनाएं

नवंबर 2026 की शुरुआत में शोधकर्ताओं और वेंडरों ने दो अलग सुरक्षा घटनाओं का खुलासा किया, जिनमें Linux होस्टिंग सर्वर को मैनेज और सुरक्षित करने वाले टूल शामिल थे। 5 नवंबर को QiAnXin XLab ने CWPdoor पर शोध प्रकाशित किया, जो Control Web Panel (CWP) द्वारा इस्तेमाल होने वाले cwpsrv वेब-सर्वर बाइनरी के एक संशोधित संस्करण में छिपाया गया बैकडोर है। इससे अलग, OPSSHIELD ने 3 नवंबर को बताया कि एक हमलावर उसके इन्फ्रास्ट्रक्चर के एक हिस्से में घुस गया था और उसने 2 नवंबर को उसके cPGuard अपडेट चैनल के ज़रिए एक दुर्भावनापूर्ण अपडेट भेजा।

घटना	हमले का रास्ता	सुरक्षा पर असर
CWPdoor	हमलावर की दी हुई, अपडेटर जैसी एक स्क्रिप्ट cwpsrv को ट्रोजनाइज़्ड बाइनरी से बदल देती है	छिपा हुआ रिमोट कमांड एक्ज़ीक्यूशन
cPGuard	चुराए गए अपडेट-वितरण क्रेडेंशियल के कारण दुर्भावनापूर्ण अपडेट ग्राहकों के सर्वर तक पहुंच पाता है	root स्तर पर एक्ज़ीक्यूशन, क्रेडेंशियल का उजागर होना और पर्सिस्टेंस (persistence)

इन घटनाओं को एक ही अभियान या एक ही कंप्रोमाइज़ हुआ अपडेट चैनल नहीं बताया जाना चाहिए। XLab ने यह स्थापित नहीं किया है कि वैध CWP वेंडर के आधिकारिक अपडेट इन्फ्रास्ट्रक्चर में सेंध लगी थी। XLab कहता है कि उसे नहीं पता कि स्क्रिप्ट सर्वर तक कैसे पहुंचती है या किस कमज़ोरी का इस्तेमाल होता है। cPGuard घटना में OPSSHIELD के वितरण तंत्र का वास्तविक कंप्रोमाइज़ हुआ था। दोनों में जो बात साझा है, वह व्यावहारिक है: दोनों ऐसे सॉफ़्टवेयर के ज़रिए सर्वर तक पहुंचते हैं जो ऊंचे प्रिविलेज के साथ चलता है, इसलिए दोनों मामलों में जवाब यही है कि पहले बाइनरी की जांच करें, फिर वह सब रोटेट करें जिसे कोई root प्रोसेस पढ़ सकता था।

CWPdoor: वेब सर्वर काम करता रहता है, जबकि अंदर एक बैकडोर छिपा रहता है

CWP सर्वर-होस्टिंग के लिए एक एडमिनिस्ट्रेशन इंटरफ़ेस देता है। इसका cwpsrv कंपोनेंट मैनेजमेंट ट्रैफ़िक संभालता है। XLab के अनुसार, उसके Cyber Threat Insight and Analysis System ने 29 जून, 2026 को cwpsrv_update.sh नाम की एक स्क्रिप्ट पकड़ी। यह स्क्रिप्ट 136.0.141[.]71 से cwpsrv नाम की एक फ़ाइल डाउनलोड करती है और सिस्टम पर इसी नाम की फ़ाइल को उससे बदल देती है। XLab कहता है कि स्क्रिप्ट केवल cwpsrv के वर्शन 1.24.0 और 1.15.10 को सपोर्ट करती है और उसका root के रूप में चलना ज़रूरी है।

XLab इस बदले गए बाइनरी को एक पैसिव (passive) बैकडोर बताता है। सामान्य अनुरोधों के लिए यह वैध cwpsrv की तरह व्यवहार करता है और केवल उस अनुरोध पर कार्रवाई करता है जिसमें तीन खास हेडर हों: X-Ngx-Integrity-Time, X-Ngx-Integrity-Data और X-Ngx-Integrity-Sig। अगर टाइमस्टैम्प या सिग्नेचर की जांच विफल होती है, तो अनुरोध सामान्य ट्रैफ़िक की तरह आगे बढ़ता है। XLab यह भी कहता है कि बैकडोर अनुरोध के मॉड्यूल कॉन्टेक्स्ट में छेड़छाड़ करता है ताकि लॉगिंग मॉड्यूल उस अनुरोध को दर्ज न करे, और यह कि स्क्रिप्ट फ़ाइलों और डायरेक्टरी के टाइमस्टैम्प बहाल कर देती है और history -d चलाती है। TechiesJournal का अपना अनुमान, XLab का बयान नहीं, यह है कि ऐसे बैकडोर को उपलब्धता जांचों (availability checks) से पकड़ना कठिन है, क्योंकि पैनल काम करता रहता है।

XLab यह भी बताता है कि evidencia.tgz नाम की एक फ़ाइल 30 सितंबर, 2026 को ब्राज़ील से VirusTotal पर अपलोड की गई थी। उसमें एक cwpsrv.suspeito फ़ाइल थी, जिसे XLab CWPdoor के रूप में पहचानता है और जिसका डिटेक्शन शून्य था, और उसके साथ एक सैंपल था जिसे ज़्यादातर वेंडरों ने Ebury बैकडोर के रूप में पहचाना। XLab का निष्कर्ष है कि असली पीड़ित मौजूद हैं, और वह कहता है कि Ebury और CWPdoor के बीच संबंध स्पष्ट नहीं है।

XLab द्वारा उद्धृत QiAnXin के Hunter Platform के डेटा के अनुसार, पिछले एक महीने में 340,000 से ज़्यादा CWP इंस्टेंस इंटरनेट पर उजागर (exposed) थे (XLab)। यह आंकड़ा एक्सपोज़र को मापता है, पुष्ट संक्रमणों को नहीं, और इससे यह स्थापित नहीं होता कि कितने सिस्टम तक ट्रोजनाइज़्ड बाइनरी पहुंचा।

स्रोत: QiAnXin XLab, CWPdoor।

cPGuard: भरोसेमंद सॉफ़्टवेयर अपडेट ही हमले का रास्ता बन गए

OPSSHIELD के 3 नवंबर के खुलासे के अनुसार, एक हमलावर 1 और 2 नवंबर को उसके बिलिंग और लाइसेंसिंग एनवायरनमेंट में घुसा, अपडेट प्रकाशित करने के लिए इस्तेमाल होने वाली कुंजियां (keys) ले गया और 2 नवंबर को एक नकली cPGuard अपडेट अपलोड किया। वेंडर कहता है कि cPGuard एजेंटों ने इसे लगभग 02:08 से 03:20 UTC के बीच इंस्टॉल किया। किसी सर्वर को प्रभावित न मानने के लिए इस समय-सीमा पर भरोसा न करें। OPSSHIELD की एडवाइज़री के उदाहरण लॉग एंट्री में प्रभावित वर्शन 2 नवंबर को 12:46 तक इंस्टॉल होते दिखते हैं, और एडवाइज़री कहती है कि लॉग का न होना या अधूरा होना अपने आप में यह नहीं दिखाता कि सर्वर प्रभावित नहीं हुआ। अगर आप निश्चित नहीं हैं, तो वह OPSSHIELD Support से संपर्क करने की सलाह देती है।

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

वेंडर द्वारा बताया गया अवलोकन	दायरा
दुर्भावनापूर्ण अपडेट चलाने वाले ग्राहक सर्वर	लगभग 2,950
कॉपी किए गए बिलिंग-पोर्टल अकाउंट रिकॉर्ड	लगभग 7,900
प्रभावित अपडेट वर्शन (OPSSHIELD एडवाइज़री)	5.88.12 से 5.88.19 तक

OPSSHIELD कहता है कि बिलिंग अकाउंट के पासवर्ड bcrypt हैश के रूप में संग्रहीत थे। ये आंकड़े वेंडर द्वारा बताए गए घटना-निष्कर्ष हैं, न कि इस बात की स्वतंत्र पुष्टि कि हर सर्वर से ठीक-ठीक क्या बाहर ले जाया गया। सर्वरों की संख्या भी बदली है: OPSSHIELD की पहली एडवाइज़री ने अनुमान लगाया था कि हमलावर ने इकट्ठा की गई 32 फ़ाइलें हासिल कीं, और इसे पुष्ट रूप से हासिल की गई फ़ाइलों की प्रारंभिक गिनती बताया था, प्रभावित सर्वरों की संख्या नहीं, जबकि उसका बाद का खुलासा बताता है कि लगभग 2,950 सर्वरों ने अपडेट चलाया।

स्रोत: OPSSHIELD घटना खुलासा (नवीनतम) और OPSSHIELD एडवाइज़री (पहले के निष्कर्ष)।

cPGuard एडमिनिस्ट्रेटर को क्या करना चाहिए

OPSSHIELD की एडवाइज़री cPGuard 5.88.25 या उसके बाद का वर्शन चलाने को कहती है। उसका बाद का खुलासा 5.88.26 को साफ़ (clean) रिलीज़ बताता है और कहता है कि एक और अपडेट i93677 शेड्यूल्ड टास्क को हटाता है। नवीनतम वर्शन पर अपडेट करें, फिर पुष्टि करें कि नीचे सूचीबद्ध फ़ाइलें हट चुकी हैं। एडवाइज़री ये कदम इसी क्रम में बताती है।

1. अपडेट हिस्ट्री जांचें। 5.88.12 से 5.88.19 तक की कोई एंट्री होने का मतलब है कि सर्वर ने एक प्रभावित अपडेट इंस्टॉल किया। OPSSHIELD कहता है कि इससे इंस्टॉलेशन की पुष्टि होती है, यह नहीं कि कौन-सी फ़ाइलें भेजी गईं, और यह कि ऐसे सर्वर को संभावित रूप से कंप्रोमाइज़ माना जाना चाहिए, भले ही वह अब 5.88.25 या उसके बाद का वर्शन चला रहा हो।

grep 'Successfully updated' /opt/cpguard/logs/install_log

2. अपडेट करें।

cpgcli update --start

3. वर्शन की पुष्टि करें। OPSSHIELD की एडवाइज़री 5.88.25 या उसके बाद का वर्शन मांगती है और कहती है कि अपडेट विफल होने पर सपोर्ट से संपर्क करें।

cpgcli --version

4. पुष्टि करें कि बची हुई फ़ाइलें हट चुकी हैं। खुलासा /etc/cron.d/i93677, /var/tmp/.i93677/ और /var/tmp/.cpg91511_sh के नाम बताता है। एडवाइज़री इनमें /var/tmp/.cpg91511 और /var/tmp/.cpg91511/loot.tgz जोड़ती है। OPSSHIELD कहता है कि सफ़ाई के बाद इन फ़ाइलों का न होना यह स्थापित नहीं करता कि स्क्रिप्ट पहले चली थी या नहीं।

5. क्रेडेंशियल रोटेट करें। एक साफ़ अपडेट पहले से कॉपी हो चुके क्रेडेंशियल को रद्द (revoke) नहीं करता। OPSSHIELD संभावित रूप से प्रभावित सर्वरों के एडमिनिस्ट्रेटर से कहता है कि वे:

• root और सभी लोकल अकाउंट के पासवर्ड रीसेट करें, एडवाइज़री के अनुसार किसी भरोसेमंद रिकवरी एनवायरनमेंट से, और दूसरे सिस्टम पर दोबारा इस्तेमाल किए गए पासवर्ड किसी भरोसेमंद डिवाइस से बदलें।
• root की SSH कुंजियां बदलें और जिन सिस्टम ने उन पर भरोसा किया था, उन सभी पर authorized_keys से पुरानी पब्लिक कुंजियां हटाएं। जब तक कुंजियां बदली नहीं जातीं, उन कुंजियों से पहुंच में आने वाले दूसरे सर्वरों को उजागर (exposed) मानें।
• MySQL root पासवर्ड और /root/.my.cnf में संग्रहीत डेटाबेस पासवर्ड बदलें।
• root की शेल हिस्ट्री में मिले पासवर्ड, API कुंजियां और टोकन रोटेट करें, साथ ही /root/.s3cfg में मौजूद कुंजियां और कोई भी DigitalOcean टोकन (एडवाइज़री दोनों के नाम बताती है)।
• OPSSHIELD बिलिंग-पोर्टल का पासवर्ड रीसेट करें और टू-फ़ैक्टर लॉगिन चालू करें। खुलासा यह रीसेट उन मामलों में भी करने को कहता है जहां उस समय-सीमा के दौरान cPGuard ऑफ़लाइन था।
• 1 नवंबर से पहले लिए गए किसी साफ़ बैकअप से सर्वर को दोबारा तभी बनाएं (rebuild) जब OPSSHIELD ने आपको बताया हो कि हमलावर ने आपके सर्वर में हाथ से (manually) लॉगिन किया था। अन्यथा एडवाइज़री नियमित रीबिल्ड की सलाह नहीं देती, और इस आकलन को अस्थायी बताती है।

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

CWP एडमिनिस्ट्रेटर को क्या करना चाहिए

XLab नीचे दी गई होस्ट जांचें प्रकाशित करता है। पहली जांच Unix सॉकेट ngx_http_integrity_helper को खोजती है, जिसे CWPdoor इंटर-प्रोसेस कम्युनिकेशन के लिए इस्तेमाल करता है।

ss -axp | grep integrity
ps aux | grep cwpsrv
strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-Integrity

दूसरे कमांड के लिए XLab कहता है कि cwpsrv के संदिग्ध हेल्पर चाइल्ड प्रोसेस देखें। तीसरे के लिए वह कहता है कि बाइनरी में संदिग्ध X-Ngx-Integrity स्ट्रिंग देखें। नेटवर्क टीमें फ़ायरवॉल और प्रॉक्सी लॉग में 136.0.141[.]71 की ओर जाने वाले कनेक्शन भी खोज सकती हैं। XLab इस पते को डाउनलोडर के रूप में सूचीबद्ध करता है।

अगर संक्रमण की पुष्टि होती है, तो XLab तीन कदमों की सलाह देता है। पहला, दुर्भावनापूर्ण cwpsrv को उस वैध बैकअप से बदलें जिसे हमलावर की स्क्रिप्ट ने /usr/local/cwpsrv/bin में बनाया था और जिसका नाम cwpsrv.prev- के बाद एक टाइमस्टैम्प होता है। दूसरा, नवीनतम वर्शन पर अपग्रेड करें और पुष्टि करें कि ss -axp | grep integrity अब कोई मैच नहीं लौटाता। तीसरा, सभी कंट्रोल पैनल क्रेडेंशियल तुरंत रोटेट करें, उन्हें कंप्रोमाइज़ मानें, और होस्ट को भी कंप्रोमाइज़ मानकर दूसरे खतरों के लिए उसकी जांच करें।

ध्यान दें कि XLab यह भी कहता है कि बदलाव सफल होने पर स्क्रिप्ट अपना बैकअप मिटा देती है, इसलिए वह cwpsrv.prev- फ़ाइल शायद मौजूद न हो। TechiesJournal का अनुमान है कि किसी भरोसेमंद CWP स्रोत से लिया गया बाइनरी बदलने के लिए ज़्यादा सुरक्षित विकल्प है। XLab आपसे होस्ट को कंप्रोमाइज़ मानने को कहता है, क्योंकि बैकडोर मनमाने कमांड चला सकता है, इसलिए केवल बाइनरी बदलना काफ़ी नहीं है।

स्रोत: QiAnXin XLab, CWPdoor।

एडमिनिस्ट्रेटर के लिए मुख्य सबक

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

संदर्भ

• QiAnXin XLab: CWPdoor शोध, 5 नवंबर, 2026
• OPSSHIELD घटना खुलासा (नवीनतम), 3 नवंबर, 2026
• OPSSHIELD एडवाइज़री (पहले के निष्कर्ष), 3 नवंबर, 2026

स्रोत 12 नवंबर, 2026 को पढ़े गए। OPSSHIELD कहता है कि वह अपने खुलासे को अपडेट करता रहेगा, इसलिए कोई कदम उठाने से पहले इसे जांच लें।