كيفية Secure مستودعات Server Secure

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

تؤكد «مايكروسوفت» ذلك صراحةً: يمكن لنظام الحماية من البرامج الضارة في «شيربوينت» أن يحد من الأضرار، لكنه لا يُعد نقطة دفاع وحيدة.

في الخدمات المصرفية والمالية والتأمين (BFSI)، والرعاية الصحية، والقطاع الحكومي، والتكنولوجيا التشغيلية (OT) أو بيئات البنية التحتية الحيوية، تشمل البيانات المعرضة للخطر الإقرارات المتعلقة بالامتثال، وسجلات المرضى، وملفات القضايا، والوثائق الهندسية. وتُخزَّن جميعها في مكتبة تتزايد حجمها عامًا بعد عام، في حين لا يتم العودة أبدًا لإعادة فحص ما تحتويه بالفعل.

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

تتتبع بيانات Enlyft المتعلقة باعتماد التكنولوجيا 256,295 شركة تستخدم حاليًا Microsoft SharePoint، وتغطي قطاعات متنوعة بدءًا من الخدمات تكنولوجيا المعلومات الخدمات القطاع المصرفي والرعاية الصحية والنفط والغاز والقطاع الحكومي. وعادةً ما يتراوح عدد الموظفين في هذه الشركات بين 50 و200 موظف، مع إيرادات تتراوح بين 1 مليون و10 ملايين دولار.

هذا الحجم هو بالضبط السبب الذي يجعل المهاجمين يولون اهتمامًا لمستودعات SharePoint ويعاملونها كأهداف ذات قيمة عالية.

ولا يعني أي مما سبق أن SharePoint لا يؤمّن خوادمه أو يهمل أمن الملفات. وفقًا لوثائق Microsoft، Server SharePoint Server مع واجهتي فحص محتملتين هما:

• VSAPI ( API فحص الفيروسات)، وهي واجهة تكامل لمكافحة الفيروسات في SharePoint تتيح لبرامج مكافحة الفيروسات المتوافقة من جهات خارجية فحص المستندات أثناء عمليات مثل التحميل والتنزيل.

• AMSI (واجهة فحص البرامج الضارة)، وهي إطار عمل تابع لشركة مايكروسوفت لتكامل برامج مكافحة البرامج الضارة، يتيح Server SharePoint Server الملفات إلى محركات مكافحة الفيروسات المتوافقة مع AMSI (مثل Microsoft Defender) لفحصها بحثًا عن البرامج الضارة أثناء عمليات المحتوى المدعومة.

يمكن تهيئة Server SharePoint لاستخدام VSAPI أو AMSI أو الوضع التلقائي. وبغض النظر عن الخيار الذي تم تعيينه، لا يقوم سوى محرك فحص واحد بتقييم الملف في كل مرة.

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

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

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

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

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

تتبع التهديدات المجهولة نفس المنطق. ونظرًا لعدم وجود توقيع مرفق بها، فإن التحليل الثابت (وهو ما تقوم به محركات برامج مكافحة الفيروسات) لا يستطيع اكتشاف التهديد.

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

في يوليو 2025، كشفت شركة مايكروسوفت عن استغلال نشط لسلسلة ثغرات تسمح بتنفيذ التعليمات البرمجية عن بُعد دون الحاجة إلى المصادقة، والتي تؤثر على Server SharePoint المحلي: CVE-2025-49706 وCVE-2025-49704، وانضمت إليهما لاحقًا CVE-2025-53770 وCVE-2025-53771. ولم يتطلب هذا الاستغلال أي بيانات اعتماد أو تسجيل دخول ليعمل.

ثم قامت «مايكروسوفت» بإصلاح هذه الثغرة، وأُطلق اسم على سلسلة الاستغلال هذه: «ToolShell».

وفقًا لتحليل شركة «Per Eye Security»، الذي استشهدت به مجلة «Infosecurity Magazine»، تم الكشف عن 396 نظامًا تعرض للاختراق في 145 مؤسسة بـ 41 دولة. وتلقى القطاع الحكومي الضربة الأقوى، حيث شكل 30% من حالات الإصابة المؤكدة، وشكلت الولايات المتحدة وحدها 31% من الإجمالي. من ناحية أخرى، أفادت مؤسسة Shadowserver Foundation أن أكثر من 10,700 مثيل من SharePoint ظل معرضًا للخطر، ويمكن الوصول إليه من قبل أي شخص يستخدم سلسلة الاستغلال نفسها، حتى بعد الكشف عن الثغرة الأمنية التي أثرت على مئات المؤسسات. وقامت مجموعة Storm-2603، وهي إحدى المجموعات التي تقف وراء عملية الاستغلال، بتحويل هذا التعرض إلى حمولة من برامج الفدية Warlock.

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

تم بناء ToolShell استنادًا إلى أربع ثغرات أمنية (CVE) متسلسلة، مع تضمين آليات لتجاوز التصحيحات منذ البداية. وقد ظهرت الثغرتان CVE-2025-53770 و-53771 على وجه التحديد لأن التصحيحات الأصلية للثغرتين CVE-2025-49704 و-49706 كان من الممكن التحايل عليها.

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

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

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

وللإنصاف، لم يكن «ToolShell» مستندًا ضارًّا تمكن من التسلل عبر فحص الملفات المُحمَّلة. لكن ماذا عن «الويب شيل» (spinstall0.aspx ومتغيراته التي أُعيدت تسميتها) التي زرعها المهاجمون؟ هذا ملف حقيقي. فقد بقي موجودًا على الخادم، وكان اكتشافه أو عدم اكتشافه مرهونًا بنفس القيود الموضحة سابقًا: محرك فحص واحد، فحص واحد، في لحظة زمنية واحدة.

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

لا يهم أي مما سبق كثيرًا بالنسبة للمحتوى الذي ظل دون تغيير منذ عام 2023، ما لم يتم فحصه فعليًّا.

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

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

يمكن نشر MetaDefender Storage Security عبر نماذج متنوعة: خوادم مادية للتركيب المباشر على الأجهزة، ومنصات المحاكاة الافتراضية (المتوافقة مع VMware وHyper-V وXenServer)، وخدمة البنية التحتية كخدمة (IaaS) من كبار مزودي الخدمات السحابية، أو من خلال عمليات النشر في حاويات ضمن مجموعات Kubernetes.

تستند قائمة المراجعة هذه إلى إرشادات وكالة الأمن السيبراني والبنية التحتية (CISA) بشأن ثغرة «ToolShell».

1. تأكد من حالة التصحيح.

تتوفر تحديثات أمنية لجميع الثغرات الأمنية المعروفة (CVE) التي تم استغلالها، لكن الخوادم التي لم يتم تثبيت التصحيحات عليها تظل معرضة لخطر «ToolShell». يرجى تثبيت تحديثات الأمان الصادرة عن مايكروسوفت لجميع Server SharePoint المتأثرة.

2. تأكد من تهيئة AMSI.

إن نشر نظام AMSI مع وجود أخطاء في تكوينه يترك ثغرة أمنية مماثلة لعدم وجود هذا النظام من الأساس. تأكد من تمكين تكامل نظام AMSI ومن نشر حل مكافحة الفيروسات على كل خادم SharePoint.

3. تغيير مفاتيح الجهاز في ASP.NET

تسمح مفاتيح الجهاز المسروقة للمهاجمين بتزوير رموز مصادقة صالحة حتى بعد تثبيت التصحيح على الخادم. ولا يؤدي تثبيت التصحيح وحده إلى إبطال صلاحية المفاتيح التي سُرقت بالفعل. قم بتبديل مفاتيح الجهاز، ثم قم بتطبيق التحديث الأمني، ثم قم بتبديل مفاتيح الجهاز مرة أخرى. أعد تشغيل IIS باستخدام iisreset.exe بعد كل عملية تبديل لإزالة الإدخالات الضارة من ملفَي applicationHost.config و web.config.

4. البحث يدويًّا عن أي دلائل تشير إلى تعرض النظام للاختراق في السابق.

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

5. تحقق من وجود إصدارات انتهت مدة صلاحيتها أو انتهت مدة خدمتها.

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

6. مراجعة السجلات بحثًا عن المؤشرات المعروفة

تحدد وكالة الأمن السيبراني والبنية التحتية (CISA) أنماطًا محددة للطلبات نظام منع التطفل بهذه الحملة. ابحث في سجلات البحث عن الطلبات التي تتطابق مع المراجع التي أوردتها الوكالة.

7. مراجعة صلاحيات الإدارة والتصميم.

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

8. قم بتقييم ما تم تخزينه بالفعل، وليس فقط ما هو معروض حاليًا

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

تحديد ما إذا كان محتوى المستودع الحالي قد أُعيد فحصه منذ إصدار التصحيحات وتحديثات التوقيعات ذات الصلة، أم أنه لا يزال يحمل نتيجة الفحص الأصلية التي قد تكون قديمة.