OSINT e vinculação de identificadores on-chain e off-chain

A pesquisa em fontes abertas frequentemente fornece o vínculo que a análise on-chain não consegue estabelecer: uma publicação em que um suspeito divulgou um endereço, o histórico de registro do site de um golpe, um nome de usuário reutilizado em uma segunda plataforma. Essas correspondências deram início a muitas identificações. Também são fontes frequentes de erro, pois identificadores podem ser copiados, falsificados, revendidos e coincidir por acaso, e uma captura de tela sem URL, sem horário e sem registro de como foi encontrada é um alvo fácil de contestação em juízo. Esta aula aborda como planejar o trabalho com fontes abertas, coletar itens com proveniência, avaliar cada tipo de vínculo entre dados on-chain e off-chain e testar um vínculo antes de se apoiar nele.

Informação, inteligência e evidência

O Protocolo de Berkeley sobre Investigações Digitais em Fontes Abertas, publicado em dezembro de 2020 pelo Human Rights Center da UC Berkeley School of Law em conjunto com o Alto Comissariado das Nações Unidas para os Direitos Humanos, é a principal referência internacional para o trabalho com fontes abertas destinado a processos judiciais. Ele estabelece três distinções:

• Informação de fontes abertas: informação que qualquer membro do público pode observar, comprar ou solicitar, sem condição jurídica especial ou acesso não autorizado.
• Inteligência de fontes abertas (OSINT): informação de fontes abertas utilizada principalmente para apoiar decisões, como onde concentrar esforços ou o que solicitar.
• Evidência de fontes abertas: informação de fontes abertas com valor probatório, que pode ser utilizada para estabelecer fatos em processos.

A maior parte da OSINT em um caso envolvendo criptoativos permanece como inteligência, indicando o serviço a ser contatado. Somente itens coletados e preservados segundo um padrão probatório podem se tornar evidência; portanto, planeje isso desde a primeira busca: uma página que desaparece não pode ser coletada novamente. Quanto à localização dos dados, a Convenção de Budapeste permite que uma Parte acesse dados de computador armazenados e disponíveis publicamente, independentemente de sua localização geográfica (Artigo 32(a)); as regras nacionais sobre pesquisas on-line realizadas por investigadores continuam aplicáveis e são definidas pelos assessores jurídicos da unidade.

Planejamento e postura

O trabalho com fontes abertas segue o ciclo de inteligência: orientação (o que precisamos saber?), coleta, processamento, análise, disseminação e retroalimentação. O Protocolo de Berkeley descreve as etapas investigativas como pesquisas on-line, avaliação preliminar, coleta, preservação, verificação e análise investigativa. Antes de pesquisar, redija um breve plano de coleta nos autos do caso:

O plano limita a pesquisa ao que a pergunta exige (a minimização de dados está entre os princípios do Protocolo de Berkeley, juntamente com exatidão, preservação e segurança desde a concepção) e permite responder, posteriormente, por que uma fonte foi ou não pesquisada.

A forma como o investigador aparece on-line importa para a segurança e para o caso. A pesquisa atribuível é identificável como sendo do órgão ou da empresa e pode alertar os investigados. A pesquisa não atribuível utiliza infraestrutura que não revela a organização e consiste apenas em visualização passiva; é adequada à maior parte da OSINT sobre investigados. O trabalho encoberto, que envolve interação com investigados sob uma identidade fictícia, não é OSINT passiva e exige autorização legal específica; o Protocolo de Berkeley alerta que a falsa representação, como ingressar em grupos fechados sob falsos pretextos, pode violar direitos de privacidade e comprometer uma investigação. Até mesmo consultar um endereço suspeito em um explorador público informa ao operador que alguém está interessado; consultas sensíveis devem ser feitas em seu próprio nó (Aula 1.5).

Busca, captura e proveniência

Os operadores de busca ("…" para uma sequência exata, site:, -term, OR, intitle:, filetype: e, em alguns mecanismos, before: e after:) variam entre mecanismos e mudam ao longo do tempo; por isso, registre a sequência exata da consulta junto de cada resultado. Para casos envolvendo criptoativos:

• Pesquise endereços completos, com e sem aspas, em vários mecanismos de busca, repositórios de código e sites de compartilhamento de texto; um resultado para uma sequência longa e única raramente é coincidência, embora possa ser uma cópia. Pesquise nomes de usuário com suas variantes (sublinhados, dígitos, substituições).
• Consulte arquivos da web, como a Wayback Machine do Internet Archive, em busca de versões anteriores à remoção dos endereços de depósito de um site de golpe ou à edição de uma publicação por um usuário; cite a URL do arquivo e o horário da captura conforme registrados pelo arquivo.
• Capture primeiro, analise depois. Páginas no ar mudam e desaparecem, às vezes porque o investigado percebeu o interesse.

Cada item precisa de informações suficientes para demonstrar posteriormente o que era, de onde veio, quando e como foi capturado e que não foi alterado. O documento Boas Práticas para Aquisição de Conteúdo On-line do SWGDE (documento 21-F-001) recomenda capturar a sequência completa de URLs, registrar datas, horários e fuso horário do acesso, preservar metadados, calcular o hash de cada arquivo adquirido com algoritmos aprovados pelo NIST e documentar o perito, o navegador e o IP de acesso; o Protocolo de Berkeley acrescenta as ferramentas e os softwares utilizados. Uma entrada no registro de coleta:

{
  "item_id": "OS-0007",
  "case_id": "CF-2026-0142",
  "url": "https://forum.example/t/48213?page=3#post-912",
  "query": "\"bc1q…7k3f\" site:forum.example",
  "captured_utc": "2026-03-06T10:41:12Z",
  "method": "full-page capture + HTML source + WARC",
  "tool": "open-source capture tool v3.2, browser 128",
  "files": [
    {"name": "OS-0007.warc.gz", "sha256": "5b0e…11d4"},
    {"name": "OS-0007.png", "sha256": "c3a9…7e20"}
  ],
  "archive_copy": "web archive capture requested 2026-03-06T10:44Z",
  "posture": "non-attributable, research host RH-2",
  "collector": "EX-07",
  "note": "post dated 2023-11-14 shows address in user signature"
}

A entrada mantém um arquivo WARC (o formato de arquivamento da web padronizado como ISO 28500), que preserva a troca HTTP; uma captura de tela legível; e o código-fonte HTML, cada um com hash calculado no momento da captura, além de uma cópia independente em arquivo da web como registro de terceiro. A nota separa a data exibida na publicação, uma alegação da plataforma, do horário da captura, uma observação do próprio perito.

Tipos de vínculo e sua força

Cada vínculo é classificado individualmente segundo a escala da Aula 4.5, e uma cadeia de vínculos recebe a classificação de seu elo mais fraco. A coluna de força é um ponto de partida típico, não uma classificação: uma assinatura que você mesmo verificou é evidência direta de controle no momento da assinatura (A nessa escala); uma única publicação ou um registro cadastral é um indicador com modos de falha conhecidos (C); uma correspondência isolada de nome de usuário ou horário de atividade geralmente é uma pista (D); e qualquer um deles sobe para B quando um indicador independente de outro tipo concorda.

Mensagens assinadas e serviços de nomes

A correspondência mais forte é uma mensagem assinada. Segundo o BIP-322 (Bitcoin) ou o EIP-191 (Ethereum), o detentor de uma chave assina um texto, e qualquer pessoa pode verificar a assinatura. Uma assinatura válida mostra que o signatário podia assinar pelo endereço naquele momento. O próprio BIP-322 observa o que isso não comprova: que o signatário ainda controla os fundos ou que enviou alguma transação anterior. Verifique você mesmo cada assinatura com uma implementação aberta, registrando a ferramenta e a versão.

O Ethereum Name Service (ENS) mapeia nomes para endereços em duas direções de pesos diferentes. A resolução direta (nome para endereço) é definida pelo proprietário do nome e pode apontar para qualquer endereço sem o consentimento desse endereço; ela mostra o que o proprietário do nome escolheu exibir. A resolução reversa (endereço para nome principal) é definida por uma transação do próprio endereço; portanto, é uma declaração de quem controlava o endereço quando ela foi definida, o que é mais forte, especialmente quando os registros direto e reverso coincidem. Os nomes também contêm registros de texto, como url, email, com.twitter e avatar. Eles expiram: após o período de carência e um período de 21 dias de preço premium decrescente, qualquer pessoa pode registrar um nome expirado; por isso, registre o histórico de registro e o bloco em que cada registro foi definido. Selos de carteira verificada e recursos de "conectar carteira" nas plataformas são declarações da plataforma; seus registros de qual conta vinculou qual endereço podem ser solicitados.

Nomes de usuário, e-mails e domínios

As pessoas reutilizam nomes de usuário. Na investigação do Silk Road, um investigador que buscava as primeiras menções on-line ao mercado encontrou publicações de janeiro de 2011 de um mesmo nome de usuário promovendo o site em dois fóruns; uma publicação posterior do mesmo nome de usuário, recrutando um desenvolvedor, fornecia um endereço de e-mail pessoal para respostas, que se tornou uma pista apurada por meio de procedimentos legais. Pondere uma correspondência de nome de usuário pela raridade (quietharbor_77 em dois fóruns significa mais do que crypto_king; pesquise quantos usuários sem relação entre si o compartilham), pela consistência de temas, estilo, fusos horários e datas, pelo histórico da conta (uma conta criada no dia seguinte a um alerta público tem maior probabilidade de ser uma imitação do que uma reutilização) e pela direção (o uso mais antigo geralmente é o mais importante). Uma correspondência sustenta uma hipótese; a conta por trás dela é uma conta em um serviço cujos registros de assinante podem ser solicitados (Aula 1.4).

Plataformas de golpe, exchanges falsas e kits de phishing precisam de domínios, e domínios deixam registros. Para domínios genéricos de primeiro nível, o Protocolo de Acesso a Dados de Registro (RDAP) tornou-se a fonte definitiva de dados de registro em 28 de janeiro de 2025, substituindo o WHOIS. As respostas públicas frequentemente têm dados ocultados por motivos de privacidade, de modo que os dados do titular do domínio geralmente são obtidos junto ao registrador por meio de procedimentos legais; o Segundo Protocolo Adicional à Convenção de Budapeste prevê solicitações diretas de informações de registro de nomes de domínio (Artigo 6). Dados históricos de registro e DNS passivo mostram quais endereços IP um domínio utilizou e quais outros domínios os compartilharam. Os logs de Certificate Transparency (RFC 6962) registram certificados TLS publicamente confiáveis em logs públicos que só permitem acréscimos, e pesquisá-los por uma marca de golpe frequentemente revela domínios relacionados. A infraestrutura compartilhada vincula sites entre si com mais confiabilidade do que a uma pessoa: um IP compartilhado em um grande serviço de hospedagem é fraco, enquanto um identificador incomum de análise de tráfego ou um endereço de depósito compartilhado é forte.

Cópias, cronologia e evidência de IP

Endereços estão entre as sequências de caracteres mais copiadas na internet. Endereços de doação e pagamento são republicados por fãs, golpistas e agregadores. No envenenamento de endereços, atacantes criam endereços semelhantes que compartilham os primeiros e os últimos caracteres do endereço de uma contraparte da vítima e enviam transferências de valor mínimo ou zero para que o endereço semelhante apareça no histórico da vítima; um endereço truncado em uma captura de tela pode corresponder a qualquer um dos dois. Algumas plataformas permitem edições sem histórico visível; portanto, compare com capturas de arquivos da web. Sempre compare o endereço completo, caractere por caractere ou por hash. A cronologia é o teste mais forte: uma publicação que mostra um endereço antes de sua primeira atividade on-chain é muito mais forte do que uma que aparece após um alerta público, quando qualquer pessoa poderia copiá-lo. No exemplo, a publicação OS-0007 é datada de 2023-11-14 e o endereço recebeu fundos pela primeira vez em dezembro de 2023.

Endereços IP vêm principalmente de registros de serviços (logs de login de exchanges, backends de carteiras, provedores de nós ou APIs) obtidos por meio de procedimentos legais (Aula 7.5). Biryukov, Khovratovich e Pustogarov (2014) demonstraram que observadores da rede ponto a ponto às vezes conseguem vincular transações Bitcoin ao endereço IP que primeiro as retransmitiu, mas isso não é uma evidência rotineira, e o Tor inviabiliza essa técnica. Uma correspondência de IP precisa de contexto: nós de saída de VPN, Tor, NAT de operadora e escritórios compartilhados colocam muitas pessoas atrás de um único endereço, e os logs usam fusos horários diferentes.

Perfis de horários de atividade são, no máximo, evidência complementar. Contar as transações de um cluster por hora UTC (em SQL, EXTRACT(HOUR FROM block_timestamp), ou HOUR() ou date_part('hour', …) em alguns mecanismos) gera um perfil para comparar com os horários de publicação de um nome de usuário. Lembre-se dos limites: o horário do bloco não é o horário de propagação (no Bitcoin, os timestamps dos blocos podem diferir do horário real em mais de uma hora), bots funcionam 24 horas por dia e muitas pessoas compartilham um fuso horário.

Verificação e teste de um vínculo

Os itens coletados são alegações até que sejam verificados quanto à autenticidade, confiabilidade, relevância e valor probatório. Examine a fonte (quem publicou; a conta é autêntica e estabelecida?), o conteúdo (é consistente internamente e com outras informações?) e os vestígios técnicos (metadados, estrutura da página, histórico em arquivos da web). A blockchain oferece uma forte verificação independente de alegações datadas. Em seguida, registre as explicações concorrentes (o autor da publicação controla o endereço; copiou o endereço; teve sua identidade imitada ou sua conta comprometida) e as evidências a favor e contra cada uma.

Pergunte com que frequência um vínculo ocorreria por acaso. Se um suspeito sacou 0,5 ETH da Exchange K dez minutos após um depósito de 0,5 ETH em outro lugar, conte quantos saques de 0,5 ETH as carteiras quentes da Exchange K fizeram nesse intervalo; se foram quarenta, a correspondência é fraca. Depois, aplique uma lista de verificação:

1. O identificador é raro, e você verificou quantos outros o compartilham?
2. Ele foi observado antes de o caso se tornar público?
3. Ele poderia ter sido copiado, imitado ou envenenado?
4. O horário do registro off-chain é compatível com a atividade on-chain?
5. Existe um segundo vínculo independente, idealmente de outro tipo?
6. As explicações concorrentes foram registradas e testadas?

Registre também os vínculos que não passaram pela lista de verificação.

Documentação para apresentação em juízo

Uma peça de evidência de fonte aberta é defensável quando outro perito consegue seguir o mesmo caminho e verificar cada item. Os autos do caso contêm o plano de coleta e suas alterações; o registro de coleta e as capturas com hash sob cadeia de custódia (Aulas 8.2 e 8.3); notas contemporâneas aos fatos, incluindo buscas que não encontraram nada; a verificação de cada item utilizado como fundamento; e uma declaração de postura confirmando que não houve acesso não autorizado nem falsa representação. No laudo, cite os itens por identificador, transcreva apenas o necessário e oculte os dados de pessoas não envolvidas; vínculos com pessoas físicas permanecem em um anexo de acesso restrito até serem confirmados por meio de procedimentos legais.

Foco no exame: informação, inteligência e evidência de fontes abertas no Protocolo de Berkeley (2020) e suas etapas de investigação; Artigo 32(a) da Convenção de Budapeste; um plano de coleta com regra de parada; posturas atribuível, não atribuível e encoberta e por que o trabalho encoberto exige autorização específica; registro da consulta exata e captura antes da análise; registros de coleta com URL completa, horário UTC, método, versão da ferramenta, hashes SHA-256 e WARC (ISO 28500), conforme o SWGDE 21-F-001; os tipos de vínculo e sua força típica; o que uma mensagem assinada (BIP-322, EIP-191) comprova e o que não comprova; resolução direta versus reversa do ENS e expiração; ponderação de correspondências de nomes de usuário (raridade, consistência, histórico da conta, primeiro uso); RDAP desde 28 de janeiro de 2025, DNS passivo, Certificate Transparency (RFC 6962) e infraestrutura compartilhada; endereços copiados, envenenamento de endereços e comparação de endereços completos; limites da correlação de IP e horários de atividade; raciocínio baseado em taxas-base e a lista de verificação contra vínculos coincidentes.