قبل بضعة أيام، كشفت شركة النشر التعليمي العملاقة McGraw Hill عن حادثة سيبرانية شملت المجموعة المشهورة من الجهات التهديدية ShinyHunters. بدأت الواقعة على أنها حادثة «وصول محدود»، ووفقًا لمصادر الشركة تصاعدت بسرعة في الحجم، إذ وصلت ما يقرب من 13 مليون سجل إلى الويب المظلم وتلقفها وسطاء البيانات. وبينما ذكرت McGraw Hill أن ShinyHunters استغلوا سوء تهيئة في بيئة Salesforce المخترقة لتنفيذ الاختراق، فإن الحادثة لم تؤثر في حسابات Salesforce الأخرى، أو المحتوى التعليمي (courseware)، أو قواعد بيانات العملاء، أو الأنظمة الداخلية.

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

قبل أن نبدأ التحليل المتعمق، لا تنسَ الاطلاع على تدوينتنا السابقة بعنوان أهم 15 تحديًا في حماية CPS وكيف يمكن لفرق OT التعامل معها هنا.  

الجدول الزمني للاختراق ومتجه الهجوم

ظهرت تفاصيل الاختراق علنًا في 14 أبريل 2026. وتزامن ذلك مع موعد نهائي لفدية حددته ShinyHunters.

السبب الجذري: فخ «Experience Cloud»

لم يكن المتجه الأساسي استغلالًا من نوع يوم الصفر. بل كان سوء تهيئة في Salesforce Experience Cloud (المعروفة سابقًا باسم Community Cloud). وتستخدم المؤسسات هذه الميزات لبناء بوابات عامة أو موجهة للشركاء والعملاء.

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

·  استغلال «Aura»: لوحظ أن ShinyHunters يستخدمون ماسحات آلية للاستعلام عن مكونات Salesforce Aura لتحديد نقاط الضعف. ومن خلال استهداف نقاط نهاية غير مصادَق عليها محددة، يمكنهم «تمويه» النظام أو، وبشكل أدق:

o   إساءة استخدام نقاط النهاية /s/sfsites/aura أو /aura

o   استدعاء وحدات Apex التحكيمية على جهة الخادم

o   استغلال الدوال @AuraEnabled المكشوفة بشكل غير صحيح

o   بالاقتران مع سياق مستخدم الضيف

(لاستخراج سجلات ليست محمية بشكل صحيح عبر أذونات الكائنات (CRUD) وFLS ونموذج المشاركة.)

التباين في البيانات

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

كان ShinyHunters داخل النظام لفترة، وقام بتسريب البيانات ببطء.

تحليل جنائي متعمق: «محدود» مقابل «قاتل»

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

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

• هجمات حشو بيانات الاعتماد

• حملات التصيّد الاحتيالي

• الربط الهوياتي باستخدام مجموعات بيانات OSINT

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

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

الجهة المهددة: ShinyHunters

قد تتذكر ShinyHunters من هذه الحادثة. لقد تطوروا، إن جاز التعبير. فلم يعودوا يهتمون بالتشفير المعقد (برمجيات الفدية) وبيع أدوات فك التشفير. لقد تحولوا إلى مبتزين بحتين، كما يقال تمامًا.  

أساليب وإجراءات ShinyHunters (TTPs)

• اكتشاف الأصول

  • فحص النطاقات المكشوفة لـ Salesforce Experience Cloud (*.force.com, *.site.com)

• حصر نقاط النهاية

  • الاستهداف:

    • /s/

    • /aura

  • تحديد المكونات القابلة للاستدعاء على جهة الخادم

• إساءة استخدام الامتيازات

  • العمل ضمن:

    • سياق مستخدم الضيف

    • الملفات الشخصية القياسية سيئة التهيئة

• استخراج البيانات

  • الحصاد الآلي عبر طلبات مُبرمجة

  • التركيز على الكائنات عالية القيمة (جهات الاتصال، المستخدمون، الحسابات)

• سير عمل الابتزاز

  • نشر عينة من التسريبات

  • التفاوض المباشر أو إعادة البيع للشركاء

إجراءات وقائية: إغلاق الخزنة

لمنع مؤسستك من أن تصبح ضحية لهذه المجموعة، عليك تنفيذ إعدادات Salesforce «Zero Trust» التالية فورًا:

التعزيز الاستراتيجي

• تعطيل «الوصول العام» افتراضيًا: راجع كل موقع Salesforce وكل بوابة Experience Cloud. وتأكد من أن «الوصول العام» مفعّل فقط للصفحات التي تتطلبه بالفعل بشكل صارم.

• تشديد «مستخدم الضيف»: استخدم قواعد مشاركة مستخدم الضيف لضمان أن المستخدمين الضيوف لا يمكنهم أبدًا الوصول إلى السجلات افتراضيًا. ويجب ألا يروا إلا ما تتم مشاركته صراحةً عبر قواعد «Secure Guest User Sharing».

• أمن واجهات API: قيّد الوصول إلى واجهات API وفق نطاقات IP محددة وفرض TLS المتبادل (mTLS) للعمليات التكاملية الحساسة.

• راجع جميع مواقع الوصول العام والصلاحيات. واسحب الصلاحيات غير المطلوبة 

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

·       تدقيق فئات Apex المفعّلة عبر Aura

·       تحديد جميع الدوال @AuraEnabled

·       التأكد من:

o   وجود فحوصات المصادقة

o   التحقق من المدخلات

o   عدم كشف الكائنات مباشرة

·       تعزيز Experience Cloud

·       مراجعة جميع المواقع:

o   إزالة نقاط النهاية غير المستخدمة

o   تعطيل الوصول العام حيث لا يلزم

·       حوكمة التطبيقات المتصلة

·       فرض:

o   IP Relaxation = مقيّد

o   جلسات عالية الضمان

o   تقليل نطاقات OAuth إلى الحد الأدنى 

الضوابط التكتيكية

• Salesforce Shield (مراقبة الأحداث): فعّل Shield لتتبع أحداث «Report Export» و«Bulk API». إذا وصل مستخدم ضيف (أو أي مستخدم) فجأة إلى عدة سجلات، ينبغي للنظام، في الوضع المثالي، عزل الجلسة تلقائيًا ورفع تنبيه متعدد المستويات. نحن نتحدث هنا عن سياسات أمان المعاملات، ومراقبة الأحداث، وقواعد مخصصة تغطي سيناريوهات متعددة.

• أمن مستوى الحقل (FLS): حتى لو استطاع المستخدم رؤية كائن، فلا ينبغي له رؤية كل حقل. أخفِ حقول البيانات التعريفية الشخصية عن جميع الأدوار الإدارية باستثناء الأكثر ضرورة..

• المراقبة:

·  أنماط الوصول إلى URI (/aura, /s/)

·   ارتفاعات أحداث API

·   عمليات تصدير التقارير

مؤشرات الأداء الرئيسية: كيفية تتبع مستوى التعرض

لا يمكنك إدارة ما لا تقيسه. تتبع هذه المقاييس شهريًا:

• عدد أذونات مستخدم الضيف: عدد الكائنات التي يمكن الوصول إليها عبر الملفات الشخصية غير المصادَق عليها «Guest». (الهدف: 0 للكائنات الحساسة).

• معدل انحراف الإعدادات: مدى تكرار إدخال إعدادات «متساهلة» بعد دورة نشر.

• متوسط زمن الكشف (MTTD) لعمليات التصدير الجماعي: عدد الدقائق التي تمر بين استعلام ضخم على البيانات وتنبيه مركز العمليات الأمنية SOC.

• نسبة المستخدمين الذين لديهم MFA: تأكد من أن كل مستخدم داخلي وكل مستخدم شريك يخضع للمصادقة متعددة العوامل.

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

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

وبالنسبة إلى 13.5 مليون شخص أصبحت بياناتهم الآن منتشرة في العلن، فالدرس واضح: في السحابة، التهيئة عنصر أمني أساسي.

أبقِ سجلاتك محكمة، وصلاحياتك أكثر إحكامًا.

موارد إضافية     

دليل شامل لاكتشاف الشبكات والاستجابة لها NDR في 2026 هنا 
تقرير قابل للتنزيل عن الحادثة السيبرانية لشركة Stryker هنا     
أدلة المعالجة هنا   
أفضل ممارسات أمن OT وتوجيهات تقييم المخاطر هنا  
قائمة تحقق لتقييم مخاطر OT/ICS المستندة إلى IEC 62443 لقطاع تصنيع الأغذية والمشروبات هنا