jconwell/secret_handshakeقناة C2 نموذجية لبرمجيات خبيثة تستخدم شهادات x509 عبر mTLS
أولًا، لماذا سأجعل هذا المشروع مفتوح المصدر؟
لا يتحدث MITRE ATT&CK إلا عن الشهادات المسروقة أو الموقعة ذاتيًا، وتمنح أنظمة كشف الشبكة والاستجابة (NDRs) (على حد علمي) اهتمامًا ضئيلًا جدًا بمحتوى شهادات x509 بخلاف الجهة المصدِرة (CA). بشكل عام، تُعتبر شهادات x509 موثوقة ويُسمح لها بالمرور عبر جدران الحماية لدينا دون رقابة. لكنها في جوهرها مجرد ملفات يمكن أن تحتوي بسهولة على حمولات خبيثة مثل أي ملفات أخرى. نحن نثق بها ونتجاهلها لأنها مكوّن أساسي في عملية التشفير التي اعتدنا أن نعتبرها أمرًا مسلمًا به. الهدف الأساسي من هذا المشروع هو رفع مستوى الوعي حول فئة من مؤشرات الأمان التي اعتدنا على الوثوق بها، وتسليط الضوء على الطرق التي يمكن استخدامها لكشف الاستخدامات الخبيثة لها.
كنت أتساءل دائمًا عما إذا كان الفاعلون الخبيثون قد استخدموا شهادات x509 كجزء من اتصالات C2 الخاصة بهم، ليس لتشفير حركة مرور الشبكة، ولكن لتضمين اتصالات C2 في شهادة x509 نفسها. بعد البحث عن شيء كهذا في البرية لمدة 5 سنوات، قررت أخيرًا أن أكتب الكود بنفسي لأرى ما إذا كان ذلك ممكنًا... وهو ممكن.
كل رسالة مشفرة تُرسل عبر HTTPS/TLS تصبح ممكنة بفضل نقل شهادة x509. عند إنشاء مصافحة TLS (الشكل أدناه)، في الخطوة الرابعة يرسل الخادم شهادته x509 إلى العميل. يتحقق العميل من الشهادة، ويقارن خوارزميات التشفير التي يدعمها الخادم، ويختار الخوارزمية التي سيستخدمها في جميع الاتصالات اللاحقة.
كما يوضح هذا الرسم البياني، هذا مجرد نقل باتجاه واحد لشهادة x509 من الخادم إلى العميل. وهذا لا يصلح جيدًا لاتصالات C2 لأنه لا توجد طريقة للعميل للرد على الخادم. في أفضل الأحوال، يمكن استخدامه فقط كآلية لنقل البيانات باتجاه واحد (انظر قسم الأعمال السابقة أدناه).
لكن هناك نوع آخر من جلسات TLS يسمى مصادقة TLS المتبادلة (mTLS)، حيث يتبادل كل من العميل والخادم شهادات x509 كوسيلة لمصادقة بعضهما البعض.
كما يوضح الشكل أعلاه، أثناء المصادقة المتبادلة، تُرسل شهادة x509 الخاصة بالخادم إلى العميل للمصادقة، ثم تُرسل شهادة x509 الخاصة بالعميل إلى الخادم للمصادقة. يمثل هذا التبادل للأصول فرصة لإنشاء قناة اتصال ثنائية الاتجاه لخوادم C2.
بما أن شهادتي الخادم والعميل يتم تبادلهما بواسطة مكتبة SSL الأساسية، فلا تتاح للعميل فرصة استخراج الرسالة من شهادة الخادم، وتنفيذ الأمر، وإنشاء شهادة استجابة داخل اتصال mTLS واحد. وهذا يعني أن قناة C2 تحتاج إلى تصميم بحيث يتم تبادل الطلب والرد عبر اتصالي TLS متبادلين مختلفين، تقريبًا مثل وضع إرسال شبه أحادي الاتجاه (pseudo-half duplex).
تتبع عملية الطلب/الرد الخطوات التالية:
بعد أن جعلت هذا يعمل، كنت فخورًا جدًا بنفسي لكوني مبتكرًا وكل ذلك.
ثم صادفت محاضرة BSides في 2018 لجيسون ريفز الذي كتب أداة إسقاط ثنائي للبرمجيات الخبيثة (malware binary dropper) باستخدام شهادات x509 عبر TLS. وبعد عام، نشر جيسون هذه الورقة البحثية التي توضح بالتفصيل قناة اتصال كاملة ثنائية الاتجاه باستخدام mTLS.
يتطلب mTLS أن تكون شهادات كل من العميل والخادم موقعة من نفس شهادة المرجع المصدق (CA)، لذا فإن الخطوة الأولى هي توليد زوج المفتاح الخاص / الشهادة الخاص بالمرجع المصدق الخاص بك.
إنشاء المفتاح الخاص للمرجع المصدق الجذر (Root CA):
openssl genrsa -des3 -out hmCA.key 2048
ملاحظة: ستمنع عبارة المرور أي شخص يحصل على مفتاحك الخاص من توليد شهادة جذر خاصة به.
إنشاء شهادة المرجع المصدق الجذر (Root CA):
openssl req -x509 -new -nodes -key hmCA.key -sha256 -days 1825 -out hmCA.pem
انسخ ملفات المفتاح والشهادة المولدة إلى مجلد certs/ca_certs. يأتي المشروع مع زوج مفتاح/شهادة تجريبي، لذا يمكنك تخطي هذه الخطوة إذا أردت.
تشغيل العميل:
python client.py
تشغيل الخادم:
python server.py
لا أريد أبدًا إصدار أي شيء يحتمل أن يكون خبيثًا دون توضيح كيفية اكتشافه في سجلات شبكتك.
قد تظن أن اكتشاف هذا النمط من TLS سيكون سهلًا، لكن الأمر ليس بهذه البساطة. من أهم مؤشرات قناة C2 هذه أسلوب الاتصال شبه أحادي الاتجاه (half-duplex)؛ إذ يتطلب الأمر تدفقَي مصادقة متبادلة لإكمال طلب/رد كامل بين الخادم والعميل. وسيتكرر هذا عدة مرات بينما يرسل الخادم أوامر مختلفة إلى العميل.
هذا يعني أنه يجب عليك البحث عن:
يبدو هذا كمجموعة قواعد كشف محكمة، لكن كما قلت سابقًا، الأمر ليس بهذه السهولة. فقد اتضح أن هناك مجموعة من الخدمات المؤسسية التي لديها أيضًا نمط حركة مرور mTLS مشابه، بما في ذلك:
يبدو أن العديد من هذه الخدمات هي خدمات إدارة أصول/أجهزة، لذا من الناحية النظرية يجب أن ترسل نفس مجموعة الشهادات في كل مرة تمر فيها على جميع أجهزتها. يمكنك التحقق مما إذا كانت هناك مجموعات من جلسات mTLS متعددة تتكرر كل N ساعة، ثم معرفة ما إذا كانت تجزئات الشهادات بين مجموعتين مختلفتين من جلسات mTLS متطابقة أو متطابقة في معظمها. كذلك، ابحث عن احتمال اختلاف شهادات العميل لكل جلسة mTLS، مع بقاء نفس شهادة الخادم عبر جميع الجلسات.
يعد فحص SSL (SSL inspection) إحدى الطرق التي قد تحجب هذا النوع من قنوات اتصال C2، لأن خادم فحص SSL لن يمتلك شهادة المرجع المصدق (CA) الخبيثة اللازمة لمصادقة شهادة العميل.
