Unas pruebas de penetración (pentest) en blockchain adversarias y manuales amplían el pentest convencional de cloud y web para cubrir las rutas de firma, aprobación, retirada y flujo de fondos que un atacante podría aprovechar para mover dinero.
Un pentest convencional suele evaluar cloud, web, APIs, identidad y operaciones. Las pruebas de penetración en blockchain llevan ese enfoque a la intención de firma, los controles de aprobación y retirada, la lógica de fondos y la ejecución on-chain, y comprueban si las debilidades de todos ellos pueden encadenarse en una ruta reproducible hasta los fondos.
Frontend e intención de firma
Controles de aprobación y retirada
Lógica de fondos
Ejecución on-chain
01/ 04
La infraestructura de soporte y los agentes de IA operativos pueden entrar en el alcance cuando contribuyen a una ruta hacia los fondos acordada. La garantía sobre el código de los contratos corresponde al Code Audit correspondiente; la corrección de la custodia de claves con MPC, TSS y TEE, a Wallet Security Audit; la resiliencia profunda de nodos, clústeres y RPC, a Blockchain Security Testing; y los sistemas agénticos del lado del pago, a Agentic Payment Security Audit.
Cada proyecto sigue cuatro pasos controlados: definir el alcance y las hipótesis de acceso, ejecutar los escenarios de ataque acordados, informar de los hallazgos con evidencias y volver a probar las correcciones. Unas Rules of Engagement por escrito fijan las salvaguardas antes de empezar.
Alineamos objetivos, arquitectura, flujos de fondos, entornos objetivo y límites de autorización. Las Rules of Engagement definen las técnicas permitidas, las actividades prohibidas, las salvaguardas en producción, los criterios de comunicación y de parada, y si la ingeniería social, el acceso físico, la persistencia o el movimiento lateral entran en el alcance.
El alcance, el calendario, los entregables y un presupuesto a medida se confirman tras el descubrimiento técnico.
Mapeamos los activos expuestos, las identidades, las relaciones de confianza, los flujos de firma y aprobación y las dependencias on-chain. Después acordamos la posición de partida del tester —externo, autenticado, privilegiado, con un proveedor comprometido o dando por hecha una brecha— y seleccionamos los escenarios que podrían llegar a acciones que mueven dinero.
Dentro de las salvaguardas acordadas, ejecutamos los escenarios de ataque autorizados sobre las superficies seleccionadas, encadenamos debilidades cuando procede y determinamos si producen un impacto reproducible. Los hallazgos se trian para distinguir las rutas explotables del comportamiento esperado, y los problemas críticos se comunican por el canal de escalado acordado.
Entregamos un informe que vincula cada ruta confirmada con evidencia reproducible, el control que falló, el impacto de negocio, la severidad y una remediación accionable. Una vez aplicadas las correcciones, volvemos a probar los hallazgos acordados y documentamos si las rutas de ataque demostradas dejan de ser reproducibles en las condiciones del retest.
Las pruebas son puntuales en el tiempo y están acotadas al alcance. No garantizan una brecha ni un descubrimiento exhaustivo; las rutas explotables confirmadas se documentan con evidencia reproducible.
From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing
De dónde salen realmente las pérdidas y qué reguladores ya exigen pruebas.
What Is Blockchain Penetration Testing? Definitions and Boundaries
La definición, el modelo de amenazas del manejo de fondos y las cinco capacidades conectadas.
Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing
Autoridad, límites operativos, controles de flujos sensibles, criterios de parada y retest.
Web3 Attack Surfaces: A Penetration Testing Overview
El modelo de cuatro componentes de una institución y las cinco superficies de ataque que expone.
Las pruebas de penetración en blockchain, también llamadas web3 penetration testing, son una evaluación adversaria y manual de un sistema en funcionamiento, realizada dentro de un entorno y unas reglas de compromiso acordados, para validar rutas explotables y cadenas de control.
Rastrean rutas completas, no debilidades aisladas. Complementan a una auditoría de seguridad a nivel de código y también pueden contratarse por separado.
Porque las pérdidas más graves se originan cada vez más fuera del smart contract: en la firma, la custodia, las claves, las personas y la cadena de suministro.
En nuestro propio seguimiento de 2026 (pérdidas superiores a 100 000 $), los fallos ajenos a la capa de contratos supusieron aproximadamente uno de cada ocho incidentes, pero más de tres cuartas partes de las pérdidas.
Una auditoría de código examina el código; la monitorización a nivel de transacción examina las transacciones cuando llegan a la cadena. Ninguna de las dos reconstruye la ruta que las une.
El ataque a Bybit de 2025 es un ejemplo: una interfaz de firma manipulada convirtió la propia aprobación de los operadores en una transferencia que nunca quisieron hacer, y tanto el contrato como su auditoría y la monitorización podían leer esa transferencia como legítima.
Más análisis de incidentes de BlockSec: una clave de API robada en un canal oficial de actualizaciones, el fallo del generador de direcciones Profanity, un fallo de entropía en un monedero hardware.
La diferencia está en el objetivo de aseguramiento.
Una auditoría de código genera confianza en el código, incluidos el diseño, la arquitectura y las hipótesis del protocolo. Un pentest establece si las condiciones reales de un entorno institucional en funcionamiento pueden encadenarse hasta producir un impacto reproducible.
Una auditoría por sí sola no produce evidencia de explotabilidad en tiempo de ejecución a escala de toda la institución, y un pentest no sustituye al aseguramiento a nivel de código. Los métodos se solapan y los equipos pueden trabajar juntos.
Las pruebas de penetración tradicionales siguen siendo valiosas en cloud, web, API, identidad y accesos privilegiados. Lo que suelen no tener es la semántica de negocio propia de cripto: una firma puede autorizar un movimiento de valor irreversible, y aprobar una retirada es una decisión de control de fondos, no el envío de un formulario.
Un tester puede encontrar un bypass de autenticación y aun así no ver cómo se combina con una discrepancia en lo que se muestra al firmar o con una política de aprobación débil para formar una ruta hasta los fondos.
Un test convencional demuestra impacto sobre los controles de TI; este trata el movimiento de valor como condición final. La diferencia viene del criterio especializado en seguridad web3, no de herramientas nuevas.
Para un conjunto concreto de entidades autorizadas, sí. La obligación es condicional, no universal, y el alcance, la periodicidad y las reglas de independencia varían según el mercado.
Los reguladores exigen pruebas de penetración; no nombran una categoría comercial concreta. Lo que hace especialista a un test son los sistemas incluidos en el alcance: cuando esos sistemas autorizan, firman, custodian o contabilizan valor cripto, probarlos como es debido exige soltura con los flujos de firma y de fondos.
Estos ejemplos son ilustrativos y no constituyen asesoramiento jurídico. Cada institución debe confirmar con sus abogados su propia calificación, sus exenciones y sus obligaciones.
El alcance se acuerda caso por caso. Puede incluir cloud, web, API, identidad y operación en producción siempre que conecten con una ruta hacia los fondos. Además probamos cuatro partes conectadas de la cadena de manejo de fondos en Web3:
El aseguramiento del código de los contratos sigue siendo competencia del Code Audit correspondiente.
Solo con autorización por escrito y salvaguardas acordadas, recogidas en un documento de Rules of Engagement antes de empezar.
Las RoE separan lo que está dentro del alcance de la actividad que está permitida: un servicio de retiradas en producción puede estar dentro del alcance para validar la ruta de autorización, mientras que las retiradas reales de clientes, la exportación de claves privadas, la persistencia y los ataques que generan carga siguen prohibidos.
Para los flujos de firma y retirada, los escenarios controlados especifican monederos designados, destinos en lista de permitidos y un valor máximo de prueba, quiénes participan en la aprobación y la conciliación entre la actividad on-chain, los asientos contables y los saldos.
Con el responsable del servicio se acuerdan criterios de parada medibles, un canal de seguridad protegido y una autoridad designada para pausar o reanudar. La institución conserva la autoridad sobre las decisiones de producción, la comunicación a clientes y la remediación.
Recibes cada ruta confirmada con evidencia reproducible, severidad y pautas de remediación, además del retest de las correcciones acordadas.
El registro final vincula cada hallazgo con su evidencia, su impacto, su responsable, su plan de remediación y su condición de retest. Al cierre, retiramos las identidades y permisos temporales de prueba, y la evidencia se conserva solo durante el periodo acordado.
Los entregables y el acuerdo de retest se confirman en cada proyecto.
No. La evaluación es metódica, guiada por evidencias y puntual en el tiempo: sus conclusiones se aplican a los sistemas, versiones, configuraciones e hipótesis de acceso que se probaron.
Un trabajo sistemático sobre la superficie acordada no puede garantizar que se descubran todas las debilidades o rutas de ataque, ni que los testers logren una brecha. Examinamos rutas potenciales y documentamos con evidencia reproducible las que se confirman explotables.
Un pentest no puede garantizar la prevención, ni puede demostrar que habría detenido un incidente pasado concreto.
Empieza por tres preguntas: ¿Qué sistemas mueven fondos? ¿Qué evidencia de aseguramiento existe ya? ¿Qué cadena de control no se ha validado todavía de forma adversaria? Las respuestas identifican la brecha de aseguramiento sin elegir prematuramente un servicio por su nombre.
Después, una conversación de alcance alinea el objetivo, las hipótesis de acceso, las salvaguardas en producción y los entregables esperados.
BlockSec no publica precios fijos; el alcance, el calendario, los entregables y un presupuesto a medida se facilitan a petición tras el descubrimiento técnico.
