بنية الذكاء الاصطناعي تتحول إلى نقطة تحكم عالية القيمة للهجمات

تقدم Microsoft Threat Intelligence قراءة واسعة لهجمات استهدفت ثلاث بيئات مرتبطة بتشغيل الذكاء الاصطناعي: بوابة LiteLLM، ومنصة RAGFlow لمعالجة المستندات والاسترجاع المعزز بالتوليد، وبيئة Kestra لتنسيق سير العمل. ورغم اختلاف مسارات الاختراق، تكررت الأهداف نفسها تقريباً: سرقة مفاتيح الاعتماد، تثبيت آليات وصول مستمر، والوصول إلى موارد الحوسبة لاستخدامها في تعدين العملات المشفرة.

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

ثلاثة مسارات اختراق، ونمط واحد للنتائج

في حالة LiteLLM، ترجح Microsoft بدرجة ثقة عالية أن الوصول الأولي تم عبر استغلال واجهة مكشوفة للبوابة. وتشير المادة إلى مسارات ثغرات عامة، بينها CVE-2026-42271، المرتبطة بتنفيذ أوامر مصادق عليه في نقاط اختبار LiteLLM MCP stdio، ومسار بحثي يربطها بـ CVE-2026-48710، وهي ثغرة لتجاوز التحقق من ترويسة المضيف في Starlette. وقد يؤدي هذا الربط، في إعدادات متأثرة، إلى جعل تنفيذ الأوامر عن بُعد متاحاً من دون بيانات اعتماد صحيحة.

بعد الاختراق، قرأ الحمْل البرمجي بيئة العملية الرئيسية داخل الحاوية، بما في ذلك /proc/1/environ، بحثاً عن مفاتيح مزودي النماذج ومفتاح LiteLLM الرئيسي وسلاسل اتصال قواعد البيانات وكلمات المرور والرموز. ثم جرى تنزيل ملفات تنفيذية متنكرة في صورة خدمات Linux، وفحص المضيف والمنافذ والعمليات، وتجهيز تعدين يعتمد على XMRig أو RandomX. كما استُخدمت سلسلة اتصال PostgreSQL للوصول إلى جداول LiteLLM التي قد تحتوي على إعدادات النماذج ومفاتيح المزودين والمفاتيح الافتراضية الصادرة عن الوكيل. وشملت آليات الاستمرارية تعديل ملف authorized_keys لحساب خدمة، وتغيير مهام cron، واستخدام ملفات مخفية وأسماء خدمات متنكرة.

أما RAGFlow، فتركز النشاط المرصود على اعتراض بيانات اعتماد نماذج اللغة التي يضيفها المستأجرون أو يعدلونها. رصدت Microsoft أولاً سلوكاً شبيهاً بطلبات SSRF، ثم تنفيذ أوامر داخل سياق خدمة Flask وتعديلاً لمسار بدء تشغيل التطبيق لتحميل خطاف مخفي. كان الخطاف يلتقط نوع المزود واسم النموذج ومادة مفتاح API وبيانات نقطة النهاية ويرسلها إلى الخارج. وتؤكد المادة أن Microsoft لا تحدد بثقة عالية الثغرة التي سببت التنفيذ؛ إذ تذكر CVE-2026-45312 وCVE-2026-28797 وCVE-2026-24770 وCVE-2025-68700 كسياق تقني محتمل، لا كسبب مؤكد لهذه الحالة.

في Kestra، ترجح Microsoft بدرجة ثقة عالية أن الاستغلال ارتبط بالثغرة الحرجة CVE-2026-49869، التي قد تسمح بتجاوز المصادقة، وتعريف سير عمل خبيث يستخدم Process runner، ثم تشغيل أوامر shell على العامل. استُخدم هذا المسار للوصول إلى مقبس Docker، وفحص بيئة الحاويات، ونشر عامل تعدين، وتنفيذ عمليات لإخفاء الملفات. كما استُخدمت مهام سير العمل لاحقاً لجلب نصوص عن بُعد وتنفيذها مباشرة، ثم تخزين المخرجات المشفرة عبر واجهة القيم المفتاحية الخاصة بـ Kestra.

ما الذي يتغير عملياً لفرق الدفاع؟

الاستنتاج الأهم هو أن تقييم المخاطر يجب أن ينطلق من وظيفة بيئة الذكاء الاصطناعي داخل المؤسسة. فالبوابة قد تكون مخزناً لمفاتيح مزودي النماذج وقاعدة بيانات للمفاتيح الافتراضية، بينما قد تحتوي منصة RAG على إعدادات المستأجرين، ويمكن لمحرك سير العمل أن يمتلك صلاحية تنفيذ أوامر والتعامل مع خدمات خارجية. لذلك لا يكفي تطبيق مؤشرات كشف خاصة بكل منتج بمعزل عن غيره.

توصي Microsoft بمعاملة بوابات الذكاء الاصطناعي كمخازن أسرار من المستوى الأعلى، مع تحديث LiteLLM والأدوات المشابهة، وفرض المصادقة على واجهات API وواجهات الإدارة، وتقييد منافذ الإدارة وعدم تعريضها مباشرة للإنترنت. كما توصي باستخدام مفاتيح افتراضية منفصلة لكل فريق مع حدود للإنفاق، وتخزين مفاتيح المزودين في مخزن أسرار مُدار بدلاً من متغيرات بيئة العملية، وتدوير المفاتيح التي ربما انكشفت.

وتشمل الضوابط الأخرى تطبيق أقل قدر من الصلاحيات على البوابة وقاعدة البيانات، وضع قاعدة البيانات خلف نقطة نهاية خاصة وجدار ناري مقيد، وفرض قواعد خروج شبكية ترفض الاتصالات افتراضياً وتسمح فقط بالنقاط المطلوبة. وينبغي مراقبة الوصول إلى /proc/1/environ، وتشغيل shell أو Python أو أدوات التنزيل من عملية بوابة، وتعديل cron أو ملفات SSH، واستخدام مقبس Docker، والتنفيذ من مسارات مؤقتة قابلة للكتابة.

حدود الاستنتاج وأسئلة المراجعة

لا تثبت الحالات الثلاث أن كل نشر لـ LiteLLM أو RAGFlow أو Kestra معرض بالطريقة نفسها، كما أن Microsoft تميز بوضوح بين الثغرات المؤكدة في بعض المسارات والثغرات المحتملة في حالة RAGFlow. كذلك فإن وجود سمات في بعض الحمْلات توحي باستخدام أدوات مساعدة أو توليدية لا يمثل دليلاً على مصدرها أو هوية مطوريها. ومن ثم، ينبغي استخدام هذه النتائج لبناء فرضيات كشف ومراجعة إعدادات، لا لإسناد هجوم إلى جهة محددة.

وتوفر Microsoft استعلامات Advanced hunting لرصد سلاسل السلوك، مثل تشغيل البوابة لمفسرات أو أدوات تنزيل، وقراءة متغيرات بيئة العملية الرئيسية، والوصول إلى جداول LiteLLM، ومحاولات تحميل وحدة MSR مع تفعيل الكتابة، وتعديل مفاتيح SSH أو cron. القيمة العملية لهذه الاستعلامات تظهر عند ربطها في خط زمني واحد؛ فعملية shell منفردة قد تكون إدارية، لكن اقترانها بقراءة الأسرار واتصال خارجي وتنفيذ ملف من مسار مؤقت يرفع مستوى الاشتباه بصورة كبيرة.