eladshamir/internal-monologueهجوم المونولوج الداخلي: استرداد تجزئات NTLM دون لمس LSASS
Mimikatz، التي طورها Benjamin Delpy (@gentilkiwi)، هي أداة معروفة جيدًا لمرحلة ما بعد الاستغلال، تسمح للخصوم باستخراج كلمات المرور النصية العادية، وتجزئات NTLM، وتذاكر Kerberos من الذاكرة، بالإضافة إلى تنفيذ هجمات مثل تمرير التجزئة (pass-the-hash) أو تمرير التذكرة (pass-the-ticket) أو بناء تذكرة ذهبية. يمكن القول إن الاستخدام الأساسي لـ Mimikatz هو استرداد بيانات اعتماد المستخدم من ذاكرة عملية LSASS لاستخدامها في الحركة الجانبية بعد الاستغلال.
مؤخرًا، قدمت Microsoft ميزة Credential Guard في Windows 10 Enterprise وWindows Server 2016، والتي تستخدم الأمان القائم على المحاكاة الافتراضية لعزل الأسرار، وهي فعالة جدًا في منع Mimikatz من استرداد التجزئات مباشرة من الذاكرة. أيضًا، أصبحت Mimikatz هدفًا رئيسيًا لمعظم حلول حماية نقاط النهاية، وهي عدوانية جدًا في جهودها لكشفها ومنعها. على الرغم من أن هذه الجهود محكوم عليها بالفشل، إلا أنها أصبحت مصدر إزعاج متزايد.
NetNTLM هو بروتوكول التحدي والاستجابة من Windows المستخدم بشكل أساسي حيث لا يتم دعم Kerberos. في NetNTLM، يرسل الخادم إلى العميل رقمًا عشوائيًا من 8 بايت (nonce) كتحدٍ، ويحسب العميل استجابة تعالج التحدي باستخدام تجزئة NTLM كمفتاح، وهي تجزئة MD4 لكلمة مرور المستخدم. هناك نسختان من بروتوكول مصادقة NetNTLM، وكلاهما عرضة لهجمات معينة. بطبيعة الحال، الإصدار 1 أضعف بكثير من الإصدار 2، ولذلك اعتبارًا من Windows Vista/2008 يتم تعطيل NetNTLM الإصدار 1 افتراضيًا.
نظرًا لأن تجزئة NTLM هي المفتاح لحساب الاستجابة، لا يحتاج الخصم بالضرورة إلى الحصول على كلمة مرور النص العادي للضحية للمصادقة، وبالتالي فإن استرداد التجزئة من ذاكرة LSASS باستخدام Mimikatz يعادل تقريبًا سرقة كلمة مرور نصية عادية. نشر Chris Hummel مقالًا يصف هذه التقنية في عام 2009 وأطلق عليها اسم "Pass the Hash" [https://www.sans.org/reading-room/whitepapers/testing/crack-pass-hash-33219].
في مؤتمر Defcon 2012، قدم Moxie Marlinspike وDavid Hulton هجوم "فرق تسد" ضد NetNTLMv1 [https://www.youtube.com/watch?v=sIidzPntdCM]. في NetNTLMv1، يتلقى العميل التحدي المكون من 8 بايت ويحسب الاستجابة عن طريق تشفيره ثلاث مرات باستخدام DES مع أجزاء مختلفة من تجزئة NTLM كمفتاح. طول المفتاح لـ DES هو 56 بت فعليًا، أي 7 بايت، بينما تجزئة NTLM هي 16 بايت. يقوم NetNTLMv1 أولاً بتشفير التحدي باستخدام أول 7 بايت من تجزئة NTLM كمفتاح، ثم تشفير التحدي باستخدام الـ 7 بايت التالية من تجزئة NTLM كمفتاح، وأخيرًا تشفير التحدي باستخدام آخر 2 بايت من تجزئة NTLM مع حشو بايتات صفرية كمفتاح. يعني هذا فعليًا أنه لاسترداد تجزئة NTLM بوجود تحدٍ واستجابة من NetNTLMv1، يجب على الخصم اختراق مفتاحين DES بطول 56 بت، وهو أسهل بشكل هائل من اختراق مفتاح واحد بطول 128 بت. طور Moxie وHulton أجهزة مخصصة لهذه المهمة وتمكنا من اختراق كامل مساحة مفاتيح DES بالقوة العمياء في أقل من 24 ساعة، مما يضمن استرداد تجزئة NTLM بنجاح في غضون وقت معقول. لاحظ أنه على عكس هجمات القاموس أو القوة العمياء ضد كلمة المرور، التي قد لا تكون مثمرة، فإن هذا الهجوم يضمن استرداد تجزئة NTLM بنجاح.
كما هو موضح من ToorCon على https://crack.sh، من الممكن إنشاء جدول قوس قزح كامل لجميع الاستجابات الممكنة لـ NetNTLMv1 لتحدٍ مختار، مثل 0x1122334455667788، مما يسمح باختراق تجزئة NTLM لاستجابة معينة في غضون دقائق. المعنى الضمني هو أن التقاط استجابة NetNTLMv1 للتحدي المختار يمكن ترجمتها إلى تجزئة NTLM المقابلة بشكل فوري تقريبًا، وهو ما يعادل تقريبًا الحصول على كلمة المرور بسبب تمرير التجزئة.
عادةً ما يتم تنفيذ Mimikatz بعد أن يحصل الخصم على وصول مرتفع إلى المضيف الهدف. في هذه المرحلة، يمكن للخصم أيضًا تغيير مفاتيح التسجيل، مثل LMCompatibilityLevel، الذي يحدد ما إذا كان المضيف سيتفاوض على NetNTLMv1 أو NetNTLMv2. يمكن للخصم تغيير القيمة إلى 0 أو 1 أو 2، مما يتيح NetNTLMv1 كعميل، ثم محاولة المصادقة على خادم SMB مخادع يقوم بالتقاط استجابة العميل، كما هو موضح في منشور مدونة Optiv [https://www.optiv.com/blog/post-exploitation-using-netntlm-downgrade-attacks].
قد يمنع إعدادان آخران الضحية من التفاوض على استجابة NetNTLMv1:
في البيئات الآمنة، حيث لا يجب تنفيذ Mimikatz، يمكن للخصم تنفيذ هجوم المونولوج الداخلي، حيث يستدعي استدعاء إجراء محلي (LPC) لحزمة مصادقة NTLM (MSV1_0) من تطبيق وضع المستخدم عبر SSPI لحساب استجابة NetNTLM في سياق المستخدم المسجل الدخول، بعد تنفيذ خفض مستوى NetNTLM موسع.
يتم وصف تدفق هجوم المونولوج الداخلي أدناه:
لقد قمت مؤخرًا بإعادة اختبار Internal Monologue في بيئات بها Credential Guard مفعل وحصلت على نتائج سلبية. لست متأكدًا ما إذا كان Credential Guard لا يعمل بشكل صحيح في بيئة الاختبار الخاصة بي أثناء الاختبارات الأولية، أو ربما تغير شيء منذ ذلك الحين. لقد قمت بتحديث التنفيذ للحصول على رمز خادم من AcceptSecurityContext بشكل ديناميكي والتلاعب به لتجنب فخ المصادقة المحلية، بحيث إذا فشل NetNTLMv1 بدون أمان الجلسة الموسعة، يمكن على الأقل التقاط تحدي-استجابة NetNTLMv2.
من الجدل أن هجوم المونولوج الداخلي أكثر تكتماً من تشغيل Mimikatz لأنه لا حاجة لحقن كود أو تفريغ الذاكرة من/إلى عملية محمية. نظرًا لأن استجابة NetNTLMv1 يتم استخراجها عن طريق التفاعل مع NTLM SSP محلياً، لا يتم توليد حركة مرور شبكية، والتحدي المختار ليس مرئيًا بسهولة. لا يتم تسجيل أي حدث مصادقة NTLM ناجح في السجلات. قد تؤدي تغييرات التسجيل لخفض مستوى NetNTLM وسرقة الرموز/انتحال هوية المستخدمين الآخرين إلى إثارة المؤشرات.
هذه الأداة هي إثبات مفهوم ينفذ هجوم المونولوج الداخلي بلغة C#. قد يؤدي نقل الكود إلى PowerShell إلى استبدال بعض سجلات الأحداث في مسار التدقيق بأخرى. كود إثبات المفهوم بعيد عن الكمال. المساهمات والتحسينات الإيجابية مرحب بها.
Elad Shamir من The Missing Link Security
