# دليل لتجميع موارد تقوية البنية التحتية للفريق الأحمر
هذه الويكي مخصّصة لتوفير مرجع لإعداد بنية تحتية مرنة للفريق الأحمر. تم إنشاؤها لتكمل حديث ستيف بوروش (@424f424f) وجيف ديموك (@bluscreenofjeff) في مؤتمر BSides NoVa 2017 بعنوان "Doomsday Preppers: Fortifying Your Red Team Infrastructure" (الشرائح)
إذا كان لديك إضافة ترغب في تقديمها، يرجى إرسال طلب سحب (Pull Request) أو فتح مشكلة (issue) في المستودع.
شكرًا لجميع مؤلفي المحتوى المُشار إليه في هذه الويكي ولكل من ساهم!
عند تصميم بنية تحتية للفريق الأحمر تحتاج إلى الصمود أمام استجابة نشطة أو الاستمرار لفترة طويلة (أسابيع، أشهر، سنوات)، من المهم فصل كل أصل بناءً على وظيفته. يوفر هذا مرونة وخفة حركة ضد الفريق الأزرق عندما تبدأ أصول الحملة في الظهور. على سبيل المثال، إذا تم اكتشاف بريد التصيّد الخاص بالتقييم، فسيحتاج الفريق الأحمر فقط إلى إنشاء خادم SMTP جديد وخادم استضافة حمولات جديد، بدلاً من إعداد خادم فريق كامل.
ضع في اعتبارك فصل هذه الوظائف على أصول مختلفة:
ستكون كل وظيفة من هذه الوظائف مطلوبة على الأرجح لكل حملة هندسة اجتماعية. نظرًا لأن الاستجابة النشطة للحوادث شائعة في تقييمات الفريق الأحمر، يجب تنفيذ مجموعة جديدة من البنية التحتية لكل حملة.
لزيادة المرونة والإخفاء، يجب وضع جهاز إعادة توجيه أمام كل أصل خلفي (أي خادم الفريق). الهدف هو دائمًا وجود مضيف بين هدفنا وخوادمنا الخلفية. إعداد البنية التحتية بهذه الطريقة يجعل تجهيز بنية تحتية جديدة أسرع وأسهل بكثير - لا حاجة لإعداد خادم فريق جديد، أو ترحيل الجلسات، أو إعادة توصيل الأصول غير المكشوفة في الخلفية.
الأنواع الشائعة لأجهزة إعادة التوجيه:
لكل نوع من أنواع أجهزة إعادة التوجيه خيارات تنفيذ متعددة تناسب سيناريوهات مختلفة. تتم مناقشة هذه الخيارات بالتفصيل في قسم أجهزة إعادة التوجيه في الويكي. يمكن أن تكون أجهزة إعادة التوجيه مضيفي VPS، أو خوادم مخصصة، أو حتى تطبيقات تعمل على مثيل Platform-as-a-Service.
فيما يلي تصميم نموذجي، مع مراعاة الفصل الوظيفي واستخدام أجهزة إعادة التوجيه:
رؤية لعمليات الفريق الأحمر الموزعة - Raphael Mudge (@armitagehacker)
البنية التحتية لعمليات الفريق الأحمر المستمرة - Raphael Mudge
تكتيكات التهديدات المتقدمة (2 من 9): البنية التحتية - Raphael Mudge
أجهزة إعادة التوجيه المستندة إلى السحابة للاختراق الموزع - Raphael Mudge
كيفية بناء بنية تحتية لـ C2 باستخدام Digital Ocean – الجزء 1 - Lee Kagan (@invokethreatguy)
نشر البنية التحتية للفريق الأحمر تلقائيًا باستخدام Terraform - الجزء 1 - Rasta Mouse (@_RastaMouse)
ستختلف السمعة المدركة للنطاق بشكل كبير اعتمادًا على المنتجات التي يستخدمها هدفك، بالإضافة إلى تكوينها. على هذا النحو، فإن اختيار نطاق يعمل على هدفك ليس علمًا دقيقًا. سيكون جمع المعلومات مفتوح المصدر (OSINT) أمرًا بالغ الأهمية للمساعدة في تقديم أفضل تخمين لحالة الضوابط والموارد التي يجب فحص النطاقات مقابلها. لحسن الحظ، يواجه المعلنون عبر الإنترنت نفس المشكلات وقد أنشأوا بعض الحلول التي يمكننا الاستفادة منها.
expireddomains.net هو محرك بحث عن النطاقات المنتهية أو المسقطة مؤخرًا. يوفر البحث والتصفية المتقدمة، مثل عمر الانتهاء، وعدد الروابط الخلفية، وعدد لقطات Archive.org، ودرجة SimilarWeb. باستخدام الموقع، يمكننا تسجيل نطاقات مستخدمة مسبقًا، والتي ستأتي مع عمر النطاق، والتي تبدو مشابهة لهدفنا، أو تبدو مشابهة لانتحالنا، أو ببساطة من المرجح أن تندمج في شبكة هدفنا.
عند اختيار نطاق لـ C2 أو استخراج البيانات، فكر في اختيار نطاق مصنف ضمن فئة التمويل أو الرعاية الصحية. لن تقوم العديد من المؤسسات بإجراء وساطة SSL (SSL middling) على تلك الفئات بسبب احتمالية حدوث مشكلات قانونية أو حساسية البيانات. من المهم أيضًا التأكد من أن النطاق الذي اخترته غير مرتبط بأي حملات برمجيات خبيثة أو تصيّد سابقة.
أداة CatMyFish من Charles Hamilton(@MrUn1k0d3r) تعمل على أتمتة عمليات البحث وفحص تصنيف الويب باستخدام expireddomains.net و BlueCoat. يمكن تعديلها لتطبيق المزيد من عوامل التصفية على عمليات البحث أو حتى إجراء مراقبة طويلة الأمد للأصول التي تسجلها.
أداة أخرى، DomainHunter من Joe Vest (@joevest) و Andrew Chiles (@andrewchiles)، تُرجع تصنيف BlueCoat/WebPulse و IBM X-Force و Cisco Talos، وعمر النطاق، ونطاقات المستوى الأعلى (TLDs) البديلة المتاحة، وروابط Archive.org، وتقرير HTML. بالإضافة إلى ذلك، تقوم بإجراء فحوصات للاستخدام في حملات البرمجيات الخبيثة والتصيّد المعروفة باستخدام Malwaredomains.com و MXToolBox. تتضمن هذه الأداة أيضًا دعم OCR لتجاوز كابتشا BlueCoat/WebPulse. تحقق من منشور المدونة حول الإصدار الأولي للأداة لمزيد من التفاصيل.
أداة أخرى أيضًا، AIRMASTER من Max Harley (@Max_68) تستخدم expireddomains.net و Bluecoat للعثور على النطاقات المصنفة. تستخدم هذه الأداة OCR لتجاوز كابتشا BlueCoat، مما يزيد من سرعة البحث.
إذا لم يكن النطاق المسجل مسبقًا متاحًا أو كنت تفضل نطاقًا مسجلًا ذاتيًا، فمن الممكن تصنيف النطاقات بنفسك. باستخدام الروابط المباشرة أدناه أو أداة مثل Chameleon من Dominic Chell (@domchell). ستتجاهل معظم منتجات التصنيف عمليات إعادة التوجيه أو المحتوى المستنسخ عند تحديد تصنيف النطاق. لمزيد من المعلومات حول استخدام Chameleon، تحقق من منشور Dominic التصنيف ليس حدًا أمنيًا.
أخيرًا، تأكد من أن إعدادات DNS الخاصة بك قد انتشرت بشكل صحيح.
يبدو أن كلمتي سهل وتصيّد لا تتناسبان معًا أبدًا. قد يكون إعداد بنية تحتية مناسبة للتصيّد أمرًا مزعجًا حقًا. سيزودك البرنامج التعليمي التالي بالمعرفة والأدوات لإعداد خادم تصيّد بسرعة يجتاز "معظم" عوامل تصفية البريد العشوائي حتى الآن ويزودك بواجهة RoundCube لتجربة تصيّد سهلة تشمل الاتصال ثنائي الاتجاه مع هدفك. هناك العديد من الإعدادات والمنشورات حول التصيّد. هذه مجرد طريقة واحدة.
بمجرد حصولك على نطاق يجتاز الفحوصات المناسبة المدرجة في القسم السابق وتشغيل خادم التصيّد الخاص بك، ستحتاج إلى إنشاء سجلين "A" لنطاقك كما هو موضح.
بعد ذلك، اتصل عبر SSH بخادم التصيّد الخاص بك وتأكد من أن لديك اسم مضيف FQDN مناسب مدرجًا في ملف /etc/hosts الخاص بك. مثال "127.0.0.1 email.yourphishingserver.com email localhost"
الآن، ستقوم بتثبيت الواجهة الأمامية للويب للتصيّد منها في بضع خطوات سهلة. ابدأ بتنزيل أحدث إصدار "BETA" من iRedMail على خادم التصيّد الخاص بك. الطريقة السهلة هي النقر بزر الماوس الأيمن على زر التنزيل، ونسخ عنوان الرابط، واستخدام wget للتنزيل مباشرة على خادم التصيّد الخاص بك. بعد ذلك، قم بفك ضغطه "tar -xvf iRedMail-0.9.8-beta2.tar.bz2". انتقل إلى المجلد الذي تم فك ضغطه واجعل سكربت iRedMail.sh قابلاً للتنفيذ (chmod +x iRedMail.sh). نفّذ السكربت كجذر، واتبع المطالبات، وستحتاج إلى إعادة التشغيل لإنهاء كل شيء.
ستحتاج إلى التأكد من أن لديك جميع سجلات DNS المناسبة التي تشير إلى خادم البريد الخاص بك. (https://docs.iredmail.org/setup.dns.html). بالنسبة لـ DKIM، يجب أن يكون الأمر الجديد هو "amavisd-new showkeys" لعرض مفتاح DKIM الخاص بك.
بالنسبة لـ DMARC، يمكننا استخدام (https://www.unlocktheinbox.com/dmarcwizard/) لإنشاء إدخال dmarc الخاص بنا.
الآن، أنشئ مستخدمًا للتصيّد به.
سجّل الدخول إلى واجهة RoundCube باستخدام المستخدم الجديد الخاص بك وقم بالتصيّد بمسؤولية!
يوفر Cobalt Strike وظائف تصيّد بالرماح قابلة للتخصيص لدعم اختبار الاختراق أو التصيّد عبر البريد الإلكتروني للفريق الأحمر. يدعم القوالب بتنسيقات HTML و/أو نص عادي، والمرفقات، وعنوان ارتداد (bounceback)، وتضمين URL، واستخدام خادم SMTP عن بُعد، وتأخيرات الإرسال لكل رسالة. ميزة أخرى مثيرة للاهتمام هي القدرة على إضافة رمز مميز فريد إلى عنوان URL المضمّن لكل مستخدم لتتبع النقرات.
لمزيد من المعلومات التفصيلية، تحقق من هذه الموارد:
بالنسبة لتمارين الفريق الأحمر والتصيّد حيث تكون ثقة العميل وأمن العمليات (OPSEC) مهمة، فإن الاحتفاظ ببيانات العميل التي تم التقاطها والبنية التحتية الأساسية على خوادم العميل الخاصة (محليًا) يوفر مزايا كبيرة مقارنة بالحلول السحابية فقط. يستخدم هذا النهج الأصول السحابية فقط كأجهزة إعادة توجيه وواجهات أمامية رفيعة مع الحفاظ على العمليات الحساسة داخليًا.
يتكون إعداد Evilginx المحلي القوي عادةً من:
يعمل حجب ملفات تعريف الارتباط على تقليل زيارات الروبوتات والفحص الآلي من خلال طلب ملف تعريف ارتباط محدد للوصول إلى بوابة التصيّد:``` (http.host eq "portal.example.com") and (not http.cookie contains "session_token=abc123def456") and not (http.host eq "landing.example.com" and http.request.uri.path eq "/favicon.ico")
توجه هذه القاعدة الطلبات إلى نطاق البوابة التي لا تحتوي على ملف تعريف الارتباط المطلوب، مع إعفاء طلبات الأيقونة المفضلة لمنع حلقات إعادة التوجيه.
### نموذج تكوين Caddy```caddyfile
# Redirect direct IP access to prevent fingerprinting
1.2.3.4 {
redir https://legitimate-site.com{uri} permanent
}
landing.example.com {
log {
output file /var/log/caddy/landing_access.log
format console
}
tls internal
encode gzip
reverse_proxy http://127.0.0.1:8000
}
portal.example.com {
log {
output file /var/log/caddy/portal_access.log
format console
}
tls internal
encode gzip
reverse_proxy https://evilginx:443 {
transport http {
versions 1.1
tls_insecure_skip_verify
tls_server_name portal.example.com
}
header_up Host portal.example.com
header_up X-Forwarded-Proto https
}
}
قم بتشغيل Evilginx على العقدة الداخلية مع العلامات المناسبة:```bash ./evilginx2 -p ./phishlets -t ./redirectors -developer -debug
**مهم:** يجب أن يكون Evilginx قابلاً للوصول فقط من داخل الشبكة الخاصة؛ لا تنشر عنوان IP الخاص به في DNS العام أبدًا.
### قائمة فحص OPSEC والتقوية
1. **لا تعرض عناوين IP الخاصة بـ Evilginx في DNS العام أبدًا** - استخدم الشبكات الخاصة فقط
2. **احتفظ بالبيانات الحساسة على خوادم العملاء فقط** - يجب ألا تخزن أجهزة إعادة التوجيه بيانات الاعتماد التي تم التقاطها
3. **قم بتقوية أجهزة إعادة التوجيه** - قم بتدوير النطاقات، واستخدم فترات TTL قصيرة، وانشر أجهزة إعادة توجيه مؤقتة متعددة
4. **نفذ قواعد WAF/جدار الحماية** - استخدم فحوصات ملفات تعريف الارتباط، أو قوائم السماح للعناوين IP، أو التحقق من UA
5. **افصل التسجيل والاحتفاظ** - احتفظ بسجلات الوصول على Caddy وسجلات الالتقاط على مضيف Evilginx
6. **تجنب البصمات** - لا تستخدم أنماطًا يمكن التنبؤ بها أو بصمات TLS متطابقة
يوفر هذا النهج الهجين (إعادة توجيه عامة/التقاط خاص) مرونة التغطية السحابية مع الحفاظ على المزايا الأمنية والقانونية لإبقاء العمليات الحساسة في الموقع.
## أطر التصيد
إلى جانب إعداد نظام التصيد الخاص بك أو استخدام إطار عمل لاختبار الاختراق أو الفريق الأحمر، مثل Cobalt Strike، هناك العديد من الأدوات والأطر المخصصة للتصيد عبر البريد الإلكتروني. على الرغم من أن هذه الويكي لن تتعمق في تفاصيل كل إطار عمل، إلا أنه يتم جمع بعض الموارد لكل منها أدناه:
### Gophish
* [الموقع الرسمي لـ Gophish](https://getgophish.com/)
* [مستودع Gophish على GitHub](https://github.com/gophish/gophish)
* [دليل مستخدم Gophish](https://www.gitbook.com/book/gophish/user-guide/details)
### Phishing Frenzy
* [الموقع الرسمي لـ Phishing Frenzy](https://www.phishingfrenzy.com/)
* [مستودع Phishing Frenzy على GitHub](https://github.com/pentestgeek/phishing-frenzy)
* [تقديم Phishing Frenzy - Brandon McCann (@zeknox)](https://www.pentestgeek.com/phishing/introducing-phishing-frenzy)
### مجموعة أدوات المهندس الاجتماعي
* [مستودع مجموعة أدوات المهندس الاجتماعي على GitHub](https://github.com/trustedsec/social-engineer-toolkit)
* [دليل مستخدم مجموعة أدوات المهندس الاجتماعي](https://github.com/trustedsec/social-engineer-toolkit/raw/master/readme/User_Manual.pdf)
### FiercePhish (المعروف سابقًا باسم FirePhish)
* [مستودع FiercePhish على GitHub](https://github.com/Raikia/FiercePhish)
* [ويكي FiercePhish](https://github.com/Raikia/FiercePhish/wiki)
# أجهزة إعادة التوجيه
## SMTP
قد لا تكون كلمة "جهاز إعادة توجيه" أفضل وصف لما سنحققه، لكن الهدف هو نفسه كما هو الحال مع إعادة التوجيه الأخرى لدينا. نريد إزالة أي آثار لأصل التصيد الخاص بنا من ترويسات البريد الإلكتروني النهائية وتوفير حاجز بين الضحية وخادمنا الخلفي. من الناحية المثالية، يجب أن يكون جهاز إعادة توجيه SMTP سريع الإعداد وسهل الإيقاف عن العمل.
هناك إجراءان رئيسيان نريد تكوين جهاز إعادة توجيه SMTP لتنفيذهما:
### Sendmail
#### إزالة ترويسات الخادم السابقة
أضف السطر التالي إلى نهاية `/etc/mail/sendmail.mc`:```bash
define(`confRECEIVED_HEADER',`by $j ($v/$Z)$?r with $r$. id $i; $b')dnl
أضِف إلى نهاية ملف /etc/mail/access:```bash
IP-to-Team-Server TAB RELAY
Phish-Domain TAB RELAY
[إزالة عنوان IP الخاص بالمرسل من رأس Received في البريد الإلكتروني](https://www.devside.net/wamp-server/removing-senders-ip-address-from-emails-received-from-header)
[إزالة الرؤوس من إعداد Postfix](https://major.io/2013/04/14/remove-sensitive-information-from-email-headers-with-postfix/)
#### تكوين عنوان catch-all
سيقوم هذا بإعادة توجيه أي بريد إلكتروني يتم استلامه على *@phishdomain.com إلى عنوان بريد إلكتروني محدد. وهذا مفيد للغاية لتلقي أي ردود أو رسائل ارتدادية على بريد التصيد الاحتيالي.```bash
echo PHISH-DOMAIN >> /etc/mail/local-host-names
أضف السطر التالي مباشرة قبل //Mailer Definitions// (نحو النهاية) من ملف /etc/mail/sendmail.mc:```bash
FEATURE(virtusertable', hash -o /etc/mail/virtusertable.db')dnl
أضف السطر التالي إلى نهاية ملف `/etc/mail/virtusertable`:```bash
@phishdomain.com external-relay-address
ملاحظة: يجب أن يكون الحقلان مفصولين بعلامة تبويب
يوفر Postfix بديلاً أسهل لـ sendmail مع توافق أوسع. كما يقدم Postfix دعماً كاملاً لـ IMAP عبر Dovecot. وهذا يتيح للمختبرين التواصل في الوقت الفعلي مع أهداف التصيد الذين يردون على الرسالة الأصلية، بدلاً من الاعتماد على عنوان catch-all والاضطرار إلى إنشاء رسالة جديدة باستخدام أداة التصيد الخاصة بك.
يتوفر دليل كامل لإعداد خادم بريد Postfix لأغراض التصيد في منشور Julian Catrambone (@n0pe_sled) Mail Servers Made Easy.
ملاحظة: عند استخدام redirectors الخاصة بـ C2، يجب تكوين مستمع خارجي (foreign listener) على إطار عمل ما بعد الاستغلال لديك لإرسال حركة مرور التجهيز (staging traffic) عبر نطاق الـ redirector. سيؤدي ذلك إلى جعل المضيف المخترق يتجهز عبر الـ redirector تماماً مثل حركة مرور C2 نفسها.
يمكن استخدام socat لإعادة توجيه حزم DNS الواردة على المنفذ 53 إلى خادم الفريق لدينا. على الرغم من أن هذه الطريقة تعمل، فقد أبلغ بعض المستخدمين عن مشاكل في التجهيز مع Cobalt Strike أو مشاكل في زمن الاستجابة باستخدام هذه الطريقة. تعديل 4/21/2017: يبدو أن أمر socat التالي يعمل بشكل جيد بفضل الاختبارات من @xorrior:``` socat udp4-recvfrom:53,reuseaddr,fork udp4-sendto::53; echo -ne
[Redirecting Cobalt Strike DNS Beacons - Steve Borosh](https://medium.com/rvrsh3ll/redirecting-cobalt-strike-dns-beacons-e3dcdb5a8b9b)
### iptables لـ DNS
تم العثور على أن قواعد إعادة توجيه DNS الخاصة بـ iptables تعمل بشكل جيد مع Cobalt Strike. لا يبدو أن هناك أيًا من المشكلات التي يواجهها socat في التعامل مع هذا النوع من حركة المرور.
فيما يلي مثال على مجموعة قواعد مُعيد توجيه DNS.```bash
iptables -I INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination <IP-GOES-HERE>:53
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1
أيضًا، غيّر سياسة سلسلة "FORWARD" إلى "ACCEPT"
قد يكون لدى البعض متطلب أو حاجة لاستضافة خادم C2 على شبكة داخلية. باستخدام مزيج من IPTABLES وSOCAT وأنفاق SSH العكسية، يمكننا بالتأكيد تحقيق ذلك بالطريقة التالية.
في هذا السيناريو، لدينا جهاز إعادة التوجيه المؤقت الخاص بنا الذي يستخدم IPTables لتوجيه كل حركة مرور DNS باستخدام قاعدة المثال الموضحة سابقًا في هذا القسم. بعد ذلك، ننشئ نفق إعادة توجيه منفذ SSH عكسي من خادم C2 الداخلي لدينا إلى جهاز إعادة التوجيه الرئيسي. سيؤدي هذا إلى توجيه أي حركة مرور يستقبلها جهاز إعادة التوجيه الرئيسي على المنفذ 6667 إلى خادم C2 الداخلي على المنفذ 6667. الآن، ابدأ تشغيل socat على خادم الفريق لدينا لتقسيم أي حركة مرور TCP واردة على المنفذ 6667 إلى منفذ UDP 53، وهو ما يحتاج خادم DNS C2 الخاص بنا إلى الاستماع عليه. أخيرًا، نقوم بالمثل بإعداد مثيل socat على جهاز إعادة التوجيه الرئيسي لإعادة توجيه أي حركة مرور UDP واردة على المنفذ 53 إلى نفق SSH الخاص بنا على المنفذ 6667.
ملاحظة: عند استخدام أجهزة إعادة توجيه C2، يجب تكوين مستمع خارجي على إطار عمل ما بعد الاستغلال لديك لإرسال حركة مرور التجهيز عبر نطاق جهاز إعادة التوجيه. سيؤدي هذا إلى جعل المضيف المخترق يقوم بالتجهيز عبر جهاز إعادة التوجيه مثل حركة مرور C2 نفسها.
يوفر socat إعادة توجيه "أنبوب بسيط". أي طلب يستقبله socat على واجهة/منفذ المصدر المحدد يتم إعادة توجيهه إلى عنوان IP/منفذ الوجهة. لا يوجد تصفية أو إعادة توجيه شرطية. من ناحية أخرى، يوفر Apache mod_rewrite عددًا من الطرق لتعزيز هجمات التصيد وزيادة مرونة البنية التحتية للاختبار لديك. يمتلك mod_rewrite القدرة على إجراء إعادة توجيه شرطية بناءً على سمات الطلب، مثل URI ووكيل المستخدم وسلسلة الاستعلام ونظام التشغيل وعنوان IP. يستخدم Apache mod_rewrite ملفات htaccess لتكوين مجموعات القواعد لكيفية تعامل Apache مع كل طلب وارد. باستخدام هذه القواعد، يمكنك، على سبيل المثال، إعادة توجيه الطلبات إلى خادمك التي تحمل وكيل مستخدم wget الافتراضي إلى صفحة مشروعة على موقع هدفك.
باختصار، إذا كان جهاز إعادة التوجيه الخاص بك يحتاج إلى إجراء إعادة توجيه شرطية أو تصفية متقدمة، فاستخدم Apache mod_rewrite. بخلاف ذلك، ستكون إعادة توجيه socat مع تصفية iptables اختيارية كافية.
يمكن استخدام socat لإعادة توجيه أي حزم TCP واردة على منفذ محدد إلى خادم الفريق لدينا.
الصيغة الأساسية لإعادة توجيه منفذ TCP 80 على localhost إلى المنفذ 80 على مضيف آخر هي:``` socat TCP4-LISTEN:80,fork TCP4::80
إذا كان المُوجِّه (redirector) لديك مُهيَّأً بأكثر من واجهة شبكة واحدة، يمكن ربط socat بواجهة محددة، عبر عنوان IP، باستخدام الصيغة التالية:```
socat TCP4-LISTEN:80,bind=10.0.0.2,fork TCP4:1.2.3.4:80
في هذا المثال، 10.0.0.2 هو أحد عناوين IP المحلية للمُعيد (redirector) و1.2.3.4 هو عنوان IP لخادم الفريق البعيد.
بالإضافة إلى socat، يمكن لـ iptables تنفيذ إعادة توجيه "الأنبوب البسيط" عبر NAT. لإعادة توجيه المنفذ المحلي 80 للمُعيد إلى مضيف بعيد، استخدم الصيغة التالية:``` iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination :80 iptables -t nat -A POSTROUTING -j MASQUERADE iptables -I FORWARD -j ACCEPT iptables -P FORWARD ACCEPT sysctl net.ipv4.ip_forward=1
### SSH لـ HTTP
لقد قمنا سابقًا بتغطية استخدام SSH لأنفاق DNS. يعمل SSH كوسيلة صلبة وقوية لاختراق NAT والحصول على طريقة للـ implant للاتصال بـ redirector وإلى بيئة الخادم الخاصة بك. قبل إعداد SSH redirector، يجب عليك إضافة الأسطر التالية إلى `/etc/ssh/sshd_config`:```text
# Allow the SSH client to specify which hosts may connect
GatewayPorts yes
# Allow both local and remote port forwards
AllowTcpForwarding yes
لإعادة توجيه المنفذ المحلي 80 الخاص بالموجّه إلى خادمك الداخلي، استخدم الصيغة التالية على الخادم الداخلي:``` tmux new -S redir80 ssh -R *:80:localhost:80 Ctrl+B, D
يمكنك أيضًا تمرير أكثر من منفذ واحد، على سبيل المثال إذا كنت تريد فتح المنفذين 443 و80 في نفس الوقت:```
tmux new -S redir80443
ssh <redirector> -R *:80:localhost:80 -R *:443:localhost:443
Ctrl+B, D
عند تقديم الحمولات وموارد الويب، نهدف إلى تقليل قدرة المستجيبين للحوادث على مراجعة الملفات وزيادة فرص تنفيذ الحمولة بنجاح، سواء لإنشاء اتصال C2 أو لجمع المعلومات الاستخباراتية.
استخدامات وأمثلة Apache Mod_Rewrite بقلم Jeff Dimmock:
استخدامات وأمثلة أخرى لـ Apache mod_rewrite:
لإعداد Apache Mod_Rewrite تلقائيًا على خادم إعادة التوجيه، اطّلع على منشور مدونة Julain Catrambone (@n0pe_sled) Mod_Rewrite Automatic Setup والأداة المصاحبة.
الهدف من إعادة توجيه حركة مرور C2 مزدوج: إخفاء خادم الفريق الخلفي والظهور كموقع ويب شرعي إذا تصفحه مستجيب للحوادث. من خلال استخدام Apache mod_rewrite وملفات تعريف C2 المخصصة أو وسائل بروكسي أخرى (مثل Flask)، يمكننا تصفية حركة مرور C2 الحقيقية بشكل موثوق من حركة التحقيق.
بناءً على "إعادة توجيه C2" أعلاه، هناك طريقة أخرى تتمثل في جعل خادم إعادة التوجيه يستخدم محرك SSL Proxy الخاص بـ Apache لاستقبال طلبات SSL الواردة، وتمرير تلك الطلبات إلى مستمع HTTPS عكسي. يتم استخدام التشفير في جميع المراحل، ويمكنك تدوير شهادات SSL على خادم إعادة التوجيه حسب الحاجة.
لجعل هذا يعمل مع قواعد mod_rewrite الخاصة بك، تحتاج إلى وضع قواعدك في "/etc/apache2/sites-available/000-default-le-ssl.conf" بافتراض أنك استخدمت LetsEncrypt (المعروف أيضًا باسم CertBot) لتثبيت شهادتك. أيضًا، لتمكين محرك SSL ProxyPass، ستحتاج إلى الأسطر التالية في نفس ملف التكوين:```bash
SSLProxyEngine On
ProxyPass / https://DESTINATION_C2_URL:443/ ProxyPassReverse / https://DESTINATION_C2_URL:443/
SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off
### موارد أخرى لـ Apache mod_rewrite
* [أتمتة Apache mod_rewrite وملفات تعريف Cobalt Strike](https://posts.specterops.io/automating-apache-mod-rewrite-and-cobalt-strike-malleable-c2-profiles-d45266ca642)
* [mod-rewrite-cheatsheet.com](http://mod-rewrite-cheatsheet.com/)
* [توثيق Apache 2.4 الرسمي لـ mod_rewrite](http://httpd.apache.org/docs/current/rewrite/)
* [مقدمة إلى Apache mod_rewrite](https://httpd.apache.org/docs/2.4/en/rewrite/intro.html)
* [دليل متعمق لـ mod_rewrite في Apache](http://code.tutsplus.com/tutorials/an-in-depth-guide-to-mod-rewrite-for-apache--net-6708)
* [مدقق صياغة Mod_Rewrite/.htaccess](http://www.htaccesscheck.com/)
# تعديل حركة مرور C2
## Cobalt Strike
يعدّل Cobalt Strike حركة مروره باستخدام ملفات تعريف Malleable C2. توفر ملفات التعريف خيارات قابلة للتخصيص بدرجة كبيرة لتعديل شكل حركة مرور C2 لخادمك على الشبكة. يمكن استخدام ملفات تعريف Malleable C2 لتعزيز التهرب من الاستجابة للحوادث، أو انتحال شخصية خصوم معروفين، أو التنكر كتطبيقات داخلية مشروعة يستخدمها الهدف.
* [ملفات تعريف Malleable C2 الرسمية - GitHub](https://github.com/rsmudge/Malleable-C2-Profiles)
* [توثيق Malleable Command and Control - cobaltstrike.com](https://www.cobaltstrike.com/help-malleable-c2)
* [Cobalt Strike 2.0 - Malleable Command and Control - Raphael Mudge](http://blog.cobaltstrike.com/2014/07/16/malleable-command-and-control/)
* [Cobalt Strike 3.6 - مسار لتصعيد الامتيازات - Raphael Mudge](http://blog.cobaltstrike.com/2016/12/08/cobalt-strike-3-6-a-path-for-privilege-escalation/)
* [عالم جديد شجاع: Malleable C2 - Will Schroeder (@harmj0y)](http://www.harmj0y.net/blog/redteaming/a-brave-new-world-malleable-c2/)
* [كيفية كتابة ملفات تعريف Malleable C2 لـ Cobalt Strike - Jeff Dimmock](https://bluescreenofjeff.com/2017-01-24-how-to-write-malleable-c2-profiles-for-cobalt-strike/)
* [التهرب في الذاكرة (سلسلة فيديو) - Raphael Mudge](https://www.youtube.com/watch?v=lz2ARbZ_5tE&list=PL9HO6M_MU2nc5Q31qd2CwpZ8J4KFMhgnK)
عندما تبدأ في إنشاء أو تعديل ملفات تعريف Malleable C2، من المهم مراعاة حدود حجم البيانات لموضع معلومات Beacon. على سبيل المثال، سيتطلب تكوين الملف التعريفي لإرسال كميات كبيرة من البيانات في معامل URL العديد من الطلبات. لمزيد من المعلومات حول هذا، راجع منشور مدونة Raphael Mudge [احذر من التنزيلات البطيئة](https://blog.cobaltstrike.com/2018/03/09/beware-of-slow-downloads/).
إذا واجهت مشكلات مع ملف تعريف Malleable C2 الخاص بك ولاحظت أن وحدة التحكم في teamserver تُخرج أخطاء، فراجع منشور مدونة Raphael Mudge [الوعود المكسورة وملفات تعريف Malleable C2](https://blog.cobaltstrike.com/2018/06/04/broken-promises-and-malleable-c2-profiles/) للحصول على نصائح استكشاف الأخطاء وإصلاحها.
## Empire
يستخدم Empire ملفات تعريف الاتصال، التي توفر خيارات تخصيص لعناوين URI لطلبات GET، ووكيل المستخدم، والترويسات. يتكون الملف التعريفي من كل عنصر، مفصولاً بحرف الأنبوب، ويتم تعيينه باستخدام خيار `set DefaultProfile` في قائمة سياق `listeners`.
فيما يلي نموذج لملف تعريفي افتراضي:```bash
"/CWoNaJLBo/VTNeWw11212/|Mozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.1)|Accept:image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*|Accept-Language:en-en"
بدلاً من ذلك، يمكن تعيين قيمة DefaultProfile عن طريق تعديل الملف /setup/setup_database.py قبل الإعداد الأولي لـ Empire. سيؤدي هذا إلى تغيير ملف تعريف الاتصال الافتراضي الذي سيستخدمه Empire.
بالإضافة إلى ملف تعريف الاتصال، فكر في تخصيص URIs التمهيد لخادم Empire، ورؤوس الخادم، ومحتوى صفحة الويب الافتراضية باتباع الخطوات المعروضة في منشور Joe Vest (@joevest) Empire - Modifying Server C2 Indicators.
يمكن أن يوفر الاستفادة من خدمات الويب الموثوقة والشرعية لـ C2 ميزة قيّمة على استخدام النطاقات والبنية التحتية التي قمت بتكوينها بنفسك. يختلف وقت التكوين والتعقيد بناءً على التقنية والخدمة المستخدمة. مثال شائع على الاستفادة من خدمات الطرف الثالث لإعادة توجيه C2 هو Domain Fronting.
Domain Fronting هي تقنية تستخدمها خدمات وتطبيقات تجاوز الرقابة لتوجيه حركة المرور عبر نطاقات شرعية وموثوقة للغاية. تشمل الخدمات الشائعة التي تدعم Domain Fronting Google App Engine وAmazon CloudFront وMicrosoft Azure. من المهم ملاحظة أن العديد من المزودين، مثل Google وAmazon، قاموا بتنفيذ إجراءات تخفيف ضد Domain Fronting، لذلك قد تكون بعض الموارد المرتبطة أو المعلومات المقدمة في هذا الويكي قديمة بحلول الوقت الذي تحاول استخدامها.
باختصار، تستخدم حركة المرور اسم DNS وSNI لمزود الخدمة الموثوق، ويُستخدم Google في المثال أدناه. عندما تستقبل خوادم الحافة (مثل: الموجودة على gmail.com) حركة المرور، يتم إعادة توجيه الحزمة إلى خادم الأصل (مثل: phish.appspot.com) المحدد في حقل Host في الحزمة. اعتمادًا على مزود الخدمة، سيقوم خادم الأصل إما بإعادة توجيه حركة المرور مباشرة إلى نطاق محدد، والذي سنشير إليه إلى خادم الفريق الخاص بنا، أو سيكون تطبيق وكيل مطلوبًا لتنفيذ القفزة النهائية لإعادة التوجيه.
لمزيد من المعلومات التفصيلية حول كيفية عمل Domain Fronting، راجع الورقة البيضاء Blocking-resistant communication through domain fronting وتوثيق meek الخاص بمشروع TOR.
بالإضافة إلى النطاقات القابلة للواجهة القياسية، مثل أي نطاق google.com، من الممكن الاستفادة من نطاقات شرعية أخرى للواجهة.
لمزيد من المعلومات حول البحث عن النطاقات القابلة للواجهة، تحقق من:
يوفر العديد من مزودي PaaS وSaaS نطاقًا فرعيًا ثابتًا أو عنوان URL لاستخدامه مع مثيل مُجهز. إذا كان النطاق المرتبط موثوقًا به بشكل عام، يمكن أن توفر المثيلات ثقة إضافية للبنية التحتية لـ C2 الخاصة بك مقارنة بنطاق مشترى وVPS.
لإعداد إعادة التوجيه، ستحتاج إلى تحديد خدمة تصدر نطاقًا فرعيًا ثابتًا أو عنوان URL كجزء من المثيل. بعد ذلك، ستحتاج إما إلى تكوين المثيل بإعادة توجيه قائمة على الشبكة أو التطبيق. سيعمل المثيل كوكيل، على غرار أدوات إعادة التوجيه الأخرى التي تمت مناقشتها في هذا الويكي.
تقنية أخرى مثيرة للاهتمام تستحق مزيدًا من البحث هي استخدام دلائل Amazon S3 شديدة التساهل لـ C2. تحقق من المنشور S3 Buckets for Good and Evil بقلم Andrew Luke (@Sw4mp_f0x) لمزيد من التفاصيل حول كيفية استخدام دلائل S3 لـ C2. يمكن دمج هذه التقنية مع قدرات C2 التابعة لجهات خارجية في Empire لاستخدام دلائل S3 الشرعية للهدف ضدهم.
لمثال آخر على استخدام PaaS لـ C2، تحقق من Databases and Clouds: SQL Server as a C2 بقلم Scott Sutherland (@_nullbind).
تم استخدام خدمات تابعة لجهات خارجية أخرى في البرية لـ C2 في الماضي. يمكن أن يساعدك الاستفادة من مواقع الويب التابعة لجهات خارجية التي تسمح بالنشر السريع أو تعديل المحتوى الذي ينشئه المستخدم في تجاوز الضوابط القائمة على السمعة، خاصة إذا كان موقع الطرف الثالث موثوقًا به بشكل عام.
تحقق من هذه الموارد لخيارات C2 الأخرى التابعة لجهات خارجية:
غالبًا ما يكون من السهل تحديد البنية التحتية للهجوم، حيث تبدو وكأنها قشرة لخادم شرعي. سنحتاج إلى اتخاذ خطوات إضافية مع بنيتنا التحتية لزيادة احتمالية الاندماج مع الخوادم الحقيقية سواء داخل المؤسسة المستهدفة أو الخدمات التي قد يستخدمها الهدف بشكل معقول.
يمكن أن تساعد أدوات إعادة التوجيه في الاندماج عن طريق إعادة توجيه URIs غير الصالحة أو إنهاء روابط حمولات التصيد أو حظر تقنيات المستجيبين للحوادث الشائعة؛ ومع ذلك، يجب أيضًا إيلاء الاهتمام للمضيف الأساسي ومؤشراته.
على سبيل المثال، في المنشور Fall of an Empire، يغطي John Menerick (@Lord_SQL) طرقًا لاكتشاف خوادم Empire على الإنترنت.
لمكافحة هذه المؤشرات وما شابهها، من الجيد تعديل أنماط حركة مرور C2 وتعديل صفحات الهبوط للخادم وتقييد المنافذ المفتوحة وتعديل رؤوس الاستجابة الافتراضية.
لمزيد من التفاصيل حول كيفية القيام بهذه التكتيكات وغيرها لأطر الهجوم المتعددة، تحقق من هذه المنشورات:
يمكن مهاجمة البنية التحتية للهجوم تمامًا مثل أي مضيف آخر متصل بالإنترنت، ويجب اعتبارها شديدة الحساسية بسبب البيانات المستخدمة والاتصالات ببيئات الهدف.
في عام 2016، تم الكشف عن ثغرات تنفيذ التعليمات البرمجية عن بُعد في أكثر أدوات الهجوم شيوعًا:
يجب استخدام iptables لتصفية حركة المرور غير المرغوب فيها وتقييد حركة المرور بين عناصر البنية التحتية المطلوبة. على سبيل المثال، إذا كان خادم فريق Cobalt Strike سيخدم الأصول فقط لموجه Apache، فيجب أن تسمح قواعد iptables بالمنفذ 80 فقط من عنوان IP الخاص بالموجه. هذا مهم بشكل خاص لأي واجهات إدارة، مثل SSH أو المنفذ الافتراضي 50050 لـ Cobalt Strike. فكر أيضًا في حظر عناوين IP للدول غير المستهدفة. كبديل، فكر في استخدام جدران حماية برنامج Hypervisor التي يوفرها مزودو VPS. على سبيل المثال، تقدم Digital Ocean Cloud Firewalls التي يمكنها حماية واحدة أو أكثر من droplets.
يمكن استخدام chattr على خوادم الفريق لمنع تعديل أدلة cron. باستخدام chattr، يمكنك تقييد أي مستخدم، بما في ذلك root، من تعديل ملف حتى تتم إزالة سمة chattr.
يجب أن يقتصر SSH على مصادقة المفتاح العام فقط وأن يتم تكوينه لاستخدام مستخدمين بصلاحيات محدودة لتسجيل الدخول الأولي. لمزيد من الأمان، فكر في إضافة مصادقة متعددة العوامل إلى SSH.
تحديث! لا تكتمل أي قائمة تأمين بدون تذكير بتحديث الأنظمة بانتظام وتطبيق التصحيحات السريعة حسب الحاجة لمعالجة الثغرات الأمنية.
بالطبع، هذه القائمة ليست شاملة لما يمكنك القيام به لتأمين خادم الفريق. اتبع ممارسات التحصين الشائعة على جميع البنية التحتية:
هناك عدد من الموارد المتاحة عبر الإنترنت تناقش الإعداد الآمن وتصميم البنى التحتية. لن يكون كل اعتبار تصميمي مناسبًا لكل بنية تحتية للهجوم، ولكن من المفيد معرفة الخيارات المتاحة وما يفعله المختبرون الآخرون.
فيما يلي بعض هذه الموارد:
الموضوعات التي تمت تغطيتها في هذا الويكي تقوي البنى التحتية للهجوم، ولكنها تتطلب عمومًا قدرًا كبيرًا من الوقت للتصميم والتنفيذ. يمكن استخدام الأتمتة لتقليل أوقات النشر بشكل كبير، مما يسمح لك بنشر إعدادات أكثر تعقيدًا في وقت أقل.
تحقق من هذه الموارد حول أتمتة البنية التحتية للهجوم:
وثّق كل شيء - تشغيل بنية تحتية معقدة للفريق الأحمر يعني العديد من الأجزاء المتحركة. تأكد من توثيق وظيفة كل أصل وإلى أين يتم إرسال حركة المرور الخاصة به.
وزّع الأصول بين مزودي خدمات ومناطق مختلفة - يجب توزيع أصول البنية التحتية عبر مزودي خدمات ومناطق جغرافية متعددة. قد يرفع أعضاء الفريق الأزرق عتبات المراقبة ضد المزودين الذين تم تحديدهم على أنهم ينفذون هجومًا نشطًا وقد يحظرون مزود خدمة معينًا تمامًا. ملاحظة: ضع في اعتبارك قوانين الخصوصية الدولية إذا كنت ترسل بيانات مشفرة أو حساسة عبر الحدود.
لا تبالغ - من السهل أن تتحمس للتقنيات المتقدمة وتريد إلقاء كل شيء على الهدف. إذا كنت تحاكي تهديدًا خصمًا محددًا، فاستخدم فقط التقنيات التي استخدمها الفاعل الحقيقي للتهديد أو التقنيات ضمن مجموعة مهارات الفاعل. إذا كان اختبار الفريق الأحمر الخاص بك سيهاجم نفس الهدف على المدى الطويل، ففكر في البدء "بسهولة" والعمل من خلال الحرفية الأكثر تقدمًا مع استمرار تقييماتك. إن تطوير تقنية الفريق الأحمر جنبًا إلى جنب مع الفريق الأزرق سيدفع المؤسسة باستمرار إلى الأمام، بينما قد يؤدي ضرب الفريق الأزرق بكل شيء دفعة واحدة إلى إرباك الفريق الأزرق وإبطاء عملية التعلم.
راقب السجلات - يجب مراقبة جميع السجلات طوال فترة المشاركة: سجلات SMTP، وسجلات Apache، وtcpdump على أدوات إعادة توجيه socat، وسجلات iptables (المحددة لإعادة توجيه حركة المرور أو التصفية المستهدفة)، وسجلات الويب، وسجلات Cobalt Strike/Empire/MSF. قم بإعادة توجيه السجلات إلى موقع مركزي، مثل rsyslog، لسهولة المراقبة. قد يكون الاحتفاظ ببيانات طرفية المشغل مفيدًا لمراجعة استخدام الأوامر التاريخي أثناء العملية. أنشأ @Killswitch_GUI برنامجًا سهل الاستخدام باسم lTerm يسجل جميع أوامر bash الطرفية في موقع مركزي. سجل جميع مخرجات الطرفية باستخدام lTerm. تحقق من منشور Vincent Yiu CobaltSplunk للحصول على مثال حول كيفية إرسال سجلات Cobalt Strike إلى Splunk للمراقبة والتحليل المتقدم للبنية التحتية.* تنفيذ تنبيهات الأحداث عالية القيمة - قم بتكوين البنية التحتية للهجوم لتوليد تنبيهات للأحداث عالية القيمة، مثل جلسات C2 الجديدة أو عمليات التقاط بيانات الاعتماد. إحدى الطرق الشائعة لتنفيذ التنبيهات هي عبر واجهة برمجة تطبيقات منصة دردشة، مثل Slack. تحقق من المنشورات التالية حول تنبيهات Slack: Slack Shell Bot - Russel Van Tuyl (@Ne0nd0g)، Slack Notifications for Cobalt Strike - Andrew Chiles (@AndrewChiles)، Slack Bots for Trolls and Work - Jeff Dimmock (@bluscreenfojeff)
بصمة الاستجابة للحوادث - إذا أمكن، حاول بصمة إجراءات الاستجابة للحوادث بشكل سلبي أو نشط قبل بدء التقييم. على سبيل المثال، أرسل بريدًا إلكترونيًا للتصيد الاحتيالي متوسط الجودة إلى الهدف (باستخدام بنية تحتية غير مرتبطة) وراقب حركة المرور التي تستقبلها تلك البنية التحتية. يمكن لتحقيقات فريق الاستجابة للحوادث أن تكشف قدرًا كبيرًا من المعلومات حول كيفية عمل الفريق والبنية التحتية التي يستخدمونها. إذا أمكن تحديد ذلك قبل التقييم، يمكن تصفيته أو إعادة توجيهه تمامًا.
شكرًا جزيلاً لجميع الأشخاص التاليين (مدرجين أبجديًا) الذين ساهموا بأدوات أو نصائح أو روابط لإدراجها في الويكي، وشكرًا آخر لأي شخص كتب أداة أو منشورًا مشارًا إليه في هذا الويكي!