Cowrie Research

compromise-class-authority-rotation-and-residual-revocation-discipline

13 min read

Compromise-Class Authority Rotation and Residual-Revocation Discipline

  • Name: compromise-class authority rotation and residual-revocation discipline
  • Category: incident-response reference / signer-rotation checklist / residual-authority revocation note / compromised-trust-boundary response discipline
  • Summary: When a signer class, wallet-generation tool, custody workflow, browser bundle, backend service role, or transaction-authoring surface is plausibly compromised, healthy teams do not stop at move balances, pause the UI, or replace the obvious hot wallet. They inventory every surviving authority object reachable by that compromised class — admins, owners, module installs, minter roles, bridge endpoints, vault operators, signer allowlists, emergency delegates, withdrawal lanes, and downstream trust assumptions — then rotate or revoke those rights as one response object. This note preserves the positive-design companion behind Wintermute, Tapioca, ALEX XLink, Radiant, and adjacent operator incidents: compromise response must rotate authority, not only assets.
  • Why this note exists:
    • operator-boundary-opacity preserves the failure family where the real authority boundary was already smaller or stranger than the public story.
    • authorized-action-origination-compromise preserves the adjacent family where a backend or custody workflow already authored legitimate-looking requests before the final signer acted.
    • blind-sign-payload-substitution preserves the representation-layer cousin where humans approved one thing while authentic execution authorized another.
    • What still deserves its own positive-design note is the response question on the other side of those incidents: once a key class, signer lane, transaction-authoring service, or admin workflow is suspected compromised, what exactly has to rotate before the system can honestly say the boundary changed?
    • The recurring operational mistake is to evacuate balances or patch the most visible surface while leaving the compromised class embedded inside some quieter owner list, bridge endpoint roster, rescue path, or privileged execution lane.

The core design rule

A compromised trust boundary is not remediated until every authority object reachable through that boundary has been rotated, revoked, quarantined, or explicitly narrowed.

Healthy systems should not let these remain equivalent:

  • we moved funds away from the compromised wallet
  • the compromised wallet can no longer govern, upgrade, release, mint, rescue, or redirect production value

What this note means by compromise class

  • Compromise class means the shared trust root that should now be treated as suspect: a vanity-address generator family, a custody browser bundle, one Safe proposal service, one KMS role, one signer workstation image, one transaction-authoring backend, one recovery vendor, or one emergency key lane.
  • Authority rotation means replacing not only the exposed secret material but also every live permission edge that still trusts that class.
  • Residual revocation means finding the leftovers teams miss first: stale owner slots, module permissions, bridge endpoint signers, minter roles, migration helpers, rescue authorities, or fallback delegates that still accept the old class as truth.
  • The decisive question is not which wallet lost money first? but what else would still obey that same compromised trust root tomorrow?

The five separations healthy response should preserve

1. Balance evacuation versus authority evacuation

  • Sweeping assets away from a compromised key can reduce immediate loss while leaving the real control plane untouched.
  • Wintermute is the cleanest example: moving ETH out of the Profanity vanity EOA did not matter once the same EOA still retained admin rights over the live vault.
  • Healthy response treats where the money sits and what the compromised boundary can still command as separate inventories.

2. Key replacement versus trust-boundary replacement

  • Replacing one signer or rotating one seed is insufficient if the same browser bundle, authoring service, KMS policy, recovery path, or signer workstation remains authoritative.
  • If the attacker compromised the lane that creates authentic-looking actions, the response has to rotate the lane, not only the credentials flowing through it.
  • This is why UI, proposal-service, and workflow compromises often require a wider response than raw key theft.

3. Primary-path shutdown versus residual-path shutdown

  • Teams usually patch the obvious production path first: the hot wallet, the frontend, the bridge lane, the owner address displayed in docs.
  • Attackers look for the quieter siblings: module installs, rescue roles, forgotten owner slots, signer allowlists, emergency delegates, route-local release paths, or stale deployer privileges.
  • Tapioca and Wintermute both preserve the lesson that thought it had already moved is not the same thing as no longer live.

4. Temporary continuity versus full-value operation

  • If the effective threshold worsens during incident response, permissions should narrow before continuity resumes.
  • Healthy systems fall into named degraded modes: lower withdrawal caps, no upgrades, no endpoint rewrites, no new mint authority, no fast-path bridge releases, tighter destination allowlists, and explicit review for any privileged action.
  • We kept operating while we investigated is only acceptable if the remaining operation ran under a smaller, clearly bounded trust model.

5. Internal rotation versus downstream de-recognition

  • Remediation is incomplete if downstream systems still trust the compromised boundary.
  • Collateral engines, wrappers, route registries, bridge peers, governance dashboards, and counterparties may still honor old signers, old endpoints, old admins, or old attestations unless they are explicitly told not to.
  • Response should therefore rotate both the authority itself and the systems that consume it as truth.

What sound design looks like

1. One compromise-class inventory

  • Incident response should begin with one shared sheet of everything that trusts the suspected boundary:
    • signer addresses and multisig owners
    • proxy admins and upgrade roles
    • module / plugin installs and delegatecall lanes
    • minter, rescuer, pauser, and operator roles
    • bridge endpoints, DVNs, relayers, and signer sets
    • KMS roles, backend settlement authoring paths, and proposal services
    • downstream contracts or counterparties that still honor those identities
  • The key test is whether responders can answer what still obeys this compromised class right now? without ad hoc archaeology.

2. One authority-rotation object, not many isolated fixes

  • Healthy teams do not rotate owners in one place, pause routes somewhere else, and remember stale rescue roles days later.
  • They define one response object that names the compromised class and every required revocation, replacement, cap reduction, and downstream notification attached to it.
  • One compromised trust root should produce one bounded rotation plan.

3. Residual rights treated like first-class liabilities

  • Old deployers, migration helpers, fallback owners, endpoint signers, and emergency delegates are not cleanup debt during an incident.
  • They are live liabilities with the same priority as obvious treasury balances.
  • Response quality is often determined by how quickly the team finds these quieter rights.

4. Degraded-mode privilege narrowing by default

  • If a system must keep running before full rotation finishes, it should drop into a lower-trust mode automatically:
    • remove upgrade authority from everyday signer lanes
    • pause bridge routes or cap route-local releases
    • disable module installs and arbitrary-call helpers
    • freeze minter admission and rescue flows
    • require slower out-of-band review for privileged actions
  • A compromise class should shrink privileges before it regains confidence.

5. Public trust-boundary reset, not vague reassurance

  • Users and counterparties need a concrete answer to what changed?
  • Healthy communication can say:
    • which signer / workflow / vendor class is considered compromised
    • which authorities were revoked or rotated
    • which surfaces remain in degraded mode
    • what downstream trust assumptions should now be treated as invalid
  • Funds are safe now is weaker than the old admin class no longer controls upgrades, withdrawals, or releases anywhere in the system.

High-signal contrast cases

  • Wintermute is the cleanest balance sweep without authority revocation exemplar: the vanity EOA’s direct ETH was moved, but its admin rights over the live vault survived.
  • Ronin preserves the stale-delegation cousin: the hard lesson was not only four Sky Mavis validators were compromised, but also that the temporary Axie DAO gas-free-RPC signing accommodation had never been extinguished as live bridge authority.
  • Tapioca preserves the we thought authority had already migrated version, where a hot wallet still sat above production minter and rescue reality.
  • ALEX XLink preserves the bridge-control-plane version, where compromise response had to rotate endpoint and route authority, not merely one wallet balance.
  • Radiant preserves the admin-multisig version, where compromise of the owner lane meant the protocol needed a full trust-boundary reset around upgrade and ownership truth.
  • Bybit and WazirX preserve the representation-layer cousin: when the signer-review surface itself is compromised, response must rotate proposal and rendering trust, not only signer devices.

Design questions worth asking first

  • What exact trust root do we believe is compromised: one key, one signer class, one browser bundle, one proposal service, one KMS policy domain, one recovery path, or one vendor-operated control plane?
  • Which live authorities still trust that root today, even if they are not part of the main product path?
  • If we stopped looking only at balances and instead looked at permissions, what admin, upgrade, release, mint, rescue, routing, or endpoint powers would still survive?
  • Which downstream systems, peers, or counterparties would still treat the old boundary as authentic even after our internal team stopped doing so?
  • What privileges should narrow immediately while rotation is incomplete?
  • What evidence will prove the old class no longer holds production authority anywhere meaningful?

Red flags that usually mean response is incomplete

  • We swept the wallet without a full inventory of owner, admin, module, minter, or endpoint roles
  • The compromised address is no longer used while contracts still trust it
  • The frontend is back even though the proposal or rendering lane that authored malicious actions has not been replaced
  • We rotated the signer but left the same browser bundle, KMS policy, backend service, or vendor control plane in charge of semantic truth
  • Only one route was affected while sibling bridge lanes, rescue paths, or module installs still honor the same compromised class
  • The multisig is still secure when the attacker actually compromised the service or representation layer above that multisig
  • We paused upgrades but left minter, release, rescue, or owner-transfer lanes live under the same suspect boundary

Failure-prevention checklist

  • Maintain a compromise-response inventory template that enumerates owners, admins, modules, minter roles, bridge endpoints, signer sets, backend authoring paths, KMS roles, recovery paths, and downstream trust consumers before any incident happens.
  • Treat compromise by class, not only by address. If one signer lane, proposal service, wallet generator, or vendor boundary is suspect, review every permission edge that depends on that class.
  • Separate balance evacuation from authority evacuation in the runbook. Require responders to prove both where assets moved and which rights were revoked.
  • Predefine degraded modes for trust-boundary incidents: lower caps, disable upgrades, freeze endpoint rewrites, block module installs, pause new mint authority, and narrow bridge releases while rotation is underway.
  • Revoke residual rights aggressively: stale owners, migration leftovers, founder rescue hooks, route-local operators, module delegates, and undocumented emergency paths should be assumed live until explicitly removed.
  • Require downstream de-recognition steps: counterparties, wrappers, route registries, bridge peers, dashboards, and governance tooling should stop trusting the old boundary as part of remediation, not as later cleanup.
  • Preserve one shared response object per compromised boundary so owners, ops, and comms teams do not silently fix different subsets of the authority graph.
  • Keep privileged action classes segregated enough that a compromised operational lane cannot both continue routine withdrawals and redefine authentic future control at the same time.
  • Publish a trust-boundary reset note after response: what class was compromised, what authorities were rotated, what residual surfaces remain, and what narrower operating mode applies until full rotation completes.
  • Rehearse old key class is suddenly suspect scenarios so the team can rotate permissions faster than attackers can enumerate residual rights.

Audit prompts

  • If one signer class or operator workflow were declared compromised right now, could the team enumerate every live authority edge that still trusts it within minutes?
  • Which permissions would survive even after balances are moved away: upgrade admin, proxy owner, module install, minter role, rescue path, bridge endpoint, signer allowlist, or backend settlement authority?
  • Are degraded-mode caps and privilege reductions tied to trust-boundary compromise, or would operations silently continue at full authority while rotation is incomplete?
  • Which downstream systems continue to trust the old boundary, and how would responders notify or disable them?
  • Do any incident runbooks prove the negative property that the old class no longer holds authority anywhere, or do they only describe the visible wallet rotation?
  • Which stale or low-frequency paths would responders be most likely to miss: migration helpers, founder wallets, endpoint rosters, emergency delegates, or module-based side doors?
  • If the compromised boundary sat above proposal rendering or request origination, what exact replacement proves human review and executed bytes are once again tied to a different trust root?
  • What evidence would let an external reviewer conclude the old class cannot still move value or redefine control through some residual path?

Lessons that should already be standard

  • Sweeping balances is not the same thing as rotating authority.
  • A compromised signer class usually survives longest in the permissions nobody was actively thinking about.
  • Tooling compromise is governance compromise if the tooling still defines who can author authentic action.
  • The first trustworthy post-incident claim is rarely all clear; it is the old class no longer controls these named surfaces, and these other surfaces remain degraded until rotation finishes.
  • Residual rights are where remediation quality shows up. Anyone can rotate the obvious wallet; strong teams also kill the forgotten owner slot and the quiet rescue hook.
  • Trust-boundary resets need downstream consumers. If integrators still honor the old signer, endpoint, or admin as authentic, the compromise is only partially remediated.
  • We already moved off that key is not evidence unless the old key class has also been stripped of every surviving production permission.

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks