CARBONATO: دودة الذكاء الاصطناعي تهاجم خوادم Docker. قائمة مراجعة لمن يحتفظون بالبارسرات على VPS

في 22 سبتمبر 2026، وصف الباحثون في ThreatDown شبكة البوت CARBONATO. تدخل إلى الخوادم عبر واجهة Docker API المفتوحة بدون كلمة مرور، وتقوم بتشغيل وكيل ذكاء اصطناعي على المضيف، وتبحث أولاً عن مفاتيح نماذج اللغة. تأتي مفاتيح SSH ورموز الوصول بعد ذلك. إذا كانت لديك برامج زحف تعمل على VPS في حاويات، وكانت مفاتيح OpenRouter أو OpenAI وبيانات اعتماد الوكيل موجودة في .env، فهذا هو ملف المخاطر الخاص بك. أدناه تحليل لكيفية تنفيذ الهجوم، وقائمة مراجعة لمدة 15 دقيقة تغلق هذا المدخل.

ما تم العثور عليه: 4.3 جيجابايت من الصور ووكيل باسم GH0ST

بدأ كل شيء مع سجل Docker غير المغلق للمشغلين أنفسهم. وفقًا لThreatDown، كان هناك 59 مستودعًا، 234 علامة صورة و4.3 جيجابايت من البيانات. يغطي الأرشيف الفترة من أكتوبر 2024 إلى أغسطس 2026، مما يعني أن شبكة البوت كانت تعمل لمدة عامين تقريبًا قبل أن يتم وصفها. تم العثور على مُعدن XMRig وصور بأسماء مثل fsociety/agent في المستودعات.

تبدو سلسلة العدوى وفقًا للتقرير كما يلي:

1. يبحث الماسح عن المضيفين حيث تكون واجهة Docker API مفتوحة على TCP 2375 بدون مصادقة.
2. عبر هذه الواجهة، يقوم الدودة بتشغيل حاوية ذات امتيازات مع نظام ملفات مضيف مُركب. من هذه النقطة، يكون فعليًا جذرًا على الجهاز.
3. يتم إنشاء نفق SSH عكسي إلى بنية المشغلين، ويتم تثبيت خادم SSH بمفتاحهم.
4. يتم التثبيت عبر cron، مؤقتات systemd، rc.local وOpenRC، حيث يتم وضع علامة على الملفات بأنها غير قابلة للتغيير. تقوم العمليات الحارسة بإعادة تحميل الصور إذا تم حذف أي شيء.
5. تتخفى الحاوية تحت systemd-resolved، بينما تتخفى العملية تحت تدفق نواة [kworker/u2:0].
6. كل خمس دقائق، تقوم السكربتات بمسح الشبكات الفرعية المجاورة /24 وجسور Docker بحثًا عن المنفذ المفتوح التالي 2375.

الانتشار تلقائي بالكامل ولا يعتمد على الذكاء الاصطناعي. الذكاء الاصطناعي هنا مسؤول عن ما يحدث داخل الخادم الذي تم الاستيلاء عليه بالفعل.

لماذا يحتاج البوت إلى وكيل ذكاء اصطناعي ولماذا يحتاج بالضبط إلى مفاتيح LLM

يتم تثبيت إطار العمل المفتوح Hermes Agent مع شخصية GH0ST (تعليماتها موجودة في ملف SOUL.md). يكتب المشغل المهمة في Telegram، ويقوم الوكيل بإعادة توجيهها مع التعليمات إلى بوابة LLM للعملية. تقوم النموذج بتحليل المهمة، وكتابة الأوامر للترمينال، وقراءة المخرجات وتحديد ما يجب القيام به بعد ذلك. تذهب النتائج مرة أخرى إلى Telegram.

في تعليمات الوكيل، تم تحديد الأولويات بشكل مباشر. يقتبس ThreatDown: «مفاتيح واجهة برمجة التطبيقات للذكاء الاصطناعي هي الأولوية المطلقة. يجب استخراجها أولاً». في القائمة، هناك 14 مزودًا للنماذج، بما في ذلك OpenAI وAnthropic وGoogle وGroq وMistral وOpenRouter. تأتي حسابات SSH ورموز الوصول وبيانات القواعد في النقاط التالية.

المنطق بسيط: يتحول مفتاح LLM المسروق على الفور إلى حسابات مجانية أو إلى سلعة لإعادة البيع، ويدفع ثمنها مالك المفتاح. على عكس التعدين، لا يمكن رؤية هذه السرقة من خلال الحمل على المعالج. ستلاحظها فقط من خلال الفاتورة من مزود النموذج.

لماذا يهم هذا أولئك الذين يقومون بالزحف

يبدو أن كومة الزحف النموذجية في عام 2026 هي كما يلي: VPS، عدة حاويات (زاحف، قائمة انتظار، قاعدة بيانات، متصفح بدون واجهة)، LLM لتحليل الصفحات ومجموعة من الوكلاء. جميع الأسرار موجودة في .env واحد أو في متغيرات البيئة للحاويات. بالنسبة للوكيل الذي "يقرأ كل شيء" مع وصول الجذر، هذه هي الفريسة الجاهزة في ملف واحد:

• مفاتيح LLM: من أجلها تم إنشاء CARBONATO؛
• بيانات اعتماد الوكلاء: التقرير لا يميزها بشكل منفصل، ولكن الوكيل مع وصول الجذر يجمع أي حسابات ورموز يراها، وعادة ما تكون بيانات اعتماد الوكيل بالقرب منها؛
• مفاتيح السحابة والوصول إلى القواعد مع نتائج الزحف؛
• الخادم نفسه: XMRig في نفس الأرشيف يعني أن وحدة المعالجة المركزية للزاحف الخاص بك ستذهب إلى التعدين، وستبدأ المهام في الفشل بسبب انتهاء المهلة.

هناك مشكلة منفصلة تتعلق بالسمعة. الخادم الذي يقوم الدودة بمسح الشبكات الفرعية الأخرى منه، سريعًا ما يقع في قوائم الإساءة، ويمكن لمزود الخدمة حظره بناءً على الشكوى. بالنسبة للزحف، هذه ضربة مزدوجة: عنوان 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، واجهة برمجة تطبيقات مدير الوكيل) فقط على العنوان المحلي: -p 127.0.0.1:6379:6379. اجعل الوصول الخارجي عبر نفق SSH.
• إذا لم يكن بالإمكان تجنب المنفذ الخارجي، قم بتصفية في سلسلة DOCKER-USER: لا يقوم Docker بإعادة كتابة هذه السلسلة، وهي التي تنطبق على حركة مرور الحاويات.
• لا تحتفظ بخادم مفتوح للوكيل بدون مصادقة (Squid على 3128، SOCKS على 1080 "لأصدقائه"). تقوم الماسحات بشكل منتظم بالعثور على مثل هذه المنافذ، ومن خلال عنوان 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 هو خدمة المضيف، وليس حاوية);
• حركة مرور غير متوقعة صادرة إلى واجهة برمجة تطبيقات Telegram ونفق SSH عكسي نحو AS262145;
• اتصالات مع العناوين 45.79.183.61، 213.136.79.115، 190.211.124.187;
• ملفات غير قابلة للتغيير في cron وsystemd: lsattr /etc/cron.d/* /etc/systemd/system/* ستظهر العلم i.

إذا تطابقت أي علامة، فإن تنظيف الخادم يدويًا يكون بلا جدوى: التثبيت متعدد الطبقات، وسيرجع الحارس الزرع. الترتيب الصحيح هو:

1. من جهاز آخر، قم بإلغاء جميع المفاتيح التي كانت على الخادم: LLM، السحابة، القواعد، الوكلاء.
2. تحقق من الاستهلاك لكل مفتاح خلال الأسابيع الأخيرة لدى المزودين. ستظهر الإحصائيات الخاصة بتسجيل دخول الوكيل على الفور حركة مرور الآخرين.
3. قم بإنشاء خادم جديد من صورة نظيفة، وأصدر مفاتيح جديدة، ثم انقل البيانات فقط، بدون ثنائيات وملفات cron من الجهاز القديم.

أين الوكلاء هنا وما الذي لا يحلونه

لا تحمي الوكلاء الخادم من CARBONATO. تأتي الدودة ليس من خلال طلباتك الصادرة، ولكن عبر المنفذ الوارد. ولكن، فإن المخطط الصحيح للعمل مع الوكلاء يقلل من الأضرار. تسجيلات دخول منفصلة للمهام، حدود حركة المرور، والربط حسب IP تحول التسرب من "كل الرصيد ذهب" إلى "ألغيت تسجيل دخول واحد".

هناك أيضًا جانب آخر، تظهره الشبكات البوتية بانتظام: الأجهزة التي تم الاستيلاء عليها من قبل الآخرين تصبح بنفسها "وكلاء مقيمين" في شبكات مشبوهة. لذلك، من الأفضل أخذ حركة المرور من مزود ذو مصدر واضح للمجموعة. لمعظم مهام جمع البيانات، ستكون الوكلاء المقيمين مع الدفع حسب الجيجابايت مناسبة، حيث يمكن رؤية الاستهلاك لكل وكيل في المكتب. لمهام الخدمة بدون حماية صارمة ضد الروبوتات، ستكون وكلاء مراكز البيانات الأرخص كافية.

الاستنتاج

لا تستخدم CARBONATO أي ثغرات يوم الصفر أو استغلالات معقدة. يدخل من الباب الذي فتحه مالكو الخوادم بأنفسهم: TCP 2375 بدون كلمة مرور. الجديد فيه هو: يعمل داخل وكيل ذكاء اصطناعي، تم تكليفه أولاً بأخذ المفاتيح إلى النماذج. بالنسبة لأولئك الذين يجمعون البيانات على VPS الخاصة بهم، فإن الاستنتاج عملي. أغلق واجهة Docker API، انشر المنافذ الخدمية على 127.0.0.1، وزع مفاتيح LLM والوكلاء حسب المهام مع حدود النفقات. هذه 15 دقيقة من العمل، وبعدها يصبح خادمك هدفًا غير مثير للاهتمام لمثل هذه الشبكات البوتية.