On May 26, 2026, the on-chain investigator known as b-block posted a warning that a fake Uniswap operation had drained at least $400,000 from users who clicked a Google search ad and signed a transaction on a site that looked exactly like the real thing. Two attacker wallet addresses were named and verifiable on Etherscan. The mechanism was not a smart-contract exploit and not a stolen private key. The victims approved the theft themselves, with a single signature, on a counterfeit front-end they reached through the top result on Google.
This is the quiet, persistent layer of crypto crime that does not make the same headlines as a nine-figure bridge drain but steadily empties retail wallets month after month. May 2026 saw a notable surge in search-ad-driven drainer campaigns impersonating widely used DeFi front-ends. Uniswap was the most impersonated brand in detected malicious sites, followed by Morpho Finance, with PancakeSwap, Hyperliquid, CoW Swap, and the hardware wallet brand Ledger also abused. The attackers do not need to break any protocol. They need to rank above it.
What makes the approval-drainer pattern so effective is that every step looks legitimate to the victim and to the chain. The contract being interacted with is often a real token contract. The signature is a valid ERC-20 approve. The wallet prompt is genuine. The only thing that is fake is the website that constructed the transaction, and by the time the user notices, the allowance is already granted and the funds are gone.
TL;DR
- On May 26, 2026, on-chain analyst b-block reported a fake-Uniswap phishing campaign that drained at least $400,000 by routing users through Google search ads to lookalike domains.
- Two attacker addresses were publicly identified and verified on Etherscan:
0x37925684BA178821b4436E06e67f5dBD6cfA49Bband0x2fC25F46cC49D226eF92E9A7665f3d2821F3c5E2. - The technique: buy search ads, register lookalike domains mirroring the official front-end, and prompt victims to sign malicious token approvals. No protocol or contract was exploited.
- The malicious ad reportedly persisted at the top of Uniswap search results for weeks despite reports.
- In the broader May 2026 wave, Uniswap was the most-impersonated brand among detected phishing sites, with Morpho Finance second; PancakeSwap, Hyperliquid, CoW Swap, and Ledger were also targeted.
- The root cause is the ERC-20 approval model plus the trust users place in the first search result. Defense is process and tooling, not a contract patch.
- Monday-morning actions: reach DeFi front-ends only via bookmarks, simulate and scrutinize approvals, set spending caps instead of unlimited allowances, and routinely revoke stale approvals.
What happened
According to the report from b-block, relayed by BeInCrypto, scammers bought search advertisements and registered domains that mirrored Uniswap's official front-end. A user searching for Uniswap on Google would see the malicious ad ranked at the top, click through to a pixel-accurate clone, connect their wallet, and be prompted to sign what looked like a routine transaction. The signature instead granted the attacker spending authority, after which the attacker's contract pulled the approved tokens out.
The figure publicly attributed to this specific campaign is approximately $400,000, with two on-chain addresses named. The reporting also notes that the fraudulent ad continued to appear at the top of results for weeks despite being reported, which underscores a recurring failure: paid search remains a reliable, low-cost distribution channel for crypto phishing, and takedowns lag the campaigns.
The broader pattern in May 2026 is what matters for defenders. The fake-Uniswap incident was not isolated. It sat inside a wave of search-ad and lookalike-domain campaigns impersonating the most-used DeFi interfaces. Uniswap led the impersonation volume, with Morpho Finance close behind, and PancakeSwap, Hyperliquid, CoW Swap, and Ledger rounding out the targeted brands. The common thread across all of them is the malicious approval, not any weakness in the protocols themselves.
How the attack worked
The approval-drainer chain has four stages, and only one of them touches the blockchain.
Stage 1: Acquire the top of the funnel
The attacker buys Google search ads keyed to the target brand and registers a lookalike domain. Lookalikes use homoglyphs, extra words ("app-uniswap", "uniswap-defi"), or alternate TLDs. Because the ad outranks the organic result, users who trust "the first link" land on the clone.
Stage 2: Clone the front-end
The phishing site is a high-fidelity copy of the real dApp, often a direct mirror of the legitimate front-end's HTML and assets. The wallet-connection flow is genuine; the site uses the same wallet libraries any dApp would. Nothing in the UI signals danger.
Stage 3: Construct the malicious approval
Here is the sleight of hand. The user believes they are swapping or depositing. The transaction the site actually asks them to sign is an ERC-20 approve granting a large or unlimited allowance to an attacker-controlled spender. The token contract in the prompt is the real token; only the spender is hostile.
The following is an illustrative sketch of the call the victim unknowingly authorizes. It is not functional exploit code.
// ILLUSTRATIVE — the function the victim is tricked into signing
// Standard ERC-20 approve, hostile spender, max allowance
token.approve(
attackerSpender, // attacker-controlled address
type(uint256).max // unlimited allowance
);
In wallet UIs that show only a "spending cap" or an opaque "approve" label, the victim sees a normal-looking confirmation. The danger is the combination of an unlimited cap and an unfamiliar spender, which most users are never taught to read.
Stage 4: Drain on a schedule
Once the allowance is granted, the attacker's contract or EOA calls transferFrom to pull the approved tokens whenever it chooses. The victim's funds can be moved minutes or weeks later, which is why drains sometimes appear long after the original interaction. The two named addresses in this campaign are where the proceeds consolidated.
What detection looks like
For individual users and for teams operating treasuries or front-ends, the signals are concrete.
Transaction-level signals before signing:
- The method is
approveorpermit(an off-chain signed approval) when you expected a swap or transfer. - The allowance amount is
type(uint256).max(often shown as 115792089237316195... or "unlimited"). - The spender is an address you do not recognize and that is not the protocol's audited router or vault.
- The site origin in the wallet prompt does not match the official domain exactly.
Operational and brand-protection signals for protocol teams:
- New domains registered with your brand name plus common modifiers, or homoglyph variants.
- Your brand appearing in paid search ads you did not place.
- On-chain clustering: multiple victim wallets granting approvals to the same spender within a short window, followed by
transferFromsweeps to a consolidation address.
Illustrative on-chain hunting logic:
# ILLUSTRATIVE — adapt to your analytics stack
# Approvals to a suspect spender across many distinct victims
event == "Approval"
AND spender == 0x...suspect
AND COUNT(DISTINCT owner) > N
WITHIN 24h
# Followed by sweeps out
event == "Transfer"
AND from IN (victims)
AND to == consolidation_address
Publicly named IOCs for this campaign (verify on Etherscan before acting): attacker addresses 0x37925684BA178821b4436E06e67f5dBD6cfA49Bb and 0x2fC25F46cC49D226eF92E9A7665f3d2821F3c5E2.
What to do Monday morning
-
Stop reaching dApps through search. Bookmark the canonical URL for every protocol you use and navigate only via the bookmark. Treat the search-results page as hostile for anything wallet-related. This single habit defeats the entire search-ad funnel.
-
Read every approval before signing. Confirm the method (
approve/permit), the spender address, and the amount. Reject unlimited allowances by default; set a cap equal to what you are transacting. -
Use a transaction simulator. Wallets and browser extensions that simulate and decode transactions will show you "you are granting unlimited USDC allowance to 0xUnknown" in plain language before you sign. Enable one.
-
Revoke stale approvals on a schedule. Use a reputable allowance dashboard (for example, a token-approval checker on the relevant chain's explorer) to review and revoke approvals you no longer need. Old unlimited approvals are standing liabilities.
-
Segment funds. Keep a low-balance "hot" wallet for active dApp interaction and a separate cold wallet for storage. A drainer can only take what the connected wallet has approved.
-
For protocol and treasury teams: monitor for lookalike domains and unauthorized brand ads, publish your canonical domains prominently, and consider on-chain monitoring for approval clustering against unknown spenders so you can warn your community before sweeps complete.
Why this keeps happening
The approval-drainer is durable because it exploits design and psychology, not bugs.
The ERC-20 approval model separates granting spending authority from spending it. That separation is useful for legitimate dApps, but it means a single signature can hand over open-ended control of a token balance, and the theft can happen later, decoupled from the moment of consent. Most users do not understand that an "approve" is fundamentally different from a "send," and wallet UIs have historically done a poor job of making the distinction legible.
Layered on top is the distribution problem. Paid search is cheap, fast to deploy, and slow to take down. As long as a malicious ad can sit at the top of results for weeks, attackers will keep buying them, because the funnel converts. The protocols being impersonated have no control over the ad auction, and the ad platforms' enforcement consistently trails the campaigns. The result is a steady drip of losses that never quite triggers the alarm a single large exploit would, even as the cumulative damage rivals it.
The structural fix
Most of the defense here lives with users and wallet software, and it would be dishonest to claim a supply-chain platform stops a person from clicking a search ad. Where the structural problem does intersect Safeguard is the front-end and operational side of DeFi teams. The same approval-drainer pattern increasingly arrives through compromised dependencies and injected front-end code, which is the lane TrapDoor-style supply-chain attacks occupy. Safeguard's reachability analysis and SBOM coverage help DeFi teams know exactly what code ships in their official front-end and detect tampering or malicious dependencies that could turn a legitimate site into an approval trap. Honest framing: this reduces the blast radius of a compromised front-end and shortens the time to detect injected drainer logic. It does not police Google's ad auction or stop a user from visiting a lookalike domain.
What we know we don't know
- Total losses. The publicly cited figure is approximately $400,000 for the specific fake-Uniswap operation b-block flagged. The cumulative total across the broader May 2026 lookalike-domain wave is not consolidated in a single verified source.
- Victim count. The number of distinct wallets drained is not publicly confirmed.
- Attribution. The campaign is identified by on-chain addresses, not by a named actor or group. Whether these brands were targeted by one operator or several is not established.
- Recovery. Whether any funds were frozen, traced through mixers, or recovered after the disclosure is not reported as of this writing.
References
- BeInCrypto, "Fake Uniswap Site Drains $400,000 From Multiple Wallets, Investigator Warns" — https://beincrypto.com/fake-uniswap-drainer-400k-phishing/
- CoinGabbar, "Fake Uniswap Google Ads Steal $400K From Crypto Users" — https://www.coingabbar.com/en/crypto-currency-news/fake-uniswap-google-ads-400k-stolen-phishing-2026
- BleepingComputer, "Inside a Crypto Drainer: How to Spot it Before it Empties Your Wallet" — https://www.bleepingcomputer.com/news/security/inside-a-crypto-drainer-how-to-spot-it-before-it-empties-your-wallet/
- Group-IB, "Crypto Wallet Drainers" knowledge hub — https://www.group-ib.com/resources/knowledge-hub/crypto-wallet-drainers/
Internal Safeguard resources: