Cuentas de exchanges y de la nube como evidencia

La mayoría de las investigaciones que comienzan en la cadena terminan en un servicio: un exchange que sabe quién retiró los fondos, una cuenta de la nube que contiene la copia de seguridad, una bandeja de entrada de correo electrónico llena de confirmaciones de depósitos. Los registros de estos proveedores suelen aportar la identidad y la intención que la cadena de bloques no puede mostrar. Pero una hoja de cálculo de un exchange no se autentica por sí sola: el examinador debe saber de dónde procede, si está completa, qué significa cada columna y si concuerda con la cadena. Esta lección aborda qué contienen los registros de los proveedores, cómo autenticarlos, cómo gestionar el acceso en vivo a las cuentas y cómo conciliar los datos de los proveedores con los datos en la cadena.

Qué contienen los registros de exchanges y custodios

Cómo solicitar los registros se explica en la lección Colaboración con proveedores de servicios; esta lección comienza cuando llega la respuesta. Una entrega habitual de registros de un exchange o custodio contiene:

Los registros pueden llegar de tres formas, con distinto peso probatorio. Las entregas de registros del proveedor responden a requerimientos legales y cuentan con la procedencia documentada por el proveedor. Las exportaciones del usuario, como los estados de cuenta descargados por un sospechoso o aportados por una víctima, se encuentran en dispositivos o se entregan y deben contrastarse con el proveedor. Las capturas en vivo son registros que un investigador recopila al iniciar sesión con autorización legal o consentimiento. Un hallazgo debe indicar en cuál de estos tipos se basa.

Autenticación de los registros del proveedor

Autenticar significa demostrar que un registro es lo que afirma ser y que no ha cambiado desde que se generó.

1. Procedencia. Documente quién solicitó los datos, con qué autorización, a través de qué canal (un portal para autoridades policiales, una transferencia segura, un soporte físico), quién los recibió y cuándo.
2. Integridad en la recepción. Calcule de inmediato el hash de cada archivo entregado, conserve el original sin modificar y trabaje con copias. Si el proveedor facilita sus propios hashes, compárelos.
3. Declaración de autenticidad. Muchos proveedores pueden facilitar una declaración del custodio de los registros que describa cómo se crean y conservan los registros en el curso ordinario de su actividad. La necesidad de esta declaración y su forma dependen de la jurisdicción; solicitarla cuesta poco.
4. Significado. Obtenga un diccionario de datos: qué zona horaria utilizan las marcas de tiempo, si los importes son brutos o netos de comisiones, qué significa cada código de estado y cómo se muestran las transferencias internas.
5. Integridad del conjunto. Compruebe que se hayan entregado todos los períodos, cuentas, activos y tipos de registros solicitados, y que el saldo inicial más los movimientos sea igual al saldo final.

El software de hojas de cálculo provoca errores evitables. Los identificadores numéricos largos pueden convertirse a notación científica, pueden eliminarse los ceros iniciales, redondearse los importes y reinterpretarse las fechas según los formatos locales. Importe los archivos del proveedor como texto en una herramienta de análisis o una base de datos, realice las conversiones de forma deliberada y conserve los pasos de conversión.

Acceso en vivo a cuentas y registros de API

A veces, los investigadores acceden directamente a una cuenta: con el consentimiento de una víctima, con credenciales encontradas durante un registro legal o mediante la API de un exchange. Los datos a los que se accede de esta forma pueden estar almacenados en el extranjero. El artículo 32 del Convenio de Budapest permite a una parte acceder a datos almacenados en otra parte con el consentimiento lícito y voluntario de la persona legalmente autorizada para divulgarlos, así como acceder a datos de acceso público; fuera de esos supuestos, se aplican las vías de la lección Autorización legal y cooperación internacional. Cuando existe la posibilidad de obtener una orden de entrega de datos, esta suele ofrecer una procedencia más sólida que un inicio de sesión.

Si se utiliza el acceso en vivo, documéntelo como una actuación en vivo: grabación de pantalla de la sesión, la hora, la cuenta, cada exportación descargada con su hash y, para las llamadas a la API, el endpoint, los parámetros y la respuesta sin procesar guardada sin modificaciones. Tenga cuidado de no modificar la cuenta: no realice operaciones, no cambie la configuración, no restablezca la contraseña de forma que alerte al titular ni realice acciones que infrinjan los acuerdos de no divulgación del proveedor.

Conciliación de los registros del proveedor con los datos en la cadena

Un registro del proveedor y la cadena de bloques son dos fuentes independientes sobre los mismos hechos. Conciliarlos permite comprobar ambas fuentes, y un registro conciliado es mucho más difícil de impugnar que cualquiera de las dos fuentes por separado. La comprobación principal de los retiros une las filas del proveedor con los datos de la cadena de la propia unidad:

-- Conciliar los retiros del proveedor con las salidas en la cadena (tablas de tipo UTXO)
SELECT w.withdrawal_id, w.txid, w.to_address, w.amount_sat,  -- importe del estado de cuenta, convertido a satoshis al importar
       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 fila de retiro se vincula primero con la transacción mediante el txid, después con la salida que paga a la dirección indicada y, por último, con la hora confirmada de su bloque. Las uniones de tipo LEFT JOIN conservan las filas del proveedor que no tienen coincidencia, y la expresión CASE las clasifica en categorías explicables en lugar de descartarlas. La salida contiene el importe neto tras descontar la comisión de retiro del proveedor, mientras que la consulta compara el importe tal como figura en el estado de cuenta; determinar si esa cifra es bruta o neta requiere consultar el diccionario de datos, y una diferencia igual a la comisión es una diferencia explicada, no una discrepancia (W-102 más abajo). En las cadenas con modelo de cuentas, la unión con las salidas se convierte en una unión con las transferencias o los registros de transferencia de tokens, con un índice de registro en lugar de la salida.

Un ejemplo resuelto de conciliación de cinco retiros de una cuenta:

Cada fila termina con una coincidencia o una explicación. W-103 es un caso típico: las transferencias internas entre clientes del mismo servicio son asientos en el libro de movimientos del proveedor, por lo que los registros del proveedor son la única evidencia de ellas (véase la lección Rastreo a través de exchanges y servicios de custodia). W-104 muestra por qué una transacción por lotes no debe atribuirse en su totalidad a un solo cliente. Los depósitos se concilian del mismo modo, teniendo en cuenta que los proveedores posteriormente concentran los depósitos en billeteras calientes. Las diferencias horarias deben explicarse mediante la zona horaria del proveedor y el intervalo entre la solicitud, la difusión y la confirmación.

Cuentas de la nube como evidencia

Los servicios de la nube contienen lo que los usuarios quieren mantener seguro o sincronizado: fotos de frases semilla, copias de seguridad de billeteras, hojas de cálculo de direcciones, bóvedas de gestores de contraseñas, notas y correos electrónicos con notificaciones de exchanges sobre depósitos, retiros, inicios de sesión y pasos de KYC. Estos registros se obtienen y autentican igual que los de los exchanges: se preservan de forma temprana, se entregan con autorización legal, se calcula su hash al recibirlos y se comprueba que estén completos.

El ataque a Bitfinex de 2016 muestra el valor de combinarlos con los datos de la cadena. En virtud de una orden de registro, los investigadores obtuvieron un archivo de una cuenta de almacenamiento en la nube y lo descifraron. El archivo enumeraba unas 2.000 direcciones de moneda virtual con sus claves privadas. El análisis de la cadena de bloques vinculó casi todas esas direcciones con el robo y, el 31 de enero y el 1 de febrero de 2022, las autoridades incautaron unos 94.636 BTC de ellas. El archivo de la nube aportó pruebas de control y un vínculo con su titular; la cadena confirmó que las direcciones correspondían a los fondos robados. Ninguna de las dos fuentes por separado habría tenido el mismo peso.

Enfoque del examen: qué contienen los registros de los exchanges (KYC, libro de movimientos, depósitos, retiros, operaciones, registros de acceso, canales de moneda fíat) y el uso forense de cada uno; entregas de registros del proveedor frente a exportaciones del usuario y capturas en vivo; los cinco pasos de autenticación (procedencia, integridad en la recepción, declaración de autenticidad, significado, integridad del conjunto) y los riesgos de las hojas de cálculo; documentación del acceso en vivo y mediante API y la vía del consentimiento del artículo 32 del Convenio de Budapest; conciliación de retiros por txid, dirección, importe neto y hora; explicación de transferencias internas, comisiones, lotes y solicitudes canceladas; cuentas de la nube como fuentes de claves, copias de seguridad y notificaciones; el caso Bitfinex como ejemplo de combinación de evidencia de la nube y de la cadena.