في يوليو 2026، شرحت Microsoft كيف أمضت عصابة الابتزاز ShinyHunters عامًا كاملًا وهي تستنزف بهدوء مستأجري Salesforce عبر قطاعات التجزئة والرعاية الصحية والطيران والتقنية — وفعلت ذلك دون كسر كلمة مرور واحدة. أساءت حملة ShinyHunters Salesforce OAuth استغلال الشيء الوحيد الذي لم تُصمَّم المصادقة متعددة العوامل قط لإيقافه: مستخدم يضغط طوعًا على «سماح». وحيث كانت الاختراقات الأقدم تسرق بيانات الاعتماد، سرق هذا الاختراق الثقة، إذ خدع الموظفين لتفويض تطبيق connected app خبيث احتفظ بعدها برمز API صالح إلى أجل غير مسمى.
هذا التمييز مهم لأي شخص يدير حزمة SaaS. نادرًا ما لمس المهاجمون شاشة تسجيل الدخول، لذا ظلت مطالبات MFA وقواعد السفر المستحيل وتنبيهات تسجيل الدخول صامتة في معظمها. إذا كان نموذجك الأمني يفترض «لدينا MFA، إذًا نحن محميون»، فإن هذه الحملة هي دراسة الحالة التي تثبت العكس.
ما الذي حدث فعليًا
بين منتصف 2025 ومنتصف 2026، أدارت ShinyHunters (التي تتعقبها Mandiant التابعة لـ Google باسم UNC6040 لنشاط التصيّد الصوتي وUNC6395 لسرقة الرموز) عملية بمقياس صناعي ضد عملاء Salesforce. يقدّر ملخص The Hacker News لمعلومات التهديد الخاصة بـ Microsoft ادعاءات الشركاء بما يقارب 1,000 منظمة متأثرة، رغم أن كثيرًا منها يبقى غير مؤكد. كانت الغنيمة بيانات CRM — سجلات العملاء وتذاكر الدعم وقوائم جهات الاتصال — التي استخدمتها المجموعة بعد ذلك في الابتزاز، مهدِّدةً بتسريبها ما لم يدفع الضحايا.
الجزء البارع كان في الاستمرارية. لا تنتهي صلاحية رمز OAuth المسروق عند إعادة تعيين كلمة مرور أو عندما يغيّر الموظف الذي وقع ضحية التصيّد جهاز MFA الخاص به. وكما أشارت Microsoft، فإن معظم سجلات Salesforce «لم تُبنَ لإظهار» ما يحدث بعد التفويض، ولذلك امتزجت استدعاءات API الخبيثة مع حركة الأتمتة العادية لأسابيع.
طرق الدخول الثلاث
يصف كلٌّ من Microsoft وفريق معلومات التهديد في Google Cloud ثلاثة مسارات دخول متمايزة، تنتهي جميعها إلى المكان نفسه: منحة OAuth يتحكم بها المهاجم.
| مسار الهجوم | كيف عمل | التفصيل الأساسي |
|---|---|---|
| التصيّد الصوتي (vishing) | انتحل المتصلون صفة دعم تقنية المعلومات وقادوا الموظفين عبر شاشة موافقة OAuth في Salesforce | فوّض الضحايا تطبيقًا خبيثًا ينتحل صفة Data Loader من Salesforce، وأُعيدت تسميته أحيانًا إلى «My Ticket Portal» |
| سرقة الرموز عبر سلسلة التوريد | اخترق المهاجمون تكاملات موثوقة وأعادوا استخدام رموز OAuth الخاصة بها ضد المستأجرين اللاحقين | Salesloft/Drift (أغسطس 2025) وGainsight (نوفمبر 2025) وKlue (يونيو 2026)؛ تقدّر التقارير التعرّض اللاحق بـ700+ و200+ منظمة على التوالي |
| وصول ضيف مُهيّأ بشكل خاطئ | أتاحت أدوار الضيف مفرطة الصلاحيات في Experience Cloud للمستخدمين غير المصادَق عليهم قراءة البيانات | استخدم الفاعلون ترقيم صفحات GraphQL للتسلل من حدّ الاستعلام البالغ 2,000 سجل |
مسار التصيّد الصوتي هو العنوان الأبرز لأنه لا يحتاج إلى أي ثغرة برمجية على الإطلاق — مجرد مكالمة هاتفية مقنعة ومسؤول مشتّت الانتباه. أما مسار سلسلة التوريد فهو أسوأ على الأرجح: اختراق واحد لدى مورّد مثل Salesloft سلّم المهاجمين حلقة مفاتيح لمئات المنظمات العميلة التي لم ترتكب أي خطأ بنفسها قط.
لماذا يمرّ إساءة استغلال OAuth مباشرةً بجانب MFA
هذا هو التفصيل الذي تتغافل عنه معظم التغطية، وهو سبب نجاح الحملة لمدة طويلة. موافقة OAuth مصمَّمة لتفويض الوصول. عندما يوافق موظف على تطبيق connected app، تُصدر Salesforce رمزًا طويل الأمد يتيح لذلك التطبيق استدعاء API نيابةً عن المستخدم — دون تسجيل دخول متكرر، ودون تحدٍّ جديد من MFA. هذا هو الغرض الكامل من OAuth، ولهذا فإن «فعّل MFA فحسب» ليس دفاعًا هنا.
بمجرد وجود الرمز، يعمل المهاجم بصفته تطبيقًا موثوقًا، لا بصفته تسجيل دخول مشبوهًا. لا يوجد موقع جغرافي شاذ للإشارة إليه لأن استدعاءات API تصدر من البنية التحتية الخاصة بالتطبيق نفسه. لا تُفعَّل سياسات مخاطر تسجيل الدخول أبدًا لأنه لا يوجد تسجيل دخول. لا يجدي تدوير كلمات المرور نفعًا لأنه لا كلمة مرور معنية. إبطال الرمز هو مفتاح الإيقاف الحقيقي الوحيد — ولا يمكنك إبطال إلا ما يمكنك رؤيته، وهو بالضبط ما جعلته سجلات Salesforce الافتراضية صعبًا. هذا هو الدرس نفسه القائل إن «الهوية هي المحيط الجديد» الكامن خلف عمليات الانتقال إلى zero trust: حافة الشبكة غير ذات صلة عندما يصل المهاجم حاملًا بيان اعتماد صالحًا.
من الذي تعرّض للضربة
تُقرأ قائمة الضحايا كأنها دليل «من هو من» في عالم الشركات. تربط التقارير العلنية ومنشورات مواقع التسريب نشاط ShinyHunters الأوسع على Salesforce بـ Google وCloudflare وZscaler وPalo Alto Networks وProofpoint وQantas وAllianz Life وAdidas وChanel وPandora وعدة علامات تجارية تابعة لـ LVMH، من بين آخرين. ولم يسلم موردو الأمن — إذ يظهر Tanium وHuntress وRecorded Future أيضًا في التقارير، وهو تذكير حادّ بأن خطر موافقة OAuth عالمي، وليس مشكلة الشركات الصغيرة.
استقطب قطاع الرعاية الصحية اهتمامًا خاصًا. أصدرت Health-ISAC إرشادات تخفيف بعد أن امتدّ نشاط المجموعة إلى القطاع، ونشرت الجهة المنظِّمة للقطاع المالي FINRA تنبيهها الخاص بشأن Salesforce Experience Cloud الذي يغطي مسار سوء تهيئة وصول الضيف.
كيف تُحكم إغلاق موافقة OAuth في مؤسستك
الحل هو الحوكمة، لا التصحيح البرمجي — وينطبق على أي منصة SaaS تدعم تفويض تطبيقات الطرف الثالث (تملك Google Workspace وMicrosoft 365 التعرّض نفسه). قائمة تحقق عملية:
- قيّد من يستطيع منح الموافقة. أوقِف موافقة OAuth من المستخدم النهائي ووجّه كل عمليات اعتماد تطبيقات connected apps الجديدة عبر طابور مراجعة للمسؤول. في Salesforce، أحكِم إعدادات «Connected Apps OAuth Usage»؛ وفي Microsoft 365، استخدم سياسات موافقة التطبيقات والوصول المشروط.
- جرِد ونقِّ المنح القائمة. راجع كل تطبيق connected app مُصرَّح به وأبطِل كل ما هو غير مستخدَم أو غير معروف أو خامل. رمزٌ من تطبيق لا يتذكر أحد تثبيته هو أعلى مخاطرك.
- راقب السجلات الصحيحة. لن تلتقط سجلات تسجيل الدخول هذا. راقب بدلًا من ذلك أحداث تفويض OAuth، وحجم استدعاءات API لتطبيقات connected apps، وأنماط التصدير الجماعي للبيانات. عمليات القراءة الجماعية المفاجئة من تطبيق نادر الاستخدام هي العلامة الفارقة.
- درّب الموظفين على التصيّد الصوتي عند شاشة الموافقة. النقرة الأخيرة بشرية. تأكد من أن الموظفين يعرفون أن تقنية المعلومات لن تتصل بهم أبدًا لتقودهم عبر مطالبة OAuth «سماح».
- دقّق في موردي التكامل لديك. يُظهر اختراقا Salesloft وGainsight أن أمن Salesforce لديك ليس أقوى من الأطراف الثالثة التي منحتها رموزًا — الدرس ذاته عن سلسلة التوريد من أزمة سلسلة توريد npm Shai-Hulud.
الأسئلة الشائعة
هل استغلّت ShinyHunters ثغرة في Salesforce؟
لا. لم يكن هناك أي خلل في Salesforce نفسها. أساء المهاجمون استغلال موافقة OAuth المشروعة ووصول الضيف المُهيّأ بشكل خاطئ — حالة من ميزات تعمل كما صُمِّمت جرى توجيهها ضد المستخدمين.
هل كانت MFA ستوقف هذا؟
ليس بمفردها. تحمي MFA تسجيل الدخول، لكن إساءة استغلال رموز OAuth تحدث بعد أن يكون المستخدم قد فوّض تطبيقًا بالفعل. الدفاع هو حوكمة الموافقة ومراقبة الرموز، لا عوامل تسجيل دخول أقوى.
ما هو «connected app» في هذا السياق؟
هو تطبيق طرف ثالث مُنح وصول API إلى منظمة Salesforce عبر OAuth. التطبيقات المشروعة (Data Loader، أدوات التحليلات) شائعة، وهذا بالضبط سبب تسلّل نسخة خبيثة مقلَّدة.
كيف أعرف إن كنت قد تأثرت؟
دقّق في تطبيقات connected apps المُصرَّح بها ومنح OAuth لديك، وأبطِل كل ما هو غير مألوف، وراجع سجلات استدعاءات API بحثًا عن عمليات تصدير جماعية غير معتادة. إذا كنت تستخدم Salesloft أو Gainsight أو Klue، فعامل حوادثها المُفصَح عنها كدافع لتدوير الرموز.
هل هذه مشكلة تخص Salesforce وحدها؟
لا. أي منصة SaaS ذات OAuth للطرف الثالث — Google Workspace، Microsoft 365، Slack، GitHub — تحمل خطر التصيّد بالموافقة نفسه. المخطط أعلاه غير مرتبط بمنصة بعينها.
Sources
- Microsoft Security — الدفاع عن التطبيقات القائمة على SaaS ضد إساءة استغلال OAuth من ShinyHunters (13 يوليو 2026) — الإفصاح الأساسي عن معلومات التهديد والتوصيات الدفاعية.
- The Hacker News — Microsoft ترسم خريطة نشاط ShinyHunters على مدى عام — ملخص مسارات الهجوم والنطاق والتقارير عن الضحايا.
- Google Cloud Threat Intelligence — دفاع استباقي ضد ابتزاز SaaS من ShinyHunters — تتبّع UNC6040/UNC6395 وإرشادات الكشف.
- Varonis — تهديد التصيّد الصوتي على Salesforce (UNC6040) — آلية انتحال Data Loader.
- Mitiga — ShinyHunters وUNC6395: اختراقا Salesforce وSalesloft — تفصيل سرقة الرموز عبر سلسلة التوريد.
- Health-ISAC — أثر ShinyHunters على قطاع الصحة — إرشادات التخفيف الخاصة بالقطاع.
- FINRA — تنبيه أمني بشأن Salesforce Experience Cloud — مسار سوء تهيئة وصول الضيف.
وقاص احمد وسیر
وقاص احمد وسیر مطوّر ومهندس أتمتة بخبرة تزيد على 8 سنوات في بناء أنظمة إنتاجية يستخدمها أكثر من 100 ألف شخص. يبني تطبيقات SaaS متعددة المستأجرين، وأتمتة بالذكاء الاصطناعي (n8n، تدفقات LLM، بوتات واتساب)، وبنية استضافة (WHM/cPanel، CloudLinux) — وهو صانع WaSphere وFlowMaticX وعلامة الاستضافة WaseerHost. أنجز أكثر من 100 مشروع لشركات صغيرة ومتوسطة ووكالات وشركات ناشئة ممولة.
