Cowrie Research

wintermute-defi-hot-wallet-profanity-vanity-key-bruteforce-admin-redirection-drain-2022-09-20

14 min read

Wintermute DeFi Hot Wallet Profanity Vanity-Key Brute Force / Admin-Redirection Drain (2022-09-20)

  • Name: Wintermute DeFi hot wallet Profanity vanity-key brute force / admin-redirection drain
  • Date: 2022-09-20
  • Protocol: Wintermute
  • Chain: Ethereum
  • Category: private-key compromise / predictable vanity-address generation / privileged admin redirection / operator-boundary opacity
  • Loss: about $160M to $162.5M
  • Summary: Wintermute’s DeFi loss was not caused by a vault math bug or an AMM invariant failure. The decisive break happened earlier, when an attacker recovered the private key for vanity EOA 0x0000000fE6A514a32aBDCDfcc076C85243De899b, which public investigators tied to the vulnerable Profanity address generator. That compromised EOA was still an admin on Wintermute vault contract 0x00000000AE347930bD1E7B0F35588b92280f9e75. After funding the compromised admin with 2 ETH, the attacker repeatedly called privileged function selector 0x178979ae to redirect assets from the vault into attacker contract 0x0248f752802B2CFB4373Cc0C3Bc3964429385c26, reportedly doing so 109 times. Wintermute had already moved ETH out of the vanity EOA after the 1inch warning, but it had not removed the address from the vault’s admin set, so a recovered private key still translated directly into live treasury authority.
  • Trigger / entry point:
    • On 2022-09-15, 1inch publicly warned that Profanity generated 256-bit private keys from only a 32-bit seed via mt19937_64, making vanity EOAs brute-forceable.
    • Public investigators linked Wintermute’s EOA 0x0000000fE6a514a32aBDCDfcc076C85243De899b to that vulnerable vanity-address pattern.
    • Amber Group later sharpened the operational consequence: once an attacker suspects a Profanity-derived address, any historical signed transaction from that EOA leaks enough signature material to recover the EOA’s public key, which is all the attacker needs to search the much smaller Profanity seed space rather than the full Ethereum private-key space.
    • Mudit Gupta observed that Wintermute removed ETH from the vanity EOA shortly after the disclosure, but left the address authorized as an admin on the vault contract.
    • That meant the real authority boundary was not who still actively uses the EOA? but which addresses still retain privileged vault rights if their keys are recovered later?
  • Root cause:
    • Wintermute relied on a vanity-address generation tool whose entropy model collapsed signer secrecy from a 256-bit private-key space to a tractable 32-bit seed search plus deterministic expansion.
    • The compromised vanity EOA still held privileged admin rights on a live asset-holding contract even after the Profanity warning surfaced.
    • Wintermute’s mitigation was therefore incomplete: moving ETH off the EOA reduced the balance on the key itself but did not revoke the key’s authority over the vault.
    • The incident preserves a useful operator lesson: offchain wallet-generation tooling and stale privileged address lists can be as treasury-critical as the contracts they administer.
  • Exploit path:
    1. The attacker targeted Wintermute’s vanity admin EOA 0x0000000fE6a514a32aBDCDfcc076C85243De899b, which public analyses tied to Profanity-style generation.
    2. Using the Profanity weakness, they recovered the EOA’s private key from the address / public-key relationship rather than exploiting a Solidity bug in the vault itself.
    3. They funded the compromised EOA with 2 ETH in tx 0x93eadb28e6b50e7ed14348a14cfc3c9f09618dace9c20d3f39ab3d5828e3fd21 so it could pay gas.
    4. Starting with tx 0xeecba26d5eb7939257e5b3e646e4bc597b73e256a89cb84a6dfc58de250d8a38, the compromised EOA called Wintermute vault 0x00000000AE347930bD1E7B0F35588b92280f9e75 using privileged selector 0x178979ae.
    5. Instead of sending funds to Wintermute-controlled destinations, those calls redirected assets into attacker contract 0x0248f752802B2CFB4373Cc0C3Bc3964429385c26.
    6. Public reporting said the attacker repeated that privileged drain flow 109 times and later routed portions of the proceeds through stablecoin swaps and other laundering paths.
  • What the attacker needed to be true:
    • Wintermute had to keep using, or at least keep authorizing, an EOA generated through Profanity’s weak seed-expansion process.
    • The attacker needed a recoverable public key for that vanity address, which Ethereum transactions naturally expose through signatures.
    • The compromised EOA needed to remain privileged on a live asset-moving contract after the public disclosure of the Profanity flaw.
    • The vault contract had to treat the EOA’s admin calls as fully authoritative without any stronger second factor, delay, or destination allowlist that would block emergency misuse.
  • Technical anatomy worth remembering:
    • 1inch’s key observation was that Profanity seeded a 256-bit private key from only 2^32 possible initial seeds, then deterministically expanded the rest. That turned recovering a vanity-wallet secret into a feasible search problem rather than an impossible one.
    • Amber Group later showed the attack was not brute-force every possible EOA. Their method was to recover the victim EOA’s public key from a historical signed Ethereum transaction, precompute the Q_0,0 public-key set for all 2^32 Profanity seeds, then walk Profanity’s thread / round arithmetic backward until one candidate matched. In Amber’s reproduction, the one-time precomputation took under 10 hours on a 16GB MacBook M1, the per-address crack for a seven-leading-zero vanity class took about 40 minutes, and the full implementation plus recovery of Wintermute’s key took under 48 hours.
    • Amber also noted a practical optimization that matters for defenders: storing only the lower 8 bytes of each precomputed compressed public key cut the lookup dataset from about 128GB to about 32GB, making the seed-space search much more operationally accessible than teams might assume from the raw 2^32 figure alone.
    • The compromised EOA did not hold the entire treasury directly. Instead, it held admin rights over a separate Wintermute vault contract, so one offchain key compromise became many onchain asset transfers.
    • Mudit Gupta’s early reconstruction is the sharpest operator lesson: Wintermute appeared to understand enough of the Profanity risk to sweep ETH out of the vanity EOA, but not enough to revoke the EOA’s residual admin role on the vault.
    • This is why the case belongs first in operator-compromise / custody rather than contract-exploit taxonomy. The vault executed privileged instructions from an address it was explicitly designed to trust.
  • Representative transactions and contracts:
    • Compromised Wintermute vanity EOA: 0x0000000fE6A514a32aBDCDfcc076C85243De899b
    • Wintermute vault contract: 0x00000000AE347930bD1E7B0F35588b92280f9e75
    • Attacker helper / receiver contract: 0x0248f752802B2CFB4373Cc0C3Bc3964429385c26
    • Attacker funding tx for the compromised EOA: 0x93eadb28e6b50e7ed14348a14cfc3c9f09618dace9c20d3f39ab3d5828e3fd21
    • Early privileged drain tx highlighted by public analysis: 0xeecba26d5eb7939257e5b3e646e4bc597b73e256a89cb84a6dfc58de250d8a38
    • Wintermute ETH-removal tx from the vanity EOA after the Profanity warning: 0x93716f3e3a9e3f47dec05b4df511e07e53b3e4695e84cd4f05f5d83188f3552a
    • Representative pre-exploit tx used by Amber to recover the public key: 0x2b64b221b1a9869fa08d09c5fe2236baee37332b473589f8f90f07ea2ccb2e6b
  • Response / mitigation:
    • Wintermute publicly said the loss hit only DeFi operations and that CeFi and OTC operations were unaffected.
    • The company remained solvent and sought to negotiate with the attacker while continuing operations.
    • The broader ecosystem response was more durable than any one Wintermute statement: projects rushed to rotate funds, revoke admins, and migrate away from Profanity-generated EOAs and smart-contract owners.
    • The deeper mitigation lesson is not only stop using Profanity; it is treat stale privileged addresses as live liabilities even after their direct balances are moved away.

Three residual-admin-authority promotions this incident collapsed

  1. A weak signer class still existed as a live reachable object
    • A Profanity-derived vanity EOA still sat inside Wintermute’s production authority graph.
    • Historical signed Ethereum transactions from that address still exposed enough signature material for investigators to recover the public key and turn the Profanity seed-space weakness into a practical private-key recovery problem.
    • Sweeping ETH off the EOA did not erase the dangerous object; it only changed the visible balance on it.
  2. That signer class still counted as canonical vault-admin truth for this exact action
    • Wintermute’s vault still treated 0x0000000fE6A514a32aBDCDfcc076C85243De899b as a legitimate admin even after the Profanity disclosure and after Wintermute’s own post-disclosure ETH sweep from that address.
    • The real promotion error was not merely the private key might be recoverable; it was this now-suspect key class still defines authentic treasury instructions for the vault.
    • Once the attacker recovered the key, the contract did exactly what its trust model told it to do: accept the compromised EOA’s admin calls as real authority.
  3. That accepted admin truth still deserved immediate treasury-scale redirection authority
    • The vault let one recovered EOA repeatedly redirect assets into attacker-controlled contract 0x0248f752802B2CFB4373Cc0C3Bc3964429385c26.
    • There was no stronger second factor, timelock, destination allowlist, or post-disclosure privilege downgrade standing between valid admin call and large-scale asset movement.
    • That is the preserved design lesson: even after a signer class becomes publicly weak, systems often keep granting it the full operational budget of a healthy root admin.

Pattern tags

Why the exploit worked

  • The exploitable secret was not valuable because it still held ETH; it was valuable because Wintermute’s vault still treated that EOA as a fully trusted admin after the Profanity weakness was already public.
  • Wintermute’s emergency response appears to have recognized the balance risk faster than the authority risk. Sweeping ETH off the vanity account reduced direct wallet exposure but left the more important question unanswered: what production contracts still obey this key if someone recovers it tomorrow?
  • That mismatch between we no longer use this wallet for funds and this wallet still defines treasury truth for a vault is the preserved design lesson. The attack cashed out through residual admin reach, not through residual wallet balance.
  • This is why the incident belongs as much to operator-boundary opacity and decommissioning discipline as to key compromise itself: the real treasury boundary was a stale privileged address list that had not been re-interrogated after the threat model changed.

Detection and audit pivots

  • When a key-generation flaw, leaked seed class, or compromised signer cohort becomes public, inventory residual authority first, not only residual balances. Ask which contracts, multisigs, modules, or vaults would still honor that key class if its secret were recovered later.
  • Treat historical signed transactions as part of the exposure surface. For schemes like Profanity, one old onchain signature can leak the public key needed to turn suspicious vanity address into a tractable seed-space search, even if the address has not been used recently.
  • Diff addresses we swept against addresses we deauthorized. Any gap between the two should be treated as live production risk, especially for admin EOAs that no longer look economically important in ordinary wallet dashboards.
  • Trace every admin-capable address through downstream privileges: owner slots, module installs, vault admin lists, minter roles, bridge endpoints, pause rights, and upgrade controls. A stale single address can quietly sit above a more sophisticated custody stack.
  • Treat public disclosures about weak key material as triggers for decommissioning review, not just wallet hygiene. The right follow-up question is not did we move the money? but did we extinguish every privileged path this secret class can still reach?

Failure-prevention checklist

  • Treat vanity generators, browser extensions, hardware-wallet firmware, signer middleware, MPC vendors, and seed-handling workflows as treasury infrastructure if they can ever originate or preserve privileged addresses. The secret-generation path is part of custody, not an external convenience layer.
  • Maintain one machine-readable inventory of every address that still carries live authority: vault admin roles, owner slots, multisig membership, module permissions, upgrade rights, emergency pause, minter roles, bridge endpoints, and operational allowlists. A wallet is not decommissioned when its balance hits zero; it is decommissioned when that inventory says it has no remaining power.
  • Make compromise-class response playbooks authority-first. For any disclosed weak key family or leaked credential class, responders should revoke or rotate privileges before, or at least in lockstep with, moving balances.
  • Separate funds evacuation from authority extinguishment operationally and verify both. One team can sweep balances while another proves the same key can no longer move treasury assets through any contract-admin surface.
  • Require explicit expiry, review cadence, or retirement triggers for admin EOAs so yesterday’s bootstrap key does not silently outrank today’s more mature custody stack.
  • Minimize single-key authority over live vaults. If a lone EOA must exist temporarily, keep its scope narrow, rate-limited, and easy to revoke rather than letting it retain broad asset-redirection rights indefinitely.
  • Monitor for residual-power drift after incident disclosures: the dangerous state is often no direct balance, still privileged, which ordinary wallet dashboards and treasury views tend to hide.
  • Rehearse suspect key class drills ahead of time: enumerate affected addresses, map downstream privilege reach, rotate contracts and modules, and confirm no stale permissions remain reachable from the compromised secret class.

Audit prompts

  • If one signer class, vanity-tool cohort, seed derivation method, or custody vendor became suspect tonight, which production contracts would still obey it tomorrow morning?
  • Where do we currently conflate wallet no longer funded with wallet no longer trusted? What exact role inventory disproves that shortcut?
  • Which privileged addresses were created for bootstrap convenience, vanity requirements, integration hacks, or historical tooling constraints, and why are they still alive now?
  • Can we produce a complete graph from each admin-capable address to every downstream authority it retains: owners, modules, proxies, vault withdrawals, minter/burner rights, bridge controls, pause powers, or offchain signing permissions?
  • What event automatically forces deauthorization when a key class becomes publicly weak: disclosed entropy failure, leaked seed phrase, broken signer firmware, compromised workstation, or vendor-side intrusion?
  • If an address was last used months ago, would we still notice quickly that it remained an admin somewhere important? Which dashboards or controls make residual authority visible rather than inferring safety from inactivity?
  • Do emergency playbooks require proof that suspect keys lost authority, not merely that balances were swept and new wallets were funded?
  • Could one compromised admin address redirect treasury assets repeatedly before responders intervene, and what rate limits, pauses, destination restrictions, or separation of duties would bound that loss?

Lessons that should already be standard

  • A stale admin key is still a hot wallet for as long as production contracts obey it.
  • Weak-secret disclosures should trigger privilege retirement, not just asset movement.
  • Treasury threat models have to include the tooling that creates keys, not just the contracts those keys later administer.
  • We no longer use that address is meaningless unless the protocol also no longer trusts that address.
  • Authority inventories age just like software inventories. If teams cannot answer quickly which old EOAs still sit above live contracts, the custody boundary is already too opaque.
  • Bootstrap convenience should expire. The temporary single-key admin that helped launch or operate a system is often the least defended component left in the stack once the rest of custody matures around it.
  • Historical signatures and old addresses do not become harmless just because current flows moved elsewhere; they can remain enough to recover keys or re-open authority paths later.

Why this incident matters

  • It is the cleanest large-scale example of a vanity-address generation flaw turning directly into protocol-admin authority, rather than merely draining the EOA’s own wallet balance.
  • It shows how a recovered single-signer key can be more dangerous than a multisig failure if that signer still sits inside the authorization graph of a high-value vault.
  • It also captures a subtle but important failure mode in emergency response: asset evacuation without privilege revocation can leave the real attack surface fully intact.
  • It is also a clean compromised key class response case: once Profanity-derived EOAs were publicly suspect, the real remediation target was every surviving authority edge that still trusted that class, not just the wallet balance users could already see.

Internal linkages

Control surface

Graph View

Backlinks