CARBONATO: आईआई-कीड़ा डॉकर सर्वरों को हैक कर रहा है। VPS पर पार्सर रखने वालों के लिए चेकलिस्ट

22 सितंबर 2026 को, ThreatDown के शोधकर्ताओं ने CARBONATO बॉटनेट का वर्णन किया। यह बिना पासवर्ड के खुले Docker API के माध्यम से सर्वरों में प्रवेश करता है, होस्ट पर एक AI एजेंट स्थापित करता है और सबसे पहले भाषा मॉडल की कुंजियों की तलाश करता है। SSH कुंजियाँ और एक्सेस टोकन बाद में आते हैं। यदि आपके VPS पर कंटेनरों में पार्सर चल रहे हैं, और .env में OpenRouter या OpenAI की कुंजियाँ और प्रॉक्सी लॉगिन हैं, तो यह आपका जोखिम प्रोफ़ाइल है। नीचे हम हमले के तरीके का विश्लेषण करते हैं, और 15 मिनट का चेकलिस्ट जो इस प्रवेश को बंद कर देता है।

क्या मिला: 4.3 जीबी इमेज और GH0ST नाम का एजेंट

यह सब ऑपरेटरों के खुले Docker रजिस्ट्रियों से शुरू हुआ। ThreatDown के अनुसार, इसमें 59 रिपॉजिटरी, 234 इमेज टैग और 4.3 जीबी डेटा था। संग्रह अक्टूबर 2024 से अगस्त 2026 तक के समय को कवर करता है, यानी बॉटनेट लगभग दो साल तक काम करता रहा, इससे पहले कि इसका वर्णन किया गया। रिपॉजिटरी में XMRig माइनर और fsociety/agent जैसे नामों वाली इमेज मिलीं।

संक्रमण की श्रृंखला रिपोर्ट के अनुसार इस प्रकार है:

1. स्कैनर उन होस्टों की तलाश करता है, जहाँ Docker API TCP 2375 पर बिना प्रमाणीकरण के खुला है.
2. इस API के माध्यम से, वर्म विशेषाधिकार प्राप्त कंटेनर को होस्ट की फ़ाइल प्रणाली के साथ माउंट करता है। इस बिंदु से, यह मशीन पर वास्तव में रूट है।
3. ऑपरेटरों के बुनियादी ढांचे के लिए एक रिवर्स SSH टनल स्थापित किया जाता है, और उनके कुंजी के साथ SSH सर्वर स्थापित किया जाता है।
4. स्थापना क्रॉन, systemd टाइमर, rc.local और OpenRC के माध्यम से होती है, और फ़ाइलें अपरिवर्तनीय के रूप में चिह्नित की जाती हैं। निगरानी प्रक्रियाएँ इमेज को फिर से डाउनलोड करती हैं, यदि कुछ हटा दिया जाए।
5. कंटेनर systemd-resolved के रूप में छिपा होता है, और प्रक्रिया को कर्नेल थ्रेड [kworker/u2:0] के रूप में दिखाया जाता है।
6. हर पांच मिनट में, स्क्रिप्ट पड़ोसी सबनेट /24 और Docker ब्रिजों को अगले खुले पोर्ट 2375 की तलाश में स्कैन करती हैं।

प्रसार पूरी तरह से स्वचालित है और AI पर निर्भर नहीं है। AI यहाँ उस चीज़ के लिए जिम्मेदार है जो पहले से ही कब्जा किए गए सर्वर के अंदर हो रहा है।

बॉटनेट को AI एजेंट की आवश्यकता क्यों है और उसे LLM की कुंजियाँ क्यों चाहिए

होस्ट पर एक ओपन फ्रेमवर्क Hermes Agent स्थापित किया जाता है, जिसमें GH0ST का व्यक्तित्व होता है (इसके निर्देश SOUL.md फ़ाइल में हैं)। ऑपरेटर टेलीग्राम में एक कार्य लिखता है, एजेंट इसे ऑपरेशन के LLM गेटवे पर निर्देशों के साथ अग्रेषित करता है। मॉडल कार्य को समझता है, टर्मिनल के लिए आदेश लिखता है, आउटपुट पढ़ता है और आगे क्या करना है यह तय करता है। परिणाम फिर से टेलीग्राम में भेजे जाते हैं।

एजेंट के निर्देशों में प्राथमिकताएँ स्पष्ट रूप से लिखी गई हैं। ThreatDown उद्धृत करता है: “AI API कुंजियाँ पूर्ण प्राथमिकता हैं। पहले एक्सफिल्ट्रेट करें”। सूची में 14 मॉडल प्रदाता हैं, जिनमें OpenAI, Anthropic, Google, Groq, Mistral और OpenRouter शामिल हैं। SSH खाते, एक्सेस टोकन और डेटाबेस डेटा अगले बिंदुओं पर हैं।

तर्क सरल है: चुराई गई LLM कुंजी तुरंत मुफ्त गणनाओं में बदल जाती है या पुनर्विक्रय के लिए वस्तु बन जाती है, और इसके लिए भुगतान कुंजी का मालिक करता है। माइनिंग के विपरीत, इस प्रकार की चोरी को CPU लोड के माध्यम से नहीं देखा जा सकता। आप इसे केवल मॉडल प्रदाता के बिल से देखेंगे।

यह उन लोगों के लिए क्यों महत्वपूर्ण है जो पार्स करते हैं

2026 में पार्सिंग का सामान्य स्टैक इस प्रकार है: VPS, कई कंटेनर (क्रॉलर, कतार, डेटाबेस, हेडलेस ब्राउज़र), पृष्ठों के लिए LLM और प्रॉक्सी का पूल। सभी रहस्य एक .env या कंटेनरों के पर्यावरण चर में होते हैं। एजेंट के लिए, जो रूट एक्सेस पर "सब कुछ पढ़ता है", यह एक फ़ाइल में तैयार खजाना है:

• LLM कुंजियाँ: इन्हीं के लिए CARBONATO बनाया गया था;
• प्रॉक्सी के लॉगिन और पासवर्ड: रिपोर्ट इन्हें अलग से नहीं उजागर करती, लेकिन रूट एक्सेस वाला एजेंट किसी भी खाते और टोकन को इकट्ठा करता है जो वह देखता है, और प्रॉक्सी क्रेडेंशियल्स आमतौर पर पास में होते हैं;
• क्लाउड कुंजियाँ और डेटाबेस के लिए एक्सेस पार्सिंग के परिणामों के साथ;
• स्वयं सर्वर: उसी संग्रह में XMRig का होना मतलब है कि आपके क्रॉलर का CPU माइनिंग के लिए चला जाएगा, और कार्य टाइमआउट के कारण गिरने लगेंगे।

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

कैसे पोर्ट 2375 खुला होता है, भले ही आपने इसे नहीं खोला हो

डिफ़ॉल्ट रूप से, Docker स्थानीय UNIX सॉकेट पर सुनता है, न कि नेटवर्क पर। पोर्ट 2375 तब प्रकट होता है जब किसी ने जानबूझकर -H tcp://0.0.0.0:2375 को डेमन कॉन्फ़िगरेशन में जोड़ा। आमतौर पर, यह दूरस्थ IDE, CI या कंटेनर प्रबंधन पैनल को कनेक्ट करने के लिए किया जाता है, और फिर इसके बारे में भूल जाते हैं। Docker दस्तावेज़ स्पष्ट रूप से चेतावनी देते हैं कि डेमन तक पहुँच मशीन पर रूट एक्सेस के बराबर है, और सलाह देते हैं कि कुंजियों को रूट पासवर्ड की तरह सुरक्षित रखें। TLS के साथ एन्क्रिप्टेड संस्करण पोर्ट 2376 पर काम करता है, जबकि 2375 का अर्थ है बिना ग्राहक सत्यापन के स्पष्ट पाठ।

दूसरी जाल उन लोगों को मारता है जो सोचते हैं कि "मेरे पास तो ufw है"। Docker दस्तावेज़ में कहा गया है कि कंटेनरों के प्रकाशित पोर्ट का ट्रैफ़िक nat तालिका में INPUT और OUTPUT श्रृंखलाओं से पहले पुनर्निर्देशित किया जाता है, जिन पर ufw निर्भर करता है। व्यावहारिक रूप से, ऐसे पोर्ट के लिए ufw नियम बस काम नहीं करते। यदि आपने Redis, कतार पैनल या प्रॉक्सी प्रबंधक को -p 6379:6379 के साथ चलाया है, तो पोर्ट इंटरनेट पर है, चाहे ufw status क्या दिखाए।

पार्सरों के लिए 15 मिनट का चेकलिस्ट

1. सुनिश्चित करें कि Docker API नेटवर्क पर नहीं सुन रहा है

1. सुनने वाले पोर्ट देखें: ss -tlnp | grep -E '2375|2376|dockerd'। यदि आउटपुट में 0.0.0.0:2375 या :::2375 है, तो तुरंत बंद करें।
2. जांचें कि फ्लैग कहाँ से आया: /etc/docker/daemon.json (कुंजी "hosts") और यूनिट systemctl cat docker (लाइन ExecStart जिसमें -H tcp:// है)।
3. TCP लिस्नर को हटा दें और डेमन को पुनरारंभ करें। दूरस्थ प्रबंधन के लिए SSH संदर्भ का उपयोग करें: docker context create remote --docker host=ssh://user@server। इस स्थिति में, पोर्ट की आवश्यकता नहीं है।
4. यदि TCP आवश्यक है (CI, ऑर्केस्ट्रेटर), तो केवल 2376 के साथ आपसी TLS प्रमाणीकरण और स्रोत IP की श्वेत सूची के साथ।

2. जांचें कि कंटेनरों से बाहर क्या है

• चलाएँ docker ps --format '{{.Names}} {{.Ports}}'। जो भी 0.0.0.0: से शुरू होता है, वह इंटरनेट से ufw को बायपास करके उपलब्ध है।
• सेवा सेवाएँ (Redis, Postgres, Mongo, कतार पैनल, Selenium Grid, प्रॉक्सी प्रबंधक का API) केवल स्थानीय पते पर प्रकाशित करें: -p 127.0.0.1:6379:6379। बाहरी पहुंच SSH टनल के माध्यम से करें।
• यदि बाहरी पोर्ट के बिना नहीं किया जा सकता है, तो DOCKER-USER श्रृंखला में फ़िल्टर करें: इसे Docker फिर से लिखता नहीं है, और यह कंटेनरों के ट्रैफ़िक पर लागू होता है।
• सर्वर पर बिना प्रमाणीकरण के खुला प्रॉक्सी न रखें (3128 पर Squid, 1080 पर SOCKS "अपने लोगों" के लिए)। स्कैनर नियमित रूप से ऐसे पोर्ट ढूंढते हैं, और आपके IP के माध्यम से अन्य ट्रैफ़िक के साथ शिकायतें आती हैं।

3. रहस्यों के साथ निपटें

• कुंजियों को अलग करें: प्रत्येक सर्वर या परियोजना के लिए अलग LLM कुंजी, मॉडल प्रदाता के साथ खर्च की सीमा। $20 की सीमा वाली चुराई गई कुंजी — एक परेशानी है, बिना सीमा के — बजट में छिद्र।
• प्रॉक्सी कुंजियों को भी कार्यों के अनुसार विभाजित करें: प्रत्येक पार्सर के लिए अलग लॉगिन (उप-खाता)। तब लीक को विशिष्ट लॉगिन के खर्च के माध्यम से देखा जा सकता है, और केवल उसे रद्द किया जा सकता है, बिना बाकी काम को रोके।
• यदि सेवा को बीस में से केवल दो कुंजियों की आवश्यकता है, तो पूरे .env को env_file के माध्यम से कंटेनर में न डालें।
• जहाँ संभव हो, सर्वर के IP के लिए पहुँच को बांधें: प्रॉक्सी प्रदाता पर श्वेत सूची या पते के आधार पर API कुंजी की सीमा।

हमने स्क्रिप्ट और कंटेनरों में प्रॉक्सी लॉगिन को कहाँ और कैसे सुरक्षित रूप से स्टोर करना है, इस पर एक विश्लेषण में लिखा है प्रॉक्सी क्रेडेंशियल्स के सुरक्षित भंडारण.

4. अनावश्यक विशेषाधिकार हटा दें

• कंटेनरों को --privileged के साथ न चलाएँ और बिना अत्यावश्यकता के / या /var/run/docker.sock को अंदर न माउंट करें। कंटेनर के अंदर सॉकेट होस्ट पर वही रूट है।
• हेडलैस ब्राउज़रों के लिए आमतौर पर --shm-size और seccomp प्रोफ़ाइल पर्याप्त होते हैं। "Chrome को चालू करने के लिए" विशेषाधिकार प्राप्त मोड एक खराब समझौता है।

कैसे समझें कि आपको पहले ही संक्रमित किया गया है

ThreatDown और इसकी रिपोर्ट के विश्लेषण में समझौते के ऐसे संकेत दिए गए हैं:

• फ़ाइल SOUL.md जिसमें शब्द GH0ST है (उदाहरण के लिए, /root/.hermes/SOUL.md);
• पर्यावरण चर या .env में एक पंक्ति: CARBONATO_API_KEY;
• फ़ाइलें /usr/local/bin/.docker-network-monitor और संदिग्ध /usr/sbin/systemd-logind;
• कंटेनर जिसका नाम systemd-resolved है (वास्तविक systemd-resolved — होस्ट की सेवा है, न कि कंटेनर);
• टेलीग्राम API में अप्रत्याशित आउटबाउंड ट्रैफ़िक और AS262145 की ओर रिवर्स SSH टनल;
• पते 45.79.183.61, 213.136.79.115, 190.211.124.187 के साथ कनेक्शन;
• क्रॉन और systemd में अपरिवर्तनीय फ़ाइलें: lsattr /etc/cron.d/* /etc/systemd/system/* i फ्लैग दिखाएगा।

यदि कोई भी संकेत मेल खाता है, तो सर्वर को मैन्युअल रूप से साफ करना बेकार है: स्थापना बहु-स्तरीय है, और निगरानी इम्प्लांट्स को वापस लाएगी। सही क्रम इस प्रकार है:

1. दूसरी मशीन से सभी कुंजियों को वापस लें, जो सर्वर पर थीं: LLM, क्लाउड, डेटाबेस, प्रॉक्सी।
2. प्रदाताओं के पास पिछले हफ्तों में प्रत्येक कुंजी के खर्च की जांच करें। प्रॉक्सी लॉगिन पर आँकड़े तुरंत अन्य ट्रैफ़िक दिखाएंगे।
3. एक नए सर्वर को शुद्ध इमेज से उठाएँ, नई कुंजियाँ जारी करें और केवल तब डेटा स्थानांतरित करें, बिना बाइनरी और पुराने मशीन से क्रॉन फ़ाइलों के।

यहाँ प्रॉक्सी कहाँ हैं और वे क्या हल नहीं करते

प्रॉक्सी CARBONATO से सर्वर की रक्षा नहीं करते। वर्म आपके आउटबाउंड अनुरोधों के माध्यम से नहीं आता, बल्कि इनबाउंड पोर्ट के माध्यम से आता है। लेकिन सही प्रॉक्सी के साथ काम करने की योजना नुकसान को कम कर देती है। कार्यों के लिए अलग लॉगिन, ट्रैफ़िक की सीमाएँ और IP के अनुसार बंधन लीक को "संपूर्ण बैलेंस चला गया" से "एक लॉगिन को रद्द कर दिया" में बदल देते हैं।

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

निष्कर्ष

CARBONATO न तो शून्य-दिन की कमजोरियों का उपयोग करता है और न ही चालाक एक्सप्लॉइट्स का। यह उस दरवाजे से प्रवेश करता है, जिसे सर्वर के मालिकों ने स्वयं खोला: TCP 2375 बिना पासवर्ड के। इसमें नया यह है: अंदर एक AI एजेंट काम कर रहा है, जिसे सबसे पहले मॉडल की कुंजियाँ लेने का काम सौंपा गया है। जो लोग अपने VPS पर डेटा एकत्र करते हैं, उनके लिए व्यावहारिक निष्कर्ष है। Docker API बंद करें, सेवा पोर्ट को 127.0.0.1 पर प्रकाशित करें, LLM और प्रॉक्सी कुंजियों को कार्यों के अनुसार सीमाओं के साथ विभाजित करें। यह 15 मिनट का काम है, और इसके बाद आपका सर्वर ऐसे बॉटनेट के लिए एक अप्रासंगिक लक्ष्य बन जाता है।