Alegação de exposição de dados do GhostMarket.net em 2009

Os metadados internos do arquivo repetem o nome da entidade como GhostMarket e GhostMarket.net, informam um escopo de 3.331 registros de contas na fonte e fornecem apenas 2009 no campo de data da violação. Uma verificação limitada dos metadados públicos do acervo do Guardian também dá respaldo ao contexto de operação de um fórum de crimes online associado ao nome GhostMarket em 2009. A fonte pública não comprova o dia exato em que este arquivo específico foi obtido, não confirma que o operador do GhostMarket.net tenha autenticado esse conjunto de dados nem estabelece que todas as linhas arquivadas tenham vindo de um único evento. Por isso, o registro não é apresentado como um comunicado de violação verificado e emitido pela própria entidade. isVerified permanece false, e a descrição separa deliberadamente as evidências do arquivo selado do contexto público mais amplo.

A data é armazenada com precisão apenas de ano. O valor de banco de dados 1 de janeiro de 2009 é somente uma representação técnica do ano de 2009; não afirma que o evento tenha ocorrido em 1 de janeiro. Os metadados internos identificam 2009 como a “data da violação”, enquanto o cabeçalho da exportação SQL indica um momento de geração em julho de 2009. O momento de geração de um dump de banco de dados pode indicar quando uma exportação foi produzida, mas não estabelece, por si só, uma data de exposição. As referências a 2009 nos metadados públicos corroboram o período de operação da entidade, mas não situam a exposição dos dados privados em um dia específico. Por esses motivos, breachDatePrecision é year, o dia exato permanece desconhecido e a representação como 1 de janeiro vem acompanhada de uma ressalva explícita. Uma futura fonte primária poderia justificar uma revisão separada da data.

A fonte é um arquivo 7z completo de 3.728.860 bytes. Sua identidade SHA-256 está selada, e o arquivo passou em um teste completo de integridade 7z. Todos os quatro arquivos regulares contidos nele foram extraídos e vinculados de forma independente por tamanho e SHA-256. São eles: um arquivo genérico de metadados Breached_Info, um arquivo de metadados Info com contexto e amostras do GhostMarket, uma representação CSV da tabela de usuários do phpBB e um dump MySQL com oito tabelas do phpBB. Nenhum arquivo compactado aninhado foi encontrado, e o conteúdo da fonte não foi modificado. Os arquivos explicativos foram avaliados por meio de contadores livres de PII e rótulos estruturais, em vez de serem tratados como dados de contas em massa. Essa distinção evita que a legibilidade de um arquivo seja apresentada indevidamente como autorização para importar todos os tokens encontrados nele.

O mapeamento de e-mails se baseia exclusivamente no respaldo explícito do esquema. A DDL do MySQL identifica diretamente phpbb_users.user_email e phpbb_banlist.ban_email como campos de e-mail. Outras colunas cujos nomes contêm “email”, incluindo user_email_hash, user_emailtime, user_allow_viewemail e user_allow_massemail, representam um hash, uma marca de tempo ou indicadores de preferência e não são importadas como endereços. Noventa e dois valores que ocupam campos inteiros em outras partes (nomes de usuário, assuntos de mensagens, publicações, identificadores de mensagens instantâneas e valores de configuração) coincidem com o formato de endereços de e-mail canônicos, mas esses campos não têm a função de armazenar e-mails de contas e são excluídos. Não se usou nenhum ajuste à contagem do catálogo, calibragem para uma contagem-alvo ou coleta irrestrita de tokens brutos para escolher o mapeamento. Foram aceitos apenas os campos de e-mail declarados na DDL.

Dois leitores compilados independentes analisaram todas as 34.014 linhas SQL distribuídas em 505 instruções INSERT, sem erros estruturais. Ambos produziram a mesma sequência de 3.281 ocorrências válidas de e-mail, os mesmos 71.823 bytes e a mesma identidade SHA-256. As contagens de divergências no número de campos por linha, instruções não terminadas, falhas de varredura e erros de análise foram todas zero. Após a remoção das ocorrências duplicadas e a aplicação de uma validação estrita de e-mail em ASCII, restaram 3.271 endereços canônicos únicos, ordenados. A coluna explícita user_email no CSV de usuários do phpBB produziu, de forma independente, 3.280 ocorrências e exatamente o mesmo conjunto canônico de 3.271 endereços. Os arquivos canônicos CSV e SQL são idênticos byte a byte. O CSV não é importado novamente; ele é mantido como evidência de representação equivalente, para que uma conta não seja gravada duas vezes apenas porque a mesma tabela aparece em dois formatos na fonte.

O arquivo de metadados Info contém dois tokens brutos com aparência de e-mail. Apenas um pertence ao conjunto explícito de e-mails de contas. O outro aparece em metadados ou em texto de amostra e não pode ser vinculado a um campo de e-mail de conta com respaldo no esquema. Portanto, o arquivo Info não é selecionado como fonte de e-mails e recebe uma pendência NON_AUTHORITATIVE_METADATA_SAMPLE. O arquivo genérico Breached_Info não contém campo de e-mail nem sinal de arroba. A representação CSV é vinculada como DUPLICATE_REPRESENTATION_SET_EQUAL. A cobertura do mapeamento permanece intencionalmente PARTIAL, pois essas classificações não afirmam que cada trecho de texto do arquivo, ou o evento histórico inteiro, esteja completo. Ainda assim, os endereços aceitos têm respaldo integral na DDL explícita e na concordância independente entre os conjuntos canônicos.

A fonte inclui nomes de usuário, endereços IP, hashes de senhas, publicações no fórum e tabelas de mensagens privadas; por isso, essas categorias são listadas como contexto do escopo do registro. Esta operação do LeakData importa apenas endereços de e-mail. Senhas, endereços IP, nomes de usuário, conteúdo de publicações e conteúdo de mensagens privadas não são gravados em relacionamentos do Mongo por este processamento. totalRecords registra as 3.331 linhas de contas da fonte. canonicalEmailCount e affectedCountLowerBound são 3.271, mas esse número não é uma contagem de pessoas únicas. Uma pessoa pode controlar vários endereços, e um endereço pode ser compartilhado ou estar inativo. O número exato de pessoas afetadas permanece desconhecido, portanto pwnCount é null. O valor de 3.271 representa somente o limite inferior de endereços canônicos únicos verificados em campos explícitos de e-mail.

Você deve manter três distinções em mente. Primeiro, os metadados públicos dão respaldo à identidade GhostMarket e ao seu contexto de 2009, mas não foi localizada uma confirmação da própria entidade sobre este conjunto exato de dados. Segundo, a aprovação em um teste de integridade do arquivo comprova a estabilidade dos bytes e a legibilidade da estrutura, não a veracidade de cada alegação histórica contida nos arquivos. Terceiro, a presença de um endereço no conjunto canônico não comprova que a pessoa tenha usado todos os outros campos do arquivo nem que uma conta tenha permanecido ativa. O registro é marcado como sensível, mantém seu status de não verificado e é processado com regras restritas a e-mails que bloqueiam o processamento em caso de falha. Se evidências primárias mais sólidas vierem a estabelecer uma data mais precisa, um escopo diferente ou uma identidade organizacional diferente, os metadados deverão ser revisados por meio de uma análise separada das evidências.