Qué es el análisis forense de criptoactivos

Toda investigación de criptoactivos produce vínculos y cifras, pero solo algunos de ellos pueden tener peso en un tribunal, una solicitud de inmovilización de activos o una reclamación en un procedimiento de insolvencia. El análisis forense de criptoactivos es la disciplina que permite obtener hallazgos sobre los flujos, las tenencias y el control de activos digitales de una manera que otra persona cualificada pueda comprobar, repetir y cuestionar. Cada hallazgo se basa en datos que alguien recuperó, decodificó e interpretó; un examinador que no puede indicar qué nodo produjo los datos, qué software los decodificó y de quién eran las etiquetas aplicadas no puede defender el hallazgo. Esta lección expone qué hace que un trabajo sea forense, para qué casos sirve, quién lo realiza y qué aporta cada capa de datos de la cadena de bloques.

Trabajo analítico y trabajo forense

Los mismos datos de la cadena de bloques permiten realizar dos tipos de trabajo. El trabajo analítico responde a preguntas con la rapidez necesaria para actuar: qué exchange recibió un depósito, cuál es la exposición de un cliente a un mezclador, si una billetera sigue activa. Admite supuestos de trabajo, utiliza la herramienta más rápida y se evalúa por su utilidad. El trabajo forense responde a preguntas conforme a un estándar probatorio: el hallazgo se basa en datos de origen preservados, se obtiene mediante un método explícito, se registra de modo que pueda reproducirse y se expresa con sus limitaciones. Se evalúa por su capacidad para resistir el escrutinio de un perito de la parte contraria y del tribunal.

La mayoría de los casos comienzan como trabajo analítico y pasan a ser forenses cuando una decisión con consecuencias jurídicas depende de ellos. La trampa consiste en trasladar atajos analíticos, como una etiqueta no verificada o una regla de rastreo no documentada, al ámbito probatorio. Las unidades que trabajan bien tratan cada caso como potencialmente forense desde su recepción, porque reconstruir la procedencia después es lento y, a veces, imposible.

Reproducible, documentado, defendible

Tres criterios distinguen un hallazgo forense de una opinión.

Reproducible. Otro examinador, con las mismas fuentes y el mismo método, llega al mismo resultado. En una cadena de bloques pública, esto es excepcionalmente viable: cada txid, bloque e importe puede recuperarse de nuevo desde un nodo independiente. Lo que no es automáticamente reproducible es la interpretación añadida: una heurística de agrupación, una etiqueta de terceros, un método de rastreo. ISO/IEC 27037 menciona la repetibilidad (mismo método, mismo entorno, mismo resultado) y la reproducibilidad (mismo método, distintas herramientas o condiciones, mismo resultado), junto con la auditabilidad y la justificabilidad, como cualidades que debe tener el manejo de pruebas digitales.

Documentado. Cada paso se registra en el momento en que se realiza: qué se consultó, en qué fuente, con qué versión de la herramienta, a qué hora en UTC y qué se obtuvo. Si el registro no muestra un paso, quien lo revise debe asumir que no ocurrió tal como se describe. La lección 8.3 aborda los aspectos prácticos.

Defendible. El método se ajusta a la pregunta, se indican sus debilidades conocidas, se consideraron alternativas y la conclusión no va más allá de las pruebas. Un hallazgo defendible anticipa las preguntas que hará un perito de la defensa (lección 8.4).

Un hábito útil es separar tres capas en cada afirmación:

• observación: lo que muestra la cadena o un registro;
• inferencia: lo que el examinador concluye a partir de ello y mediante qué método;
• supuesto: lo que se da por hecho, como la exactitud de una etiqueta.

Qué investiga el análisis forense de criptoactivos

Las técnicas son comunes, pero cada tipo de caso tiene puntos de partida (semillas), preguntas y puntos de llegada típicos.

Los casos públicos muestran esta variedad. Tras el ataque de ransomware contra Colonial Pipeline en 2021, los investigadores rastrearon el rescate de 75 BTC y recuperaron unos 63,7 BTC que se encontraban en una dirección. En el ataque a Bitfinex de 2016, los investigadores siguieron unos 119.754 BTC robados durante varios años y, en 2022, recuperaron más de 94.000 BTC tras descifrar un archivo en una cuenta de almacenamiento en línea que contenía claves privadas. En ambos casos, el rastreo fue solo una parte: el resto consistió en actuaciones jurídicas, pruebas de dispositivos y de la nube, y documentación que hizo utilizables los hallazgos.

Roles en una investigación de criptoactivos

Los responsables de respuesta a incidentes de exchanges y protocolos suelen realizar el trabajo de las primeras horas tras un robo. Sus notas y exportaciones se convierten después en pruebas, por lo que necesitan la misma disciplina. Un perito designado por el tribunal trabaja para el tribunal, no para ninguna de las partes.

En unidades pequeñas, una persona puede desempeñar varios roles, lo cual es viable si cada producto registra qué rol lo produjo. Un producto de inteligencia puede basarse en fuentes sensibles y no está redactado para el tribunal; copiarlo en una declaración probatoria es un motivo frecuente por el que los hallazgos se excluyen o reciben escaso valor probatorio.

De dónde proceden los datos de la cadena de bloques

Los datos de la cadena de bloques se presentan en tres capas, cada una construida sobre la inferior.

Los datos sin procesar del nodo son la referencia de base: todo nodo completo honesto de la misma cadena devuelve los mismos bytes para el mismo hash de bloque. Los datos decodificados solo son tan fiables como el decodificador, que debe conocer el tipo de script o la interfaz del contrato (su ABI). Los datos enriquecidos añaden criterio: precios de un mercado elegido, etiquetas de una fuente elegida, agrupaciones basadas en heurísticas elegidas. Cuanto más alta es la capa, más útiles son los datos y más supuestos incorporan.

Nodos, proveedores, exploradores y almacenes de datos

Lo que puede responder un nodo completo depende de lo que conserve. Bitcoin Core necesita el índice opcional de transacciones (txindex=1) para buscar cualquier transacción confirmada por txid y no tiene índice de direcciones, por lo que los historiales de direcciones necesitan un indexador independiente (entre los ejemplos de código abierto están Electrs, Fulcrum y Esplora). Un nodo completo de Ethereum con la configuración predeterminada conserva el estado (saldos, almacenamiento de contratos) solo para bloques recientes, aproximadamente los últimos 128 con el almacenamiento basado en rutas predeterminado de Geth; los saldos históricos y la mayor parte del rastreo de transacciones antiguas requieren un nodo de archivo. Desde julio de 2025, los principales clientes de ejecución de Ethereum también admiten la caducidad parcial del historial conforme a EIP-4444, lo que permite a un nodo eliminar los cuerpos y recibos anteriores a la fusión (antes de septiembre de 2022), conservando todas las cabeceras. La lección 2.1 aborda las API de los nodos.

Los proveedores RPC operan nodos por usted, y usted hereda su configuración, sus límites de solicitudes y sus errores. Un explorador de bloques es adecuado para una primera revisión, pero no para basarse exclusivamente en él: sus métodos rara vez están documentados, sus etiquetas se aplican de forma retroactiva a transacciones antiguas y los exploradores discrepan en cifras derivadas, como las transacciones internas y los saldos de tokens. Un almacén de datos (una base de datos columnar de datos indexados de la cadena) responde a preguntas sobre muchas transacciones, pero su calidad depende del proceso ETL que lo alimentó. Un flujo de trabajo sólido utiliza un explorador para orientarse, un almacén de datos para trabajar a escala y un nodo para verificar las transacciones concretas de las que depende un hallazgo (lección 2.7).

Un ejemplo resuelto: un pago, dos tipos de respuesta

Una víctima denuncia un pago de 3,0 ETH a una plataforma de inversión falsa. Un analista abre una herramienta de rastreo y escribe: "Los fondos fueron a Exchange K". Eso es una pista. La versión forense dice:

Hallazgo F-03

• Observación: el txid 0x9c1e…44ab (bloque 19.204.124, 2024-02-11 10:06:59 UTC) transfirió 3,0 ETH de la dirección de la víctima 0x5D0f…a1C2 a 0xA1b2…9F.
• Observación: 0xA1b2…9F envió 2,98 ETH a 0x77cd…e310 en el txid 0x41b0…7d2e (bloque 19.204.160). Posteriormente, 0x77cd…e310 transfirió la totalidad de su saldo a 0xE3f9…08B1.
• Inferencia: 0x77cd…e310 es una dirección de depósito de Exchange K. Fundamento: la transferencia de la totalidad del saldo a 0xE3f9…08B1, que dos fuentes independientes etiquetan como una billetera caliente de Exchange K (capturas S-07 y S-08).
• Supuesto: las etiquetas de S-07 y S-08 son exactas.
• Grado: observaciones A, registradas en la cadena (verificadas de nuevo en un nodo propio, 2024-03-02); atribución de la dirección de depósito C, un único indicador (la transferencia de la totalidad del saldo) basado en etiquetas de terceros, que subiría a B si los registros de Exchange K la confirman.

Cualquiera puede volver a comprobar las observaciones en la cadena. La inferencia identifica su fundamento, el supuesto se declara en lugar de ocultarse y la línea del grado indica qué cambiaría la conclusión: los registros del exchange (la lección 3.2 desarrolla la gradación).

La definición de los datos importa tanto como lo anterior. Al preguntar cuánto ETH recibió 0xA1b2…9F en febrero de 2024, tanto la lista de transacciones de un explorador como una consulta del almacén de datos sobre la tabla transactions suman 41,20 ETH, mientras que una consulta que añade las llamadas internas de la tabla traces suma 53,70 ETH. Ninguno de los resultados es incorrecto. Los dos primeros cuentan solo las transacciones de nivel superior con la dirección en el campo to; los 12,50 ETH adicionales llegaron mediante llamadas a contratos (un retiro desde una billetera de contrato inteligente) visibles solo en las trazas. Incluir ETH envuelto, un token visible solo en los registros de eventos, daría otra respuesta; contar las llamadas revertidas, que las trazas registran pero que no transfirieron nada, daría una respuesta incorrecta. "53,70 ETH recibidos como valor nativo en los bloques X a Y, incluidas las transferencias internas exitosas y excluido WETH" es una respuesta que otro examinador puede reproducir.

Hábitos de reproducibilidad

Lo que impide la reproducibilidad rara vez es la capa sin procesar, que no cambia una vez alcanzada la finalidad. Es todo lo que la rodea:

• Referencias cambiantes. "El más reciente" cambia cada pocos segundos. Vincule cada consulta a una altura de bloque y registre el hash de ese bloque.
• Fuentes no registradas. Anote el nodo o proveedor, el cliente y su versión, así como la versión del conjunto de datos y de la tabla.
• Transformaciones no registradas. Conserve la consulta o el script exactos, incluidos los filtros y las conversiones de unidades.
• Etiquetas mutables. Registre la fuente de cada etiqueta y la fecha en que la consultó; las etiquetas se revisan.
• Datos no finalizados. Los bloques recientes pueden ser reemplazados (lección 2.1).

Un hallazgo basado en "el explorador lo decía el martes pasado" no puede comprobarse; uno basado en un hash de bloque identificado, una consulta guardada y una versión de cliente registrada puede comprobarlo cualquiera que tenga un nodo. La lección 2.6 convierte estos hábitos en un registro de procedencia.

Enfoque del examen: deberá distinguir el trabajo analítico del forense, reconocer que el estándar probatorio exige que sea reproducible, documentado y defendible, y conocer las cualidades de ISO/IEC 27037 (repetibilidad, reproducibilidad, auditabilidad, justificabilidad). Prepárese para clasificar afirmaciones como observación, inferencia o supuesto, relacionar los tipos de caso con sus semillas y puntos de llegada, distinguir los roles y explicar por qué los productos de inteligencia no deben incluirse en las declaraciones probatorias. En cuanto a los datos: las tres capas y sus supuestos, txindex y la ausencia de un índice de direcciones, los nodos de archivo para el estado histórico, EIP-4444, por qué las transferencias nativas, internas y de tokens dan totales distintos, y la vinculación de las consultas a una altura y un hash de bloque.