By Come ha fatto l’attacco a Haruko a raggiungere i dati dei clienti?
Haruko, fornitore di tecnologia crypto per il settore istituzionale, è stato colpito da un cyberattacco che ha coinvolto 15 clienti, esponendo dettagli API in read-only relativi agli exchange e informazioni di trading, e portando, secondo quanto riportato, al furto di una piccola quantità di fondi dei clienti.
La società, con sede a Londra, fornisce infrastrutture per la gestione di portafoglio, il monitoraggio del rischio e i dati di trading a società operanti nel settore degli asset digitali, collegando i clienti istituzionali a exchange centralizzati, custodi, blockchain e protocolli di finanza decentralizzata.
Secondo i messaggi del co-fondatore e chief technology officer Adam Carlile, gli attaccanti hanno sfruttato una vulnerabilità in uno dei processi di Haruko ed estratto un token di accesso utente. Il token è stato poi utilizzato per catturare le informazioni presenti nella memoria del processo, che potrebbero includere dettagli API in read-only relativi agli exchange e altri dati di trading.
Le credenziali di login dei clienti non sono state compromesse sui sistemi propri dei clienti stessi. L’attaccante ha invece ottenuto l’accesso tramite l’infrastruttura di Haruko.
“Si è trattato di un attacco mirato condotto da un gruppo contro di noi”, ha dichiarato Carlile ai clienti. “Sono stati colpiti 15 clienti.”
Haruko ha affermato di aver corretto la vulnerabilità e rinnovato i propri segreti lato server. La società intende inoltre pubblicare un’analisi tecnica post-incidente che spieghi l’evento in maggiore dettaglio.
Perché la whitelist ha fatto la differenza?
Una delle distinzioni più evidenti tra i clienti colpiti e quelli non colpiti sembra essere stata la whitelist. I 15 clienti coinvolti erano clienti Haruko che non avevano configurato la whitelist, secondo i messaggi inviati dalla società.
La whitelist IP limita l’accesso alle API a indirizzi internet specificati, riducendo la possibilità che credenziali o token sottratti vengano utilizzati da un sistema non autorizzato. Dopo l’attacco, Haruko ha comunicato ai clienti che la configurazione di una whitelist IP in ingresso avrebbe fornito la “massima protezione”.
GSR ha dichiarato di non essere stata coinvolta nell’incidente. Anche 3iQ Digital Assets ha affermato che i propri fondi sono rimasti al sicuro, indicando in particolare la whitelist IP come elemento che ha impedito l’esposizione del proprio accesso API all’ambiente compromesso.
Questa distinzione rende la violazione particolarmente rilevante per gli hedge fund e le società di trading più piccole, che dipendono da infrastrutture di terze parti ma potrebbero non mantenere gli stessi controlli di sicurezza delle istituzioni più grandi. Una chiave API in read-only normalmente non può autorizzare direttamente dei prelievi, ma dati di trading esposti, informazioni sui conti e infrastrutture interconnesse possono comunque creare superfici di attacco aggiuntive.
In sintesi per gli investitori
L’incidente Haruko dimostra che il rischio crypto a livello istituzionale non si esaurisce con gli exchange e le chiavi private. Le società di trading dipendono sempre più da sistemi di terze parti che aggregano posizioni e collegano più piattaforme, il che significa che la compromissione di un’unica infrastruttura può esporre più clienti contemporaneamente. La protezione apparentemente offerta dalla whitelist IP mostra inoltre come controlli di accesso di base possano modificare in modo sostanziale l’esito della stessa violazione.
Perché Haruko è una componente importante delle infrastrutture crypto istituzionali?
Haruko afferma di servire più di 80 clienti a livello globale e di integrarsi con oltre 100 piattaforme di trading centralizzate, più di 30 blockchain e 250 protocolli onchain. Il suo sito elenca tra i clienti Bitcoin Suisse, GSR, Flowdesk, 3iQ Digital Assets, M2, Ampersan e Trovio Asset Management.
La piattaforma si posiziona di fatto tra le società di trading istituzionali e molti degli exchange e protocolli che queste utilizzano, consolidando posizioni, transazioni e informazioni sul rischio in un unico sistema.
Ciò rende i fornitori di infrastrutture obiettivi appetibili anche quando non custodiscono direttamente gli asset dei clienti. Un attaccante che compromette un singolo fornitore di servizi può ottenere informazioni su più fondi, sui loro rapporti con gli exchange e potenzialmente sulla loro attività di trading.
L’attacco si inserisce in uno schema già visibile in numerosi exploit crypto rilevanti del 2026, dove infrastrutture compromesse, credenziali e sistemi operativi sono diventati vettori di attacco sempre più rilevanti, accanto alle tradizionali vulnerabilità degli smart contract.
Gli attaccanti crypto si stanno orientando verso le infrastrutture?
La violazione di Haruko arriva in un anno particolarmente intenso per gli incidenti di sicurezza nel settore crypto. Nella prima metà del 2026 sono stati registrati oltre 200 attacchi, con perdite che, secondo alcune stime del settore, si avvicinano a 1 miliardo di dollari.
Il più ampio set di dati di CertiK relativo al primo semestre 2026 ha stimato perdite per circa 1,32 miliardi di dollari su 344 incidenti di sicurezza. La compromissione dei wallet da sola ha rappresentato centinaia di milioni di dollari di perdite, mentre altri attacchi hanno preso di mira sempre più i sistemi che circondano le applicazioni blockchain, piuttosto che le vulnerabilità degli smart contract in sé.
I ricercatori di sicurezza avevano già avvertito che gli attacchi alla supply chain, il phishing e gli attacchi alle infrastrutture stavano diventando una componente sempre più rilevante del modello di minaccia crypto con l’aumento dell’adozione istituzionale.
L’analisi post-incidente promessa da Haruko sarà quindi rilevante anche oltre la propria base clienti. Le domande centrali riguardano il modo in cui il token di accesso è stato estratto, quali informazioni fossero esattamente disponibili nella memoria del processo, se le credenziali in read-only sottratte siano state utilizzate in attacchi successivi e perché si siano verificate perdite di fondi dichiarate nonostante le API esposte fossero descritte come in read-only.
Per le società crypto istituzionali, l’incidente trasforma la sicurezza delle API, la gestione dei token e la whitelist obbligatoria da semplici scelte di configurazione tecnica a veri e propri interrogativi sul rischio di controparte.