ثغرة واحدة، وآلاف المتاجر

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

هذا بالضبط ما ظهر في حملة استغلال واسعة استهدفت متاجر تعمل على Magento وAdobe Commerce. فخلال أسابيع قليلة، تمكن مهاجم يطلق على نفسه اسم Lockster من اختراق أكثر من 3,800 متجر إلكتروني، والوصول إلى أنظمة الخوادم، وزرع أدوات لسرقة بيانات البطاقات، وسحب مفاتيح خاصة ببوابات الدفع، وإنشاء وسائل متعددة للبقاء داخل البيئات المخترقة.

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

وهنا تظهر المسألة الحقيقية: إدارة الثغرات ليست مجرد عملية Patch Management، بل جزء مباشر من الحوكمة وإدارة المخاطر والاستجابة للحوادث.

#حملة واسعة بدأت من نقطة ضعف واحدة

بحسب البيانات التي كُشفت من البنية التحتية التابعة للمهاجم، احتوى أحد خوادم Lockster المكشوفة على بيانات مرتبطة بما لا يقل عن 3,834 موقعاً معروفاً، معظمها متاجر إلكترونية.

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

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

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

#ما هي StyleSmuggler؟

الثغرة التي استُغلت في الحملة عُرفت باسم:

StyleSmuggler

وهي ثغرة حرجة استهدفت بيئات:

Magento
Adobe Commerce

وبحسب البيانات التي ظهرت في البنية التحتية للمهاجم، كانت قائمة الأهداف تضم متاجر تستخدم إصدارات ضمن النطاق:

Magento 2.4.2 to 2.4.9

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

/customer/address_file/upload

الفكرة التقنية في الاستغلال تمثلت في رفع ملف صورة مركب من نوع:

Polyglot GIF

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

PHP

قابلة للتنفيذ على الخادم.

كما استُخدم حقل محدد داخل الطلب لإخفاء المحتوى الخبيث:

custom_attributes[country_id]

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

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

#من اختراق التطبيق إلى السيطرة على الخادم

الوصول الأولي لم يكن نهاية الهجوم.

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

CVE-2026-31431
CVE-2021-4034 - PwnKit
CVE-2026-23111

وهنا يتغير مستوى الحادثة بالكامل.

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

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

#سرقة بيانات البطاقات مباشرة من صفحة الدفع

بعد اختراق المتاجر، زرع Lockster برمجية من نوع:

Credit Card Skimmer

وهي شيفرة خبيثة صممت لمراقبة نماذج الدفع واعتراض البيانات التي يدخلها المستخدم أثناء تنفيذ عملية شراء.

البيانات التي استهدفتها البرمجية شملت:

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

الأكثر تعقيداً أن البرمجية كانت:

Polymorphic

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

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

#عندما تصبح مفاتيح بوابة الدفع جزءاً من الغنيمة

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

تشير البيانات إلى أنه استطاع أيضاً فك تشفير وسرقة مفاتيح خاصة مرتبطة ببوابات دفع مثل:

Braintree
Authorize.net

هذه المفاتيح تمثل مشكلة أخطر من مجرد كلمة مرور عادية، لأنها جزء من الثقة التقنية بين المتجر ومزود خدمة الدفع.

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

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

#البقاء داخل البيئة: ثلاث طبقات من الاستمرارية

من أكثر الجوانب اللافتة في الحملة أن المهاجم لم يعتمد على باب خلفي واحد.

بحسب الآثار التي عُثر عليها، استخدم Lockster ثلاثة أساليب رئيسية للمحافظة على الوصول إلى المتاجر المخترقة.

#1. زرعة خفية داخل نظام التشغيل

أنشأ المهاجم عملية خفية مكتوبة بلغة:

Rust

واستخدم أسماء تشبه عمليات النظام الطبيعية مثل:

kworker
fc-cache

الهدف من اختيار هذه الأسماء هو الاندماج داخل بيئة الخادم وتقليل فرصة ملاحظة العملية أثناء الفحص السريع.

كانت هذه الزرعة تتصل ببنية القيادة والسيطرة عبر قنوات مشفرة تستخدم:

NTP
WebSocket

كمكونات في آلية الاتصال.

#2. وصول خلفي عبر SSH

أنشأ المهاجم حسابات متعددة على النظام، واستخدم مفاتيح:

ed25519

للوصول إليها.

ومن أسماء الحسابات التي ظهرت في البنية المخترقة:

cfgmgr
monclean
pkgsync
opsmaint
apppush
bakctl
pkgpulse
cachehook
dbaide
pkgprobe
jobaide
tracguard

وجود حسابات بهذه الأسماء قد يجعل بعضها يبدو لأول وهلة كحسابات تشغيلية أو حسابات خدمة طبيعية.

#3. حسابات إدارية داخل Magento

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

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

#المهاجم لم يحمِ وصوله فقط... بل حاول منع مهاجمين آخرين

من المثير في هذه الحملة أن Lockster بدا مدركاً أن جهات هجومية أخرى كانت تستغل الثغرة نفسها.

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

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

ومن ناحية الدفاع، فإن هذا يغيّر مفهوم الاستجابة من:

"تم تركيب التحديث وانتهت المشكلة."

إلى:

"هل توجد دلائل تثبت أن النظام لم يُخترق قبل تركيب التحديث؟"

وهذا فرق جوهري.

#لماذا لا يكفي تثبيت التحديث؟

أصدرت Adobe إصلاحاً طارئاً مرتبطاً بالمعرّف:

VULN-39341
APSB26-146

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

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

لذلك يجب التعامل مع الأنظمة المعرضة أو المتأثرة وفق فرضية:

Assume Compromise

أي افتراض أن الاختراق قد حدث حتى تثبت التحقيقات عكس ذلك.

#ما الذي يجب البحث عنه داخل الأنظمة المتأثرة؟

تضمنت المؤشرات المنشورة عدداً من الملفات والاتصالات والعناصر التي تستحق المراجعة في بيئات Magento وAdobe Commerce.

من الملفات والأنماط المهمة:

kworker
fc-cache
sk.js

وقد يظهر ملف:

sk.js

داخل مسارات مثل:

/magento_root/pub/media/<...>
/magento_root/media/<...>

كما أوصى الباحثون بمراجعة ملفي الدفع:

PaymentInformationManagement.php
GuestPaymentInformationManagement.php

والبحث عن سلاسل مشبوهة مثل:

fsnif2
fsnif1fsnif2c
$fsn_a['x_host']

وظهرت كذلك مجموعة من النطاقات المرتبطة بالبنية الهجومية:

js-static[.]io
checkout-cdn[.]com
ntpsync[.]io
ntp[.]reposync[.]to
ntp[.]synctime[.]to
ntp[.]syncstime[.]to

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

#أثر الحادثة من منظور GRC

الهجوم تقني في بدايته، لكن نتائجه تتجاوز فريق الأمن السيبراني بسرعة.

القيمة الأساسية في هذا الربط أن المؤسسة لا تتعامل مع CVE أو إصلاح أمني بوصفه مهمة تقنية منعزلة.

الثغرة الحرجة في نظام تجارة إلكترونية قد تتحول إلى:

Cybersecurity Risk
Operational Risk
Financial Risk
Third-Party Risk
Compliance Risk
Reputational Risk

خلال فترة زمنية قصيرة جداً.

#الحوكمة تبدأ قبل ظهور الثغرة

المؤسسات التي تعتمد على منصات تجارة إلكترونية تحتاج إلى معرفة إجابات واضحة قبل حدوث أي استغلال واسع:

• ما الأنظمة المكشوفة مباشرة للإنترنت؟
• ما الإصدارات المستخدمة فعلياً؟
• من المسؤول عن تحديث كل منصة؟
• ما هي الخدمات الخارجية المتصلة بالمتجر؟
• أين يتم تخزين مفاتيح الدفع والأسرار؟
• من يستطيع إنشاء حساب إداري؟
• ما السجلات التي تُحتفظ بها؟
• هل يمكن عزل النظام بسرعة عند الاشتباه؟
• هل توجد نسخة موثقة من الحسابات والعمليات الطبيعية يمكن مقارنة النظام بها أثناء التحقيق؟

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

#من Patch Management إلى Exposure Management

إحدى أهم الدروس في هذه الحادثة أن إدارة الثغرات لا ينبغي أن تبدأ عند نشر التحديث وتنتهي عند تثبيته.

المنهج الأكثر نضجاً ينظر إلى دورة الخطر كاملة:

Discover
Assess Exposure
Prioritize
Patch
Hunt
Contain
Rotate Secrets
Validate
Monitor

في حالة حملة StyleSmuggler، فإن الخادم الذي كان معرضاً للثغرة خلال فترة الاستغلال قد يحتاج إلى عملية فحص وتحقيق حتى لو تم تثبيت الإصلاح لاحقاً.

الأولوية لا تكون فقط للسؤال:

Is the vulnerability patched?

بل أيضاً:

Was the system exploited before the patch?

هذا التحول في السؤال هو ما يفصل بين إدارة تحديثات تقليدية وبين إدارة تعرض حقيقية مبنية على المخاطر.

#مؤشرات الاختراق ليست بديلاً عن التحقيق

قائمة النطاقات والملفات والحسابات التي ظهرت في الحملة مفيدة، لكنها لا تكفي وحدها لإثبات سلامة البيئة.

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

DNS Poisoning
Password Hash Cracking
CCTV Camera Probing
Password Spraying

وهذا يعني أن غياب مؤشر واحد معروف لا يساوي غياب الاختراق.

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

#الخطر لا يتوقف عند المتجر

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

يمكن تصور سلسلة التأثير كالتالي:

Internet-Facing Magento
        ↓
Remote Code Execution
        ↓
Privilege Escalation
        ↓
Server Compromise
        ↓
Payment Data Theft
        ↓
Secret Key Theft
        ↓
Persistence
        ↓
Potential Impact on Connected Services

وهنا يظهر سبب أهمية فهم الاعتماد المتبادل بين الأنظمة.

فالمتجر قد يكون مجرد واجهة، لكن المفاتيح المخزنة عليه قد تمنحه القدرة على التعامل مع خدمات دفع، أو قواعد بيانات، أو أنظمة داخلية، أو مزودين خارجيين.

لذلك يجب أن يعكس تقييم المخاطر قيمة الاتصالات والاعتماديات، وليس قيمة الخادم منفرداً.

#ماذا تعلمنا من Lockster؟

المهاجم في هذه الحملة لم يعتمد على أسلوب واحد.

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

وفي مفارقة واضحة، انكشفت أجزاء من بنيته التحتية نفسها، وهو ما كشف حجم الحملة وأدواتها وبعض بيانات ضحاياها.

كما احتوت البنية المكشوفة على رسالة فدية موجهة إلى إحدى الجهات، تطالب بمبلغ:

150,000 USD

هذه الحادثة تقدم مثالاً واضحاً على أن الهجمات الحديثة لا تنتهي عند الاستغلال الأولي. القيمة الحقيقية للمهاجم تأتي من مرحلة ما بعد الاستغلال: تثبيت الوصول، جمع البيانات، سرقة الأسرار، وتوسيع نطاق السيطرة.

#الخلاصة

أكثر من 3,800 متجر، بيانات دفع، مفاتيح خاصة، أبواب خلفية، حسابات إدارية، وقنوات اتصال خفية؛ كل ذلك بدأ من ثغرة واحدة في منصة تجارة إلكترونية واسعة الانتشار.

الدرس الأهم ليس أن Magento أو Adobe Commerce تعرضتا لثغرة حرجة، بل أن المؤسسات تحتاج إلى النظر إلى الثغرات ضمن سياق أكبر.

التحديث الأمني يعالج سبباً تقنياً، لكنه لا يثبت أن البيئة سليمة.

وحين تكون الثغرة مستغلة فعلياً على الإنترنت، فإن السؤال الصحيح لا يكون فقط:

هل تم تثبيت التحديث؟

بل:

هل نملك أدلة كافية على أن المهاجم لم يصل إلى النظام قبل تثبيت التحديث؟

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

#مراجع تقنية

Adobe Commerce Emergency Hotfix:
https://experienceleague.adobe.com/en/docs/commerce-knowledge-base/kb/announcements/commerce-apsb26-146

Sansec - StyleSmuggler 0-day Research:
https://sansec.io/research/stylesmuggler-0day