Alegação de exposição de dados da Grastin.ru em 2022

A descrição do arquivo compactado vincula a organização a Grastin e grastin.ru, informa que a fonte abrange o período de agosto de 2021 a novembro de 2022 e inclui nomes, números de telefone, endereços físicos e endereços de e-mail entre as categorias de dados. Os metadados CDX do Internet Archive também confirmam que grastin.ru mantinha uma presença ativa na web durante esse período. Os metadados públicos, por si só, não comprovam a autenticidade desse arquivo privado, não demonstram que o operador de Grastin o confirmou nem estabelecem o dia exato em que os dados foram expostos. Portanto, este registro não é apresentado como um comunicado de violação verificado pela própria organização. isVerified permanece false, e a alegação da fonte local é mantida separada do contexto público limitado sobre a entidade.

A data tem precisão apenas de mês. Os metadados internos usam a expressão novembro de 2022 como data da violação. O valor armazenado de 1 de novembro de 2022 é uma representação técnica desse mês; não indica que um incidente tenha ocorrido no primeiro dia. Os mesmos metadados afirmam que os registros abrangem o período de agosto de 2021 a novembro de 2022. Esse intervalo pode descrever atividades relacionadas a pedidos, clientes ou entregas e não permite, por si só, determinar o dia em que um conjunto de dados foi coletado ou distribuído. A pesquisa pública de escopo limitado não localizou um comunicado oficial, uma notificação de órgão regulador ou um relato confiável de incidente que confirmasse esse conjunto de dados específico. Portanto, breachDatePrecision é month, não há respaldo de uma fonte com autoridade para confirmar o dia exato, e qualquer alteração futura da data deve exigir uma nova revisão apoiada em evidências primárias mais robustas.

A fonte é um arquivo 7z completo de 35.580.567 bytes. Sua identidade SHA-256 está selada, e o arquivo passou em um teste completo de integridade 7z. Os três arquivos regulares contidos nele foram extraídos, tiveram seus tamanhos medidos e seus hashes calculados de forma independente. São eles: um arquivo genérico de metadados Breached_Info, um arquivo de metadados Info com descrições de Grastin e alegações da fonte, e um arquivo de dados CSV de 266.121.201 bytes. Não há arquivos compactados aninhados, e o conteúdo da fonte não foi modificado. O CSV tem 1.581.126 linhas físicas. Devido a sete quebras de linha incorporadas em campos CSV entre aspas, a contagem de registros lógicos de dados, excluindo o cabeçalho, é de 1.581.118. A análise estrita do CSV não encontrou erros de sintaxe, quantidade incorreta de colunas nem registros incompletos. A estabilidade dos bytes e a estrutura legível comprovam a integridade da fonte, mas não transformam todas as afirmações históricas contidas no arquivo em fatos públicos verificados.

O mapeamento de e-mails se baseia apenas no cabeçalho explícito definido pela fonte. As seis colunas são buyer, phone, address, email, region e month, nessa ordem. Apenas a quarta coluna, email, é selecionada. O campo buyer contém 332 células cujo conteúdo integral atende, por acaso, aos critérios estritos de sintaxe de e-mail, mas seu significado declarado é comprador ou nome, e não e-mail. Por isso, esses valores são excluídos deliberadamente. Textos com sinais de arroba no campo address, assim como os valores de phone, region e month, também são excluídos da importação de e-mails. Exemplos ou textos no arquivo de metadados Info não são tratados como campos de e-mail de conta. Nenhum campo adicional foi selecionado para se aproximar da alegação de 653.907 apresentada no catálogo, nenhum valor inválido foi corrigido e nenhum contador foi ajustado para atingir uma meta.

Dois leitores compilados independentes, escritos em Go, validaram todos os 1.581.118 registros lógicos de dados e o esquema de seis colunas sem erros. Ambos contabilizaram 704.204 ocorrências válidas de e-mail na coluna explícita email, 1.233 células não vazias rejeitadas e 875.681 células vazias. Após a deduplicação das ocorrências e a canonicalização estrita dos e-mails em ASCII, restam 654.125 endereços únicos ordenados. As duas ferramentas produziram o mesmo fluxo de ocorrências de 14.499.807 bytes, com a mesma identidade SHA-256. Também chegaram à mesma saída canônica, com 13.386.578 bytes, 654.125 linhas e uma única identidade SHA-256. O segundo validador verifica o esquema, os valores agregados e o conjunto canônico existente sem materializar uma segunda saída canônica. Esse caminho independente reduz a chance de que uma falha em uma única implementação de analisador ou no buffer de registros possa autorizar a importação.

Os metadados internos alegam 653.907 registros de e-mail, enquanto a extração estrita do campo explícito resulta em 654.125 endereços canônicos únicos, uma diferença de 218. A discrepância é preservada, e não ocultada. A alegação dos metadados não é reinterpretada como uma contagem de pessoas distintas, de endereços válidos ou de todas as linhas. totalRecords representa os 1.581.118 registros lógicos de dados do CSV, sourcePhysicalRecordCount registra a alegação de 1.581.126 linhas físicas, e canonicalEmailCount informa apenas os 654.125 endereços verificados na coluna explícita email. affectedCountLowerBound usa o mesmo limite inferior técnico de endereços, mas não é uma contagem de pessoas distintas. Uma pessoa pode controlar vários endereços, e um endereço pode ser compartilhado, abandonado ou reatribuído. Como a população de pessoas afetadas é desconhecida, pwnCount permanece null.

Esta operação do LeakData grava apenas endereços de e-mail nas relações do Mongo. Nomes, números de telefone, endereços físicos, regiões e valores de mês não são importados por esta tarefa. O arquivo Info fica pendente como NON_AUTHORITATIVE_METADATA_SAMPLE, enquanto o arquivo genérico Breached_Info é encerrado como RESOLVED_NO_EMAIL por não conter um campo de e-mail. A cobertura do mapeamento permanece PARTIAL; esse rótulo não indica que todos os textos do arquivo compactado ou todo o evento histórico tenham sido verificados. O registro é marcado como sensível e mantém o status de alegação de terceiros não verificada. A presença de um endereço no conjunto canônico não comprova que uma pessoa tenha usado os outros campos, que o registro ainda esteja atualizado ou que Grastin tenha confirmado esse arquivo específico. Se evidências oficiais mais robustas alterarem posteriormente a identidade, o escopo, a data ou as contagens, os metadados deverão ser revisados por meio de uma análise de evidências separada e rastreável.