Cowrie Research

wazirx-multisig-wallet-interface-mismatch-malicious-implementation-swap-drain-2024-07-18

16 min read

WazirX Multisig Wallet Interface Mismatch / Malicious Implementation Swap Drain (2024-07-18)

  • Name: WazirX multisig wallet interface mismatch / malicious implementation swap drain
  • Date: 2024-07-18
  • Protocol: WazirX
  • Chain: Ethereum
  • Category: blind-sign payload substitution / signer-quorum compromise / malicious implementation swap
  • Loss: approximately $230M to $235M
  • Summary: On 2024-07-18, attackers drained WazirX multisig wallet 0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4 after collecting the approvals needed to execute a transaction that did not match what operators believed they were signing. WazirX’s own incident posts said the malicious execution still carried three WazirX signatures plus Liminal’s final approval, even though the signers reportedly saw ordinary ERC-20 transfer details, expected token names (USDT and GALA), and whitelisted destination addresses in Liminal’s interface and related notifications. Third-party contract analyses later traced the decisive onchain step to transaction 0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d, which used a delegatecall into pre-deployed malicious contract 0xef279c2ab14960aa319008cbea384b9f8ac35fc6 to overwrite the multisig proxy’s implementation pointer. Once the wallet’s logic had been swapped, the attacker could drain assets to a cluster of recipient addresses. The unresolved dispute over whether signer devices, Liminal infrastructure, or both were compromised matters less than the preserved mechanism: a trusted multisig workflow displayed a benign transfer while valid approvals ended up authorizing a hostile implementation change.
  • Trigger / entry point:
    • The affected wallet was operated through Liminal’s custody and wallet infrastructure beginning in February 2023.
    • WazirX said the wallet used six signatories: five from WazirX and one final verifier from Liminal.
    • The intended security story was that WazirX operators would initiate transfers only to previously whitelisted addresses, then Liminal’s last signature and firewall policies would independently verify the request. Liminal’s own docs for EVM multisigs sharpen the operator boundary further: the customer supplies one signature fewer than threshold, while Liminal Gas Station provides the concluding signature and gas fees for execution.
    • During the exploit, WazirX said all relevant signers saw expected token names and destination addresses in the Liminal interface and via related notifications, yet the signed transaction onchain did something different.
    • WazirX’s July 25 update added more of the operational shape: the three WazirX signers were on separate devices in separate locations using Ledger hardware wallets, bookmarked or shortcut access to the Liminal site, and 2FA, and WazirX said it found no preliminary evidence of device compromise or a new-wallet-connection prompt during the signing flow.
    • The same update also said the malicious execution was not sent to any whitelisted destination address even though Liminal’s final signature and firewall layer were supposed to reject that path.
    • WazirX’s later update said it found no preliminary evidence of signer-device compromise and considered a Liminal-side breach more likely, while third-party analyses argued the attacker likely captured some signer authority directly and also abused the interface layer. The source trail preserves the incident as partially attribution-contested even though the onchain exploitation path is clear.
  • Root cause:
    • The multisig signing flow relied on the correctness of a custody interface because ERC-20 signing in this environment remained effectively blind on hardware wallets: WazirX stressed that the Ledger devices did not display the ERC-20 token or destination address, so operators depended on Liminal’s web interface to know what they were approving.
    • Safe-style proxy storage allowed a delegatecall to attacker-controlled code to rewrite slot 0, changing the wallet implementation without moving the wallet address.
    • The control system that was supposed to constrain transfers to whitelisted destinations did not stop the actual payload that reached the chain from being an implementation-swap transaction. That failure sat not just in UI rendering but in the vendor-mediated last-signature / policy path that was supposed to be the final independent check.
    • Because the wallet infrastructure accepted the resulting approvals as authentic, the attacker did not need a smart-contract arithmetic bug inside WazirX’s custody wallet. They only needed the signers’ intent and the signed payload to diverge.
  • Exploit path:
    1. The attacker prepared malicious infrastructure in advance, with public analyses noting relevant smart contracts deployed on 2024-07-10, about eight days before the theft, but with no public interaction with the WazirX wallet until the day of the exploit.
    2. WazirX operators initiated what they believed was an ordinary multisig ERC-20 transfer flow through Liminal, relying on the interface’s displayed token and destination details because the hardware-wallet signing step was blind.
    3. The malicious flow still collected the required approval set — three WazirX signatures and Liminal’s final signature — even though WazirX later said the resulting execution was not actually to a whitelisted destination.
    4. Transaction 0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d executed a delegatecall into 0xef279c2ab14960aa319008cbea384b9f8ac35fc6.
    5. That delegatecall rewrote slot 0 of the multisig proxy so the wallet started delegating to attacker-controlled logic instead of the legitimate Safe implementation.
    6. With the implementation swapped, subsequent wallet operations drained the held assets into addresses such as 0x04b21735e93fa3f8df70e2da89e6922616891a88, 0x35febc10112302e0d69f35f42cce85816f8745ca, 0x90ca792206ed7ee9bc9da0d0df981fc5619f91fd, and 0x361384e2761150170d349924a28d965f0dd3f092.
  • What the attacker needed to be true:
    • The approval workflow had to depend on an interface representation of the transaction rather than on independent human verification of raw calldata or a clear-sign hardware-wallet display.
    • Enough approvals had to be collected to satisfy the multisig plus Liminal signing policy, including the supposedly independent final Liminal signature.
    • Liminal’s whitelisting and firewall checks had to fail to detect that the actual signed payload was an implementation-changing delegatecall, not the benign whitelisted transfer the interface allegedly showed.
    • The wallet’s proxy implementation pointer had to remain mutable from the execution path available through the signed transaction.
  • Technical anatomy worth remembering:
    • WazirX is an early large-scale example of the same slot 0 / masterCopy rewrite family later seen more publicly in Bybit.
    • The public disagreement over root cause is itself part of the lesson. Whether the attacker reached the signatures by compromising endpoints, the custody interface, or both, the exploit still cashed out through one exact onchain mechanism: a multisig-approved delegatecall that changed wallet logic.
    • WazirX’s own writeup preserved the operational asymmetry clearly: three signers on separate devices and networks plus a final Liminal verifier were still not enough once all of them ultimately trusted the same transaction-presentation layer.
    • Liminal’s own EVM-multisig docs make the hidden workflow even clearer: the organization provides one signature fewer than threshold and Liminal Gas Station adds the final signature and gas. That means the vendor was not only showing the transaction and enforcing whitelist policy; it was also operationally on the threshold-completion and publication path.
    • The incident also preserves the operational weakness of ERC-20 blind-signing in multisig environments. If the signer cannot independently read the real destination and function on the device, the interface becomes part of the trust boundary.
    • WazirX also preserved an uncomfortable policy-layer lesson: the malicious execution was allegedly not to a whitelisted destination at all, which means the security story failed not merely at the signer layer but at the final whitelist / firewall enforcement layer that was supposed to constrain what a validly signed transfer could ever do.

Three signer-authority promotions this incident collapsed

  1. A transfer-looking transaction object existed on trusted custody review surfaces

    • WazirX’s signers, related notifications, and Liminal’s workflow all preserved a coherent story that this was an ordinary ERC-20 transfer to expected token destinations.
    • That is only the weakest claim: a transaction-shaped object was visible to humans inside the custody ceremony.

  2. That represented object was over-promoted into canonical signer-intent truth

    • The decisive break was not merely that the transaction was malicious; it was that the object rendered as whitelisted token transfer was not the same object later authorized onchain.
    • The executed transaction instead performed a delegatecall into 0xef279c2ab14960aa319008cbea384b9f8ac35fc6, which rewrote the multisig proxy’s implementation pointer.
    • This is the exact signer-intent promotion that failed: the system treated the custody UI’s transfer story as if it still described the signed hash and the executed payload.

  3. That accepted transaction object still retained live root-wallet authority

    • Even after the transaction entered what operators believed was a routine withdrawal ceremony, the same approval lane still carried enough privilege to mutate future wallet logic rather than only move already-approved assets.
    • Liminal’s concluding signature, whitelist / firewall path, and publication role therefore did not merely bless one payout; they helped preserve root-control authority for a payload class that should have been unmistakably outside a routine transfer lane.
    • That surviving authority budget is what turned signer-intent failure into treasury-scale loss.
  • Representative transactions and addresses:
    • Victim wallet: 0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4
    • Main exploit transaction: 0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d
    • Malicious delegatecall target / phishing contract: 0xef279c2ab14960aa319008cbea384b9f8ac35fc6
    • Attacker address highlighted in third-party analysis: 0x6eedf92fb92dd68a270c3205e96dccc527728066
    • Recipient / laundering cluster from early public tracing:
      • 0x04b21735e93fa3f8df70e2da89e6922616891a88
      • 0x35febc10112302e0d69f35f42cce85816f8745ca
      • 0x90ca792206ed7ee9bc9da0d0df981fc5619f91fd
      • 0x361384e2761150170d349924a28d965f0dd3f092
  • Response / mitigation:
    • WazirX halted withdrawals, began forensic work, and publicly disputed Liminal’s account of the incident.
    • The exchange emphasized that the breach occurred outside WazirX’s own server infrastructure, said it had found no preliminary evidence of signer-device compromise, and pressed for fuller disclosure of how Liminal’s whitelisting, firewall, and signing controls were bypassed.
    • The aftermath became both a forensic incident and a custody-boundary dispute, underscoring how little comfort contractual role splits provide once the signed payload itself can be misrepresented.

Pattern tags

Why the exploit worked

  • The incident collapsed three different signer-authority promotions into one trusted ceremony: a transfer-looking object existed on the custody UI, that represented object was treated as if it still matched the hash being signed, and that accepted object still retained enough authority to mutate the wallet’s future logic.
  • WazirX’s real signing boundary already included Liminal’s transaction-display layer, its destination-whitelist and firewall policy stack, the coordination flow that collected the final Liminal approval, Liminal’s concluding-signature / gas-submission path for EVM multisigs, and the blind-signing limitations of the Ledger step beneath it. Once that combined representation and policy layer produced the wrong payload, the nominal 3 WazirX + 1 Liminal threshold authenticated the attacker’s calldata instead of the operators’ intended transfer.
  • The transaction ceremony failed to preserve one machine-checkable object across displayed whitelisted ERC-20 transfer → signed hash → executed multisig payload. WazirX’s own writeups preserve the key symptom: signers said they saw expected token names and whitelisted destinations, while the onchain transaction instead executed a delegatecall that rewrote wallet logic.
  • The Liminal policy story appears to have bound too much trust to the represented transfer rather than to exact payload truth. Liminal’s own firewall docs say outgoing transactions are checked before signing and broadcasting, which makes the preserved failure sharper: even the last line of defense still blessed a payload shape that should have been categorically different from a routine whitelisted token send.
  • Safe-style proxy mutability then turned that representation-layer win into root control. Once slot 0 was rewritten through delegatecall, the attacker no longer needed to keep spoofing transfer details; the wallet itself had become hostile logic.

Detection and audit pivots

  • Treat any custody or treasury flow where operators believe they approved a whitelisted transfer but the executed transaction performs delegatecall, implementation-slot mutation, owner change, or other root-control semantics as a representation-layer incident first, not merely a signer compromise.
  • Preserve and compare the exact transaction hash, proposal object, UI-rendered transfer summary, whitelisting metadata, firewall decision trail, signer-device prompts, email notifications, and executed calldata. The core forensic question is whether all review and policy surfaces were still describing one identical transaction object.
  • Audit policy engines and whitelists for privileged-shape drift: do they bind to exact target, operation type, calldata, and payload hash, or only to decoded token/destination summaries? Whitelisted recipient is not a defense if the real payload is an implementation swap.
  • Treat custody middleware as part of the wallet’s root-of-trust. Browser delivery, proposal APIs, transaction decoders, whitelist books, approval-notification rails, and final-signature services can matter as much as the onchain multisig when proving how signer intent was subverted.

Failure-prevention checklist

  • Separate routine payout authority from any lane that can execute delegatecall, rewrite implementation pointers, install modules, rotate owners, or otherwise mutate future wallet authority. A whitelisted transfer ceremony should not also be an upgrade ceremony.
  • Bind the displayed transfer, whitelist verdict, firewall decision, proposal object, signed hash, and executed calldata to one exact machine-checkable transaction envelope. If the UI can show token send to approved destination while the signed payload authorizes a proxy rewrite, the custody lane is already broken.
  • Make policy engines validate privileged shape, not just destination summaries. Unexpected delegatecall, helper contracts, implementation-slot writes, owner changes, or non-transfer selectors should fail closed even when the surrounding workflow still decodes as a normal withdrawal.
  • Treat the concluding-signature / gas-publication path as root authority, not as a neutral convenience layer. If the vendor supplies the last signature and the submission rail, that lane needs the same or stronger action-class checks as the customer-facing signer workflow.
  • Require an independent review surface for actions the hardware wallet cannot render meaningfully. At minimum, operators need a second channel that makes call versus delegatecall, target contract, and privileged action class unmistakable before threshold collection finishes.
  • During recovery, prove clean signer-facing bytes and dead suspect approvals, not only clean servers or clean source. If the attack path may have involved UI, proposal, email, or policy presentation layers, responders should invalidate live proposals, rebuild the signer surface, and confirm every signer cohort is now reviewing the same clean transaction object.

Audit prompts

  • Can the same Liminal-mediated workflow that handles ordinary whitelisted token transfers also authorize delegatecall, implementation rewrite, owner change, or other control-plane actions, and what exact machine-enforced split prevents those envelopes from hiding inside payout-looking ceremonies?
  • What exact object did each layer authenticate: browser-rendered transfer summary, whitelist entry, firewall result, stored proposal, signed hash, or executed calldata? Where could one layer still accept a different object from the others?
  • Did the whitelisting and firewall logic bind to exact target × operation × calldata × value, or only to decoded token and destination metadata? If the latter, the final policy lane was still reviewing a story rather than the real payload.
  • How much of the effective threshold sat above the onchain multisig in Liminal-operated display, coordination, notification, and final-signature infrastructure, and could operators have independently verified or bypassed that lane during an anomaly?
  • After a suspected signer-intent compromise, can responders enumerate and invalidate every pending or partially signed transaction, rebuild the signer-facing review path, and prove that the restored workflow now renders the same object that will be signed and executed?

Lessons that should already be standard

  • Whitelisted transfer is not a meaningful security class if the same ceremony can still carry delegatecall-class root authority.
  • The final vendor signature is not independent defense if it validates the same misrepresented transaction object the human signers were already shown.
  • Hardware-wallet key custody does not preserve signer intent when the device cannot render the semantic boundary that matters and the browser or custody UI is still trusted to explain it.
  • Recovery from a signer-facing custody incident is not complete when one party says its infrastructure is clean; it is complete when every signer cohort can prove it now reviews the intended bytes and no harvested approval object remains live.

Why this incident matters

  • It preserves an important pre-Bybit exemplar of signer-intent spoofing in exchange custody: the attack did not need to steal every key outright if the signing surface could lie about what was being approved and the final policy-verification layer would still bless the resulting payload.
  • It also shows that multisig wallet upgrade abuse is not only a protocol-admin problem. A custody wallet can be drained through the same delegatecall-driven implementation swap once a trusted operator workflow authenticates the wrong payload.
  • It is also a sharp bridge across five positive-design questions that are easy to blur together: signer intent truth as a single security object explains how the Liminal review surface, Ledger approval step, and collected signatures should have stayed bound to one exact transaction object; stored-privileged-approval expiry and revocation discipline explains why any suspect queued multisig object, partially collected signature set, or replayable approval bundle should have died as soon as the signer-facing environment looked untrustworthy; execution-envelope identity pinning explains why a supposedly whitelisted transfer path should never have been able to cash out as a delegatecall that rewrote wallet logic; privileged-action lane separation and ceremony escalation explains why a routine withdrawal lane should not also carry future-authority mutation; and exact production artifact attestation and rollback discipline captures the narrower recovery lesson that signer-facing UI / policy / notification surfaces need rollback proof at the bytes operators actually reviewed, not just vendor assurances about backend state.
  • Finally, the unresolved WazirX-versus-Liminal blame split is analytically useful because it keeps attention on the invariant that actually failed: the system accepted valid approvals over a transaction the operators did not think they were authorizing, then still let that misrepresented transaction keep root-wallet authority.

Internal linkages

Control surface

Graph View

Backlinks