تزايدت خلال 2026 موجة من الهجمات الإلكترونية التي لا تكتفي بسرقة البيانات، بل تحاول تحويل كل خطوة من حياة الضحية الرقمية إلى نقطة ضغط: مكالمة هاتفية تُشبه الدعم الفني، طلب “تحديث عاجل”، ثم بوابة تسجيل مزيفة تُسقط كلمات المرور ورموز التحقق، تليها حركة داخل منظومة السحابة و[Microsoft 365] و[Okta] وصولًا إلى ابتزاز علني عبر مواقع تسريب. وفق تقارير من [Google Threat Intelligence Group] و[ Mandiant] فإن هذه الحملة تُنسب إلى مجموعة تهديد تُعرف باسم [UNC6671]، وتتميز تحديدًا بالاعتماد المكثف على التصيّد الصوتي (التصيّد بالهاتف) (Vishing) كمدخل رئيسي.

الأهمية هنا ليست في “نوع الابتزاز” فقط، بل في الطريقة: الهجمات تستهدف طبقة الهوية (Identity) وتستغل الثقة بين مزود الهوية (IdP) والخدمات المتصلة، ما يسمح للمهاجمين بالانتقال عبر منظومة التطبيقات بعد جلسة مصادقة واحدة. هذا النمط يعيد تعريف ما يعنيه “اختراق الحساب” في عصر الاعتماد المكثف على [SSO] و[ MFA] وواجهات إدارة الهويات.

لماذا تستهدف الهجمات القطاع المالي والخدمات المهنية تحديدًا؟

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

• حجمًا كبيرًا من البيانات (وثائق عملاء، عقود، تقارير امتثال، سجلات تدقيق).
• تكاملًا واسعًا مع منصات هوية وسحابة (مثل [Okta] و[Microsoft Entra ID]).
• حساسية عالية تجاه انقطاع الخدمة والامتثال، ما يجعل الاستجابة الفورية لطلبات “الأعطال الأمنية” عاملًا نفسيًا يُستغل في التصيّد.

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

كيف يعمل التصيّد الصوتي (Vishing) كقناة اختراق للهوية؟

التصيّد الصوتي ليس مجرد خداع بسيط. في هذه الحملة، تُستخدم مكالمة من رقم هاتف شخصي للموظف، مع انتحال دور موظف دعم تقني (Help Desk) لتوليد شعور بوجود مشكلة “مستعجلة” تخص الحساب أو الأمان. الهدف أن يضغط الضحية على الرابط إلى صفحة تسجيل مزيفة تعمل كمنظومة اعتراض بين الضحية والمصادقة الحقيقية (Adversary-in-the-Middle) (AitM).

على نحو مبسط، يعمل نموذج (AitM) على النحو التالي:

• الضحية تُدخل بيانات الاعتماد في بوابة مزيفة.
• البنية الهجومية تلتقط كلمات المرور وتعيد توجيه الضحية/الجلسة بما يسمح بحيازة رموز المصادقة و[ MFA tokens] لحظة بلحظة.
• بعد ذلك تُستخدم البيانات لإنشاء جلسات ثابتة (Persistence) داخل بيئة الضحية، ثم تُطلق عمليات استخراج بيانات (Exfiltration) من تطبيقات سحابية و[ SaaS] مثل [Microsoft 365] و[Okta].

النتيجة أن الهجوم لا يحتاج إلى اختراق “كل تطبيق على حدة”. عندما يتم إسقاط مصادقة عبر مزود الهوية، يمكن للمهاجمين الاستفادة من العلاقة بين [IdP] والخدمات المتصلة لتجاوز مسارات الحماية في كل خدمة منفردة. لمزيد من الفهم حول [SSO] يمكن الرجوع إلى شرح [SSO] على ويكيبيديا.

من أين تأتي “الصفحات المزيفة”؟ وكيف تُدار عمليات الابتزاز متعددة الواجهات؟

وفقًا للتقارير، اعتمدت المجموعة على لوحات التقاط بيانات اعتماد تُستضاف على نطاقات عامة تبدو متصلة بموضوعات مثل [passkeys] و[ MFA] و[SSO]، مع إضافة نطاق فرعي مخصص لكل ضحية لزيادة دقة التصيّد الصوتي. كما رُصد استخدام نهج “تجزئة العلامات” عبر عدة أسماء ابتزاز عامة (extortion brands) مثل [Redact] و[Pink] و[Helix] و[Falcon]، وأيضًا الإشارة إلى علامة سابقة [BlackFile] التي قيل إنها أُوقفت في 11 مايو 2026 قبل أن تعود لفترة قصيرة برسالة إغلاق، ثم انتقلت العمليات لاحقًا إلى علامات أخرى.

هذه البنية المتعددة الأسماء ليست مجرد تغيير تسويقي؛ بل استراتيجية تشغيلية تساعد على:

• تعقيد التتبع لدى فرق الاستجابة والتحقيق.
• عزل مراحل الابتزاز عن مرحلة الاختراق نفسها.
• رفع قابلية التفاوض عبر تفاوت مسارات التفاوض حسب الضحية.

وتشير وقائع الرصد إلى أن المنظومة تعمل بإيقاع عالٍ (operational cadence)، مع استهداف “عشرات” المؤسسات في مناطق متعددة. وفي الفترة بين 7 يناير و12 مايو 2026، أفادت [Google] بأنها رصدت مدفوعات تجاوزت 10.6 مليون دولار مرتبطة بمحافظ عملات رقمية مرتبطة بالمجموعة، ما يعكس أن الابتزاز لم يكن مجرد تهديد نظري.

لماذا فشل افتراض “MFA يكفي” في هذا السيناريو؟

من أكثر الرسائل التي تترك أثرًا لدى فرق الأمن هي: MFA وحده لا يكفي عندما يكون الهجوم قادراً على الاعتراض أثناء المصادقة. ما يحدث هنا هو استغلال (AitM) لالتقاط رموز المصادقة أثناء لحظة التحقق، وليس فقط الحصول على كلمة مرور. إذا كانت [MFA] تعتمد على طرق قابلة للاعتراض أو إعادة الاستخدام ضمن جلسة مصادق عليها، فقد تتحول إلى طبقة “تسهل” الاختراق بدلًا من أن تمنعه.

لهذا السبب شددت [Google] على أهمية الانتقال إلى [MFA] مقاوم للتصيّد (phishing-resistant MFA). الفكرة العامة: استخدام آليات تحقق لا يمكن نسخها أو relayingها بسهولة عبر بوابة مزيفة، مثل مفاتيح أمان أو بروتوكولات تعتمد على التحدي-الاستجابة (Challenge-Response) مع ربط قوي بالسياق.

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

خطورة “النقطة الواحدة للدخول” على مستوى منظومة السحابة

وفق [CrowdStrike] التي تصف التجمع تحت توصيف [Cordial Spider]، تقوم المجموعة بتنفيذ سرقة بيانات بسرعة وابتزاز عبر انتحال دور الدعم الفني وإطلاق استعجال نفسي مبني على قضايا “حساب” أو “تحديث أمني”. ثم تُوجَّه الضحية إلى صفحات (AitM) تلتقط بيانات الدخول و[session tokens] في الوقت الحقيقي.

لكن أخطر عنصر هو ما يلي: عند الحصول على وصول عبر مزود الهوية، يمكن للمهاجمين استخدام “جلسة مصادقة” واحدة كمدخل لحركة جانبية داخل منظومة [SaaS]. هذا يتوافق مع تحذيرات أمنية واسعة النطاق حول مخاطر فشل التحكم في جلسات الهوية (Session Controls) عند الاعتماد على [SSO].

كما رُصد أسلوب لتثبيت الوصول عبر تسجيل أجهزة [MFA] يتحكم بها المهاجم داخل الحسابات المخترقة، مع إزالة الأجهزة القائمة قبل ذلك. هذا يعني أن حتى لو عاد الضحية إلى “تغيير كلمة المرور” أو حاول تفعيل [MFA] من جديد، قد تكون هناك طبقة وصول خفية تستمر.

إشارات إضافية: بوابات تصيّد “مقفلة” وتهرب من الباحثين

في تحليل لأحد مسارات [Pink] نشرته [SOCRadar]، وُصف تركيز الهجوم على “صيد أهداف كبيرة” عبر مجموعات [phishing kits] مُخصصة لبيئات [Okta] و[Microsoft Entra ID]، مع “بوابات” تعطل الوصول من بيئات تحليل الأمان أو تمنع الباحثين من رؤية المحتوى. كما جرى ذكر استخدام خدمات استضافة وحماية من نوع [Cloudflare] و[ DDoS-Guard]، إضافة إلى سلاسل نطاقات (Domain Registration) عبر جهات متعددة.

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

إطار الاستجابة: ما الذي ينبغي فعله قبل أن يصبح الابتزاز “نتيجة حتمية”؟

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

• تطبيق [MFA] مقاوم للتصيّد وربطه بسياسات قوية بدل الاكتفاء بأشكال قد تكون قابلة للالتقاط أثناء (AitM).
• دمج تطبيقات السحابة مع [SSO] مع ضبط سياسات وصول تفصيلية، وتقليل مساحات الحسابات المتعددة.
• ضبط التحكم في الجلسات في مزود الهوية: مراقبة الجلسات غير المعتادة، وتقليل فرص إعادة استخدام رموز المصادقة.
• تقييد المصادقة من الشبكات/الأجهزة الموثوقة قدر الإمكان، ويفضل اشتراط أجهزة مُدارة من المؤسسة.
• مراقبة سجلات [IdP] بحثًا عن تسجيلات [MFA] غير مألوفة، وتغييرات الأجهزة، ومحاولات المصادقة التي تأتي من سياقات غير متوقعة.
• حماية ضد التقاط بيانات الاعتماد عبر حلول تراقب إدخال كلمات المرور أو رموز المصادقة إلى نطاقات غير مصرح بها، وتنبيه فرق الأمن عند أي “تسريب سياقي” (Contextual Credential Entry).

على مستوى الامتثال، كثير من المؤسسات تستند إلى أطر مثل [NIST Cybersecurity Framework] وإرشادات [NIST] حول إدارة الهوية والمصادقة، إضافة إلى ممارسات [ISO/IEC 27001] لإدارة المخاطر. وفي بيئات الشركات التي تعمل ضمن الاتحاد الأوروبي، قد تُستدعى أيضًا متطلبات [GDPR] عند التعامل مع بيانات شخصية متأثرة بالانتهاك. (يمكن مراجعة [NIST] عبر ويكيبيديا كمرجع تعريفي، مع التأكد من الرجوع للنصوص الرسمية عند التطبيق.)

دروس تاريخية: لماذا تتكرر “الموجات” عندما تُستغل الثغرات البشرية والهوية؟

هذا النمط ينسجم مع تطور طويل في عالم الابتزاز: من استغلال ثغرات تقنية مباشرة، إلى اختراق عبر كلمات مرور مسروقة، ثم إلى استغلال الثقة بين الهوية والتطبيقات. ما يميز 2026 هو أن “التصيّد” لم يعد مجرد إقناع الضحية بفتح رابط؛ بل صار هندسة اجتماعية متكاملة مع اعتراض المصادقة (AitM) وبناء مسارات لحركة داخل منظومة السحابة.

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

ما الأسئلة التي يجب أن تطرحها فرق الأمن الآن؟

إذا كانت هذه الهجمات تُدار كأنها شبكة موزعة من “فرق اختراق” و“فرق تفاوض”، فهل لدى مؤسستكم القدرة على اكتشافها في الوقت المناسب قبل أن تتحول إلى ابتزاز؟

السؤال الأهم: هل يمكنكم إثبات أن [MFA] لديكم مقاوم للتصيّد في سيناريوهات (AitM)، وأن سجلات [IdP] تُراقب لالتقاط مؤشرات تثبيت الوصول عبر أجهزة [MFA] جديدة، وأن ضوابط الجلسات تمنع استمرار السيطرة بعد محاولة فاشلة أو نجاح جزئي؟

للمتابعة والنقاش، شارك هذا الموضوع مع فريق الأمن لديك وسؤالهم: ما أسرع مسار استجابة يمكنه تقليص نافذة “الهندسة الاجتماعية إلى مصادقة معترضة”؟

https://www.facebook.com/Cybrat.NET

https://x.com/CYBRAT_NET