شركة كومورا سوفت ذ.م.م.
تواصل معنا
القائمة

سياسة تدقيق أمن Windows وتحقيق سجلّ الأحداث عمليّاً ── لتصبح نظم المعلومات قادرة على قراءة 4625

· · Windows, الأمن, سجلّ الأحداث, سياسة التدقيق, تصميم السجلّات, PowerShell, نظم المعلومات

«حساب يُقفَل مراراً منذ الليلة الماضية. أريد معرفة السبب.» «أريد التحقّق هل يحاول أحد تسجيل الدخول بحساب موظّف سابق.» «هذا الخادم، هل نعرف متى ومن وماذا نفَّذ؟» ── طلبات يتلقّاها فجأة موظّفو تقنيّة المعلومات في المنشآت الصغيرة والمتوسّطة، أو المطوِّرون الذين سلَّموا نظاماً لعميل. وما ينتهون إلى الاعتماد عليه هو سجلّ أحداث Security في Windows.

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

واقعان ينتظرانك في عارض الأحداثعند فتح عارض الأحداث تواجه أحد واقعين سياسة التدقيق غير مفعَّلة فلا يُسجَّل الحدث المطلوب أو الضوضاء تضخّم السجلّ فيُدفَن الحدث تحت كمّ هائل فلا يُقرأ لذا يلزم تصميم ما الذي يُسجَّل وإلى أيّ حدّغير مسجَّلمدفونفتح عارض الأحداثأيّ واقع ينتظرك؟الحدث المطلوب غير مسجَّلأحداث هائلة فلا تُقرأسياسة التدقيق معطَّلةضوضاء وتضخّمصمِّم ماذا تسجِّل وإلى أيّ حدّ

الشكل 1: «غير مسجَّل» أو «مدفون فلا يُقرأ». السبب في الحالتين أنّ نطاق التسجيل لم يُصمَّم.

ينظِّم هذا المقال آليّة سياسة التدقيق (النظامان: الأساسيّ والمفصَّل)، والفئات الفرعيّة التي ينبغي تفعيلها كحدّ أدنى في بيئة صغيرة ومتوسّطة، وكيفيّة قراءة معرِّفات الأحداث الثابتة ── 4624/4625/4740/4688 وغيرها ── وتصميم سعة سجلّ Security، وكيفيّة التحقيق بـ PowerShell، استناداً إلى مصادر أوّليّة حتّى أغسطس 2026. إذا كانت مقالات تدقيق NTLM وتوقيع SMB وBitLocker والجدار الناريّ التي تناولها هذا الموقع عن «تثبيت الدفاعات»، فهذا المقال عن «تمكين التحقّق لاحقاً ممّا حدث» ── تتمّة تربطها.

1. الخلاصة أوّلاً

  • لسياسة التدقيق نظامان ── «أساسيّ» و«مفصَّل (Advanced Audit Policy)» ── ولا يجوز خلطهما. مايكروسوفت تنصّ صراحةً على أنّ استخدام الاثنين يترك نتائج التدقيق في حالة غير متوقَّعة. وحِّد على الجانب المفصَّل (أكثر من 40 فئة فرعيّة).1
  • افحص الحالة الحاليّة بـ auditpol /get /category:*. يسرد ما هو نافذ الآن فعليّاً، بغضّ النظر عن كونه من GPO أو إعداد محلّيّ.2
  • «تفعيل الكلّ» شيء لا يجوز فعله. تفعيل فئات فرعيّة تولِّد كمّاً هائلاً من الأحداث يدفن الأحداث الجوهريّة تحت الضوضاء، ويؤثّر على الأداء أيضاً. ابدأ من توصيات خطّ الأساس لدى مايكروسوفت وأضف ما تحتاجه فقط.34
  • نجاح تسجيل الدخول 4624؛ والفشل 4625. في 4624 اقرأ «أيّ نوع تسجيل دخول كان» من نوع تسجيل الدخول (2 = Interactive، 3 = Network، 10 = RemoteInteractive، وهكذا).5
  • في 4625 يخبرك رمز Status/Sub Status بسبب الفشل. الثوابت: 0xC0000064 = اسم مستخدم غير موجود، 0xC000006A = كلمة مرور خاطئة، 0xC0000072 = حساب معطَّل، 0xC0000234 = الحساب مقفول.6
  • مكان تسجيل الحدث ثابت. 4624/4625 يُسجَّلان على الآلة التي جرى الوصول إليها؛ تحقّق بيانات الاعتماد (4776) وفشل المصادقة المسبقة لـ Kerberos (4771) يُسجَّلان على متحكّم النطاق. إن نظرت إلى الآلة الخطأ شخصت خطأ «لا سجلّ».678
  • نصف تصميم سجلّ Security هو الوعاء نفسه ── الحجم الأقصى والاحتفاظ. إن كان الاحتفاظ وضع كتابة فوق، تختفي الأحداث القديمة أوّلاً. افحص الحجم الأقصى وعدد السجلّات بـ Get-WinEvent -ListLog Security، ووسِّعه عدّاً عكسيّاً من عدد الأيّام التي تحتاج إبقاؤها فعليّاً.910
  • تسجيل سطر الأوامر لإنشاء العمليّة (4688) قويّ، لكنّ ثمنه أسرار تهبط في السجلّ بنصّ واضح. دقِّق سكربتاتك قبل التفعيل.1112

2. أساس سياسة التدقيق ── لا تخلط «الأساسيّ» و«المفصَّل»

لسياسة تدقيق Windows نظامان.1

  • سياسة التدقيق الأساسيّة: إعدادات الفئات التسع تحت «Local Policies > Audit Policy». هذا النظام الأقدم، من قبل Windows Vista.
  • تكوين سياسة التدقيق المفصَّلة (Advanced Audit Policy Configuration): إعدادات الفئات الفرعيّة الأربعين فأكثر تحت «Security Settings > Advanced Audit Policy Configuration». تفكّك كلّ فئة أساسيّة إلى عدّة فئات فرعيّة ── مثلاً فئة أساسيّة واحدة «Audit account logon events» تقابل أربع فئات فرعيّة على الجانب المفصَّل. تفعيل فئة أساسيّة واحدة له أثر تفعيل كلّ فئاتها الفرعيّة المقابلة، فيُسجَّل كمّ كبير من الأحداث قد لا تهمّك أصلاً.1

المهمّ أنّ هذين النظامين غير متوافقين. مايكروسوفت تقول بصراحة: «لا تستخدم سياسة التدقيق الأساسيّة والمفصَّلة معاً ── فقد يؤول ذلك إلى نتائج تدقيق غير متوقَّعة.» عندما تُطبَّق سياسة التدقيق المفصَّلة عبر نهج المجموعة، تُمسَح أوّلاً إعدادات التدقيق القائمة على ذلك الحاسوب ثم تُطبَّق إعدادات الجانب المفصَّل؛ ومن تلك النقطة لا يستطيع ضبط التدقيق بثقة إلا الجانب المفصَّل. في البيئات التي تستخدم الجانب المفصَّل، فعِّل خيار الأمن «Audit: Force audit policy subcategory settings to override audit policy category settings» حتّى لا تستطيع الإعدادات الأساسيّة الكتابة فوقه (مفعَّل افتراضيّاً على الآلات المستقلّة).14

علاقة سياسة التدقيق الأساسيّة والمفصَّلةسياسة التدقيق الأساسيّة والمفصَّلة غير متوافقتين واستخدامهما معاً يترك نتائج التدقيق في حالة غير متوقَّعة لذا وحِّد على الجانب المفصَّل وفعِّل فرض إعدادات الفئة الفرعيّة لمنع الكتابة فوقه من الجانب الأساسيّنعملاسياسة التدقيق الأساسيّة（9 فئات）تستخدم الاثنتين؟سياسة التدقيق المفصَّلة（أكثر من 40 فئة فرعيّة）نتائج تدقيق غير متوقَّعةوحِّد على الجانب المفصَّلفعِّل فرض إعدادات الفئة الفرعيّةيمنع الكتابة فوقه من الجانب الأساسيّ

الشكل 2: النظامان غير متوافقين. وحِّد على الجانب المفصَّل، وامنع الكتابة فوقه من الجانب الأساسيّ بإعداد «الفرض».

فحص الحالة الحاليّة أمر واحد، يُشغَّل من موجه أوامر بامتياز المسؤول.2

rem سرد إعدادات التدقيق النافذة الآن، حسب الفئة الفرعيّة
auditpol /get /category:*

rem نسخة احتياطيّة (CSV) قبل التغيير ثمّ الاستعادة
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

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

ما يظهره auditpol هو السياسة الناتجةخرج auditpol هو سياسة التدقيق النافذة فعليّاً بغضّ النظر عن كونها من GPO أو إعداد محلّيّ فيصلح للمضاهاة عندما لا تنعكس إعدادات GPO وتغيير إعداد التدقيق نفسه يُسجَّل في الحدث 4719 ويمكن تتبّعه لاحقاًإعداد موزَّع بـ GPOالسياسة النافذة فعليّاًالإعداد المحلّيّسرد بـ auditpol /getيصلح للمضاهاة عند عدم انعكاس GPOتغيير إعداد التدقيق نفسهيُسجَّل 4719 ويمكن تتبّعه لاحقاً

الشكل 3: auditpol يعيد «الإعداد النافذ» بغضّ النظر عن المصدر. تغيير إعداد التدقيق نفسه يبقى في 4719.

3. جدول قرار للفئات الفرعيّة الواجب تفعيلها كحدّ أدنى

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

لماذا تفعيل الكلّ حركة سيّئةتفعيل كلّ الفئات الفرعيّة يولِّد كمّاً هائلاً من الأحداث فيُدفَن الحدث الجوهريّ تحت الضوضاء ويتأثّر الأداء وفي وعاء السجلّ المحدود تُقتطع أيضاً أيّام الاحتفاظ بالأحداث اللازمةتفعيل كلّ الفئات الفرعيّةتحدث أحداث هائلةيُدفَن الحدث الجوهريّتأثير على الأداءتُقتطع أيّام الاحتفاظتصميم التدقيق هو تقرير ما لا تُسجِّله

الشكل 4: «تفعيل الكلّ» يدفن الحدث الجوهريّ. تصميم التدقيق هو تقرير ما لا تُسجِّله.

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

الفئة الفرعيّة (الفئة) معرِّفات الأحداث الرئيسة ماذا تُخبرك التوصية في بيئة صغيرة ومتوسّطة
Logon (Logon/Logoff) 4624 / 4625 نجاح/فشل تسجيل الدخول، نوع تسجيل الدخول، المصدر نجاح + فشل. Windows 10 1809 فما بعد مفعَّل فيه النجاح والفشل افتراضيّاً أصلاً3
Special Logon (نفسها) 4672 / 4964 حدوث تسجيل دخول بامتياز المسؤول نجاح
Account Lockout (نفسها) 4625 محاولة تسجيل دخول فاشلة على حساب مقفول حالياً فشل (4625 حدث فشل؛ لا أحداث نجاح لهذه الفئة الفرعيّة)13
User Account Management (Account Management) 4720 / 4726 / 4738 / 4740 إنشاء الحساب وحذفه وتعديله وقفله نجاح + فشل
Security Group Management (نفسها) 4728 / 4732 / 4756 (إضافة)، 4729 / 4733 / 4757 (إزالة) أعضاء أُضيفوا إلى مجموعات إداريّة وغيرها أو أُزيلوا منها (عامّة/محلّيّة/شاملة) نجاح (لا أحداث فشل لهذه الفئة الفرعيّة)14
Credential Validation (Account Logon) 4776 نجاح مصادقة NTLM أو فشلها. يُسجَّل على DC لحسابات النطاق7 نجاح + فشل
Kerberos Authentication Service (نفسها، DC فقط) 4768 / 4771 إصدار TGT وفشل المصادقة المسبقة (كلمة مرور خاطئة وغيرها)8 نجاح + فشل، على DC
Process Creation (Detailed Tracking) 4688 من شغَّل ماذا، ومن أيّ عمليّة أصل نجاح. اقرأ تحذير الفصل 7 قبل تفعيل تسجيل سطر الأوامر
Other Object Access Events (Object Access) 4698 إنشاء مهمّة مجدولة (أسلوب شائع للاستمرار)15 انظر في تفعيل النجاح
Audit Policy Change (Policy Change) 4719 تغييرات إعدادات التدقيق نفسها نجاح + فشل

بالمقابل، الأسلم عموماً ألا تمسّ افتراضيّاً تدقيق الوصول إلى الكائنات في نظام الملفّات أو السجلّ، ولا استخدام الامتيازات، ولا فئات مرشّح الحزم الفرعيّة (5152 وما شابه). هذه تنفع عندما تضيِّقها بضبط SACL موجَّه أو بتحقيق محدود المدّة، لا شيئاً يُترَك مفتوحاً دائماً على نطاق واسع ── فذلك يلتهم سجلّك.4

التعامل مع فئات فرعيّة كثيرة الأحداثتدقيق الوصول إلى الكائنات في نظام الملفّات والسجلّ واستخدام الامتيازات وفئات مرشّح الحزم إن تُركت مفتوحة دائماً تلتهم السجلّ فلا تنفع إلا بضبط SACL مضيَّق أو لفترة عزل محدودةمفتوحة دائماًSACL مضيَّق الهدفلفترة عزل محدودةفئات فرعيّة كثيرة الأحداثكيف تفعِّلها؟تدقيق الوصول إلى الكائناتاستخدام الامتيازات ومرشّح الحزمتلتهم السجلّتنفعتنفع

الشكل 5: لا تترك الوصول إلى الكائنات واستخدام الامتيازات مفتوحين دائماً. لا ينفعان إلا بتضييق الهدف والمدّة.

4. كيفيّة قراءة معرِّفات الأحداث الثابتة

4.1. 4624 ── نجاح تسجيل الدخول يُفرَز بنوع تسجيل الدخول

4624، «تمّ تسجيل دخول حساب بنجاح»، يُسجَّل على الآلة التي أُنشئت عليها جلسة تسجيل الدخول (الآلة التي جرى الوصول إليها).5 ولأنّه حدث عالي الكمّ، أوّل خطوة في قراءته الفرز بـ Logon Type.5

نوع تسجيل الدخول الاسم معناه عمليّاً
2 Interactive تسجيل دخول على وحدة التحكّم الخاصّة بذلك الحاسوب
3 Network وصول عبر الشبكة (مجلّدات مشتركة، أدوات إدارة، وغيرها). الأكثر شيوعاً، لأنّه يطلق مرّة لكلّ آلة
4 Batch تنفيذ دفعيّ (مهام مجدولة وغيرها)
5 Service بدء خدمة (عبر مدير التحكّم بالخدمات)
7 Unlock إلغاء قفل الشاشة
8 NetworkCleartext تسجيل دخول شبكيّ مُرِّرت فيه كلمة المرور إلى حزمة المصادقة بنصّ واضح
9 NewCredentials استنساخ رمزة قائمة ببيانات اعتماد بديلة (مكافئ runas /netonly)
10 RemoteInteractive سطح المكتب البعيد
11 CachedInteractive تسجيل دخول ببيانات اعتماد مخزَّنة مؤقتاً (عندما تعذَّر بلوغ DC)

حقول أخرى يجدر النظر إليها معها: اسم الحساب تحت «New Logon»، وعنوان المصدر تحت «Network Information»، و«Authentication Package» (NTLM أو Kerberos)، و«Elevated Token» (هل للجلسة امتياز مسؤول). إن أردت تتبّع تسجيلات الدخول بامتياز المسؤول فقط، يفيد أيضاً الحدث 4672 (Special privileges assigned to new logon) المسجَّل تحت نفس Logon ID.5

خطوات قراءة 4624 وتمييزهأحداث 4624 الكثيرة تُفرَز أوّلاً بنوع تسجيل الدخول ثم تُفحَص اسم الحساب والمصدر وحزمة المصادقة والرمزة المرتفعة وتُضاهاة تسجيلات الدخول بامتياز المسؤول مع 4672 لنفس معرِّف تسجيل الدخول4624 نجاح تسجيل الدخولفرز بنوع تسجيل الدخولفحص الحقول الرئيسةاسم الحساب والمصدرحزمة المصادقةالرمزة المرتفعةتتبّع امتياز المسؤول4672 لنفس Logon ID

الشكل 6: افرز 4624 بنوع تسجيل الدخول ثم اقرأ الحقول. اربط تسجيل الدخول المتميّز بـ 4672.

4.2. 4625 ── ثبِّت سبب الفشل برمز Status/Sub Status

4625، «فشل تسجيل دخول حساب»، يُسجَّل على الآلة التي جرت عليها محاولة تسجيل الدخول.6 بدل الوثوق بصياغة حقل «Failure Reason»، القراءة الموثوقة هي رمز Status/Sub Status السداسيّ عشر. الثوابت كالتالي.6

  • 0xC0000064: اسم مستخدم غير موجود. تتابع سريع في نافذة قصيرة يمكن أن يدلّ على هجوم تعداد حسابات
  • 0xC000006A: كلمة مرور خاطئة. إخفاقات متكرِّرة على حساب معيّن يمكن أن تدلّ على هجوم تخمين كلمة مرور
  • 0xC000006D: اسم مستخدم أو معلومات مصادقة غير صالحة
  • 0xC000006F: خارج ساعات تسجيل الدخول المسموحة
  • 0xC0000070: من محطّة عمل غير مسموحة
  • 0xC0000072: حساب عطَّله مسؤول (محاولات حساب موظّف سابق تظهر هنا)
  • 0xC000015B: نوع تسجيل الدخول المطلوب غير مسموح على هذه الآلة
  • 0xC0000193: حساب منتهٍ
  • 0xC0000234: مقفول

«من، ومن أين، ولماذا فشل» تُثبَّت بثلاثيّة الحساب المستهدف، والمصدر (اسم محطّة العمل / عنوان IP)، وهذا الرمز. الفصل 6 يتضمّن PowerShell يستخرج الثلاثة معاً دفعة واحدة.

تدفّق تثبيت سبب فشل 4625سبب فشل 4625 يُثبَّت برمز Status/Sub Status السداسيّ عشر وبعد قراءة دلالة الرمز على هجوم محتمل تُحدَّد الحالة بثلاثيّة الحساب المستهدف والمصدر والرمزتتابع 0xC0000064تتابع 0xC000006A0xC00000724625 فشل تسجيل الدخولفحص رمز Sub Statusما اتّجاه الرمز؟دلالة تعداد حساباتدلالة تخمين كلمة مرورمحاولة حساب موظّف سابقالتثبيت بالثلاثيّةالحساب المستهدف+المصدر+الرمز

الشكل 7: ثبِّت سبب الفشل بالرمز، واقرأه بثلاثيّة الحساب المستهدف والمصدر والرمز.

4.3. 4740 ── مصدر القفل هو «Caller Computer Name»

4740، «تمّ قفل حساب مستخدم» (الفئة الفرعيّة: User Account Management). الحقل المحوريّ في هذا الحدث هو «Caller Computer Name»، ويسجِّل الحاسوب الذي صدرت منه محاولة تسجيل الدخول التي أشعلت القفل.16 الإجراء الثابت تحديد آلة المصدر من هذا الحقل، ثم غسل بيانات الاعتماد القديمة ما تزال مخزَّنة على تلك الآلة. في معظم الحالات السبب شيء يواصل استخدام بيانات قديمة بعد تغيير كلمة المرور ── بيانات محفوظة، أو جلسة RDP مقطوعة متروكة، أو خدمة أو مهمّة مجدولة مضبوطة بكلمة المرور القديمة.

الإجراء الثابت لتحقيق قفل الحسابحدِّد الجهاز المصدر من اسم الحاسوب المستدعي في 4740 ثم اغسل بيانات الاعتماد القديمة المتبقّية عليه بيانات محفوظة وجلسة RDP مقطوعة متروكة وخدمة أو مهمّة بكلمة مرور قديمة4740 حدوث قفل حسابفحص اسم الحاسوب المستدعيتحديد الجهاز المصدراغسل بيانات الاعتماد القديمةبيانات اعتماد محفوظةجلسة RDP مقطوعة متروكةخدمة أو مهمّة بكلمة مرور قديمة

الشكل 8: حدِّد المصدر من «اسم الحاسوب المستدعي» في 4740، ثم اغسل بيانات الاعتماد القديمة على ذلك الجهاز.

ثمّة أمر واحد يستحق الانتباه. 4625 يُسجَّل على الحاسوب الذي استقبل محاولة تسجيل الدخول. إن كان السبب تسجيل دخول شبكيّاً من آلة المصدر إلى خادم ملفّات مثلاً، لا يبقى 4625 في سجلّ Security الخاصّ بآلة المصدر نفسها؛ بل يبقى الأثر في 4625 على خادم الوجهة، أو لحساب نطاق في 4776 (NTLM) أو 4771 (فشل المصادقة المسبقة لـ Kerberos) على DC.78 عندما «لا شيء في سجلّ آلة المصدر»، اذهب وانظر جانب الاستقبال.

الآلة التي تبقى فيها أثر الفشلفشل تسجيل الدخول الشبكيّ لا يبقى على الجهاز المصدر نفسه بل يُسجَّل في 4625 على خادم الوجهة الذي استقبل المحاولة وإن كان حساب نطاق يبقى أثر أيضاً في 4776 أو 4771 على متحكّم النطاقتسجيل دخول شبكيّمصادقة حساب نطاقالجهاز المصدر（لا يبقى عليه 4625）خادم الوجهةيُسجَّل 4625متحكّم النطاق4776（NTLM）/4771（Kerberos）

الشكل 9: 4625 يبقى على الجانب الذي استقبل المحاولة. إن لم يوجد شيء على الجهاز المصدر، انظر خادم الوجهة ومتحكّم النطاق.

4.4. عائلة 4720 ── إنشاء الحساب وتعديله وإضافات المجموعات

أحداث إدارة الحسابات تشكِّل سلسلة أرقام متجاورة: 4720 (إنشاء حساب مستخدم)17، و4726 (حذف)، و4738 (تعديل)، وعلى جانب المجموعة إضافة عضو/إزالته. لاحظ أنّ معرِّف الحدث الذي يُطلَق لتغيير عضويّة مجموعة يعتمد على نوع المجموعة. 4732/4733 للمجموعات المحلّيّة، و4728/4729 للعامّة، و4756/4757 للشاملة.14 Domain Admins مجموعة عامّة، لذا تظهر إضافة إليها 4728 ── إن نبَّهت على 4732 فقط، فاتك بالضبط الحدث الذي تريد التقاطه أكثر من غيره. يوميّاً هذا في الغالب سجلّ عمل مكتب المساعدة، لكن «مستخدم قياسيّ أُضيف فجأة إلى مجموعة إداريّة» أو «أُنشئ حساب لا يعرفه أحد» يستحقّ التحقيق ولو وقع مرّة واحدة. مايكروسوفت نفسها تعطي الإضافات غير المتوقَّعة لأعضاء إلى مجموعات متميّزة مثالاً على حدث يستحقّ تنبيهاً منفرداً.3

نوع المجموعة وحدث إضافة عضوإضافة عضو إلى مجموعة تنقسم فيها معرِّفات الأحداث حسب نوع المجموعة المحلّيّة 4732 والعامّة 4728 والشاملة 4756 لذا إضافة إلى Domain Admins وهي مجموعة عامّة تُرى في 4728محلّيّةعامّةشاملةإضافة عضو إلى مجموعةما نوع المجموعة؟تُسجَّل في 4732تُسجَّل في 4728تُسجَّل في 4756إضافة Domain Admins هنامراقبة 4732 وحدها تُسقط الحدث

الشكل 10: معرِّف حدث إضافة عضو ينقسم حسب نوع المجموعة. الإضافة إلى Domain Admins هي 4728.

4.5. 4688 ── إنشاء العمليّة. تسجيل سطر الأوامر مفتاح منفصل

4688، «أُنشئت عمليّة جديدة»، يسجِّل حساب الإنشاء، ومسار الملفّ التنفيذيّ للعمليّة الجديدة، والعمليّة الأصل، ونوع رفع الرمزة في كلّ مرّة تُنشأ عمليّة.11 حدث ذو قيمة تحقيقيّة عالية يستطيع الإجابة عن «من نفَّذ ماذا على هذا الخادم».

غير أنّه افتراضيّاً لا تُسجَّل وسيطات سطر الأوامر. فقط متى فعَّلت على حدة إعداد نهج المجموعة «Include command line in process creation events» (Administrative Templates > System > Audit Process Creation) يُملأ حقل «Process Command Line» في 4688 بالوسيطات.1112 هذا في الواقع ضروريّ لتتبّع إطلاقات مريبة مثل powershell -EncodedCommand ...، لكن لا تفعِّله إلا بعد فهم خطر انكشاف الأسرار الموصوف في الفصل 7.

علاقة 4688 بتسجيل سطر الأوامرتفعيل تدقيق إنشاء العمليّة يسجِّل في 4688 الحساب ومسار الملفّ التنفيذيّ والعمليّة الأصل لكن وسيطات سطر الأوامر لا تُسجَّل إلا بعد تفعيل نهج مجموعة منفصل وفيها خطر ظهور أسرار بنصّ واضحكما هو افتراضيّاًتفعيل GPO إضافيّتفعيل تدقيق إنشاء العمليّةيُسجَّل 4688الحساب والمسار والعمليّة الأصلتريد الوسيطات أيضاً؟سطر الأوامر فارغتُسجَّل الوسيطاتخطر ظهور أسرار بنصّ واضح

الشكل 11: تسجيل سطر أوامر 4688 مفتاح منفصل. افحص خطر اختلاط الأسرار قبل التفعيل.

4.6. 4698 ── إنشاء مهمّة مجدولة

4698، «أُنشئت مهمّة مجدولة»، يسجِّل اسم المهمّة وXML تعريف المهمّة كاملاً (بما فيه الأمر الذي تشغِّله). ولأنّ تسجيل مهمّة مجدولة أسلوب شائع تستخدمه البرمجيّات الخبيثة للبقاء بعد إعادة التشغيل، توصي مايكروسوفت بمراقبة أحداث إنشاء المهمّات.15 حتّى في البيئات التي تستخدم المهام المجدولة بكثافة لأغراض الأعمال، الإنشاء نفسه ليس شيئاً يحدث كلّ يوم، فتبقى الضوضاء صغيرة نسبيّاً.

الاستمرار بتسجيل مهمّة و4698البرمجيّات الخبيثة تستخدم تسجيل مهمّة مجدولة وسيلة معتادة للبقاء بعد إعادة التشغيل لذا مراقبة 4698 المسجَّل عند إنشاء المهمّة تتيح تتبّع تعريف المهمّة بما فيه أمر التنفيذاستمرار البرمجيّة الخبيثةتسجِّل مهمّة لتبقىيُسجَّل 4698XML كامل يتضمّن أمر التنفيذكشف بمراقبة إنشاء المهمّةالإنشاء ليس يوميّاً والضوضاء قليلة

الشكل 12: تسجيل المهمّة، الوسيلة المعتادة للاستمرار، يبقى في 4698. XML التعريف الكامل يوصل حتّى أمر التنفيذ.

وثمّة واحد آخر يستحقّ التذكّر: 1102، «تمّ مسح سجلّ التدقيق». مسح سجلّ Security يترك هذا الحدث دائماً، لذا إن وجدت «السجلّ فارغ»، يتيح لك تمييز حادث عن عمليّة روتينيّة.18

تمييز مسح السجلّ بـ 1102مسح سجلّ Security يترك دائماً 1102 لذا عندما يكون السجلّ فارغاً تفحص وجود 1102 فتميِّز هل كان ثمّة عمليّة مسح أم يُشتبه بحادثنعملاالسجلّ فارغالمسح يترك دائماً 1102هل يوجد 1102؟حدثت عمليّة مسحاشتبه بحادث

الشكل 13: مسح سجلّ Security يترك دائماً 1102. السجلّ الفارغ يُميَّز حادثاً أو عمليّة بوجود 1102 أو غيابه.

5. تصميم وعاء السجلّ ── الحجم الأقصى والاحتفاظ

قبل أن تزيد سياسة التدقيق، افحص الوعاء المستقبِل. لسجلّ Security حجم أقصى ووضع احتفاظ: في وضع الكتابة فوق (التكوين المعتاد)، متى بلغ الحجم الأقصى، تكتب الأحداث الجديدة فوق أقدمها. بالمقابل، في وضع الاحتفاظ (عدم الكتابة فوق)، متى امتلأ السجلّ، الأحداث الجديدة هي التي تُهمَل بدل ذلك.10 أيّ السلوكين يمكن أن يتركك بـ«السجلّ الذي احتجته غير موجود»، لذا فهم الحالة الحاليّة يأتي أوّلاً.

# فحص وعاء سجلّ Security: وضع الاحتفاظ، الحجم الأقصى، العدد الحاليّ
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# كم يوماً يبقى فعليّاً الآن (وقت أقدم حدث)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog يعيد تكوين السجلّ وعدد السجلّات معاً.9 الفرق بين «وقت أقدم حدث» والوقت الحاليّ هو مدّة الاحتفاظ الفعليّة؛ إن قصرت عن متطلّبك (كم يوماً تريد أن تقدر على الرجوع إليه في تحقيق حادث)، وسِّع الحجم الأقصى. يمكنك ضبط هذا بـ wevtutil sl Security /ms:<عدد البايتات>، أو توزيعه عبر نهج المجموعة.10

تصميم السعة بالعدّ العكسيّ من أيّام الاحتفاظافحص التكوين والعدد بـ ListLog لـ Get-WinEvent واحسب أيّام الاحتفاظ الفعليّة من وقت أقدم حدث وإن قصرت عن الأيّام التي تريد الرجوع إليها في تحقيق حادث وسِّع الحجم الأقصىتكفيلا تكفيافحص التكوين والعدد بـ ListLogافحص وقت أقدم حدثاحسب أيّام الاحتفاظ الفعليّةهل تكفي المتطلّبات؟أبقِ الحجم الحاليّوسِّع الحجم الأقصىاضبط بـ wevtutil sl أو GPO

الشكل 14: تأكَّد من الأيّام المتبقّية فعليّاً، واحسب الحجم الأقصى عدّاً عكسيّاً من الأيّام التي تريد الرجوع إليها.

وثمّة أيضاً خيار أمن اسمه «Audit: Shut down system immediately if unable to log security audits» (المعروف بـ CrashOnAuditFail). متى فُعِّل، إن صار النظام عاجزاً عن تسجيل حدث تدقيق، توقّف بخطأ STOP C0000244. موجود لمتطلّبات مصادقة لا تحتمل إضاعة أثر تدقيق إطلاقاً، وهو معطَّل افتراضيّاً. مايكروسوفت نفسها تحذِّر أنّ هذا يمكن تحويله إلى DoS، بمهاجم يولِّد عمداً سيلاً من الأحداث لإيقاف خادم ── لذا ليس شيئاً يُفعَّل باستخفاف في بيئة صغيرة ومتوسّطة معتادة.19

السلوك عند امتلاء السجلّتكوين الاحتفاظ وضعان الكتابة فوق وعدم الكتابة فوق وعندما يتعذّر تسجيل التدقيق في وضع عدم الكتابة فوق إن كان CrashOnAuditFail مفعَّلاً وهو إعداد منفصل يتوقّف النظام بخطأ STOP C0000244وضع الكتابة فوقعدم الكتابة فوقنعمسجلّ Security بلغ الحجم الأقصىما تكوين الاحتفاظ؟يُكتَب فوق أقدم الأحداثتُهمَل الأحداث الجديدةكلاهما سبب لا سجلّ حين تنتبهCrashOnAuditFail مفعَّل أيضاً؟توقّف بخطأ STOP C0000244

الشكل 15: تكوين الاحتفاظ وضعان: كتابة فوق أو إهمال. CrashOnAuditFail إعداد منفصل يوقف النظام عندما يتعذّر التسجيل.

6. التحقيق عمليّاً ── التصفية، وGet-WinEvent، والتصدير

6.1. التضييق في عارض الأحداث

لتحقيق لمرّة واحدة، عارض الأحداث يكفي. افتح سجلّ Security وحدِّد معرِّف حدث (مثلاً 4625) ونطاقاً زمنيّاً بـ «Filter Current Log». احفظ الشروط التي تفحصها مراراً كـ «Custom View» فتصير نقراً واحداً في المرّة التالية. إن أردت التضييق بحساب معيّن لا بمعرِّف حدث فقط، يمكنك تحرير استعلام XPath مباشرةً في علامة تبويب XML بحوار المرشّح.

6.2. الاستخراج بـ Get-WinEvent

للتحقيقات ذات عدد سجلّات كبير، أو شروط متعدّدة، أو تشغيل دوريّ، حوِّل إلى Get-WinEvent في PowerShell. النقطة الجوهريّة استخدام -FilterHashtable، الذي يطبِّق المرشّح على جانب الخادم.9

المفاضلة بين وسائل التحقيقالتحقيق لمرّة واحدة يكفي فيه مرشّح عارض الأحداث والشروط التي تعود إليها تُحفَظ في عرض مخصَّص والتحقيق كثير العدد أو متعدّد الشروط أو الدوريّ يُحوَّل إلى Get-WinEventمرّة واحدةشروط تعود إليهاكمّ كبير ومتعدّد ودوريّأيّ نوع تحقيق؟تصفية بعارض الأحداثاحفظها في عرض مخصَّصحوِّل إلى Get-WinEventصفِّ بـ FilterHashtable

الشكل 16: المرّة الواحدة عارض الأحداث، والتكرار عرض مخصَّص، والكمّ الكبير Get-WinEvent.

# جلب فشل تسجيل الدخول (4625) في آخر 24 ساعة
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# تشكيل «من، من أين، ولماذا» في جدول
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

متى ملكت هذا القالب لسحب EventData من تمثيل XML للحدث، أعدت استخدامه كما هو لـ 4624 أو 4688. تصميم تصفية Get-WinEvent ── متى تستخدم FilterHashtable مقابل XPath، وكيف تصلح استعلاماً بطيئاً ── مشروح بالتفصيل في «تحقيق سجلّ الأحداث عمليّاً بـ Get-WinEvent ── سرعة التصفية تحدّد مدّة التحقيق».

قالب سحب EventData وتنسيقهتحويل الأحداث المسترجَعة بـ Get-WinEvent إلى تمثيل XML وسحب حقول EventData وتنسيقها جدولاً قالب يُعاد استخدامه بالمنوال نفسه لـ 4624 أو 4688 لا لـ 4625 وحدهااسترجع بـ Get-WinEventحوِّل الحدث إلى تمثيل XMLاسحب EventDataنسِّق جدولاً وجمِّعالمنوال نفسه لـ 4624 و4688

الشكل 17: قالب سحب EventData من تمثيل XML وتنسيقه جدولاً يُعاد استخدامه ولو تغيّر معرِّف الحدث.

6.3. التصدير بـ wevtutil

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

rem حفظ سجلّ Security بالكامل كملفّ evtx
wevtutil epl Security C:\logs\security-20260801.evtx

rem تصدير أحداث 4625 فقط، مضيَّقة بـ XPath
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

ملفّ .evtx مُصدَّر يمكن تحليله على آلة أخرى بالمنوال نفسه تماماً، بـ Get-WinEvent -Path C:\logs\security-20260801.evtx.9 عادة الحفظ قبل التحليل هي العقلية نفسها «أمِّن التفريغ أوّلاً» في تحقيق الانهيار (انظر «مدخل إلى جمع ملفّات تفريغ انهيار Windows - WER/ProcDump/WinDbg»).

تدفّق الحفظ ثم التحليلصدِّر سجلّ Security على الآلة قيد التحقيق بـ wevtutil epl إلى ملفّ evtx لتحفظه ثم حلِّله بالمنوال نفسه على آلة أخرى عبر Path في Get-WinEventالآلة قيد التحقيقاحفظ evtx بـ wevtutil eplانقل إلى آلة أخرىحلِّل بـ Get-WinEvent -Pathاحفظ قبل أن تمحوه الكتابة فوق

الشكل 18: احفظ أوّلاً، ثم حلِّل. إن أمَّنته في evtx استطعت التحقيق بالمنوال نفسه على آلة أخرى.

7. المطبات ── أربعة يسهل الوقوع فيها في الميدان

(1) أسرار تهبط في سطر أوامر 4688. تفعيل تسجيل سطر الأوامر يضع وسيطات كلّ عمليّة في سجلّ Security بنصّ واضح. مايكروسوفت تنصّ صراحةً على أنّ «أيّ مستخدم يملك صلاحية قراءة أحداث الأمن يستطيع قراءة وسيطات سطر الأوامر لكلّ عمليّة أُنشئت بنجاح. وقد تتضمّن وسيطات سطر الأوامر معلومات حسّاسة أو خاصّة مثل كلمات المرور.»12 إن وُجد تطبيق أعمال واحد أو سكربت واحد يطلق شيئاً مثل myapp.exe /user:admin /password:P@ssw0rd، فذلك سرّ مكشوف لكلّ من يستطيع عرض السجلّ. قبل التفعيل، امسح المواضع التي تمرِّر أسراراً وسيطات سطر أوامر وأصلحها. حيث تصدِّر السجلّ أو تعيد توجيهه يحتاج أيضاً تعاملاً بمستوى السرّيّة نفسه.

ترتيب تفعيل تسجيل سطر الأوامرقبل تفعيل تسجيل سطر أوامر 4688 امسح تطبيقات الأعمال والسكربتات التي تمرِّر أسراراً وسيطات وأصلح المواضع المعنيّة ثم فعِّل واطلب مستوى التعامل نفسه في وجهة الحفظ وإعادة التوجيهنعملاامسح تمرير الأسرار وسيطاتهل ثمّة موضع؟أصلح المواضع التي تمرِّرفعِّل تسجيل سطر الأوامروجهة الحفظ والنقل بالمستوى نفسه

الشكل 19: تسجيل سطر الأوامر «امسح وأصلح ثم فعِّل». عكس الترتيب يجعله نشراً للأسرار.

(2) التشغيل دون معرفة ما يحدث عندما يمتلئ السجلّ. في وضع الكتابة فوق، يختفي الأثر القديم بهدوء؛ وفي وضع عدم الكتابة فوق، تُهمَل الأحداث الجديدة؛ ومع CrashOnAuditFail مفعَّلاً، يتوقّف النظام كلّه (الفصل 5).1019 المنهج الصحيح أن تعرف أيّ سلوك اخترت، وأن تضع آليّة ── تصديرات مجدولة، أو منصّة جمع سجلّات ── تجمع البيانات قبل أن تُمحى بالكتابة فوق.

(3) متحكّمات النطاق ومحطّات العمل تتطلّب النظر في سجلّات مختلفة. 4624/4625 يُسجَّلان على الآلة التي جرى الوصول إليها.56 بالمقابل، تحقّق بيانات الاعتماد لحساب نطاق (4776 لـ NTLM) يُسجَّل على الآلة التي لها سلطة على بيان الاعتماد ── لحساب نطاق، ذلك هو DC7 ── وفشل المصادقة المسبقة لـ Kerberos (4771) يُسجَّل على DC فقط.8 «لا 4625 على خادم الملفّات» لا يعني «لم يكن ثمّة هجوم»؛ لا تكتمل الصورة إلا بعد مضاهاة 4776/4771 على DC أيضاً. انظر «NTLM وKerberos مشروحان بالرسوم ── لماذا تسقط المصادقة إلى NTLM» لكيفيّة تدفّق كلّ بروتوكول مصادقة فعليّاً.

(4) انحراف الساعة يكسر المضاهاة. صفّ سجلّات عدّة آلات لتتبّع «أيّ محطّة أنتجت 4625 مباشرة قبل هذا 4740» لا يعمل إلا إن اتفقت ساعة كلّ آلة. في بيئة نطاق، Kerberos نفسه يضع حدّاً أعلى لانحراف الساعة (5 دقائق افتراضيّاً)، وبعده تبدأ المصادقة نفسها بالفشل.20 من منظور التحقيق، انحراف ثوانٍ ── فضلاً عن خمس دقائق ── يمكن أن يدفعك إلى إساءة قراءة ترتيب الأحداث، لذا ينبغي أن يكون فحص حالة مزامنة w32time أوّل خطوة في إجراء التحقيق. وتذكَّر أيضاً أنّ أوقات الأحداث تُحفَظ بـ UTC وتُعرَض حسب المنطقة الزمنيّة لآلة العرض، فلا تنسَ تحويل المناطق الزمنيّة عند قراءة .evtx جُلب من موقع في الخارج أو خادم مضبوط على UTC.

مزامنة الوقت وفرضيّة تحقيق المضاهاةتحقيق مضاهاة سجلّات عدّة آلات حسب الوقت يفترض أنّ ساعات الآلات متوافقة وانحراف ثوانٍ يُخطئ قراءة الترتيب وانحراف يتجاوز 5 دقائق افتراضيّاً يفشل مصادقة Kerberos نفسها لذا اجعل فحص مزامنة w32time أوّل خطوة التحقيقمتوافقةانحراف ثوانٍيتجاوز 5 دقائق افتراضيّاًمضاهاة سجلّات عدّة آلاتتوافق الساعات فرضيّةما انحراف الساعة؟تُتتبَّع حسب الوقتخطأ في قراءة الترتيبتفشل مصادقة Kerberosفحص w32time أوّل الخطوة

الشكل 20: مضاهاة عدّة آلات تفترض ضبط الساعات. انحراف ثوانٍ يكفي لإساءة قراءة الترتيب.

8. الخلاصة

  • لسياسة التدقيق نظامان، «أساسيّ» و«مفصَّل»، وخلطهما يُنتج نتائج غير متوقَّعة. وحِّد على الجانب المفصَّل، افحص الحالة الحاليّة بـ auditpol /get /category:*، وصمِّم من هناك.
  • «تفعيل الكلّ» يقتل تحقيقك بالضوضاء والتضخّم. ابدأ من توصيات خطّ الأساس لدى مايكروسوفت واعمل عبر جدول القرار في الفصل 3، المبنيّ حول تسجيل الدخول وإدارة الحسابات وإنشاء العمليّات.
  • 4624 يُقرأ بنوع تسجيل الدخول، و4625 برمز Status/Sub Status، و4740 بـ Caller Computer Name، و4688 بالعمليّة الأصل وسطر الأوامر ── لكلّ حدث حقل معيّن يلزم فحصه.
  • وعاء السجلّ (الحجم الأقصى ووضع الاحتفاظ) نصف تصميم التدقيق. افحص كم يوماً يبقى فعليّاً، حدِّد الحجم عدّاً عكسيّاً من متطلّبك، وصدِّر أو جمِّع قبل أن تمحوه الكتابة فوق.
  • دقِّق خطر انكشاف الأسرار قبل تفعيل تسجيل سطر الأوامر لـ 4688. أين يُسجَّل كلّ حدث، ومزامنة الساعة، فرضيّتان لمضاهاة عبر الآلات.
  • ابدأ التحقيق بمرشّحات عارض الأحداث؛ حوِّل إلى Get-WinEvent -FilterHashtable لأيّ شيء متكرِّر؛ احفظ بـ wevtutil epl. لا تكسر ترتيب «احفظ أوّلاً، ثم حلِّل».

مقالات ذات صلة

مجالات الاستشارة ذات الصلة

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

روابط مرجعيّة

  1. Microsoft Learn, Advanced security auditing FAQ. حول الفرق بين سياسة التدقيق الأساسيّة (الإعدادات التسعة تحت Local Policies) وسياسة التدقيق المفصَّلة؛ وحول تفعيل فئة أساسيّة واحدة يكافئ تفعيل كلّ فئاتها الفرعيّة المقابلة؛ وحول عدم توافق النظامين، واستخدامهما معاً يترك نتائج التدقيق في حالة غير متوقَّعة لذا لا يجوز خلطهما؛ وحول تطبيق الجانب المفصَّل عبر نهج المجموعة يمسح إعدادات التدقيق القائمة؛ وحول لزوم تفعيل «Audit: Force audit policy subcategory settings to override audit policy category settings»؛ وحول تقليل كمّ الأحداث بتحديد الموارد والأنشطة والمستخدمين المهمّين وتضييق النطاق إليهم. ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, auditpol. حول قدرة أمر auditpol على عرض سياسة تدقيق النظام (/get)، وضبطها (/set)، والنسخ الاحتياطيّ إلى CSV (/backup)، والاستعادة (/restore)، والمسح (/clear). ↩ ↩2

  3. Microsoft Learn, System Audit Policy recommendations. حول جدول قيم Windows الافتراضيّة وتوصيات خطّ الأساس والتوصيات الأقوى مفصَّلة حسب محطّة العمل والخادم؛ وحول كون التوصيات نقطة انطلاق فقط، تُراجَع وتُختبَر وفق تهديدات كلّ منظّمة وتحمّلها للخطر؛ وحول فئة Logon الفرعيّة مفعَّل فيها النجاح والفشل كليهما افتراضيّاً منذ Windows 10 1809 فما بعد؛ وحول أهمّيّة مراقبة محطّات العمل بقدر مراقبة الخوادم؛ وحول أمثلة أحداث تستحقّ تنبيهاً منفرداً، كإضافات أعضاء غير متوقَّعة إلى مجموعات متميّزة؛ وحول كشف طفرات فشل تسجيل الدخول بالمقارنة مع خطّ أساس. ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. حول إمكان إدارة التدقيق بدقّة عبر أكثر من 40 فئة فرعيّة؛ وحول إبقاء هذا الإعداد مفعَّلاً ممارسة فضلى، والقيمة الافتراضيّة Enabled للعملاء وخوادم الأعضاء وDC على حدّ سواء؛ وحول التحذير أنّ إعدادات تولِّد كمّاً هائلاً من الأحداث، كتفعيل تدقيق النجاح لفئة استخدام الامتيازات الفرعيّة كلّها، تجعل إيجاد مدخلات أخرى في سجلّ الأمن صعباً ويمكن أن تؤثّر تأثيراً كبيراً على الأداء. ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, 4624(S): An account was successfully logged on. حول تسجيل 4624 على الآلة التي جرى الوصول إليها عند إنشاء جلسة تسجيل الدخول؛ وحول قائمة أنواع تسجيل الدخول (2 = Interactive، 3 = Network، 4 = Batch، 5 = Service، 7 = Unlock، 8 = NetworkCleartext، 9 = NewCredentials، 10 = RemoteInteractive، 11 = CachedInteractive)؛ وحول علامة Elevated Token؛ وحول Authentication Package (NTLM/Kerberos/Negotiate) وPackage Name لـ NTLM (NTLM V1/V2/LM)؛ وحول المضاهاة عبر Logon ID مع أحداث مثل 4672. ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, 4625(F): An account failed to log on. حول تسجيل 4625 على الحاسوب الذي جرت عليه محاولة تسجيل الدخول (لمحاولة على محطّة المستخدم، تلك المحطّة)؛ وحول فئتيه الفرعيّتين Account Lockout وLogon؛ وحول معنى رموز Status/Sub Status (0xC0000064 = اسم مستخدم سيّئ، 0xC000006A = كلمة مرور خاطئة، 0xC000006D = اسم مستخدم أو معلومات مصادقة سيّئة، 0xC000006F = خارج ساعات تسجيل الدخول المسموحة، 0xC0000070 = محطّة عمل غير مسموحة، 0xC0000072 = حساب معطَّل، 0xC000015B = نوع تسجيل دخول غير مسموح، 0xC0000193 = حساب منتهٍ، 0xC0000234 = مقفول)؛ وحول تكرار 0xC0000064 يمكن أن يدلّ على هجوم تعداد حسابات. ↩ ↩2 ↩3 ↩4 ↩5

  7. Microsoft Learn, 4776(S, F): The computer attempted to validate the credentials for an account. حول تسجيل 4776 لكلّ تحقّق من بيانات اعتماد يُجرى لمصادقة NTLM؛ وحول التسجيل فقط على الحاسوب الذي له سلطة على بيان الاعتماد ── متحكّم النطاق لحساب نطاق، أو الحاسوب المحلّيّ لحساب محلّيّ؛ وحول تسجيل النجاح والفشل كليهما. ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn, 4771(F): Kerberos pre-authentication failed. حول تسجيل 4771 لكلّ فشل من KDC في إصدار TGT لـ Kerberos (كلمة مرور خاطئة، انتهاء، وغيرها)؛ وحول توليد هذا الحدث على متحكّمات النطاق فقط. ↩ ↩2 ↩3 ↩4

  9. Microsoft Learn, Get-WinEvent (Microsoft.PowerShell.Diagnostics). حول استرجاع تكوين السجلّ (LogMode، MaximumSizeInBytes، RecordCount) عبر -ListLog؛ وحول التصفية الكفؤة عبر -FilterHashtable محدَّداً كجدول تجزئة من LogName وId وStartTime وغيرها؛ وحول قراءة ملفّ .evtx محفوظ عبر -Path؛ وحول استرجاع الأحداث من الأقدم وعدّاً عبر -Oldest / -MaxEvents. ↩ ↩2 ↩3 ↩4

  10. Microsoft Learn, wevtutil. حول ضبط الحجم الأقصى (/ms) ووضع الاحتفاظ (/rt) عبر set-log (sl)؛ وحول وضع الاحتفاظ true يعني الاحتفاظ بالأحداث القائمة وإهمال الجديدة متى امتلأ السجلّ، بينما false يعني كتابة الأحداث الجديدة فوق أقدم القائمة؛ وحول تصدير سجلّ أحداث إلى ملفّ عبر export-log (epl)، مع خيار /q للتضييق باستعلام XPath؛ وحول تشغيل استعلام عبر query-events (qe). ↩ ↩2 ↩3 ↩4 ↩5

  11. Microsoft Learn, 4688(S): A new process has been created. حول تسجيل 4688 لكلّ بدء عمليّة جديدة؛ وحول تضمّنه حساب المنشئ، ومسار الملفّ التنفيذيّ للعمليّة الجديدة، واسم عمليّة المنشئ (الأصل)، ونوع رفع الرمزة؛ وحول حقل Process Command Line فارغ افتراضيّاً، ولا يُملأ إلا بعد تفعيل إعداد نهج المجموعة «Include command line in process creation events». ↩ ↩2 ↩3

  12. Microsoft Learn, Command line process auditing. حول لزوم تسجيل سطر الأوامر تدقيق إنشاء العمليّة في سياسة التدقيق المفصَّلة و«Include command line in process creation events» كليهما (Administrative Templates > System > Audit Process Creation، غير مضبوط افتراضيّاً)؛ وحول التحذير أنّه متى فُعِّل تُسجَّل معلومات سطر أوامر كلّ عمليّة في سجلّ أحداث الأمن بنصّ واضح، وأيّ مستخدم يملك صلاحية قراءة أحداث الأمن يستطيع قراءة وسيطات سطر الأوامر لكلّ عمليّة أُنشئت بنجاح، وقد تتضمّن معلومات حسّاسة مثل كلمات المرور؛ وحول كتابة الإعدادات الأساسيّة فوق سياسة التدقيق المفصَّلة تولِّد الحدث 4719، وهو ما يمنعه إعداد «الفرض». ↩ ↩2 ↩3 ↩4

  13. Microsoft Learn, Audit Account Lockout. حول فئة Account Lockout الفرعيّة تدقِّق محاولات تسجيل الدخول الفاشلة على حساب مقفول حالياً؛ وحول الحدث المُولَّد 4625(F)؛ وحول عدم وجود أحداث نجاح لهذه الفئة الفرعيّة، لذا تفعيل تدقيق النجاح لها لا فائدة منه؛ وحول توصية تدقيق الفشل عبر كلّ أنواع الحواسيب. ↩

  14. Microsoft Learn, Audit Security Group Management. حول هذه الفئة الفرعيّة تدقِّق إنشاء مجموعات الأمن وتعديلها وحذفها، وإضافة الأعضاء وإزالتهم؛ وحول اختلاف معرِّفات أحداث إضافة/إزالة الأعضاء حسب نوع المجموعة ── 4732/4733 للمحلّيّة، و4728/4729 للعامّة، و4756/4757 للشاملة؛ وحول وجود أحداث مخصَّصة لمجموعات النطاق مثل 4728؛ وحول عدم وجود أحداث فشل لهذه الفئة الفرعيّة، لذا يُوصى بتدقيق النجاح عبر كلّ أنواع الحواسيب. ↩ ↩2

  15. Microsoft Learn, 4698(S): A scheduled task was created. حول تسجيل 4698 لكلّ مهمّة مجدولة تُنشأ؛ وحول فئته الفرعيّة Other Object Access Events؛ وحول تسجيله اسم المهمّة وXML تعريف المهمّة كاملاً، بما فيه الأمر المراد تشغيله؛ وحول التوصية بمراقبة أحداث إنشاء المهمّات، خصوصاً على الآلات المهمّة، لأنّ البرمجيّات الخبيثة تستخدم المهام المجدولة عادةً للبقاء عبر إعادات التشغيل. ↩ ↩2

  16. Microsoft Learn, 4740(S): A user account was locked out. حول تسجيل 4740 لكلّ قفل حساب مستخدم؛ وحول فئته الفرعيّة User Account Management؛ وحول حقل Caller Computer Name يسجِّل اسم الحاسوب الذي صدرت منه محاولة تسجيل الدخول التي تسبَّبت بالقفل. ↩

  17. Microsoft Learn, 4720(S): A user account was created. حول تسجيل 4720 على متحكّمات النطاق وخوادم الأعضاء ومحطّات العمل لكلّ كائن مستخدم جديد يُنشأ؛ وحول فئته الفرعيّة User Account Management. ↩

  18. Microsoft Learn, 1102(S): The audit log was cleared. حول تسجيل الحدث 1102 لكلّ مسح لسجلّ تدقيق أمن Windows. ↩

  19. Microsoft Learn, Audit: Shut down system immediately if unable to log security audits. حول توقّف النظام برسالة STOP هي C0000244 {Audit Failed} إن فُعِّل هذا الإعداد وتعذَّر تسجيل تدقيقات الأمن؛ وحول القيمة الافتراضيّة Disabled؛ وحول إمكان تحويله إلى DoS عبر توليد كمّ كبير من أحداث الأمن عمداً لفرض إيقاف؛ وحول خطر صيرورة بيانات التطبيق غير قابلة للاستخدام بسبب توقّف مفاجئ. ↩ ↩2

  20. Microsoft Learn, Maximum tolerance for computer clock synchronization. حول استخدام Kerberos v5 للطوابع الزمنيّة دفاعاً ضدّ هجمات إعادة التشغيل، ولهذا يُضبط حدّ أقصى للتحمّل (5 دقائق افتراضيّاً وبالتوصية) لانحراف الساعة بين عميل ومتحكّم نطاق، وبعده لا يُعدّ الطابع الزمنيّ أصيلاً. ↩

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

لم نضبط أيّ سياسة تدقيق، فلماذا يظهر 4624 و4625 أصلاً في سجلّ Security؟
لأنّ Windows فيه فئات فرعيّة للتدقيق مفعَّلة افتراضيّاً. فئة «Logon» مثلاً مفعَّل فيها تدقيق النجاح والفشل كليهما افتراضيّاً منذ Windows 10 الإصدار 1809، لذا يُسجَّل 4624 (نجاح) و4625 (فشل) ولو لم تضبط شيئاً بنفسك. غير أنّ الإبقاء على الافتراضيّ يترك كثيراً من الأحداث التي تريدها في التحقيق ── تحقّق بيانات الاعتماد (4776) أو إنشاء العمليّة (4688) مثلاً ── بلا تسجيل. ما المفعَّل في بيئتك تتأكَّد منه بـ `auditpol /get /category:*`. ومن هناك الإجراء العمليّ تفعيل الفئات الفرعيّة الناقصة صراحةً على جانب سياسة التدقيق المفصَّلة.
أريد التحقيق في فشل تسجيل دخول، لكن لا أجد الحدث 4625 في سجلّ Security على الخادم المستهدف. أين أنظر؟
أوّلاً أكِّد المبدأ: 4625 يُسجَّل على «الحاسوب الذي جرت عليه محاولة تسجيل الدخول». فشل تسجيل دخول على جهاز المستخدم يبقى على الجهاز؛ فشل وصول إلى خادم ملفّات يبقى على خادم الملفّات. ثم افحص بـ `auditpol /get /category:*` هل تدقيق الفشل مفعَّل لفئة «Logon» الفرعيّة. لحسابات النطاق كثيراً ما يبقى الأثر بدل ذلك في تحقّق بيانات الاعتماد (4776) أو فشل المصادقة المسبقة لـ Kerberos (4771) على متحكّم النطاق، وعندما لا تستطيع تثبيت الجهاز المعنيّ يكون البدء من جانب DC أسرع في الغالب. إن لم تجد شيئاً بعد ذلك، افحص هل محيت الأحداث الأقدم بالكتابة فوق (قارن الحجم الأقصى للسجلّ بوقت أقدم حدث).
هل ينبغي تفعيل تسجيل سطر الأوامر لإنشاء العمليّة (4688)؟
قيمته التحقيقيّة عالية جدّاً، لكنّه إعداد لا تفعِّله إلا بعد فهم الخطر. متى فُعِّل، تُسجَّل وسيطات سطر أوامر كلّ عمليّة في سجلّ Security بنصّ واضح. إن وُجد سكربت واحد أو تطبيق أعمال واحد يمرِّر كلمة مرور أو مفتاح API وسيطة سطر أوامر، صار ذلك السرّ مرئيّاً لكلّ من يستطيع قراءة سجلّ Security. مايكروسوفت نفسها توثِّق هذا التحذير صراحةً. الترتيب الموصى به أن تفحص أوّلاً هل تمرِّر سكربتاتك أسراراً وسيطات سطر أوامر، وتصلح ما يفعل ذلك، ثم تفعِّل الإعداد.
كم ينبغي أن يكون الحجم الأقصى لسجلّ Security؟
المنهج الصحيح العدّ العكسيّ من «كم يوماً نريد إبقاؤه في اليد»، لا رقم واحد يناسب الجميع. الإعداد الحاليّ وسلوكه الفعليّ تتأكَّد منهما بـ `Get-WinEvent -ListLog Security`؛ الفرق بين وقت أقدم حدث والوقت الحاليّ هو «كم يوماً يبقى فعليّاً الآن». زيادة فئات التدقيق الفرعيّة تزيد كمّ الأحداث، فبعد تغيير الإعداد أعد فحص مدّة الاحتفاظ الفعليّة هذه حتماً. الاستجابة للحوادث تحتاج أحياناً سجلّات من أسابيع أو أشهر سابقة، لذا يطمئنّك إمّا تصدير السجلّ دوريّاً قبل أن تمحوه الكتابة فوق، أو تجميعه على آلة أخرى بآليّة جمع سجلّات.
كيف أحقِّق سبب قفل حساب (4740)؟
أوّل دليل حقل «Caller Computer Name» في الحدث 4740. يسجِّل الحاسوب الذي صدرت منه محاولة تسجيل الدخول الفاشلة التي أشعلت القفل. انتبه مع ذلك أنّ سجلّ الفشل نفسه (4625) يبقى على الجانب الذي استقبل المحاولة، لا على آلة المصدر. إن كان المصدر تسجيل دخول شبكيّاً، اتبعه زمنيّاً عبر 4625 على خادم الوجهة، أو لحساب نطاق عبر 4776/4771 على متحكّم النطاق. متى حدَّدت آلة المصدر، افحص عليها ما يزال يحمل بيانات اعتماد قديمة من قبل تغيير كلمة المرور ── بيانات محفوظة، أو جلسة سطح مكتب بعيد مقطوعة متروكة، أو خدمة أو مهمّة مجدولة مضبوطة بكلمة المرور القديمة. إن تكرَّر القفل، افحص أيضاً هل انحرفت مزامنة الساعة.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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

تواصل معنا
العودة إلى المدونة