Exchange e contas na nuvem como evidências

A maioria das investigações que começam on-chain termina em um serviço: uma exchange que sabe quem sacou os fundos, uma conta na nuvem que guarda o backup, uma caixa de entrada de e-mail cheia de confirmações de depósitos. Os registros desses provedores muitas vezes revelam a identidade e a intenção que a blockchain não pode mostrar. Mas uma planilha de uma exchange não comprova a si mesma: o examinador precisa saber de onde veio, se está completa, o que cada coluna significa e se está de acordo com a cadeia. Esta aula aborda o que os registros dos provedores contêm, como autenticá-los, como lidar com o acesso a contas ativas e como reconciliar os dados dos provedores com os dados on-chain.

O que os registros de exchanges e custodiante contêm

Como solicitar registros é abordado na aula Trabalho com provedores de serviços; esta aula começa quando a resposta chega. Uma produção típica de uma exchange ou custodiante contém:

Os registros podem chegar de três maneiras, com diferentes pesos probatórios. Produções do provedor respondem a solicitações legais e vêm acompanhadas da procedência informada pelo provedor. Exportações do usuário, como extratos baixados por um suspeito ou fornecidos por uma vítima, são encontradas em dispositivos ou entregues, e precisam ser verificadas junto ao provedor. Coletas ao vivo são registros que um investigador coleta ao fazer login com autorização ou consentimento. O relatório de uma constatação deve indicar em qual tipo ela se baseia.

Autenticação de registros dos provedores

Autenticar significa demonstrar que um registro é o que afirma ser e que não foi alterado desde que foi produzido.

1. Procedência. Registre quem solicitou os dados, com base em qual autoridade, por qual canal (um portal para autoridades policiais, transferência segura, mídia física), quem os recebeu e quando.
2. Integridade no recebimento. Gere o hash de cada arquivo recebido imediatamente, armazene o original sem modificações e trabalhe com cópias. Se o provedor fornecer seus próprios hashes, compare-os.
3. Atestado. Muitos provedores podem fornecer uma declaração de um custodiante de registros descrevendo como os registros são criados e mantidos no curso normal dos negócios. Se é necessário e em que formato depende da jurisdição; solicitá-lo custa pouco.
4. Significado. Obtenha um dicionário de dados: qual fuso horário os registros de data e hora usam, se os valores são brutos ou líquidos de tarifas, o que significa cada código de status e como as transferências internas são apresentadas.
5. Completude. Verifique se o período, as contas, os ativos e os tipos de registro solicitados foram todos fornecidos e se o saldo inicial mais as movimentações equivale ao saldo final.

Softwares de planilhas causam erros evitáveis. Identificadores numéricos longos podem ser convertidos em notação científica, zeros à esquerda podem ser removidos, valores podem ser arredondados e datas podem ser reinterpretadas em formatos locais. Importe os arquivos dos provedores para uma ferramenta de análise ou banco de dados como texto, converta-os deliberadamente e mantenha o registro das etapas de conversão.

Acesso a contas ativas e registros de API

Às vezes, 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 maneira 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 tem autoridade legal para divulgá-los, bem como acesse dados publicamente disponíveis; além disso, aplicam-se os meios descritos na aula Autoridade legal e cooperação internacional. Quando há uma ordem de produção disponível, ela geralmente proporciona uma procedência mais sólida do que um login.

Se houver acesso ao vivo, documente-o como uma ação ao vivo: gravação de tela da sessão, horário, conta, cada exportação baixada com seu hash e, no caso de chamadas de API, endpoint, parâmetros e resposta bruta salva sem alterações. Tome cuidado para não modificar a conta: não faça negociações, não altere configurações, não redefina a senha de modo a alertar o titular e não realize ações que violem acordos de não divulgação do provedor.

Reconciliação dos registros dos provedores com os dados on-chain

Um registro do provedor e a blockchain são duas fontes independentes sobre os mesmos eventos. Reconciliá-los permite verificar ambas, e um registro reconciliado é muito mais difícil de contestar do que qualquer uma das fontes isoladamente. A verificação central dos saques combina as linhas do provedor com os dados da cadeia da própria unidade:

-- Reconcile provider withdrawals with on-chain outputs (UTXO-style tables)
SELECT w.withdrawal_id, w.txid, w.to_address, w.net_amount_btc,
       o.value_btc, b.block_time_utc,
       CASE
         WHEN w.txid IS NULL THEN 'NO_TXID'
         WHEN t.txid IS NULL THEN 'TXID_NOT_ON_CHAIN'
         WHEN o.txid IS NULL THEN 'ADDRESS_NOT_IN_TX'
         WHEN o.value_btc <> w.net_amount_btc THEN 'AMOUNT_DIFFERS'
         ELSE 'MATCHED'
       END AS status
FROM provider_withdrawals w
LEFT JOIN transactions t ON t.txid = w.txid
LEFT JOIN outputs o ON o.txid = t.txid AND o.address = w.to_address
LEFT JOIN blocks b ON b.block_height = t.block_height
ORDER BY w.requested_utc;

Cada linha de saque é primeiro associada à transação pelo txid, depois à saída que paga o endereço informado e, por fim, ao bloco correspondente para determinar o horário de confirmação. Junções à esquerda mantêm as linhas do provedor que não encontram correspondência, e a expressão CASE as organiza em categorias que podem ser explicadas, em vez de descartá-las. Os valores são comparados líquidos da tarifa de saque do provedor, por isso o dicionário de dados é importante. Em blockchains com modelo de contas, a junção com saídas é substituída por uma junção com transferências ou registros de transferência de tokens, usando um índice de registro no lugar da saída.

Uma reconciliação trabalhada de cinco saques de uma conta:

Cada linha termina em correspondência ou com uma explicação. W-103 é típico: transferências internas entre clientes do mesmo serviço são lançamentos no livro-razão do provedor; portanto, os registros do provedor são a única evidência delas (consulte a aula Rastreamento por 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 reconciliados da mesma maneira, lembrando que, mais tarde, os provedores transferem os depósitos para carteiras quentes. 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

Serviços de nuvem guardam o que os usuários querem manter em segurança ou sincronizado: fotos de frases-semente, backups de carteiras, planilhas de endereços, cofres de gerenciadores de senhas, notas 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 registros de exchanges: preservados desde cedo, produzidos sob autoridade, com hash gerado no recebimento e verificados quanto à completude.

O ataque à Bitfinex em 2016 mostra o valor de combinar esses registros com dados da cadeia. Com um mandado de busca, 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 de blockchain vinculou quase todos esses endereços ao roubo 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ências de controle e um vínculo com seu titular; a cadeia confirmou que os endereços correspondiam aos fundos roubados. Nenhuma das fontes, sozinha, teria o mesmo peso.

Foco no exame: o que os registros de exchanges contêm (KYC, livro-razão, depósitos, saques, negociações, registros de acesso, canais fiduciários) e o uso forense de cada um; produções do provedor vs. exportações do usuário vs. coletas ao vivo; as cinco etapas de autenticação (procedência, integridade no recebimento, atestado, significado, completude) e as armadilhas das planilhas; documentação do acesso ao vivo e por API e a via do consentimento prevista no Artigo 32 da Convenção de Budapeste; reconciliação de saques por txid, endereço, valor líquido e horário; explicação de transferências internas, tarifas, 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 cadeia.