GoPlus Security 🚦

🚨 GoPlus Security Alert: Brazilian exchange @MercadoBitcoin has experienced abnormal asset outflows from its multichain custody wallets, with losses exceeding $30 million. Some stolen funds have been frozen. MB has suspended deposits and withdrawals following the attack. The stolen assets span at least 9–10 networks, including Bitcoin, Ethereum, Arbitrum, Solana, Tron, Stellar, Polygon, Avalanche, BNB Chain, and XDC. The Ethereum wallet transferred out approximately 2,852 ETH, while the Solana wallet transferred out approximately 10,695.56 SOL. On Bitcoin, alongside a transfer of approximately 104.43 BTC, another transaction spent funds from 54 distinct addresses across 86 inputs. Large XLM, USDC, and EURC outflows were also recorded on Stellar. The underlying issue may involve abuse of hot-wallet signing or transaction authorization systems. Concentrated outflows across multiple chains and simultaneous spending from multiple Bitcoin addresses warrant priority investigation into key management, signing services, and withdrawal approval workflows. These characteristics resemble the earlier Binance theft, but the available evidence does not yet identify a specific threat group. 📌 Attacker-Related IOCs: EVM Receiving Address Across Multiple Chains: 0xe485e7A70b1131216Cb47CA4555c4Bbb2C742478 Bitcoin Receiving Address: 19qGpsHvzh1t6pVi526XNNkh6hW6prDZp Solana Receiving Address: 3YX6WHncP1Ra4AotE9YLawFt4nPmxyux288FWXkEW97J Tron Receiving Address: TEX3HuDRHRa3tnYpy96M4UfSx62VhDyA5L Stellar Receiving Address: GDXYRI6IONQA5YTGRLQ6O3FGJ2BWXPJTTQPUXFPSEXSRKBZLFKMZSOLP 🛡️ Security Recommendations: Exchanges and custodians should strengthen transaction risk controls: check recipient addresses, networks, assets, and transaction amount patterns; enforce delays on withdrawals to new recipient addresses, additional review for large transfers, aggregate limits across chains, and circuit breakers for anomalous outflows. MPC/HSM deployments should be paired with independent authorization policies to limit the damage from compromised administrator privileges. Users should follow official updates and avoid using the service until MB confirms it is secure and service has been restored. Preserve account balance records and transaction records, and watch for phishing exploiting the incident. Obtain updates on service restoration or reimbursement only through verified official channels. Never share passwords, verification codes, private keys, or seed phrases with supposed “reimbursement support.”

9/13 C. Call withdraw to send 4.4904 WBTC from the pool to the attack contract

8/13 B. Execute tiny option trades in the same tx, producing many TransferSingle events

7/13 A. Deposit small WBTC amounts (0.28065, 0.46775…) to establish or adjust LP positions

4/13 (1) An option purchase through the normal trading flow triggered the vault itself to send WBTC into the empty pool. The vault followed its normal underwrite/trade (write) path: buyer paid 0.11714618 WBTC premium; vault locked 3.76125 WBTC collateral into the Premia po

1/13 ⚠️ Exploit Breakdown: Premia Labs Options Vault Attack On November 1, @PremiaLabs vault contracts on #Arbitrum were exploited for over $400,000. The factory allows permissionless deployment of option pools, but the vaults lacked sufficient checks to establish whether those pools were safe to interact with. The attacker created empty pools, used flash loans to buy options and trigger the vaults to lock collateral into those pools, then extracted the collateral through the pools’ liquidity mechanisms. 🔍 Root Cause: Premia v3 separates options trading into two layers: ① Option Pool: Deployed permissionlessly through the factory for a given underlying/quote pair, strike price, expiry, and option type (call or put). Anyone can create a new series. ② Underwriter Vault: Users deposit a single asset. The vault uses those deposits as collateral to write options for buyers and collect premiums. Call vaults hold the underlying asset (WBTC/WETH/ARB), while put vaults hold USDC.e. When a buyer trades with a vault, the vault locks collateral into the corresponding option pool. If the vault checks only whether the pool was deployed by the official factory—without checking its liquidity, age, or whether it is an empty pool controlled exclusively by the attacker—then: • The attacker can deploy a fresh, empty pool with no other LPs. • A flash loan can fund the entire sequence in one transaction: establish a position → trigger the vault to lock collateral into the pool → extract that collateral through liquidity or pool-side accounting mechanisms. • In an empty pool, the attacker effectively controls the entire market and can manipulate the initial trading path and accounting state. 🔗 Attack Flow: 1️⃣ Deploy empty option pools The attacker’s EOA called the attack contract to create the six option pools used in the subsequent exploit. arbiscan.io/tx/0xe3c263fcae5…

🚨 GoPlus Security Alert: On October 31, the official Flap and Kintsu websites suffered DNS hijacking attacks. The attacker likely compromised a domain registrar, with more than 10 other domains also hijacked alongside Flap and Kintsu. By manipulating DNS, the attacker redirected traffic from official project domains to malicious clone sites to steal assets. ⚠️ How Funds Are Stolen: Users who click “Connect Wallet” on the clone sites are redirected to a malicious wallet-connection or drainer page. The theft takes two forms, with attack characteristics pointing to the #StepDrainer group: 1. Direct native-token transfers: Users sign a transaction sending BNB to the attacker’s Safe. 2. ERC-20 approval abuse: Users approve the Safe to spend their tokens. The attacker then calls `transferFrom` to move the tokens. Attacker-controlled Safe recipient address: 0x24497068cA4166ca32a04ae530ce00Cf79755bD5 Safe’s sole owner / execution address: 0x33dfc810365193bff54326812d7df34b3e438da3 🚑 Recovery Status: Kintsu is back online (kintsu.xyz). Flap is also back online (flap.sh), with flap.cool remaining available as an alternative domain. The cause of the DNS hijacking is still under investigation. 🛡️ Security Recommendations: 1️⃣ Stay alert to unusual behavior or anything that differs from the site’s usual behavior. DNS hijacking can redirect you to a malicious clone. 2️⃣ If you signed a suspicious transaction or notice a suspicious transfer, investigate immediately and move your remaining assets to a fresh, secure wallet as soon as possible. 3️⃣ Use tools such as the GoPlus security extension to check for and revoke suspicious token approvals promptly.

3/4 The protocol designated `SyncL2TxHashRelayer` as an authorized relayer, while `SyncL2TxHashRelayer` itself could be called by anyone. Logs from the attack transaction show that the Ethereum Gateway’s identity (`0x83Bc7394738A7A084081aF22EEC0051908c0055c`) was used to invoke the gateway-only function `ZkLink.syncBatchRoot`. An attacker-chosen value was written as the `l2LogsRootHash` for batch 116409. Subsequent withdrawal inclusion proofs were checked against that root, so forged ETH and ERC-20 withdrawals were accepted. Funds moved directly from the custody contracts to the attacker’s EOA, without first passing through the attack contract. etherscan.io/tx/0x4f3c23e75b…

2/4 etherscan.io/address/0x1ee09… etherscan.io/address/0x7a0Bb…

1/4 ⚠️ Exploit Breakdown: zkLink Nova Ethereum Bridge Attack On October 29, an attacker withdrew 22.43129453 ETH and 11 different ERC-20 tokens from zkLink Nova’s L1 custody contracts in a single transaction. The stolen assets were worth approximately $797,016.48 at the time of the attack. 🔍 Root Cause: The vulnerability was in zkLink Nova’s `Arbitrator.claimMessage`. The function uses `finalizeMessageHash` in transient storage to record the hash of a message just authenticated through a callback from the source chain’s canonical message service. The value was not cleared after the call. The function also did not require a fresh authentication callback for every call, allowing an already-authenticated message to be reused. etherscan.io/tx/0x4f3c23e75b…