Dispositivos e recuperação de carteiras · Aula 5 de 5
Contas em exchanges e na nuvem como evidência
9 min de leitura
A maioria das investigações que começa na blockchain termina em um serviço: uma exchange que sabe quem sacou os fundos, uma conta na nuvem que armazena o backup, uma caixa de entrada de e-mail repleta de confirmações de depósito. Os registros desses provedores frequentemente contêm a identidade e a intenção que a blockchain não consegue mostrar. Mas uma planilha de uma exchange não comprova sua própria autenticidade: o perito deve saber de onde ela veio, se está completa, o que cada coluna significa e se está de acordo com a blockchain. Esta aula aborda o conteúdo dos registros de provedores, como autenticá-los, como lidar com o acesso direto a contas e como conciliar os dados do provedor com os dados na blockchain.
O que contêm os registros de exchanges e custodiantes
Como solicitar registros é abordado na aula Trabalho com provedores de serviços; esta aula começa quando a resposta chega. Uma entrega típica de registros de uma exchange ou de um custodiante contém:
| Registro | Campos típicos | Uso forense |
|---|---|---|
| Dados do cliente e de KYC | Nome, documentos, verificações por selfie, datas de verificação | Identidade por trás de uma conta; verificação de identidades sintéticas ou emprestadas |
| Extrato ou livro-razão da conta | Cada crédito e débito, ativo, saldo, referência interna | Fluxo completo dentro do serviço, incluindo movimentações fora da blockchain |
| Depósitos | Endereço de depósito, txid, valor, rede, horário do crédito | Vinculação de entradas na blockchain à conta |
| Saques | Endereço de destino, txid, valor, taxa, rede, horários da solicitação e da transmissão | Vinculação da conta às saídas; a próxima etapa de um rastreamento |
| Negociações e conversões | Par, lado da operação, quantidade, preço, horário | Valor mudando de forma dentro do serviço |
| Logs de acesso | Horários de login, endereços IP, dispositivos, chaves de API | Quem operou a conta e de onde |
| Canais de moeda fiduciária | Contas bancárias vinculadas, cartões, referências de pagamento | Ponte para registros financeiros tradicionais |
Os registros podem chegar de três formas, com diferentes pesos probatórios. Entregas pelo provedor atendem a procedimentos legais e vêm com a proveniência do provedor. Exportações de usuários, como extratos baixados por um suspeito ou fornecidos por uma vítima, são encontradas em dispositivos ou entregues e devem ser conferidas com o provedor. Capturas em acesso direto são registros que um investigador coleta ao fazer login mediante autorização legal ou consentimento. Uma constatação deve indicar em qual tipo se baseia.
Autenticação dos registros de provedores
Autenticar significa demonstrar que um registro é o que afirma ser e que não foi alterado desde que foi produzido.
- Proveniência. Registre quem solicitou os dados, com base em qual autorização legal, por qual canal (um portal para autoridades policiais, transferência segura, mídia física), quem os recebeu e quando.
- Integridade no recebimento. Calcule o hash de cada arquivo entregue imediatamente, armazene o original sem modificações e trabalhe em cópias. Se o provedor fornecer seus próprios hashes, compare-os.
- Atestação. Muitos provedores podem fornecer uma declaração de um responsável pela custódia dos registros descrevendo como eles são criados e mantidos no curso normal das atividades. A necessidade dessa declaração e sua forma dependem da jurisdição; solicitá-la custa pouco.
- Significado. Obtenha um dicionário de dados: qual fuso horário os carimbos de data e hora usam, se os valores são brutos ou líquidos de taxas, o que significa cada código de status e como as transferências internas são apresentadas.
- Completude. Verifique se todo o período, as contas, os ativos e os tipos de registro solicitados foram entregues e se o saldo inicial mais as movimentações equivale ao saldo final.
Softwares de planilha causam erros evitáveis. Identificadores numéricos longos podem ser convertidos em notação científica, zeros à esquerda podem ser eliminados, valores podem ser arredondados e datas podem ser reinterpretadas em formatos locais. Importe os arquivos do provedor para uma ferramenta de análise ou banco de dados como texto, faça as conversões de forma deliberada e preserve as etapas de conversão.
Acesso direto a contas e registros de API
Às vezes, os investigadores acessam uma conta diretamente: com o consentimento de uma vítima, com credenciais encontradas durante uma busca legal ou por meio da API de uma exchange. Os dados acessados dessa forma podem estar armazenados no exterior. A Convenção de Budapeste, Artigo 32, permite que uma parte acesse dados armazenados localizados em outra parte com o consentimento lícito e voluntário da pessoa que tenha autoridade legal para divulgá-los, e que acesse dados disponíveis ao público; além disso, aplicam-se as vias descritas na aula Autorização legal e cooperação internacional. Quando uma ordem de apresentação de dados está disponível, ela geralmente oferece uma proveniência mais robusta do que um login.
Se for utilizado acesso direto, documente-o como uma ação em ambiente ativo: gravação de tela da sessão, horário, conta, cada exportação baixada com seu hash e, para chamadas de API, o endpoint, os parâmetros e a resposta bruta salva sem alterações. Tome cuidado para não alterar a conta: nenhuma negociação, nenhuma mudança de configuração, nenhuma redefinição de senha que alerte o titular e nenhuma ação que viole os acordos de não divulgação do provedor.
Conciliação dos registros de provedores com dados na blockchain
Um registro de provedor e a blockchain são duas fontes independentes sobre os mesmos eventos. Conciliá-los coloca ambos à prova, e um registro conciliado é muito mais difícil de contestar do que qualquer uma das fontes isoladamente. A verificação central dos saques associa as linhas do provedor aos dados da blockchain obtidos pela própria unidade:
-- Conciliar saques do provedor com saídas na blockchain (tabelas no estilo UTXO)
SELECT w.withdrawal_id, w.txid, w.to_address, w.amount_sat, -- valor do extrato, convertido em satoshis na importação
o.value AS value_sat, t.block_timestamp,
CASE
WHEN w.txid IS NULL THEN 'NO_TXID'
WHEN t.hash IS NULL THEN 'TXID_NOT_ON_CHAIN'
WHEN o.transaction_hash IS NULL THEN 'ADDRESS_NOT_IN_TX'
WHEN o.value <> w.amount_sat THEN 'AMOUNT_DIFFERS'
ELSE 'MATCHED'
END AS status
FROM provider_withdrawals w
LEFT JOIN transactions t ON t.hash = w.txid
LEFT JOIN outputs o ON o.transaction_hash = t.hash AND o.address = w.to_address
ORDER BY w.requested_utc;
Cada linha de saque é associada primeiro à transação pelo txid, depois à saída que paga ao endereço informado e, por fim, ao horário confirmado de seu bloco. As junções à esquerda mantêm as linhas do provedor que não têm correspondência, e a expressão CASE as classifica em categorias explicáveis em vez de descartá-las. A saída contém o valor líquido da taxa de saque do provedor, enquanto a consulta compara o valor conforme registrado no extrato; saber se esse valor é bruto ou líquido é uma questão a ser esclarecida pelo dicionário de dados, e uma diferença igual à taxa é uma diferença explicada, não uma divergência (W-102 abaixo). Em blockchains com modelo de contas, a junção com as saídas passa a ser uma junção com transferências ou logs de transferência de tokens, com um índice de log no lugar da saída.
Um exemplo de conciliação de cinco saques de uma conta:
| Saque | Status | Explicação |
|---|---|---|
| W-101 | MATCHED | txid, endereço e valor correspondem; horário do bloco 4 minutos após a solicitação |
| W-102 | AMOUNT_DIFFERS | O extrato mostra o valor bruto de 0,5000; a saída é de 0,4995; a taxa de saque de 0,0005 explica a diferença |
| W-103 | NO_TXID | O endereço do destinatário pertence a outro cliente da mesma exchange; liquidado no livro-razão interno, nunca na blockchain |
| W-104 | MATCHED | A transação é um lote que paga a 212 saídas; apenas a saída para o endereço informado pertence a este cliente |
| W-105 | TXID_NOT_ON_CHAIN | Solicitação cancelada antes da transmissão; a coluna de status confirma isso, após consulta ao dicionário de dados |
Cada linha termina com uma correspondência ou uma explicação. W-103 é um caso típico: transferências internas entre clientes do mesmo serviço são lançamentos no livro-razão do provedor, de modo que os registros do provedor são a única evidência dessas transferências (consulte a aula Rastreamento por meio de exchanges e serviços de custódia). W-104 mostra por que uma transação em lote não deve ser atribuída integralmente a um único cliente. Os depósitos são conciliados da mesma forma, lembrando que os provedores posteriormente consolidam os depósitos em carteiras quentes. As diferenças de horário devem ser explicadas pelo fuso horário do provedor e pelo intervalo entre solicitação, transmissão e confirmação.
Contas na nuvem como evidência
Os serviços de nuvem armazenam o que os usuários querem manter seguro ou sincronizado: fotos de frases-semente, backups de carteiras, planilhas de endereços, cofres de gerenciadores de senhas, anotações e e-mails com notificações de exchanges sobre depósitos, saques, logins e etapas de KYC. Esses registros são obtidos e autenticados como os registros de exchanges: preservados antecipadamente, fornecidos mediante autorização legal, submetidos ao cálculo de hash no recebimento e verificados quanto à completude.
O ataque à Bitfinex em 2016 mostra o valor de combiná-los com dados da blockchain. Com base em um mandado de busca, os investigadores obtiveram um arquivo de uma conta de armazenamento na nuvem e o descriptografaram. Ele listava cerca de 2.000 endereços de moedas virtuais com suas chaves privadas. A análise da blockchain vinculou quase todos esses endereços ao furto e, em 31 de janeiro e 1º de fevereiro de 2022, as autoridades apreenderam cerca de 94.636 BTC desses endereços. O arquivo na nuvem forneceu evidência de controle e um vínculo com seu titular; a blockchain confirmou que os endereços correspondiam aos fundos furtados. Nenhuma das fontes isoladamente teria o mesmo peso.
Foco no exame: o que os registros de exchanges contêm (KYC, livro-razão, depósitos, saques, negociações, logs de acesso, canais de moeda fiduciária) e o uso forense de cada um; entregas pelo provedor versus exportações de usuários versus capturas em acesso direto; as cinco etapas de autenticação (proveniência, integridade no recebimento, atestação, significado, completude) e as armadilhas das planilhas; documentação do acesso direto e por API e a via do consentimento do Artigo 32 da Convenção de Budapeste; conciliação de saques por txid, endereço, valor líquido e horário; explicação de transferências internas, taxas, lotes e solicitações canceladas; contas na nuvem como fontes de chaves, backups e notificações; o caso Bitfinex como exemplo da combinação de evidências da nuvem e da blockchain.