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

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

La exposición institucional se extiende más allá de los errores de contrato hacia la firma, la custodia, las claves, las personas, las cadenas de suministro y la infraestructura [1]. Como tal, esta superficie no está cubierta por completo por las soluciones de seguridad web3 conocidas—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 aplica a cualquier institución donde una persona, proveedor, interfaz o aplicación pueda influir en lo que se firma, aprueba, acredita o mueve—incluyendo los casos donde la custodia se externaliza. En paralelo, los reguladores en varios mercados imponen requisitos, obligaciones condicionales o expectativas de supervisión con distintos alcances, cadencias y reglas de independencia.

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

Parte 1: De dónde proviene el riesgo

1.1 El riesgo más allá del contrato inteligente

Las vulnerabilidades de los contratos inteligentes siguen siendo importantes, pero muchas de las pérdidas más grandes recientes se han originado en otros lugares, particularmente en las claves, los sistemas de firma y la infraestructura operativa. En 2024, los atacantes robaron aproximadamente $305 millones de DMM Bitcoin al comprometer a un proveedor de software de wallets y manipular una solicitud de transacción legítima [2]. En 2025, Bybit perdió aproximadamente $1.5 mil millones tras un compromiso en la cadena de suministro que manipuló su interfaz de firma [3], mientras que la pérdida de la 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 que rastreamos en 2026, las fallas fuera del contrato representaron aproximadamente 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 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 este 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 las fallas en manejo de claves, la canalización de firma de transacciones, cadena de suministro y dependencias, exposición de datos sensibles e implementación criptográfica.

* Los ~$90M de Coldcard son el piso verificado en cadena (aproximadamente 1,405 BTC); las estimaciones privadas llegan hasta ~$130M.

Lo que conecta esto con las pruebas de penetración no es simplemente que estos casos queden fuera del contrato, sino que si pueden explotarse 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 extremo a extremo, 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 de seguridad web3 ya conocidas funciona en 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 se mueve el valor desde un punto de entrada hasta una acción de movimiento de fondos. La ruta alcanzable de un atacante es una trayectoria a través de esa cadena: puede ir desde un punto de entrada web, dApp, móvil, API, nube o identidad, pasando por la firma, la aprobación y la lógica de fondos, y puede atravesar cómo se comporta un contrato en ese contexto en vivo, hasta la acción de movimiento de 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 según fue escrito, no que las identidades, aprobaciones y firmantes desplegados aún lo hacen cumplir; 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 la validación adversarial independiente de que los controles se componen correctamente en el sistema en ejecución.

Las pruebas de penetración de blockchain ejercitan el sistema ensamblado y en ejecución para descubrir y demostrar si dicha ruta puede llegar a los fondos antes de que un incidente lo revele. 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 del mismo y el monitoreo de transacciones podrían leer como legítimo. Las pruebas de penetración de blockchain apuntan directamente a esa composición: adoptando la posición de un proveedor, operador o interfaz comprometido, prueban si dicho punto de apoyo puede convertir una aprobación de apariencia válida en un movimiento de fondos no autorizado, 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 de 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 rígido. La Parte 2 define qué validan las pruebas de penetración de blockchain y dónde termina su alcance.

1.3 Pruebas de penetración tradicionales: útiles pero no suficientes

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 de dominio: un ejercicio convencional puede no aportar la semántica de negocio propia de las criptomonedas ni su modelo acoplado de seguridad y cumplimiento.

En las 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 las transacciones también pueden tener implicaciones de sanciones o de origen de fondos. Un evaluador podría encontrar un bypass de autenticación pero pasar por alto cómo se combina con una discrepancia en la visualización de firma, una política de aprobación débil o un fallo de redondeo para convertirse en una ruta hacia los fondos.

Las pruebas de penetración de blockchain aplican técnicas adversariales establecidas a las superficies tradicionales, además de superficies específicas de web3 como firma, aprobación, lógica de fondos y dinámica de contratos en todo el sistema en ejecución. Su diferenciador es el juicio especializado de seguridad web3, no nuevas herramientas: los evaluadores 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 es de objetivo: una prueba convencional típicamente demuestra el impacto en el control de TI—una sesión de administrador tomada, un servidor alcanzado—mientras que una prueba de blockchain trata el movimiento de valor como la condición final. Continúa más allá: altera el destinatario o el monto dentro de una solicitud de firma legítima y comprueba si lo que ve el aprobador, la política de aprobación y los fondos que realmente se mueven siguen estando alineados.

En resumen, se trata de una garantía complementaria, no de 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 de blockchain las conectan al validar las rutas alcanzables; no las sustituyen, ni garantizan el descubrimiento de una brecha, ni garantizan su prevención.

Parte 2: Qué exigen los reguladores

Los requisitos varían según la jurisdicción, creando un espectro de obligaciones de licenciamiento, continuas y activadas por el regulador 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 NYDFS 23 NYCRR Parte 500 [12], incluidos los negocios de moneda virtual con licencia de DFS, deben probar los 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 entidades pequeñas que califican reciben una exención limitada de esta disposición de prueba, pero permanecen sujetas a las demás disposiciones aplicables de la Parte 500.

• Dubái: requisito anual y activado por cambios. Los VASP con licencia 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 es relevante para el negocio y las actividades del VASP. Las pruebas de penetración dirigidas por amenazas no tienen una cadencia universal: la VARA puede exigirlas cuando sea necesario y proporcional según el riesgo.

• Hong Kong: requisito de condición de licencia para solicitantes considerados con licencia. Los solicitantes de plataformas de negociación de activos virtuales considerados con licencia 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 a los solicitantes de nuevas corporaciones. Un tercero independiente debe cubrir la infraestructura y las aplicaciones especificadas a través de las capas de aplicación y de 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 cubre a las entidades financieras, incluidos los proveedores de servicios de criptoactivos [15]. Exige pruebas adecuadas—no pruebas de penetración específicamente—al menos anualmente para los sistemas que respaldan 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 solo a las entidades identificadas por las autoridades competentes, se ejecutan en sistemas de producción en vivo y generalmente se requieren al menos cada tres años; las autoridades pueden ajustar esa frecuencia por motivos de riesgo. DORA también impone condiciones de independencia para los evaluadores. Las microempresas están fuera del requisito del programa de pruebas.

• Singapur: expectativa de supervisión no vinculante. Las Directrices de Gestión de Riesgos Tecnológicos de MAS indican que las instituciones financieras deben realizar pruebas de penetración y esperan que los sistemas accesibles por 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, dirigido a bancos, no especifica pruebas de penetración. El aviso vinculante sobre pagos o tokens de pago digital está fuera del alcance de este artículo.

En conjunto, estos regímenes exigen o esperan pruebas de penetración—no una categoría "web3" con marca propia. 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 flujo de fondos descrita en la Parte 1.

La conclusión es precisa: un conjunto sustancial de entidades con licencia en jurisdicciones específicas ya enfrenta un requisito o expectativa de supervisión—no el mismo mandato en todos los mercados. Las distinciones determinan el alcance, la cadencia, la independencia del evaluador, la remediación, la evidencia y si la prueba respalda 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 de blockchain son una capa de garantía necesaria. Validan las 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 cada ruta explotable. 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úe con la serie:

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

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

• Parte 4: Superficies de ataque web3: una descripció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 de 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 la garantía existente; 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 su brecha de garantía, hable con nuestro equipo de pruebas de penetración de blockchain; el alcance del compromiso y los precios están disponibles a solicitud. Comience 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 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).