Conjunto de dados de 2017 associado ao fórum Horse & Hound

Ele não é apresentado como um incidente de segurança verificado. Não foi encontrado nenhum comunicado da Horse & Hound que vincule o arquivo compactado inspecionado a um incidente específico, por isso é obrigatório manter isVerified=false. A data de 1 de janeiro de 2017 é apenas a representação técnica de uma data cuja precisão se limita ao mês e não indica que um incidente tenha ocorrido exatamente nesse dia. O número de pessoas únicas afetadas é desconhecido, portanto pwnCount permanece null.

A associação ao evento vem de dois catálogos públicos distintos. O BreachEra lista Horse and Hound, horseandhound.co.uk, o ano de 2017, um total de 95.337 registros e as categorias endereços de e-mail, endereços IP, nomes de usuário e senhas em uma única linha. O Leak-Lookup informa 95.338 registros para o mesmo domínio e lista colunas de nome de usuário, endereço de e-mail, endereço IP, senha e salt em seu esquema de estatísticas. A diferença de um registro entre esses catálogos é totalmente explicada por um registro de preâmbulo, sem dados, na fonte selada. Nenhum dado foi selecionado nem ampliado apenas para se aproximar do total de um catálogo.

O arquivo compactado HorseAndHound_BF.7z inspecionado tem 4.529.396 bytes e está selado com o SHA-256 ee05e8…5352. Ele passou em um teste completo de integridade 7z. O principal arquivo contido nele se chama Forums-secure.horseandhound.co.uk_vb_January_2017.txt, tem 8.868.144 bytes e SHA-256 b69419…7ca2. A fonte contém 95.338 registros físicos: um preâmbulo e 95.337 registros de dados. Uma nota genérica de distribuição, separada, com 441 bytes, não tem campo de e-mail por linha e foi classificada como metadados sem e-mail, com a análise encerrada, em vez de ser usada para ampliar a fonte.

A fonte principal não é um CSV comum com cabeçalho explícito. Seus registros se assemelham a uma representação do vBulletin delimitada por dois-pontos, com larguras variáveis, pois os próprios nomes de usuário podem conter dois-pontos. A análise usou o único resumo criptográfico de senha hexadecimal de 32 caracteres em cada registro de dados como referência estrutural e mediu o campo com formato de e-mail duas posições antes dessa referência. A regra pode ser aplicada estruturalmente a todos os 95.337 registros de dados. Ainda assim, a identificação do campo é inferida, em vez de ser definida por um cabeçalho, por isso a política de segurança aplica um limite mínimo mais alto para admissão.

Dois analisadores sintáticos independentes, compilados em Go, processaram o mesmo conjunto completo de arquivos internos com implementações distintas e produziram fluxos de ocorrências e de valores canônicos idênticos byte a byte. Ambos informaram 94.917 ocorrências aceitas, 94.876 resultados canônicos únicos, 41 ocorrências duplicadas, 390 valores não vazios rejeitados e 30 posições vazias. A cobertura do campo selecionado é de cerca de 99.56 por cento, enquanto o campo alternativo com formato de e-mail mais promissor contém apenas 90 candidatos. Essas medições sustentam uma inferência forte, mas mapping-admission v3 exige pelo menos 100.000 ocorrências aceitas para um mapeamento inferido.

As 94.917 ocorrências observadas ficam 5.083 abaixo desse mínimo obrigatório. Por isso, o controle de admissão foi encerrado com INFERENCE_OCCURRENCES_TOO_SMALL. O limite não foi reduzido, outros campos não foram adicionados para corresponder à contagem de um catálogo, e os 94.876 resultados canônicos não foram publicados como uma contagem de pessoas afetadas. Este registro de metadados não significa que algum vínculo de e-mail tenha sido importado: canonicalEmailCount é null, importedRecordCount=0, e o processamento continua pendente. Nenhum pacote READY, tarefa de importação ou vínculo de e-mail no Mongo pode ser criado, a menos que a admissão do mapeamento seja aprovada posteriormente.

Uma comparação global em tempo real foi realizada apenas para fins de auditoria. Do conjunto canônico inferido, 73.670 valores já existiam no índice global de e-mails e 21.206 não existiam; as correspondências estavam distribuídas por 798 identificadores de vazamentos. Essa distribuição não identificou um único registro existente ao qual a fonte Horse & Hound pertencesse, e nenhuma tarefa de importação anterior estava vinculada à mesma chave de origem, ao mesmo SHA do arquivo compactado, ao mesmo SHA canônico ou à mesma identidade de nome de arquivo. Uma sobreposição não comprova, por si só, que um endereço pertença a esse fórum. Ela mostra apenas que o mesmo valor canônico aparece em outros conjuntos de dados.

Os metadados do Wayback CDX, consultados sem baixar o conteúdo das páginas arquivadas, confirmam capturas bem-sucedidas do subdomínio seguro do fórum durante 2017. O domínio oficial atual da Horse & Hound também dá respaldo à identificação do serviço. Por outro lado, não foi encontrada nenhuma entrada exata no fonte pública sobre vazamentos de dados ou no NiamonX, nem foi identificado qualquer comunicado de incidente emitido pela própria empresa. Esses resultados negativos não comprovam a ausência de um incidente; eles delimitam o que foi possível verificar. Por isso, o registro mantém uma atribuição cautelosa, não afirma que os dados abrangem o evento por completo e deve ser reavaliado caso seja disponibilizado um comunicado da própria empresa ou um esquema explícito da fonte.