IBo nefig: أفضل إفصاحات الأمن السيبراني لعام 2020 وفقًا لـ JSOC

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





لقطة من سلسلة ساوث بارك

تعرفنا عليه بخط يده

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



لذلك ، خلال أحد البرامج التجريبية ، كان العميل في طور إعادة بناء مشهد تكنولوجيا المعلومات الخاص به وأراد أن يرى كيف تتلاءم SOC مع بنيتها التحتية وعملياتها الجديدة. نظرًا لظروف مختلفة خارجة عن سيطرتنا ، لم يكن لدينا مصدر شبكة واحد متصل ، والذيkapets كم حدنا في الكشف عن الحوادث المختلفة. تم توصيل وحدة تحكم المجال واثنين من خوادم Windows وخادم البريد ومكافحة الفيروسات فقط. مر الطيار بهدوء تام وكان معيارًا لنا : تم العثور على العديد من البرامج الضارة في البنية التحتية ، واستخدام TOR و RATs المحظورة. ولكن في أحد الأيام الجميلة ، بدأ عدد كبير من قواعدنا في العمل ، من بينها قواعد من فئة Threat Hunting ، والتي تعمل على أتمتة عملية تحديد آثار المهاجم. سرعان ما أدرك المحلل المسؤول أن الحالة تفوح منها رائحة الكاز ، وأدرك حتى من يتعامل معه.



ماذا حدث؟ أول شيء رأيناه هو إضافة حسابات جديدة إلى مجموعة Domain Admins. لكن نجحت قاعدة أخرى ، وهي الاسم المشبوه للحسابات ، والذي واجهناه بالفعل. أحد معارفنا القدامى ، مهاجم ، عند تنفيذ الهجمات ، يقوم بإنشاء حسابين مكتوبين في نصه: هذان الاسمان "يتجولان" من ضحية إلى أخرى - لا يمكن أن يحدث تغيير بسيط إلا من خلال قواعد تسمية حسابات المنظمة التي تعرضت للهجوم. لقد قابلناه عدة مرات أثناء التحقيق في الحوادث. يهاجم المؤسسات من جميع الأحجام والصناعات بنفس الطريقة ، وينتهي به الأمر عادةً بتشفير الخوادم الرئيسية للشركة.



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







كان العامل الأهم هو توزيع أداة تشفير قانونية على المضيفين المخترقين. لم يكن لديه الوقت لتحميله على جميع المضيفين. وكان المهاجم قد "طُرد" من البنى التحتية بعد 23 دقيقة من انطلاقه.



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



ip nat داخل المصدر ثابت tcp "العنوان الرمادي" 22 "العنوان الأبيض" 9922

ip nat داخل المصدر الثابت tcp "العنوان الرمادي" 3389 "العنوان الأبيض" 33899



تم استنتاج أنه ، على الأرجح ، أصبح أحد الخوادم حيث تم تكوين NAT هذا هو نقطة الدخول. قمنا بتحليل سجلات هذه الخوادم ورأينا مصادقة ناجحة ضمن حساب المسؤول ، حيث أطلقنا Mimikatz ثم أطلقنا برنامج نصي أنشأ مسؤولي المجال. من خلال هذا الحادث ، أجرى العميل مراجعة كاملة لقواعد جدار الحماية وكلمات المرور وسياسات الأمان وحدد العديد من العيوب في بنيته التحتية. وحصلت أيضًا على فهم أكثر منهجية لسبب الحاجة إلى SOC في مؤسستها.

أجهزة التوجيه عن بُعد والمنزلية - جنة القراصنة

من الواضح ، في ظروف انتقال الشركات إلى جهاز التحكم عن بُعد ، أصبح من الصعب جدًا مراقبة الأحداث على الأجهزة الطرفية. هناك سببان رئيسيان:

1. يستخدم عدد كبير من الموظفين الأجهزة الشخصية للعمل ؛
2. VPN , .

ومن الحقائق الواضحة أيضًا أنه حتى المهاجمين المتمرسين أصبحوا مهتمين بالشبكات المنزلية ، نظرًا لأن هذه هي الآن نقطة الاختراق المثالية في محيط الشركة.



كان لدى أحد عملائنا 90٪ من الموظفين تحولوا إلى وضع العمل عن بُعد ، وكان لديهم جميعًا أجهزة كمبيوتر محمولة ذات نطاق - وبالتالي ، يمكننا الاستمرار في مراقبة الأجهزة الطرفية - بالطبع ، مع مراعاة النقطة 2 أعلاه. وهذه هي النقطة التي لعبت ضدنا.



لم يتصل أحد المستخدمين أثناء العزلة الذاتية بشبكة VPN لمدة يوم كامل تقريبًا. في نهاية يوم العمل ، كان لا يزال بحاجة إلى الوصول إلى موارد الشركة. لقد استخدم VPN ، وحصلنا على السجلات من جهاز عمله ورأينا شيئًا غريبًا. تم إنشاء مهمة مشبوهة في Task Scheduler: تم إطلاق ملف معين كل يوم أربعاء الساعة 17:00. بدأوا في الفهم.







أدت الآثار إلى ملفين مستندين: أحدهما أنشأ المهمة ، والثاني هو الملف القابل للتنفيذ في المهمة. قام المستخدم بتنزيلها من Google Drive.



في هذه المرحلة من بحثنا ، كانت خدمة الأمن الخاصة بالعميل متصلة بالفعل وبدأت تحقيقًا داخليًا. اتضح أن المستخدم تلقى خطابًا إلى بريده الشخصي ، يحتوي على رابط إلى Google Drive ، حيث تم تنزيل المستندات منه. تدريجيًا وصلنا إلى جهاز توجيه المستخدم - بالطبع ، كان تسجيل الدخول / كلمة المرور الخاصة به admin / admin (كما لو كان الأمر بخلاف ذلك؟). ولكن الشيء الأكثر إثارة للاهتمام تم العثور عليه في إعدادات خادم DNS الخاص بالموجه: تمت الإشارة إلى عنوان IP لإحدى الدول الأوروبية هناك. نقلنا هذا العنوان إلى VirusTotal - أضاءت معظم المصادر باللون الأحمر. بعد انتهاء التحقيق أرسل لنا العميل ملفين للبحث ، ورأينا أن الملف الذي أطلقته المهمة بدأ في "السير" عبر جميع أنواع الأدلة وتفريغ البيانات من هناك.



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

كسروا لهم أيضا

في المرحلة الأولى من العمل مع شركة SOC للاستعانة بمصادر خارجية ، نوصي دائمًا بربط مصادر الأحداث على مراحل ، بحيث يصحح العميل من جانبه العمليات ، ويحدد بوضوح مجالات المسؤولية ويتعود عمومًا على هذا التنسيق. لذلك ، في أحد عملائنا الجدد ، قمنا أولاً بتوصيل المصادر الأساسية ، مثل وحدات التحكم في المجال وجدران الحماية والوكلاء وأدوات أمان المعلومات المختلفة والبريد وخوادم DNS و DHCP والعديد من الخوادم المختلفة الأخرى. عرضنا أيضًا توصيل أجهزة مسؤولي المكتب الرئيسي على مستوى السجلات المحلية ، لكن العميل قال إن هذا غير ضروري في الوقت الحالي وهو يثق في مسؤوليه. هنا ، في الواقع ، تبدأ قصتنا.



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



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



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



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

النتيجة

على الرغم من حقيقة أنه عام 2020 بالفعل ، لا تزال العديد من المنظمات لا تلتزم بالحقائق المشتركة لأمن المعلومات ، ويمكن أن يؤدي عدم مسؤولية موظفيها إلى عواقب وخيمة.



في هذا الصدد ، إليك بعض النصائح:

1. لا تقم أبدًا بتعريض RDP و SSH للخارج ، حتى إذا قمت بإخفائها خلف منافذ أخرى - فهذا لا يساعد.
2. اضبط أعلى مستوى تسجيل ممكن لتسريع اكتشاف المتسللين.
3. Threat Hunting . TTPs , . .
4. , . , , .

, Solar JSOC (artkild)