Все утечки
1 января 2009 г. Не подтверждено Запись с чувствительными данными Другое

Заявление об утечке данных GhostMarket.net в 2009 году

В этой записи с оговорками описывается набор данных форума, связанный с доменом GhostMarket.net и отнесённый к 2009 году.

Не менее 3 271
Заявленное число записей
6
Типы данных
Не ниже: Низкая
Масштаб раскрытия данных
10 окт. 2026 г.
Последнее обновление

Эта классификация основана на проверенной нижней границе; фактический масштаб последствий и серьёзность могут быть выше.

Защитите себя

Проверьте, затронула ли вас эта утечка

Проверить мой адрес электронной почты

Типы раскрытых данных

6
  • Адреса электронной почты
  • Имена пользователей
  • IP-адреса
  • Пароли
  • Сообщения на форумах
  • Личные сообщения

Об этой записи

Во внутренних метаданных архива название ресурса повторяется в вариантах GhostMarket и GhostMarket.net, заявленный объём исходных данных составляет 3 331 запись об аккаунтах, а в поле даты утечки указан только 2009 год. Ограниченная проверка общедоступных метаданных архива Guardian также подтверждает, что в 2009 году действовал онлайн-форум криминальной направленности, связанный с названием GhostMarket. Общедоступный источник не доказывает, в какой именно день был получен этот архив, не подтверждает, что оператор GhostMarket.net удостоверил подлинность набора данных, и не устанавливает, что все строки архива относятся к одному событию. Поэтому эта запись не представляется как проверенное уведомление об утечке от самой организации. Значение isVerified остаётся false, а в описании намеренно разграничены зафиксированные свидетельства из архива и более широкий публичный контекст.

Дата хранится с точностью до года. Значение 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.

Две независимые скомпилированные программы чтения разобрали все 34 014 строк SQL в 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 году, но подтверждения именно этого набора данных от самой организации не найдено. Во-вторых, успешная проверка целостности архива подтверждает неизменность байтов и читаемость структуры, а не достоверность каждого исторического утверждения в файлах. В-третьих, наличие адреса в каноническом наборе не доказывает, что его владелец использовал все остальные поля архива или что аккаунт оставался активным. Запись помечена как чувствительная, сохраняет неподтверждённый статус и обрабатывается по правилам, допускающим только адреса электронной почты и запрещающим импорт при недостаточной проверке. Если впоследствии более весомые первичные свидетельства установят более точную дату, иной объём данных или принадлежность к другой организации, метаданные следует пересмотреть в рамках отдельной проверки доказательств.

Методика проверки и подготовки материалов

LeakData сверяет название инцидента, дату, число затронутых записей и типы раскрытых данных с доступными источниками. Неподтверждённые сведения не представляются как факты, а записи обновляются при появлении новых подтверждающих данных.

Сообщить о недостающих или неверных сведениях