Forense de Contratos Inteligentes

¿Qué es la forense de contratos inteligentes?

$60 millones en 3 horas. Eso fue lo que el atacante de The DAO extrajo en junio de 2016 explotando una vulnerabilidad de reentrancy en un smart contract de Ethereum. Aquel incidente forzó un hard fork de la red y creó Ethereum Classic como cadena alternativa. Casi una década después, la tendencia es justo la contraria y conviene decirlo con la fuente delante: según el Ecosystem Vulnerability Scoreboard de Immunefi, que mide seis años de pérdidas en protocolos DeFi, estas cayeron un 80 % desde el máximo de 2.620 millones de dólares en 2022 hasta 534 millones en 2024, y la pérdida mediana por incidente bajó de 6 a 1,5 millones. La propia clase de ataque que costó The DAO —reentrancy y manipulación de oráculos con flash loans— pasó de casi el 19 % de las pérdidas DeFi en 2022 a menos del 1 % en 2025. Lo que no ha bajado es la exposición en la capa custodia: los exchanges absorbieron más de 1.600 millones en 2025, encabezados por el robo a Bybit, que no fue un fallo del contrato sino de su cadena de aprobación de firmas. En España, el auge de las plataformas DeFi ha multiplicado las consultas a peritos informáticos especializados en blockchain, porque cada smart contract explotado deja un rastro forense inmutable: bytecode desplegado, transacciones de ataque, logs de eventos y flujos de fondos trazables.

La forense de contratos inteligentes es la rama del análisis forense digital que investiga smart contracts desplegados en redes blockchain (principalmente Ethereum, BNB Smart Chain, Polygon y Arbitrum) para determinar si contienen vulnerabilidades explotadas, puertas traseras intencionadas o lógica fraudulenta. El perito examina el código fuente (si esta disponible) o decompila el bytecode, reconstruye la secuencia de transacciones del ataque, y documenta la evidencia de forma admisible judicialmente.

Fundamentos técnicos de los smart contracts

Qué es un smart contract

Un smart contract es un programa informático autoejecutado que se despliega en una blockchain y cuya lógica se ejecuta automáticamente cuando se cumplen las condiciones programadas. A diferencia de un contrato legal tradicional, un smart contract no requiere intermediarios: el código es la ley.

Características forenses clave:

• Inmutabilidad: Una vez desplegado, el bytecode del contrato no puede modificarse (salvo contratos proxy/upgradeable).
• Transparencia: Todo el bytecode esta disponible públicamente en la blockchain.
• Determinismo: dado el contexto completo —los datos de la llamada, el estado del contrato y de aquellos con los que interactúa, y las variables del bloque como TIMESTAMP, BASEFEE o PREVRANDAO—, la ejecución se reproduce exactamente. Repetir solo la misma entrada en otro bloque no reproduce el resultado, y eso importa al peritar un exploit que dependa de oráculos o de préstamos flash: hay que fijar el bloque, no la llamada.
• Trazabilidad: Cada interacción con el contrato genera una transacción con timestamp inmutable.
• Eventos (logs): Los contratos emiten eventos que quedan registrados permanentemente y facilitan la reconstrucción cronológica.

Lenguajes y entornos

Relevancia forense: Immunefi desglosa sus pérdidas por cadena, no por lenguaje, y en su recuento las más golpeadas siguen siendo Ethereum y BNB Chain —ambas EVM, ambas Solidity—, con Solana ya en el mismo orden de magnitud una vez ajustado por valor bloqueado (≈0,42 %, 0,33 % y 0,42 % de pérdidas sobre TVL respectivamente en 2025). Para el perito eso significa dos cosas: que dominar el instrumental EVM cubre la mayor parte de los encargos, y que no basta, porque el material que llega a un despacho hoy incluye cadenas no EVM.

⚠️ Figuraba aquí que «el 85 % de los exploits documentados en 2024 afectaron a contratos escritos en Solidity», atribuido a Immunefi. Immunefi no publica ese corte: sus informes reparten por cadena y por clase de vulnerabilidad, nunca por lenguaje de programación.

Estructura de un smart contract Solidity

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract VaultExample {
    mapping(address => uint256) public balances;

    // Depositar fondos en el vault
    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    // Retirar fondos (version VULNERABLE a reentrancy)
    function withdraw() external {
        uint256 balance = balances[msg.sender];
        require(balance > 0, "No balance");

        // PELIGRO: Envio de ETH ANTES de actualizar balance
        (bool success, ) = msg.sender.call{value: balance}("");
        require(success, "Transfer failed");

        // Actualizacion de balance DESPUES del envio
        balances[msg.sender] = 0;
    }
}

En el ejemplo anterior, la función withdraw() envía ETH al usuario antes de actualizar su balance a cero. Este patron es la causa raiz de los ataques de reentrancy, como se detalla en la siguiente sección.

Vectores de ataque en smart contracts

1. Reentrancy (reentrada)

Descripción: El contrato atacante vuelve a llamar a la función de retirada durante la ejecución de la transferencia de fondos, antes de que el contrato víctima actualice el balance del atacante.

Mecanismo técnico:

// Contrato del atacante
contract ReentrancyAttacker {
    VaultExample public vault;

    constructor(address _vault) {
        vault = VaultExample(_vault);
    }

    // 1. Depositar fondos iniciales
    function attack() external payable {
        vault.deposit{value: msg.value}();
        vault.withdraw();
    }

    // 2. Funcion receive: se ejecuta al recibir ETH
    // Vuelve a llamar withdraw() ANTES de que el vault actualice el balance
    receive() external payable {
        if (address(vault).balance >= 1 ether) {
            vault.withdraw(); // Reentrancy: drena fondos repetidamente
        }
    }
}

Impacto histórico:

Detección forense: El perito busca patrones de llamadas recursivas en los traces de transacciones. En Etherscan, lo que delata la reentrada son varias llamadas internas a la misma función withdraw() dentro de una única transacción, anidadas bajo ella. Conviene no confundirlo con varios withdraw() en el mismo bloque: eso son usuarios distintos operando a la vez, y filtrar por bloque produce falsos positivos. La reentrada es intra-transacción, es un indicador claro de reentrancy.

2. Flash loan exploits (préstamos flash)

Descripción: Los flash loans permiten pedir prestadas cantidades enormes de criptomonedas sin colateral, siempre que se devuelvan en la misma transacción. Los atacantes los utilizan para manipular precios en pools de liquidez y drenar fondos de protocolos vulnerables.

Secuencia típica de ataque:

Transaccion unica (atomica):
  1. Pedir prestados 10M USDC via flash loan (Aave)
  2. Depositar 10M USDC en pool victima (inflando precio token X)
  3. Usar precio inflado para pedir prestado 5M en token Y
  4. Retirar fondos del pool victima
  5. Devolver flash loan + comision (Aave v3: 0,05 % segun su documentacion; el 0,09 % es la tarifa de v2)
  6. Beneficio neto: $2-5M

Casos relevantes:

Análisis forense: El perito decompila la transacción de ataque paso a paso usando herramientas como Tenderly o Phalcon (de BlockSec). Cada operación interna revela la secuencia exacta: el préstamo flash, la manipulación del pool, la extracción de fondos y la devolución del préstamo. Todo ocurre en una única transacción, lo que facilita la documentación pericial.

3. Manipulación de oráculos

Los protocolos DeFi dependen de oráculos (Chainlink, Band Protocol, Pyth) para obtener precios de activos externos. Si un atacante manipula el feed de precios, puede ejecutar operaciones a precios falsos.

Ejemplo: Un atacante manipula el precio del token X en un pool de baja liquidez que el oraculo utiliza como referencia. El protocolo víctima, que usa ese oraculo para calcular colateral, permite al atacante pedir prestado mucho más de lo que debería.

4. Errores de lógica y puertas traseras

Funciones privilegiadas ocultas:

// Funciones que un perito busca como red flags:
function mint(uint256 amount) public onlyOwner { ... }     // Crear tokens ilimitados
function pause() public onlyOwner { ... }                   // Bloquear transferencias
function setFee(uint256 fee) public onlyOwner { ... }       // Subir comisiones al 100%
function emergencyWithdraw() public onlyOwner { ... }       // Retirar TODOS los fondos
function blacklist(address user) public onlyOwner { ... }   // Impedir que un usuario venda
function upgradeTo(address impl) public onlyOwner { ... }   // Cambiar toda la logica

Contratos proxy (upgradeable): Merecen atención especial. Un contrato proxy permite al propietario cambiar toda la lógica del contrato sin que los usuarios lo noten. Un proyecto puede pasar una auditoría con código limpio y luego actualizar la implementación con una puerta trasera.

Metodología forense: como investigar un smart contract

Herramientas forenses para smart contracts

Herramientas de exploración y verificación

Herramientas de decompilacion

Herramientas de debugging y simulación

Herramientas de análisis estático

Caso práctico: exploit de reentrancy en protocolo DeFi

Contexto: Un protocolo de lending en Ethereum pierde 420 ETH (aproximadamente 950.000 euros) cuando un atacante explota una vulnerabilidad de reentrancy en la función de retirada de fondos.

Cronología del ataque:

Bloque N (hora de bloque H):
  1. Atacante despliega contrato malicioso: 0xAttacker...
  2. Deposita 10 ETH en el protocolo victima
  3. Llama withdraw() desde contrato malicioso
  4. Funcion receive() del contrato atacante re-llama withdraw()
  5. Ciclo se repite 42 veces en una sola transaccion
  6. Total extraido: 420 ETH (42 x 10 ETH)
  7. Balance del atacante pasa de 10 ETH a 420 ETH

Bloque N+2 (H + 24 s):
  8. Atacante transfiere 420 ETH a wallet intermedia: 0xInter...

Bloque N+66 (H + 13 min):
  9. 250 ETH enviados a Tornado Cash (mixing)
  10. 170 ETH enviados a exchange centralizado (Binance)

Resultado trazabilidad:
  - Fondos enviados a un mezclador: prácticamente irrecuperables
  - Fondos enviados a un exchange centralizado: quedan sujetos a lo que ese exchange decida,
    que depende de su jurisdicción, de su política y de si media requerimiento judicial.
    Ni el bloqueo ni la identificación por KYC son automáticos, y este escenario
    NO afirma que se produjeran ni en qué proporción se recuperó nada.

Qué haría el análisis forense en un caso así:

1. Decompilación del contrato atacante: se descarga el bytecode de Etherscan y se decompila con Heimdall, buscando en la función receive() la llamada recursiva a withdraw().

2. Depuración de la transacción: en Tenderly se reproduce la transacción paso a paso, para comprobar si el balance se actualiza antes o después de la llamada externa —que es donde vive la reentrada—.

3. Trazabilidad de fondos: se sigue el rastro hasta ver si alguna wallet fue financiada desde un exchange con KYC, que es el punto donde la investigación puede dejar de ser anónima. Requiere herramientas de licencia comercial, y hay que declararlo.

4. Informe pericial: huellas de las transacciones, capturas del depurador, código decompilado anotado y trazabilidad de los fondos, separando lo reproducible con un nodo de lo que se apoyó en servicios de pago.

Marco legal en España

Código Penal

Art. 197 bis CP - Interceptación de comunicaciones informáticas: La explotación de vulnerabilidades en smart contracts puede tipificarse como acceso ilícito a sistemas informáticos cuando el atacante accede sin autorización a la lógica del contrato para drenar fondos.

Art. 248-251 CP - Estafa: Cuando el desarrollador de un smart contract incluye intencionadamente puertas traseras o lógica fraudulenta (como funciones ocultas onlyOwner para drenar fondos), el despliegue del contrato constituye el “engaño bastante” requerido por el tipo penal de estafa. Penas de 1 a 6 años si la cuantía supera 50.000 euros.

Art. 264 CP - Daños informáticos: La explotación de vulnerabilidades que causa destrucción o alteración de datos en smart contracts (por ejemplo, vaciando el balance de un protocolo) puede constituir daño informático. Pena de 6 meses a 3 años.

Art. 301 CP - Blanqueo de capitales: El uso de mixers (Tornado Cash), bridges cross-chain y privacy coins para ocultar el destino de fondos robados de smart contracts constituye blanqueo. Pena de 6 meses a 6 años.

Reglamento MiCA (UE 2023/1114)

El Reglamento de Mercados de Criptoactivos, en aplicación plena desde diciembre de 2024, establece requisitos de transparencia para emisores de criptoactivos. Aunque los protocolos DeFi verdaderamente descentralizados quedan en un área gris, los smart contracts desplegados por entidades identificables deben cumplir con requisitos de información y gobernanza.

Admisibilidad de la evidencia forense de smart contracts

Lo que hace peritable un smart contract, y que el tribunal valorará por sana crítica conforme al art. 348 LEC como cualquier otro dictamen:

• Inmutabilidad del bytecode: El código desplegado en blockchain no puede ser alterado retroactivamente, garantizando la integridad de la evidencia.
• Verificabilidad publica: Cualquier tercero (juez, fiscal, perito contrario) puede verificar las transacciones y el bytecode accediendo a un nodo Ethereum.
• Orden temporal verificable: cada transacción queda en un bloque con su marca de tiempo, y el orden entre bloques es comprobable por cualquiera. Conviene decirlo con precisión: esa marca la fija el proponente del bloque dentro de los márgenes que el protocolo admite, y no es un sello de tiempo cualificado como el del art. 42 del Reglamento eIDAS. Sirve para ordenar hechos, no como acreditación notarial de la hora.
• Lo que la cadena NO cubre: acredita lo ocurrido on-chain, y hasta ahí llega. No documenta cómo el perito obtuvo esa información, con qué herramienta, cuándo la copió ni cómo la trasladó al dictamen, que es precisamente lo que registra una cadena de custodia. Llamarla «registro notarial» sobra: no hay fedatario, y la marca de tiempo la fija el proponente del bloque.

Relación con otros conceptos

• Blockchain Forense: La forense de smart contracts es una subespecialidad del blockchain forense. Mientras que el blockchain forense general se centra en trazar transacciones y flujos de fondos, la forense de smart contracts analiza la lógica interna del código que origino el fraude o exploit.

• Chainalysis: Herramienta complementaria fundamental. Mientras el perito analiza el smart contract (el “como” del ataque), Chainalysis traza los fondos robados (el “adonde” fueron) para facilitar la recuperación.

• DeFi (Finanzas Descentralizadas): Los protocolos DeFi son el principal escenario donde se aplica la forense de smart contracts. Lending protocols, DEX, bridges y yield farms son los objetivos más frecuentes de exploits.

• Rug pull cripto: Un rug pull es un caso específico donde el desarrollador del smart contract incluye intencionadamente funciones maliciosas. La forense de smart contracts permite demostrar que el fraude fue premeditado analizando el código desplegado.

FAQ

P: ¿Se puede analizar un smart contract si el código fuente no esta verificado en Etherscan? R: Si. El bytecode desplegado en la blockchain es público e inmutable. Herramientas como Heimdall, Dedaub y Panoramix permiten decompilarlo a pseudocodigo Solidity legible. Ahora bien, el decompilado es una reconstrucción con pérdidas: no recupera nombres, comentarios ni tipos originales, y con código optimizado o con transient storage puede no reconstruir todo el flujo. Sirve para razonar sobre el comportamiento del contrato, y sobre eso hay que ser explícito en el dictamen: se peritó el bytecode desplegado, cuyo hash sí es verificable, apoyándose en un decompilado que es una interpretación. En un dictamen conviene decir exactamente eso: qué se analizó (el bytecode, con su huella) y con qué apoyo (un decompilado, que es una lectura).

P: ¿Cuanto tiempo tiene un perito para actuar tras un exploit de smart contract? R: Las primeras 24-48 horas son críticas. No para el análisis del contrato (el bytecode es inmutable y puede analizarse en cualquier momento), sino para la trazabilidad de fondos: si el atacante mueve los fondos a un mixer o los retira de un exchange antes de que se solicite el bloqueo judicial, la recuperación se complica enormemente.

P: ¿Puede un smart contract auditado ser explotado? R: Si. Las auditorias reducen el riesgo pero no lo eliminan. Algunas vulnerabilidades solo se manifiestan en la interacción entre múltiples contratos, o dependen de condiciones de mercado específicas (como los flash loan attacks). Además, los contratos upgradeable pueden ser modificados después de la auditoría.

P: ¿Un perito informático puede ratificar en juicio un informe sobre smart contracts? R: Si. El perito debe ser capaz de explicar al tribunal, de forma comprensible, la lógica del smart contract, como se exploto la vulnerabilidad, y como se trazaron los fondos. La documentación con capturas de Etherscan, diagramas de flujo y debugging paso a paso facilita esta explicación.

Referencias y Fuentes

1. Immunefi. The Ecosystem Vulnerability Scoreboard: 6 Years of DeFi Loss Data — serie 2020-2025 de pérdidas en protocolos DeFi, normalizada por TVL. Es la fuente de las cifras de este artículo. Advierte expresamente de su propio alcance: separa los fallos de exchanges y custodios de los fallos de protocolo, porque mezclarlos «distorsionaría el panorama». Sus informes periódicos cubren trimestres concretos y no son intercambiables entre sí.

2. Chainalysis. (2025). “The 2025 Crypto Crime Report”. chainalysis.com — Análisis de tendencias en hackeos de smart contracts y trazabilidad de fondos robados.

3. Trail of Bits. (2025). “Slither: Static Analysis Framework for Solidity”. github.com/crytic/slither — Framework open source de análisis estático para detectar vulnerabilidades en contratos Solidity.

4. OpenZeppelin. Contracts — documentación de la librería — implementaciones auditadas de los estándares ERC y utilidades de seguridad, referencia de facto en desarrollo de contratos.

5. Solidity. Documentación oficial del lenguaje — mantenida por el equipo de Solidity, no por la Ethereum Foundation.

6. ConsenSys Diligence. (2024). “Ethereum Smart Contract Security Best Practices”. consensys.github.io/smart-contract-best-practices — Catálogo de vulnerabilidades conocidas y patrones de prevención.

7. Rekt News. (2025). “DeFi Exploits Leaderboard”. rekt.news/leaderboard — Ranking actualizado de los mayores hackeos y exploits DeFi por cantidad robada.

8. Parlamento Europeo. (2023). “Reglamento (UE) 2023/1114 relativo a los mercados de criptoactivos (MiCA)”. eur-lex.europa.eu — Marco regulatorio europeo para criptoactivos.

9. Código Penal español. Arts. 197 bis (acceso ilícito), 248-251 (estafa), 264 (daños informáticos), 301 (blanqueo de capitales). boe.es

10. BlockSec. (2025). “Phalcon: Transaction Analysis and Debugging”. blocksec.com/phalcon — Herramienta de visualizacion de flujo de fondos en transacciones complejas de smart contracts.

11. Tenderly. Transaction Debugger — permite reproducir paso a paso la ejecución de una transacción, útil para reconstruir un exploit.

12. SlowMist. (2025). “Blockchain Security and AML Analysis Annual Report 2024”. slowmist.com — Análisis técnico de los principales exploits de smart contracts del año.

Última actualización: 10 Febrero 2026 Categoría: Técnico (SMC-001) Nivel técnico: Avanzado Relevancia forense: MUY ALTA (smart contracts como vector principal de fraude cripto)