Cowrie Research

harmony-horizon-bridge-multisig-compromise-2022-06-23

16 min read

Harmony Horizon Bridge Multisig Compromise / Forged Bridge Withdrawals (2022-06-23)

  • Name: Harmony Horizon Bridge multisig compromise / forged bridge withdrawals
  • Date: 2022-06-23
  • Protocol: Harmony Horizon Bridge
  • Chain: Harmony + Ethereum + BNB Smart Chain
  • Category: bridge verification failure / signer-quorum compromise / validator private-key compromise / forged withdrawal approval
  • Loss: approximately 100M across 14 bridged assets, including about 13,100 ETH, 5.5M BUSD, additional ERC-20 bridge assets on Ethereum, and about 5,000 BNB plus 640,000 BUSD on BNB Smart Chain
  • Summary: Harmony’s Horizon Bridge let a low-threshold signer set authorize withdrawals from bridge custody on Ethereum and BNB Smart Chain. Public reporting described the live custody path as effectively 2-of-5, while Harmony’s later incident summary said the perpetrators had compromised at least two out of four bridge-validator private keys and had targeted Harmony’s internal bridge infrastructure rather than any smart-contract bug. Harmony said the attackers likely phished at least one developer, read internal chat or non-public bridge code, gained backdoor access to privileged bridge servers, and then used that access to generate the bridge approvals needed to transfer roughly $100M of bridged assets to attacker address 0x0d043128146654c7683fbf30ac98d7b2285ded00. Once those signatures existed, Horizon treated forged withdrawals as authentic bridge truth.
  • Trigger / entry point:
    • Horizon’s Ethereum-side and BNB-side custody depended on a small signer quorum rather than a proof-verifier path with broader independent validation.
    • Public reporting described the bridge as secured by an effectively 2-of-5 multisig, so compromise of only two signing authorities was enough to release nine-figure custody.
    • Harmony’s official summary later said the perpetrators had compromised at least two out of four bridge-validator private keys and that key generation required operations on a secure set of servers with privileged access.
    • Harmony also said the attack targeted internal infrastructure: a phishing compromise on at least one developer machine, likely access to internal chat threads and/or non-public bridge code, and backdoor access into one or more privileged bridge servers.
    • Harmony additionally disclosed a June 18 vulnerability in software packages used by an internal subgraph service that exposed private-cloud server addresses, creating another route for internal infrastructure probing before the theft.
    • The bridge held substantial reserves across separate custody contracts, so one successful quorum capture immediately translated into withdrawable ETH, BUSD, ERC-20 assets, BNB, and other inventory.
  • Root cause:
    • The bridge’s authenticity boundary was too small for the value it protected. Publicly, 2-of-5 already meant two keys are the bridge treasury.
    • Harmony’s own incident summary also showed that the real threshold lived partly above the visible multisig: bridge-key operations depended on privileged internal servers and operator workflows, so compromise of that environment could help collapse the effective signer boundary.
    • The real failure was operational key security and signer-hosting design, not token-contract logic or proof parsing.
    • Once the attacker controlled enough signing authority, Horizon had no second authenticity layer, value cap, or withdrawal throttle strong enough to reject the resulting outflows.
    • The incident preserved both the clean low-threshold signer-compromise branch of bridge failure and a weaker operator-boundary-opacity cousin: the bridge did not misread bridge truth; its own authorized signers and supporting infrastructure manufactured the bridge truth.
  • Exploit path:
    1. Harmony’s later summary said attacker activity against the bridge environment predated the theft itself: post-hack evidence suggested review of Horizon Bridge implementations as early as 2022-06-02, a recent trojan-horse installation on 2022-06-17, and by 2022-06-18 an internal subgraph-package vulnerability that exposed private-cloud server addresses.
    2. The attacker then gained enough Harmony bridge-signing authority — publicly understood as an effectively 2-of-5 withdrawal threshold, with Harmony later describing compromise of at least two out of four bridge-validator private keys — to satisfy Horizon’s release rules.
    3. Starting around 2022-06-23 11:06:46 UTC, the attacker began sending bridge-approved withdrawals from Horizon custody contracts to 0x0d043128146654c7683fbf30ac98d7b2285ded00.
    4. The Ethereum-side ETH Bridge, ERC20 Bridge, and BUSD Bridge each released assets because the withdrawals carried sufficient valid signatures under Horizon’s own rules.
    5. On BNB Smart Chain, the attacker also withdrew roughly 5,000 BNB and 640,000 BUSD through the same signer-authorized bridge model.
    6. Stolen ERC-20 assets were forwarded through secondary addresses, swapped heavily into ETH, and reconsolidated before later laundering through privacy rails including Tornado Cash and, later, Railgun.
    7. Harmony announced the theft more than 14 hours after the first withdrawals had begun, after the core bridge-side losses were already realized.
  • What the attacker needed to be true:
    • Two compromised signers had to be enough to pass the bridge’s release threshold.
    • Those signers had to be reachable through shared operator infrastructure or weakly isolated key-management paths rather than through truly independent custody domains.
    • The developer and bridge-server environment had to expose enough operational knowledge and privileged access for the attacker to move from workstation compromise into bridge-key exercise.
    • Horizon contracts had to trust signer approval completely, without independent value caps or sanity checks that could stop obviously abnormal outflows.
    • Bridge custody on Ethereum and BNB Chain had to be deep enough that forged approvals were worth cashing out immediately.
  • Technical anatomy worth remembering:
    • Horizon is the clean bridge verification failure through captured signer truth case. No parser bug or cryptographic proof edge was needed; the bridge’s own authority layer vouched for fake withdrawals.
    • Small multisig thresholds are deceptive if the absolute threshold is tiny relative to the protected value. 2-of-5 sounds like distributed governance; economically it meant two keys controlled roughly $100M.
    • Harmony’s own writeup also makes Horizon a useful operator-boundary case, not just a quorum-size case: the public story was 2-of-5, but the official incident summary described bridge-key operations on privileged servers, phishing of a developer laptop, internal-code or chat-thread exposure, and private-cloud probing.
    • Harmony is a useful companion to ronin-bridge-validator-quorum-compromise-2022-03-23 because both incidents sit in the signer-quorum family, but Horizon is starker on the nominal-threshold side while Ronin is starker on the stale-delegation side.
    • The asset path matters. This was not just one-token theft; separate custody contracts for ETH, ERC-20 assets, and BUSD all honored the same compromised bridge authority, then the attacker normalized the haul toward ETH for exit and laundering.
    • Later tracing tied the laundering flow to the Lazarus Group / APT38 cluster, with Elliptic noting the same Tornado-Cash-first laundering style seen after Ronin and later heavy use of Railgun once Tornado Cash was sanctioned.

Representative transactions and artifacts

  • Representative 13.1k ETH withdrawal from Horizon custody: 0x27981c7289c372e601c9475e5b5466310be18ed10b59d1ac840145f6e7804c97
  • Representative 5.5M BUSD withdrawal from Horizon custody: 0x44256bb81181bcaf7b5662614c7ee5f6c30d14e1c8239f006f84864a9cda9f77
  • Exploiter address: 0x0d043128146654c7683fbf30ac98d7b2285ded00
  • Secondary consolidation addresses highlighted by rekt.news: 0x9e91ae672e7f7330fc6b9bab9c259bd94cd08715 and 0x58f4baccb411acef70a5f6dd174af7854fc48fa9
  • Harmony multisig wallet cited in reporting: 0x715CdDa5e9Ad30A0cEd14940F9997EE611496De6
  • Harmony ETH Bridge: 0xf9fb1c508ff49f78b60d3a96dea99fa5d7f3a8a6
  • Harmony ERC20 Bridge: 0x2dCCDB493827E15a5dC8f8b72147E6c4A5620857
  • Harmony BUSD Bridge: 0xfd53b1b4af84d59b20bf2c20ca89a6beeaa2c628
  • Signer addresses publicly highlighted as compromised in rekt.news reporting: 0xf845A7ee8477AD1FB4446651E548901a2635A915 and 0x812d8622C6F3c45959439e7ede3C580dA06f8f25
  • Harmony’s official incident-summary forum post: summary-of-the-horizon-bridge-incident/20990 — useful as the primary-source operator timeline for the phishing, package-exposure, privileged-server, and validator-key-compromise path described above.

Response / mitigation

  • Harmony announced the exploit on 2022-06-23, halted Horizon Bridge activity, and began tracing funds with Chainalysis, AnChain, exchanges, and law enforcement.
  • Harmony’s later summary said cloud-service access, including bridge-node access, was decoupled during the response to preserve forensic evidence while reducing further compromise risk.
  • Harmony also said it stood up a Security Operations team, reviewed cloud practices, and began rolling out measures such as SSO + MFA, VPN use, clearer separation of sensitive data, and stronger access traceability across entry points.
  • Harmony paused the unaffected Bitcoin bridge, reinforced it with an expanded key set, swapped the multisig signers to a new key set, then released and returned the Bitcoin-bridge funds so that bridge could be effectively rendered offline while securing user funds.
  • Public monitoring noted that Harmony increased the Horizon bridge signer requirement to 4 shortly after the exploit, but that change came only after the live custody had already been drained.
  • The team offered a return bounty, first at $1M and later at $10M, but did not recover the main stolen balance through that route.
  • Elliptic later traced large portions of the stolen ETH through Tornado Cash and then Railgun; by January 2023 the FBI publicly attributed the theft to North Korea’s Lazarus Group / APT38, and Binance / Huobi later reported seizing a small portion of the laundered funds.
  • The incident quickly became one of the clearest 2022 bridge-loss examples showing that operator-key compromise alone can be enough to destroy bridge solvency.

Three bridge-and-signer-authority promotions this incident collapsed

  1. Some signer lane could still satisfy Horizon withdrawal rules

    • Public reporting already described the live bridge as effectively 2-of-5, and Harmony’s later incident summary said the perpetrators had compromised at least two out of four bridge-validator private keys.
    • Harmony’s own summary also made the weaker-but-more-honest point that the relevant signer lane was not just two keys exist; it included phishing exposure on at least one developer machine, likely access to internal chat or non-public bridge code, and backdoor access to privileged bridge servers involved in bridge-key operations.

  2. That reachable signer output still counted as canonical Horizon withdrawal truth

    • Once the attacker could produce enough approvals under Horizon’s own rules, the ETH Bridge, ERC20 Bridge, BUSD Bridge, and BNB-side bridge paths all treated those signatures as authentic authorization for exact withdrawals.
    • The dangerous promotion was not merely signatures were present; it was this compromised operator-derived signer result still means a real Horizon release.

  3. That accepted signer truth still deserved immediate multi-pool custody authority

    • After Horizon accepted the forged approvals, the same signer truth still had ordinary-speed authority to release roughly $100M across several custody pools and asset types.
    • Horizon had no meaningful route-local cap, staged large-withdrawal lane, or per-pool brake strong enough to keep captured signer truth from immediately becoming bridge treasury outflow.

Pattern tags

Why the exploit worked

  • Horizon’s public 2-of-5 story already meant a tiny compromise set could manufacture bridge truth, and Harmony’s later incident summary made the effective threshold smaller still: phishing, internal-code/chat exposure, and backdoor access to privileged bridge servers sat in the same authority path as the signer keys.
  • The bridge treated signer approval as final authenticity, not as one input into a narrower release lane. Once the attacker reached enough signing authority, the ETH, ERC-20, BUSD, and BNB custody pools all honored the same forged withdrawal reality.
  • The important independence failure was operational, not mathematical. Five signers exist or four validators exist did not matter if the real compromise domain still ran through a small, shared operator environment and the key-management workflow above it.
  • Horizon also lacked a meaningful post-authenticity brake: no route-local quota, staged settlement delay, or asset-local throttle appears to have narrowed what one captured signer path could release before operators reacted.
  • Detection lag finished the job. More than fourteen hours passed before Harmony publicly disclosed the theft, so bridge truth that had already been counterfeited stayed fully monetizable across multiple custody lanes.

Detection and audit pivots

  • Rebuild the real bridge-withdrawal threshold from hosting and operations, not only from the nominal signer count: which signers share one cloud account, one bridge server fleet, one developer-admin path, one HSM or hot-wallet tier, or one incident-response domain?
  • Treat phishing-resistant workstation security, privileged-server access, and signer-key exercise as one bridge-authenticity control surface. If compromise of a developer laptop or bridge ops host can help originate valid approvals, that path belongs inside the effective threshold.
  • Alert on multi-asset withdrawals that suddenly reuse the same small signer subset or originate across several custody pools in one short window; a captured bridge lane often drains every pool it can reach, not only one asset.
  • Ask the bounded-release question directly: after quorum is satisfied, what exact per-asset cap, queue, settlement delay, or emergency brake stops one forged approval set from immediately emptying live custody?
  • Compare public validator/signer marketing against the actual operator map and key-generation workflow. If the bridge advertises 2-of-5 or 4 validators but the real authority depends on a much smaller privileged environment, the safer number is the one attackers would target.

Failure-prevention checklist

  • Score the bridge by independent compromise domains, not signer-count aesthetics. If two bridge approvals can release nine figures of custody, the system should be reviewed as two compromises can empty the treasury unless independent operator and hosting evidence proves otherwise.
  • Keep bridge-signing infrastructure purpose-built and isolated from ordinary developer, subgraph, and support environments. Harmony’s own summary is the warning: once phishing, internal code/chat visibility, privileged bridge servers, and validator-key exercise live in one shell, the public quorum overstates security.
  • Put explicit expiry, re-approval, and revocation requirements on every bridge-side operational exception, server trust path, or support workflow that can touch validator keys or bridge-node access. Historical convenience paths should age out before attackers get to discover them.
  • Add route-local bounded release under signer truth: per-asset withdrawal caps, rolling quotas, staged release lanes for abnormal withdrawals, and fast pauses that can cut off ETH, ERC-20, BUSD, and BNB custody pools independently rather than letting one captured signer path drain them all together.
  • Make custody reconciliation and signer-subset anomaly detection treasury-grade controls. The bridge should page responders on concentrated signer reuse, simultaneous multi-pool withdrawals, and outflows that are large relative to recent route flow before fourteen-plus hours can pass.
  • Treat bridge compromise as environment compromise, not only key compromise. Rotating the visibly stolen keys is not enough if the same privileged servers, workstation paths, or cloud roles can still regenerate or exercise successor authority.
  • Force regular effective-threshold review against the live operator map: who runs each key, where key-generation or signing workflows occur, what privileged bridge hosts exist, and which supporting services now sit inside the custody boundary.
  • Separate marketing from security review. Published 2-of-5 or 4 validators language should never be allowed to stand in for an honest statement of how many truly independent compromises must happen before the bridge starts lying.

Audit prompts

  • After collapsing shared operators, bridge servers, cloud accounts, developer-admin paths, and key-management infrastructure, how many independent compromises are actually needed to authorize a Horizon withdrawal?
  • Which bridge-validator keys or signing workflows can be reached from privileged bridge hosts, internal support services, or developer workstations, and what proves those paths are segmented rather than merely undocumented?
  • What concrete telemetry would surface one signer lane is draining multiple custody pools before a long public-disclosure gap becomes possible: signer-subset concentration, cross-asset withdrawal bursts, destination clustering, or custody-delta alarms?
  • Once quorum is satisfied, what specific per-asset cap, queue, delay, or fast-pause control still limits cumulative loss on Ethereum and BNB-side custody before operators react?
  • Which operational exceptions, legacy services, package vulnerabilities, or private-cloud access paths can still help an attacker move from ordinary infrastructure compromise into bridge-validator authority?
  • Are bridge-liability reconciliation and anomaly monitoring run outside the same operator environment that can already originate approvals, or would one compromise blind both signing and detection at once?
  • If bridge keys are rotated after an incident, what procedure proves that the surrounding privileged servers, cloud roles, and support services no longer inherit equivalent authority over the replacement set?
  • Can the protocol explain its effective threshold in a way that matches the real operator topology, or does the public story still hide the smaller set of compromises attackers would actually need?

Lessons that should already be standard

  • 2-of-5 is not conservatism when the protected balance sheet is nine figures and the two keys can be reached through one operator environment.
  • Bridge-validator compromise is often workstation, server, and cloud compromise wearing a smaller key-count label. The surrounding operator shell is part of bridge truth.
  • One signer lane should not have immediate line-of-sight to every custody pool. Captured authenticity needs route-local bounded release beneath it or the first successful compromise becomes a treasury event.
  • Monitoring is part of custody. If a bridge-sized multi-asset withdrawal can run for more than half a day before disclosure, the protocol never had an adequate treasury self-awareness layer.
  • Published signer counts are not the security model. The real security model is the effective threshold after shared infrastructure, privileged operations, and key-management workflows are collapsed into honest compromise domains.
  • Post-incident key rotation is incomplete if the same privileged environment still survives around the new keys. You have not repaired the bridge if you only changed the labels on the authority objects.

Why this incident matters

  • It is a brutally clear example of why small signer quorums are bridge custody, not just bridge administration.
  • It shows that bridge security can fail long before any smart-contract bug matters if the system defining authenticity is captureable through ordinary infrastructure compromise.
  • It is also a good calibration case for bridge operator analysis: before asking whether a bridge uses signatures or proofs, ask how many truly independent compromises are needed before the bridge starts lying, and whether the real threshold includes privileged servers, developer workstations, or cloud roles that never appear in the advertised signer count.
  • It is also a bounded-release case study: after two compromised signing paths became sufficient bridge truth, separate ETH, ERC-20, BUSD, and BNB custody pools all honored that same authority, so the decisive lesson is not only two keys were enough but also one compromised bridge lane still controlled far too much immediately withdrawable value.

Internal linkages

Control surface

Graph View

Backlinks