في الثاني عشر من يونيو 2026، تمكّن المهاجمون من الإيقاع بـ Klue — منصة SaaS للاستخبارات التنافسية — واستخدامها نقطةَ انطلاق للنفاذ إلى بيئات CRM الخاصة بـ Salesforce لدى ما لا يقل عن عشرة من عملاء Klue من الشركات الكبرى. وبحلول إعلان Klue عن الاختراق في الحادي والعشرين من يونيو، كان المهاجمون قد نجحوا بالفعل في استخراج بيانات جهات الاتصال التجارية وعروض الأسعار وملاحظات فرص البيع والتفاصيل التعاقدية من منظمات من بينها HackerOne وHuntress وSnyk وRecorded Future وJamf وOneTrust وTanium وSprout Social وGong وInsurity. وتبنّت مجموعة الجرائم الإلكترونية Icarus مسؤولية الهجوم، مهدِّدةً بنشر جميع البيانات المسروقة ما لم تدفع كل ضحية فدية قبل الثالث والعشرين من يونيو 2026. وكانت Salesforce قد عطّلت تكامل تطبيق Klue Battlecards في السابع عشر من يونيو إثر رصد “نشاط غير معتاد يتعلق بالتطبيق قد يكون أفضى إلى وصول غير مصرح به”.
لا يُعدّ هذا الحادث حدثاً استثنائياً منفرداً؛ إذ يستحضر اختراق أغسطس 2025 عبر تكامل Salesloft/Drift، ويندرج ضمن نمط أوسع يرصده الباحثون الأمنيون منذ عامين: مهاجمون يستهدفون جسور OAuth الرابطة بين منصات SaaS عوضاً عن المنصات ذاتها. وتُعدّ قضية Klue الدليل الأوضح حتى الآن على ما يمكن أن ينتج عن هذا النمط على نطاق واسع — وعلى مدى السرعة التي يمكن بها لحساب خدمة مخترق واحد أن يُقوّض الوضع الأمني لقاعدة عملاء بأكملها.
كيف يعمل هجوم سلسلة التوريد عبر SaaS
لفهم سبب نجاح اختراق Klue بهذا الشكل اللافت، لا بد من فهم آلية عمل تكاملات SaaS الحديثة. حين تربط شركةٌ ما Klue بمثيل Salesforce الخاص بها، فإنها تمنح Klue مجموعةً من رموز OAuth — وهي بيانات اعتماد طويلة الأمد تُخوّل خوادم Klue بقراءة بيانات Salesforce وكتابتها نيابةً عن العميل. وتُخزَّن هذه الرموز لدى مزوّد التكامل. ومن منظور المهاجم، يُفرز هذا هدفاً واحداً بالغ القيمة: اختراق مزوّد واحد يُتيح توارث صلاحية الوصول المشروع إلى عشرات أو مئات من البيئات العميلة في آنٍ واحد.
في حادثة Klue، كانت نقطة الدخول بيانات اعتماد قديمة مخترقة — على الأرجح كلمة مرور أو رمز حساب خدمة — مرتبطة بحساب خدمة تكامل. وما إن حصل المهاجمون على موطئ قدم داخل البنية الخلفية لـ Klue، حتى أطلقوا أوامر غير مصرح بها ودفعوا تحديث كود خبيثاً مُصمَّماً خصيصاً لاصطياد رموز OAuth التي تحتفظ بها Klue نيابةً عن عملائها. وبعد امتلاكهم لهذه الرموز، انتقل المهاجمون مباشرةً إلى بيئات Salesforce العميلة عبر واجهة برمجة التطبيقات REST الخاصة بـ Salesforce — نفس نقطة النهاية التي تستخدمها Klue للمزامنة المشروعة للبيانات.
وفق تحليل ReliaQuest، كان الاستخراج سريعاً ومنهجياً في آنٍ معاً: إذ أطلق المهاجمون ما يقارب ألف استعلام API في خمس عشرة دقيقة، ثم حافظوا على نوافذ استخراج ممتدة تجاوزت ست ساعات. واستخدموا تقنية تُعرف بـ “QueryMore” لاسترداد البيانات في كتل مُقسَّمة، متحايلين بذلك منهجياً على حد الـ 2000 سجل المفروض على استجابات API في Salesforce. والنتيجة: استخراج منظّم وواسع النطاق لبيانات CRM مع أدنى قدر من الضجيج — بالضبط ذلك النوع من النشاط الذي يندمج مع حركة مرور التكامل الاعتيادية.
استجابت Klue في الثاني عشر من يونيو بسحب بيانات الاعتماد المخترقة فوراً وتعطيل التكاملات مع Salesforce وHubSpot وSharePoint وZoom وGong وChorus وClari وGoogle Drive وSlack. وعقدت الشركة اتفاقاً مع CrowdStrike للاستجابة للحادث وأخطرت الجهات القانونية المختصة. وعلى الرغم من سرعة الاحتواء، كانت الأضرار قد وقعت بالفعل — إذ لم تتجاوز نافذة الاختراق من بدء الوصول إلى الاستخراج أربعاً وعشرين ساعة.
لماذا تتصاعد هذه الهجمات؟
لم ينجح اختراق Klue لأن Salesforce كانت ضعيفة. بل نجح لأن المهاجم لم يلمس أنظمة المصادقة الأصلية لـ Salesforce قط. فكل استعلام وصل إلى API Salesforce حمل رمز OAuth مشروعاً — صادراً من Salesforce ذاتها — ولم يكن ثمة سبب لإلغائه حتى أبلغت Klue عن الحادث بعد أيام. هذه هي السمة المحددة لهجمات سلسلة توريد SaaS: إنها تُسلّح الثقة.
ثلاثة اتجاهات هيكلية تُسرّع هذه الفئة من الهجمات. أولاً، تربط المؤسسة المتوسطة اليوم عشرات الأدوات البرمجية بأنظمة CRM وERP المحورية لديها. وكل تكامل يُجسّد علاقةَ ثقة ضمنية، وكل علاقة ثقة تُشكّل سطحاً محتملاً للهجوم. وقد كشف مسح أجرته Nudge Security عام 2025 أن الشركة المتوسطة الحجم لديها أكثر من 200 اتصال OAuth نشط بين تطبيقات SaaS — غالبيتها غير موثّقة وغير مُراقَبة من قِبل فريق الأمان.
ثانياً، تحتفظ شركات التكامل — ولا سيما في مجالات الاستخبارات التنافسية والعمليات التجارية ونجاح العملاء — بنطاقات OAuth واسعة للغاية. فأداة الاستخبارات التنافسية التي تحتاج لقراءة بيانات الفرص تجد نفسها في الغالب مزوَّدة برموز تمنح أيضاً وصولاً إلى جهات الاتصال والحسابات والعقود وقوائم الأسعار. وكانت رموز Klue واسعةً بما يكفي لتمكين المهاجمين من استعراض البيانات واستخراجها عبر كائنات Salesforce متعددة في جلسة ممتدة واحدة.
ثالثاً، طوّر ممثلو التهديد مناهجهم في المقابل. وقد ظهرت Icarus فحسب في أواخر أبريل 2026 بضحيتين سابقتين فقط قبل عملية Klue. وتعكس السرعة التي نفّذت بها مجموعة ابتزاز وليدة هجوماً على سلسلة التوريد عبر SaaS متعدد المستأجرين — مستهدِفةً بنية التكامل بدلاً من نقاط النهاية أو المحيطات الشبكية — مدى سهولة الوصول إلى هذا النمط من الهجوم.
إعلان
ما يجب على فرق الأمان والمسؤولين عن أمن المعلومات فعله
تُشكّل حادثة Klue دافعاً قوياً لإعادة النظر في كيفية إدارة المؤسسات لعلاقات الثقة بين منصات SaaS. والإجراءات التالية مُرتَّبة حسب الأثر الفوري.
1. مراجعة جميع اتصالات OAuth الخارجية بالأنظمة الحيوية
ابدأ ببيئات Salesforce وHubSpot وGoogle Workspace لديك. أنشئ قائمة جرد شاملة لجميع التطبيقات المتصلة ونطاقات OAuth التي تمتلكها وتاريخ آخر استخدام لكل رمز. يستطيع معظم مديري Salesforce استخراج هذه المعلومات من الإعداد ← التطبيقات المتصلة ← استخدام OAuth. لكل اتصال، اطرح ثلاثة أسئلة: هل لا تزال هذه التطبيقات بحاجة إلى هذا الوصول؟ هل النطاق أضيق مما هو ممنوح؟ متى جرت مراجعة هذا الاتصال آخر مرة؟ احذف أي رمز لم يُستخدَم منذ 90 يوماً أو ينتمي إلى مورّد لم تعد المؤسسة تتعامل معه فعلياً.
2. تطبيق رصد مستمر لنشاط API الخاص بـ Salesforce
أطلق مهاجمو Klue ما يقارب 1000 استعلام API في 15 دقيقة — نمط شاذ بأي معيار، غير أنه لم يُرصَد إلا بأثر رجعي. ينبغي لفرق الأمان وضع معدلات استعلام API مرجعية لكل تطبيق متصل والتنبيه عند الانحراف بما يزيد عن انحرافَين معياريَّين عن المتوسط المتحرك. نشر Datadog Security Labs قواعد كشف محددة لنمط هجوم Klue، بما فيها تسلسلات التصدير الجماعي عبر QueryMore، يمكن اعتمادها نموذجاً للبدء. منتج Salesforce Shield Event Monitoring يلتقط البيانات اللازمة؛ والثغرة تكمن عادةً في التحليل والتنبيه.
3. تطبيق مبدأ الحد الأدنى من الصلاحيات على نطاقات OAuth للتكاملات
تطلب معظم تكاملات SaaS نطاقات OAuth واسعة عند الإعداد الأولي ونادراً ما تُراجَع لاحقاً. لكل تطبيق متصل، قارن النطاقات الممنوحة حالياً بالنطاقات التي يحتاجها الأداة فعلاً لأداء وظيفتها. أداة الاستخبارات التنافسية تحتاج لقراءة أسماء الفرص والحسابات؛ وليست بحاجة إلى صلاحية الكتابة في جهات الاتصال أو الوصول إلى سجلات التسعير. حيثما تسمح ملفات تعريف التطبيقات المتصلة بـ Salesforce بتقييد نطاقات OAuth المخصصة، طبّقها. وتفاوض على شروط صريحة لمعالجة البيانات مع موردي التكامل تشمل مهل الإخطار بالاختراق وأحكام المسؤولية عن سوء إدارة بيانات الاعتماد.
نموذج الثقة في SaaS تحت الضغط
يكمن المدلول الأشمل لحادثة Klue في أن نموذج الثقة في SaaS — الذي بموجبه يُؤتَمن موردو التكامل ضمنياً على حماية بيانات الاعتماد التي تحتفظ بها منتجاتهم — لا يتناسب جوهرياً مع بيئة المخاطر التي تعمل فيها المؤسسات اليوم. حين اختُرق حساب الخدمة القديم الخاص بـ Klue، لم تكن ثمة آلية تُمكّن عشرات الشركات العميلة الأكثر تعرضاً من معرفة، في الوقت الفعلي، أن رموز OAuth الخاصة بـ Salesforce كانت تُستخدَم لتفريغ بيانات CRM الخاصة بهم. Klue احتفظت بهذه الرموز؛ وكانت Klue مسؤولة عن حمايتها؛ وحين أخفقت هذه الحماية، امتد نطاق الضرر فوراً ليشمل كل عميل كان رمزه يقبع في مخزن الرموز الخاص بـ Klue.
هذه ليست مشكلة خاصة بـ Klue. إنها خاصية هيكلية لآليات عمل أسواق تكامل SaaS الحديثة. فئة الاستخبارات التنافسية وحدها — التي تضم Klue وCrayon وBombora وعشرات الأدوات الأصغر — تحتفظ جماعياً برموز OAuth لمثيلات Salesforce الخاصة بآلاف العملاء من الشركات الكبرى. وينطبق الأمر ذاته على منصات تفاعل المبيعات وأدوات عمليات الإيرادات ومنصات نجاح العملاء وموردي إثراء البيانات. تُشير حادثة Klue إلى أن المنظمين ومشتري الأمن المؤسسي سيطالبون بشكل متزايد بأن تُثبت شركات SaaS كيفية حمايتها لبيانات اعتماد التكامل. المؤسسات التي تنتظر الضغط التنظيمي للتحرك ستجد نفسها في موقف العشر شركات التي كانت تتسابق لتقييم مخاطر تعرّضها عبر Salesforce في أسبوع الثاني عشر من يونيو 2026.
الأسئلة الشائعة
ما البيانات التي سُرقت في اختراق Klue لـ Salesforce؟
استخرج المهاجمون معلومات الاتصال التجاري (الأسماء وعناوين البريد الإلكتروني والمسميات الوظيفية وأرقام الهواتف)، وبيانات حسابات المبيعات، وعروض الأسعار، وملاحظات الفرص، وفي بعض الحالات معلومات العقود المخزنة في بيئات Salesforce لدى العملاء. لم تُبلَّغ عن أي حالات مؤكدة لسرقة بيانات الثغرات لدى العملاء أو معلومات بطاقات الدفع أو البيانات الهندسية بين الضحايا المُفصَح عنهم.
كيف تمكّن المهاجمون من الدخول إلى Klue في المقام الأول؟
كانت نقطة الدخول الأولية بيانات اعتماد قديمة مخترقة — كلمة مرور أو رمز حساب خدمة — مرتبطة بحساب خدمة تكامل لم يُعاد تدويره أو إيقافه بشكل صحيح. بمجرد الدخول، دفع المهاجمون تحديثاً ببرمجية خبيثة حصدت رموز OAuth التي كانت Klue تحتفظ بها نيابةً عن عملائها، مما أتاح لهم الوصول المباشر عبر API إلى بيئات Salesforce لدى هؤلاء العملاء.
كيف يمكن للمؤسسات اكتشاف هذا النوع من الهجمات في بيئة Salesforce الخاصة بها؟
أفرز هجوم Klue أنماطاً شاذة في نشاط API مرئية في سجلات أحداث Salesforce: ما يقارب ألف استعلام API في 15 دقيقة ونوافذ استخراج مستمرة تتجاوز ست ساعات باستخدام تقسيم QueryMore. ينبغي للمؤسسات تفعيل Salesforce Shield Event Monitoring وإنشاء معدلات مرجعية لاستعلامات API لكل تطبيق، وإنشاء تنبيهات لتسلسلات QueryMore المجمّعة التي تُطلقها التطبيقات المتصلة خارج ساعات العمل الاعتيادية أو بأحجام غير طبيعية. نشر Datadog Security Labs قواعد اكتشاف محددة مستندة إلى بصمة هجوم Klue.
المصادر والقراءات الإضافية
- Klue hack results in data breach at several cybersecurity firms — TechCrunch
- Cybersecurity Firms Impacted by Klue Supply Chain Attack — SecurityWeek
- Klue breach exposes Salesforce data across the SaaS supply chain — Nudge Security
- Detecting the Klue supply chain attack in Salesforce instances — Datadog Security Labs
- Security shops among the ‘hundreds’ of Klue hack victims — The Register
- Salesforce Disables Klue Integration After OAuth Token Theft — HackRead














