بناء Moonbunny: إطار عمل للقيادة والتحكم (C2) بمساعدة الذكاء الاصطناعي وبنية انعدام الثقة (Zero-Trust) بلغة Go
→ العودة إلى المدونة
بناء Moonbunny: إطار عمل للقيادة والتحكم (C2) بمساعدة الذكاء الاصطناعي وبنية انعدام الثقة (Zero-Trust) بلغة Go

بناء Moonbunny: إطار عمل للقيادة والتحكم (C2) بمساعدة الذكاء الاصطناعي وبنية انعدام الثقة (Zero-Trust) بلغة Go

الوسوم:

في مجال محاكاة التهديدات الحديثة (Adversary Simulation)، غالباً ما تُسد الفجوة بين الاختراق الأولي (Initial Access) وعمليات ما بعد الاستغلال (Post-Exploitation) عبر أطر عمل قيادة وتحكم (C2) ضخمة يسهل تتبع بصمتها، أو نصوص برمجية (Scripts) مخصصة وهشة تفشل تحت الضغط. أردت بناء شيء أكثر تخفياً وصلابة: إطار عمل C2 خفيف الوزن، مصمم ليكون آمناً بشكل افتراضي (Secure-by-default)، يوفر لمشغلي الفرق الحمراء (Red Teams) واجهة نظيفة، ويتحدث في الوقت ذاته بلغة النماذج اللغوية للذكاء الاصطناعي لتنفيذ عمليات مستقلة.

من هنا جاء Moonbunny، وهو إطار عمل تجريبي لمحاكاة التهديدات والتنفيذ الموزع أقوم حالياً ببنائه باستخدام لغة Go. ورغم كونه في مرحلة إثبات المفهوم (Proof-of-Concept) حصراً في هذه المرحلة، إلا أنه يجمع بين الأداء السريع لبروتوكول gRPC، والمرونة في عمليات ما بعد الاستغلال التي توفرها نصوص Lua المدمجة، وبروتوكول سياق النموذج (MCP) للتنسيق القائم على الذكاء الاصطناعي، كل ذلك مغلف ببنية تعتمد على انعدام الثقة (Zero-Trust) وتراعي أمن العمليات (OpSec).

Figure 1: هندسة Moonbunny — ثنائي Go واحد. أدوات المشغل (TUI, AI/MCP) تتصل بخادم Moonbunny الذي يستضيف نقاط نهاية gRPC وMCP مدعومة بمحركات Lua مستقلة (تتشارك في pkg/lua)، ويفرضها محرك السياسات. العملاء المتصلون (جلسات التنفيذ الخاصة بالخادم) يتفاعلون عبر هذه الواجهات. ملاحظة: إعداد المحركين هو حل مؤقت؛ المعمارية المخطط لها (proto/lua/lua.proto) تعرّف LuaVMMService مع إدارة مجموعة VM (ResizePool, CleanupIdleVMs) للتنفيذ المتوازي.

إليكم جولة تفصيلية، طبقة بطبقة، حول كيفية تصميم Moonbunny ليتناسب مع عمليات الفرق الحمراء الحديثة، والقرارات المعمارية التي تقف وراءه.

العمود الفقري لإطار C2: لماذا gRPC و Go؟

يعتمد Moonbunny في جوهره على بنية خادم-عميل (Client-Server) محددة بصرامة وعالية الأداء، مبنية باستخدام لغة Go وبروتوكول gRPC. كان قرار استخدام gRPC بدلاً من HTTP REST التقليدي أو مقابس TCP (TCP Sockets) المخصصة مدفوعاً باعتبارات الأداء وأمن العمليات على حد سواء.

Figure 2: تدفق اتصال gRPC/mTLS — مصافحة TLS المتبادلة تؤسس الهوية التشفيرية قبل تدفق أي بيانات C2. الأوامر تصل عبر تدفق، تمر عبر فرض السياسة (عدادا SP2/SP3)، وتنفذ داخل محرك Lua المضمن في الخادم. البث ثنائي الاتجاه يتيح إرسال أوامر بزمن وصول منخفض وبيانات فورية.

  • البث ثنائي الاتجاه والعبء المنخفض (Bidirectional Streaming & Low Overhead): تتيح تقنية تعدد الإرسال (Multiplexing) في HTTP/2 بثاً مستمراً وعالي الكفاءة للأوامر والبيانات دون العبء المزعج المرتبط بطلبات HTTP المتكررة (HTTP Polling).
  • عازلة البروتوكولات (Protocol Buffers): تم تعريف واجهة برمجة التطبيقات (API) الخاصة بـ C2 بالكامل في proto/moonbunny.proto و proto/lua/lua.proto، مما يولد روابط Go متينة (moonbunny.pb.go). يعرّف proto/moonbunny.proto خدمات gRPC الخمس المنفذة بالكامل، بينما يعرّف proto/lua/lua.proto أربع خدمات مؤجلة (VM pool, function registry, sandbox, debug, event — مخططات أولية فقط، بدون تنفيذ Go). يعرّف proto/lua/lua.proto أيضاً LuaVMMService مع إدارة مجموعة VM (ResizePool, CleanupIdleVMs) للتنفيذ المتوازي في المعمارية المخطط لها. هذا النمط الصارم (Strict Typing) يقضي على فئات كاملة من الثغرات الأمنية على مستوى المحلل النحوي (Parser-level Vulnerabilities) والتي غالباً ما توجد في بروتوكولات C2 المصممة خصيصاً.
  • ثنائي واحد (Single Binary): Moonbunny هو ثنائي Go واحد يضم خادم gRPC وخادم MCP ومحرك Lua ومحرك السياسات وكل معالجة الإعدادات. واجهة سطر أوامر xiaotu هي أداة إعدادات مصاحبة — وليست مكوّناً منشوراً.
  • الموثوقية من البداية للنهاية (E2E Reliability): يجب أن تكون أدوات الفريق الأحمر مستقرة؛ انهيار الخادم يُعطّل جميع العمليات. يتضمن الإطار بيئة اختبار شاملة (Test Harness) من البداية للنهاية (test/e2e/harness_test.go) تغطي النشر وgRPC وmTLS ووصول Lua وبيانات MCP.

Figure 3: تعريفات البروتوكول والكود المولّد — proto/moonbunny.proto يعرّف 5 خدمات gRPC منفذة بالكامل؛ proto/lua/lua.proto يعرّف 4 خدمات مؤجلة (VM pool, function registry, sandbox, debug, event — مخططات أولية فقط، بدون تنفيذ Go). روابط Go المولّدة (moonbunny.pb.go, moonbunny_grpc.pb.go) تخدم خادم الثنائي الواحد.

أمن العمليات (OpSec) أولاً: لماذا mTLS والسياسات التشفيرية؟

لا تقاس قوة إطار عمل C2 إلا بقدرته على التخفي في وضح النهار ومقاومة تحليل الفريق الأزرق (Blue Team). تم وضع نموذج التهديد (Threat Model) لـ Moonbunny ليعمل في بيئات معادية وخاضعة للمراقبة المكثفة.

Figure 4: فرض mTLS والسياسات — مرجع مصدق خاص يصدر شهادات للطرفين. التحقق المتبادل يحدث قبل تدفق أي بيانات تطبيقية. محرك السياسات يفرض عدادات SP2/SP3 لكل تنفيذ (عمليات الملفات، اتصالات الشبكة، انتهاء المهلة) وحراسات نظام الملفات/الشبكة؛ السياسة الافتراضية متسامحة، والقيود تُطبّق فقط عند الضبط الصريح.

  • فرض mTLS إجبارياً: لم يعد الاعتماد على بروتوكول TLS القياسي كافياً للتهرب من الفحص العميق للحزم (Deep Packet Inspection) أو الفحص النشط. يفرض Moonbunny استخدام TLS المتبادل (mTLS). يضمن ذلك ليس فقط تشفير حركة المرور، مما يجعلها تمتزج مع حركة مرور الخدمات المصغرة (Microservices) القياسية في المؤسسات، بل يتيح لخادم الفريق (Team Server) التحقق من الهوية التشفيرية لكل عميل متصل. هذا يحيد الجلسات الطرفية المارقة ويمنع الفرق الزرقاء من استجواب البنية التحتية لـ C2 (pkg/grpc/mtls_handshake_test.go).
  • محرك سياسات صارم: يطبق Moonbunny محرك سياسات قوي يعمل في وقت التشغيل (pkg/policy/policy.go) مع حدود تنفيذ محددة عبر pkg/grpc/server_exec_policy.go. يفرض محرك السياسات عدادات SP2/SP3 — عمليات الملفات المحدودة، حدود اتصالات الشبكة، وانتهاء مهلة التنفيذ — بالإضافة إلى قوائم السماح لنظام الملفات وحجب الشبكة. التغييرات على السياسات مؤقتة فقط (تراكب في الذاكرة)، ولا يمكن لجلسة عميل مخترقة إدخال أوامر بشكل تعسفي أو تجاوز حدود التنفيذ المُعدّة لها.

Figure 5: حدود التنفيذ تحبط سوء الاستخدام — عميل مخترق لا يستطيع تجاوز عدادات SP2/SP3 لكل تنفيذ. حدود عمليات الملفات واتصالات الشبكة تُفرض على مستوى استدعاء Lua؛ تجاوزها يمنع العملية، ويسجّل الانتهاك في سجل التدقيق، ويُظهر تنبيهاً للمشغل.

قابلية البرمجة لما بعد الاستغلال عبر Lua المدمج

بدلاً من دمج كل وحدة ممكنة لما بعد الاستغلال (Post-Exploitation Module) داخل ثنائي Go (مما يزيد من التوقيع وحجم الملف بشكل كبير)، يوفر Moonbunny بيئة تشغيل Lua مدمجة (pkg/lua/engine.go).

Figure 6: دورة حياة نص Lua — النصوص تُدفع في الذاكرة فقط (لا كتابات على القرص)، تُتحقق منها بالسياسة، ثم تُنفّذ داخل محرك Lua المضمن في الخادم. الإنفاذ لكل تنفيذ (pkg/lua/enforce.go) يطبق عدادات الموارد (عمليات الملفات، اتصالات الشبكة) وقيود الصندوق الرملي على مستوى استدعاء VM. وضع الصندوق الرملي (حذف المتغيرات الخطيرة مثل os وdebug وpackage وrequire) اختياري عبر علم السياسة enable_sandbox — السياسة الافتراضية تمنح صلاحية الوصول الكاملة للنظام.

يخلق هذا نظاماً بيئياً للملحقات (Plugins) شديد التخفي. يمكن للمشغلين دفع نصوص برمجية خفيفة ديناميكياً لتعمل بالكامل في الذاكرة (In-memory) لجمع البيانات، أو إنشاء ثبات (Persistence)، أو إجراء وعي ظرفي (Situational Awareness)، ويقوم محرك Go بفرض حدود موارد التنفيذ (عمليات الملفات المحدودة، عدادات اتصالات الشبكة، وانتهاء المهلة) عبر pkg/lua/enforce.go. وضع الصندوق الرملي (Sandbox mode) — الذي يحد من الوصول على مستوى نظام التشغيل — متاح عند تفعيله صراحةً عبر علم enable_sandbox في السياسة (pkg/lua/enforce.go)؛ السياسات الافتراضية تمنح صلاحية الوصول الكاملة للنظام.

يُشحن المشروع مع مكتبة أولية من النصوص البرمجية لعمليات الاستطلاع والجرد في العالم الحقيقي:

Figure 7: فئات نصوص Lua المدمجة — نصوص نمطية في الذاكرة تغطي استطلاع المضيف، اكتشاف الحاويات، وتعداد الشبكة. كل نص يعمل في آلة Lua معزولة مع مخرجات منظمة.

الفرق الحمراء المستقلة: لماذا بروتوكول سياق النموذج (MCP)?

هنا يتوقف Moonbunny عن كونه مجرد C2 آخر ويصبح منصة محاكاة تهديدات تطلعية للمستقبل. يتزايد استخدام وكلاء الذكاء الاصطناعي (AI Agents) لتحليل بيئات Active Directory المعقدة أو اقتراح مسارات لتصعيد الامتيازات (Privilege Escalation).

ومع ذلك، فإن منح نموذج لغوي كبير (LLM) وصولاً مباشراً (Raw Shell Access) إلى بيئة تنفيذ يعد مخاطرة تشغيلية كارثية. قرار استخدام بروتوكول سياق النموذج (Model Context Protocol - MCP) يحل هذه المشكلة.

Figure 8: تكامل MCP — يتفاعل وكلاء الذكاء الاصطناعي مع Moonbunny حصرياً عبر أدوات MCP المسجلة. كل استدعاء أداة يمر عبر محرك السياسات، مما يضمن عدم قدرة LLM على تجاوز الحواجز المعرفة من المشغل. LLM يرى بيانات منظمة فقط، لا وصول صدفة خام.

ينفذ Moonbunny واجهة خادم MCP (pkg/mcp/server.go)، الموثقة في docs/guides/mcp-interface.md. يوفر MCP بروتوكولاً قياسياً ومقيداً بشدة حيث لا يمكن للذكاء الاصطناعي استدعاء سوى الأدوات والاستعلامات المسجلة صراحةً. يطلب النموذج اللغوي الكبير بيانات الهدف عبر شبكة Moonbunny بشكل أصلي وآمن، ولكنه يرى وينفذ فقط ما يسمح به محرك Lua ومحرك السياسات صراحةً. هذا يدمج الحركة الجانبية (Lateral Movement) الآلية والذكية مع حواجز حماية برمجية صارمة للمشغل.

Figure 9: تعداد AD ذاتي عبر MCP — الذكاء الاصطناعي ينسق استطلاعاً متعدد العملاء: يكتشف العملاء المتصلين، يختار هدفاً، ينفذ نص Lua متوافق مع السياسة (تعداد بنمط BloodHound)، يستقبل بيانات رسم منظمة، ويعرض مسار الهجوم — كل ذلك دون وصول صدفة خام.

التطور إلى ما بعد مشهد C2 التقليدي

عند تقييم الأطر الهجومية الحديثة، ينحت Moonbunny لنفسه مكانة مميزة. تقدم الشركات التقليدية العملاقة مثل Cobalt Strike ميزات تجارية لا مثيل لها، ولكنها تحمل رسوم ترخيص باهظة وتوقيعات (Signatures) تخضع لفحص دقيق. البدائل مفتوحة المصدر الشائعة مثل Sliver (مكتوب أيضاً بلغة Go) أو Covenant (.NET) قوية للغاية، إلا أنها تركز بشكل كبير على تصميمات الوكلاء المتجانسة التقليدية (Monolithic Implant Designs) والمهام اليدوية التي يوجهها المشغل. وبالمثل، تتفوق المنصات المعيارية مثل Mythic في العمليات التعاونية متعددة الوكلاء ولكنها تتطلب إعدادات معقدة.

يختلف Moonbunny من خلال إعطاء الأولوية لبصمة خفيفة للغاية، وبشكل حاسم، إمكانية التشغيل البيني للذكاء الاصطناعي (AI Interoperability) المستقل عبر بروتوكول سياق النموذج (MCP). من خلال الجمع بين سياسة تنفيذ تشفيرية تم التحقق منها بصرامة مع بيئة تشغيل Lua مدمجة، فإنه يوفر التخفي والرشاقة لمشاريع مثل Havoc أو SILENTTRINITY، ولكنه يضع نفسه بشكل فريد لمستقبل محاكاة التهديدات بمساعدة النماذج اللغوية الكبيرة (LLMs).

وحدة تحكم المشغل: واجهة مستخدم طرفية (TUI) عبر Bubble Tea

أخيراً، ولأن أي عملية لا تكون فعالة إلا بفعالية واجهتها (ولأني أحب بناء واجهات مستخدم طرفية، كما رأينا في مشروع Gocaster الخاص بي)، يتضمن Moonbunny تطبيق واجهة مستخدم طرفية (TUI) ثري (cmd/tui/main.go).

Figure 10: هندسة TUI (بنية نظيفة) — TUI من Bubble Tea هو عميل gRPC منفصل. العروض (لوحة التحكم، النصوص، التنفيذ، السياسات) تتواصل مع قلب خادم الفريق فقط عبر واجهة gRPC API. لا وصول مباشر للحزم الداخلية.

  • يوفر “لوحة تحكم للمخترق” (Hacker Dashboard) ملموسة تعتمد على لوحة المفاتيح لإدارة جلسات العملاء النشطين، ومراجعة حالات سياسات التنفيذ، وإطلاق حمولات Lua عن بُعد (cmd/tui/scripts.go، cmd/tui/execution.go).
  • من خلال الالتزام بمبادئ البنية النظيفة (Clean Architecture)، يتم فصل واجهة TUI تماماً عن المنطق الأساسي لخادم الفريق، حيث تعمل ببساطة كعميل gRPC آخر مصادق عليه يستهلك واجهة برمجة التطبيقات الأساسية.

Figure 11: مشهد أطر عمل C2 — Moonbunny يستهدف الربع عالي OpSec والذاتي بالذكاء الاصطناعي (الأعلى يمين). الأطر التقليدية تتجمع في مناطق العمليات اليدوية متوسطة OpSec. Moonbunny يعطي الأولوية لفرض تنفيذ وقت التشغيل، والبصمة الدنيا، والتشغيل البيني الأصلي للذكاء الاصطناعي عبر MCP.

الحالة الحالية: إثبات المفهوم (Proof of Concept)

في حين أن Moonbunny يثبت نجاحه في دمج هندسة الأمن الهجومي (Offensive Security Engineering)، والأنظمة الموزعة، وتكامل الذكاء الاصطناعي، فمن المهم التأكيد على أن هذا المشروع هو قيد التطوير النشط. إنه حالياً في مرحلة إثبات المفهوم وليس جاهزاً بعد للاستخدام التجاري أو النشر في بيئات الإنتاج أو العمليات الحية (Live Engagements).

من خلال الجمع بين التزامن (Concurrency) ونظام gRPC البيئي في Go، مع التنفيذ الديناميكي في الذاكرة الخاص بـ Lua وقدرة MCP على التكامل مع الذكاء الاصطناعي، فإنه يمثل رؤيتي للجيل القادم من أدوات محاكاة التهديدات. سأقضي الأشهر القادمة في تطوير استقراره الأساسي، وتوسيع قدرات مكتبة Lua القياسية، وتقوية محرك السياسات.