هجوم Kerberoasting خطوة بخطوة: كيف يعمل وكيف تكتشفه

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

وأهمية فهمه بسيطة: في كثير من بيئات الدليل النشط (Active Directory) ينجح هذا الهجوم منذ اليوم الأول، بلا شيء أكثر من بيانات دخول مستخدم عادي. ولهذا يفضّله المهاجمون الحقيقيون، ويجب على كل مدافع أن يعرف كيف يتعرف عليه في سجلاته.

بروتوكول Kerberos بكلمات بسيطة

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

• مركز توزيع المفاتيح (Key Distribution Center – KDC): هو مكتب إصدار التذاكر، وكل وحدة تحكم بالنطاق في الدليل النشط تشغّل واحدًا منه.
• تذكرة منح التذاكر (Ticket-Granting Ticket – TGT): التذكرة التي تحصل عليها بعد تسجيل الدخول. تُثبت أنك مستخدم موثَّق، وتستخدمها لطلب تذاكر أخرى.
• تذكرة الخدمة (TGS): تذكرة لخدمة واحدة بعينها، كخادم قواعد بيانات SQL أو تطبيق ويب، وتحصل عليها بتقديم تذكرة TGT إلى مركز توزيع المفاتيح.
• اسم الخدمة (Service Principal Name – SPN): الاسم الذي تُسجَّل به الخدمة، مثل MSSQLSvc/db01.corp.local:1433، وهو ما يخبر مركز توزيع المفاتيح بالحساب الذي يشغّل تلك الخدمة.

التفصيل المهم يقع في الخطوة الرابعة. فحين يُصدر مركز توزيع المفاتيح تذكرة خدمة، يشفّر جزءًا منها بالمفتاح الدائم للحساب الذي يشغّل الخدمة، وهذا المفتاح مشتق من كلمة مرور ذلك الحساب. تستطيع الخدمة فك التذكرة لأنها تعرف كلمة مرورها، ولا ينبغي لأحد غيرها أن يستطيع ذلك.

لماذا يستطيع أي مستخدم طلب تذكرة؟

صُمّم Kerberos بحيث لا يقرر مركز توزيع المفاتيح من يحق له استخدام الخدمة، بل تقرر الخدمة نفسها ذلك بعد أن تستلم التذكرة. ولهذا يسلّم المركز تذكرة لأي اسم خدمة إلى أي مستخدم موثَّق يطلبها. فطلب التذكرة ليس هجومًا في ذاته، بل يحدث آلاف المرات يوميًا في كل نطاق.

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

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

الهجوم خطوة بخطوة

يصنّف إطار MITRE ATT&CK هذا الهجوم تحت الرمز T1558.003 (سرقة تذاكر Kerberos أو تزويرها: Kerberoasting)، وهو يمر بأربع خطوات.

1. البحث عن أسماء الخدمات: يستعلم المهاجم الدليل النشط عبر بروتوكول LDAP عن حسابات المستخدمين التي تحمل الخاصية servicePrincipalName، وهي معلومة يستطيع أي مستخدم في النطاق قراءتها.
2. طلب التذاكر: يطلب المهاجم من مركز توزيع المفاتيح تذكرة خدمة لكل حساب منها، ويبدو الطلب في نظر وحدة التحكم بالنطاق طلبًا عاديًا.
3. استخراج البصمة: يُحفظ الجزء المشفر من كل تذكرة بصيغة تفهمها أدوات كسر كلمات المرور.
4. الكسر دون اتصال: على أجهزته الخاصة، يجرّب المهاجم كلمات مرور محتملة، ويشتق المفتاح من كل تخمين، ثم يتحقق إن كان يفك التذكرة. وحين ينجح أحدها، يحصل على كلمة مرور حساب الخدمة.

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

# Authorized testing only
Rubeus.exe kerberoast /outfile:hashes.txt
GetUserSPNs.py corp.local/alice -request -outputfile hashes.txt

أداة Rubeus مجموعة أدوات مكتوبة بلغة C# لاستغلال Kerberos وتعمل على Windows، أما GetUserSPNs.py فهي جزء من مجموعة Impacket وتعمل من أي جهاز يصل إلى وحدة التحكم بالنطاق. ثم تُمرَّر النتيجة إلى أداة كسر مثل hashcat.

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

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

لماذا يهم نوع التشفير: RC4 مقابل AES

تعتمد سرعة تلك التخمينات على نوع تشفير التذكرة.

• خوارزمية RC4-HMAC (النوع 0x17، أي 23): المفتاح هنا هو ببساطة بصمة NT لكلمة المرور، دون أي ملح، فاختبار كل تخمين رخيص جدًا. وفي hashcat يقابله الوضع 13100.
• خوارزميتا AES128 (النوع 0x11) وAES256 (النوع 0x12): يُشتق المفتاح بدالة PBKDF2 مع 4096 دورة، وملح مكوَّن من اسم النطاق واسم الحساب، فيكلّف كل تخمين أكثر بكثير. وفي hashcat يقابلهما الوضعان 19600 و19700.

يُبطئ AES الكسر إذن بشكل كبير، ولهذا تُعد تذاكر RC4 صيدًا ثمينًا. وقد تُصدر وحدات التحكم بالنطاق تذاكر RC4 لحسابات الخدمة غير المهيأة لدعم AES، وكثيرًا ما تطلب أدوات الهجوم RC4 عمدًا.

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

الرصد: كيف يبدو الهجوم في السجلات

لأن كل خطوة على الشبكة تشبه حركة Kerberos العادية، يعتمد الرصد على ملاحظة الأنماط لا على حدث «خبيث» واحد. والمصدر الأساسي هنا هو سجل الأمان في وحدة التحكم بالنطاق.

حين تُفعَّل فئة التدقيق «تدقيق عمليات تذاكر خدمة Kerberos» (Audit Kerberos Service Ticket Operations) على وحدات التحكم بالنطاق، يُنتج كل طلب لتذكرة خدمة الحدث 4769: «طُلبت تذكرة خدمة Kerberos». ويسجّل هذا الحدث الحساب الطالب، واسم الخدمة، وعنوان الجهاز، والأهم من ذلك كله: نوع تشفير التذكرة.

هناك ثلاثة مؤشرات تستحق أن تُبنى عليها التنبيهات:

1. تشفير RC4 حيث يُتوقع AES: في نطاق تدعم فيه الأجهزة وحسابات الخدمة خوارزمية AES، يلفت النظر حدث 4769 بنوع التشفير 0x17 لحساب خدمة من حسابات المستخدمين، إذ كثيرًا ما تطلب أدوات الهجوم RC4 عمدًا لتسهيل الكسر.
2. خدمات كثيرة، حساب واحد، وقت قصير: المستخدم العادي يتعامل مع عدد قليل من الخدمات. أما حساب واحد يطلب تذاكر لعشرات أسماء الخدمات المختلفة خلال دقائق، فذلك سلوك نموذجي لهذا الهجوم.
3. لمس حساب الطُعم (Honey SPN): أنشئ حساب مستخدم وهميًا له اسم خدمة لا يستخدمه أي نظام حقيقي، وامنحه كلمة مرور قوية جدًا، ثم نبّه على أي حدث 4769 يخصه. لن تطلبه أي حركة مشروعة، فتكاد الإنذارات الكاذبة تنعدم.

ولتقليل الضجيج، استبعد حسابات الأجهزة (أسماء الخدمات المنتهية بالرمز $) وحساب krbtgt، وابنِ خط أساس للخدمات التي يستخدمها كل فريق عادةً.

وهناك صورة أخرى من الهجوم تستحق المراقبة. فالمهاجم الذي يملك صلاحية الكتابة على حساب مستخدم آخر يستطيع إضافة اسم خدمة إليه ثم مهاجمته بالطريقة نفسها، وهو ما يُعرف أحيانًا بالهجوم الموجَّه (Targeted Kerberoasting). فإذا كان تدقيق تغييرات خدمة الدليل مفعّلًا، تظهر التعديلات على الخاصية servicePrincipalName في الحدث 5136، وأي اسم خدمة يُضاف فجأة إلى حساب مستخدم عادي يستحق نظرة فاحصة.

الوقاية: اجعل التذكرة بلا قيمة

لا يمكن إيقاف هذا الهجوم بزر؛ فإصدار تذاكر الخدمة هو طريقة عمل Kerberos أصلًا. لكن ما تستطيعه هو أن تضمن أن كل تذكرة يحصل عليها المهاجم لا تنفعه في شيء.

• استخدم حسابات الخدمة المُدارة جماعيًا (Group Managed Service Accounts – gMSA): يحصل هذا النوع من الحسابات على كلمة مرور عشوائية من 120 حرفًا، يغيّرها الدليل النشط تلقائيًا كل 30 يومًا افتراضيًا. لا أحد يحتاج إلى معرفتها، ولن يكسرها أحد. وهذا هو الحل الأكثر فاعلية على الإطلاق.
• استخدم كلمات مرور طويلة عشوائية حيث يتعذر gMSA: بعض التطبيقات القديمة لا تدعم هذه الحسابات، فامنح حسابات خدمتها 25 حرفًا عشوائيًا أو أكثر يولّدها مدير كلمات المرور، وغيّرها دوريًا.
• فعّل AES وتخلّ عن RC4: هيّئ حسابات الخدمة لدعم AES عبر الخاصية msDS-SupportedEncryptionTypes، واعمل على إيقاف RC4 في النطاق.
• طبّق مبدأ أقل الصلاحيات: يجب أن يملك حساب الخدمة ما تحتاجه خدمته فقط، ولا يكون أبدًا عضوًا في مجموعة مسؤولي النطاق أو غيرها من المجموعات ذات الامتيازات العالية.
• احذف أسماء الخدمات التي لا يستخدمها أحد: راجع حسابات المستخدمين التي لها أسماء خدمات، فالإدخالات القديمة لتطبيقات متوقفة ليست سوى مساحة إضافية للهجوم.
• راقب وضع طُعمًا: فعّل تدقيق الحدث 4769، ونبّه على الأنماط السابقة، وأنشئ حساب طُعم له اسم خدمة.

التدرّب على ذلك بأمان

هذا أسلوب ينبغي فهمه من الجهتين: كيف يُنفَّذ، وكيف يُكتشف. ويبقى المبدأ الذي تحدثنا عنه في المقال السابق قائمًا: «أولًا: لا تُلحق ضررًا». فهذه الخطوات مكانها البيئات التي تملكها أو المصرَّح لك صراحةً باختبارها، وفق قواعد اشتباك متفق عليها.

ولهذا بالضبط نبني بيئات تدريب معزولة. ففي دورة FortMind FM-O300 لعمليات الفريق الأحمر على الدليل النشط، تنفّذ هذا الهجوم على نطاق تدريبي مصمَّم لهذا الغرض، ثم تبدّل موقعك لتتعقب النشاط نفسه في السجلات. ترى الهجوم وبصماته، من متصفحك، دون أن تلمس شبكة إنتاج لأي أحد.

خذ لحظة لتفحص نطاقك: أي حسابات المستخدمين لها أسماء خدمات؟ كم عمر كلمات مرورها؟ وهل سيلاحظ مركز العمليات الأمنية لديك لو طلب أحدهم تذاكر لها جميعًا بعد ظهر اليوم؟