Conjunto de datos de 2017 asociado al foro de Horse & Hound
Este registro documenta un conjunto de datos etiquetado como correspondiente a enero de 2017 y asociado a la marca Horse & Hound, al dominio horseandhound.co.uk y al antiguo servicio de foro forums-secure.horseandhound.co.uk.
Tipos de datos expuestos
5- Direcciones de correo electrónico
- Nombres de usuario
- Direcciones IP
- Contraseñas transformadas mediante funciones hash
- Salts
Acerca de este registro
No se presenta como un incidente de seguridad verificado. No se encontró ningún comunicado de Horse & Hound que vincule el archivo comprimido inspeccionado con un incidente concreto, por lo que es obligatorio establecer isVerified=false. El 1 de enero de 2017 es solo la representación técnica de una fecha cuya precisión se limita al mes; no indica que se produjera un incidente ese día exacto. Se desconoce el número de personas distintas afectadas, por lo que pwnCount permanece en null.
La asociación con el evento procede de dos catálogos públicos independientes. BreachEra incluye en una misma fila Horse and Hound, horseandhound.co.uk, el año 2017, un alcance de 95 337 registros y las categorías de direcciones de correo electrónico, direcciones IP, nombres de usuario y contraseñas. Leak-Lookup informa de 95 338 registros para el mismo dominio e incluye columnas de nombre de usuario, dirección de correo electrónico, dirección IP, contraseña y sal criptográfica (salt) en su esquema estadístico. La diferencia de un registro entre ambos catálogos se explica por completo por un registro de preámbulo sin datos en la fuente sellada. No se seleccionaron ni ampliaron datos con el único fin de aproximarse al total de un catálogo.
El archivo comprimido inspeccionado HorseAndHound_BF.7z ocupa 4 529 396 bytes y está sellado mediante SHA-256 ee05e8…5352. Superó una prueba completa de integridad de 7z. Su archivo principal se llama Forums-secure.horseandhound.co.uk_vb_January_2017.txt, ocupa 8 868 144 bytes y tiene el SHA-256 b69419…7ca2. La fuente contiene 95 338 registros físicos: un preámbulo y 95 337 registros de datos. Una nota genérica de distribución independiente, de 441 bytes, no contiene ningún campo de correo electrónico por fila y se dio por cerrada como metadatos sin correo electrónico, en lugar de utilizarla para ampliar la fuente.
La fuente principal no es un CSV convencional con un encabezado explícito. Sus registros se asemejan a una representación de vBulletin delimitada por dos puntos y con un número variable de campos, ya que los propios nombres de usuario pueden contener dos puntos. La revisión utilizó como referencia estructural el único resumen hexadecimal de contraseña de 32 caracteres presente en cada registro de datos y examinó el campo con formato de correo electrónico situado dos posiciones antes de esa referencia. La regla se puede aplicar estructuralmente a cada uno de los 95 337 registros de datos. Sin embargo, la función del campo se infiere en lugar de estar indicada en un encabezado, por lo que la política de seguridad aplica un umbral de admisión más alto.
Dos analizadores independientes compilados en Go procesaron el mismo conjunto completo de archivos mediante implementaciones distintas y produjeron flujos de ocurrencias y de resultados canónicos idénticos byte a byte. Ambos informaron de 94 917 ocurrencias aceptadas, 94 876 resultados canónicos únicos, 41 ocurrencias duplicadas, 390 valores no vacíos rechazados y 30 posiciones vacías. La cobertura del campo seleccionado es de aproximadamente el 99,56 por ciento, mientras que el campo alternativo con formato de correo electrónico más sólido contiene solo 90 candidatos. Estas mediciones respaldan una inferencia sólida, pero mapping-admission v3 exige al menos 100 000 ocurrencias aceptadas para un mapeo inferido.
Las 94 917 ocurrencias observadas quedan 5 083 por debajo de ese mínimo obligatorio. Por tanto, el control de admisión se cerró con INFERENCE_OCCURRENCES_TOO_SMALL. No se redujo el umbral, no se añadieron otros campos para ajustarse al recuento de un catálogo y los 94 876 resultados canónicos no se publicaron como un recuento de personas afectadas. Este registro de metadatos no significa que se haya importado ninguna relación de correo electrónico: canonicalEmailCount es null, importedRecordCount=0 y el procesamiento sigue pendiente. No se puede crear ningún paquete READY, trabajo de importación ni relación de correo electrónico en Mongo a menos que el mapeo se admita posteriormente.
Se realizó una comparación con el índice global en tiempo real únicamente como auditoría. Del conjunto canónico inferido, 73 670 valores ya existían en el índice global de correos electrónicos y 21 206 no; las coincidencias se distribuían entre 798 identificadores de filtraciones. Esa distribución no permitió identificar ningún registro existente como titular de la fuente de Horse & Hound, y ningún trabajo de importación anterior estaba vinculado mediante la misma clave de origen, el mismo SHA del archivo comprimido, el mismo SHA canónico o la misma identidad del nombre de archivo. Una coincidencia no demuestra por sí sola que una dirección pertenezca a este foro. Solo muestra que el mismo valor canónico aparece en otros conjuntos de datos.
Los metadatos de Wayback CDX, consultados sin descargar el contenido de las páginas archivadas, confirman que se realizaron capturas correctamente del subdominio seguro del foro durante 2017. El dominio oficial actual de Horse & Hound también respalda la identificación del servicio. En cambio, no se encontró ninguna entrada exacta en fuente pública sobre la filtración de datos ni en NiamonX, y no se identificó ninguna comunicación sobre un incidente emitida por la propia organización. Estos resultados negativos no prueban que no haya ocurrido un incidente; delimitan el alcance de la verificación. Por ello, el registro mantiene una atribución prudente, no afirma abarcar la totalidad del evento y debe reevaluarse si se publica un comunicado de la propia organización o se dispone de un esquema explícito de la fuente.
Método de verificación y revisión editorial
LeakData compara el nombre del incidente, la fecha, la cantidad de registros afectados y los tipos de datos expuestos con fuentes accesibles. Los campos no verificados no se presentan como hechos, y los registros se actualizan cuando se dispone de nuevas pruebas.
Notificar errores u omisiones en la información