El proveedor institucional de tecnología cripto Haruko sufrió a inicios de esta semana un ciberataque dirigido que afectó a 15 de sus clientes, según personas con conocimiento del incidente, exponiendo las credenciales de API de exchanges de solo lectura y los datos de trading de los clientes.

Haruko, una firma con sede en Londres, suministra infraestructura de gestión de carteras, riesgos y datos de trading a firmas institucionales de activos digitales. Su plataforma se conecta con exchanges centralizados, custodios, blockchains y protocolos de finanzas descentralizadas, ofreciendo a los clientes una vista única y consolidada de posiciones, transacciones y exposición al riesgo. Las interfaces expuestas —interfaces de programación de aplicaciones, los canales a través de los cuales los sistemas de los clientes y la plataforma de Haruko se comunican— servían conexiones de solo lectura a cuentas de exchange que custodiaban y comerciaban activos como Bitcoin (BTC), junto con registros de trading al contado y de contratos. Esa consolidación es también lo que da a un solo incidente de un proveedor un radio de impacto amplio: la conectividad con exchanges y los registros de trading de muchas instituciones convergen en un solo proveedor de infraestructura, y así una única intrusión se manifestó a la vez en 15 relaciones de clientes.

El alcance del daño financiero sigue sin estar claro. Fuentes indicaron que se robó una pequeña cantidad de fondos de clientes y que los hedge funds más pequeños con controles de seguridad más débiles pudieron haber sido especialmente expuestos. Haruko no ha confirmado públicamente pérdidas a nivel de clientes y no respondió a repetidas solicitudes de comentarios.

Debido a que las transacciones cripto son generalmente irreversibles, y a que las plataformas dependen de credenciales digitales y sistemas de firma que pueden otorgar a los atacantes acceso directo a los activos, los equipos de riesgo institucional tratan incluso una filtración modesta credenciales del lado del venue como un evento grave.

La brecha afectó a todos los clientes de Haruko que no estaban en la lista blanca. La firma no divulga su lista completa de clientes, pero su sitio web menciona como clientes a Bitcoin Suisse, GSR, Flowdesk, 3iQ Digital Assets, M2, Ampersan, MNNC Group —que ahora opera como Monarq Asset Management— y Trovio Asset Management. Un portavoz de GSR declaró que la firma no fue impactada por ninguna supuesta brecha; las demás firmas mencionadas no habían comentado al momento de redactar esta nota. El acceso de solo lectura es el nivel de permisos estándar para las herramientas de monitoreo e informes sobre las que operan las plataformas de agregación como la de Haruko. El alcance de solo lectura de las claves filtradas significa que por sí solas no podían mover fondos, pero los datos de trading robados le dan a un atacante un mapa preciso de dónde se encuentran los activos institucionales —una dinámica que, según la evaluación del reporte, puede dejar a los fondos más pequeños con menor monitoreo como los más expuestos a pérdidas posteriores.

Extracción de tokens, no robo de credenciales

El relato de Haruko sobre el incidente, transmitido por el cofundador y director de tecnología Adam Carlile en mensajes a los clientes, señala a la propia empresa —y no a ningún cliente individual— como el objetivo. Carlile describió un ataque dirigido de un grupo contra Haruko, situó el impacto en 15 clientes y detalló la ruta de intrusión: el atacante explotó una vulnerabilidad en uno de los procesos de la firma, extrajo un token de acceso de usuario —una credencial permanente que autentica a su portador ante un sistema sin que intervenga el inicio de sesión del propio usuario— y lo usó para capturar datos almacenados en la memoria de ese proceso, que podían incluir los detalles de la API de exchange de solo lectura y otros datos de clientes.

Las credenciales de inicio de sesión de los clientes no fueron comprometidas en sus propios sistemas; el token fue extraído de la infraestructura de Haruko.

La arquitectura también influyó. Haruko opera servidores bare-metal —máquinas físicas usadas exclusivamente por la firma— en lugar de servicios en la nube como Amazon Web Services, que añaden controles de seguridad adicionales, dijo una persona familiarizada con el asunto. El hardware dedicado reduce la exposición de inquilinos compartidos, pero coloca toda la carga de endurecimiento, parcheo y control de acceso en el propio equipo del operador. Dado que los afectados eran los clientes de la empresa que no estaban en la lista blanca —y una lista blanca solo permite la comunicación con máquinas aprobadas— los 15 clientes impactados estaban, por definición, fuera de ese perímetro de protección.

Remediación y análisis posterior

Haruko declaró que ha corregido la vulnerabilidad y renovado sus secretos del lado del servidor. Informó a los clientes que configurar una lista blanca de IP entrante que restrinja el acceso a direcciones de internet especificadas proporcionaría la "máxima protección". Está previsto un análisis técnico completo.

La empresa dice atender a más de 80 clientes a nivel global y conectarse con más de 100 venues de trading centralizados, 30 blockchains —que abarcan los principales entornos de Layer 2 construidos sobre redes base— y 250 protocolos onchain, cubriendo la clase de venues DeFi a la que pertenecen protocolos como Ether.fi (ETHFI).

Un año récord para los ataques cripto

El incidente de Haruko ocurre en un año récord de ataques. Los datos de incidentes de la industria contabilizaron 207 hacks en el primer semestre de 2026, más del doble de los 83 registrados un año antes, con pérdidas combinadas de 972 de dólares. Los compromisos de infraestructura y operativos representaron solo alrededor del 15% de los incidentes, pero aproximadamente el 76% del dinero robado —un patrón que el reporte describe como ejemplificado por la técnica de token de acceso y memoria usada en este caso.

La evidencia primaria decisiva será el análisis técnico prometido, que se espera nombre el proceso vulnerable, confirme el movimiento onchain de los fondos robados y cuantifique la pérdida. Hasta entonces, la remediación confirmada se limita a la corrección del código, la renovación de secretos y las listas blancas de IP.