Reporte de Incidente de Seguridad

5 de enero — primer ataque

El 5 de enero descubrimos un ataque deliberado y altamente sofisticado dirigido contra Kontigo, que impactó a 1.005 usuarios y resultó en la pérdida de 340.905,28 USDT. Dentro de los 30 minutos posteriores a detectar la actividad maliciosa, activamos una respuesta integral de incidentes y escalamos la situación con todos los sistemas de seguridad clave. Desde ese momento operamos 24/7, realizando decenas de llamadas diarias con expertos de la industria, proveedores de infraestructura, hackers éticos, autoridades locales y clientes, reconociendo plenamente la gravedad de la situación.

Una vez contenido el ataque, comenzamos a emitir reembolsos de inmediato y completamos el proceso dentro de las siguientes 24 horas.

Cómo ocurrió el ataque

El ataque requirió tokens de autenticación válidos y “minted” (JWTs) emitidos por nuestro proveedor de autenticación.

El atacante identificó un legacy gateway en el flujo de autenticación Apple OIDC de nuestro proveedor de autenticación, en el cual el sistema no validaba/aplicaba correctamente el issuer esperado. Como resultado, el atacante pudo utilizar un issuer OIDC controlado por él para generar tokens que el proveedor de autenticación aceptó como tokens válidos de Apple. Esto le permitió acceder a las cuentas y obtener un JWT de autenticación válido.

Una vez que el atacante contó con tokens de autenticación válidos, pudo generar transacciones (quotes) para retiros de billetera y conectarse a las billeteras de los usuarios afectados para ejecutar dichas cotizaciones.

De nuestro lado, ciertas tablas de backend en nuestro proveedor de base de datos no tenían configurado Row-Level Security (RLS) / row level security para restringir el acceso a nivel granular. Esto generó una visibilidad de registros de usuarios que normalmente no se permitiría cuando estos controles están habilitados. Estas tablas no incluían llaves privadas, acceso a llaves privadas, ni información específica del usuario más allá de emails e IDs de usuario del proveedor de autenticación. Kontigo no almacena, ni mantiene, ni tiene acceso a llaves privadas de billeteras.

Los logs revelaron que nuestra tabla de información de usuarios en nuestro proveedor de base de datos, que contenía IDs de usuario del proveedor de autenticación, fue accedida el 28 de diciembre y nuevamente el 3 de enero. Este acceso no autorizado permitió al atacante recopilar IDs de usuario del proveedor de autenticación, así como direcciones de email, pero no acceso a las billeteras.

El equipo de Kontigo trabajó con nuestros proveedores de infraestructura y auditores independientes 24/7 para corregir la vulnerabilidad. Dentro de las primeras 12 horas desde el ataque inicial, tanto el problema de tokens OIDC en el sistema de autenticación (que habilitaba acceso a cuentas de usuarios) como el problema de control de acceso vía RLS (que habilitaba acceso de lectura a ciertas tablas) fueron corregidos. Posteriormente, todos los usuarios fueron reembolsados de inmediato por la totalidad de los fondos robados.

8 de enero — ataque de seguimiento

El 8 de enero, los atacantes drenaron 56.913 USDC desde 258 de las mismas billeteras de usuarios previamente afectados. En esta segunda fase, el atacante no necesitó mintear nuevos tokens de autenticación. En su lugar, re-utilizó wallet session JWTs asociados a nuestro proveedor de billetera embebida (Thirdweb) que fueron capturados durante el compromiso inicial.

Al examinar los logs, notamos un patrón claro: los usuarios se conectaron a sus billeteras el lunes, pero las transacciones se ejecutaron el jueves sin que hubiera una conexión posterior del usuario a través de nuestras APIs. Thirdweb confirmó que, bajo configuraciones por defecto, la expiración del wallet session JWT es de 30 días. Con base en esto, determinamos que el atacante almacenó wallet session JWTs durante el ataque inicial y los re-utilizó durante el segundo ataque.

Trabajamos con Thirdweb para invalidar todos los JWTs activos, y la expiración de todos los nuevos Thirdweb JWTs se redujo a 15 minutos. Además, implementamos restricciones por PIN tanto para la conexión de billetera como para la ejecución de transacciones, con el fin de prevenir accesos maliciosos a las APIs de Thirdweb.

Reembolsamos al 100% a todos los usuarios por los fondos perdidos aproximadamente 24 horas después del segundo ataque. Nuestro objetivo es emitir reembolsos y reactivar servicios lo más rápido posible, asegurando al mismo tiempo que el vector de ataque haya sido cerrado correctamente para prevenir abusos futuros.

Pudimos detener ambos ataques e identificar su causa raíz gracias al soporte excepcional de Andrew MacPherson, Security Lead de Privy y parte del equipo Security Alliance (SEAL) 911.

Movimiento de fondos y ruta de lavado

Los fondos sustraídos fueron movidos por los atacantes desde Kontigo hacia ChangeNOW, un exchange de criptomonedas basado en Saint Vincent and the Grenadines. Los atacantes utilizaron infraestructura originada en Bulletproof Hosting (BHP), un servicio vinculado a actores APT conocidos.

Adicionalmente, el equipo SEAL 911 de ZeroShadow nos ayudó a confirmar que, con base en la actividad de la dirección del threat actor (TA) en Base (0x7347C7468Cef51053d395a6D1e0c771198c5014A), un total de 56.913 USDC fue swappeado y bridged vía ChangeNOW, resultando en 123,07 XMR en la red de Monero.

La dirección en Base que fondeó la dirección del TA (0xa779f675dF0Ad1aBbD7f241313662a12592c39f0) recibió sus fondos a través de Bridgers, con origen en la dirección de TRON (TAD5jaRKvGgKbSzLsqBKPaRLSRBiPuq1cF).

Los fondos en TRON parecen haberse originado en ChangeNOW; los detalles del depósito fuente relacionados con el swap y el bridge hacia la dirección en TRON aún están pendientes.

Hemos identificado una serie de direcciones IP desde las cuales se perpetró el ataque, y estamos colaborando con autoridades locales para identificar y procesar a los hackers.

¿Por qué Kontigo utiliza un proveedor externo de autenticación y base de datos?

Nuestro proveedor de autenticación es uno de los proveedores más grandes, de mayor crecimiento y más prominentes de la industria. Dan soporte a compañías Fortune 500 y a buena parte del ecosistema de startups de Silicon Valley. Múltiples empresas globales y ampliamente conocidas han escalado sobre su infraestructura, y han invertido de forma significativa en seguridad.

Kontigo migró a este stack de autenticación + base de datos durante nuestro batch de YC S24. Como fellow YC companies, creemos que Kontigo puede seguir escalando con estos proveedores, como aliados estratégicos valiosos a lo largo de nuestro acelerado crecimiento.

Próximos pasos

Para fortalecer aún más la protección de los usuarios, Kontigo ha implementado capas adicionales de seguridad por encima de nuestro sistema de autenticación, para asegurar que no exista un único punto de falla para ninguno de nuestros usuarios.

Al mismo tiempo, Kontigo está llevando a cabo security research activa para mapear de forma proactiva todas las amenazas potenciales, incluyendo los posibles próximos pasos de hackers y criminales crypto. Hemos contratado a Trail of Bits para realizar una revisión rápida de respuesta a incidentes enfocada en los incidentes de seguridad de enero de 2026. Además, estamos evaluando trabajo adicional de seguridad como parte de nuestra respuesta de largo plazo. Estamos comprometidos a invertir fuertemente en ciberseguridad mientras escalamos más rápido y de forma más segura.

En consecuencia, también anunciamos la contratación de nuestro nuevo CISO y de un CISO advisory team, que pronto se hará público en un comunicado separado.

Sobre la infraestructura non-custodial de Kontigo

El ataque descrito arriba no estuvo relacionado, bajo ninguna forma o capacidad, con la naturaleza non-custodial de las billeteras de Kontigo.

Utilizamos Thirdweb embedded (in-app) wallets y mantenemos la llave privada abstraída del front-end. En concreto, Thirdweb genera y utiliza la llave dentro de AWS Nitro Enclaves (un “trusted execution environment” de confidential computing), de modo que la llave no se reconstruye en el cliente y el firmado ocurre dentro del enclave.

Por qué abstraemos las llaves privadas en la UI (y por qué puede ser más seguro)

La mayoría de los usuarios de Kontigo no son crypto-native. Hacer de “descargar/exportar tu llave privada” un flujo principal y visible crea un riesgo real (pérdida, captura por malware del clipboard, screenshots, social engineering, almacenamiento incorrecto). Thirdweb incluso advierte que revelar llaves privadas puede comprometer los activos. Por eso, por defecto, usamos una UX más segura y mainstream, manteniendo disponible un path de exportación bajo control del usuario.

Por qué esto se está convirtiendo en un “safe industry standard”

Este patrón, confidential computing (TEE) para la custodia y el firmado con llaves, se está usando cada vez más porque reduce la superficie de ataque frente a manejar secretos en dispositivos de usuario final o en servidores de propósito general. AWS posiciona explícitamente Nitro Enclaves para proteger y procesar datos altamente sensibles (incluyendo datos financieros), con attestation e integración con KMS para asegurar que solo código autorizado dentro del enclave pueda acceder a material sensible. AWS también publica reference architectures para secure blockchain key management y transaction signing usando Nitro Enclaves.

Por último, pero no menos importante:

Kontigo ya atiende a más de 1.300.000 usuarios activos diarios y a 1.200 compañías, convirtiéndose rápidamente en el nuevo estándar de referencia para DeFi banking.

Nuestra obsesión por cerrar brechas financieras a escala es irreprimible.