تتكرر في تقارير الهجمات الإلكترونية قصة واحدة—لكنها لا تصبح أقل خطورة: الأمان كثيرًا ما يُبنى على “توقعات” خاطئة. شاشة تبدو كصفحة تسجيل دخول، أو دليل تثبيت مألوف، أو مكالمة “من جهة شريكة”، أو خدمة تعمل “كما اعتدناها”؛ ثم يكتشف فريق الدفاع أن الافتراض الذي اعتمد عليه النظام كان مجرد وهم. خلف الواجهة تتسلل بيانات اعتماد مُعاد استخدامها، وأدوات تحميل صامتة، ومسارات استغلال كان ينبغي أن تكون أصعب، وثقة تم إساءة توظيفها في أكثر من طبقة.
الأخبار الأخيرة تُظهر نمطًا متكررًا: الهجمات لم تعد تقتصر على إسقاط برمجيات خبيثة فقط، بل أصبحت هندسة ثقة—خلق مواقف تبدو طبيعية للمستخدم وللسياسات الأمنية معًا، ثم استخدام ذلك لفتح الطريق نحو الاستحواذ على الحسابات، والتوسع داخل الشبكات، وأخيرًا الابتزاز أو السرقة.
ما الذي يحدث عندما “تبدو الأمور طبيعية”؟
لفهم جوهر ما ورد في التقارير، من المهم توضيح ثلاث مفاهيم تتقاطع في معظم السيناريوهات الحديثة:
- استغلال الثقة (Trust Abuse): عندما يُعامل طرف أو مسار أو جهاز أو حساب على أنه “موثوق” بسبب علاقة سابقة أو اعتماد ضمني، ويُستخدم هذا التوثيق كجسر للوصول غير المصرح.
- تصيّد موجه (Spear Phishing): رسائل مُصممة لتبدو “مناسبة” لضحايا محددين، غالبًا عبر أسماء شركات، روابط خدمات شرعية، أو سرديات إدارية.
- تسوية مسار التأثير (Impact Chaining): سلسلة مراحل من التحميل الأولي إلى جمع البيانات والانتقال الجانبي ثم التشفير أو الابتزاز—بهدف تقليل فرص اكتشاف مبكر.
هذه الأفكار ليست نظرية. ففي عدة حملات موثقة مؤخرًا، كان الهدف المشترك هو جعل المستخدم يختار المسار الخاطئ: فتح رابط “تحديث”، تشغيل أمر “تثبيت”، أو منح صلاحية—ثم يتحول ذلك إلى نقطة ارتكاز للهجوم.
قطاع المال والتصنيع: ثمن الافتراضات البسيطة
تستهدف جماعات الابتزاز والسرقة المالية غالبًا القطاعات التي تتعامل مع بيانات حساسة وتملك أنظمة داخلية معقدة، خصوصًا القطاع المصرفي والتصنيع والشركات التقنية والتجزئة. والسبب واضح: أي اختراق هناك لا يقتصر على تعطيل خدمة؛ بل قد يؤدي إلى تعطيل عمليات، وإسقاط ثقة العملاء، وتسييل معلومات أو شل سلسلة التوريد.
ابتزاز برمجيات فدية مع تقليل الاعتماد على أدوات خارجية
كشفت تقارير عن مجموعة ابتزاز مالي تستهدف روسيا ومحيطها، طورت عائلة فدية مخصصة (ورد اسم GenieLocker). الأهم هنا ليس مجرد “نوع الفدية”، بل كيف تطورت أدواتها لتصبح أكثر قابلية للتشغيل داخل البيئات المستهدفة وأقل اعتمادًا على مُشفّرات طرف ثالث.
في واحدة من الحالات الموثقة، جرى الحصول على وصول أولي عبر اتصال OpenVPN قادم من شبكة شريك خارجي—وهو سيناريو يوضح خطورة الثقة بين المؤسسات. بمجرد تجاوز بوابة “الشريك”، يصبح الاستطلاع وجمع بيانات الاعتماد والانتقال الجانبي (مثل استخدام RDP وSSH) مسألة وقت.
برمجيات تجسس على أندرويد عبر واجهات تبدو كحلول أمنية
كما رصدت تقارير حملة اجتماعية تستهدف عملاء مصرفيين عبر تروجان أندرويد (مثل LunaSpy) متخفٍ تحت شكل تطبيق مضاد فيروسات. هذا النوع من الهجمات يعتمد على حقيقة أن المستخدم—خصوصًا في البيئات المالية—قد يثق في “أداة حماية” أكثر من ثقته في إشعار مجهول.
عندما يجمع التروجان صور الكاميرا والصوت ولقطات الشاشة ويستخرج بيانات حساسة، فإن “الأثر” لا يقتصر على جهاز واحد؛ بل يمتد إلى أي حسابات أو جلسات أو تأكيدات قد تُستخدم لاحقًا.
الويب والمتصفح: عندما تصبح صفحة التصيّد تجربة “شخصية”
لم يعد التصيّد مجرد صفحات ثابتة. ظهرت منصات تُنشئ صفحات مخصصة لكل ضحية، بحيث يصعب على أنظمة الحماية العامة التقاط مؤشرات نمطية. على سبيل المثال، تم وصف LogoKit بأنه تطور من “عدة تصيّد” إلى منصة خداع لحظي تبني واجهات تسجيل دخول شبيهة بالموقع الشرعي—لكنها تُخدِع المستخدم.
الفكرة الجوهرية: يتم التقاط عناصر من الموقع الحقيقي (مثل لقطات وخلفيات وشعارات) ثم تُدمج في صفحة التصيّد بحيث يبدو السياق مألوفًا. هذا يقلل فعالية مؤشرات مثل “اللافتة” أو “الاختلاف البسيط” في تصميم الصفحة، ويزيد أهمية دفاعات تعتمد على التحقق القائم على المخاطر وليس على شكل الصفحة فقط.
لمزيد من فهم آليات التصيّد، يمكن الرجوع إلى التصيّد.
أخطر بوابة: حسابات الهوية وطبقة التحكم السحابي
أحد أكثر التحولات تأثيرًا في السنوات الأخيرة هو أن الهجمات أصبحت تستهدف الهوية كخط سيطرة. فبدلًا من ضرب الخوادم مباشرة، يسعى المهاجمون إلى الحصول على وصول عبر إعادة ضبط كلمات المرور أو الالتفاف على التحقق متعدد العوامل أو اختطاف جلسات الدخول.
تحذيرات من جهات مثل Health-ISAC أشارت إلى ارتفاع هجمات ناجحة مرتبطة بمجموعات مثل ShinyHunters، حيث يتم تكرار سلسلة تعتمد على:
- هندسة اجتماعية صوتية (تُعرف غالبًا بـ [vishing])
- إعادة ضبط عبر مركز المساعدة أو تجاوز إعادة تسجيل الجهاز
- اختطاف حسابات عبر SSO مثل Microsoft Entra أو Okta أو Google
- الانتقال إلى منصات سحابية مترابطة ثم استخراج بيانات بوتيرة سريعة
الخلاصة الأمنية هنا حادة: SSO هو “لوحة التحكم” في كثير من المؤسسات. وإذا تمكن الخصم من السيطرة عليها، فسيصبح اختراق SaaS بمثابة فتح أبواب متعددة في وقت واحد. لمزيد من الخلفية حول SSO، راجع التسجيل الموحد.
تطورات سلسلة التوريد والبرمجيات: من الحزم إلى المُشغلات
بينما تركز فرق الدفاع على تصحيح الثغرات، يستمر الخصوم في استغلال نقاط ضعف “سلسلة التوريد” خصوصًا في المستودعات وعمليات البناء والنشر وبيئات التكامل المستمر (CI/CD). هنا يأتي دور جهود مثل ما أعلنته GitHub من تحسينات لتقليل مخاطر استهداف مستودعات الحزم وعمليات التشغيل الآلي.
من بين الإجراءات المذكورة: حماية حسابات عالية الأثر في npm، وضبط افتراضي أكثر أمانًا لـ GitHub Actions، والتحكم بمن يملك صلاحية تشغيل مسارات العمل، وتجميد نسخ الحزم عند التحديثات، وإجراءات لإلغاء الاعتمادات ذاتيًا أثناء الاستجابة للحوادث.
هذه ليست مجرد “أفضل ممارسات”. إنها استجابة لواقع أن الهجمات لم تعد تحتاج دائمًا إلى اختراق مباشر؛ أحيانًا يكفي أن تُسمم نقطة توزيع أو خطوة بناء لتصل البرمجيات الخبيثة إلى عدد كبير من الضحايا بسرعة.
ثغرات تُستغل بسرعة: عندما يتقدم الهجوم على التصحيح
أحد أكثر المؤشرات تقلقًا هو تسارع استغلال الثغرات المعروفة. تحليل من VulnCheck يشير إلى أن نسبة من الثغرات المدرجة ضمن KEVs (الثغرات المعروفة التي تم استغلالها) يظهر عليها دليل استغلال قبل يوم نشر CVE، وأن الزمن الوسيط من نشر CVE إلى بداية الاستغلال انخفض من 120 يومًا في 2025 إلى 80 يومًا في النصف الأول من 2026.
هذا يعني أن نافذة الاستجابة التقليدية—من اكتشاف الثغرة إلى نشر التصحيح ثم تطبيقه—قد لا تكفي. الدفاع هنا يتطلب:
- إدارة Patch أسرع وأكثر انتظامًا
- ترتيب الأولويات وفق “قابلية الاستغلال” لا وفق “شدة التصنيف فقط”
- تقليل سطح الهجوم عبر تقوية الإعدادات الافتراضية
- مراقبة سلوك الشبكة والهوية بحثًا عن استغلال مبكر
لمزيد من فهم CVE وKEV، يمكن الرجوع إلى Common Vulnerabilities and Exposures.
الذكاء الاصطناعي والهجمات ذات الحكم الذاتي: من مهارة المهاجم إلى “تسريع” الهجوم
هناك اتجاه واضح: دمج أدوات ذكاء اصطناعي في مسار الهجوم، ليس فقط لصناعة رسائل مقنعة، بل لتوليد أكواد/محاولات استغلال، وجمع بيانات عن بيئة الضحية، واتخاذ قرارات تشغيلية. في تقارير عن حملات “ذاتية” تستغل عدة ثغرات في منصات شائعة (مثل أنظمة إدارة سير العمل، بوابات تطبيقات، وأجهزة طرفية)، تم وصف استخدام وكلاء ذكيين لتقييم الثغرات وتحديد الأهداف وتجميع الأدلة.
المفارقة أن هذا لا يعني أن الهجمات أصبحت “أكثر ذكاءً” بالضرورة؛ بل تعني أنها أصبحت أكثر اتساقًا في التنفيذ وأقل اعتمادًا على الخبرة البشرية في كل خطوة.
كيف تتعامل المؤسسات مع “افتراضات الثقة” قبل أن تُستغل؟
إذا كان الدرس واحدًا من كل هذه السيناريوهات، فهو أن الدفاع لا يجب أن يقتصر على منع الاختراق فقط، بل على تقليل قيمة الافتراضات التي يعتمد عليها المستخدم أو النظام أو الشريك. إليك إطارًا عمليًا:
- تدقيق روابط الثقة بين الشركاء: افصل الشبكات، وطبّق مبدأ أقل صلاحية، وراقب الاتصالات القادمة من الطرف الثالث.
- حماية الهوية كخط أول: راقب أنماط الدخول، وطبّق سياسات مخاطرة، ولا تعتمد على “شكل” صفحة أو “سياق” رسالة.
- تعزيز المراقبة القابلة للتحقيق: خاصة على أجهزة الحافة مثل الجدران النارية وبوابات VPN. التشخيص العدلي (Forensics) يتطلب “قابلية رؤية” بعد وقوع الحادث، وليس فقط تنبيهات.
- تقليل الاعتماد على التحقق السطحي: فالتصيّد الشخصي يقلل فعالية المؤشرات العامة.
- اختبار مسار الاستجابة للحوادث: تأكد أن الفريق يستطيع جمع الأدلة بسرعة، وفهم ما إذا كان الجهاز/الخادم ما يزال “موثوقًا”.
يمكن اعتبار هذا امتدادًا لمبدأ الدفاع المتعدد الطبقات، لكن مع التركيز على “سلسلة الثقة” داخل المؤسسة.
إحصاءات وواقع عملي: لماذا لا يكفي تحديث الأنظمة وحده؟
حتى مع تسارع تصحيحات كبرى الشركات، مثل ما أُعلن عن تحديثات واسعة لمنتج متصفح شهير (مع مئات الثغرات المرقعة خلال فترة زمنية قصيرة)، تظل المشكلة في التطبيق الفعلي والزمن والانتشار. بالإضافة إلى ذلك، لا يعني غياب “استغلال مُعلن” أن الهجوم غير نشط؛ كثير من الهجمات تبقى غير مرئية حتى تصبح النتائج واضحة.
هناك سبب إعلامي بسيط لهذا: معظم حالات الفشل تبقى صامتة—لا تُسجَّل لأنها لم تُسبب ضررًا بعد. لكن عندما ينجح الافتراض الخاطئ مرة واحدة، يمكن أن يتحول الفشل الصامت إلى اختراق واسع.
ختام: ما الافتراض الذي لا تفحصه مؤسستك بما يكفي؟
قد تعمل شاشة تسجيل الدخول كما اعتدت. وقد ينجح اتصال الشريك. وقد يبدو أن الأداة “سلوكها طبيعي”. ثم يأتي يومٌ يكتشف فيه الفريق أن افتراضًا واحدًا كان يؤدي وظيفة الأمان كلها.
سؤالي لك: ما هو الافتراض الأكثر شيوعًا في بيئتك—صفحة تسجيل، رابط بريد، صلاحية شريك، مسار تحديث، أو ثقة في “سلوك طبيعي”—والذي لم يتم اختباره فعليًا ضد سيناريو تصيّد أو اختراق هوية أو استغلال ثغرة قبل أن يصبح مكلفًا؟
للمتابعة والنقاش، يمكنك زيارة حسابنا على وسائل التواصل:
وسوم نقاش مقترحة: #أمن_المعلومات #الهوية #التصيّد #سلسلة_التوريد #استجابة_للحوادث
مصادر إضافية (للقراءة الموسعة):
Leave a Reply