Kerberoasting بالعربي: ليش حساب الخدمة أهم من عدد SPN، وكيف تراجع الخطر بدون تخمين كلمات مرور؟

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

وش المقصود بالمحاولة خارج الاتصال؟

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

ابدأ بجرد محدود تستطيع تفسيره

المراجعة لا تحتاج استعلامًا يجلب كل خصائص كل مستخدم في الغابة. في مختبر lab.test اختَر حساب خدمة واحدًا معروفًا، مثل svc_reports، واقرأ فقط ما تحتاجه. مثال: Get-ADUser -Identity svc_reports -Server dc01.lab.test -Properties ServicePrincipalNames,PasswordLastSet,PasswordNeverExpires,Enabled | Select-Object SamAccountName,Enabled,PasswordLastSet,PasswordNeverExpires,ServicePrincipalNames.
هذا الاستعلام يعرض معلومات إدارية، ولا يعرض كلمة المرور ولا يثبت قوتها. PasswordLastSet يعطيك زمنًا مرتبطًا بآخر تعيين وفق بيانات الدليل، وليس نتيجة اختبار جودة السر. وPasswordNeverExpires يوضح إعدادًا يتعلق بالانتهاء، لكنه لا يقول إن كلمة المرور لم تُغير قط. ربما يوجد تدوير خارجي معتمد؛ تحتاج تسأل وتتحقق من سجله.
قائمة ServicePrincipalNames تساعدك تربط الحساب بخدمات، لكنها ليست جردًا كاملًا لاستخداماته. قد يستعمله تطبيق في مهمة مجدولة أو اتصال لا يظهر بهذه القائمة. لذلك قارِن الأسماء مع سجل التطبيقات والخوادم المعروف. إذا كان الحساب بلا مالك أو استخداماته متضاربة، هذه مشكلة إدارة هوية تستحق توثيقًا حتى قبل أي نقاش عن نوع التشفير.
أضف SID والاسم المميز عند الحاجة لتمييز الهوية بين نسخ الجرد. لا تجعل اسمًا يبدأ بـsvc دليلًا على أنه حساب خدمة، ولا تجعل اسمًا عاديًا دليلًا على عدم استخدامه لتشغيل خدمة. دور الحساب يُستنتج من الاستخدام المعتمد، لا من أسلوب التسمية. هذا التفصيل يمنع حذف حساب مهم من المراجعة أو إدخال مستخدم لا يخص الحالة.

خصائص التشفير ليست نفس التشفير المشاهد

هناك فرق بين قدرة حساب معلنة أو إعداد مسموح وبين نوع التذكرة التي صدرت في طلب معين. قد تنظر إلى خاصية وتظن أن كل الطلبات أصبحت تستخدم AES، بينما السجلات تشير إلى استخدام آخر في مسار محدد. وقد تقرأ حدثًا لتذكرة قديمة ثم تنسبه إلى حالة بعد تعديل حديث. الربط الزمني مهم هنا.
مرجع Microsoft للحدث 4769 يوضح أنه يتعلق بطلب تذكرة خدمة على وحدة تحكم الدومين، ويعرض حقولًا مثل نوع تشفير التذكرة، وفي الإصدارات الحديثة تفاصيل إضافية عن القدرات والمفاتيح. انتبه أن TicketEncryptionType وSessionKeyEncryptionType ليسا اسمين لنفس الحقل. لا تسحب قيمة أحدهما وتعرضها في تقرير على أنها الآخر.
عندما تطلب من فريق المراقبة عينة، حدد الحساب والخدمة والوقت والعميل والحقول المطلوبة. لا تطلب سجل Security كاملًا لشهر إذا تكفي نافذة متفق عليها. العينة تساعدك تفهم الاستخدام المشاهد، لكنها لا تثبت سلوك كل العملاء وكل التطبيقات. اكتب حدود التغطية بدل تعميم نتيجة حالة واحدة على الدومين.
كذلك لا تعتمد على جدول قديم لقيم افتراضية من مقال مجهول. دعم Kerberos وإعداداته وتحديثاته تتغير. مراجعة بيئة قائمة تحتاج النسخ الفعلية والتحديثات والمرجع الحالي وخطة الفريق. لهذا المقال لا يعطي أمر Registry عامًّا أو موعدًا مفترضًا يقول إن كل البيئات توقفت عن استخدام RC4. ما يهم هو الحالة المقروءة في نطاقك والأدلة التي تشرحها.

سر قوي، تدوير، وصلاحيات: ثلاث مسائل منفصلة

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

مثال مقارنة: نفس SPN تقريبًا، لكن أثر مختلف

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

التنبيه الأمني لا يكفي وحده لإعلان حادث

قد ترى تنبيهًا عن نشاط غير معتاد في طلبات خدمات Kerberos. خذ التنبيه بجدية، لكن افصل ما رصدته المنصة عما تثبته الأدلة. حساب اختبار مصرح قد يسبب نمطًا مختلفًا، وخدمة جديدة قد تزيد عدد الطلبات، وفي المقابل قد يستخدم شخص غير مخول طلبات تبدو صحيحة من ناحية البروتوكول.
اطلب سياق المصدر والهوية والوقت والخدمات المطلوبة ومقارنته بخطة العمل أو التغيير. لا تعتبر عنوان IP اسم شخص؛ قد يكون وراءه جهاز مشترك أو مسار وسيط. كذلك لا تساوي عددًا كبيرًا من الأحداث مع نجاح الحصول على كلمة المرور. كل خطوة في الاستنتاج تحتاج نوع دليل يناسبها.
في اختبار Purple Team متفق عليه، تستطيع تقييم قدرة الفريق على رؤية سيناريو تدريبي مصرح، لكن خطة النشاط وحدود البيانات يجب أن تكون واضحة قبل التنفيذ. هذا المقال يشرح المراجعة ولا يقدم طريقة توليد مواد تخمين. يمكن اختبار تحليل أحداث نموذجية أو سجلات تدريب معدة لهذا الغرض دون التعامل مع أسرار حسابات تشغيل حقيقية.
وعند عدم ظهور تنبيه، راجع التغطية قبل الحكم. هل المصدر مراقب؟ هل السجل موجود؟ هل نافذة الاحتفاظ كافية؟ هل المنتج جمع الأحداث المطلوبة؟ غياب التنبيه يثبت أنك لم تر تنبيهًا في المكان والوقت المقروءين، ولا يثبت أن كل نشاط محتمل سينكشف. هذه طريقة تفكير مفيدة في أغلب اختبارات الرصد، مب في Kerberoasting فقط.

كيف تبني معالجة يمكن اختبارها؟

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

النتيجة التي تستحق القراءة في التقرير

صياغة النتيجة تبدأ بالحساب والخدمة، ثم الإعداد أو الاستخدام المثبت، ثم الأثر المرتبط بالصلاحيات. مثال مفترض: «هوية خدمة قديمة تستخدم تشفيرًا ضعيفًا في العينة المقروءة وتملك حقوقًا إدارية خارج حاجتها الموثقة؛ يرفع ذلك أثر فقد بيانات اعتمادها». هذه الجملة لا تدعي تخمينًا ناجحًا ولا اختراقًا وقع.
أرفق مقتطفات محدودة من الجرد والسجلات مع وقت ونطاق ومصدر. اخفِ بيانات غير لازمة للعرض، واحتفظ بالمعلومات التفصيلية ضمن ملف المشروع المصرح. لا تضع مواد حساسة في التقرير لمجرد أنها تبدو دليلًا قويًا؛ يقدر التقرير يثبت سوء الإعداد دون نسخ أسرار إلى أشخاص لا يحتاجونها.
في إعادة الفحص، قارن الحالة قبل وبعد على الهوية نفسها، وراجع أن التطبيق يعمل وأن الحقوق والإدارة والاستخدام المشاهد تغيرت كما خُطط. إذا كان التحقق محدودًا بعميلين، اذكر ذلك. وإذا بقيت سياسة غير محسومة، اكتب ما الذي يمنع الإغلاق وما الدليل المطلوب، بدل وعد بأن «التشفير صار آمنًا» بلا قياس.
فهم Kerberoasting يفيدك أكثر لما يغير طريقة مراجعتك لحسابات الخدمة: اسأل عن الحاجة والهوية والسر والتشفير والأثر، ثم اربط الإجابات. عدد SPN لا يشرح هذه الصورة، وأسماء الأدوات لا تغني عنها. هنا يصير المقال مفيدًا لطالب شهادة ومختبر بدأ يعمل وموظف يدير التطبيق بنفس الوقت.
المراجع: مراجعة RC4 الرسمية https://learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos وشرح الحدث 4769 https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769 . راجع النسخة الحالية عند تطبيق تغيير؛ التفاصيل المتعلقة بالتحديثات والتوافق يجب مطابقتها مع بيئتك.