ما حدث لـMarcus & Millichap
أُدرجت Marcus & Millichap, Inc. (NYSE: MMI)، أحد أكبر وسطاء العقارات التجارية في الولايات المتحدة، على موقع تسريبات ShinyHunters في 12 أبريل 2026. ادّعت المجموعة الوصول إلى أكثر من 30 مليون سجل Salesforce تحتوي على معلومات تعريفية شخصية وبيانات مؤسسية داخلية، وحدّدت موعداً نهائياً للفدية في 14 أبريل 2026 قبل نشر البيانات أو بيعها.
اتبع الهجوم الطريقة المعيارية الآن لـShinyHunters: استغلال بيئة Salesforce سيئة التهيئة أو تدفق OAuth، وسحب بيانات CRM باستخدام أداة Data Loader الخاصة بـSalesforce نفسها، وابتزاز الضحية تحت تهديد النشر. لم تكن ثغرة منتج Salesforce مطلوبة — استغل المهاجمون كيفية تهيئة مستأجر Salesforce الخاص بـMarcus & Millichap.
حادث Marcus & Millichap يقع داخل حملة أكبر بكثير. بحلول مارس 2026، كانت ShinyHunters قد ادّعت اختراق McGraw-Hill (45 مليون سجل عبر سوء تهيئة Salesforce) وRockstar Games ومزعوماً Cisco CRM. بحلول الشهر ذاته، ادّعت المجموعة اختراق 300 إلى 400 مؤسسة عبر Salesforce، حوالي 100 منها ذات ملف شخصي عال.
كيف تخترق ShinyHunters Salesforce فعلياً
مستمد من تحليلات Help Net Security وMitiga وVaronis وSafestate وSecurity Boulevard، تدير ShinyHunters ثلاثة أنماط هجوم رئيسية على مستأجري Salesforce:
1. سوء تهيئة المستخدم الزائر في Experience Cloud (Aura)
مواقع Salesforce Experience Cloud (المعروفة سابقاً باسم Community Cloud) المبنية على إطار عمل Aura تسمح بملف تعريف «Guest User» بصلاحيات افتراضية. ملفات الزائر سيئة التهيئة — وتحديداً عند ترك صلاحية API Enabled مفعّلة — تتيح لأي زائر غير مصادَق الاستعلام عن كائنات Salesforce عبر مكالمات API مجهولة.
بنت ShinyHunters واستخدمت أداة مفتوحة المصدر تسمى AuraInspector لأتمتة هذا الاكتشاف عبر آلاف مواقع Experience Cloud. بمجرد العثور على موقع بصلاحيات زائر مفرطة السماح، تعدّ الأداة الكائنات الممكن الوصول إليها وتسحب السجلات.
2. إساءة استخدام تدفق جهاز OAuth عبر Vishing
للمستأجرين الذين لا يكشفون ملفات زائر، تتحول المجموعة إلى الهندسة الاجتماعية. تدفق جهاز OAuth مصمم للأجهزة التي ليس بها متصفح (أجهزة التلفاز الذكية، أدوات CLI) — تزور الضحية عنوان URL للتحقق، وتُدخل رمزاً قصيراً، وتُصادق على التطبيق.
تسيء ShinyHunters استخدامه عبر:
- تشغيل Salesforce Data Loader محلياً، مُهيّأ لبدء تدفق جهاز OAuth.
- توليد رمز تحقق من 8 أحرف.
- إجراء مكالمة vishing لمسؤول Salesforce ناطق بالإنجليزية، منتحلاً دعم IT أو مورّداً.
- توجيه الضحية إلى عنوان التحقق في Salesforce وإملاء الرمز.
- عند موافقة الضحية، يُصدر Salesforce رمز وصول إلى مثيل Data Loader للمهاجم.
- تسريب صامت متمهل لبيانات CRM في أجزاء صغيرة لتجنب إثارة كشف الشذوذ.
3. إساءة استخدام التطبيقات المتصلة عبر OAuth (Salesloft / UNC6040)
اخترقت ShinyHunters والمجموعة المجاورة UNC6040 (وفقاً لـMitiga) تطبيقات طرف ثالث متصلة بـSalesforce عبر OAuth — تحديداً Salesloft — واستخدمت تلك الرموز الدائمة للاستعلام عن مستأجري Salesforce في المصب.
إعلان
لماذا يتأخر الكشف
صلاحية API Enabled في Salesforce مرئية في كل وحدة تحكم إدارية للمستأجر. تظهر تطبيقات OAuth المتصلة في كل قائمة تدقيق Connected App. ومع ذلك، يصل اختراق تلو الآخر إلى موقع تسريبات ShinyHunters لأن:
- إساءة استخدام رموز OAuth غير مرئية لأنظمة SIEM القديمة. وجد CISO Report 2026 أن 84.8٪ من رؤساء أمن المعلومات يرون أن أدواتهم الأمنية غير كافية للكشف عن إساءة رموز OAuth أو مفاتيح API.
- أدوات أمن SaaS مجزأة. CASB وSSPM والسجلات الأصلية لـSaaS نادراً ما تترابط في جدول زمني واحد.
- الهندسة الاجتماعية تهزم الضوابط. تُقنع مكالمة vishing مسؤولاً شرعياً بالإذن للمهاجم. كل ضابط IAM لاحق يتصرف عندئذٍ «بشكل صحيح».
- Data Loader أداة شرعية. التسريب يبدو وكأنه مهمة تكامل طبيعية.
خطة تحصين SaaS
مُجمَّعة من Varonis وHelp Net Security وApex Hours وإرشادات Salesforce نفسها، مرتبة حسب الإجراء الفوري:
فوري (هذا الأسبوع)
- عطّل «API Enabled» في ملف Guest User على كل موقع Experience Cloud. Setup → Guest User Profile → System Permissions → ألغِ التحديد. هذا هو الضابط الأكثر تأثيراً ضد هجمات من نمط AuraInspector.
- دقّق جميع Connected Apps ذات الوصول OAuth. Setup → Apps → Connected Apps OAuth Usage. ألغِ أي تطبيقات غير معروفة أو خاملة. أعِد التفويض لتلك التي تحتاجها فعلياً فقط.
- افرض Salesforce API Access Control. قيّد أي مستخدمين وأي نطاقات IP يمكنها استدعاء API في Salesforce. يجب أن يكون الوصول الإداري للإنتاج مسموحاً به فقط من نطاقات الشركة وVPN.
30 يوماً
- دوّر وقلّل مدة حياة رموز OAuth. قلّل TTL الخاص برمز التحديث إلى الحد الأدنى الذي تتحمله تكاملاتك. افرض إعادة المصادقة على الجلسات المشبوهة.
- افرض MFA مقاومة للتصيد لجميع مسؤولي Salesforce. مفاتيح FIDO2 المادية، وليس SMS. تعتمد هجمات vishing على إيصال هدف إلى رمز عبر الكلام؛ يتطلب FIDO2 أن يمتلك المهاجم المفتاح المادي.
- انشر SaaS Security Posture Management (SSPM). أدوات مثل AppOmni وObsidian وGrip وWing Security تدقّق تهيئة Salesforce باستمرار وتُعلم بالانحراف.
- دمج Salesforce Event Monitoring في SIEM الخاص بك. راقب عمليات تشغيل Data Loader غير المعتادة، وسحب API المجمّع، ونشاط API خارج ساعات العمل.
استراتيجي (90 يوماً+)
- بناء دليل استجابة لحوادث SaaS. تختلف استجابة حوادث SaaS عن IR المحلية: لا توجد نقطة نهاية لعزلها، والسجلات بحوزة المورّد، ولا يمكن للضحية «فصل كابل الشبكة». تدرّب على إلغاء الرموز وقتل الجلسات بالجملة ومسارات التصعيد مع المورّد.
- تدرّب ضد vishing. تمارين red team تحاكي مكالمة vishing لمسؤول Salesforce، مع المسؤول كهدف blue team. قِس من يوافق على طلب OAuth الزائف.
- دمج هوية SaaS تحت SSO مع وصول مشروط صارم. Salesforce وHubSpot وWorkday وServiceNow — كل SaaS خلف نفس مزوّد الهوية مع قواعد وضع الجهاز والموقع الجغرافي ومصادقة التصعيد.
ما يعنيه ذلك عالمياً
حملة Salesforce الخاصة بـShinyHunters هي الحادث السيبراني الأكثر فائدة في 2025-2026 لأنها تهاجم الواقع التشغيلي للمؤسسات الحديثة: CRM هو مصدر الحقيقة لبيانات العملاء، ولا يزال أمن SaaS يُعامل كمشكلة المورّد. ليس كذلك. التهيئة والهوية وحوكمة OAuth هي مسؤولية العميل.
كل مؤسسة تشغّل Salesforce — وبالتالي كل مستأجر SaaS كبير — لها سطح تعرّض متماثل. قضية Marcus & Millichap لن تكون الأخيرة. المؤسسات التي تستثمر الآن في SSPM وFIDO2 وتدريبات استجابة حوادث SaaS ستكون في القائمة المختصرة لتلك التي ستتجنّب موقع التسريبات في 2027.
الأسئلة الشائعة
هل استغلت ShinyHunters ثغرة منتج في Salesforce؟
لا. تعود كل حادثة علنية إلى تهيئة من جانب العميل (صلاحيات Guest User)، أو الهندسة الاجتماعية (vishing لتدفق جهاز OAuth)، أو اختراق تطبيق طرف ثالث متصل (سلسلة توريد بنمط Salesloft). صحّحت Salesforce مشاكل مرتبطة بـAura لكن النمط القابل للاستغلال هو الإعدادات الافتراضية المفرطة السماح التي يحتفظ بها العملاء. هذا فشل في نموذج المسؤولية المشتركة.
كيف ينبغي للمؤسسات اكتشاف اختراق نشط بنمط ShinyHunters؟
راقب Salesforce Event Monitoring من أجل: قراءات API مجمّعة غير عادية، جلسات Data Loader من عناوين IP غير متوقعة، تفويضات تطبيقات OAuth الجديدة، ونشاط إداري خارج ساعات العمل. ادمج هذه مع SIEM مع خطط تلغي الرموز تلقائياً وتقفل الجلسات. بدون Event Monitoring، الكشف شبه مستحيل.
هل يمنع دفع الفدية تسريب البيانات؟
تشير الأدلة التاريخية عبر ضحايا ShinyHunters إلى أن الدفع لا يمنع بشكل موثوق التسريبات، وقد يموّل حملات إضافية. ينصح FBI ومعظم CERTs الوطنية بعدم الدفع. على المؤسسات التخطيط لسيناريو الإفصاح العلني بغض النظر عن قرار الدفع — إشعار العملاء والإيداعات التنظيمية والاستجابة للسمعة يجب التدرّب عليها.
المصادر والقراءات الإضافية
- Cisco CRM “Salesforce Data Breach” Claims Tied to ShinyHunters — Security Boulevard
- ShinyHunters Target Marcus & Millichap in Major Ransomware Attack — DeXpose
- ShinyHunters claims new campaign targeting Salesforce Experience Cloud sites — Help Net Security
- ShinyHunters and UNC6395: Inside the Salesforce and Salesloft Breaches — Mitiga
- What Salesforce Organizations Need to Know About ShinyHunters and Vishing — Varonis
- McGraw-Hill Salesforce Data Breach 2026 Analysis — Rescana











