Meteor

أداة C2/teamserver متعددة المنصات تدعم بروتوكولات نقل متعددة، مكتوبة بلغة Go.

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

عام

ينقسم نظام Meteor إلى عدة أجزاء:

• Core: العنصر الرئيسي "لخادم الفريق" الذي سيتتبع الإجراءات والمضيفات والمجموعات، إلخ. يشغّل Core واجهة برمجة تطبيقات داخلية "ليست" متاحة إلا من خلال المستمعين والحاويات الأخرى على شبكة Meteornet (شبكة docker).
• Database - قاعدة بيانات Postgres، تحتوي على علاقات ent التي يستخدمها Core
• Client - كيف يتفاعل المستخدم مع Core. العميل الحالي هو Daddy Tops، ولكن يمكن تطوير خيارات مخصصة بسهولة تامة
• Agents - الزرعات الفعلية التي سيتم تشغيلها على المضيفات المخترقة. يتولى الوكلاء مسؤولية التواصل مع المستمع الخاص بهم، وسحب/تنفيذ الإجراءات، وإرجاع نتائجها
• Listeners - الوسيط بين الخارج و Core. سيكون لكل بروتوكول اتصال مستمع خاص به (مثل واحد للويب، وواحد لـ ICMP، إلخ). سيعالج المستمعون عمليات تسجيل وصول الوكلاء، ثم يعيدون الإجراءات المعلقة، وفي النهاية يعيدون النتائج إلى Core. يعيش Daddy Tops و Nest في الدليل مع بقية المستمعين لأنهما حاويتان مستضافتان تستمعان على الشبكة، لكن الغرض منهما يختلف قليلاً عن المستمعين المستخدمين للتواصل مع الوكلاء

التثبيت والاستخدام

استنسخ المستودع وقم ببناء صور compose المطلوبة:

$ git clone https://github.com/degenerat3/meteor
$ cd meteor
$ docker-compose build
<wait patiently as Golang and docker stuff happens>
$ docker-compose up

أصبح Meteor قيد التشغيل الآن! لاحظ أنه يمكنك إزالة الحاويات من ملف compose إذا كنت لن تستخدمها، لذا إذا كنت تريد فقط استخدام نقل الويب، فلا حاجة لبناء وتشغيل Petrie/Cera أيضًا. بمجرد تشغيل حاوياتك، استخدم curl localhost:8888 للتأكد من أن Core يعمل.

عند هذه النقطة، يجب أن يكون عميل Daddy Tops قد تم بناؤه، لذا اتبع التعليمات في meteor/docs/daddy_tops.md لتنزيل العميل والبدء في بناء الوكلاء!

Protobuf

تقريبًا كل التواصل في نظام Meteor يتم باستخدام protocol buffers. يحدد معيار اتصالات Meteor (MCS) كيفية تنسيق البيانات ليقوم Core بمعالجتها. يستخدم المستمعون والوكلاء أيضًا MCS لنقل الإجراءات والنتائج، ويستخدم Daddy Tops نظام MCS لكل شيء بدءًا من المصادقة وصولاً إلى تسجيل البوتات والمجموعات. يمكن العثور على ملف proto الخاص بـ MCS في meteor/pbuf/mcs.proto.

قنوات النقل الحالية

أزواج الوكلاء/المستمعين الحالية منفذة، مع خطط لإضافة المزيد في المستقبل:

• Petrie: مقبس TCP أساسي
• Little_Foot: ويب (HTTP)
• Cera (WIP): ICMP

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

Nest

يُستخدم Nest لبناء وتجميع كود Meteor (الوكلاء فقط حاليًا)، حتى لا تضطر إلى ذلك بنفسك. يمكنك استخدام Daddy Tops (أو أداة مخصصة) لإرسال المعاملات المطلوبة. على عكس بقية المشروع، تتكون Nest API من نقاط نهاية JSON بدلاً من protobuf. والسبب هو أن الملفات الثنائية يمكن بناؤها وتنزيلها ببعض أوامر curl البسيطة، بدلاً من الحاجة إلى استخدام protobuf وكود أكثر تعقيدًا.

المزيد من الوثائق

الوثائق محدودة إلى حد ما حاليًا، لكنها ستتحسن بمرور الوقت. يمكن العثور على بعض الوثائق الخاصة بـ Core و Nest APIs، بالإضافة إلى تعليمات Daddy Tops في meteor/docs.

إخلاء مسؤولية: هذه الأداة لأغراض تعليمية فقط. لا تعبث بأجهزة ليست ملكك. المؤلفون غير مسؤولين عن أي استخدام غير مشروع لقاعدة الشيفرة هذه.