Haruko cyberattack exposes API keys, steals funds from smaller hedge‑fund clients
Haruko’s breach revealed read‑only exchange API details, leading to theft from 15 institutional clients. We explain how the attack worked and what it means for crypto infrastructure providers.
According to CoinDesk: Bitcoin, Ethereum, Crypto News and Price Data, Haruko, a London‑based provider of portfolio and risk‑management infrastructure for institutional crypto firms, suffered a targeted cyberattack that compromised read‑only exchange API details for 15 non‑whitelisted clients and resulted in the theft of a small amount of funds from several smaller hedge funds. The incident highlights the fragile security balance between on‑premise server setups and the growing threat landscape for crypto‑focused technology firms.
What happened
Haruko’s breach affected fifteen customers that were not on the company’s IP whitelist – a list that restricts inbound traffic to approved addresses. The attackers exploited a vulnerability in one of Haruko’s processes, extracted a user‑access token from the process’s memory, and used that token to pull read‑only exchange API credentials and trading data. The stolen token gave the attackers a window into exchange connections without needing the clients’ private keys, but it was enough to move a modest amount of assets from a handful of smaller hedge‑fund clients. The breach did not expose the clients’ own login credentials on their personal systems; the leak originated from Haruko’s own infrastructure.
Why it works that way
An API (application programming interface) is a set of rules that lets two computer systems talk to each other. In crypto trading, a read‑only exchange API provides market data and the ability to query account balances, but it cannot sign transactions. Those APIs are usually paired with a separate signing key that authorises trades. By stealing the read‑only API details, the attackers gained a live view of client positions, order flow, and could potentially combine the data with other leaked information to infer private keys or launch more sophisticated attacks.
Haruko runs its platform on bare‑metal servers – physical machines dedicated to the company – instead of cloud services such as Amazon Web Services (AWS). Bare‑metal gives firms fine‑grained control over hardware and can reduce latency, but it also means the provider must implement every security layer themselves. Cloud providers offer built‑in features like isolated networking, automated patching, and managed secret storage that make it harder for attackers to extract tokens from memory. In Haruko’s case, a flaw in a server‑side process allowed the attacker to read the process’s memory space, a technique known as memory scraping. Once the token was in hand, the attacker could issue API calls from any IP address, bypassing the intended whitelist protection.
IP whitelisting is a simple but effective defensive measure: only traffic from pre‑approved IP addresses is allowed to reach the server. However, it only works if the token used to authenticate the API call is securely stored and never exposed. If an attacker can capture the token before it is validated, the whitelist becomes irrelevant because the malicious request appears to come from an approved source.
What changes because of it
Haruko has patched the vulnerable process, rotated all server‑side secrets, and urged clients to configure inbound IP whitelists for “maximum protection.” The firm also promises a full technical post‑mortem, which should shed light on whether the flaw was a coding error, a misconfiguration, or a deeper architectural issue. For the affected clients, the immediate impact is two‑fold: a loss of funds – albeit small – and the exposure of trading data that could be used to reverse‑engineer strategies or target future attacks.
The broader market sees a reinforcement of the debate over on‑premise versus cloud hosting for crypto infrastructure. While bare‑metal can deliver performance benefits, the incident adds to a growing list of breaches where infrastructure‑level compromises outweigh application‑level bugs. Providers that rely on physical servers now face pressure to adopt cloud‑style security controls: automated secret rotation, hardware‑based enclaves for key storage, and continuous vulnerability scanning.
For institutional investors, the takeaway is to scrutinise not just the software stack but also the hosting environment of their tech partners. Smaller hedge funds, which may lack dedicated security teams, are especially vulnerable when a provider’s security posture slips. Adding layers such as multi‑factor authentication for API token generation, regular token expiration, and strict network segmentation can reduce the attack surface.
What we would watch next is Haruko’s detailed post‑mortem and any sign that other firms using similar bare‑metal setups experience follow‑on attacks. If the breach triggers a shift toward managed cloud services, we may see a short‑term scramble for compliant, secure hosting solutions in the crypto‑infrastructure niche. Conversely, if Haruko can demonstrate that its remedial steps close the gap without sacrificing performance, the incident may become a cautionary tale rather than a catalyst for wholesale migration.
