Cowrie Research

blind-sign-payload-substitution

15 min read

Blind-Sign Payload Substitution / Signer-Intent Spoofing

  • Name: blind-sign payload substitution / signer-intent spoofing
  • Category: exploit pattern / signing-workflow compromise / transaction-representation failure / multisig custody failure
  • Summary: This exploit family appears when a signing workflow shows operators one transaction but actually gathers valid signatures over another. The attacker does not necessarily need to steal every signing key outright. Instead, they compromise the UI, API, web bundle, signer endpoint, custody middleware, or proposal relay that translates human intent into signed calldata. The sharp lesson is that a clean-looking review surface or simulation is only evidence about the object it actually received; if the signed payload diverges upstream or downstream of that review surface, valid signature stops meaning intended action. The most dangerous cases happen in multisig and custody environments where hardware wallets cannot clearly display the true function call, operation type, or destination, so signers rely on a trusted interface that quietly swaps in a malicious payload. When the workflow also supports long-lived approvals — durable nonces, queued proposals, or other delayed-execution primitives — the attacker can separate signature collection from the eventual drain window and keep a suspiciously obtained approval live after the original session should have died. Once enough signatures are collected, the exploit often cashes out through a second-step primitive such as ownership transfer, proxy implementation swap, counterfeit-collateral admission, or direct asset sweep.
  • What it is:
    • A protocol, exchange, bridge, or admin multisig uses a signing ceremony with several human approvers, often through a web UI such as Safe or a managed custody dashboard.
    • The signers believe they are approving a benign transfer or routine admin action.
    • A compromised interface, proposal service, browser session, signer endpoint, or web-delivery path substitutes a different payload for actual signature collection.
    • The resulting signatures are valid, but they attest to attacker-chosen calldata rather than the operation the humans intended.
    • The exploit then monetizes those valid signatures through whatever privileged surface they control: wallet implementation changes, admin ownership transfer, bridge withdrawal release, or direct token sweeps.
  • Typical preconditions:
    • Signers depend on a UI, simulation surface, or custody dashboard to interpret transaction meaning because raw calldata is not independently reviewed.
    • Hardware-wallet or custody-device output is blind-signed or too opaque to make the malicious payload obviously distinguishable.
    • The signed action has large blast radius: wallet logic upgrade, ownership transfer, bridge withdrawal, or admin role change.
    • The signer workflow does not enforce out-of-band verification of the final hash, operation, target address, or privileged storage effects.
    • The underlying contract architecture contains a latent high-impact admin primitive once signatures are obtained — for example delegatecall, proxy implementation rewrites, upgrade authority, ownership transfer, market listing, oracle control, or withdrawal-limit changes.
    • The signing workflow may let approvals persist beyond the immediate signing session, so a mistaken signature can stay live until the attacker chooses the execution window.
  • Common vulnerable surfaces:
    • Safe or custody-dashboard signing flows that depend on browser-rendered transaction summaries
    • ERC-20 or multisend signing flows that remain blind on hardware wallets
    • web applications served from mutable cloud storage or CDN paths that sit directly in front of privileged signing ceremonies
    • transaction-proposal APIs that can store or relay one representation while signatures were gathered over another
    • durable-nonce, queued-proposal, or delayed-execution signing flows where execution can happen long after the original review moment
    • admin multisigs whose signers normalize retries, signer glitches, or other workflow anomalies during routine maintenance
    • custody systems where whitelisting or policy engines validate what the interface claims a transfer is, not necessarily the exact calldata that reaches the chain
  • Failure sequence:
    1. The attacker compromises the delivery or interpretation layer around a privileged signing ceremony.
    2. Signers initiate a legitimate transfer or admin action and review the transaction through the compromised interface.
    3. The interface or signing path substitutes attacker-selected calldata — often a delegatecall, ownership transfer, or other control-plane action — while preserving a benign-looking representation for the humans.
    4. Enough signers provide valid signatures because they believe they are approving the benign transaction.
    5. If the workflow supports persistent approvals, the attacker can wait until a quieter or more profitable execution window before broadcasting.
    6. The attacker executes the signed payload onchain.
    7. A second-step drain primitive, such as implementation swap, owner change, counterfeit-collateral admission, or direct sweep function, turns the captured intent gap into fund loss.
  • Variants:
    • Compromised signer endpoint — malware or device compromise changes what is sent for signing while leaving Safe, Tenderly, or another review tool looking normal, as in Radiant.
    • Compromised custody interface — a managed custody or policy-enforced dashboard shows whitelisted transfers while the signed payload is different, as preserved in WazirX’s dispute with Liminal.
    • Compromised web-delivery path — attacker-controlled JavaScript from a legitimate signing domain targets specific wallets or signers and rewrites payloads in-browser, as in Bybit.
    • Hash / proposal mismatch — one transaction is stored or displayed for multisig coordination while signatures were collected over a different hash.
    • Long-lived approval persistence — the attacker collects valid signatures in advance, then waits for the best execution moment because durable nonces, stored proposals, or similar mechanisms keep the malicious payload live, as in Drift.
    • Implementation-swap cash-out — the first signed action only changes wallet or protocol logic; the actual theft happens in later calls once the new implementation is live.

Three signer-workflow promotions reviewers should not collapse

  1. Some represented transaction object exists on a review surface

    • A browser session, custody dashboard, notification, proposal record, or simulation view shows operators a transaction-shaped object.
    • That is only the weakest claim: there is something humans are being asked to approve.

  2. That represented object really counts as canonical signer-intent truth

    • The rendered summary, target, operation, calldata, value semantics, nonce, and proposal hash all still need to refer to the same object the device signs and the chain later executes.
    • This is the decisive signer-intent question: the thing the humans think they are approving is still the thing the machinery is authorizing.

  3. That accepted signer-intent object still deserves this much live authority right now

    • Even a correctly represented payload should not automatically retain full treasury, upgrade, or admin power forever across queued proposals, durable nonces, degraded review conditions, or routine transfer lanes that were never supposed to carry root-control semantics.
    • This is the authority-budget question: why is this authenticated intent object still allowed to do this much damage here and now?

Healthy review gets materially better once teams stop flattening those three promotions into one vague the multisig signed it moment.

  • Detection heuristics:
    • Compare the exact payload signed on the device with the payload shown in the UI, not just the human-readable summary.
    • Compare simulation input identity, not only simulation outcome. A clean Tenderly or Safe simulation of the displayed transaction is not evidence if the signer endpoint or proposal relay can still send a different hash for signature collection.
    • Treat unexpected delegatecall, proxy-slot mutation, implementation changes, owner transfers, addresses-provider ownership moves, or operation = 1 flags during routine transfer workflows as critical anomalies.
    • Audit signing flows for places where the browser, custody dashboard, signer endpoint, or proposal API can mutate transaction content after human review.
    • Verify that proposal services reject mismatched hashes and signatures rather than storing whatever object the client sends.
    • Investigate repeated signature failures, device glitches, odd retries, or unexpected durable-nonce / queued-proposal activity during admin ceremonies instead of normalizing them as harmless UX friction.
    • Treat partially collected privileged signatures as dormant authority after any anomaly. If a session looked wrong, the important question is not only did execution already happen? but also what harvested approval object is still live?.
    • Preserve browser cache, signed payloads, proposal ids, nonce accounts, simulation inputs, and hardware-wallet screenshots after incidents; this family often leaves its best evidence in the gap between displayed and executed transactions.
  • Defenses:
    • Use hardware-wallet flows that clearly display final destination, operation type, and high-risk method semantics whenever possible.
    • Add out-of-band transaction verification for privileged actions: raw calldata or hash review on a second device, not only in the browser session that prepared the transaction.
    • Reject unexpected delegatecall, implementation changes, owner transfers, addresses-provider ownership moves, or other control-plane actions by policy when the signing ceremony is supposed to be a plain asset transfer.
    • Serve critical signing interfaces through hardened, minimal, tightly monitored delivery paths; mutable front-end infrastructure is part of the custody boundary.
    • Make proposal services, signing coordinators, and simulation surfaces verify that the proposed transaction object exactly matches the signatures being attached to it and the object being simulated.
    • Require explicit expiry, cancellation, or fresh re-review for durable-nonce and delayed-execution approval flows so attacker-harvested signatures cannot stay live indefinitely.
    • Automatically invalidate or age out partially collected privileged approvals after signer anomalies, browser-bundle drift, endpoint compromise, or proposal-hash mismatch; suspicious signatures should die faster than incident responders can forget about them.
    • Split roles so the same signing ceremony cannot both approve ordinary treasury movement and mutate root control surfaces.
    • Abort signing ceremonies on any unexplained wallet glitches, retries, or data mismatches rather than pushing through them under time pressure.

What sound design looks like

  • Signer-intent authority stays staged instead of collapsing into one approval event
    • Healthy systems keep represented transaction object exists, represented object really is canonical signer intent, and that accepted intent still deserves this much live authority as separate promotions with explicit checks and expiry at each step.
    • The fastest way to hide this failure class is to narrate all three promotions as one the multisig signed it fact.
  • The signer workflow preserves one machine-checkable intent object from UI render through device confirmation, stored proposal, collected signatures, policy evaluation, simulation, and final execution.
  • Privileged shape is explicit everywhere: routine transfers are visibly different from delegatecall, implementation swap, owner rotation, addresses-provider ownership transfer, module install, queued admin action, or other root-control semantics.
  • Browser summaries and custody dashboards are treated as advisory until a second channel, exact hash check, or device-visible confirmation proves they still describe the same payload the signer will authorize.
  • Simulation is identity-bound, not theater. The system can prove that the transaction which was simulated, the transaction whose signatures were collected, and the transaction later executed are still the same object.
  • Policy engines bind to exact target, call primitive, selector set, payload hash, and nonce semantics rather than to decoded summaries or destination-only whitelists.
  • Durable approvals are narrow, expiring, and easy to cancel; a harvested signature cannot quietly remain live for a later execution window without a fresh review moment.
  • Root-control actions and routine treasury movement are separated strongly enough that one compromised signing surface cannot silently turn ordinary payment trust into upgrade or ownership authority.

Failure-prevention checklist

  • Review three separate promotions every time: a represented transaction object exists, that represented object really is the canonical signer-intent object, and that authenticated intent still deserves this much live authority now. Healthy workflows prove all three instead of assuming one implies the next.
  • Make the proposal record, UI review object, hardware-device confirmation, simulation input, collected signatures, and execution payload all point to one exact transaction hash or typed envelope. If any layer can describe a different object, the ceremony is already unsafe.
  • Fail closed on privileged shape mismatches inside routine treasury flows: unexpected delegatecall, module installs, owner changes, addresses-provider ownership transfers, proxy upgrades, nonzero operation = 1, or unapproved target contracts should stop the ceremony automatically.
  • Treat browser bundles, custody dashboards, proposal APIs, decoders, notification rails, and signer-endpoint software as custody infrastructure with hardened delivery, change monitoring, and explicit rollback plans.
  • Require a second review channel for high-blast-radius actions: raw calldata or exact hash confirmation on a second device, independent simulation whose input hash is also verified, or a separately delivered pre-approved action manifest.
  • Bind policy engines and whitelists to exact payload truth, not only to decoded summaries or destination addresses. Whitelisted recipient is not a defense if the real call shape is an implementation swap.
  • Put explicit expiry, cancellation, and re-review requirements on durable-nonce, queued-proposal, and delayed-execution workflows so harvested signatures cannot stay live indefinitely.
  • Automatically revoke or expire partially signed privileged envelopes after any unexplained retry storm, hash mismatch, signer-endpoint compromise, bundle rollback, or proposal-service integrity incident.
  • Keep routine asset-transfer ceremonies structurally narrower than root-control ceremonies. A daily transfer path should not quietly carry upgrade, module-enablement, or ownership-transfer authority.
  • Preserve detailed proposal, signing, simulation, cache, and device evidence by default so any representation-layer incident can be reconstructed quickly instead of devolving into attribution fog.

Audit prompts

  • What exact machine-readable object does each signer review, and what proves it is the same object later stored, countersigned, and executed?
  • Can the proposal coordinator, browser session, custody dashboard, or signer endpoint mutate any field after human review but before or during signature collection?
  • Which dangerous semantics remain too opaque on the signing device: delegatecall, module install, implementation change, owner transfer, unusual nonce handling, or batched subcalls?
  • Do policy checks and whitelists evaluate the exact target, operation, calldata, and payload hash, or only a decoded UI summary and destination address?
  • Can a routine treasury-transfer ceremony still authorize a control-plane action if the UI or metadata is compromised?
  • What happens to queued proposals, durable nonces, or partially collected signatures after a retry, device glitch, or suspicious failed signing attempt?
  • Which logs, cached assets, signed payloads, and browser-delivery artifacts would responders need to prove that the humans reviewed one transaction while signatures authorized another?

Lessons that should already be standard

  • Represented transaction exists, represented transaction is the canonical signed intent, and that intent still deserves live authority are different properties.

  • A multisig threshold does not protect signers who cannot independently tell what they are signing.

  • Whitelisted address and simulation looked fine are weak assurances if the trusted interface can still misstate the call primitive or hidden side effect, or if the simulated object was never the one the device actually signed.

  • The web bundle, decoding layer, proposal store, simulation path, notification path, and signer endpoint are part of the custody boundary, not convenience middleware.

  • Blind-signing should reduce what a ceremony is allowed to authorize. If the device cannot express the privilege shape, the workflow needs a stronger second channel or a narrower action set.

  • Durable approvals are stored explosives. If the system keeps them live for later, it must also keep cancellation, expiry, and fresh-review discipline equally real.

  • Repeated signing friction during privileged ceremonies is already evidence, not just annoyance. Attackers know teams normalize retries, glitches, and resubmissions.

  • The most important comparison in these incidents is often not was the signature valid? but was the represented transaction still identical to the signed and executed one?

  • High-signal incidents:

    • signer-intent phishing drain (2020-12-14) — the stripped-down single-signer exemplar, where a compromised local MetaMask environment made a hardware wallet collect a valid signature over a different transfer than the user believed he was approving.
    • malicious implementation swap drain (2024-07-18) — the early exchange-custody exemplar where a supposedly whitelisted transfer flow produced approvals over a delegatecall that rewrote wallet logic.
    • malicious ownership-transfer upgrade drain (2024-10-16) — the DeFi admin-multisig exemplar where compromised signer endpoints let the attackers turn routine maintenance approvals into LendingPoolAddressesProvider ownership transfer.
    • [[../../../incidents/operator-compromise-custody/bybit-eth-cold-wallet-safe-ui-compromise-malicious-mastercopy-swap-drain-2025-02-21|Bybit ETH cold wallet Safe UI compromise / malicious masterCopy swap drain (2025-02-21)]] — the clearest web-delivery-path exemplar, where targeted Safe JavaScript preserved the benign transfer in the UI while harvesting signatures over a delegatecall that replaced the wallet implementation.
    • CVT counterfeit-collateral drain (2026-04-01) — the durable-nonce persistence exemplar, where attacker-harvested Security Council approvals stayed live long enough to seize admin control later and monetize that capture through counterfeit collateral admission.

Internal linkages

Control surface

Graph View

Backlinks