داخل هجوم التصيد الذي يحدث في الوقت الفعلي

في هذا المثال، سنحلل حملة تصيد احتيالي تتنكر في صورة Netflix وتستخدم آلية التحكم في الضحية في الوقت الفعلي. وهذه ليست مجرد نموذج HTML ثابت عادي، بل خدمة تصيد كاملة: يمر المستخدم بعدة مراحل، ويقرر المشغل من لوحة التحكم إلى أين يوجهه بعد ذلك — إلى إدخال اسم المستخدم، أو بيانات البطاقة، أو رمز الرسالة القصيرة، أو رمز PIN، أو التأكيد في التطبيق.

وقد تأكدنا بشكل منفصل من آلية العمل هذه من خلال الوصول إلى لوحة التحكم الخاصة بهذا الموقع الاحتيالي ودراستها.

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

0. الطُعم

أول ما يتلقاه المستخدم هو رسالة تتضمن تكتيكات الهندسة الاجتماعية المعتادة لحثه على اتخاذ إجراء. ويأمل المهاجمون في جذب انتباه المستخدم إلى احتمال تعليق مشاهدته لبرامجه التلفزيونية المفضلة. ولتجاوز مرشحات البريد وإخفاء نطاق التصيد النهائي، يستخدم المهاجمون رابطًا مختصرًا عبر البنية التحتية لشبكة التواصل الاجتماعي X: https://t.co/XXXXXXX

للوهلة الأولى، يبدو هذا الرابط عاديًا عبر t.co، ولذلك تبدو أقل إثارة للريبة بالنسبة للمستخدم وبالنسبة لبعض المرشحات التلقائية.

بعد النقر، لا ينتقل المستخدم مباشرةً إلى الصفحة الرئيسية للتصيد. بل يتم توجيهه أولاً إلى مورد وسيط.

1. حاوية S3 العامة كجهاز إعادة توجيه وسيط

يؤدي الرابط إلى سلة S3 عامة: https://access-authority-2faXXXXX.s3.eu-north-1.amazonaws.com/index.html

تؤدي هذه المرحلة دور المرشح وأداة إعادة التوجيه.

index.html تتضمن تصفية حسب البلدان وعناوين IP المعروفة مسبقًا. وهذا يتيح عدم إظهار موقع التصيد الاحتيالي الحقيقي للباحثين، وأدوات الفحص الآلية، وبيئات الاختبار، وأنظمة الحماية.

بعد اجتياز المرشح، يتلقى المستخدم إعادة توجيه بسيطة بتنسيق HTML:

<meta http-equiv="refresh" content="1;url=https://www.XXXXX.help/index.html">

يتم إخفاء النطاق تحت ستار خدمة لحل اختبار CAPTCHA. وهذا تبرير ملائم: يرى المستخدم الاسم التقني وقد يعتقد أنه أمام اختبار وسيط للمتصفح أو اختبار CAPTCHA أو التحقق الأمني.

في الواقع، هذه بنية تحتية للتصيد الاحتيالي.

في هذه المرحلة بالذات، يتم إجراء «بصمة» الجهاز. يقوم الكود بجمع أحداث المستخدم:

• mousemove
• touchmove
• keyup
• Backspace
• deviceorientation

لا يقتصر تحليل البرنامج النصي على مجرد وقوع الأحداث فحسب، بل يشمل أيضًا معلماتها:

• سرعة الحركة؛
• الفواصل الزمنية بين الأحداث؛
• الإحداثيات المعيارية؛
• حدة التغير في الاتجاه؛
• سلوك لوحة المفاتيح؛
• اتجاه الجهاز؛
• ملف تعريف اللمس/الماوس.

يُستخدم هذا لتقييم ما إذا كان الزائر شخصًا حقيقيًّا أم لا.

التعتيم و«تشفير» بيانات التليمترية

يتم تشفير جزء من بيانات التليمترية عبر خوارزمية AES-CBC قبل إرسالها: crypto.subtle.encrypt({ name: 'AES-CBC', iv: ... }, key, data)

يحتوي الكود على منطق مضاد للتصحيح. يقوم البرنامج النصي بتجميع كلمة debugger من مصفوفة أرقام ويستدعيه عبر new Function(). إذا تأخر التنفيذ، ترسل الصفحة طلب إشارة إلى /misc/index.php?r=<random> مع المعلمة bcl

يبدو هذا وكأنه محاولة لتحديد ما إذا كان المستخدم قد فتح DevTools أو أن تنفيذ JavaScript قد توقف عند نقطة توقف (breakpoint)، حيث يمكن للخلفية (backend) تغيير السلوك وإخفاء المسار الحقيقي وعرض خطأ أو إعادة توجيه المستخدم إلى موقع Netflix الشرعي.

بعد اجتياز «كابتشا» بنجاح، تتم إعادة التوجيه إلى main/prepare.php

2. المرحلة الأولى: جمع اسم المستخدم وكلمة المرور

المرحلة الأولى الحقيقية للهجوم — ليست البطاقة ولا الرسالة النصية القصيرة. في البداية، يصل المستخدم إلى صفحة تحاكي صفحة تسجيل الدخول إلى Netflix.

في هذه المرحلة، يقوم المهاجمون بجمع عنوان البريد الإلكتروني وكلمة المرور.

هذا مهم: تبدأ الهجمة باختراق الحساب، ثم تنتقل بعد ذلك إلى بيانات الدفع.

بعد إرسال نموذج POST، تنقل الصفحة المستخدم إلى المرحلة التالية — «التحقق من بطاقة الدفع».

وبهذه الطريقة، حتى لو لم تكتمل خطوات الدفع اللاحقة، فإن المهاجمين يكونون قد حصلوا بالفعل على نتيجة قيّمة: الوصول إلى الحساب.

3. المرحلة الثانية: إدخال بيانات البطاقة

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

في هذه المرحلة، يحاكي السيناريو الحاجة إلى تأكيد البطاقة المرتبطة بـ Netflix. يرى المستخدم واجهة تشبه عملية الدفع الشرعية، ويقوم بإدخال بيانات الدفع.

الهدف من هذه المرحلة هو جمع:

• اسم حامل البطاقة
• رقم البطاقة
• تاريخ انتهاء الصلاحية
• رمز CVV/CVC

يتم إرسال بيانات التلقي عن بُعد طوال العملية:

4. المرحلة الثالثة: شاشة التحميل وانتظار المشغل

بعد إدخال بيانات البطاقة، ينتقل المستخدم إلى صفحة الانتظار. وهذا هو كود HTML الذي نراه في العنصر الذي تمت دراسته.

تنص الصفحة على ما يلي:

يلزم إجراء تحقق إضافي لإتمام عملية التحقق من بطاقتك

ستتلقى رسالة قصيرة على هاتفك المحمول...

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

5. التحكم في الوقت الفعلي عبر WebSocket

آلية التحكم الرئيسية هي WebSocket. يمكننا ملاحظة وجود wss:// في أسفل الطلبات. تتصل الصفحة بـ WebSocket وتنتظر أمرًا من الخلفية. تم تضمين المنطق في HTML حيث يمكن للمشغل توجيه المستخدم إلى شاشات مختلفة:

تبدأ البطاقة التي يدخلها المستخدم تلقائيًا أو في الوضع شبه التلقائي في الاستخدام للدفع في متاجر مختلفة. وعلى الأرجح، فإن هذه المتاجر تخضع لسيطرة المخترقين.

وهنا بالذات يصبح عنصر «الوقت الفعلي» خطيرًا بشكل خاص. يمكن للمشغل معرفة نوع التأكيد الذي طلبته نظام الدفع، وتكييف صفحة التصيد الاحتيالي وفقًا لللحظة المحددة للهجوم. حيث يطلب أحيانًا التأكيد داخل التطبيق، وأحيانًا الرمز الوارد عبر الرسائل القصيرة، وأحيانًا الرمز السري للبطاقة.

6. التأكيد عبر لوحة الإدارة

بعد دراسة طريقة عمل موقع التصيد، قررنا البحث عن نقاط الضعف في لوحة الإدارة هذه. وفي أثناء ذلك، تلقينا «إشارات خفية» غريبة إلى حد ما من مطور لوحة الإدارة هذه.

وبناءً على السجلات، يمكن الجزم بأن 4 مسؤولين مختلفين على الأقل دخلوا إلى لوحة الإدارة خلال 24 ساعة، بفاصل زمني يتراوح بين 4 و7 ساعات.

كما اكتشفنا منافذ إضافية مفتوحة على اللوحة هي 2082 و2095 و8880 و1010، مما سمح لنا بالكشف عن عنوان IP الحقيقي، حيث إن موقع المحتالين يقع خلف CloudFlare.

وقد تم إخطار مزودي خدمة الإنترنت.

7. مؤشرات الاختراق

النطاقات

*.solvecaptcha.help

8. الخلاصة

تُظهر هذه الحملة كيف تقوم خدمات التصيد الاحتيالي الحديثة بتحويل صفحة تسجيل الدخول العادية إلى عملية تُدار في الوقت الفعلي.

يحصل المهاجمون أولاً على اسم المستخدم وكلمة المرور، ثم بيانات الدفع، وبعد ذلك يبقون المستخدم عالقاً على شاشة التحميل. في هذه اللحظة، يقرر المشغل من لوحة التحكم الخلفية (backend/admin) الخطوة التالية التي سيتم عرضها: رمز SMS، أو رمز PIN، أو تأكيد في التطبيق، أو إعادة التوجيه النهائية إلى موقع Netflix الحقيقي.

السمة التقنية الرئيسية لهذه الحيلة هي التحكم عبر WebSocket. فهذا هو بالذات ما يجعل الهجوم تفاعليًا ويسمح للمشغلين بتكييف السيناريو وفقًا للضحية المحددة والتدفق المصرفي المحدد.

لم تعد هذه مجرد «صفحة تصيد». إنها عملية تصيد حية.