Cowrie Research

nexus-mutual-hugh-karp-metamask-spoof-transaction-signer-intent-phishing-drain-2020-12-14

14 min read

Nexus Mutual Hugh Karp MetaMask Spoof-Transaction / Signer-Intent Phishing Drain (2020-12-14)

  • Name: Nexus Mutual Hugh Karp MetaMask spoof-transaction / signer-intent phishing drain
  • Date: 2020-12-14
  • Protocol: Nexus Mutual
  • Chain: Ethereum
  • Category: blind-sign payload substitution / signer-intent spoofing / front-end-extension compromise / personal-wallet drain
  • Loss: 370,000 NXM, roughly $8.2M-$8.3M at the time
  • Summary: On 2020-12-14, attackers drained 370,000 NXM from Nexus Mutual founder Hugh Karp’s personal wallet after first compromising his Windows machine, then altering MetaMask on disk so the extension rendered a benign reward-claim flow while actually forwarding a spoofed transfer for signature. Karp still signed with a Ledger, but the signing ceremony had already been corrupted: the browser extension showed one intended action while the actual transaction sent for approval transferred his NXM to attacker address 0x09923e35f19687a524bbca7d42b92b6748534f25. Karp’s own postmortem is useful because it preserves the exact operator-side failure: the protocol treasury, capital pool, and Nexus systems were not compromised; the decisive break sat in the representation layer between what the browser said, what the Ledger actually received, and what final onchain payload his wallet authorized.
  • Trigger / entry point:
    • The attacker appears to have first gained remote access to Karp’s personal computer rather than to Nexus Mutual core contracts or treasury systems.
    • In Karp’s own reconstruction, the first visible anomaly came at about 10:20 UTC on 2020-12-11, when his screen went black for 2-3 seconds. Roughly an hour later, at about 11:20 UTC, MetaMask was altered on disk and replaced with an infected version.
    • Karp’s postmortem said the compromise put his browser into developer mode and that the malicious extension fetched configuration from coinbene.team, which is why ordinary downloaded the wrong extension warnings did not apply cleanly here.
    • Nexus Mutual also disclosed that the attacker had completed KYC as a Nexus member 11 days earlier and switched membership to a new address on 2020-12-03, suggesting advance preparation to receive and liquidate the stolen NXM.
    • On 2020-12-14, when Karp went to claim shield-mining rewards through the real Nexus Mutual application, the compromised extension presented a spoofed signing request that he ultimately approved with his hardware wallet.
  • Root cause:
    • The private keys themselves were not reportedly extracted from the hardware wallet; instead, the attacker compromised the transaction-construction and review layer around them.
    • Karp relied on MetaMask’s browser-rendered representation of the transaction closely enough that a maliciously substituted payload could reach final device approval.
    • Karp’s own writeup is unusually clear on the human-factors failure: the Ledger could have exposed the wrong To address and other raw transaction details, but because NXM was not rendered in a friendly way and the interaction looked like a low-risk reward claim on a trusted site, the real payload remained too easy to wave through.
    • In other words, the failure was not hardware wallet broken but human intent and signed payload diverged after the local wallet UI was compromised.
    • This preserves an early, stripped-down version of the same signer-intent problem later seen in larger multisig incidents: valid signatures can still authorize theft if the signing surface lies about what is being signed.
  • Exploit path:
    1. The attacker established remote access to Hugh Karp’s personal computer.
    2. They modified or replaced the local MetaMask extension environment used for wallet interactions.
    3. Karp later initiated an unrelated transaction through MetaMask.
    4. The compromised extension substituted attacker-chosen calldata and destination while preserving the appearance of the intended action strongly enough for Karp to continue.
    5. Karp approved the transaction with his hardware wallet, producing a valid signed transfer from his personal wallet to attacker address 0x09923e35f19687a524bbca7d42b92b6748534f25.
    6. Transaction 0x4ddcc21c6de13b3cf472c8d4cdafd80593e0fc286c67ea144a76dbeddb7f3629 moved 370,000 NXM out of Karp’s wallet.
    7. The attacker then wrapped stolen NXM into wNXM, routed part of the inventory through 1inch, converted some proceeds into WETH, USDT, and about 137.188 renBTC, then pushed the BTC side out to several Bitcoin addresses.
  • What the attacker needed to be true:
    • Remote control of Karp’s endpoint had to be sufficient to tamper with the local MetaMask environment.
    • Karp needed to continue trusting the browser-rendered signing prompt enough to approve the substituted transaction.
    • The hardware-wallet confirmation flow needed to be too blind, too routine, or too easy to misread for the malicious recipient address to be caught before final approval.
    • The attacker needed an address already capable of receiving and monetizing NXM, including Nexus membership / KYC prerequisites and downstream liquidity routes through wNXM.
  • Technical anatomy worth remembering:
    • This was not a smart-contract exploit against Nexus Mutual itself; it was a signer-workflow compromise against a high-value individual wallet.
    • Karp’s postmortem preserved a more exact attacker path than most early writeups: MetaMask was altered on disk, the browser was put into developer mode, and the malicious extension fetched configuration from coinbene.team. That is a much sharper boundary than the vaguer story the founder got phished.
    • The important lesson is the same one preserved later by WazirX, Radiant, Bybit, and Drift in larger institutional settings: the signing boundary is only as strong as the layer that tells the human what they are signing.
    • The attacker did not need to break the hardware wallet cryptographically. They only needed to ensure the hardware wallet received a different transaction than the one Karp believed he had initiated.
    • Karp also noted that the attacker did not take the full amount of NXM they could have, which is a useful clue that the payload was prepared and targeted rather than a generic drain everything visible extension smash-and-grab.
    • The post-theft flow matters because it shows the operational bridge from identity-gated protocol membership to immediate external liquidity: stolen NXM was not held as-is, but wrapped into wNXM and progressively laundered through DEX and BTC conversion paths.
  • Representative transactions and addresses:
    • Victim address (twiddle.eth, Hugh Karp): referenced by Etherscan on attack transaction 0x4ddcc21c6de13b3cf472c8d4cdafd80593e0fc286c67ea144a76dbeddb7f3629
    • Attacker recipient: 0x09923e35f19687a524bbca7d42b92b6748534f25
    • Main drain transaction: 0x4ddcc21c6de13b3cf472c8d4cdafd80593e0fc286c67ea144a76dbeddb7f3629
    • Early 1inch cash-out transaction cited publicly: 0xfe2910c24e7bab5c96015fb1090aa52b4c0f80c5b5c685e4da1b85c5f648558a
    • Merkle Science follow-on address for wrapped inventory (E2): 0x03E89F2e1EbCEa5d94c1B530f638cEA3950c2E2b
  • Response / mitigation:
    • Nexus Mutual quickly stated that only Karp’s personal wallet was compromised and that the mutual’s capital pool and systems were unaffected.
    • Karp later published the infected MetaMask archive, a background.js diff, and the rough compromise timeline, which turned the incident into a rare early primary-source record of a signer-intent attack rather than a mostly reconstructed after-the-fact rumor chain.
    • Public reporting emphasized that the attacker had not stolen Karp’s private keys directly; instead, Karp had been tricked into signing the wrong transaction.
    • The incident became an early warning that hardware wallets do not neutralize browser compromise when device displays and operator habits are not sufficient to verify exact intent.

Three signer-authority promotions this incident collapsed

  1. A MetaMask-looking transaction prompt existed on a trusted workflow

    • Karp really was using a Ledger through MetaMask against the real Nexus Mutual application while trying to claim shield-mining rewards.
    • That is only the weakest fact: a familiar wallet prompt existed on a canonical-looking path.

  2. That rendered prompt still counted as exact signer-intent truth

    • The harder question was whether the browser-rendered reward-claim flow, the transaction MetaMask actually forwarded, and the payload shown on the Ledger were still one identical machine-meaningful object.
    • The incident broke here first: the altered extension preserved the appearance of the intended low-risk claim while the transaction actually sent for signature transferred 370,000 NXM to attacker address 0x09923e35f19687a524bbca7d42b92b6748534f25.

  3. That accepted object still deserved unrestricted wallet-spend authority

    • Even after one browser-mediated prompt crossed the signing ceremony, a single interactive approval should not have carried immediate full-balance transfer authority over a founder wallet.
    • This is where post-authentication bounded loss becomes the useful healthy-side companion: once signer-intent integrity is weak, the next question is how much inventory one accepted prompt is still allowed to move.

Pattern tags

  • blind-sign-payload-substitution
  • signer-intent-truth-security-object
  • post-authentication-bounded-loss-design
  • The preserved failure was not hardware wallet compromise or NXM contract exploit; it was that a compromised local signing surface successfully substituted one attacker-chosen transfer for the benign action Karp believed he was approving.
  • Nexus Mutual is therefore a clean early single-signer exemplar of the same family later preserved in larger Safe and custody incidents: a valid signature over the wrong transaction is still a custody failure.

Why the exploit worked

  • The attacker did not need Karp’s private keys in the narrow cryptographic sense. They only needed control over the transaction-construction and review layer strongly enough that the browser and extension could tell Karp one story while his hardware wallet signed another.
  • That makes the real failure boundary narrower and more useful than personal computer got hacked: the decisive break was that MetaMask’s rendered transaction, Karp’s intended action, and the payload delivered for device approval were no longer the same machine-meaningful object.
  • The incident is also a clean demonstration that hardware-wallet protection is only partial when the device cannot independently communicate enough semantic detail for the signer to catch a substituted destination or transfer purpose. Key custody remained intact while signer intent did not.
  • The attacker’s prior Nexus membership and KYC preparation mattered because they reduced post-theft friction around receiving and monetizing NXM, but those membership controls did not defend the boundary that actually failed. Once Karp signed the spoofed transfer, the token’s gated-holder model offered no second brake.
  • Loss size also remained effectively unbounded at the wallet layer: one spoofed approval could move the full 370,000 NXM balance in a single step. That makes the incident a useful small-scale companion to later post-authentication bounded-loss discussions, even though the setting here was a personal wallet rather than an exchange or protocol treasury.

Detection and audit pivots

  • Preserve the exact transaction object shown in the UI, the hardware-wallet approval view, and the transaction that landed onchain. The key forensic question in this family is whether those three objects were still identical.
  • Treat endpoint compromise around privileged wallets as custody compromise even when keys remain inside hardware devices. Browser extensions, injected scripts, local proxies, and desktop malware all sit inside the signer-intent boundary if they prepare or render transactions.
  • Ask what the signing device actually displayed. If the device could not make the malicious destination, transfer semantics, or call shape meaningfully distinguishable, the workflow was already depending on trust in the browser.
  • Inventory local wallet-extension integrity, browser-profile hardening, and change-detection coverage for high-value operator wallets. In this family, the compromised rendering surface is often the decisive choke point rather than the chain or the key store.
  • For identity-gated or otherwise illiquid tokens, trace the attacker’s preparation path as part of the exploit. Membership transfer, KYC completion, wrapper conversion, and downstream DEX routes can all show that the attacker solved monetization before the theft, not after it.

Failure-prevention checklist

  • Treat the browser profile, wallet extension, local desktop environment, and signer device as one custody surface whenever the wallet can move treasury-scale personal holdings or protocol-founder inventory. In this incident, compromising the extension layer was enough to defeat the whole ceremony without ever extracting the key.
  • Require a second review channel for high-value transfers: independent transaction-hash verification, destination-address confirmation on a separate screen, or a workflow that makes the signer compare exact recipient and amount outside the browser session that constructed the request.
  • Keep high-balance personal wallets on narrower rails than ordinary interactive wallets. If one browser-driven approval can still move the full position in a single step, the design has no post-authentication loss bound once signer intent is spoofed.
  • Harden and monitor wallet-software integrity as if it were custody infrastructure: extension version pinning, browser-profile isolation, allowlisted extension updates, host telemetry, and rapid rollback / reimage playbooks all matter because the wallet UI is part of the trust boundary.
  • Separate low-value routine actions like reward claims or ordinary token interactions from high-value unrestricted transfer authority when possible. A casual interactive session should not silently carry the same blast radius as a full-balance asset sweep.
  • Preserve one machine-checkable intent object from browser render through hardware-wallet approval and final broadcast. If the signer cannot prove the reviewed transaction is the same payload the device signs, the ceremony is already relying on hope.

Audit prompts

  • What exact semantic detail does the signing device display for ERC-20 transfers or contract interactions: recipient, amount, token, function class, and any unusual destination change? If the device view is too thin to catch substitution, where is the real verification supposed to happen?
  • Can a compromised extension, browser session, local RPC path, or injected desktop process alter destination or calldata after the user believes they initiated a benign action?
  • Which wallet balances are large enough that one spoofed but validly signed action becomes catastrophic, and what explicit ceilings, allowlists, delays, or split-wallet policies keep those balances from being reachable through one browser approval?
  • How quickly would responders know that the rendered transaction, the device-confirmed payload, and the onchain transaction diverged, and which artifacts would they need to prove it?
  • Are privileged holders and operators using isolated browser profiles, dedicated signing machines, pinned extension builds, and monitored update paths, or are high-value approvals still happening in everyday browsing environments?
  • For identity-gated tokens like NXM, what recipient-side assumptions actually matter after a compromised holder signs a transfer? Membership checks may shape attacker preparation, but do they do anything once the wallet itself authorizes the move?

Lessons that should already be standard

  • A hardware wallet protects key custody, not transaction truth, if the human still depends on a compromised browser to explain what is being signed.
  • Endpoint compromise around a privileged wallet is already a custody incident even when no seed phrase or private key is extracted.
  • Browser extension integrity is not wallet UX; it is part of the effective signer quorum whenever the device cannot independently express full transaction semantics.
  • Identity-gated or KYC-gated token mechanics do not save a holder once the authenticated wallet signs the wrong transfer. Those controls may slow attacker monetization, but they do not repair signer-intent failure.
  • High-value personal wallets need explicit blast-radius limits too. Founder wallet or long-term inventory is not a reason to let one interactive browser approval move everything immediately.
  • The key forensic comparison in signer-intent incidents is not just was the signature valid? but did the browser-rendered action, the device-approved payload, and the onchain transaction stay the same object?

Why this incident matters

  • It is a clean early exemplar of blind-sign payload substitution before the later Safe- and multisig-centered mega-incidents made the family famous.
  • The case is especially useful because it strips away governance, proxy upgrades, or complex settlement logic and leaves the core lesson exposed: one compromised signing interface can turn a valid user approval into attacker-authorized value transfer.
  • Karp’s own postmortem also preserves unusually concrete artifact detail for such an early incident — altered-on-disk MetaMask, developer-mode enablement, a published infected extension archive, and a background.js diff — so the note can point to a real representation-layer compromise rather than only a generalized malware on the laptop story.
  • It is also the stripped-down personal-wallet version of signer intent truth as a single security object: one human reviewed action, one browser-rendered prompt, one device approval, and one signed payload should all have stayed the same object, but the compromised MetaMask layer broke that identity before the hardware wallet ever mattered.
  • It also shows how identity-gated tokens are not safe once the holder’s authenticated wallet itself is manipulated; membership / KYC gates only shaped the attacker’s preparation, not the security boundary that failed.

Internal linkages

Control surface

Graph View

Backlinks