Afirmación de exposición de datos de GhostMarket.net en 2009

Los metadatos internos del archivo repiten el nombre de la entidad como GhostMarket y GhostMarket.net, indican que el conjunto de origen abarca 3 331 registros de cuentas y solo incluyen 2009 en el campo de fecha de la filtración. Una comprobación acotada de los metadatos públicos del archivo de Guardian también respalda el contexto operativo de un foro de delincuencia en línea asociado al nombre GhostMarket durante 2009. La fuente pública no demuestra el día exacto en que se obtuvo este archivo concreto, no confirma que el operador de GhostMarket.net autenticara este conjunto de datos ni establece que todas las filas archivadas procedan de un único suceso. Por tanto, el registro no se presenta como una notificación verificada de filtración emitida por la propia entidad. isVerified sigue siendo false, y la descripción distingue deliberadamente las pruebas del archivo sellado del contexto público más amplio.

La fecha se almacena con una precisión limitada al año. El valor de la base de datos, 1 de enero de 2009, es solo una representación técnica del año 2009; no afirma que el suceso ocurriera el 1 de enero. Los metadatos internos identifican 2009 como la “fecha de la filtración”, mientras que la cabecera de la exportación SQL indica una fecha de generación de julio de 2009. La fecha de generación de un volcado de base de datos puede indicar cuándo se produjo una exportación, pero no establece por sí sola una fecha de exposición. Las referencias a 2009 en los metadatos públicos corroboran el período de actividad de la entidad, pero no sitúan la exposición de datos privados en un día concreto. Por estas razones, breachDatePrecision es year, el día exacto sigue siendo desconocido y se aclara expresamente el sentido de la representación del 1 de enero. Una futura fuente primaria podría justificar una revisión de la fecha por separado.

La fuente es un archivo 7z completo de 3 728 860 bytes. Su identidad SHA-256 está sellada y el archivo superó una prueba completa de integridad 7z. Se extrajeron los cuatro archivos regulares que lo componen y se vincularon de forma independiente mediante su tamaño y SHA-256. Se trata de un archivo genérico de metadatos Breached_Info, un archivo de metadatos Info que contiene contexto y muestras de GhostMarket, una representación CSV de la tabla de usuarios de phpBB y un volcado MySQL que contiene ocho tablas de phpBB. No se encontró ningún archivo comprimido anidado y no se modificó el contenido de origen. Los archivos explicativos se evaluaron mediante contadores sin PII y etiquetas estructurales, en lugar de tratarlos como datos masivos de cuentas. Esta distinción evita que la posibilidad de leer un archivo se presente erróneamente como fundamento para importar todos los tokens que contiene.

El mapeo de campos de correo electrónico se basa únicamente en lo que el esquema establece de forma explícita. El DDL de MySQL identifica directamente phpbb_users.user_email y phpbb_banlist.ban_email como campos de correo electrónico. Otras columnas cuyos nombres contienen “email”, como user_email_hash, user_emailtime, user_allow_viewemail y user_allow_massemail, representan un hash, una marca de tiempo o indicadores de preferencias y no se importan como direcciones. Noventa y dos valores de campos completos situados en otras partes, entre nombres de usuario, asuntos de mensajes, publicaciones, identificadores de mensajería instantánea y valores de configuración, tienen por casualidad la forma de direcciones de correo electrónico canónicas, pero esos campos no representan el correo electrónico de una cuenta y se excluyen. Para elegir el mapeo no se recurrió a ajustes para hacer coincidir el recuento del catálogo, a calibraciones para alcanzar un recuento objetivo ni a la recolección sin restricciones de tokens sin procesar. Solo se aceptaron los campos de correo electrónico declarados en el DDL.

Dos lectores compilados independientes analizaron las 34 014 filas SQL distribuidas en 505 instrucciones INSERT sin errores estructurales. Ambos produjeron la misma secuencia de 3 281 apariciones válidas de direcciones de correo electrónico, los mismos 71 823 bytes y la misma identidad SHA-256. Las discrepancias en el número de campos por fila, las instrucciones sin terminar, los fallos del escáner y los errores del analizador fueron todos cero. Tras eliminar las apariciones duplicadas y aplicar una validación estricta de correo electrónico ASCII, quedaron 3 271 direcciones canónicas únicas y ordenadas. La columna explícita user_email del CSV de usuarios de phpBB produjo de forma independiente 3 280 apariciones y exactamente el mismo conjunto canónico de 3 271 direcciones. Los archivos canónicos del CSV y del SQL son idénticos byte por byte. El CSV no se vuelve a importar; se conserva como prueba de una representación equivalente para evitar que una cuenta se escriba dos veces solo porque la misma tabla aparece en dos formatos de origen.

El archivo de metadatos Info contiene dos tokens sin procesar con apariencia de correo electrónico. Solo uno pertenece al conjunto explícito de direcciones de correo electrónico de cuentas. El otro aparece en metadatos o en texto de muestra y no puede vincularse a un campo definido explícitamente por el esquema como correo electrónico de cuenta. Por ello, el archivo Info no se selecciona como fuente de correo electrónico y se registra con una deuda NON_AUTHORITATIVE_METADATA_SAMPLE. El archivo genérico Breached_Info no contiene ningún campo de correo electrónico ni ningún signo arroba. La representación CSV se vincula como DUPLICATE_REPRESENTATION_SET_EQUAL. La cobertura del mapeo se mantiene deliberadamente en PARTIAL, porque estas clasificaciones no afirman que todos los textos del archivo, ni el suceso histórico en su conjunto, estén completos. No obstante, las direcciones admitidas están plenamente respaldadas por la definición explícita del DDL y la coincidencia de los conjuntos canónicos obtenidos de forma independiente.

La fuente incluye nombres de usuario, direcciones IP, hashes de contraseñas, publicaciones del foro y tablas de mensajes privados, por lo que esas categorías se enumeran para contextualizar el alcance del registro. Esta operación de LeakData solo importa direcciones de correo electrónico. Este proceso no escribe contraseñas, direcciones IP, nombres de usuario, contenido de publicaciones ni contenido de mensajes privados en las relaciones de Mongo. totalRecords registra las 3 331 filas de cuentas de la fuente. canonicalEmailCount y affectedCountLowerBound son 3 271, pero esa cifra no es un recuento de personas únicas. Una persona puede controlar varias direcciones, y una dirección puede ser compartida o estar inactiva. El número exacto de personas afectadas sigue siendo desconocido, por lo que pwnCount es null. La cifra de 3 271 es únicamente el límite inferior de direcciones canónicas únicas verificadas en campos explícitos de correo electrónico.

Quienes consulten este registro deben mantener tres distinciones. En primer lugar, los metadatos públicos respaldan la identidad de GhostMarket y su contexto de 2009, pero no se encontró ninguna confirmación de este conjunto de datos exacto por parte de la propia entidad. En segundo lugar, superar una prueba de integridad del archivo demuestra la estabilidad de los bytes y que la estructura es legible, no la veracidad de todas las afirmaciones históricas contenidas en los archivos. En tercer lugar, la presencia de una dirección en el conjunto canónico no demuestra que la persona utilizara todos los demás campos del archivo ni que una cuenta siguiera activa. El registro está marcado como sensible, conserva su estado de no verificado y se procesa con reglas que solo admiten correo electrónico y bloquean la operación ante un fallo. Si posteriormente aparecen pruebas primarias más sólidas que establezcan una fecha más precisa, un alcance distinto o una identidad organizativa diferente, los metadatos deberán revisarse mediante una evaluación de pruebas independiente.