داخل برمجيات سرقة بيانات الدفع في WooCommerce: كيف انتقل المخترقون من صفحات التصيد إلى الأبواب الخلفية لصفحات الدفع

ملخص تنفيذي

لسنوات طويلة، كانت الصفحات المزيفة هي البوابة الرئيسية لسرقة بيانات البطاقات؛ مثل بوابات القروض الوهمية، ومواقع المطالبة بالمكافآت، وروابط تتبع الشحنات، وصفحات تسجيل الدخول البنكية المقلدة التي تخدع الضحايا لإدخال بياناتهم في نماذج يسيطر عليها المهاجمون. تشير عمليات الاستخبارات البشرية (HUMINT) التي أجرتها CloudSEK مع جهات فاعلة في أسواق بيع البطاقات (مثل Savastan0 وCvvhub وJerrys وZillion وProton وVClub وPepe وغيرها من المتاجر والمنتديات المغلقة) إلى تحول واضح في أساليبهم. فقد تخلى المهاجمون الأكثر خبرة تقنياً إلى حد كبير عن التصيد الاحتيالي المستقل لصالح الاختراق المباشر لمواقع التجارة الإلكترونية المشروعة  ، حيث يتم الحصول على صلاحية الوصول عبر "ويب شيل" (web-shell)، وزرع باب خلفي ضمن مسار عملية الدفع أو بالقرب منه، لجمع بيانات البطاقات من العملاء الحقيقيين بصمت أثناء عمليات الشراء الفعلية.

يحلل هذا المنشور أحد هذه الأدوات الخبيثة: وهي أداة لنسخ بيانات الدفع (سكيمر) تعمل من جهة العميل، تم استردادها من متجر WooCommerce مخترق يستخدم إضافة WooCommerce Payments (Stripe). تقوم هذه الأداة بانتحال صفة عنصر الدفع الحقيقي الخاص بـ Stripe، وتتحقق من صحة البطاقات في الوقت الفعلي حتى لا يشك الضحية في أي شيء.

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

التحليل

1. الخلفية: التحول من التصيد الاحتيالي إلى اختراق صفحات الدفع

يعتمد التصيد الاحتيالي التقليدي للبطاقات على إقناع الضحية بزيارة صفحة يسيطر عليها المهاجم وإدخال البيانات طواعية. هذا الرسائل المزعجة (Spamming) يواجه هذا النموذج عقبات: فالمجالات تُحظر بسرعة، وتكتشف قوائم التصفح الآمن في المتصفحات الروابط الاحتيالية المعروفة، كما تعتمد معدلات التحويل على مدى إقناع أسلوب الهندسة الاجتماعية المستخدم.

يؤدي اختراق عملية الدفع إلى إزالة هذه العقبات تماماً. فبدلاً من استدراج الضحايا إلى موقع مزيف، ينقل المهاجم عملية السرقة إلى بيئة يثق بها العملاء بالفعل: متجر حقيقي، وعربة تسوق حقيقية، وعملية دفع حقيقية. هذا هو نموذج Magecart ، الذي سُمي تيمناً بمجموعة المجموعات الفضفاضة التي كانت سباقة في حقن برمجيات "سكيمر" (JavaScript skimmers) في المتاجر الإلكترونية المخترقة. المزايا الرئيسية للمهاجم هي:

• وراثة الثقة: يكون الضحية في موقع اختاره بنفسه، يتمتع بشهادة TLS صالحة وعلامة تجارية مألوفة. فلا يوجد شيء "لينخدع به" المستخدم.
• بيانات حديثة وعالية القيمة: يتم التقاط بيانات البطاقات لحظة إجراء عملية شراء حقيقية، مقترنة بتفاصيل الفواتير والبريد الإلكتروني، وهي بالضبط بيانات Fullz التي تُباع بأسعار مرتفعة.
• الاستمرارية والتخفي: يمكن لبرمجية "سكيمر" مخفية جيداً أن تعمل لأشهر، ولأن عملية الدفع المشروعة تكتمل بنجاح، لا يلاحظ العميل ولا التاجر وجود أي خطأ.

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

2. نظرة سريعة على العينة (sender.js)

3. التحليل الفني (السلوكي)

يصف ما يلي ما يفعله الكود على المستوى السلوكي، وهو الفهم الذي يحتاجه المدافع لاكتشاف التهديد ومعالجته. وقد تم حذف تفاصيل التنفيذ التي قد تساعد في إعادة إنتاج الكود عمداً.

‍

برمجية سرقة بيانات الدفع في التجارة الإلكترونية - سير عمل الهجوم

3.1 التعتيم وإخفاء النصوص

يبدأ البرنامج النصي بمصفوفة كبيرة من أجزاء النصوص التي يتم تدويرها عند التحميل، بالإضافة إلى وظيفة بحث تقوم بربط الفهارس الرقمية بتلك النصوص. يتم الإشارة إلى كل معرف ذي معنى، ومعرفات العناصر، وأسماء الأحداث، ورسائل الخطأ، ومحددات الهدف من خلال هذا البحث بدلاً من ظهورها كنص عادي. هذا هو الشكل المعتاد لمخرجات أدوات تعتيم JavaScript الشائعة، وهو مصمم لإحباط عمليات المسح البسيطة القائمة على grep ومراجعات الكود العابرة.

علاوة على ذلك، تحتوي العينة على طبقة ترميز مخصصة مبنية من Base64 بالإضافة إلى وظائف إلغاء الهروب من عناوين URL ومساعد لعكس النصوص لكل حرف. يتم تضمين كتلتين كبيرتين مشفرتين في جدول النصوص؛ وتفك هذه الكتل لتكشف عن ترميز وتنسيق نموذج الدفع المزيف (انظر 3.3). يجب على المدافع أن يعتبر وجود ترميز نصوص متعدد المراحل ومصمم ذاتياً داخل برنامج نصي لصفحة الدفع علامة خطر واضحة بحد ذاتها، فمكتبات الدفع المشروعة لا تخفي عناصر DOM الخاصة بها.

3.2 استهداف المنصات

تستهدف برمجية السرقة تحديداً منصة WooCommerce Payments. فهي تبحث عن حاوية دفع Stripe في الصفحة (عقدة wcpay-payment-element / StripeElement) ولا تنشط إلا عندما تجد صفحة دفع مطابقة. هذا الاستهداف الدقيق يقلل من الضجيج ويحافظ على خمول البرمجية في الصفحات التي قد تكون فيها مرئية أو عديمة الفائدة.

3.3 حقن نموذج مزيف (تقنية "التراكب")

بدلاً من قراءة إطار Stripe الحقيقي (الذي يتبع نطاقاً مختلفاً ومحمي)، تقوم البرمجية ببناء نموذجها الخاص المشابه وتضعه فوق أو بمحاذاة منطقة الدفع الأصلية. تحتوي الكتل التي تم فك تشفيرها على HTML وCSS مضمن لهذا النموذج المزيف، بتنسيق يطابق تخطيط حقول Stripe (رقم البطاقة، تاريخ الانتهاء، رمز التحقق CVC)، وصولاً إلى سلوك العناصر النائبة وتنسيق التركيز.

يمكن التعرف على الحقول التي يتحكم فيها المهاجم من خلال اصطلاح تسمية ثابت، حيث تنتهي معرفات المدخلات بلاحقة _sb (على سبيل المثال، حقول رقم البطاقة، وتاريخ الانتهاء، ورمز الأمان). ونظراً لأن هذه عناصر DOM من الطرف الأول يتم حقنها في الصفحة، فإن البيانات المكتوبة فيها تكون مقروءة بالكامل بواسطة برنامج المهاجم، على عكس إطار Stripe الحقيقي المعزول.

3.4 التحقق في الوقت الفعلي لتجنب الشك

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

• الكشف عن العلامة التجارية للبطاقة / رقم تعريف البنك (BIN). تقوم بفحص الأرقام الأولى لتصنيف البطاقة (مثل نطاقات 4، 5، 34/37، 6011/65، وسلسلة 2) وتعديل الطول المتوقع ورقم التحقق وفقاً لذلك، بحيث تظهر بطاقة Amex رمز أمان من 4 أرقام ورقم بطاقة من 15 رقماً، وهكذا.
• خوارزمية التحقق Luhn. تقوم بتشغيل خوارزمية Luhn القياسية (mod-10) بحيث يؤدي أي رقم غير صالح بوضوح إلى إظهار نفس رسالة "رقم البطاقة غير صالح" التي سيظهرها النموذج الحقيقي.
• التحقق من تاريخ الانتهاء. يتحقق البرنامج من نطاق الشهر ويقارن تاريخ الانتهاء بالشهر والسنة الحاليين، ويرفض التواريخ المنتهية أو غير المنطقية.

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

3.5 التخفي وإخفاء الأثر

يعمل برنامج الاختراق بنشاط ليبدو كجزء من البنية التحتية السليمة للموقع:

• يقوم بتخزين الحالة في localStorage تحت مفاتيح مصممة لتشبه ملفات التسويق أو التحليلات (على سبيل المثال، بادئة بأسلوب fbpixel_)، بحيث لا تثير الريبة عند إلقاء نظرة سريعة على وحدة تخزين المتصفح.
• يقوم بتعيين علامة إلغاء الاشتراك في Google Analytics (ga-disable-G-3SDSS99J4N)، مما يؤدي إلى إيقاف جمع بيانات GA على الصفحة، وهو ما يقلل على الأرجح من احتمالية رصد التاجر لأي سلوك غير طبيعي حول العنصر المحقون في تحليلاته الخاصة.
• يستخدم علامة مخزنة لـ منع تكرار بيانات الضحايا، لتجنب إعادة إرسال نفس بيانات البطاقة، مما يضمن بقاء حركة البيانات الصادرة في حدها الأدنى ودون نمط محدد.

‍

3.6 جمع البيانات وتسريبها

بمجرد اجتياز البطاقة لعملية التحقق الخاصة ببرنامج الاختراق، يقوم النص البرمجي أيضاً بسحب البريد الإلكتروني للعميل من صفحة الدفع ويجمعه مع رقم البطاقة (PAN) وتاريخ الانتهاء ورمز التحقق (CVV) التي تم التقاطها. يتم تمرير السجل المجمع عبر طبقة تشفير مخصصة (Base64 + escape + reversal) وإرساله إلى نقطة تجميع يتحكم فيها المهاجم. يساعد تشفير البيانات في جعل حركة مرور البيانات المسربة تبدو كأنها سلاسل استعلام عادية أو طلبات إشارة (beacon)، مما يساعد في تجاوز قواعد منع تسريب البيانات (DLP) التي تعتمد على مطابقة النصوص البسيطة.

‍

4. إعادة بناء سلسلة الهجوم

بناءً على العينة والمعلومات الاستخباراتية البشرية (HUMINT) المؤكدة، تتبع العملية من البداية إلى النهاية هذا التسلسل عادةً:

1. الوصول الأولي: يحصل المهاجم على موطئ قدم في المتجر، وغالباً ما يتم ذلك عبر إضافة أو قالب قديم أو به ثغرات، أو بيانات اعتماد إدارية مكشوفة، أو ثغرة معروفة في نظام إدارة المحتوى، ثم يقوم بزرع غلاف ويب (web shell).
2. الاستمرارية / الباب الخلفي: باستخدام غلاف الويب، يقوم المهاجم بزرع باب خلفي ووضع كود برمجي ليتم تنفيذه في صفحة الدفع (يتم حقنه في ملف القالب، أو إضافة، أو قاعدة البيانات، أو تحميله من خادم يتحكم فيه المهاجم).
3. تسليم أداة سرقة البيانات (Skimmer): يتم تقديم أداة سرقة البيانات "sender.js" التي تم تحليلها هنا لزوار صفحة الدفع. تظل الأداة خاملة حتى تكتشف عنصر الدفع الخاص بـ WooCommerce/Stripe.
4. جمع البيانات: يكمل العملاء الحقيقيون عمليات شراء فعلية. تلتقط أداة السرقة بيانات البطاقة والبريد الإلكتروني بالتوازي مع المعاملة المشروعة؛ وتتم عملية الطلب بنجاح.
5. تسريب البيانات: يتم إرسال السجلات المشفرة إلى نقطة تجميع البيانات، مع إزالة التكرارات لكل ضحية.
6. تحقيق الربح: تُباع البطاقات الجديدة والموثقة مع تفاصيل الفوترة في أسواق ومنتديات بيع البطاقات المسروقة.

نظراً لأن الخطوة الرابعة لا تعطل تجربة العميل أبداً، فإن فترة بقاء المهاجم غالباً ما تُقاس بالأشهر.

5. مؤشرات الاختراق (IOCs)

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

عناصر DOM مشبوهة محقونة في صفحة الدفع

• مدخلات البطاقة/تاريخ الانتهاء/رمز الأمان التي تحتوي على لاحقة _sb في معرفاتها والتي ليست جزء من ترميز WooCommerce/Stripe الأصلي.
• نموذج دفع مكرر أو متراكب يظهر بجانب عنصر wcpay-payment-element / StripeElement الحقيقي.

‍

بقايا بيانات متصفح التخزين

• مفاتيح localStorage التي تحاكي تسميات البكسل/التحليلات (مثل بادئة بنمط fbpixel_) والتي لا تقوم أدوات الموقع الحقيقية بتعيينها.
• مفتاح تمييز لإلغاء تكرار الضحايا لا يخدم أي غرض مشروع.

التلاعب بالتحليلات

• وجود علامة ga-disable-G-XXXXXXXXXX غير مبررة تم تعيينها في صفحة الدفع (القيمة المرصودة تشير إلى معرف قياس بصيغة G-3SDSS99J4N). يجب على التاجر التأكد مما إذا كانت خاصية GA هذه تابعة له من الأساس.

خصائص البرنامج النصي

• برنامج JavaScript معقد للغاية ومُشفر يتم تحميله في سياق صفحة الدفع، ويحتوي على مصفوفة سلاسل نصية مدورة، ومفكك ترميز مخصص يعتمد على Base64+escape+reverse، وكتل بيانات مشفرة مضمنة يتم فك تشفيرها لتكوين HTML/CSS.
• إعادة تنفيذ جانب العميل للتحقق من صحة خوارزمية Luhn واكتشاف رقم تعريف البنك (BIN)/العلامة التجارية داخل برنامج نصي ليس من مكتبة Stripe/WooCommerce الرسمية.

الشبكة

• طلبات صادرة من صفحة الدفع إلى نطاق لا علاقة له بـ Stripe أو معالج الدفع أو تحليلات التاجر الخاصة، خاصة تلك التي تحمل سلاسل استعلام مشفرة طويلة أو حمولات إشارات (beacons).

6. إرشادات الكشف

للتجار ومشغلي المنصات

• مراقبة سلامة جانب العميل / الصفحة: نشر أدوات (أو سياسة أمان المحتوى مع إعداد التقارير) تنبه عند وجود أي برنامج نصي جديد أو معدل في صفحة الدفع. تعتمد برمجيات سرقة البيانات من نوع Magecart في بقائها على عدم ملاحظتها في الواجهة الأمامية.
• سياسة أمان المحتوى (CSP): تقييد script-src و connect-src بالمصادر الموثوقة حتى لا تتمكن البرامج النصية المحقونة من تسريب البيانات بحرية إلى نطاقات عشوائية؛ استخدم report-uri/report-to للكشف عن الانتهاكات.
• سلامة الموارد الفرعية (SRI): ثبّت قيم التجزئة (hashes) للسكربتات الخارجية لضمان فشل تحميل أي ملفات تم التلاعب بها أو استبدالها.
• مراقبة سلامة الملفات (FIM): راقب ملفات القالب، ومجلدات الإضافات، وملفات النظام الأساسية بحثاً عن أي تعديلات غير متوقعة، حيث تُعد هذه المواقع أماكن رئيسية لاستمرار عمل الأبواب الخلفية التي تخدم برمجيات سرقة البيانات.
• مراجعة قاعدة البيانات: افحص جدول wp_options، وإضافات حقن الأكواد في الترويسة أو التذييل، ومحتوى المنشورات بحثاً عن كتل <script> محقونة أو بيانات مشفرة بصيغة base64.
• فحص شذوذ التحليلات: تحقق من أي علامات ga-disable-* مضبوطة من جهة العميل، وقارن معرفات خاصية Google Analytics بمعرفاتك الخاصة.
• اختبارات الدفع الاصطناعية: قم بإجراء عملية دفع آلية بشكل دوري في متصفح مراقب، وقارن هيكل الصفحة (DOM) وطلبات الشبكة مع نموذج أساسي سليم ومعروف.

للمستهلكين

• كن حذراً إذا طلبت منك صفحة الدفع إعادة إدخال تفاصيل بطاقتك بالكامل في نموذج ثانٍ غير معتاد، أو إذا كانت حقول الدفع تعمل بشكل مختلف عن النموذج المستضاف المعتاد الخاص بمعالج الدفع.
• فضل استخدام طرق الدفع عبر المحافظ الرقمية أو الرموز المميزة (مثل Apple Pay وGoogle Pay وPayPal) حيث لا يتم إدخال بيانات البطاقة في الصفحة مطلقاً.
• استخدم أرقام بطاقات افتراضية أو مخصصة للاستخدام مرة واحدة عند التسوق عبر الإنترنت إذا كان بنكك يدعم ذلك، وقم بتفعيل تنبيهات المعاملات.

مقتطفات الكشف والبحث

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

من جهة المتصفح: افحص صفحة دفع مباشرة بحثاً عن التراكب الخبيث

قم بتشغيل هذا الكود في أدوات المطور (DevTools) على صفحة دفع مشبوهة (أو أدرجه ضمن خطوة مراقبة اصطناعية):

‍

على القرص: ابحث عن توقيع التعتيم في ملفات القالب/الإضافة/النواة

قاعدة البيانات: ابحث عن أدوات التحميل المحقونة في WordPress/WooCommerce

YARA: حدد أداة سرقة البيانات (skimmer) في الملفات/الذاكرة

rule ecommerce_skimmer_wcpay_sb_overlay

{

    meta:

        description = "استدلالي لأداة سرقة البيانات (skimmer) عبر تراكب WooCommerce/Stripe (مكون الإرسال)"

        author = "CloudSEK TI"

    strings:

        $field1 = "numberInput_sb" ascii

        $field2 = "expiryInput_sb" ascii

        $field3 = "codeInput_sb"   ascii

        $target = "wcpay-payment-element" ascii

        $ga     = /ga-disable-G-[A-Z0-9]{6,}/ ascii

        $rotator = /\(function\([a-z],[a-z]\)\{[^}]{0,40}while\(--[a-z]\)/ ascii

        $b64helpers = /\['(atob|btoa)'\]/ ascii

    condition:

        // استهداف + حقل خبيث واحد على الأقل + سمة تعتيم/تخفي

        $target and any of ($field*) and 2 of ($ga, $rotator, $b64helpers)

}

‍

7. ما بعد Stripe: كيف تتكيف نفس أساليب الاختراق مع بوابات الدفع الأخرى

تستهدف العينة التي تم تحليلها أعلاه WooCommerce Payments (Stripe)، ولكن من الخطأ اعتبار هذه المشكلة خاصة بـ Stripe فقط. إنها فئة من التهديدات. ومن الأهمية بمكان ملاحظة أن المرحلتين الأوليين من سلسلة الهجوم - الوصول الأولي وصدفة الويب/الباب الخلفي لتحقيق الاستمرارية - هما مستقلتان تماماً عن بوابة الدفع. بمجرد أن يسيطر المهاجم على تنفيذ الكود في صفحة الدفع (أو على جانب الخادم المسؤول عن عرضها)، فإن الشيء الوحيد الذي يتغير من معالج دفع إلى آخر هو كيفية التقاط بيانات البطاقة في المرحلة الرابعة. وهذا بدوره يعتمد على نموذج التكامل المشروع الخاص ببوابة الدفع. إن فهم هذا النموذج يخبر المدافعين بالضبط أين يجب عليهم المراقبة.

7.1 نموذجان للتكامل، واستراتيجيتان للالتقاط

تندرج معظم بوابات الدفع الحديثة ضمن أحد نمطين، وتتكيف برمجيات الاختراق (skimmers) وفقاً لذلك:

• الحقول المستضافة / المعزولة (iframe-isolated): Stripe Elements، وBraintree Hosted Fields، وAdyen Web Components/Drop-in، وSquare Web Payments SDK، وAuthorize.Net Accept.js. تعيش بيانات البطاقة داخل إطار (iframe) يتحكم فيه المعالج، ولا يمكن لصفحة التاجر قراءتها بشكل مشروع. ولأن البيانات خارج نطاق الوصول، تستجيب برمجيات الاختراق من خلال وضع نموذج مزيف مطابق بصرياً فوق النموذج الأصلي (وهو بالضبط ما تفعله عينتنا) أو من خلال اعتراض استدعاء التشفير (tokenisation callback) الذي يُرجع رمزاً مميزاً/nonce.
• تدفقات إعادة التوجيه / الصفحة المستضافة أو النشر المباشر: بعض تدفقات PayPal، وطرق النشر المباشر القديمة بأسلوب Authorize.Net، والعديد من بوابات الدفع الإقليمية التي تعيد التوجيه إلى صفحة دفع مستضافة. في هذه الحالات، قد تكون واجهة إدخال البطاقة داخل الصفحة محدودة، لذا يفضل المهاجمون الاعتراض من جانب الخادم قبل إعادة التوجيه أو إدراج خطوة التقاط إضافية قبل عملية التسليم.

وبالتالي، فإن المؤشر الأكثر موثوقية والمستقل عن البوابة للمدافعين هو: وجود حقل <input> من الطرف الأول يجمع رقم البطاقة الكامل/رمز التحقق (PAN/CVV) في مكان يفترض أن يكون فيه إطار iframe معزول، مقترناً بـ اتصال صادر إلى نطاق ليس هو نطاق معالج الدفع.

‍

7.2 مؤشرات دفاعية لكل بوابة دفع

الملاحظات أدناه موجهة نحو الكشف — أي كيف يبدو التدفق الشرعي، وما الذي يجب مراقبته. وهي ليست إرشادات تنفيذية عن قصد.

‍