Su sistema de pagos existe para mover dinero — y es exactamente por eso que las hot wallets, los flujos de firma y los privilegios de administrador son objetivos directos para los atacantes. Como muestran los casos a continuación, la superficie de ataque ha ido más allá de los errores en contratos inteligentes hacia la infraestructura de firma, las claves y las personas que los operan.
Ese es el patrón detrás de tres de los incidentes más grandes relacionados con pagos en cripto de 2025. Hemos analizado en profundidad las cadenas de ataque, y cada una corresponde a un vector de ataque distinto: un ataque a la cadena de suministro sobre la infraestructura de firma, una clave de administrador filtrada y personal de operaciones comprometido mediante ingeniería social. A continuación, desglosamos lo que ocurrió en cada caso, lo que revela sobre hacia dónde se dirigen los hackeos de pagos en cripto, y luego bajamos un nivel hacia la capa de contratos sobre la que se ejecutan esos pagos — dónde aparecen realmente los contratos inteligentes en un sistema de pagos, en qué se diferencian las dos principales stablecoins en cuanto a quién puede congelar o emitir sus fondos, y qué necesita un contrato de pagos autodesplegado antes y después de entrar en producción.
Bybit, $1.500 millones: Cuando la herramienta de firma se convierte en el ataque
Los atacantes nunca explotaron un error en los propios contratos de Bybit — comprometieron la interfaz de terceros Safe{Wallet} en la que confiaban los firmantes. Inyectaron JavaScript malicioso en el código del front-end de Safe{Wallet}, la herramienta de gestión de multisig de terceros que utilizaba Bybit. Cuando los firmantes de Bybit vieron lo que parecía una "transferencia interna" rutinaria en la interfaz web de Safe{Wallet} y la firmaron, en realidad estaban firmando una operación delegatecall que reemplazaba el slot 0 del proxy del contrato multisig con un contrato de implementación controlado por el atacante. Una vez firmado, los atacantes vaciaron toda la wallet en cuestión de minutos.
Cuatro cosas tuvieron que fallar simultáneamente para que esto funcionara:
- Seguridad del endpoint — la interfaz web de los firmantes provenía de un tercero, sin verificación independiente.
- Verificación de transacciones — la firma ciega significaba que los firmantes no podían distinguir en pantalla una transferencia normal de un delegatecall.
- Diseño del contrato — el privilegio de actualización del proxy no tenía protección de timelock.
- Aislamiento operacional — el entorno de firma no estaba físicamente aislado del entorno de oficina cotidiano.
Ese último punto merece reflexión: incluso un exchange bien financiado puede perder $1.500 millones cuando varios mecanismos de protección fallan a la vez — seguridad del endpoint, verificación de transacciones, diseño del contrato y aislamiento operacional. Para un análisis más profundo sobre cómo reforzar el propio entorno de firma, consulte gestión de claves e infraestructura de firma.
UPCX, $70 millones: Una clave de administrador filtrada, control total
En 2025, el protocolo de pagos UPCX perdió aproximadamente $70 millones debido a una clave privada de administrador filtrada.
En este caso, el atacante no necesitó engañar a nadie para que firmara nada. Simplemente obtuvo la clave privada del ProxyAdmin, usó la función de actualización del contrato para reemplazar el contrato de implementación por una versión maliciosa y luego llamó a withdrawByAdmin para vaciar todos los fondos.
La lección es contundente: una clave filtrada más el privilegio de actualización de contratos equivale a control total. Por eso la gestión de claves del ProxyAdmin debe usar MPC o multisig — nunca un único titular — y por eso las actualizaciones de contratos necesitan un timelock (por ejemplo, un retraso de 48 horas) que le dé al equipo una ventana para detectar anomalías antes de que una actualización entre en vigor. Profundizamos en cómo estructurar ese tipo de configuración de gestión de claves en otro artículo de esta serie.
MoonPay, $250.000: Cuando los atacantes omiten el código por completo
No todos los hackeos de pagos en cripto involucran un contrato o un sistema de claves. Según una presentación de decomiso del Departamento de Justicia de EE. UU. de 2025, el CEO y el CFO de la empresa de pagos en cripto MoonPay fueron víctimas de phishing y perdieron aproximadamente $250.000 en USDT mediante un único correo electrónico.
El atacante se hizo pasar por una figura conocida y utilizó typosquatting para falsificar la dirección del remitente — intercambiando una "I" mayúscula por una "l" minúscula, prácticamente invisible en una fuente sans-serif — para engañar a los ejecutivos de MoonPay para que transfirieran USDT a una dirección controlada por el atacante. No hubo ninguna vulnerabilidad técnica y el sistema de claves nunca fue tocado. Fue ingeniería social pura.
Tether posteriormente congeló aproximadamente $40.000 de los fondos robados, mientras que el resto fue al extranjero para que el DOJ lo persiguiera.
Algunos aspectos destacan:
- La ingeniería social no discrimina — incluso los ejecutivos técnicamente sofisticados de una empresa de pagos líder pueden caer en ella.
- Siempre verifique la dirección del destinatario de forma independiente antes de enviar, nunca solo a partir de la dirección que aparece en un correo electrónico. Combine verificación de direcciones, listas blancas y un período de enfriamiento para montos grandes.
- La capacidad de congelamiento de stablecoins ayudó a recuperar parte de la pérdida después del hecho, pero solo se recuperó una fracción. La prevención supera al congelamiento posterior.
El patrón: Tres vectores de ataque, una sola lección
Al alinear estos tres casos, emerge un patrón — cada uno representa un punto de fallo distinto, pero cada uno tiene una defensa bien definida:
| Patrón de ataque | Caso | Objetivo | Defensa principal |
|---|---|---|---|
| Ataque a la cadena de suministro | Bybit | Herramienta de firma / front end | Verificación independiente + aislamiento del entorno de firma |
| Filtración de clave | UPCX | Clave privada de administrador | MPC/multisig + timelock |
| Ingeniería social | MoonPay | Personal de operaciones / ejecutivos | Verificación de direcciones + lista blanca + formación en concienciación de seguridad |
La superficie de ataque ha cambiado: ya no se trata solo de errores en contratos inteligentes, sino de la infraestructura de firma, las claves de administrador y el personal de operaciones que los rodea. Si usted es responsable de un sistema de pagos en cripto, la conclusión práctica es defender los tres — sus herramientas de firma, sus claves de administrador y su personal de operaciones — como superficies de ataque separadas, cada una con sus propios controles.
Dicho esto, los privilegios de contratos figuraron en dos de estos tres casos — el proxy upgrade sin timelock fue uno de los cuatro fallos detrás de Bybit, y la clave ProxyAdmin de UPCX fue el ataque en su totalidad. Por eso vale la pena bajar un nivel: en qué consiste realmente la capa de contratos de un sistema de pagos y qué necesita.
Dónde aparecen realmente los contratos inteligentes en los pagos
Si está construyendo un producto de pagos en cripto, es fácil asumir que la seguridad de los contratos inteligentes implica una complejidad al nivel de DeFi: una docena de protocolos interactuando, una red de supuestos económicos y una enorme superficie de ataque que defender. Eso no suele ser donde se ubican las empresas de pagos. En comparación con DeFi, donde un escenario puede involucrar una docena de contratos interactuando bajo un modelo económico complejo, la lógica de los contratos de pago suele ser mucho más directa. De menor a mayor complejidad, los usos se agrupan en cuatro lugares.
Contratos de stablecoins, utilizados por casi todas las empresas. USDC y USDT son en sí mismos contratos inteligentes, con funciones de administrador como mint, burn, blacklist y pause. Usted es un usuario de estos contratos, no el desplegador — pero aún necesita entender su modelo de permisos y su capacidad de congelamiento, sobre lo que profundizaremos a continuación.
Multisig de contratos y abstracción de cuentas, la capa de wallets y gobernanza. Los multisig de contratos como Safe gestionan fondos y privilegios de contratos y se sitúan en el núcleo de la capa de wallets. La abstracción de cuentas (ERC-4337) también ha comenzado a entrar en los escenarios de pago, impulsando pagos sin gas (un paymaster cubre el gas para que el usuario no necesite tener el token nativo), límites de gasto empresarial y session keys.
Divisiones automáticas, liberación condicional y liquidación entre cadenas — la categoría que escala ahora mismo. Aquí es donde el "dinero programable" se gana su nombre. El Commerce Payments Protocol de Coinbase y Shopify divide un cobro on-chain en tiempo real: en el momento de la captura, el contrato enruta atómicamente la comisión al feeReceiver y el resto al comerciante, y puede dividir una única autorización en múltiples capturas a diferentes tasas para diferentes destinatarios — por ejemplo, capturando 1.000 USDC en dos partes, pagando comisiones a diferentes destinatarios y liquidando el resto al comerciante. El mismo protocolo lleva al on-chain el familiar flujo de autorización/captura de las redes de tarjetas: un contrato de custodia retiene los fondos después de que el comprador autoriza, para que el comerciante pueda capturar o reembolsar más tarde. En el lado de la liquidación, el CCTP de Circle utiliza burn-and-mint nativo para la transferencia de USDC entre cadenas y puede desencadenar acciones de contrato de seguimiento a la llegada, encadenando el movimiento entre cadenas y la liquidación automatizada.
Rendimiento automático y gestión de tesorería — aún en etapas tempranas. Esto significa poner las reservas inactivas en protocolos DeFi de bajo riesgo para generar rendimiento, o automatizar el movimiento de tesorería con contratos. La mayoría de las empresas de pagos no han adoptado esto a escala, y con razón: introduce dependencias de protocolos externos, lo que amplía la superficie de ataque.
La mayoría de las empresas de pagos hoy en día se mantienen en las dos primeras categorías, la tercera está comenzando a escalar, y la cuarta sigue siendo incipiente. Cuanto más simple sea el uso, menor será la superficie de ataque — por eso añada complejidad de contratos solo cuando su negocio lo requiera, no por el mero hecho de ser "programable."
El modelo de permisos detrás de cada stablecoin que utiliza
Como usuario de stablecoins, necesita entender el diseño de permisos integrado en el propio contrato. Las dos stablecoins líderes adoptan enfoques opuestos.
USDC (Circle) utiliza un modelo de poderes separados: masterMinter gestiona las asignaciones de emisión, pauser puede pausar el contrato, blacklister gestiona la lista negra y owner gestiona la asignación de roles. Cada rol es independiente, sin superposición de privilegios (consulte el código fuente del contrato Circle stablecoin-evm).
USDT (Tether) utiliza un modelo de propietario único: una sola dirección de propietario concentra todos los privilegios a la vez — mint, pause y addBlackList. Es más simple en diseño, pero más concentrado.
Ninguno de los dos modelos es estrictamente mejor — presentan ventajas y desventajas distintas. Los poderes separados de USDC son más seguros pero más complejos de operar, mientras que el modelo concentrado de USDT es eficiente pero depende en mayor medida de la seguridad de una única dirección de propietario. Esa diferencia no es meramente académica: afecta directamente a su riesgo de congelamiento si alguna vez el emisor de la stablecoin necesita actuar sobre sus fondos.
El mejor auditor de seguridad para Web3
Valide el diseño, el código y la lógica de negocio antes del lanzamiento
Cómo proteger los contratos que usted mismo despliega
Si despliega sus propios contratos de recepción, liquidación, división o custodia, necesita una auditoría profesional del contrato de pagos antes del despliegue y un conjunto de mecanismos de seguridad integrados.
Antes del despliegue, obtenga una auditoría de una empresa de seguridad independiente y de terceros, más análisis estático y dinámico automatizado. Asegúrese de que la revisión cubra específicamente la gestión de permisos, los flujos de fondos, la reentrada y el desbordamiento de ratios de división — los riesgos específicos de pagos, no solo errores genéricos de contratos.
En tiempo de ejecución, se aplican cuatro mecanismos:
- Timelock — un retraso (por ejemplo, 48 horas) en las actualizaciones de contratos y cambios de parámetros, dándole a su equipo y comunidad una ventana para detectar problemas antes de que entren en vigor.
- Circuit breaker — pausa automáticamente las operaciones del contrato en el momento en que se detecta una anomalía.
- Separación de roles — el desplegador, el actualizador, el pausador y el administrador utilizan claves diferentes, de modo que ninguna credencial única controla todo.
- Patrón de proxy actualizable — un proxy transparente o UUPS, con actualizaciones protegidas por timelock más multisig.
Después del despliegue, revocar de inmediato los privilegios elevados del desarrollador es la medida principal contra las amenazas internas, y es la lección directa del incidente de UPCX mencionado anteriormente: transfiera los privilegios de administrador y propietario a un contrato multisig, proteja la clave ProxyAdmin con multisig más timelock, revise regularmente el estado de permisos del contrato para confirmar que no quedan privilegios residuales de desarrollador, y asegúrese de que cada cambio de permiso on-chain emita un registro de eventos para monitoreo y auditoría.
Nada de esto reemplaza la auditoría en sí — es lo que evita que una auditoría limpia se degrade en un contrato sin monitoreo y con privilegios excesivos después del lanzamiento.
Defienda cuatro superficies y mantenga la cuarta lo más pequeña posible
Tres de las superficies que expusieron los incidentes de 2025 son operacionales: sus herramientas de firma, sus claves de administrador y su personal de operaciones. La cuarta es la capa de contratos, y allí el objetivo es diferente — no igualar la complejidad de DeFi, sino adecuarse a su uso real: conozca el modelo de permisos de las stablecoins que utiliza, mantenga sus propios contratos tan simples como el negocio lo permita, y trate la auditoría como el día uno de una práctica continua de higiene de permisos, no como la línea de llegada.
Para ver dónde se ubica cada una de estas superficies en el sistema en su conjunto, consulte nuestro desglose de la arquitectura de pagos de seis capas. Para un desglose completo de cómo encajan estos controles, descargue el playbook completo (PDF), y para monitoreo en tiempo real que puede bloquear automáticamente transacciones de ataque en la etapa de mempool, consulte monitoreo de seguridad on-chain.
Preguntas frecuentes
¿Cuál fue el mayor hackeo de pagos en cripto en 2025? Bybit, en febrero de 2025, perdiendo aproximadamente $1.500 millones (401.347 ETH) después de que los atacantes comprometieran el código del front-end de la herramienta multisig de terceros Safe{Wallet} y engañaran a los firmantes para que aprobaran un delegatecall malicioso.
¿Cómo ocurrió el hackeo de UPCX?
Un atacante obtuvo la clave privada del ProxyAdmin de UPCX, usó la función de actualización del contrato para introducir un contrato de implementación malicioso y llamó a withdrawByAdmin para vaciar aproximadamente $70 millones en fondos.
¿Fue el incidente de MoonPay un exploit de contrato inteligente? No. El incidente de MoonPay, en el que el CEO y el CFO fueron víctimas de phishing y perdieron aproximadamente $250.000 en USDT, no involucró ninguna vulnerabilidad técnica. Fue ingeniería social pura mediante una dirección de remitente falsificada con typosquatting.
¿Qué tienen en común Bybit, UPCX y MoonPay? Cada ataque apuntó a una capa diferente de un sistema de pagos — la herramienta de firma, la clave de administrador y el personal de operaciones — demostrando que la mayor amenaza ha pasado de los errores en contratos inteligentes a la infraestructura de firma, las claves y las operaciones.
¿Cuál es la diferencia entre los modelos de permisos de USDC y USDT?
USDC (Circle) utiliza un modelo de poderes separados, con roles independientes de masterMinter, pauser, blacklister y owner. USDT (Tether) utiliza un modelo de propietario único, donde una sola dirección concentra todos los privilegios — mint, pause y addBlackList — de forma simultánea.
¿Qué mecanismos de seguridad debe tener un contrato de pagos autodesplegado? Antes del despliegue: una auditoría independiente de terceros más análisis automatizado, con revisión enfocada en gestión de permisos, flujos de fondos, reentrada y desbordamiento de ratios de división. En tiempo de ejecución: un timelock en las actualizaciones, un circuit breaker, separación de roles entre claves y un patrón de proxy actualizable protegido por timelock más multisig.
¿Por qué es tan importante revocar los privilegios del desarrollador después del despliegue? Es la medida principal contra las amenazas internas, y es la lección directa del caso UPCX. Transferir los privilegios de administrador y propietario a un contrato multisig y revisar regularmente el estado de permisos para confirmar que no quedan privilegios residuales del desarrollador cierra esa brecha.
