Cowrie Research

authorized-action-origination-compromise

18 min read

Authorized-Action Origination Compromise / Operator Workflow Became Authority

  • Name: authorized-action origination compromise / operator workflow became authority
  • Category: exploit pattern / custody-operations failure / backend workflow compromise / offchain action-authorship failure / operator-authored truth collapse
  • Summary: This pattern appears when the most dangerous authority in a custody or issuance stack is not the final key itself, but the offchain workflow that is trusted to originate a legitimate withdrawal, mint, settlement, or release action. The attacker does not necessarily need to break chain verification or harvest a visible signer quorum. Instead, they compromise the employee workstation, wallet-management vendor, backend service role, cloud control plane, request-preparation system, or settlement bot that already decides what action the trusted signer or contract should carry out. Once that workflow is captured, the resulting onchain action often looks perfectly authentic: a real BTC withdrawal, a real hot-wallet payout, a real completeSwap() call from the authorized service, or a mass wallet sweep through ordinary transfer rails. The preserved lesson is narrower than general operator opacity and different from blind-sign payload substitution: the failure is that the workflow that authored legitimate actions was itself the real authority boundary, and the same workflow was often still allowed to exercise far too much value or future-authority reach after authentication had already gone bad. Reviewers should keep three questions separate: whether a lane can still author legitimate action at all, whether a specific request still preserves the exact settlement truth policy meant to approve, and whether that surviving lane still deserves the same post-authentication budget in the current operating mode.
  • What it is:
    • A protocol, exchange, payment processor, bridge, or stablecoin stack uses an offchain workflow to author legitimate actions before they reach a signer, wallet, or privileged contract entrypoint.
    • That workflow may live in employee endpoints, wallet-management middleware, cloud services, backend bots, KMS-backed service roles, or internal request-routing systems.
    • The attacker compromises that workflow rather than attacking the chain or contract directly.
    • The downstream signer, wallet, or contract then executes an action that is technically valid under normal policy because the compromised workflow is already speaking in the protocol’s own voice.
    • The chain therefore records ordinary-looking privileged behavior rather than a malformed or obviously forged action.
  • Typical preconditions:
    • There is a high-value offchain action-authoring layer between user intent and final settlement.
    • That layer can originate, finalize, or materially rewrite withdrawals, mints, release instructions, or settlement parameters.
    • Contracts or wallet infrastructure treat outputs from that layer as authoritative with little or no independent protocol-protective upper bound.
    • One employee workstation, vendor environment, backend role, cloud account, or KMS policy admin sits close enough to that action path to become decisive authority when compromised.
    • Once the authored action lands, there are few secondary checks such as value caps, dual-control review, destination allowlists enforced on exact calldata, independent collateral sanity checks, or route-local release budgets that still bind a fully authenticated internal workflow.
    • The same request-origination lane often retains both routine spend authority and access to deeper reserve, mint, rescue, or admin surfaces, so compromise of one operational workflow silently becomes treasury-scale authority.
  • Common vulnerable surfaces:
    • exchange and payment-processor hot-wallet withdrawal systems
    • wallet-management vendors that sit between internal operators and final custody actions
    • backend service roles that finalize mint, redemption, or settlement requests
    • cloud-hosted databases or control planes that coordinate mass wallet movement
    • internal payout systems where authorized withdrawal request creation is already enough to move funds
    • bridge or custody middleware that defines destination, amount, or release approval before the final signing step

Three request-authority questions healthy systems should not collapse

1. Is the origination lane still able to author legitimate action?

  • This is the raw reachability question: can the workstation, vendor workflow, backend role, cloud service, or deployment residue still create requests that the downstream signer, wallet, or contract will honor as production truth?
  • It answers whether the lane is still inside the authority graph at all.
  • It does not yet answer whether the specific request being authored is the right one.

2. Does this exact request still preserve the settlement truth policy meant to approve?

  • This is the narrower destination, asset, amount, request class, source account, and exception scope are still the exact ones policy intended question.
  • DMM Bitcoin and Resolv are the clean reminders that authorized lane called the expected function is not enough if the workflow can still reshape the economically decisive fields inside that call.
  • A system can keep the same legitimate origination lane and still fail here because the request that emerged from it no longer preserves the right settlement envelope.

3. Even if the request is authentic, how much live authority does that lane deserve right now?

  • This is the post-authentication budget question: how much reserve value, mint capacity, destination reach, rescue power, or future-authority mutation should this lane still have under healthy mode, failover, staff shortage, vendor-only continuity, or partial-compromise conditions?
  • Healthy systems do not treat this is the only lane left as a reason to preserve ordinary treasury-scale authority.
  • The control target is not merely a real workflow still exists; it is the surviving workflow now carries a consciously smaller budget when the trust boundary has narrowed.

Three request-authority promotions healthy systems should not collapse

  1. A workstation, vendor workflow, backend role, or cloud service can still originate production-shaped requests at all

    • This is the raw reachability fact: some lane still sits inside the live authority graph strongly enough that downstream wallets, signers, or contracts will treat its output as legitimate production action.
    • CoinsPaid, Mixin, and DMM show why this is already dangerous but still incomplete. A real origination lane exists is not yet the same thing as a correct request exists.

  2. That lane’s exact request still counts as canonical settlement truth for this action

    • This is the narrower promotion from some internal workflow emitted a request to the protocol now treats this exact destination, asset, amount, request class, source account, and exception scope as the one settlement story worth honoring.
    • Resolv is the clean reminder that the dangerous jump often lives here: the lane was real, but the system still wrongly promoted attacker-chosen targetAmount into canonical liability truth.

  3. That accepted request still deserves live reserve, mint, release, or future-authority budget

    • This is the post-authentication authority question: even after the lane and request are both accepted, how much value, destination reach, rescue power, or admin reach should this surviving workflow still be allowed to spend?
    • Healthy systems do not let the request came through a real internal lane silently become the request may still spend healthy-mode treasury or mint budget right now.
  • Failure sequence:
    1. The attacker compromises the operator environment that authors legitimate custody or issuance actions.
    2. They use that foothold to create, finalize, or manipulate a real request inside the trusted workflow.
    3. The downstream signer, wallet, or contract sees an action arriving through the normal trusted path.
    4. Because the action is syntactically and operationally legitimate, onchain or wallet-level checks pass.
    5. Assets are withdrawn, liabilities are minted, or mass wallet movement begins through ordinary protocol behavior.
    6. Incident responders initially face a confusing fact pattern because the chain mostly shows valid privileged actions rather than one obvious contract bug.
  • Variants:
    • Critical-workstation withdrawal origination — a compromised employee machine becomes sufficient to create or route hot-wallet payouts, as in CoinsPaid.
    • Vendor request-path compromise — compromise of an external wallet-management provider lets the attacker interfere with a legitimate client transaction request or append unauthorized payload data inside the middleware / communication layer that carries it, as in DMM Bitcoin via Ginco.
    • Service-role settlement compromise — a backend signer or KMS-backed role that finalizes requests is compromised, letting the attacker choose economically absurd settlement parameters while still calling the expected contract function, as in Resolv.
    • Cloud-control-plane wallet sweep — compromise of a cloud-hosted database or adjacent orchestration layer yields broad wallet-drain authority without any visible smart-contract exploit, as in Mixin.
    • Latent single-operator admin residue — a supposedly migrated or distributed system still leaves one deployer, hot wallet, or backend role able to originate high-impact legitimate actions by itself, as in Tapioca DAO.
  • Detection heuristics:
    • Ask not only who signs? but who authors the action that gets signed or finalized?
    • Treat backend settlement bots, wallet-management vendors, cloud databases, withdrawal orchestration systems, and KMS policy admins as treasury-critical control surfaces.
    • Review whether privileged entrypoints enforce protocol-protective upper bounds and value sanity, not only user-protective minimums or authentication of the caller.
    • Investigate incidents that look like authorized withdrawal, valid service-role call, or ordinary wallet sweep as potential action-authorship failures instead of assuming a bare key leak.
    • Preserve request objects, internal approval artifacts, workflow logs, cloud IAM changes, KMS policy edits, and session material; these incidents are often legible only when the authored action is compared with what the operator workflow should have allowed.
    • Be suspicious whenever a wallet vendor, exchange operations platform, or cloud-hosted coordination layer can shape exact destinations or amounts while the final signer mostly rubber-stamps the resulting request.
  • Defenses:
    • Treat action-authoring workflows as part of the custody boundary, not as harmless middleware behind the real signer.
    • Add independent protocol-protective ceilings: mint caps, collateral-value checks, payout thresholds, per-destination limits, and throttles that still hold even if an authorized backend role is compromised.
    • Separate routine request origination from deeper reserve movement, admin mutation, mint expansion, or rescue powers so one compromised workflow does not inherit the whole post-authentication budget.
    • Require out-of-band review or second-channel confirmation for high-value request origination, not just for the final signature.
    • Minimize authority of vendors, workstations, and backend roles that prepare or finalize requests; if possible, make them propose actions that a narrower signing or settlement layer can still reject on objective policy.
    • Encode degraded-mode budgets explicitly: if one backend, vendor, or operator path becomes the only live workflow during failover or incident response, release scope and value ceilings should shrink automatically.
    • Harden cloud IAM, workflow runners, KMS policy administration, and employee endpoints as custody-critical infrastructure.
    • Log and alert on unusual request parameters, destination changes, sudden bulk wallet movement, or settlement outputs far outside expected collateral or balance ranges.

What sound design looks like

  • Healthy teams keep three questions separate all the way through operations review: can this lane still author production action, did this exact request preserve the intended settlement truth, and how much post-authentication budget should this lane still retain right now.
  • The workflow that originates withdrawals, mints, rescues, or settlements is treated as a first-class authority surface, with the same threat modeling, access review, monitoring, and kill-switch planning as the final signer.
  • Upstream systems propose bounded settlement envelopes rather than minting or paying arbitrary value. Downstream contracts or signers still re-check destination class, asset, amount, request type, collateral sanity, and other objective ceilings before value moves.
  • The fastest or hottest workflow is not automatically the deepest-reserve or broadest-authority workflow. Routine payout lanes, mint-completion lanes, treasury lanes, and admin-mutation lanes carry different post-authentication budgets.
  • High-blast-radius requests use a second review channel that is independent of the compromised workstation, vendor panel, or backend session that prepared the request in the first place.
  • Exact settlement truth stays machine-checkable from request creation through execution: which asset, which amount, which destination, which request class, which source account, and which policy exceptions were actually approved.
  • Claimed authority migrations are treated as unfinished until the old path is provably dead. Moved to multisig, handoff complete, or vendor no longer in the loop should require a post-change privilege diff that proves the retiring workstation, deployer, service role, or wallet middleware can no longer originate production actions.
  • Bulk or unusual request production degrades into bounded loss because rate limits, mint budgets, destination controls, and anomaly-triggered pauses remain live even for fully authenticated internal workflows.
  • If the system is operating in a weaker trust mode — one live backend, one vendor console, emergency failover, or narrowed operator staff — the surviving origination lane carries a smaller release budget instead of silently inheriting healthy-mode authority.
  • Responders can freeze the request-origination layer separately from the whole business, so one compromised backend path does not force an all-or-nothing shutdown.

Failure-prevention checklist

  • Keep lane reachability, exact request truth, and surviving post-authentication budget as separate policy checks. A workflow being production-reachable should not by itself imply that any request it emits is sound, and an authenticated request should not by itself imply ordinary healthy-mode authority budget.
  • Treat request-origination systems, wallet-management middleware, settlement bots, and backend service roles as first-class custody surfaces in architecture, access review, monitoring, and tabletop exercises.
  • Make upstream workflows propose bounded actions rather than finalize unlimited ones. The downstream signer or contract should still enforce objective ceilings on amount, destination class, mint budget, and collateral sanity.
  • Bind approval policy to exact settlement truth: exact destination, asset, amount, and request type, not just authorized backend called the expected function.
  • Partition action lanes after authentication. A workflow that can originate routine customer payouts should not automatically originate treasury drains, authority rewrites, minter grants, or emergency rescues under the same ceremony and budget.
  • Require stronger dual control for unusual or high-value request origination, especially for bulk wallet sweeps, emergency withdrawals, admin rescues, or issuance completions that materially change liabilities.
  • Keep per-asset and per-destination rate limits, daily withdrawal ceilings, issuance caps, and anomaly-triggered circuit breakers live even when the request comes from a fully authenticated internal role.
  • Encode weaker-trust operating modes ahead of time. If one vendor, one backend, or one operator cohort becomes the only live origination path, narrow destinations, amounts, and privileged action classes automatically.
  • Minimize standing authority in vendors, workstations, CI/CD, and cloud sessions. Short-lived credentials and narrow service roles should be the default around action-authoring systems.
  • Preserve high-fidelity logs of request creation, mutation, approval, routing, and execution so responders can compare what the workflow authored with what policy should have allowed.
  • Rehearse how to freeze just the compromised origination surface without freezing every settlement path in the business.
  • When authority is supposed to migrate away from one workstation, vendor, deployer, or service role, require an explicit post-migration privilege inventory proving the old surface no longer authors or finalizes production actions.

Audit prompts

  • Which three questions are enforced separately today: what origination lanes remain production-reachable, what exact request fields stay bound to approved settlement truth, and what post-authentication budget each surviving lane still deserves under the current operating mode?
  • What exact offchain workflow can originate a request that the downstream signer, wallet, or contract will mostly rubber-stamp as legitimate?
  • Which request fields can one employee session, vendor environment, or backend role still choose unilaterally: destination, asset, amount, fee, settlement parameter, bridge target, or mint size?
  • If the action-authoring workflow is fully compromised, what hard protocol or wallet-level ceilings still prevent catastrophic value extraction, and what is the actual maximum loss budget for that lane over one hour or one day?
  • Are high-value or unusual requests independently challenged, or do they receive the same low-friction treatment as routine payouts?
  • Does any policy engine validate the exact calldata or settlement envelope, or is the system mostly trusting the upstream workflow’s own interpretation of the request?
  • Can the same authenticated origination lane also rewrite future authority — signer set, minter role, endpoint, module, owner, or rescue path — in addition to moving value today?
  • How would the system detect a valid but absurd request: sudden bulk wallet movement, destination rotation, implausible mint target, repeated micro-requests with huge target amounts, or off-hours settlement bursts?
  • Which cloud IAM roles, KMS policies, vendor consoles, or employee endpoints can silently become request-authority bottlenecks?
  • If the system falls back to one live backend, vendor, or emergency operator path, what permissions and budgets shrink automatically, and where is that policy enforced?
  • Can responders suspend or narrow one compromised request-production path quickly enough that ordinary authenticated actions do not continue draining funds meanwhile?
  • Which supposedly retired or migrated operator paths — old deployers, hot wallets, vendor consoles, service roles, or emergency admins — can still originate legitimate production actions if compromised tonight?

Lessons that should already be standard

  • This lane can still author requests, this specific request still preserved approved settlement truth, and this lane still deserves ordinary authority budget are three different claims. Operator incidents get expensive when teams collapse them into one binary authenticated internal workflow conclusion.

  • The backend role that authors a legitimate action is often more dangerous than the final signer that merely authenticates it.

  • HSMs, MPC, and KMS only protect key use. They do not save a system that lets a compromised workflow choose economically absurd but syntactically valid actions.

  • Authorized request is not the same thing as safe request. Protocol-protective ceilings must still exist after authentication succeeds.

  • Valid backend auth is not a treasury budget. One healthy-looking internal workflow should not automatically inherit deep-reserve, mint, and authority-mutation reach.

  • Vendors and internal middleware are not outside the custody boundary if they can decide destination, amount, or settlement semantics.

  • The cleanest onchain traces in these incidents are often the most misleading: ordinary-looking privileged calls can still reflect a complete collapse of upstream action authorship.

  • Continuity under weaker operator trust is not free. If failover or emergency mode leaves one workflow more central, that workflow should carry less authority, not the same healthy-mode release budget.

  • Fast, scoped kill switches for request origination are as important as strong signing when the real authority lives one step earlier.

  • High-signal incidents:

    • authorized-withdrawal drain (2023-07-22) — the critical-workstation exemplar, where compromise of a key employee environment let the attacker originate authorized hot-wallet withdrawals through normal operational rails.
    • transaction-request manipulation BTC drain (2024-05-31) — the vendor request-path exemplar, where TraderTraitor used Ginco-side infrastructure access to tamper with the path carrying a legitimate DMM transaction instruction, append unauthorized data, and turn wallet middleware into real BTC outflow authority.
    • hot-wallet drain (2023-09-23) — the cloud-control-plane exemplar, where compromise of a provider-hosted database or adjacent service boundary was enough to trigger broad wallet sweeps across Ethereum, Bitcoin, and stablecoin balances.
    • [[../../../incidents/operator-compromise-custody/resolv-usr-counter-service-role-kms-compromise-unbacked-mint-eth-extraction-2026-03-22|Resolv USR Counter SERVICE_ROLE KMS compromise / unbacked mint + ETH extraction (2026-03-22)]] — the service-role settlement exemplar, where compromising the environment that could speak as SERVICE_ROLE let attackers finalize tiny legitimate requests with attacker-chosen targetAmount values and print 80M USR.
    • USDO minter addition + vesting-rescue drain (2024-10-18) — the residual-admin-path exemplar, where a supposedly superseded engineer hot wallet could still originate legitimate production admin actions powerful enough to add a USDO minter, seize vesting ownership, and turn that authority directly into pool-exitable balances.

Internal linkages

Control surface

Graph View

Backlinks