هل من الممكن أن تدافع بالكامل ضد الهجمات الإلكترونية؟ ربما ، يمكنك ، إذا كنت تحيط نفسك بكل وسائل الحماية الحالية واستأجرت فريقًا ضخمًا من الخبراء لإدارة العمليات. ومع ذلك ، فمن الواضح أنه في الواقع هذا مستحيل: ميزانية أمن المعلومات ليست لانهائية ، ومع ذلك ستحدث الحوادث. وبما أنهم سيحدثون ، فأنت بحاجة إلى الاستعداد لهم!
في هذه المقالة ، سنشارك سيناريوهات نموذجية للتحقيق في حوادث البرامج الضارة ، ونخبرنا بما يجب البحث عنه في السجلات ، ونقدم توصيات تقنية حول كيفية تكوين أدوات حماية المعلومات لزيادة فرص نجاح التحقيق.
تتضمن العملية الكلاسيكية
للاستجابة لحادث مرتبط بالبرامج الضارة مراحل مثل الاكتشاف ، والاحتواء ، والاسترداد ، وما إلى ذلك ، ومع ذلك ، يتم تحديد جميع قدراتك ، في الواقع ، في مرحلة الإعداد. على سبيل المثال ، يعتمد معدل اكتشاف الإصابات مباشرةً على مدى جودة التدقيق في الشركة.
دورة الاستجابة لحوادث SANS الكلاسيكية
بعبارات عامة ، تصرفات المحللين أثناء التحقيق هي كما يلي:
- إنشاء إصدارات تشرح أسباب الحادث (على سبيل المثال ، "تم تثبيت البرامج الضارة على المضيف لأن المستخدم أطلقها من رسالة بريد إلكتروني تصيّد" أو "الحادث إنذار خاطئ لأن المستخدم زار موقعًا شرعيًا يقع على نفس الاستضافة مثل خادم الإدارة البرامج الضارة ").
- تحديد أولويات الإصدارات حسب درجة الاحتمال. يتم احتساب الاحتمال (ولكن التظاهر بالأحرى) استنادًا إلى إحصائيات الحوادث السابقة ، وخطورة الحادث أو النظام ، وأيضًا بناءً على التجربة الشخصية.
- دراسة كل نسخة ، والبحث عن الحقائق التي تثبت أو تدحض.
بالطبع ، لا يوجد أي معنى في اختبار جميع الفرضيات الممكنة - على الأقل لأن الوقت محدود. لذلك ، سنلقي نظرة هنا على الإصدارات الأكثر احتمالا والسيناريوهات النموذجية للتحقيق في حوادث البرمجيات الضارة.
السيناريو 1
تشك في أن نظامًا غير مهم قد تعرض للاختراق بسبب البرامج الضارة. نظرًا للطبيعة غير الحرجة للنظام ، فقد تم تخصيص القليل من الوقت للتحقق.
أول شيء يقوم به معظم مهندسي الاستجابة هو إجراء فحص مضاد للفيروسات. ومع ذلك ، كما نعلم ، فإن مكافحة الفيروسات ليست صعبة للغاية للالتفاف. لذلك ، يجدر إنشاء الإصدار المحتمل للغاية التالي والعمل به: البرامج الضارة هي ملف قابل للتنفيذ منفصل أو خدمة.
كجزء من تطوير هذا الإصدار ، هناك ثلاث خطوات بسيطة لمتابعة:
- قم بتصفية سجل الأمان حسب الحدث 4688 - حتى نحصل على قائمة بجميع العمليات التي بدأت.
- قم بتصفية سجل النظام حسب الحدث 7045 - حتى نحصل على قائمة عمليات التثبيت لجميع الخدمات.
- حدد العمليات والخدمات الجديدة التي لم تكن موجودة سابقًا في النظام. انسخ هذه الوحدات وقم بتحليلها بحثًا عن تعليمات برمجية ضارة (قم بمسحها باستخدام العديد من برامج مكافحة الفيروسات ، تحقق من صحة التوقيع الرقمي ، أو قم بفك الشفرة ، إلخ).
قائمة بجميع العمليات والخدمات قيد التشغيل في Event Log Explorer
من الناحية النظرية ، هذه عملية تافهة إلى حد ما. ومع ذلك ، في الممارسة العملية هناك عدد من المزالق التي يتعين إعدادها.
أولاً ، لا يقوم إعداد تدوين Windows القياسي بتسجيل حقائق بدء العملية (الحدث 4688) ، لذلك يجب تمكينه مسبقًا في سياسة مجموعة المجال. إذا حدث أن هذا التدقيق لم يتم تضمينه مقدمًا ، فيمكنك محاولة الحصول على قائمة بالملفات القابلة للتنفيذ من عناصر Windows الأخرى ، على سبيل المثال ، من سجل
Amcache . يمكنك
استخراج البيانات من ملف التسجيل هذا باستخدام الأداة المساعدة
AmcaheParser .
مثال على استخراج حقائق بدء العمليات من Amcache.hve
ومع ذلك ، هذه الطريقة غير موثوقة للغاية ، لأنها لا توفر معلومات دقيقة حول متى وعدد المرات التي بدأت فيها العملية بالضبط.
ثانياً ، لن يكون الدليل على إطلاق العمليات مثل
cmd.exe و powershell.exe و wscript.exe وغيره من المترجمين الفوريين ذا فائدة قليلة دون معلومات حول سطر الأوامر الذي بدأت به العمليات ، لأن أنه يحتوي على المسار إلى ملف نصي يحتمل أن تكون ضارة.
تشغيل مترجم البرنامج النصي بدون معلومات حول البرنامج النصي الذي تم تشغيله
ميزة أخرى لـ Windows هي أن تدقيق سطر الأوامر للعملية التي تم إطلاقها يتم عن طريق تكوين منفصل لسياسة مجموعة المجال:
تكوين الكمبيوتر -> السياسات -> قوالب الإدارة -> النظام -> إنشاء عملية التدقيق -> تضمين سطر الأوامر في أحداث إنشاء العملية . في الوقت نفسه ، لا يقوم نظام التشغيل Windows
7/2008 المشهور إلى
حد ما بتسجيل سطر الأوامر دون
تثبيت التحديث
KB3004375 ، لذلك ضعه مقدمًا.
إذا حدث ذلك أنك لم تقم بتكوين أي شيء مسبقًا أو نسيت التحديث ، فيمكنك محاولة معرفة موقع البرنامج النصي في ملفات
الجلب المسبق (
أداة مساعدة للمساعدة ). تحتوي على معلومات حول كافة الملفات (بشكل أساسي DLLs) التي تم تحميلها في العملية في أول 10 ثوانٍ من العمر. والبرنامج النصي الموجود في وسيطات سطر الأوامر للمترجم الفوري سيكون بالتأكيد موجودًا هناك.
مثال على العثور على وسيطة سطر الأوامر "المفقودة" في الجلب المسبق
ولكن هذه الطريقة غير موثوقة على الإطلاق - في المرة التالية التي تبدأ فيها العملية ، سيتم الكتابة فوق ذاكرة التخزين المؤقت للتجربة المسبقة.
التحضير للتحقيق:
- تشمل مراجعة متقدمة لإنشاء وإنجاز العمليات.
- تمكين عملية تسجيل وسيطة سطر الأوامر.
- قم بتثبيت التحديث KB3004375 على نظام التشغيل Windows 7 / Server 2008.
السيناريو 2
تم تسجيل الوصول إلى خادم إدارة البرامج الضارة على جهاز التوجيه المحيط. تم الحصول على عنوان IP الخاص بالخادم الضار من اشتراك استخبارات تهديد الأمان المتوسط.
في
أحد مقالاتنا السابقة ، قلنا إن محللي TI يخطئون عن طريق إضافة قوائم مؤشرات عناوين IP التنافسية للخوادم التي تستضيف مراكز التحكم في البرامج الضارة والمواقع الشرعية في نفس الوقت. إذا بدأت للتو في صياغة عمليات الاستجابة ، فمن الأفضل في المراحل الأولى التخلي عن استخدام هذه المؤشرات ، لأن كل محاولة من قبل المستخدم للدخول إلى موقع شرعي ستبدو وكأنها حادثة كاملة.
يمكن تقليل أحد خيارات الاستجابة لهذه الإنذارات إلى التحقق من العملية التي أجريت الاتصال - إذا كان متصفح الإنترنت ، ثم في حالة عدم وجود حقائق أخرى تشير إلى حل وسط ، يمكن اعتبار الحادث إنذارًا خاطئًا.
هناك العديد من الطرق لاكتشاف العملية التي بدأت الاتصال: يمكنك تشغيل
netstat ومشاهدة مآخذ التوصيل الحالية أو تجميع ملف تفريغ للذاكرة ثم تعيين
التقلبات عليه ، والتي يمكنها أيضًا إظهار الاتصالات المكتملة بالفعل. لكن كل هذا طويل وغير قابل للتطوير والأهم من ذلك - لا يمكن الاعتماد عليه. يعد الحصول على جميع المعلومات الضرورية من سجل أمان Windows أكثر موثوقية.
ارتباط حدث "الوصول إلى عنوان IP الضار" في نظام HPE Arcsight SIEM والعملية المقابلة في سجل أمان Windows
إعداد التحقيق
لحل هذا السيناريو على جهاز المستخدم ، يجب تمكين تسجيل جميع اتصالات الشبكة إلى سجل الأمان. يمكن القيام بذلك بناءً على أحداث
التدقيق في
نظام الترشيح ومراجعة إسقاط الحزمة .
في الوقت نفسه ، يمكن أن تبدأ المجلة في الانسداد بسرعة ، وبالتالي زيادة حجمها إلى 2-3 غيغابايت. في تجربتنا ، على مضيف مستخدم عادي ، هذا المبلغ يكفي لمدة 3 أيام لتسجيل جميع المقابس ، وهذه الفترة كافية لإجراء تحقيق ناجح.
على الخوادم المحملة بدرجة عالية ، مثل وحدات التحكم بالمجال ، وخوادم الويب ، وما إلى ذلك ، يجب ألا تفعل ذلك ، فسوف يتدفق السجل بشكل أسرع.
السيناريو 3
يشير نظام الكشف عن الحالات الشاذة NG / ML / Anti-APT إلى أن 30 مضيفًا يستكشفون للحصول على نفس الحسابات.
عندما يدخلون شبكة جديدة ، يحاول المهاجمون عادة معرفة الخدمات الموجودة فيها والحسابات المستخدمة - وهذا يساعد كثيرًا في عملية مزيد من الحركة على طول البنية التحتية. على وجه الخصوص ، يمكن الحصول على هذه المعلومات من Active Directory نفسه باستخدام الأمر
net user / domain .
إذا تم تنفيذ معلومات استخبارية محتملة من مضيف واحد ، فيمكن التحقيق فيها ، بما في ذلك استخدام سجلات العمليات الجارية. ومع ذلك ، إذا كان هناك العديد من المضيفين ، والهجمات من نفس النوع (حدثت في نفس الوقت ، أو تم طلب نفس المجموعة من الكيانات من م) ، فمن المنطقي أولاً وقبل كل شيء استبعاد إيجابية خاطئة نموذجية. للقيام بذلك ، قم بإنشاء الإصدارات التالية والتحقق منها:
- تم إصلاح الذكاء على 30 مضيفًا لنفس كائنات AD لأن المستخدم الشرعي net ، المسؤول ، أطلق الأمر net .
- تم إصلاح الذكاء على 30 مضيفًا لكائنات AD نفسها ، لأنه صنع نفس البرنامج الشرعي.
سيساعد التحليل الإحصائي للسجلات في العثور على هذه النقاط العقدية (مستخدم مشترك أو عملية). لقد أظهرنا هذه الطريقة في مقال سابق كما هو مطبق على
سجلات خادم DNS . ومع ذلك ، لا يمكن استخدام طرق التحقيق الفعالة هذه إذا لم يتم تنظيم تخزين البيانات مسبقًا.
إعداد التحقيق
من الضروري تنظيم تخزين طويل الأجل للبيانات التالية على الأقل من سجلات خدمات الشبكة المشتركة:
- وحدات تحكم المجال - المدخلات ونواتج الحسابات وإصدار تذاكر Kerberos (فئة تسجيل الدخول إلى الحساب في إعدادات التدقيق المتقدمة).
- الوكلاء - العناوين ، ومنافذ الخادم المصدر والخارجي ، وكذلك عنوان URL الكامل.
- خوادم DNS - استعلامات DNS الناجحة وغير الناجحة ومصدرها داخل الشبكة.
- أجهزة التوجيه المحيطة - بنيت و Teardown لجميع اتصالات TCP / UDP ، وكذلك الاتصالات التي تحاول كسر قواعد الوصول المنطقي: على سبيل المثال ، يحاول إرسال استعلام DNS إلى الخارج مباشرة ، وتجاوز خادم DNS للشركات.
السيناريو 4
تم اختراق مجالك ، وتشعر بالقلق من احتمال حصول مهاجم على موطئ قدم في البنية التحتية باستخدام تقنية DCShadow.
لنفترض أن شيئًا فظيعًا قد حدث: تجد أن حساب مسؤول المجال قد تم اختراقه.
تتضمن الاستجابة لمثل هذه الحادثة طبقة كبيرة جدًا من العمل ، بما في ذلك تحليل جميع الإجراءات التي ارتكبت من تحت هذا الحساب. يمكن إجراء جزء من هذا التحقيق باستخدام سجلات وحدة تحكم المجال فقط. على سبيل المثال ، يمكنك دراسة الأحداث المرتبطة بإصدار تذاكر Kerberos لفهم من أين ذهبت من خلال هذا الحساب. أو يمكنك تحليل الأحداث المرتبطة بتغيير كائنات AD الحرجة للتحقق من تغير تكوين المجموعات ذات الامتيازات العالية (نفس مسؤولي المجال). بطبيعة الحال ، كل هذا يتطلب مراجعة تم تكوينها مسبقًا.
ومع ذلك ، هناك مشكلة في قيام مهاجم لديه حقوق مسؤول المجال بتعديل كائنات AD باستخدام تقنية DCShadow ، التي تستند إلى آلية النسخ المتماثل بين وحدات التحكم بالمجال.
جوهرها هو أن المهاجم نفسه يبدو أنه وحدة تحكم مجال ، ويقوم بإجراء تغييرات على م ، ثم ينسخ (يزامن) هذه التغييرات مع وحدات تحكم شرعية ، وبالتالي يتجاوز مراجعة تغييرات الكائن التي تم تكوينها عليها. قد تكون نتيجة هذا الهجوم إضافة مستخدم إلى مجموعة من مسؤولي المجال أو روابط أكثر صرامة عن طريق تغيير سمة
محفوظات SID أو عن طريق تعديل كائن
ACS AdminSDHolder .
من أجل التحقق من الإصدار حول وجود تغييرات غير ملتزم بها في م ، تحتاج إلى دراسة سجلات النسخ المتماثل وحدة تحكم: إذا كانت عناوين IP بخلاف وحدات تحكم المجال متورطة في النسخ المتماثل ، يمكنك القول بثقة عالية أن الهجوم كان ناجحا.
إزالة وحدة تحكم مجال غير معروفة من النسخ المتماثل مالتحضير للتحقيق:- للتحقيق في الإجراءات التي يرتكبها حساب مخترق ، يجب عليك تضمين ذلك مسبقًا:
- للتحقيق في الإصدارات المتعلقة بهجمات DCShadow المحتملة:
- تمكين التدقيق المطوّل للنسخ المتماثل لخدمة الدليل .
- تنظيم تخزين طويل الأجل للأحداث 4928/4929 ، حيث مصدر الحدث ليس وحدة تحكم مجال مشروعة (سمة DCShadow).
الخاتمة
في هذه المقالة ، تحدثنا عن بعض السيناريوهات النموذجية للتحقيق في حوادث أمن المعلومات وإجراءات الاستعداد الوقائي. إذا كنت مهتمًا بهذا الموضوع وكنت على استعداد للمضي قدمًا ، نوصيك بالاهتمام
بهذا المستند ، الذي يصف أحداث Windows التي يمكنك العثور على آثار لاستخدام أساليب القرصنة الشائعة فيها.
أود أن أنهي باقتباس من دراسة حديثة لشركة الأمن السيبراني:
"بالنسبة للجزء الأكبر ، يميل مدراء أمن المعلومات الروس إلى إعطاء إجابات متشائمة [لأسئلة البحث]. وبالتالي ، فإن نصف (48 ٪) يعتقدون أن الميزانية لن تتغير بأي شكل من الأشكال ، ويعتقد 15 ٪ أن التمويل سوف يتم تخفيض ".
بالنسبة لي شخصياً ، هذه إشارة إلى أن الميزانية المتبقية في العام الجديد من الأفضل إنفاقها ليس على شراء SZI من الطراز الجديد مثل كاشفات التعلم الآلي ، ومعرفات أخرى من الجيل التالي ، وما إلى ذلك ، ولكن على صقل تلك SZI الموجودة بالفعل. وأفضل SZI تم تكوين سجلات Windows بشكل صحيح. IMHO.