مأزق: كيف كان

تحية! بعد أن رأينا الاهتمام الكافي بما يحدث في The Standoff بين المدافعين في PHDays 9 ، قررنا أن نتحدث عن كيفية حدوث الاستعدادات و "المواجهة" نفسها من خلال عيون Jet CSIRT كجزء من Jet Security Team.

قوه مأزق ، أنا خلقت

شيء من هذا القبيل ، ذكر الزملاء أننا نشارك مرة أخرى في "المواجهة" ، وقد اتفقنا بشكل طبيعي.

تجدر الإشارة على الفور إلى أن شكل المسابقة قد تغير إلى حد ما بالنسبة للمدافعين هذا العام. تلقت جميع الفرق بنية تحتية متشابهة جدًا ، مما أتاح للمنظمين إدخال تصنيف للمدافعين في بعض الببغاوات. وبالنسبة لفريق Jet Security ، كان هذا أول "مواجهة" ، حيث تم الدفاع عن المكتب ، وليس البنية التحتية الصناعية.

وصلنا إلى البنية التحتية للإعداد للمعركة الإلكترونية في أواخر أبريل. بعد مراجعة البنية التحتية ، تم تجميع مجموعة كاملة من أوجه القصور ، وهنا فقط بعض منها. تماما في جميع أنحاء البنية التحتية لم تكن هناك تصحيحات الفعلية. يمكن الحصول على كلمات مرور جميع المستخدمين من خلال Ntds.dit بنص واضح. علاوة على ذلك ، كان لدى بعض المستخدمين كلمات مرور من قائمة TOP-500 أو كلمات المرور ذات علامة تجزئة يمكن عكسها بسهولة. كان نظام تصلب قريبة من لا شيء أو لا شيء على الإطلاق. كان لبعض المضيفين في DMZ واجهة في الشبكة الفرعية للخادم.

استنادًا إلى نتائج التدقيق ، وضعنا بعض التدابير الأمنية ، بدوره ، سمح لنا المنظمون ، بعد الحصول على موافقة مبدئية ، بتطبيق السياسات التي نحتاجها وتقديم أي أدوات وأدوات أمنية يمكن نشرها في بيئة افتراضية. بسبب ضيق المواعيد ، سقطت بعض الأفكار حول تدابير الحماية في البداية. تم تنفيذ الإعدادات والتوصيفات الأساسية لـ SPI خلال عطلات مايو (مرحبًا بكل من ألقوا صورًا من أماكن النزهات ، نحن نحبك أيضًا) ، وكان لا بد من ضبط بعض المعدات الواقية قبل البدء مباشرة على الموقع. أيضا ، تم منع عدد من الخدمات لتصحيح وإعادة تكوين بقوة. على سبيل المثال ، واحدة من هذه كانت Oracle Weblogic مع CVE-2019-2725 ، والذي صدر PoC في الأيام الأولى من مايو 2019.

حسنًا ، وقائمة ما جلبناه معنا:

• جدار الحماية (المقدم من قبل المنظمين تم استبداله) ؛
• حل مكافحة الفيروسات.
• WAF.
• EDR.
• اثنين من حلول الخداع.
• زوج من الماسحات الضوئية الضعف.
• مكدس ELK لتحليل Netflow إضافي ؛
• SIEM.

يجب أن نتحدث أيضًا عما كان سيذهب إلى SIEM. كمصادر للأحداث ، كان لدينا تحت تصرفنا سجلات Windows وسجلات Sysmon و Auditd ، وكما تعتقد ، أحداث من SZI نفسها. إذا لم تكن هناك مشاكل خاصة في الأولين ، واتفقنا بسرعة على التغييرات في سياسة Sysmon والتكوين ، فكان علينا أن نتصارع مع المنظمين لتهيئة Auditd.

بالتوازي مع هذا ، حددنا متجهات الهجوم الرئيسية ، وبناءً على ذلك قمنا باختيار وتكييف السيناريوهات وقواعد الارتباط ذات الصلة - أي ما مجموعه حوالي 160 من قواعد الارتباط. بالإضافة إلى ذلك ، تم تجميع مجموعة من لوحات معلومات motley للعُقد الحرجة و SZI وما يتطلب اهتمامًا خاصًا في البنية الأساسية للألعاب.

المواجهة

بالنسبة لـ "المواجهة" ، قررنا الالتزام بمفهوم فصل الحوادث إلى خارجية وداخلية ، حيث كان هناك فهم دقيق أننا في الخارج سنحاول بنشاط مسح الويب وتشغيله. تم رصد الحوادث المتعلقة بالمسح الضوئي ومحاولات الالتفاف على WAF بشكل منفصل ، على أولوية أقل ، مما سمح لنا بالتركيز على الحوادث الداخلية. تم توزيع لوحات معلومات SPI بين المدافعين في مناطق المسؤولية ، وتم تعيين شخصين على الأقل لكل أداة - لإمكانية الدوران والراحة.

حدث كل شيء ، كما توقعنا. بدأت المواجهة في حوالي الساعة 10 صباحًا ، وبمجرد البدء ، بدأ نظام SIEM في إعطاء مجموعة من الحوادث المتعلقة بالمسح الخارجي ومحاولات المهاجمين لاستغلال الويب. في بعض الحالات ، حتى المجموعة لم ينقذ. إلى جانب هذا ، بدأ المدققون المنظمون العمل ، والتحقق من حالة مختلف الخدمات في المكتب ، مما اضطرنا إلى إعادة إجراء التنميط إلى حد ما لقطع الايجابيات الكاذبة المرتبطة بها.

في الساعات الأولى من اللعبة ، تمكن فريق Hack.ERS من العثور على بيانات الاعتماد القياسية من المسؤول (admin / admin) على CMS لأحد الموارد واكتشاف ثغرة أمنية محتملة في LFI. لم تمر هذه المحاولات دون أن يلاحظها أحد ، فقد نفذ المدافعون ردا تنفيذيا ، ولم يتمكن المهاجمون في النهاية من التقدم أكثر.

حتى نهاية اليوم الأول من اللعبة ، لم تتغير الأساليب ، ما زالت WAF تغلبت على كل محاولات تحميل شيء مثير للاهتمام على مواقع الشركة ، وحاولت "العناوين الخارجية" نفسها ، دون توقف ، فحص مواردنا.



في المجموع ، للحدث بأكمله ، تم تسجيل 3000 حادث مرتبط بمحاولات المسح ، دون مراعاة تجميع الأحداث في الحوادث.



وحوالي 2500 حادث مع محاولات للتحايل على WAF ، أيضًا دون مراعاة تجميع الأحداث في الحوادث.

نحو الليل ، انخفضت كثافة جميع الأنشطة - كانت هناك عدة أسباب لذلك. جزء من المدافعين والمهاجمين لم يتمكنوا من مقاومة فحص الصوت والبروفة للحفل الموسيقي ، الذي كان من المفترض أن يعقد في اليوم التالي. قررت بعض الفرق المهاجمة أخذ قسط من الراحة واستمرار الهجمات في نهاية الصباح على أمل أن يكون لدى المدافعين والرصد موارد مراقبة أقل وبعض التعب.

في صباح اليوم الثاني ، غير المهاجمون التكتيكات. تم نشر المعلومات الخاصة بجزء من موظفيها على أحد مواقع الشركة الإلكترونية. استغل المتسللون هذه المعلومات وبدأوا بنشاط في جمع حسابات المستخدمين من خلال Exchange (إحصائيات المحاولات في لقطة الشاشة).



بعد ذلك بقليل ، بذلت محاولات غير آمنة لاختيار كلمة مرور على بوابة VPN ، والحسابات التي لم تكن في بنيتنا الأساسية شاركت في الغاشمة. مع الاحتمال الكبير ، حاول المهاجمون استخدام حسابات من البنية التحتية التي تم اختراقها بالفعل على أمل أن يتركها المنظمون كما هي في كل مكان. نتيجة لذلك ، دفعنا الموقف برمته باستخدام القوة الغاشمة إلى إنشاء مجموعة من لوحات المعلومات على الاتجاهات من حيث مصادقة المستخدم. بالإضافة إلى ذلك ، قمنا بتشديد المراقبة على الحوادث المتعلقة بالقوة الغاشمة الناجحة ، لكن لحسن الحظ ، لم يتم اكتشاف مثل هذه الحالات.

قبل ما يقرب من ساعة واحدة من نهاية اللعبة ، تم ملاحظة محاولات ناجحة واحدة لمصادقة العديد من المستخدمين ، بما في ذلك في Exchange ، في الاتجاهات ، وأظهر التحليل التشغيلي أن المصادر كانت عبارة عن أجهزة مستخدمين مباشرة ، حيث أشارت معظم الأحداث إلى أن المنظمين قاموا بتسجيل الدخول من وحدة VMware Vcenter.

في الوقت نفسه ، سجلنا فحصًا داخليًا من عقدة متصلة بنجاح عبر VPN. بعد إجراء تحليل تشغيلي للأحداث المتعلقة بالحادث ، أصبح من الواضح أن المهاجمين كانوا قادرين على اختراق بيانات اعتماد العديد من المستخدمين ، والحكم على غياب محاولات المصادقة غير الناجحة ، فمن المحتمل أن "بيانات المستخدم" قد "تسربت".

تم نقل المعلومات إلى المدافعين. خلال وقت الاستجابة الكامل على أجهزة الكمبيوتر الشخصية للمستخدمين المعرضين للخطر ، تم وضع حل نقطة النهاية في وضع الحماية الوقائية لإبطاء القدرة على الحصول على موطئ قدم في النظام. تم إسقاط جلسات الهجوم على بوابة VPN بالقوة ، وتم طرد المهاجمين من المحيط المحمي. في UZ للخطر ، تم تغيير كلمات المرور على الفور.

في تلك اللحظة بالذات ، استولى شباب فريق True0xA3 على المسرح واستخدموا OSINT بنجاح وأبلغوا عن حل وسط لمكتب Behealthy ، الذي يخضع لحماية فريق آخر. تمكن المهاجمون من اختراق مسؤول المجال. تم إخطار المنظمين بحادثنا وتم تقديم أدلة.

كانت الساعة الأخيرة ساخنة بشكل خاص بسبب OSINT المفاجئ ، وكان الجميع ينتظرون بعض الاستعدادات من المنظمين. وقام فريق المراقبة بدوره بمراقبة جميع الحالات الشاذة والحوادث المشبوهة ، ولكن بعد محاولة فاشلة لاختراق محاولات القرصنة الجديدة ، لم يتبع ذلك. إذن مرت الدقائق الأخيرة من وقت اللعب ، ولم يحدث القرصنة الناجحة للمكتب المحمي بواسطة فريق Jet Security.

وإحصائيات نهائية صغيرة ليومين من الألعاب:

• 1200 ربحية في المتوسط ​​وأقل بقليل من 3000 ربحية في الذروة ؛
• حوالي 7000 حادث ؛
• أكثر من 120 مليون حدث.

العوامل التي ساعدتنا على الفوز

• توزيع كفء للأدوار. كل إعداد وشارك في معظم ما يفعله في المشاريع اليومية. لم يضطر أحد إلى دراسة مواد من فئة "جدار الحماية للدمى".
• التنميط التشغيلي لقواعد الارتباط. تمت معالجة جميع الإيجابيات الخاطئة وإجراء تصحيحات تتعلق بميزات بنية الألعاب الأساسية.
• استجابة سريعة. نظرًا لحقيقة أن العديد من الأشخاص قد تم تعيينهم لكل نوع من أنواع أنظمة SZI والأنظمة ، فلم نكن نواجه أي مشكلة في حقيقة أن الشخص المسؤول قد استريح أو غادر للتو لبضع دقائق. تمت معالجة جميع المعلومات من الرصد في أسرع وقت ممكن.
• خبرة في تصلب ومراقبة مختلف البنى التحتية.

ملحوظة: شكر خاص لكل من جاء وطرح أسئلة ، ونعتذر لأولئك الذين لم يتمكنوا من معرفة شيء ما في هذه العملية - كان الفريق ينتظر "القوزاق الذين أسيء معاملتهم" من المهاجمين ولم يتمكنوا من الكشف عن كل التفاصيل.

دميتري ليفانوف ، خبير في مركز مراقبة حوادث أمن المعلومات والاستجابة لها Jet CSIRT