Thread by @AshAbdalhalim

لا أكاد أذكر حادثة من الحوادث الأمنية التي عملت عليها و لم يُستخدم فيها webshell في مرحلة من المراحل، خصوصاً الحوادث التي عملت فيها في منطقتنا (الشرق الأوسط). مجموعة تغريدات عن الـ webshells و أفكار لصيدها (hunting). #threathunting #dfir

الـ webshell عبارة عن malware في شكل script يستهدف الـ web servers (غالباً التي يمكن الوصول إليها من الإنترنت) و يدعم مجموعة من العمليات يستفيد من المهاجم مثل: نقل ملفات/بيانات من و إلي الـنظام، تنفيذ أوامر، عمل tunnels، و هلم جرا...

الـ webshells تستخدم في أكثر من مرحلة من مراحل الهجوم (attack life cycle) مثل:
— Initial Foothold: بعد ايجاد ثغرة تمكن من رفع ملفات علي web server، المهاجم قد يستعمل الثغرة لتحميل webshell علي الخادم مما يعطيه موضع قدم منه يكمل.

— Privilege Escalation: العمليات التي تتم عن طريق الـ webshell تأخذ الصلاحيات المعطاة للـ account المستخدم لتشغيل الـ web service. المخترق سيستفيد من الصلاحيات التي تعمل بها الـ web service، فإذا كانت عالية (مع معظم الأوقات هي كذلك)، يحقق المخترق EoP بإستخدام الـ webshell.

— Lateral Movement: بعض انواع الـ webshell تدعم خاصية الـ tunneling و عن طريقها يمكن استعمال النظام لوصول لنظم أخري في الشبكة.

— Persistence: تستخدم الـ webshells أيضاً لتأمين نقاط وصول ثانوية إلي الشبكة في حال تم إكتشاف الطريقة الأولي للوصول إلي الشبكة. و الميزة فيها أنها passive و لا يوجد traffic/beaconing عندما تكون غير مستخدمة.

— Exfiltration: كما ذكرنا، الـ webshells تدعم عمليات تنزيل البيانات من النظم لذا أراها تستعمل لسحب البيانات المسروقة من الأهداف.

الآن بعض الأفكار لصيدها عندك في البيئة المسئول عن حمايتها. هنالك طريقتان أساسيتان:
١/ بإستعمال علامة معينة (signature) تتعلق بالـ webshell نفسه.
٢/ بإستعمال علامات لا تتعلق بالـ webshell نفسه مثل:
— file system metadata
— web service logs
— system process logs

الطريقة الأولي تحتاج مسبق معرفة بالـ webshell الذي تحاول تصيده. الثانية، لا! وهي عندي الأقوي و لأنها تمكنك من تصيد حتي ما لا تعرف عنه من قبل و تعتمد علي مصادر أقل قرباً من المهاجم (المهاجم له كامل التحكم في محتوي الـ webshell).

المحارب الصح (الذي هو أنت🙌🏽) لا يجب أن يعتمد في حربه علي ما يتحكم فيه خصمه بل ما يتحكم به هو! المصادر المستعملة في الطريقة الثانية هي تحت سيطرتك إستفد منها.

الطريقة الأولي تقوم علي تحليل الـ webshell و تحديد علامة مميزة للتعرف عليه (signature)، غالباً ما تكون keyword في الـ webshell. ثم البحث في محتوي الملفات الموجودة في wwwroot (أو أياً كان المكان الذي يوجد فيه الملفات التي يمكن الوصول إليها عن طريق الـ web service) عن أي مطابقة.

الطريقة الثانية:
١/ قم بتجميع الـ metadata للملفات التي يمكن الوصول إليها عن طريق الـ web service في الخوادم المكشوفة علي الإنترنت، جمع الـ timestamps و inode و owner. معظم الملفات ستكون منشأة في أوقات متشابهة و متسلسلة (أثناء التنزيل، النقل أو التحديث للنظام/التطبيق/الموقع).

إبحث عن الملفات التي أنشئت في أوقات لا تتشابهة مع الأوقات المذكورة سابقاً أو عند طريق مستخدم غير الذي أنشأ باقي الملفات المعتمدة أو أن الـ inode ليست قريبة تسلسلياً من تلك الخاصة بالملفات المعتمدة. الملف صاحب الخصائص النشاز (outlier) يحتاج أن تتحقق منه.

٢/ جمع الـ access logs الخاصة بالـ web service. في هذه الـ logs ستجد معلومات مثل الملفات التي تم الوصول إليها عن طريق الـ web service و الوقت و الـ response code و الـ User Agent و الـ IP الخاص بالمستخدم (إذا لم يكن هناك reverse proxy).

إعمل stacking للملفات التي تم طلبها و راجع الملفات صاحبة أقل عدد طلبات. راجع الـ UA و إبحث عن الـ UA المتعلقة بـ Linux، قليل ما تلاقي مستخدم لموقع أو خدمة يستخدم Linux في تصفح الا قليل ممن تحب تعرفهم 😉.

إبحث عن الملفات بإمتدادات غريب أن تراها تطلب عن طريق الـ web service مثلاً .txt. إبحث أيضاً عن الطلبات تسببت في 404 و راجعها (واحد بيطلب ملف بكتابته يدوياً و أخطأ). إبحث عن طلبات من أماكن (IPs) لا تتوقع منها طلبات. لتحليل الـ access logs أداة مثل Log Parser ح تساعدك كثير.

٣/جمع الـ process creation logs من (Windows EID 4688 أو Sysmon EID 1) و إبحث في الـ processes التي أنشأتها الـ web service process و خصوصاً عن البرامج التي يمكن أن تستخدم لتنفيذ أوامر أو تشغيل scripts... حاجة زي...

(parent process name is w3wp.exe OR httpd.exe) AND (process name is cmd.exe OR powershell.exe OR wmic.exe OR cscript.exe OR wscript.exe)

Happy Hunting!