شرح AccessChk: كيف تقرأ صلاحيات ويندوز وتفرق بين ملف قابل للكتابة وثغرة مثبتة؟

أداة تعرض حرف W بجانب مسار، فيكتب المتدرب فورًا «Privilege Escalation». لكن من يملك هذه الكتابة؟ وعلى أي كائن؟ وهل يستخدمه فعلًا برنامج أعلى صلاحية؟ وهل النص الذي قرأه وصف لحقوق حساب محدد أم قائمة حقوق عدة حسابات؟ بدون هذه الأسئلة، قد تحول إعدادًا طبيعيًا إلى ثغرة أو تتجاهل حقًا مهمًا وسط مخرجات طويلة.

AccessChk من أدوات Sysinternals في مايكروسوفت، وتفيدك في قراءة صلاحيات موارد ويندوز. بنستخدمها داخل جهاز تدريب نملكه، بهدف فهم النتائج وتوثيقها، بدون تعديل ملف خدمة أو استبدال برنامج أو محاولة رفع صلاحيات. القيمة هنا أن تعرف ما أثبتته القراءة، ووش يحتاج تحققًا إضافيًا.

ابدأ بسؤال صلاحية واضح، مو بجرد القرص كله

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

خلنا نفترض مجلدًا تدريبيًا D:/LabReview وفيه ملف report.txt لا يحتوي بيانات حقيقية. حساب student يملك الحقوق المعتادة المحددة له في اللاب. قبل الفحص، اكتب توقعك: هل المطلوب قراءة الملف فقط؟ أم قراءة وكتابة؟ وهل المجلد مشترك عبر الشبكة أم محلي؟ هذه المعلومات تعطي معنى لما سيظهر لاحقًا.

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

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

الأداة الرسمية تساعدك، لكن لا تلغي مسؤولية التحقق

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

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

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

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

حدد الحساب صراحة واقرأ R وW كملخص

مثال قراءة لمجلد اللاب، بشرط أن student هو حساب التدريب المقصود ويمكن للنظام حل اسمه دون لبس:

accesschk.exe student D:/LabReview

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

الحرفان R وW ملخص لقراءة وكتابة. الملخص مفيد لتوجيه الانتباه، لكنه ما يغني عن تفاصيل الحق ونوع المورد. استخدم القراءة المفصلة عند الحاجة، مثل:

accesschk.exe -v student D:/LabReview

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

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

DACL وصف للكائن، وسياق العملية وصف لمن يطلب الوصول

في ويندوز، وصف الحماية للكائن يتضمن معلومات تتحكم في الوصول، ومن ضمنها DACL وقواعدها. أما العملية التي تحاول الوصول فلها سياق أمني يمثله Access Token، يتصل بالهوية والمجموعات والامتيازات. لهذا ما يكفي تقرأ اسم مستخدم في شاشة وتفترض أن كل عملية تعمل بالحقوق نفسها في كل الظروف.

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

كذلك وجود Allow أو Deny في قاعدة واحدة لا يحسم كل حقوق المستخدم على المورد. حقوق المجموعات والتوريث وترتيب القواعد ونوع العملية المطلوبة تدخل في الفهم. لا تستخدم شعار «Deny يفوز دائمًا» بدل قراءة الحالة كاملة؛ هناك تفاصيل في ترتيب القواعد الصريحة والموروثة وتعريف الحق المطلوب.

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

المجلد والملف: لا تفترض أنهما يتطابقان

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

مثال قراءة الملف المحدد في جهاز التدريب:

accesschk.exe -v student D:/LabReview/report.txt

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

تقدر تستعين بقراءة icacls على الملف نفسه:

icacls D:/LabReview/report.txt

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

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

صلاحية الخدمة غير صلاحية ملف برنامجها

خدمة ويندوز لها كائن حماية يمكن أن يحدد من يقرأ إعدادها أو يغيره أو يبدأها أو يوقفها. الملف التنفيذي الذي تستخدمه الخدمة له حقوق ملفات مستقلة. لذلك عبارة «صلاحيات الخدمة ضعيفة» لا تكفي بدون تحديد أي كائن وأي حق وجدته.

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

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

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

متى تصبح الكتابة مؤشر خطر يحتاج تحقيقًا؟

خلنا نفترض أن حساب تدريب عادي يملك حق كتابة على ملف يستخدمه تطبيق، حسب قراءة موثقة. هذه بداية سؤال أمني: هل ذلك الملف معد لهذا الحساب أصلًا؟ وهل يستطيع تعديله ضمن الاستخدام المتوقع؟ ومن يقرأه لاحقًا، وتحت أي صلاحيات؟ بدون معرفة الدور الفعلي للملف، ما عندك أثر واضح.

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

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

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

الأخطاء الصغيرة التي تطلع تقريرًا كبيرًا وغلط

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

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

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

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

تمرين مقارنة يبني فهمك بدون رفع صلاحيات

اتفق مع مسؤول اللاب على مجلد وملفين وهميين: ملف مخصص لقراءة حساب التدريب، وملف مخصص لعمله اليومي بحيث تكون الكتابة عليه متوقعة. لا تحتاج كائنات نظام ولا ملفات أسرار. اطلب منه وصف الحقوق المقصودة مسبقًا، واحتفظ بالوصف لتقارن الهدف بالإعداد الفعلي.

اقرأ حقوق الحساب على المجلد ثم على كل ملف بصورة مستقلة، وبعدها اطلع على وصف الحماية بالتفصيل. اكتب توقعك قبل كل قراءة: أي عملية يفترض أن يسمح بها الحساب؟ لو ظهر اختلاف، حاول تفسيره من التوريث أو قواعد الملف أو هوية الحساب قبل استدعاء أداة أخرى.

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

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

من نتيجة AccessChk إلى ملاحظة قابلة للإصلاح

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

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

ولفهم اختلاف حقوق الملفات عبر الشبكة، راجع مقال SMB Access Denied في المجتمع:
https://courses.cyberpts.com/community/72/smb-access-denied-alhsab-shyh-lkn-lysh-almjld-almshtrk-yrfdk

المراجع الأساسية: صفحة AccessChk الرسمية، وشرح Access Tokens، وحقوق كائنات الخدمات من مايكروسوفت:
https://learn.microsoft.com/en-us/sysinternals/downloads/accesschk
https://learn.microsoft.com/en-us/windows/win32/secauthz/access-tokens
https://learn.microsoft.com/en-us/windows/win32/services/service-security-and-access-rights

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