OAK — OnChain Attack Knowledge

Technique · OAK-T11.014 · emerging

OAK-T11.014 — Operator Privileged-Key Compromise

Parent Tactics
OAK-T11 (Custody and Signing Infrastructure)
Adjacent Techniques
OAK-T11.001 (Third-Party Signing / Custody Vendor Compromise — there the key stays with its honest holder and the intent signed is substituted; here the attacker holds the key), OAK-T11.002 (Wallet-Software Distribution Compromise — the attacker ships malicious wallet software; not a stolen operator key), OAK-T11.011 / OAK-T11.012 (specific key-storage defects — map those instead when the storage failure is known), OAK-T10.001 (Validator / Signer Key Compromise — the bridge- and validator-set analogue), OAK-T6.005 (Proxy-Upgrade Malicious Switching — the common use of a stolen upgrade key), OAK-T5.003 (Hidden-Mint Dilution — the common use of a stolen minter key)
Maturity
emerging
Chains
chain-agnostic
First documented
2021-04 (EasyFi admin key) as the earliest corpus anchor at this layer; the class is older
Aliases
"admin-key compromise", "deployer-key compromise", "minter-key compromise", "proxy-admin key theft", "owner key leak", "operator key compromise"

Description

An attacker obtains a private key that a protocol or project operator uses to exercise privileged authority — contract owner, proxy admin, upgrader, minter, LayerZero delegate, treasury or operational hot wallet — and uses it exactly as the contract allows. Nothing on-chain is bypassed: the contract checks the signature, the signature is valid, and the privileged function runs. The defect is that one key, held by one party, could do this at all, and that it left the operator's control.

The Technique records the key compromise as the load-bearing event and is deliberately agnostic about how the key was obtained, because in most public cases that is never disclosed. When the entry vector is known, map it alongside: social engineering of the key holder (OAK-T15.001), developer-endpoint compromise (OAK-T15.003), credential/cloud compromise (OAK-T15.004), insufficient entropy (OAK-T11.004), raw server-side key storage (OAK-T11.012), keys for several chains on one host (OAK-T11.011). When the vector is unknown, T11.014 alone is the honest mapping.

T11.014 was minted in 2026-10 because these cases had no home. The corpus had filed them under T9.004 (Access-Control Misconfiguration, which misdescribes a correctly enforced check), under T11.002 "broadly construed" (which is about compromised wallet software distribution), under T11.001 (honest key, substituted intent), and in one case under T4.003 (address poisoning). Several files said so explicitly — "no T11 sub-Technique covers generic operator-key compromise with an unestablished vector".

Observed indicators

  • A privileged function (mint, upgrade, ownership transfer, role grant, peer or delegate configuration, treasury transfer) called by the legitimate privileged address at an unusual time, to an unusual destination, or followed immediately by liquidation of the proceeds.
  • Ownership or admin rights transferred to a fresh address, then exercised within minutes.
  • An upgrade to an implementation that was not published, audited, or announced.
  • Supply minted far outside historical mint sizes, then sold into thin pools.
  • Operator statements naming "a compromised key", "leaked private key", or "unauthorised access to the upgrade authority" without describing a contract bug.

Detection signals

  • Privileged-action monitoring: alert on every call from owner / admin / minter / upgrader addresses; these are rare enough that per-call review is affordable.
  • Mint-size and destination anomalies: mint amounts relative to history; mints to addresses with no prior relationship to the protocol.
  • Upgrade provenance: implementation bytecode with no matching published source or governance record.
  • Post-action liquidation proximity: privileged action followed within a short window by large DEX sales or bridge exits from the beneficiary.

Real-world examples

Additional incidents

Reference implementations

  • mg-detectors-rs — coverage gap. Privileged-call monitoring is a configuration problem (knowing which addresses are privileged), not a detection-logic problem.

Mitigations

  • Remove single-key authority: privileged roles behind a multisig with independent signers and hardware-backed keys; no deployer EOA retains authority after launch.
  • OAK-M11 (Rate-Limiting and Per-Block Caps): mint caps, transfer caps and withdrawal limits bound what a stolen key can do in one window.
  • Timelocks on upgrades and role changes: convert an instant drain into a public, cancellable proposal.
  • Rotate on personnel change: Ankr's key was usable by a former employee; access reviews are a key-management control.

Discussion

Why not T9.004. In T9.004 the contract permits something it should not. In T11.014 the contract permits exactly what it should — to the holder of a key that should never have been in a position to be stolen, or never have had unbounded authority. Filing these as access-control bugs sent defenders to audit code that was correct.

Why not T11.002. T11.002 is the attacker shipping malicious wallet software to users (Ledger Connect Kit, compromised extensions). A stolen operator key does not involve distribution at all.

Insider ambiguity. Many cases cannot distinguish external theft from insider action (79th Vault, Force Bridge). The on-chain shape is identical; record the operator's account, note the insider alternative, and keep attribution neutral.

Parent Tactics

Worked examples (18)