De incidentes a regulación: por qué las instituciones cripto necesitan pruebas de penetración en blockchain

Para instituciones y proveedores de servicios de criptomonedas—incluyendo exchanges de criptomonedas, empresas de pagos, custodios de activos digitales y proveedores de wallets custodiales y no custodiales—las pruebas de penetración en blockchain no son, para aquellos dentro del alcance, una precaución opcional. Cuando un compromiso puede alcanzar la firma o los fondos, o cuando las normas aplicables exigen validación adversarial, constituyen una capa necesaria de garantía. El argumento se sostiene sobre dos pilares: el origen del riesgo más allá del código del contrato, y los requisitos o expectativas regulatorias de validación adversarial.

La exposición institucional se extiende más allá de los errores en los contratos, abarcando la firma, la custodia, las claves, las personas, las cadenas de suministro y la infraestructura [1]. Como tal, esta superficie no está completamente cubierta por las soluciones conocidas de seguridad web3—auditoría a nivel de código y monitoreo a nivel de transacciones—ni por las pruebas de penetración tradicionales por sí solas. Esto se aplica a cualquier institución donde una persona, proveedor, interfaz o aplicación pueda influir en lo que se firma, aprueba, acredita o mueve—incluso cuando la custodia se subcontrata. Al mismo tiempo, los reguladores en varios mercados imponen requisitos, obligaciones condicionales o expectativas de supervisión con distintos alcances, frecuencias y reglas de independencia.

Este artículo abre nuestra serie sobre pruebas de penetración en blockchain. A lo largo de la serie, "blockchain penetration testing" y "web3 penetration testing" se refieren a la misma disciplina: usamos el primero como término principal y el segundo como su sinónimo común en la industria. Presenta el argumento general y de alto nivel sobre su necesidad; artículos posteriores definirán la disciplina, sus límites operativos y la superficie de ataque institucional en detalle.

Parte 1: De dónde proviene el riesgo

1.1 Riesgo más allá del contrato inteligente

Las vulnerabilidades de los contratos inteligentes siguen siendo importantes, pero muchas de las mayores pérdidas recientes se originaron en otros lugares, particularmente en las claves, los sistemas de firma y la infraestructura operativa. En 2024, los atacantes robaron aproximadamente 305 millones de dólares de DMM Bitcoin comprometiendo a un proveedor de software de wallets y manipulando una solicitud de transacción legítima [2]. En 2025, Bybit perdió aproximadamente 1.500 millones de dólares tras un compromiso en la cadena de suministro que manipuló su interfaz de firma [3], mientras que la pérdida en el hot wallet de BtcTurk también se remontó a claves privadas comprometidas [4]. Nuestra investigación apunta en la misma dirección: entre los incidentes con pérdidas superiores a 100.000 dólares que rastreamos en 2026, los fallos fuera del contrato representaron alrededor de uno de cada ocho incidentes, pero más de tres cuartas partes de las pérdidas totales. Hasta agosto de 2026, siete de los diez mayores hackeos en la tabla de clasificación pública de rekt.news, excluyendo fraudes y otras entradas que no son hackeos, fueron compromisos fuera del contrato, representando aproximadamente el 70% tanto en número de incidentes como en valor en dólares [5].

Las wallets y los sistemas de custodia hacen que el patrón sea concreto, y la seguridad de las wallets ha seguido siendo un área especialmente activa de incidentes en los últimos años. Nuestra investigación agrupa los fallos en manejo de claves, la canalización de firma de transacciones, la cadena de suministro y dependencias, la exposición de datos sensibles y la implementación criptográfica.

* Los ~90 millones de USD de Coldcard son el mínimo verificado en cadena (aproximadamente 1.405 BTC); las estimaciones privadas llegan hasta ~130 millones de USD.

Lo que conecta esto con las pruebas de penetración no es simplemente que estos fallos caigan fuera del contrato, sino que si pueden ser explotados a menudo depende de cómo se alinean las piezas desplegadas—identidades, dependencias, controles de firma, aprobaciones y lógica de fondos—en una ruta que un atacante pueda recorrer de principio a fin—desde un punto de entrada hasta los fondos.

1.2 Auditoría a nivel de código y monitoreo a nivel de transacciones: esenciales pero limitados

Cada una de las soluciones existentes y conocidas de seguridad web3 opera a un nivel específico. La auditoría a nivel de código (auditoría de código) examina el código—la lógica del contrato, la wallet o el servicio. El monitoreo a nivel de transacciones (monitoreo) examina las transacciones a medida que llegan a la cadena; Phalcon [11], por ejemplo, detecta, alerta y bloquea actividad maliciosa en tiempo de ejecución.

Estas soluciones son útiles pero limitadas cuando se trata de la cadena de manejo de dinero de las instituciones de criptomonedas—las identidades conectadas, la infraestructura en la nube, los flujos de trabajo de firma, las cadenas de aprobación, las wallets, los proveedores y las consolas de operadores a través de las cuales el valor se mueve desde un punto de entrada hasta una acción que mueve fondos. Una ruta alcanzable por un atacante es un recorrido a través de esa cadena: puede partir de un punto de entrada web, dApp, móvil, API, nube o identidad, pasar por la firma, la aprobación y la lógica de fondos, y atravesar cómo se comporta un contrato en ese contexto en vivo, hasta llegar a la acción que mueve los fondos en el otro extremo. Revisar el código no ensambla esa ruta, y observar las transacciones no la anticipa. Incluso usadas juntas, ambas pueden dejar una brecha de composición: una auditoría muestra que el código era correcto tal como estaba escrito, no que las identidades, aprobaciones y firmantes desplegados aún lo cumplen; y el monitoreo puede dejar pasar una transferencia que es técnicamente válida pero que nunca fue lo que el operador pretendía. Lo que cierra esa brecha es una validación adversarial independiente de que los controles se componen correctamente en el sistema en funcionamiento.

Las pruebas de penetración en blockchain ejercitan el sistema ensamblado y en funcionamiento para descubrir y demostrar si tal ruta puede alcanzar los fondos antes de que un incidente la exponga. El patrón de Bybit muestra la forma del problema: una interfaz de firma comprometida convirtió la propia aprobación de los operadores en una transferencia que nunca pretendieron—un resultado que el contrato, una auditoría de este y el monitoreo de transacciones podrían leer como legítimo. Las pruebas de penetración en blockchain apuntan directamente a esa composición: tomando la posición de un proveedor, operador o interfaz comprometido, se prueba si dicho punto de apoyo puede convertir una aprobación que parece válida en un movimiento no autorizado de fondos, y qué controles desplegados—identidades, pasos de aprobación, verificaciones de firma—realmente lo impiden. La garantía a nivel de código del contrato sigue siendo tarea de la auditoría; las pruebas de penetración en blockchain interactúan con un contrato desplegado solo a través de su comportamiento en vivo cuando este forma parte de una ruta a nivel institucional hacia los fondos—alcances complementarios distinguidos por énfasis, no por un límite estricto. La Parte 2 define qué validan las pruebas de penetración en blockchain y dónde termina su alcance.

1.3 Pruebas de penetración tradicionales: útiles pero insuficientes

Las pruebas de penetración tradicionales siguen siendo valiosas en las superficies de nube, web y API, identidad y acceso privilegiado. Su limitación es el alcance y el contexto del dominio: un ejercicio convencional puede no incorporar la semántica de negocio propia de las criptomonedas ni el modelo acoplado de seguridad y cumplimiento.

En criptomonedas, una firma puede autorizar un movimiento de valor irreversible; la aprobación de un retiro es una decisión de control de fondos, no simplemente el envío de un formulario. El acreditado de depósitos, la contabilidad de saldos y las transferencias internas son lógica monetaria. Las direcciones y transacciones también pueden tener significado en términos de sanciones o de origen de fondos. Un tester podría encontrar una omisión de autenticación pero no percibir cómo se combina con una discrepancia en la pantalla de firma, una política de aprobación débil o un fallo de redondeo para formar una ruta hacia los fondos.

Las pruebas de penetración en blockchain aplican técnicas adversariales establecidas tanto a las superficies tradicionales como a las superficies específicas de web3—firma, aprobación, lógica de fondos y dinámica de contratos—a través del sistema en funcionamiento. Su diferenciador es el juicio especializado en seguridad web3, no herramientas nuevas: los testers interpretan la custodia, la intención de las transacciones, los flujos de fondos y los controles de cumplimiento como lo haría un atacante. La diferencia radica en el objetivo: una prueba convencional típicamente demuestra el impacto en el control de TI—una sesión de administrador comprometida, un servidor alcanzado—mientras que una prueba en blockchain trata el movimiento de valor como la condición final. Continúa desde ahí: altera el destinatario o el monto dentro de una solicitud de firma legítima y verifica si lo que ve el aprobador, la política de aprobación y los fondos que realmente se mueven siguen coincidiendo.

En resumen, esto es una garantía complementaria, no un muro entre lo estático y lo dinámico. Las auditorías a nivel de código, el monitoreo a nivel de transacciones y las pruebas de penetración tradicionales siguen siendo necesarias. Las pruebas de penetración en blockchain las conectan al validar rutas alcanzables; no las reemplazan, ni garantizan el descubrimiento de brechas, ni garantizan su prevención.

Parte 2: Lo que exigen los reguladores

Los requisitos varían según la jurisdicción, creando un espectro de obligaciones de licenciamiento, continuas y activadas por reguladores para entidades y sistemas específicos.

Estos ejemplos son ilustrativos, no asesoría legal. Las instituciones deben confirmar su estatus, exenciones, sistemas y obligaciones con asesoría legal.

• Estados Unidos, Nueva York: requisito explícito con exención limitada. Las entidades cubiertas bajo la norma NYDFS 23 NYCRR Part 500 [12], incluyendo los negocios de moneda virtual licenciados por el DFS, deben probar sus sistemas de información desde dentro y fuera de sus límites, según la evaluación de riesgos, al menos anualmente. Una parte interna o externa calificada puede realizar la prueba. Las pequeñas entidades que cumplan los requisitos reciben una exención limitada de esta disposición de pruebas, pero permanecen sujetas a las demás disposiciones aplicables de la Part 500.

• Dubái: requisito anual y activado por cambios. Los VASP licenciados deben realizar evaluaciones de vulnerabilidad y pruebas de penetración al menos anualmente y antes de introducir nuevos sistemas, aplicaciones o productos [13], utilizando un tercero calificado e independiente. La auditoría de contratos inteligentes se aplica cuando corresponde al negocio y las actividades del VASP. Las pruebas de penetración dirigidas por amenazas no tienen una frecuencia universal: VARA puede exigirlas cuando sea necesario y proporcional según el riesgo.

• Hong Kong: requisito de condición de licencia para solicitantes considerados como tales. Los solicitantes de plataformas de comercio de activos virtuales considerados como licenciados deben completar pruebas de penetración y evaluaciones de vulnerabilidad con resultados satisfactorios antes de la operación restringida [14]. Se aplica una guía separada para los solicitantes de nuevas corporaciones. Un tercero independiente debe cubrir la infraestructura y las aplicaciones especificadas en las capas de aplicación y red. Antes de la operación restringida, la gerencia debe completar todos los pasos de rectificación mayores y críticos para los hallazgos de riesgo medio a alto.

• Unión Europea: marco proporcional; TLPT condicionado a la identificación. DORA abarca a las entidades financieras, incluyendo a los proveedores de servicios de criptoactivos [15]. Exige pruebas apropiadas—no específicamente pruebas de penetración—al menos anualmente para los sistemas que soportan funciones críticas o importantes. Las pruebas de penetración son un método seleccionado según el riesgo y la proporcionalidad. Las pruebas de penetración dirigidas por amenazas se aplican únicamente a las entidades identificadas por las autoridades competentes, se realizan en sistemas de producción en vivo y, por lo general, se requieren al menos cada tres años; las autoridades pueden ajustar esa frecuencia según el riesgo. DORA también impone condiciones de independencia para los testers. Las microempresas quedan fuera del requisito del programa de pruebas.

• Singapur: expectativa de supervisión no vinculante. Las Directrices de Gestión de Riesgo Tecnológico del MAS indican que las instituciones financieras deben realizar pruebas de penetración y se espera que los sistemas accesibles a través de internet sean probados al menos anualmente o después de cambios o actualizaciones importantes [16]. Esta es una guía de supervisión no vinculante y no exige un tercero independiente. El Aviso de Higiene Cibernética vinculante, específico para bancos, no especifica pruebas de penetración. El aviso vinculante sobre pagos o tokens de pago digital queda fuera del alcance de este artículo.

En conjunto, estos regímenes exigen o esperan pruebas de penetración—no una categoría de marca "web3". La versión especializada en web3 se deriva de los sistemas dentro del alcance: cuando estos autorizan, firman, custodian o contabilizan valor en criptomonedas, probarlos adecuadamente requiere la misma fluidez en firma y flujos de fondos que describe la Parte 1.

La conclusión es precisa: un conjunto sustancial de entidades licenciadas en jurisdicciones específicas ya enfrenta un requisito o una expectativa de supervisión—no el mismo mandato en todos los mercados. Las diferencias determinan el alcance, la frecuencia, la independencia del tester, la remediación, la evidencia y si las pruebas respaldan el licenciamiento, el cumplimiento continuo o un ejercicio activado por el regulador.

Conclusión: Los dos pilares convergen

El origen del riesgo y los requisitos o expectativas regulatorias apuntan a la misma conclusión: para las instituciones dentro del alcance, las pruebas de penetración en blockchain son una capa de garantía necesaria. Validan rutas alcanzables a través del acceso, la aprobación, la firma y los fondos, complementando los controles existentes. No pueden garantizar la prevención, demostrar que habrían detenido algún incidente pasado específico, ni encontrar todas las rutas explotables. El objetivo es una garantía continua a lo largo del lanzamiento, la operación, la detección, la respuesta y la evidencia regulatoria—no un informe puntual.

Continúa con la serie:

• Parte 2: ¿Qué son las pruebas de penetración en blockchain? Definiciones y límites

• Parte 3: Reglas de compromiso y seguridad en producción para las pruebas de penetración en blockchain institucionales

• Parte 4: Superficies de ataque en web3: una visión general de las pruebas de penetración

También en esta serie, próximamente:

• Parte 5: Seguridad de autorización y firma: web, dApps y móvil
• Parte 6: Seguridad en la nube y CI/CD: superficies de ataque de operaciones automatizadas
• Parte 7: Seguridad del plano de control de tesorería: firma y aprobaciones de retiro
• Parte 8: Seguridad del libro contable de exchanges: rutas de robo y lógica del plano de datos

BlockSec ayuda a las instituciones a ubicar esta capa con precisión: mapea los activos, los flujos de fondos, los límites de confianza y las garantías existentes; confirma las obligaciones que la asesoría legal indica que aplican; luego define el objetivo de la prueba, el alcance, el acceso, las salvaguardas de producción, la evidencia de remediación y el plan de reprueba. Para identificar tu brecha de garantía, habla con nuestro equipo de pruebas de penetración en blockchain; el alcance del compromiso y los precios están disponibles a solicitud. Comienza donde se mueven los fondos.

Referencias

Numeradas en orden de primera aparición.

1. BlockSec, Crypto Payment Security Playbook.
2. Oficina Federal de Investigación de EE. UU., DC3, y la Agencia Nacional de Policía de Japón, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (diciembre de 2024).
3. BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack.
4. rekt.news, BtcTurk — Rekt.
5. rekt.news, Leaderboard.
6. SwissBorg, SwissBorg Security Update: Kiln Breach.
7. BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor.
8. Slope, Slope Wallet Sentry Vulnerability: Digital Forensics and Incident Response Report.
9. BlockSec, Our Short Analysis of the Profanity Tool Vulnerability.
10. BlockSec, Coldcard Entropy Failure and Seed Recovery.
11. BlockSec, Phalcon Security.
12. Departamento de Servicios Financieros del Estado de Nueva York, 23 NYCRR Part 500 — Cybersecurity Requirements for Financial Services Companies.
13. Autoridad Regulatoria de Activos Virtuales de Dubái, Technology and Information Rulebook, Parte I, Sección E.
14. Comisión de Valores y Futuros de Hong Kong, Circular 24EC65 (18 de diciembre de 2024, PDF).
15. Unión Europea, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Artículos 24–27.
16. Autoridad Monetaria de Singapur, Technology Risk Management Guidelines (enero de 2021), Secciones 2 y 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).