ثغرة LegacyHive في Microsoft Windows

ملاحظة مهمة: LegacyHive اسم غير رسمي لثغرة أمنية كُشف عنها في خدمة ملفات تعريف المستخدمين داخل Windows. المعلومات المتاحة ما تزال مبنية على تحليل Proof of Concept وتقارير أمنية أولية، بينما قد تتغير حالة الثغرة عند نشر Microsoft توضيحاً رسمياً أو رقم CVE أو تحديثاً أمنياً مخصصاً.

الخلاصة السريعة:

LegacyHive مرتبطة بخدمة Windows User Profile Service المعروفة باسم ProfSvc.
الاستغلال يتطلب وصولاً محلياً أو القدرة على تشغيل كود بحساب مستخدم داخل الجهاز.
النسخة العلنية من Proof of Concept أظهرت إمكانية تحميل Registry Hive تابع لمستخدم آخر ضمن سياق المستخدم الحالي.
لا يعني نجاح النسخة العلنية الحصول المباشر على كلمات المرور أو صلاحية SYSTEM.
الخطر الأكبر يظهر على أجهزة RDS، والأجهزة المشتركة، ومحطات الإدارة، والأجهزة التي يدخل إليها Administrators.
أفضل دفاع مؤقت هو Least Privilege وApplication Control وEDR ومراقبة السجلات وتحديث Windows وDefender.

LegacyHive Windows Security ProfSvc Registry Hive Privilege Escalation

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

تكمن أهمية LegacyHive في استهدافها للآلية التي يستخدمها Windows لإدارة ملفات Registry الخاصة بالمستخدمين. أي خلل يسمح لمستخدم بتحميل Hive تابع لحساب آخر قد يؤدي إلى كشف إعدادات وبيانات تطبيقات وآثار استخدام لا يفترض أن تكون متاحة له.

ستتعرف في هذا المقال على حقيقة LegacyHive وحدود Proof of Concept المنشور، وكيفية تقييم مستوى الخطر داخل الشركة، والخطوات الدفاعية المناسبة، وأوامر الفحص، وطرق Troubleshooting التي يحتاجها فنيو IT Support ومسؤولو Windows Server.

ما هي LegacyHive ومتى تحتاج إلى التعامل معها؟

يخزن Windows جزءاً كبيراً من إعدادات كل مستخدم داخل ملفات تسمى Registry Hives. عند تسجيل الدخول، تقوم خدمة Windows User Profile Service بتحميل الملفات الخاصة بالمستخدم وربطها بفروع Registry حتى تستطيع التطبيقات وواجهة Windows الوصول إلى إعداداته.

من أشهر هذه الملفات NTUSER.DAT وUsrClass.dat. يحتوي الأول على جزء كبير من إعدادات المستخدم، بينما يحتوي الثاني على إعدادات مرتبطة بـWindows Shell وExplorer وFile Associations وبيانات تطبيقات وآثار استخدام مختلفة.

تعتمد LegacyHive على التلاعب بطريقة تعامل خدمة ProfSvc ذات الصلاحيات المرتفعة مع مسارات الملفات وعمليات تحميل Registry Hives. النسخة العلنية من Proof of Concept أظهرت إمكانية جعل الخدمة تحمل ملف UsrClass.dat تابعاً لمستخدم مستهدف داخل مساحة Registry المتاحة للمستخدم الحالي.

ما الذي أثبته Proof of Concept فعلياً؟

أظهر النموذج المنشور إمكانية الوصول للقراءة إلى Hive تابع لمستخدم آخر. هذا قد يكشف إعدادات تطبيقات، وسجل استخدام Windows Explorer، وبيانات Forensic Artifacts، ومعلومات قد تساعد المهاجم في مرحلة الاستطلاع أو في بناء هجوم إضافي.

لكن من المهم عدم المبالغة في توصيف الخطر. ملف UsrClass.dat لا يحتوي عادةً على Password Hashes الخاصة بحساب Windows، والنسخة العلنية لا تمنح المهاجم تلقائياً صلاحيات Administrator أو SYSTEM.

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

العنصر	وظيفته	الفائدة العملية لفريق IT
Windows User Profile Service	تحميل ملفات المستخدم وإدارة Profile عند تسجيل الدخول والخروج.	تعد سجلات الخدمة نقطة مهمة عند التحقيق في تحميل Profile أو Hive بصورة غير معتادة.
NTUSER.DAT	تخزين قسم كبير من إعدادات Registry الخاصة بالمستخدم.	نسخه أو الوصول إليه من حساب آخر يحتاج إلى مراجعة دقيقة.
UsrClass.dat	تخزين إعدادات Shell وExplorer وClasses الخاصة بالمستخدم.	هو الملف الذي استهدفه Proof of Concept العلني الموصوف في التحليلات.
Registry Hive Loading	ربط ملف Registry بمسار يمكن للنظام أو المستخدم الوصول إليه.	تحميل Hive تابع لمستخدم آخر قد يؤدي إلى Cross-user Data Access.
Oplock وRace Condition	آليات قفل وتوقيت ملفات يمكن إساءة استخدامها لتغيير المسار أثناء عملية حساسة.	توضح لماذا يجب تحليل العملية والتوقيت والمسار معاً، وليس اسم الملف وحده.
EDR أو SIEM	تجميع أحداث العمليات والملفات والـRegistry والحسابات.	ربط سلسلة الأحداث واكتشاف السلوك المشبوه قبل تصعيد الحادث.

متى تصبح LegacyHive أولوية مرتفعة؟

عند وجود عدة مستخدمين على الجهاز نفسه.
على خوادم Remote Desktop Services وSession Hosts.
على أجهزة مشتركة بين موظفين أو ورديات مختلفة.
عندما يدخل فريق الدعم بحسابات Administrator إلى أجهزة المستخدمين.
عند السماح للمستخدم بتشغيل EXE أو PowerShell أو Scripts غير معتمدة.
عند وجود حسابات Local Administrator مشتركة أو غير موثقة.
عندما تكون مراقبة EDR أو تسجيل Process Creation غير مفعلة.

معلومة مهمة: LegacyHive ليست ثغرة Remote Code Execution مستقلة عبر الإنترنت. يحتاج المهاجم أولاً إلى حساب أو جلسة أو قدرة على تشغيل كود داخل Windows. لكن ثغرات Local Privilege Escalation مهمة لأنها قد تصبح المرحلة الثانية بعد التصيد أو سرقة بيانات اعتماد مستخدم عادي.

أفضل الإعدادات والخيارات حسب بيئة العمل

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

جدول قرار مبكر

بيئة العمل	الإجراء الدفاعي المناسب	مستوى الأولوية
جهاز موظف فردي	Standard User، تحديثات Windows، Defender محدث، ومراجعة Local Administrators.	متوسطة
جهاز مشترك	Application Control، إزالة Admin المحلي، ومراقبة أحداث Profiles والملفات.	مرتفعة
خادم RDS	Allowlisting صارم، EDR مركزي، وفصل جلسات الإدارة عن جلسات المستخدمين.	مرتفعة جداً
Domain Controller	منع دخول المستخدمين، استخدام حسابات إدارة منفصلة، وعدم تشغيل ملفات غير موثوقة.	حرجة
محطة إدارة فريق IT	Privileged Access Workstation وWDAC وحساب إداري منفصل.	حرجة
مختبر أمني	VM معزولة، Snapshot، بيانات وهمية، وشبكة غير متصلة بالإنتاج.	حسب الحاجة

WDAC أم AppLocker؟

Windows Defender Application Control أو WDAC يوفر مستوى تحكم أقوى، ويعد مناسباً لمحطات الإدارة والسيرفرات والأنظمة الحساسة. لكنه يحتاج إلى تصميم واختبار دقيقين حتى لا يمنع خدمات أو Drivers أو تطبيقات أساسية.

أما AppLocker فهو أسهل في العديد من البيئات الصغيرة والمتوسطة، ويمكن استخدامه لمنع تشغيل الملفات غير المعتمدة من مجلدات مثل Downloads وTemp وAppData. ابدأ دائماً بوضع Audit Only، ثم راجع الأحداث قبل الانتقال إلى Enforcement.

حسابات الإدارة المنفصلة

من أخطر الممارسات أن يستخدم الفني حساب Domain Admin أو Server Admin لتصفح الإنترنت وفتح البريد والدخول اليومي إلى أجهزة المستخدمين. يجب أن يمتلك الفني حساباً عادياً للعمل اليومي وحساباً إدارياً منفصلاً يستخدم فقط عند تنفيذ مهمة موثقة.

على الأجهزة التي تحتاج إدارة محلية، استخدم Windows LAPS لتوليد كلمة مرور Administrator محلية مختلفة لكل جهاز. بهذه الطريقة لا تؤدي سرقة كلمة مرور جهاز واحد إلى فتح جميع أجهزة الشركة.

هل تحتاج إلى Micropatch غير رسمي؟

قد تظهر حلول مؤقتة من شركات أمنية قبل نشر إصلاح Microsoft الرسمي. لا تجعلها الخيار الافتراضي لجميع الأجهزة. أي Micropatch يعد تعديلاً في سلوك مكون حساس داخل Windows ويجب اختباره على Pilot مع تطبيقات الشركة وEDR وAntivirus وخطة Rollback واضحة.

نصيحة عملية: ابدأ بالإجراءات التي تخفض الخطر دون تغيير عميق في النظام: إزالة Local Admin، فصل حسابات الإدارة، تحديث Defender، منع البرامج غير المعتمدة، ومراجعة وصول EDR إلى جميع الأجهزة الحساسة.

طريقة التجهيز والاستخدام والتنظيم

عامل LegacyHive كتنبيه أمني داخلي يحتاج إلى Inventory وHardening وDetection وPatch Readiness. لا يكفي إرسال رسالة للفريق تقول إن هناك ثغرة جديدة؛ يجب تحويل المعلومة إلى إجراءات قابلة للقياس والمتابعة.

حدد النطاق: احصر إصدارات Windows المستخدمة، والأجهزة المشتركة، وخوادم RDS، ومحطات الإدارة.
راجع الحسابات: استخرج أعضاء Local Administrators وحدد سبب وجود كل حساب.
صنّف الأجهزة: اجعل RDS ومحطات IT والأجهزة متعددة المستخدمين ضمن المجموعة الأولى.
تحقق من Defender: راجع Real-time Protection وBehavior Monitoring وتاريخ Security Intelligence.
تحقق من EDR: تأكد من أن الجهاز يرسل Telemetry وليس ظاهراً فقط داخل لوحة الإدارة.
فعّل السجلات: اجمع أحداث Process Creation وUser Profile Service وRegistry عند توفرها.
طبّق Application Control: ابدأ Audit Mode، ثم أنشئ قواعد تسمح بتطبيقات الشركة فقط.
أنشئ Hunting Queries: راقب ملفات Hive خارج المسارات الطبيعية والمسارات الداخلية غير المعتادة.
جهز الاستجابة: حدد طريقة عزل الجهاز، وحفظ الأدلة، وتعطيل الحسابات المتأثرة.
جهز التحديث: أنشئ Pilot Ring وخطة Rollback لنشر إصلاح Microsoft فور توفره.

بنية ملفات مقترحة لفريق الأمن والدعم

C:\IT\Security\LegacyHive\
|-- Advisory\
|-- Inventory\
|-- Baseline\
|-- EventLogs\
|-- EDR-Queries\
|-- Pilot\
|-- Incident-Evidence\
|-- Rollback\
`-- README.txt

ضع في مجلد Inventory قائمة الأجهزة والحسابات، وفي Baseline حالة Defender وEDR وApplication Control، وفي EventLogs السجلات المصدرة، وفي Pilot نتائج الاختبارات، وفي Incident-Evidence الأدلة المتعلقة بأي جهاز مشتبه به.

أوامر PowerShell للفحص الدفاعي

# Update Microsoft Defender security intelligence
Update-MpSignature

# Display Microsoft Defender protection status
Get-MpComputerStatus |
Select-Object AntivirusEnabled,
              RealTimeProtectionEnabled,
              BehaviorMonitorEnabled,
              AntivirusSignatureVersion,
              AntivirusSignatureLastUpdated

# Display Local Administrators members
Get-LocalGroup -SID "S-1-5-32-544" |
Get-LocalGroupMember

# Display local Windows user profiles
Get-CimInstance Win32_UserProfile |
Select-Object LocalPath,
              SID,
              Loaded,
              Special,
              LastUseTime

# Review Windows User Profile Service events
Get-WinEvent `
  -LogName "Microsoft-Windows-User Profile Service/Operational" `
  -MaxEvents 200 |
Select-Object TimeCreated,
              Id,
              LevelDisplayName,
              Message

# Review process creation events from the last 24 hours
Get-WinEvent -FilterHashtable @{
  LogName   = "Security"
  Id        = 4688
  StartTime = (Get-Date).AddHours(-24)
} |
Select-Object TimeCreated,
              Id,
              Message

أمثلة Hunting داخل Microsoft Defender XDR

الاستعلامات التالية مخصصة للبحث الدفاعي، ولا يعني ظهور نتيجة منها وجود استغلال مؤكد. يجب ربط النتيجة بالحساب والعملية والمسار والتوقيت.

// Registry hive files outside normal user profile paths
DeviceFileEvents
| where FileName in~ ("ntuser.dat", "UsrClass.dat")
| where FolderPath !startswith @"C:\Users\"
| project Timestamp,
          DeviceName,
          FileName,
          FolderPath,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessAccountName
| order by Timestamp desc

// Registry values containing unusual object manager paths
DeviceRegistryEvents
| where RegistryValueData contains "GlobalRoot"
   or RegistryValueData contains "BaseNamedObjects"
| project Timestamp,
          DeviceName,
          RegistryKey,
          RegistryValueName,
          RegistryValueData,
          InitiatingProcessFileName,
          InitiatingProcessAccountName
| order by Timestamp desc

// Processes referencing Windows user hive files
DeviceProcessEvents
| where ProcessCommandLine has_any (
    "UsrClass.dat",
    "ntuser.dat",
    "reg load"
  )
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName
| order by Timestamp desc

تحذير: لا تشغّل Proof of Concept على جهاز Production، ولا تحذف ملفات NTUSER.DAT أو UsrClass.dat، ولا تغيّر صلاحيات مجلدات Profiles عشوائياً، ولا تعطّل خدمة ProfSvc. هذه الإجراءات قد تسبب Temporary Profile أو فقدان إعدادات المستخدم أو فشل تسجيل الدخول.

التشغيل وحل المشاكل الشائعة

التحدي الأساسي في Troubleshooting هو التمييز بين نشاط Windows الطبيعي والنشاط المشبوه. خدمة Profiles وأدوات Backup وحلول إدارة User Profiles قد تصل بصورة مشروعة إلى ملفات Registry Hives، لذلك لا يمكن اعتبار اسم الملف وحده دليلاً على الاختراق.

المشكلة	السبب المحتمل	الحل المقترح
لا يظهر LegacyHive في أداة Vulnerability Management	لا يوجد رقم CVE أو تعريف Vendor رسمي داخل قاعدة الأداة.	أنشئ Custom Advisory أو Tag داخلياً واربطه بالأجهزة ذات الأولوية.
Defender محدث لكن لا تظهر حالة Protected	Security Intelligence تكشف التهديدات، لكنها لا تصلح منطق الخدمة المتأثرة.	اعتبر تحديث Defender طبقة كشف، واستمر في Hardening وApplication Control.
ظهور NTUSER.DAT أو UsrClass.dat في تنبيه	قد تكون خدمة Windows أو Backup أو Profile Management.	راجع المسار والعملية الأب والحساب والوقت والمستخدم المالك للملف.
لا تظهر أحداث Security ID 4688	Process Creation Auditing غير مفعل أو السجل لا يصل إلى SIEM.	فعّل Audit Process Creation وCommand Line Logging واختبر جهاز Pilot.
AppLocker يمنع تطبيقات الشركة	تم تطبيق Enforcement قبل جمع Baseline كافٍ.	ارجع إلى Audit Only وأنشئ Publisher أو Path Rules مدروسة.
المستخدم يدخل إلى Temporary Profile	تلف أو قفل Hive أو تغيير خاطئ في صلاحيات Profile.	راجع User Profile Service Log وخذ Backup قبل تعديل ProfileList.
ظهور حساب إداري جديد بعد حادث	اختراق سابق أو Credential Theft أو أداة إدارة غير موثقة.	اعزل الجهاز واحفظ الأدلة وعطّل الحساب وابدأ Incident Response.
Micropatch يسبب تعارضاً أو Crash	عدم توافق مع Build أو EDR أو تطبيق داخلي.	نفّذ Rollback وفق تعليمات المزود وأعد الجهاز إلى Pilot Group.

كيف تقيّم تنبيهاً متعلقاً بملفات Hive؟

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

راجع أيضاً العمليات التي سبقت الحدث. تشغيل ملف غير موقع من Downloads أو Temp، ثم ظهور نشاط على Registry Hives، ثم إنشاء Scheduled Task أو حساب محلي جديد، يمثل سلسلة أكثر خطورة من حدث ملف منفرد.

طريقة تشخيص سريعة:

هل الجهاز مشترك أو يعمل كخادم RDS؟
هل يسجل Administrators دخولاً تفاعلياً عليه؟
هل ظهر Hive خارج مجلد المستخدم الطبيعي؟
هل نفذت العملية بواسطة حساب Standard User؟
هل العملية غير موقعة أو تعمل من Temp أو Downloads؟
هل ظهرت تغييرات في Local Administrators أو Scheduled Tasks؟
هل توجد اتصالات شبكة أو أدوات Remote Access غير معتادة؟

اجتماع أكثر من مؤشر يبرر عزل الجهاز وفتح Incident بدلاً من إغلاق الحدث كـFalse Positive.

خطوات التعامل مع جهاز مشتبه به

اعزل الجهاز من خلال EDR مع إبقاء قناة الإدارة متاحة إن أمكن.
لا تعِد تشغيله مباشرة قبل جمع المعلومات المتطايرة والسجلات المهمة.
صدّر Security Log وUser Profile Service Log وسجل EDR Timeline.
احفظ قائمة العمليات والاتصالات والحسابات المحلية وScheduled Tasks.
حدد الحسابات الإدارية التي دخلت إلى الجهاز خلال الفترة المشبوهة.
غيّر بيانات اعتماد الحسابات المتأثرة من جهاز موثوق، وليس من الجهاز المشتبه به.
نفذ Full Scan أو Offline Scan بعد حفظ الأدلة وعدم الحاجة إلى الذاكرة الحالية.
أعد بناء الجهاز إذا لم يعد من الممكن إثبات سلامته بصورة موثوقة.

Best Practices لفنيي IT Support

استخدم Standard User: لا تجعل Local Administrator هو الوضع الطبيعي لموظفي الشركة.
طبّق Windows LAPS: كلمة مرور محلية فريدة ومتغيرة لكل جهاز.
افصل حسابات الإدارة: حساب يومي للبريد والتصفح وحساب مستقل للمهام الإدارية.
لا تستخدم Domain Admin على أجهزة المستخدمين: استخدم حساباً محدود الصلاحيات ومخصصاً لدعم الأجهزة.
استخدم WDAC أو AppLocker: امنع التشغيل من Downloads وTemp وAppData إلا عند وجود سبب موثق.
فعّل EDR على السيرفرات: Antivirus التقليدي وحده لا يوفر Timeline كافياً للتحقيق.
اجمع السجلات مركزياً: حتى لا يستطيع المهاجم حذف الأدلة المحلية بسهولة.
راقب محطات فريق IT: لأنها تحتوي أدوات وبيانات اعتماد أكثر حساسية من أجهزة الموظفين.
قلل Interactive Logon: استخدم أدوات الإدارة البعيدة الموثوقة بدلاً من فتح جلسة Admin لكل مهمة.
اختبر التحديثات ضمن Rings: Security Pilot ثم IT ثم الأنظمة الحساسة ثم بقية الأجهزة.
لا تعتبر تحديث Defender بديلاً عن Patch: Detection لا يزيل الثغرة من مكون Windows.
وثق كل استثناء: أي تطبيق يسمح له بالتشغيل من مسار مستخدم يجب أن يكون له Owner وسبب وتاريخ مراجعة.

نموذج README أو Security Checklist

Advisory: LegacyHive
Category: Windows User Hive Access
Owner: Security and Infrastructure Team
Status: Monitoring - Awaiting Vendor Guidance

SCOPE
[ ] Shared Windows endpoints identified
[ ] RDS servers identified
[ ] Privileged workstations identified
[ ] Local administrator membership exported

CONTROLS
[ ] Windows updates current
[ ] Defender signatures current
[ ] EDR healthy and reporting
[ ] Process creation auditing enabled
[ ] Application Control reviewed
[ ] Windows LAPS deployed
[ ] Admin accounts separated

DETECTION
[ ] User Profile Service logs collected
[ ] Hive files outside profile paths monitored
[ ] Suspicious object manager paths monitored
[ ] Local Administrators changes alerted
[ ] Scheduled Tasks changes alerted

RESPONSE
[ ] Device isolation procedure tested
[ ] Evidence storage documented
[ ] Account reset procedure documented
[ ] Pilot and rollback groups available
[ ] Microsoft advisory monitored

معيار عملي: لا تغلق تذكرة الاشتباه لأن Antivirus أعاد نتيجة نظيفة فقط. راجع العمليات والملفات والـRegistry والحسابات وPersistence وسجلات Profile Service قبل اعتبار الجهاز سليماً.

مثال عملي من بيئة شركة

لنفترض أن شركة متوسطة لديها نحو 150 جهاز Windows، وخادم RDS للتطبيقات المالية، وفريق دعم يدخل إلى أجهزة المستخدمين عند الحاجة. اكتشف الفريق أن عدداً من الموظفين يملكون Local Admin بسبب برنامج قديم، وأن بعض الفنيين يستخدمون الحساب الإداري نفسه على عدة أجهزة.

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

المرحلة	الإجراء	النتيجة
Discovery	حصر Local Admins والأجهزة المشتركة وخوادم RDS.	تحديد الأجهزة ذات الأولوية بدلاً من تطبيق تغييرات عشوائية.
Containment	إزالة صلاحيات المستخدمين وفصل حسابات الفنيين.	تقليل فرص انتقال المهاجم من حساب عادي إلى حساب إدارة.
Detection	تفعيل EDR Queries ومراقبة Hive Files وProfile Service.	تحويل الأحداث المتفرقة إلى تنبيهات قابلة للتحقيق.
Hardening	نشر Windows LAPS وتطبيق AppLocker على مجموعة Pilot.	إلغاء كلمات المرور المشتركة ومنع البرامج غير المعتمدة.
Patch Readiness	تجهيز Pilot Ring ونافذة صيانة وخطة Rollback.	الاستعداد لنشر إصلاح Microsoft دون تأخير غير ضروري.

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

بعد ذلك شُغلت AppLocker في Audit Mode لمدة كافية، واكتشف الفريق برامج قديمة تعمل من مجلدات المستخدم. تم تحويل البرامج الضرورية إلى مسارات مركزية موثوقة، ثم انتقلت السياسة تدريجياً إلى Enforcement.

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

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

ما هي ثغرة LegacyHive في Microsoft Windows؟

هي ثغرة منشورة باسم غير رسمي ترتبط بخدمة Windows User Profile Service، وتسمح Proof of Concept العلنية بتحميل Registry Hive تابع لمستخدم آخر ضمن سياق المستخدم الحالي.

هل يمكن استغلال LegacyHive عن بُعد عبر الإنترنت؟

ليست Remote Code Execution مستقلة. يحتاج المهاجم عادةً إلى وصول محلي أو حساب أو القدرة على تشغيل كود داخل الجهاز أولاً.

هل تمنح LegacyHive صلاحيات Administrator أو SYSTEM مباشرة؟

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

هل يحتوي UsrClass.dat على كلمات مرور Windows؟

لا يحتوي عادةً على Password Hashes الخاصة بحساب Windows، لكنه قد يحتوي إعدادات تطبيقات وآثار استخدام ومعلومات مفيدة للمهاجم.

هل تحديث Microsoft Defender يكفي للحماية؟

لا. يساعد Defender في الكشف عن ملفات أو سلوكيات معروفة، لكنه لا يستبدل إصلاح Windows أو Least Privilege وApplication Control.

ما الأجهزة التي يجب فحصها أولاً؟

ابدأ بخوادم RDS، والأجهزة المشتركة، ومحطات الإدارة، والأجهزة التي تحتوي عدة Profiles أو دخل إليها حساب Administrator.

هل يجب تثبيت Micropatch غير رسمي؟

يُدرس فقط للأنظمة ذات المخاطر المرتفعة بعد اختبار Pilot وموافقة Change Management وتجهيز Rollback. لا ينشر مباشرة على جميع الأجهزة.

الخاتمة

توضح LegacyHive أن حماية حسابات Windows لا تعتمد على كلمة المرور وحدها. عندما توجد طريقة لتحميل Registry Hive تابع لمستخدم آخر، قد يحصل المهاجم على بيانات وإعدادات لا يفترض أن تكون متاحة للحساب الحالي.

النسخة العلنية من Proof of Concept محدودة ولا تثبت تلقائياً السيطرة الكاملة على الجهاز، لكن وجود الخلل يستحق التعامل الجاد، خصوصاً في بيئات RDS والأجهزة المشتركة ومحطات فريق IT.

التوصية العملية هي إزالة Local Admin، وفصل حسابات الإدارة، وتحديث Windows وDefender، وتفعيل EDR وApplication Control، وتجهيز Pilot وRollback لنشر أي إصلاح رسمي من Microsoft فور توفره.