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

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

ما الذي حدث؟ عملية “بوابة” بصمات قبل عرض فخ البرمجيات الخبيثة

بحسب مايكروسوفت، جرى رصد عملية على نطاق واسع تشمل أكثر من 250 نطاقًا أماميًا (front-end domains). كانت هذه النطاقات لا تعمل فقط كمواقع واجهة، بل كانت جزءًا من منظومة قرار: عند زيارة المستخدم، يقوم الخادم بفحص بصمات الجهاز والمتصفح، ثم يقرر ما الذي سيظهر له.

تصف مايكروسوفت أن البوابة تخفي الصفحة الخبيثة عن الزواحف (crawlers) والبيئات التي تُستخدم عادة للتحليل الآلي والساندبوكس (sandboxes). وفي المقابل، تعرض لعدد محدود من مستخدمي macOS صفحة تحميل مزيفة تحت طابع “ملف آمن” أو “تنزيل لنظام macOS”، مع شارة “ناشر مُتحقق” مزورة—وهو أسلوب يُعرف ضمنيًا في مجال الهندسة الاجتماعية باسم انتحال الثقة.

لماذا تُعد “بوابة” البصمات سلاحًا فعالًا؟

لأن التحليل الآلي يعتمد غالبًا على زواحف وبروكسيات وبيئات افتراضية قد لا تُظهر سلوكًا مطابقًا لجهاز حقيقي. الهجوم يستفيد من ذلك عبر فحص مؤشرات مثل:

• سلسلة المنصة (platform string) التي يُفترض أن تُظهر “MacIntel” على جهاز ماك حقيقي.
• أبعاد الشاشة وخصائص النوافذ.
• إشارات رسومات الويب (WebGL) التي قد تختلف بين الأجهزة الحقيقية والآلات المُماثلة أو البيئات المحاكية.
• المنطقة الزمنية (timezone) ومؤشرات ما إذا كانت الصفحة داخل iframe.
• دعم اللمس؛ إذ إن سطح المكتب لدى macOS عادة لا يقدم نفس مؤشرات اللمس في المتصفحات.

هذا النوع من التحقق يُصنف كـ بصمة جهاز/متصفح (Browser Fingerprinting)، وهي تقنية تُستخدم على نطاق واسع في التتبع الإعلاني—لكنها تُستغل هنا لأغراض دفاعية/هجومية: تحديد “من يستحق الفخ” ومن لا يستحق.

كيف تُكتشف بيئات التحليل؟ مؤشرات تستهدف المحللين مباشرة

لا تكتفي البوابة بمؤشرات عامة. بل تتضمن—بحسب مايكروسوفت—اختبارات موجهة لاستهداف أدوات التحليل. من أبرزها:

• عداد يرتفع عند فتح Developer Console؛ فالمحللون عادة يفتحون وحدة التحكم لملاحظة السلوك.
• اختبار “tripwire” عبر استدعاء canPlayType(“video/mp4”) بقراءة غير مباشرة لخصائص codec المعلنة في جافاسكربت. في البيئات التي تحاكي المتصفح قد تبدو هذه القدرات “مُزيفة” أو غير متسقة.

تأثير ذلك عمليًا: حتى لو زار الباحثون نفس النطاق، قد لا يحصلون على نفس المحتوى. فقرار العرض يتم على الخادم لكل طلب، ما يعني أن زيارتين لنفس العنوان قد تُنتجان صفحتين مختلفتين تمامًا.

هذا المبدأ قريب من ما يُعرف في الأوساط الدفاعية بتقنيات التمويه ضد التحليل (Anti-analysis). وللمقارنة العامة، يمكن مراجعة خلفية تقنية بصمة المتصفح لفهم كيف تُبنى “هوية” رقمية غير مرتبطة بالكوكيز فقط.

ما الذي يحدث بعد المرور؟ شرط الطرفية لتنفيذ سلسلة سرقة المعلومات

رغم أن الهجوم يستخدم بوابة بصمات لإخفاء الفخ عن بيئات التحليل، فإن تشغيله الحقيقي لا يبدأ إلا عندما يحقق الضحية خطوة تفاعلية. تؤكد مايكروسوفت أن الهجوم يتطلب من المستخدم نسخ أمر غامض وتشغيله داخل Terminal.

الأمر—كما حللت مايكروسوفت—يستدعي سكربتات إضافية ثم يشغّل سلسلة تؤدي إلى AMOS، وهي ضمن ما وصفت مايكروسوفت بأنه MacSync وAtomic Stealer (AMOS) في سياق أوسع من حملات سرقة المعلومات على macOS.

وتشير الدراسة إلى أن الهدف النهائي يشمل سرقة أو جمع بيانات حساسة مثل:

• بيانات الاعتماد (credentials) من مصادر مختلفة.
• بيانات المتصفح.
• متاجر المصادقة (authentication stores).
• محافظ العملات الرقمية.
• ملفات حساسة.

هذه التركيبة تُظهر أن الهجوم ليس “برمجية فدية” ولا “تخريبًا مباشرًا” بقدر ما هو حصاد بيانات يركز على ما يمكن تحويله لاحقًا إلى وصول غير مصرح به، ابتزاز، أو بيع بيانات في أسواق غير قانونية.

لماذا لا نركز فقط على النطاقات الأمامية؟ استراتيجية البحث يجب أن تتغير

من المغري للفرق الدفاعية مطاردة “أسماء النطاقات” التي تبدو غريبة أو تشبه كلمات مثل “file” مع قواميس، لأن ذلك أسهل في التحري السريع. لكن مايكروسوفت تحذر: نمط الأسماء وحده ليس كافيًا. فالمجرمون يمكنهم تغيير الأسماء بسهولة بينما يبقى “جوهر السلوك” أكثر ثباتًا.

وفق مايكروسوفت، كانت هناك إشارة قوية تجمع بين:

• أسماء مُستحدثة أو غير منطقية.
• سلوك البنية التحتية المشتركة.
• بوابة البصمات (المنطق الذي يقرر ما الذي سيُعرض).
• مسارات مُحددة في البنية الخلفية مثل /curl/ التي تُستخدم لجلب سكربتات لاحقة بعد تنفيذ الأمر.

بعبارة دفاعية: التحري يجب أن يلاحق “البوابة” و”سلوك التنفيذ” أكثر مما يلاحق عنوان الواجهة وحده.

علامات إنذار عملية للمدافعين: من التصفح إلى نشاط الطرفية

تقترح مايكروسوفت أن الدفاعات ينبغي أن تراقب سلسلة مترابطة تبدأ من التصفح وتنتهي بأوامر طرفية غير معتادة. من بين المؤشرات التي ذُكرت:

• تصفح صفحة ثم تنفيذ نشاط Terminal بشكل غير مألوف.
• وجود curl يتم تمريره إلى zsh.
• استخدام Base64 لفك/ترميز محتوى سكربتات.
• استدعاء osascript (غالبًا لأتمتة واجهات النظام أو تنفيذ منطق إضافي).
• إنشاء أرشيفات ثم إرسال طلبات خارجية عبر HTTP POST.

هذه ليست مجرد “علامات تقنية” بل هي نقطة تحول في منهجية الحماية: ربط سياق التصفح بـ سياق التنفيذ محليًا (endpoint activity) هو ما يحول الكشف من رد فعل إلى استباق.

اتجاهات أوسع: لماذا ما زال شرط لصق أمر الطرفية فعّالًا؟

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

وتشير مايكروسوفت إلى أن هذا يتماشى مع تحول أوسع في حملات سرقة معلومات macOS، حيث أصبحت بعض العائلات تستخدم Terminal commands لجلب سكربتات عن بعد بدلًا من الاعتماد على صورة قرص أو تثبيت يدوي واضح. هذا النموذج يقلل آثار التثبيت المبكر ويزيد من المرونة.

ما الذي يمكن أن تفعله المؤسسات الآن؟ ربط الحماية بسياسات استخدام الطرفية

على مستوى الدفاع، لا يكفي الاعتماد على حجب النطاقات. المطلوب هو “تقوية مسار التنفيذ” ومنع سيناريوهات لصق الأوامر غير المبررة. ومن أمثلة الإجراءات العملية:

• تفعيل سياسات مراقبة الطرفية وربطها بسجلات الويب/المتصفح عند الإمكان.
• حظر أو تقييد تنفيذ أدوات شائعة في سلاسل التسليم مثل curl وosascript ضمن سياقات غير مصرح بها (باستخدام سياسات EDR أو قواعد تطبيق).
• استخدام قدرات الكشف عن الشفرة المرمزة (مثل سلوكيات Base64) وربطها بمحاولات الشبكة الخارجية.
• تعزيز الوعي: تدريب المستخدمين على قاعدة بسيطة—لا تنسخ أو تلصق أي أوامر في Terminal بناءً على تعليمات موقع أو رسالة.

ومن الناحية التقنية في نظام Apple، تم تحديث حماية macOS 26.4 (وفق ما ورد في التقرير) مع توثيق يركز على تقليل المخاطر المرتبطة بإدخال أوامر الطرفية وعمليات التنفيذ غير المعتادة. كما يبرز دور XProtect في تتبع سلوك الأوامر المرتبطة ببرمجيات خبيثة.

كيف تنسجم هذه التوصيات مع أطر الحوكمة؟

حتى لو كانت الهجمات تقنية للغاية، فإن الاستجابة تتطلب حوكمة. يمكن مواءمة هذه الإجراءات مع مبادئ مثل:

• إطار NIST للأمن السيبراني (خصوصًا مجالات الكشف والاستجابة).
• مبدأ الثقة المعدومة (Zero Trust) عبر تقليل الاعتماد على “السلامة المفترضة” للمصادر.
• ممارسات إدارة الأصول والضبط المؤسسي لسطح المكتب ضمن برامج إدارة المخاطر.

ملاحظة مهمة: “لا يبدو خبيثًا” لا يعني “آمن”

من النقاط التي تستحق التركيز—كما شددت مايكروسوفت—أن استجابة تبدو بريئة أو مطابقة للشكل ليست دليلًا على السلامة. لأن قرار المحتوى يتم على الخادم بناءً على بصمات الزائر، قد تحصل على صفحة مختلفة تمامًا عن باحث آخر أو عن بيئة تحليل آلي.

بمعنى آخر: لا يوجد ضمان من شكل الصفحة وحده. ما يلزم هو فحص السلوك (behavior) وربط الإشارات بين الويب والـ endpoint بدلًا من الاكتفاء بقائمة نطاقات.

نقطة نقاش: هل نحتاج إلى “سياسة مؤسسية” ضد لصق الأوامر في الطرفية؟

إذا كانت الهجمات الحديثة تعتمد على تحويل المستخدم إلى منفذ عبر Terminal، فالسؤال ليس فقط “كيف نكتشف هذا النوع من البرمجيات؟” بل: هل لدى مؤسستك قواعد واضحة تمنع المستخدمين من تنفيذ أوامر بناءً على تعليمات من مواقع غير موثوقة؟

ما رأيك: هل يجب أن تتحول حماية الطرفية في المؤسسات إلى سياسة إلزامية بحد أدنى (baseline) مثل ضوابط كلمات المرور، أم ما زلنا نبالغ في التركيز على جانب البرامج ونقلل من “نقطة الإنسان” في سلسلة الهجوم؟

مصادر إضافية

• تقارير أبحاث مايكروسوفت الأمنية
• Browser Fingerprinting على ويكيبيديا
• Infostealer على ويكيبيديا
• XProtect على ويكيبيديا

للتواصل والمتابعة:
فيسبوك،
إكس.