هندسة التلاعب بقواعد البيانات لإخفاء تواريخ الاختراق عن (ساما)
الكشف التقني: هندسة التلاعب بقواعد البيانات لإخفاء تواريخ الاختراق عن (ساما)
في عالم إدارة قواعد البيانات المركزية (RDBMS)، الأرقام لا تكذب، والسجلات المالية لا تتبخر من تلقاء نفسها. أي اختفاء لبيانات محددة في تسلسل زمني مالي هو إما نتيجة لانهيار كارثي في الخوادم، أو—وهو الأرجح هنا—نتيجة لتدخل بشري مباشر عبر استعلامات برمجية (Queries) مصممة خصيصاً لاستبعاد تواريخ تدين النظام.
بعد أن أثبتنا في التحقيق الأول اختراق "سلسلة العهدة" وتسريب بيانات البطاقات في تاريخين محددين (14 مايو 2025 للبطاقة 1174، و 22 مايو 2025 للبطاقة 1233)، نضع اليوم تحت المجهر الرد الرسمي الذي رفعه البنك إلى البنك المركزي السعودي (ساما). وهو الرد الذي يمثل فضيحة تقنية وتلاعباً صريحاً بالكشوفات.
1. الفجوة الزمنية: الحذف الجراحي لتواريخ الجريمة
عند مراجعة الكشف المالي الرسمي المرفوع لجهة الرقابة (ساما)، والذي يفترض أن يعكس السجل المطلق والحقيقي (Absolute Truth) للعمليات، نكتشف تدخلاً "جراحياً" لاستئصال التواريخ التي حدثت فيها الاختراقات ومحاولات الشراء من أمازون.
تأمل الكشف جيداً؛ البيانات تقفز بشكل غير منطقي. سجلات البطاقة القديمة (1174) تتوقف، وسجلات البطاقة البديلة (1233) تبدأ، ولكن أين تاريخ 14 مايو 2025؟ وأين تاريخ 22 مايو 2025؟ لقد تم محوهما بالكامل من الكشف المرسل لساما لإخفاء أثر محاولات الخصم الدولية التي تثبت تسريب البيانات من داخل المنظومة.
2. التناقض المالي الفاضح: رسوم على بطاقة مسروقة!
التلاعب لم يتوقف عند إخفاء التواريخ، بل امتد لارتكاب حماقة محاسبية تثبت التخبط. في نفس الكشف المرفق أعلاه، نجد في تاريخ 21 مايو 2025 عملية مقيدة تحت وصف (LOST STOLEN REPLACEMENT FEE) بقيمة 50 ريال للبطاقة البديلة (1233)!
كيف يتم قيد رسوم "إصدار بدل فاقد/مسروق" لبطاقة بديلة في يوم 21 مايو، بينما البطاقة نفسها تم شحنها وتسريبها ومحاولة استخدامها في اليوم التالي 22 مايو؟! البنك يفرض رسوماً على بطاقة مخترقة قبل أن تصل للعميل، وفي ذات الوقت يحذف سجلات يوم الاختراق الفعلي من التقرير الرقابي!
3. تشريح التلاعب البرمجي: كيف أخفوا البيانات؟ (كود NOT IN)
كمتخصصين في النظم، نعلم تماماً أن هذه التواريخ لم تسقط سهواً. لتوليد كشف حساب يستبعد تواريخ محددة بدقة، قام مشغل قاعدة البيانات في البنك باستخدام استعلام استبعاد شرطي. الكود البرمجي الذي تم تمريره على قاعدة بيانات العميل لاستخراج هذا الكشف المزيف يبدو بهذا الشكل التقني:
-- استعلام استخراج كشف حساب العميل لتقديمه للبنك المركزي
SELECT
Posting_Date, Billing_amount, Item_type, Display_PAN, Description
FROM
Bank_Core_System.dbo.Customer_Statements
WHERE
Account_ID = 'TARGET_ACCOUNT'
-- هنا تكمن الجريمة الرقمية: استبعاد تواريخ الاختراق عمداً
AND Posting_Date NOT IN ('2025-05-14', '2025-05-22')
ORDER BY
Posting_Date ASC;
استخدام المعامل البرمجي NOT IN هو الأداة الكلاسيكية لتنقيح البيانات وإخفاء العيوب التشغيلية قبل تصدير التقارير للجهات الرقابية. هذا ليس خطأً في النظام، هذا طمس متعمد للأدلة الرقمية (Data Tampering).
4. إثبات انتقائية الإخفاء (السوابق المسجلة)
لإثبات أن نظام البنك قادر تماماً على تسجيل عمليات (AMAZON) وأنه لم يتجاهلها لعطل فني، نستعرض كشفاً قديماً للبطاقة (1174) يثبت تسجيل العمليات الطبيعية بكفاءة.
الصورة توضح تسجيل عملية شرائية من (Amazon SA) بتاريخ 6 يوليو 2022 بشكل طبيعي. مما يؤكد أن غياب عمليات أمازون في تواريخ 14 و 22 مايو 2025 لم يكن خللاً في نظام الربط (Payment Gateway)، بل كان استبعاداً يدوياً موجهاً.
تحدي مفتوح لإدارة الأمن السيبراني وتقنية المعلومات
أضع هذا التحليل والأدلة الرقمية أمام قسم الأمن السيبراني وإدارة تقنية المعلومات في البنك، وأتحداهم فنياً وتقنياً أن يقدموا تفسيراً برمجياً أو هندسياً واحداً يبرر "اختفاء" تواريخ 14 و 22 مايو 2025 من السجلات المرفوعة للبنك المركزي، بالتزامن الدقيق مع اختراق بطاقات العميل.