A malicious Chrome extension called “Safery: Ethereum Wallet” poses as a legitimate wallet, yet it steals seed phrases by encoding them into Sui addresses and firing tiny on-chain transactions to an attacker’s wallet. Consequently, the attack avoids classic C2 and hides exfiltration inside public blockchain writes. Therefore, impacted users can lose full control of their Ethereum accounts even if they never interact with obvious phishing pages.
𝐖𝐡𝐚𝐭 “𝐒𝐚𝐟𝐞𝐫𝐲” 𝐝𝐨𝐞𝐬 𝐚𝐧𝐝 𝐰𝐡𝐲 𝐢𝐭 𝐰𝐨𝐫𝐤𝐬
When a victim creates or imports a wallet, the extension captures the mnemonic (BIP-39 seed phrase). Then it encodes those words into synthetic Sui addresses and sends dust-sized payments from a hardcoded Sui account. Afterward, the operator reads the transaction history and decodes the seed from the sequence of destination addresses. Because the data rides a public ledger rather than a suspicious domain, many network defenses miss it. Meanwhile, the extension’s storefront listing, branding, and benign-looking flow lower suspicion at install time.
𝐒𝐭𝐞𝐩-𝐛𝐲-𝐬𝐭𝐞𝐩 𝐞𝐱𝐟𝐢𝐥𝐭𝐫𝐚𝐭𝐢𝐨𝐧
First, the extension hooks the wallet setup flow and reads the mnemonic. Next, it transforms each word (or chunk) into bits that map to valid Sui address bytes and assembles a series of “recipient” addresses. Then it sends very small Sui transfers to those recipients, essentially writing the mnemonic to the chain as an address sequence. Finally, the operator queries the attacker wallet’s outbox and reconstructs the mnemonic deterministically. As a result, the theft leaves a durable, on-chain breadcrumb trail ironically making recovery of what happened possible, even if funds are already gone.
𝐖𝐡𝐲 𝐜𝐨𝐧𝐯𝐞𝐧𝐭𝐢𝐨𝐧𝐚𝐥 𝐝𝐞𝐟𝐞𝐧𝐬𝐞𝐬 𝐦𝐢𝐬𝐬 𝐢𝐭
Because there’s no obvious C2 domain and the extension behaves “normally” until setup, security tools that watch for DNS beacons or suspicious fetches may stay quiet. Moreover, review teams may focus on permissions and miss logic that writes to blockchains. Meanwhile, consumer users rarely monitor Sui addresses during an Ethereum wallet install. Therefore, the technique evades casual checks while remaining simple enough for copycats.
𝐖𝐡𝐚𝐭 𝐭𝐨 𝐝𝐨 𝐢𝐟 𝐲𝐨𝐮 𝐛𝐞𝐥𝐢𝐞𝐯𝐞 𝐲𝐨𝐮 𝐰𝐞𝐫𝐞 𝐞𝐱𝐩𝐨𝐬𝐞𝐝
Immediately assume the seed phrase is burned. Create a new wallet on a trusted client and move funds to new addresses that never touched the compromised mnemonic. Then rotate any derived wallets and revoke approvals on major chains. Additionally, remove the extension, clear browser profiles tied to the wallet, and run a separate device for recovery to avoid cross-contamination. Finally, enable hardware-wallet gates and store seeds offline going forward.
𝐈𝐧𝐝𝐢𝐜𝐚𝐭𝐨𝐫𝐬 𝐚𝐧𝐝 𝐝𝐞𝐭𝐞𝐜𝐭𝐢𝐨𝐧 𝐭𝐢𝐩𝐬 𝐟𝐨𝐫 𝐞𝐧𝐭𝐞𝐫𝐩𝐫𝐢𝐬𝐞𝐬
Blue teams should watch for installations of unknown wallet extensions, “first-run” events that trigger blockchain writes, and flows that request clipboard or content-script access around seed handling. Additionally, investigate any browser profile that created or imported a wallet shortly before funds moved. Where possible, enforce extension allowlists on managed Chrome via policy, and alert on any wallet extension that isn’t pre-approved. Because the exfil path uses Sui, telemetry that inspects wallet RPC calls or third-party extension traffic can reveal anomalous micro-transactions during setup.
𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐚𝐥 𝐩𝐫𝐞𝐯𝐞𝐧𝐭𝐢𝐨𝐧 𝐟𝐨𝐫 𝐨𝐫𝐠𝐬 𝐚𝐧𝐝 𝐜𝐫𝐞𝐚𝐭𝐨𝐫𝐬
Standardize a short list of approved wallet extensions and force-install only those. Then block everything else by policy. Moreover, require hardware-wallet usage for any treasury access and prohibit seed-phrase handling inside general-purpose browsers. In practice, publish a one-page playbook (“how we verify wallet publishers, hashes, and signatures”) and train support staff to recognize seed-rotation and asset-migration incidents quickly. Finally, keep users out of unsafe stores by linking to the official extension pages from your own documentation.
𝐇𝐢𝐠𝐡-𝐬𝐢𝐠𝐧𝐚𝐥 𝐫𝐞𝐝 𝐟𝐥𝐚𝐠𝐬 𝐰𝐡𝐢𝐥𝐞 𝐫𝐞𝐯𝐢𝐞𝐰𝐢𝐧𝐠 𝐰𝐚𝐥𝐥𝐞𝐭 𝐞𝐱𝐭𝐞𝐧𝐬𝐢𝐨𝐧𝐬
Therefore, treat any wallet that: encodes data into other chains; references Sui addresses during Ethereum setup; obfuscates seed handling; or requests broad page access during mnemonic entry as suspect. Additionally, confirm the publisher’s identity, verify recent code diffs, and refuse extensions that block offline setup. Because on-chain exfil leaves traces, post-incident responders should capture relevant Sui tx hashes to support takedowns and intelligence sharing.
𝐀𝐜𝐭𝐢𝐨𝐧 𝐜𝐡𝐞𝐜𝐤𝐥𝐢𝐬𝐭 𝐟𝐨𝐫 𝐭𝐡𝐢𝐬 𝐰𝐞𝐞𝐤
Rotate exposed seeds, migrate funds, and audit Chrome profiles for unknown wallets. Next, enable Chrome allowlist policies and remove non-approved extensions at scale. Then document a repeatable recovery flow: evidence capture, extension removal, wallet recreation, and mandatory hardware-wallet transition for affected users. Ultimately, measure response time from detection to seed rotation and drive it down each incident.
𝐅𝐀𝐐𝐬
Q: If an attacker stole my seed phrase but hasn’t moved funds, is it safe to wait?
A: No. Move assets immediately to new, unrelated addresses and rotate every account derived from the exposed seed. Then revoke token approvals and monitor.
Q: Why use Sui for exfiltration if the target is Ethereum?
A: Because it’s a separate public channel. The attacker writes the mnemonic as address patterns on Sui and reads it later, avoiding obvious Ethereum-side telemetry.
Q: Can enterprise policies actually stop this?
A: Yes. Blocklist non-approved extensions and force-install vetted wallets. Additionally, alert on any wallet that initiates blockchain writes during setup.
Q: Is a hardware wallet enough?
A: It helps, yet users can still reveal seeds during backup. Therefore, pair hardware wallets with no-seed-in-browser rules and verified publisher links.
