Il fornitore di tecnologia crypto per il settore istituzionale Haruko ha subito un cyberattacco mirato all'inizio di questa settimana che ha interessato 15 dei suoi clienti, secondo persone a conoscenza dell'incidente, esponendo le credenziali API di cambio in sola lettura e i dati di trading dei clienti.

Haruko, società con sede a Londra, fornisce infrastrutture per la gestione di portafoglio, rischio e dati di trading a società istituzionali di asset digitali. La sua piattaforma si collega a exchange centralizzati, custodi, blockchain e protocolli di finanza decentralizzata, offrendo ai clienti una visione unica e consolidata di posizioni, transazioni ed esposizione al rischio. Le interfacce esposte — application programming interface, i canali attraverso i quali i sistemi dei clienti e la piattaforma di Haruko comunicano — fornivano connessioni in sola lettura a conti di exchange che detenevano e negoziavano asset come Bitcoin (BTC), insieme ai registri di trading spot e derivati. È proprio questa consolidazione a dare a un singolo incidente di un fornitore un raggio d'azione ampio: la connettività agli exchange e i registri di trading di molte istituzioni convergono su un unico fornitore di infrastrutture, ed è così che una singola intrusione si è manifestata contemporaneamente su 15 relazioni con i clienti.

L'ent dei danni finanziari resta poco chiara. Fonti hanno indicato che una piccola quantità di fondi dei clienti è stata rubata e che i hedge fund più piccoli, con controlli di sicurezza più deboli, potrebbero essere stati particolarmente esposti. Haruko non ha confermato pubblicamente perdite a livello di clienti e non ha risposto a ripetute richieste di commento.

Poiché le transazioni crypto sono generalmente irreversibili e poiché le piattaforme si affidano a credenziali digitali e sistemi di firma che possono dare agli attaccanti accesso diretto agli asset, i team di rischio istituzionali considerano grave anche una modesta fuga di credenziali lato exchange.

La violazione ha interessato tutti i clienti non in whitelist di Haruko. La società non rende pubblico l'elenco completo dei clienti, ma il suo sito web indica tra i clienti Bitcoin Suisse, GSR, Flowdesk, 3iQ Digital Assets, M2, Ampersan, MNNC Group — oggi operante come Monarq Asset Management — e Trovio Asset Management. Un portavoce di GSR ha dichiarato che la società non è stata impattata da alcuna presunta violazione; le altre società citate non avevano commentato al momento della stesura. L'accesso in sola lettura è il livello di permessi standard per gli strumenti di monitoraggio e reporting su cui si basano le piattaforme di aggregazione come quella di Haruko. La portata in sola lettura delle chiavi compromesse significa che da sole non potevano spostare fondi, ma i dati di trading rubati offrono a un attaccante una mappa precisa di dove si trovano gli asset istituzionali — una dinamica che, secondo la valutazione del rapporto, potrebbe lasciare i fund più piccoli, con un monitoraggio più esiguo, i più esposti a perdite successive.

Estrazione di Token, Non Furto di Credenziali

La versione dell'incidente fornita da Haruko, trasmessa dal co-fondatore e direttore tecnico Adam Carlile in messaggi ai clienti, indica come bersaglio la società stessa — e non alcun singolo cliente. Carlile ha descritto un attacco mirato di un gruppo contro Haruko, ha quantificato l'impatto in 15 clienti e ha delineato il percorso di intrusione: l'attaccante ha sfruttato una vulnerabilità in uno dei processi dell'azienda, estratto un token di accesso utente — una credenziale permanente che autentica il suo possessore presso un sistema senza che sia coinvolto l'accesso dell'utente — e lo ha utilizzato per catturare i dati presenti nella memoria di quel processo, che potevano includere i dettagli delle API di cambio in sola lettura e altri dati dei clienti.

Le credenz di accesso dei clienti non sono state compromesse sui sistemi degli stessi; il token è stato invece estratto dall'infrastruttura di Haruko.

Anche l'architettura ha avuto un ruolo. Haruko utilizza server bare-metal — macchine fisiche utilizzate in esclusiva dall'azienda — anziché servizi cloud come Amazon Web Services, che aggiungono ulteriori controlli di sicurezza, ha detto una persona informata sulla questione. L'hardware dedicato riduce l'esposizione derivante dalla condivisione dell'infrastruttura, ma pone l'intero onere di hardening, patching e controllo degli accessi sul team dell'operatore. Poiché le parti interessate erano i clienti non in whitelist dell'azienda — e una whitelist consente la comunicazione solo con macchine approvate — i 15 clienti impattati erano per definizione al di fuori di quel perimetro protettivo.

Rimedi e Post-Mortem

Haruko ha dichiarato di aver corretto la vulnerabilità e rinnovato i segreti lato server. Ha comunicato ai clienti che la configurazione di una whitelist IP in ingresso, che limita l'accesso a indirizzi internet specifici, avrebbe fornito la "protezione massima." È prevista una post-mortem tecnica completa.

La società dichiara di servire oltre 80 clienti a livello globale e di collegarsi a più di 100 sedi di trading centralizzate, 30 blockchain — che comprendono i principali ambienti di Layer 2 costruiti sopra le reti di base — e 250 protocolli onchain, coprendo la categoria di sedi DeFi alla quale appartengono protocolli come Ether.fi (ETHFI).

Un Anno Record per gli Attacchi Crypto

L'incidente di Haruko si inserisce in un anno record per gli attacchi. I dati di settore sugli incidenti hanno contato 207 hack nel primo semestre del 2026, più del doppio degli 83 registrati un anno prima, con perdite complessive di 972 milioni di dollari. I compromissi di infrastruttura e operativi hanno rappresentato solo circa il 15% degli incidenti ma circa il 76% del denaro rubato — uno schema di cui il rapporto descrive la tecnica token-di-accesso-e-memoria utilizzata in questo caso come esempio.

L'evidenza primaria decisiva sarà la post-mortem tecnica promessa, che dovrebbe identificare il processo vulnerabile, confermare gli spostamenti on-chain di eventuali fondi rubati e quantificare la perdita. Fino ad allora, i rimedi confermati restano la correzione del codice, il rinnovo dei segreti e la whitelist IP.