ادعاء انكشاف بيانات GhostMarket.net في 2009

يُخزَّن التاريخ بدقة تقتصر على السنة. فقيمة قاعدة البيانات 1 يناير 2009 ليست سوى تمثيل تقني لعام 2009؛ ولا تعني أن الحدث وقع في 1 يناير. تصف البيانات الوصفية الداخلية 2009 بأنه «تاريخ الخرق»، بينما يحمل رأس تصدير SQL وقت إنشاء يعود إلى يوليو 2009. قد يشير وقت إنشاء تفريغ قاعدة البيانات إلى وقت إنتاج التصدير، لكنه لا يثبت تاريخ الانكشاف بصورة مستقلة. وتؤيد الإشارات إلى 2009 في البيانات الوصفية العامة فترة عمل الكيان، لكنها لا تحدد يومًا بعينه لانكشاف البيانات الخاصة. لهذه الأسباب، تكون قيمة breachDatePrecision هي year، ويظل اليوم المحدد مجهولًا، ويُقرن تمثيل التاريخ بصيغة 1 يناير صراحةً بهذا التحفظ. وقد يبرر ظهور مصدر أولي لاحقًا إجراء مراجعة منفصلة للتاريخ.

المصدر أرشيف 7z كامل بحجم 3,728,860 بايت. هوية SHA-256 الخاصة به مختومة، وقد اجتاز اختبارًا كاملًا لسلامة أرشيف 7z. استُخرجت جميع الملفات العادية الأربعة التي يضمها، ووُثِّق ارتباط كل منها بالمصدر على نحو مستقل باستخدام الحجم وSHA-256. وهي ملف بيانات وصفية عام باسم Breached_Info، وملف بيانات وصفية باسم Info يتضمن سياق GhostMarket وعينات، وتمثيل بصيغة CSV لجدول مستخدمي phpBB، وتفريغ MySQL يتضمن ثمانية جداول phpBB. لم يُعثر على أرشيف متداخل، ولم تُعدَّل حمولة المصدر. قُيِّمت الملفات التوضيحية باستخدام عدّادات خالية من معلومات التعريف الشخصية (PII) وتسميات بنيوية، بدلًا من التعامل معها على أنها بيانات حسابات مجمّعة. ويمنع هذا التمييز عرض قابلية قراءة أحد ملفات الأرشيف، على نحو مضلل، بوصفها سندًا لاستيراد كل رمز نصي يُعثر عليه فيه.

يعتمد تعيين حقول البريد الإلكتروني على المرجعية الصريحة للمخطط فقط. يحدد DDL في MySQL مباشرةً phpbb_users.user_email وphpbb_banlist.ban_email بوصفهما حقلين للبريد الإلكتروني. أما الأعمدة الأخرى التي تحتوي أسماؤها على «email»، ومنها user_email_hash وuser_emailtime وuser_allow_viewemail وuser_allow_massemail، فتمثل تجزئة أو طابعًا زمنيًا أو مؤشرات للتفضيلات، ولا تُستورد بوصفها عناوين. وهناك اثنتان وتسعون قيمة حقل كاملة في مواضع أخرى، ضمن أسماء المستخدمين وعناوين الرسائل والمنشورات ومعرّفات المراسلة الفورية وقيم الإعدادات، تصادف أنها تشبه عناوين بريد إلكتروني بصيغتها المعيارية، لكن تلك الحقول لا تحمل دلالة البريد الإلكتروني للحسابات، ولذلك تُستبعد. لم تُستخدم مواءمة الأعداد مع أعداد الكتالوج، أو ضبطها للوصول إلى عدد مستهدف، أو جمع الرموز النصية الخام بلا قيود لاختيار تعيين الحقول. لم تُقبل سوى حقول البريد الإلكتروني المعلنة في DDL.

حلّل برنامجا قراءة مستقلان، مُترجمان برمجيًا، جميع صفوف SQL البالغ عددها 34,014، والموزعة على 505 عبارات INSERT، دون أخطاء بنيوية. أنتج كلاهما التسلسل نفسه من 3,281 حالة ورود صالحة لعناوين البريد الإلكتروني، والبايتات نفسها البالغ عددها 71,823، وهوية SHA-256 نفسها. وكان عدد حالات عدم تطابق عرض الصفوف، والعبارات غير المنتهية، وإخفاقات الماسح، وأخطاء المحلل صفرًا في جميع الفئات. وبعد إزالة حالات الورود المكررة وتطبيق تحقق صارم من صحة عناوين البريد الإلكتروني وفق ASCII، بقي 3,271 عنوانًا معياريًا فريدًا ومرتبًا. وأنتج عمود user_email الصريح في ملف CSV لمستخدمي phpBB، بصورة مستقلة، 3,280 حالة ورود والمجموعة المعيارية نفسها تمامًا، المكوّنة من 3,271 عنوانًا. ويتطابق الملفان المعياريان الناتجان عن CSV وSQL بايتًا ببايت. لا يُستورد ملف CSV مرة أخرى؛ بل يُحتفظ به دليلًا على تكافؤ التمثيلين، حتى لا يُكتب حساب مرتين لمجرد ظهور الجدول نفسه بصيغتين في المصدر.

يتضمن ملف البيانات الوصفية Info رمزين نصيين خامّين يشبهان عناوين البريد الإلكتروني. ينتمي واحد منهما فقط إلى مجموعة عناوين البريد الإلكتروني الصريحة للحسابات. أما الآخر فيظهر في البيانات الوصفية أو في نص العينات، ولا يمكن ربطه بحقل بريد إلكتروني معتمد لحساب. لذلك لا يُختار ملف Info مصدرًا للبريد الإلكتروني، ويُسجَّل عليه دين تقني من نوع NON_AUTHORITATIVE_METADATA_SAMPLE. ولا يحتوي ملف Breached_Info العام على حقل بريد إلكتروني أو على علامة @. ويُربط تمثيل CSV بالتصنيف DUPLICATE_REPRESENTATION_SET_EQUAL. وتبقى تغطية تعيين الحقول عمدًا PARTIAL، لأن هذه التصنيفات لا تدّعي اكتمال كل جزء من النص الموجود في الأرشيف، أو اكتمال الحدث التاريخي بأكمله. ومع ذلك، فإن العناوين المقبولة مدعومة بالكامل بتعريفات DDL الصريحة وبالتطابق المستقل بين مجموعات العناوين المعيارية.

يتضمن المصدر أسماء مستخدمين وعناوين IP وتجزئات كلمات مرور ومنشورات منتدى وجداول رسائل خاصة، ولذلك تُدرج هذه الفئات لتوضيح نطاق السجل. تستورد عملية LeakData هذه عناوين البريد الإلكتروني فقط. ولا تكتب هذه المهمة كلمات المرور أو عناوين IP أو أسماء المستخدمين أو محتوى المنشورات أو محتوى الرسائل الخاصة في علاقات Mongo. يسجّل totalRecords صفوف حسابات المصدر البالغ عددها 3,331. وتبلغ قيمة كل من canonicalEmailCount وaffectedCountLowerBound عددًا قدره 3,271، لكن هذا الرقم لا يمثل عدد الأشخاص بعد استبعاد التكرار. فقد يتحكم شخص واحد في عدة عناوين، وقد يكون العنوان مشتركًا أو غير نشط. يظل العدد الدقيق للأشخاص المتأثرين مجهولًا، لذا تكون قيمة pwnCount هي null. ولا يمثل الرقم 3,271 سوى الحد الأدنى لعدد العناوين المعيارية الفريدة التي جرى التحقق منها في حقول بريد إلكتروني صريحة.

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