Cowrie Research

concentric-fi-deployer-wallet-compromise-malicious-vault-upgrade-drain-2024-01-22

11 min read

Concentric.fi Deployer-Wallet Compromise / Malicious Vault-Upgrade Drain (2024-01-22)

  • Name: Concentric.fi deployer-wallet compromise / malicious vault-upgrade drain
  • Date: 2024-01-22
  • Protocol: Concentric.fi
  • Chain: Arbitrum
  • Category: privileged upgrade abuse / deployer-wallet compromise / malicious implementation swap / approval spillover
  • Loss: Concentric’s own immediate post-mortem put the vault drain at 715.7 ETH (about $1.7M at the time); CertiK’s broader tally added roughly 65.4 ETH of user-approved token theft for total losses around 780 ETH or about $1.85M
  • Summary: A targeted social-engineering attack compromised a Concentric team member who controlled the deployer wallet. With that key, the attacker transferred ownership over Concentric’s factory / upgrade surface, upgraded live vaults to a malicious implementation containing an admin mint path, minted bogus CONE-1 LP claims to an attacker-controlled address, then burned those claims to pull real ERC-20 assets out of the vaults. Public incident analysis also describes a second attacker-controlled contract that used pre-existing user token approvals to steal additional wallet funds. The decisive failure was not a user-callable vault bug; it was that one compromised deployer/admin key could redefine what the vault logic was.
  • Trigger / entry point:
    • Concentric disclosed that the initial compromise came from a recruiter-style social-engineering lure that led a team member with deployer-wallet access to run malware.
    • That deployer/admin wallet appears to have had authority to transfer ownership of Concentric’s production factory / upgrade path.
    • Once the attacker held that authority, they could point live vaults at a new implementation without needing to defeat the prior business logic at all.
    • The malicious implementation included an admin mint capability that let the attacker fabricate CONE-1 LP balances and then redeem them for underlying vault assets.
  • Root cause:
    • Concentric’s real custody boundary sat in the deployer / admin wallet that controlled vault ownership and upgrades.
    • The production architecture let a compromised operator credential become immediate implementation-swap authority over live TVL.
    • There was no effective separation between deployment authority and production upgrade authority strong enough to contain a single-wallet compromise.
    • Because the vaults honored minted LP balances as withdrawal entitlement, malicious logic only needed to exist long enough to print fake claims against pooled assets.
  • Exploit path:
    1. A Concentric team member with deployer-wallet access was compromised in a targeted social-engineering / malware attack, according to Concentric’s own post-mortem.
    2. In ownership-transfer transaction 0xd9036566a2614045219e9bead34e490fc24c9d6ca695d5348b694c3280558e3b, the attacker shifted control over the ConeCamelotFactory upgrade surface to an attacker-controlled address.
    3. In upgrade transaction 0xb2fa31c9bc7d5e41955cb81224545588c1a0746b8564f14a2e143dc56364020a, the attacker upgraded the live Concentric vaults to malicious implementation 0xF36C407F3C467e9364Ac1b2486aA199751BA177D.
    4. CertiK reported that the modified implementation could burn CONE-1 from Concentric vault accounting and mint new CONE-1 to attacker-controlled recipient 0x105f52fcc329cef4cbe25bc946f8a3738414e4a1.
    5. The attacker then called the malicious mint path to fabricate LP balances, burned those LP tokens, and withdrew the corresponding underlying ERC-20 assets from affected vaults.
    6. Concentric’s post-mortem says the primary vault drain totaled 715.7 ETH worth of assets and initially flowed through 0x105f52fcc329cef4cbe25bc946f8a3738414e4a1.
    7. CertiK additionally reported that attacker-controlled contract 0xc62A25462A61f02EBAB35Cd39C5E9651426e760b drained assets from users who had previously approved Concentric-related contracts, adding about 65.4 ETH of wallet losses on top of the vault drain.
    8. Stolen assets were swapped into ETH and split across downstream wallets including 0xFD681A9aA555391Ef772C53144db8404AEC76030, 0x1F14E38666cDd8e8975f9acC09e24E9a28fbC42d, and 0x17865c33e40814d691663bC292b2F77000f94c34.
  • What the attacker needed to be true:
    • A single compromised team wallet had to retain meaningful production authority over vault ownership and upgrades.
    • The upgrade path had to allow a new implementation to go live quickly enough that no timelock, review gate, or independent signer could stop it.
    • Vault withdrawal entitlement had to be represented by mutable LP accounting that a malicious implementation could rewrite or mint against.
    • Users needed to have left token approvals outstanding if the attacker was going to monetize the incident beyond the vault drain itself.
    • Concentric’s contracts had to keep enough liquid underlying assets on hand for minted LP claims to cash out immediately.
  • Technical anatomy worth remembering:
    • This is a clean example of admin key compromise -> upgrade authority -> fake entitlement mint -> real asset withdrawal, not a conventional invariant break in the original vault math.
    • The attacker did not need to find a subtle path around Concentric’s normal deposit / withdrawal rules. They temporarily changed the rules.
    • The user-approval theft matters because it shows how admin compromise can spill beyond protocol TVL into wallets that trusted the protocol’s contracts previously.
    • The social-engineering setup happened offchain, but the money loss was still completely legible onchain: ownership transfer, implementation swap, fake LP mint, burn, withdraw, bridge / swap / split.
  • Representative transactions and addresses:
    • Ownership-transfer tx: 0xd9036566a2614045219e9bead34e490fc24c9d6ca695d5348b694c3280558e3b
    • Malicious upgrade tx: 0xb2fa31c9bc7d5e41955cb81224545588c1a0746b8564f14a2e143dc56364020a
    • Malicious implementation: 0xF36C407F3C467e9364Ac1b2486aA199751BA177D
    • Primary drainer / LP recipient: 0x105f52fcc329cef4cbe25bc946f8a3738414e4a1
    • Secondary approval-drainer contract highlighted by CertiK: 0xc62A25462A61f02EBAB35Cd39C5E9651426e760b
    • Downstream ETH receivers highlighted by Concentric / CertiK: 0xFD681A9aA555391Ef772C53144db8404AEC76030, 0x1F14E38666cDd8e8975f9acC09e24E9a28fbC42d, 0x17865c33e40814d691663bC292b2F77000f94c34
  • Response / mitigation:
    • Concentric publicly disclosed the compromise the same day and published an immediate post-mortem describing the social-engineering entry point and the upgrade-based drain sequence.
    • The team said it engaged security researchers, blockchain analytics providers, exchanges, and law enforcement in an attempt to trace and freeze the stolen funds.
    • Concentric also announced a $100,000 reward pool for information leading to recovery.
    • The durable mitigation lesson is architectural: deployer keys, factory ownership, and upgrade rights over live TVL need to be treated as custody, not as mere DevOps convenience.

Pattern tags

  • Privileged upgrade abuse
  • Signer-quorum compromise
  • A socially engineered deployer compromise became immediate factory-ownership capture, so who can upgrade? and who can deploy? had effectively collapsed into one live custody boundary
  • The malicious implementation did not need to invent a new withdrawal path; it only needed to mint fake CONE-1 withdrawal entitlement long enough for ordinary burn / redeem logic to pay out real assets
  • Standing ERC-20 approvals widened the blast radius beyond vault TVL, turning the same operator compromise into follow-on wallet theft through a second attacker-controlled contract

Why the exploit worked

  • Concentric’s decisive trust anchor was not its published vault logic but the deployer-controlled ownership path above ConeCamelotFactory and the live vault implementations beneath it. Once the attacker held that key, they no longer needed to defeat the original vault rules.
  • The protocol let one compromised operator credential move directly from factory ownership transfer to live implementation replacement without a slower independent review lane, higher quorum, or meaningful execution delay.
  • Vault withdrawal entitlement remained implementation-defined. That meant the malicious code only had to mint or reassign enough CONE-1 accounting to make normal burn / redeem flows release the pooled ERC-20 assets.
  • The incident also exposed a second latent release surface: users who had previously approved Concentric-related contracts extended the exploit from protocol TVL into wallet balances once the attacker introduced a second malicious contract.
  • Put bluntly, Concentric did not lose funds because users found a bug in the vault math. It lost funds because one socially engineered operator compromise was allowed to redefine what the vault math meant.

Detection and audit pivots

  • Map the real root-control chain before looking at vault math: which EOA or multisig can transfer factory ownership, replace implementations, or otherwise rewrite the logic that defines LP entitlement and redemption?
  • Treat ownership transfer plus implementation upgrade in rapid succession as one compound custody event, not two routine admin actions. If those two steps can happen from the same compromised credential, the effective threshold is lower than the team may advertise.
  • Review whether vault-share supply, LP accounting, or receipt-token balances are mutable by upgraded logic in ways that can immediately cash out against live pooled assets.
  • Audit all standing approval surfaces around the protocol, not just the vaults themselves. Concentric is a reminder that admin compromise often monetizes both protocol custody and user approvals in the same incident window.
  • Ask whether incident telemetry would clearly distinguish protocol exploit from root-authority rewrite. The onchain sequence here was legible: ownership transfer, malicious upgrade, fake entitlement mint, burn, withdrawal, then wallet-approval theft.

Failure-prevention checklist

  • Separate deployment convenience from production root authority. Deployer wallets, factory owners, proxy admins, and implementation registries should be treated as custody-critical signers with stronger ceremony than ordinary engineering operations.
  • Split routine maintenance from future-authority mutation. Ownership transfers, implementation upgrades, and factory-admin changes should not share the same fast lane as ordinary operational actions.
  • Put delay or independent confirmation between new code authorized and new code controlling live pooled assets, especially where upgraded logic can mint or rewrite withdrawal entitlement.
  • Minimize what an upgraded implementation can do immediately to user claims: stage migrations, cap emergency mint authority, and design post-authentication bounded-loss controls so one malicious upgrade cannot instantly drain all reserves.
  • Rehearse operator-compromise containment around the real control plane: revoke upgrade rights, rotate deployer material, freeze factory-level authority, and inventory all still-live approval surfaces users may have granted to protocol contracts.
  • Treat broad user approvals as part of blast-radius design. Approval hygiene, scoped spend paths, and rapid revoke guidance matter because admin compromise often spills into wallet theft once protocol trust has already been captured.

Audit prompts

  • Which exact wallet, multisig, or factory owner can replace the implementation that defines vault-share supply and redemption logic today?
  • Can one signer domain both transfer ownership and execute upgrades, or is there a hard separation between who ships code and who makes code authoritative over live TVL?
  • If a malicious implementation were installed for one block, what exact accounting objects could it mint, burn, rewrite, or redeem immediately against pooled assets?
  • What execution delay, second quorum, timelock, or out-of-band review still stands between a compromised deployer path and live asset withdrawal?
  • Which user approvals remain dangerous if protocol admin authority is captured, and how quickly could the team identify and message affected users?
  • Would defenders be able to tell within minutes whether an incident is bad vault math or root-control rewrite, and do they have different containment playbooks for those cases?

Lessons that should already be standard

  • A deployer key that can still move factory ownership or implementation authority is already a custody key, even if the team mentally classifies it as engineering tooling.
  • Upgrade authority is often more dangerous than a direct treasury key because it can mint fake entitlement inside flows that still look like ordinary withdrawals.
  • The vault logic was audited is not a full defense if one compromised operator path can replace that logic immediately.
  • Standing user approvals are part of protocol blast radius. When root authority is captured, attackers often monetize wallets and protocol TVL together.
  • Social engineering belongs inside DeFi threat models whenever one human workstation sits above live upgrade or ownership authority.

Why this incident matters

  • It is a good privileged-upgrade-abuse case where the precursor was not insider malice or multisig poisoning, but a socially engineered compromise of a single deployer/operator wallet.
  • It also shows how upgrade authority can be more dangerous than a direct treasury key because it can print fake withdrawal entitlement inside otherwise normal user-facing flows.
  • It preserves a cleaner design lesson too: execution-envelope identity pinning explains why the protocol needed to treat factory ownership + implementation authority as one privileged root-control object; privileged-action lane separation and ceremony escalation explains why deployer convenience should not have shared a fast lane with production authority over live TVL; operator topology map and effective-threshold discipline explains why one workstation compromise was enough to reach the real threshold; and post-authentication bounded-loss design explains why even a captured upgrade path should not have been able to mint immediate full-value withdrawal rights.
  • The incident is also a useful reminder that standing user approvals can widen the blast radius of an admin compromise beyond protocol-owned balances alone.

Internal linkages

Control surface

Graph View

Backlinks