ربط IAT لقنوات C2 مخصصة

هذا إثبات مفهوم (PoC) بسيط وقالب لتطوير قنوات C2 مخصصة لـ Cobalt Strike باستخدام خطافات IAT المطبقة بواسطة محمّل انعكاسي.

منشور المدونة: https://codex-7.gitbook.io/codexs-terminal-window/red-team/cobalt-strike/building-custom-c2-channels-by-hooking-wininet
صورة متحركة تجريبية لقناة TCP

الاستخدام

ملفات customCallback.h وhook.c وhash.h وhook.h هي قوالب تقريبية، لكن يمكن وضعها في Crystal kit لاستخدامها كما هي كإثبات مفهوم. ضعها في مجلد udrl/src، مع استبدال النسخ الموجودة. ملف tcg.h لم يتغير (من Raphael Mudge's tradecraft garden)

يمكن استخدام الأمثلة في مجلد examples/ كما هي، لكنها أمثلة ولم تُؤخذ الاعتبارات التشغيلية عند كتابتها. استخدمها بحذر.

الأمثلة الحالية هي:

• named pipe (يجب أن يعمل الوسيط على نفس المضيف)
• TCP
• UDP (كنت كسولًا جدًا لتنفيذ التقسيم، لذا الحد الأقصى لحجم الاستدعاء هو 65535)
• NTP (كنت كسولًا جدًا لتنفيذ التقسيم، لذا الحد الأقصى لحجم الاستدعاء هو 65535)
• ICMP (كنت كسولًا جدًا لتنفيذ التقسيم، لذا الحد الأقصى لحجم الاستدعاء هو 65535)
• Websockets (يعمل فقط مع wininet، وهو قيد الإصلاح)

لاحظ أن قدرات التهرب الأصلية في Crystal kit مثل تنفيذ Draugr وإخفاء النوم أُزيلت من hook.c للحفاظ على نظافة قاعدة الشيفرة هذه وقابليتها للنقل. إذا كنت ترغب في الاحتفاظ بهذه الميزات، يمكنك إضافتها مرة أخرى من النسخ الأصلية في Crystal kit.

يجب عليك تحديد مكتبة http المناسبة winhttp/wininet كمكتبة http لاستخدامها عند إنشاء beacon dll.

ملف تعريف malleable الذي تم اختباره بهذا القالب متوفر في المستودع - نظريًا، يجب أن تعمل معظم ملفات تعريف malleable الأخرى، لكن هذا القالب تم اختباره باستخدام هذا الملف (مأخوذ من GraphStrike).

لماذا صنعت هذا؟

واجهة ExternalC2 الرسمية مزعجة في الاستخدام - فهي تتطلب تجهيز beacon من نوع SMB عبر قناة externalc2، وحتى الإصدار 4.10 لم تكن تدعم التواصل مع beacon من نوع SMB مُعد مسبقًا دون التجهيز عبر وكيل externalc2 أولاً. وحتى في حالتها الحالية، تظل مرتبطة ببنية:

smb beacon --named pipe--> externalc2 agent --custom channel--> externalc2 handler --> teamserver

نعم، أنا على علم بأنه تمت إضافة UDC2 في Cobalt Strike 4.12. هذه مجرد تجربة ممتعة على أي حال لتكرار تلك الإمكانية في UDRL.

الفكرة بسيطة - إذا استطعت ربط WinAPIs المستخدمة للاتصال مرة أخرى، فأنت تملك بالفعل جميع البيانات اللازمة للاستدعاء. هذه الطريقة في تنفيذ قنوات C2 المخصصة تم القيام بها من قبل، كما هو موضح في GraphStrike.

ومع ذلك، فإن تنفيذ GraphStrike لا يزال مرتبطًا إلى حد كبير ببروتوكول HTTP نفسه. الهدف من هذا المستودع هو توفير قالب سهل الاستخدام والتعديل والتوسيع لتنفيذ أي قناة مخصصة، سواء كانت HTTP أو غير ذلك، مع تعديل بسيط على الكود المحيط.

توسيع القالب

من الواضح أن هذا القالب لم يُصمم لاستخدامه في حالته الافتراضية، لذا لتنفيذ قناة C2 التي تختارها، تحتاج إلى تعديل ما يلي:

دالة customCallback لتنفيذ الأمور التالية:

1. إرسال كتلة base64 (وسيطها الأول) خارجًا عبر أي وسيلة ضرورية
2. الحصول على الاستجابة وإعادتها

يمكنك استخدام المضيف والمنفذ الأصليين لطلب http (اللذين تعيّنهما من Cobalt) عبر الوسائط:

const char *host
INTERNET_PORT port

وتعديل دالة handleCallback() في broker.py للقيام بما يلي:

1. استقبال الاستدعاءات
2. استدعاء process_encoded_request(بيانات الاستدعاء الخاصة بك هنا)
3. إرسال الاستجابات مرة أخرى.

هذا كل شيء.

كمثال، إثبات المفهوم في دالة customCallback() داخل customCallback.h يقوم حاليًا بما يلي:

1. كتابة كتلة base64 إلى ملف request.txt
2. الانتظار لمدة 500 مللي ثانية
3. قراءة الاستجابة من ملف response.txt
4. إرجاع محتويات الملف

إثبات المفهوم في دالة handleCallback داخل broker.py يقوم حاليًا بما يلي:

1. قراءة الاستدعاء من request.txt
2. استدعاء process_encoded_request(encoded_request)
3. كتابة الاستجابة إلى response.txt

usage: broker.py [-h] --host HOST --port PORT حيث يشير المضيف والمنفذ إلى مستمع http على خادم فريقك. يقوم الوسيط بتحليل طلب http وإرساله إلى المستمع الفعلي.

حقائق ممتعة عشوائية أخرى حول هذا التنفيذ، لمن يهتم

هذه على الأرجح الطريقة «الأكثر كسلًا» للقيام بذلك، لكنها أيضًا واحدة من أكثر الطرق استقرارًا. إنها ببساطة تغلف طلب HTTP بالكامل وتشحنه إلى الوسيط بالطريقة التي تريدها، والذي يرسله بعد ذلك إلى خادم الفريق فعليًا، ليعمل كـ HTTP beacon، بشفافية تامة تجاه خادم الفريق.

هناك تنفيذ (تقنيًا) أنظف جربته يتضمن استخدام ملف تعريف Malleable C2 مبسط (استخدمت ملف GraphStrike في الواقع) وتحليل مكونات بيانات beacon المختلفة وفقًا لمواصفات malleable داخل خطافات wininet نفسها (id وmetadata وoutput وما إلى ذلك). كان هذا سيجعل أحجام كتل الاستدعاء أصغر قليلاً، لكن هذا التنفيذ تم التخلي عنه لأن الكود أصبح فوضويًا بشكل غير ضروري بسبب تحليل الطلب، وتطلب أيضًا استخدام ذلك الملف المحدد (وهو ليس مشكلة كبيرة لكنه اختراق كبير).

شعرت أن هذا التنفيذ أفضل لأنه أقل اعتمادًا على ملف تعريف malleable الاختراقي (تقنيًا، لا يزال يتطلب إرسال مخرجات استجابة beacon في نص الاستجابة، لكن هذا هو المطلب الوحيد) وكان الكود أسهل في القراءة بعشرة أضعاف.

ومن الجدير بالذكر أيضًا أنه لا يوجد أي تشويش أو تشفير على json طلب http بخلاف ترميز base64 - يمكنك إضافة ما يناسبك، ولكن نظرًا لأن استدعاءات Beacon مشفرة بالفعل، فمن الناحية الفنية لا توجد بيانات معرضة لخطر فك التشفير. أسوأ ما يمكن أن يحدث هو أن كتلة base64 إذا تم استرجاعها قد يتم التعرف عليها كطلب HTTP. تصرف بهذه المعلومة كما تشاء.

الاعتمادات والمراجع

• https://github.com/rasta-mouse/Crystal-Kit (القالب الأصلي للتطوير والاختبار)
• https://github.com/RedSiege/GraphStrike (ربط IAT لتنفيذ قناة Graph)
• https://github.com/benheise/TitanLdr (ربط IAT لتنفيذ DoH)
• https://tradecraftgarden.org/ (الإطار المستخدم في Crystal kit، وبالتبعية هذا)

نعم، استخدمت LLM لكتابة بعض الشيفرة والتعليقات، لا أحد يحب كتابة الوثائق أو كتابة تحليل json النمطي في C من الصفر. قابلني.

إخلاء مسؤولية

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