CaddySmith

CaddySmith هو نص برمجي صغير بلغة Python يقرأ ملف تعريف C2 من Cobalt Strike أو Sliver ويُنشئ منه تكوين خادم ويب Caddy. يقوم ملف Caddyfile الناتج بتحويل جهاز Linux عادي إلى مُوجّه (redirector): حيث يتم توجيه حركة المرور المشروعة للبيكون (beacon) عبر وكيل عكسي إلى خادم الفريق (team server)، بينما يتم توجيه أي شيء آخر (الماسحات، روبوتات البحث، فرق الكشف الزرقاء، أو طلبات curl العشوائية) إلى عنوان URL وهمي.

لقد كتبت هذه الأداة لأن Caddy هو خادم ويب أسهل بكثير في الإعداد السريع مقارنةً بـ Apache؛ فهو ثنائي ثابت واحد، وشهادات Let's Encrypt تلقائية، ولا حاجة لاستخدام a2enmod.

للاستخدام المأذون به فقط. هذه أداة أمنية هجومية. لا تقم بتشغيلها إلا على بيئات لديك إذن كتابي لاختبارها.

صيغ الملفات المدعومة

يُحدد CaddySmith الصيغة تلقائيًا من محتويات الملف:

• Cobalt Strike — الصيغة النصية التقليدية مع توجيهات مثل set uri "/foo". يتم تحويل كل URI من HTTP-GET / HTTP-POST إلى مسار دقيق خاص به مع تطبيق رؤوس العميل الواردة في الملف.
• Sliver — تكوين implant بصيغة JSON تم تصديره من Sliver. لا يحتوي Sliver على URIs ثابتة؛ بل يُنشئها وقت بناء البيكون من قوائم المسارات / الملفات / الامتدادات. يتعامل CaddySmith مع ذلك عن طريق مطابقة بادئات المسارات العليا كـ globs (مثل path /api* /static* /resources*) وإجراء مطابقة جزئية لرقم بناء Chrome في سلسلة User-Agent (والتي تبقى ثابتة رغم تغييرات Sliver لـ UA حسب النظام الأساسي).

يمكنك أيضًا فرض محلل معين باستخدام --profile-type cobaltstrike أو --profile-type sliver.

ماذا يفعل

بالنظر إلى ملف تعريف، يستخرج النص البرمجي ما يلي:

• سلسلة User-Agent
• URIs (لـ CS) أو بادئات مسارات (لـ Sliver)
• رؤوس جانب العميل (خاص بـ CS فقط — لا يحدد Sliver رؤوسًا معينة)
• رأس Host (يُستخدم كاسم نطاق المُوجّه إذا لم تمرر --server-name)
• هل تم تفعيل التجهيز (staging) (خاص بـ CS فقط — set host_stage)

ثم يُنشئ ملف Caddyfile يقوم بما يلي:

1. (اختياري) يُرجع رمز 403 لحركة مرور HTTP العادية
2. يمنع حوالي 15 وكيل مستخدم معروفًا (curl، nmap، sqlmap، Googlebot، إلخ)
3. يمنع الوصول عبر IP المباشر وأي طريقة HTTP ليست GET/POST
4. يُمرر عبر الوكيل العكسي فقط URIs الملف (أو البادئات لـ Sliver)، مقيدة بـ User-Agent المطابق
5. يمنع مسارات الماسحات الشائعة (.env، /wp-admin، .php، إلخ)
6. يُعيد توجيه كل شيء آخر إلى عنوان URL الوهمي

المتطلبات

• Python 3.7+ (يستخدم المكتبة القياسية فقط، لا حاجة لـ pip install)
• Caddy 2.x على جهاز المُوجّه نفسه (دليل التثبيت)

بداية سريعة

python3 caddysmith.py my.profile \
    --backend https://teamserver.internal:443 \
    --decoy   https://www.example.com/ \
    --server-name redirector.example.com \
    --email   [email protected] \
    --forbid-http \
    -o redirector.caddy

يكتب هذا التكوين المُنشأ إلى redirector.caddy ويطبع ملخصًا لما فعله إلى stderr.

نشر التكوين المُنشأ

الخيار أ: تشغيل ملف Caddyfile مباشرة

انسخ الملف المُنشأ إلى المُوجّه وقم بتشغيل Caddy عليه. تحتاج إلى العلم --adapter caddyfile لأن Caddy يستخدم تكوين JSON افتراضيًا:

caddy run --config /etc/caddy/redirector.caddy --adapter caddyfile

لإعادة تحميل نسخة قيد التشغيل بتكوين محدّث:

caddy reload --config /etc/caddy/redirector.caddy --adapter caddyfile

إذا حذّر Caddy من عدم تناسق التنسيق، قم بتنظيفها باستخدام:

caddy fmt --overwrite /etc/caddy/redirector.caddy

الخيار ب: استيراد من ملف Caddyfile رئيسي

ضع الملف في /etc/caddy/ واستورده من ملف Caddyfile الرئيسي:

# /etc/caddy/Caddyfile
import /etc/caddy/redirector.caddy

إذا مررت --email (مُوصى به)، فإن المقتطف المُنشأ يحتوي بالفعل على كتلة الخيارات العامة، لذا يحتاج ملف Caddyfile الرئيسي فقط إلى سطر import. إذا لم تمرر البريد الإلكتروني، أضفه يدويًا في كتلة { } فوق سطر الاستيراد.

ثم تحقق من الصحة وأعد التحميل:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

سيقوم Caddy بتوفير شهادة Let's Encrypt تلقائيًا للنطاق المحدد في --server-name طالما أن سجل A يُشير إلى المُوجّه.

جميع الخيارات

أوضاع السياسة

• strict (الافتراضي) — يتحقق من User-Agent وجميع رؤوس العميل، والوصول المباشر عبر IP، وطريقة HTTP، ومسارات الاستقصاء
• lax — يمنع فقط وكلاء المستخدم السيئين، بدون مطابقة رؤوس لكل مسار
• none — يُمرر أي طلب إلى URI في الملف، بدون تصفية

الوضع strict هو ما تريده عادةً. الوضع lax مفيد عند تصحيح الأخطاء لمعرفة سبب عدم اتصال البيكون الحقيقي.

مثال عملي

لنفترض أن لديك ملف تعريف يحاكي نقطة نهاية لـ Amazon وتريد نشره على redirector.0xtb.sh:

python3 caddysmith.py amazon.profile \
    --backend https://10.1.1.10:443 \
    --decoy   https://www.amazon.com/ \
    --server-name redirector.0xtb.sh \
    --forbid-http \
    --policy strict \
    -o /etc/caddy/redirector.caddy

سيظهر الملخص المسارات التي تم بناؤها، على سبيل المثال:

Routes built:   2
  - [profile-get] /broadcast
  - [profile-post] /1/events/com.amazon.csm.csa.prod

إذا قمت بإعادة التوليد ورأيت بدون مسارات، فمن المحتمل أن النص البرمجي فشل في تحليل ملف التعريف الخاص بك — تحقق من التحذيرات على stderr.

مثال لـ Sliver

لتكوين implant Sliver (JSON):

python3 caddysmith.py sliver-implant.json \
    --backend https://10.1.1.10:443 \
    --decoy   https://www.amazon.com/ \
    --server-name redirector.0xtb.sh \
    --email   [email protected] \
    --forbid-http \
    --policy strict \
    -o /etc/caddy/redirector.caddy

سيخبرك الملخص أنه تم اكتشاف Sliver ويعرض المسار بالبادئة:

Profile type:   sliver
Routes built:   1
  - [sliver] /api /public /resources /services /static (prefix)

لأن Sliver يُنشئ URIs عشوائيًا من مجموعات مسار × ملف × امتداد، فإن مطابق path المُنشأ يستخدم globs البادئة (path /api* /public* /resources* /services* /static*) بدلاً من المسارات الدقيقة. يستخدم مطابق User-Agent سلسلة فرعية من رقم بناء Chrome (مثل 3921.146)، والتي يحافظ عليها Sliver عبر إعادة كتابة UA الخاصة بكل منصة.

اختبارات سريعة بعد النشر

# يجب أن يُرجع HTTP العادي 403 (إذا استخدمت --forbid-http)
curl -I http://redirector.0xtb.sh/

# يجب أن يُعيد اسم المضيف المجرد التوجيه إلى الوهم
curl -kI https://redirector.0xtb.sh/

# يجب أن يُعيد UA السيئ التوجيه أيضًا
curl -kI -A "curl/8.4.0" https://redirector.0xtb.sh/broadcast

# طلب مع UA الصحيح والمسار يجب أن يُمرر (200)
# يجب أيضًا إرسال جميع رؤوس العميل الموجودة في الملف في الوضع strict.

القيود المعروفة

• لا يتم إنشاء قواعد التجهيز (staging) (Cobalt Strike). إذا كان ملف تعريف CS الخاص بك يحتوي على set host_stage "true" (أو لم يتم تعيينه على الإطلاق)، سيقوم النص البرمجي بالتحذير وتخطي URIs التجهيز. أضف set host_stage "false"; إلى ملف التعريف الخاص بك، أو مرر URIs التجهيز صراحةً عبر --extra-uri.
• مطابقة بادئات Sliver أوسع من المطابقة الدقيقة لـ CS. مع Sliver، يدّعي مسار الوكيل أي URL يبدأ بـ /api أو /static إلخ. سيتم إرسال مسح ضوئي للماسحات يستخدم هذه البادئات (مثل /api/.env) إلى خادم الفريق بدلاً من حظره محليًا — ولكن نقل HTTP الخاص بـ Sliver يصادق باستخدام معرف implant، لذا يتم رفض الطلبات غير المصرح بها على مستوى C2. لا يزال حاجز UA يبعد معظم الماسحات.
• خادم خلفية واحد لكل تشغيل. يتم توجيه جميع المسارات إلى نفس --backend. إذا كنت بحاجة إلى خوادم فريق متعددة، قم بتشغيل النص البرمجي عدة مرات وادمج يدويًا.
• تحليل URIs في الملف يعتمد على الأسطر (Cobalt Strike). set uri "/path1 /path2"; يعمل (مسارات متعددة في سطر واحد)، لكن التنسيق غير المعتاد قد يُعطل المحلل. تحقق من قائمة المسارات في الملخص للتأكيد.
• التحقق من شهادة الخادم الخلفي لـ HTTPS معطل افتراضيًا. عادةً ما تحتوي خوادم الفريق على شهادات ذاتية التوقيع، لذا يتضمن التكوين المُنشأ tls_insecure_skip_verify. إذا كان الخادم الخلفي لديه شهادة حقيقية، احذف هذا السطر من الملف المُنشأ.

الاعتمادات

كان Malleable-Redirector القائم على Apache هو نقطة البداية لما يُنشئه هذا النص البرمجي، بنفس نموذج URIs ثلاثي المسارات (URIs الملف / URIs الإضافية / URIs المخففة)، ونفس أوضاع السياسة، ونفس التخطيط العام. يقوم CaddySmith فقط بترجمة المخرجات إلى بناء جملة Caddy بدلاً من Apache .htaccess.

الرخصة

MIT