Worked example · 2024-12
Pudgy Penguins Google-Ads NFT-drainer phishing campaign — multi-chain (Ethereum-NFT-centric) — 2024-12
Summary
In December 2024, ScamSniffer identified a malicious advertising campaign hosted within Google's ad network that was specifically targeting holders of the Pudgy Penguins NFT collection — one of the highest-floor active 2024 NFT collections, with associated downstream collections (Lil Pudgys, Pudgy Rods) carrying meaningful per-token value. The campaign's distribution surface was an ad-injection flow served via the legitimate Adloox ad-tracking CDN: malicious JavaScript embedded in served ads scanned visitors' browsers for Web3 wallet extensions (MetaMask, Rabby, Phantom, etc.) and conditionally redirected wallet-bearing visitors to a typosquat phishing domain (pudqypenguin.com — pudqy substituting Latin q for the lowercase g).
The phishing page presented as a "free Penguin NFT" claim flow, soliciting the canonical NFT-drainer signature flow: a setApprovalForAll approval to an attacker-controlled operator address against the Pudgy Penguins / Lil Pudgys ERC-721 contracts. Once approved, the operator address could transfer all of the victim's holdings in those collections via standard transferFrom calls — the classic NFT-drainer extraction path documented in examples/2024-10-inferno-drainer-handover.md and the broader OAK-G02 category.
ZachXBT publicly identified the malicious campaign and notified Adloox, which removed the malicious JavaScript files from its CDN within hours. The campaign was disrupted before achieving the kind of mass-loss figure that would headline a single-incident worked example; the structural significance is in the distribution surface (Google Ads via legitimate ad-tracking CDN) rather than the per-victim loss aggregate.
For OAK's T4 / T12 / T6 framing, the Pudgy Penguins Google-Ads campaign is the canonical December-2024 worked example demonstrating three load-bearing structural features:
Ad-network distribution as a defense-evasion overlay. The campaign reached victims via Google's ad network, with the malicious payload hosted on Adloox's legitimate ad-tracking CDN. This bypasses URL-based blocklists, domain-reputation systems, and traditional phishing-link-detection heuristics — the malicious payload is served from a trusted infrastructure surface. The defender-side detection requirement is therefore behavioural (does this ad's payload scan for Web3 wallets and conditionally redirect?) rather than reputational (is this URL on a blocklist?). The case is the cleanest 2024 worked example for ad-network-as-evasion-substrate.
Wallet-extension fingerprinting as a victim-eligibility filter. The malicious JavaScript scanned for Web3 wallet extensions before redirecting; non-wallet-bearing visitors saw legitimate ad content. This is structurally a targeting refinement on top of the ad-network distribution — the operator only burns the typosquat domain on visitors who have Web3 wallets installed, materially reducing the effective rate of detection by non-target visitors and prolonging the campaign's operational lifetime. Wallet-extension fingerprinting is a discrete operator capability that warrants explicit T6.x naming in v0.x updates.
Per-collection targeting as a high-value-extraction refinement. Pudgy Penguins floor was ~$30K-50K through December 2024; per-victim-extraction-per-NFT was structurally larger than for cohort-floor collections. The campaign chose a high-floor target to maximise per-victim extraction; the defender lesson is that high-floor collection holders are higher-value targets and warrant per-collection holder-side advisories during phishing-active windows.
Timeline (UTC)
| When | Event | OAK ref |
|---|---|---|
| Pre-campaign | Operator builds typosquat phishing site (pudqypenguin.com) impersonating Pudgy Penguins collection page; payload solicits setApprovalForAll approve-pattern |
T4.005, T4.008, T12.002 (preparation) |
| Pre-campaign | Operator deploys malicious JavaScript on Adloox's legitimate ad-tracking CDN; payload scans visitor browsers for Web3 wallet extensions and conditionally redirects wallet-bearing visitors | T6 modifier (ad-network distribution + wallet-fingerprint targeting) |
| December 2024 (campaign-active window) | Google Ads serve ads carrying the Adloox-CDN payload; wallet-bearing visitors are redirected to pudqypenguin.com | (campaign distribution) |
| Mid-December 2024 | First user reports of Pudgy Penguins phishing redirects from Google Ads; ScamSniffer investigates | (community detection) |
| Mid-December 2024 | ScamSniffer publishes attribution to the Adloox-CDN ad-injection vector | (forensic publication) |
| Mid-December 2024 | ZachXBT corroborates and notifies Adloox; Adloox removes the malicious JavaScript files from its CDN | (operator-side disruption) |
| Late December 2024 | Multiple independent outlets (Invezz, Coinpedia, ICOHolder, ITC.ua, crypto.news) publish convergent reporting | (forensic record) |
| Continuing | No publicly-aggregated per-victim loss total at v0.1 cutoff; per-affiliate / per-service-operator attribution not public | (attribution state) |
What defenders observed
- Ad-network distribution surfaces are structurally hostile to URL-blocklist-based defenses. Google Ads served the malicious payload via a legitimate ad-tracking CDN. URL blocklists and domain-reputation systems have no signal on Adloox's CDN — it is a legitimate vendor — and have no signal on Google's ad network at the parent level. The defender-side detection model must therefore include behavioural signals on the served JavaScript (does this script scan for Web3 wallet extensions? does it issue a conditional redirect to a typosquat domain? does the redirect target solicit
setApprovalForAll?). Browser-side wallet-extension authors that detect approve-solicitations from unverified domains operate at the right detection layer; URL-blocklists alone do not. - Wallet-extension fingerprinting is a discrete operator-side targeting capability. The malicious JavaScript scanned for
window.ethereum,window.solana, and similar provider injections to identify Web3-wallet-bearing visitors before issuing the redirect. The conditional-redirect refinement materially reduces detection-rate by non-target visitors and prolongs campaign lifetime. The defender-side counter is the same — wallet-extension-side proactive blocking of approve-solicitations from unverified or typosquat domains. - Per-collection targeting concentrates value-at-risk. Pudgy Penguins floor was ~$30K-50K in December 2024; the campaign's choice of a high-floor collection meant per-victim extraction-per-NFT was structurally larger than cohort-floor collections. Per-collection holder-side advisories during phishing-active windows are a load-bearing collection-issuer practice; the Pudgy Penguins team posted advisories during the active window per multiple independent reports.
- ScamSniffer + ZachXBT is the canonical detection-and-disruption loop for this category. ScamSniffer's phishing-detection telemetry surfaces the campaign; ZachXBT publicly amplifies and notifies the upstream infrastructure provider; the upstream provider (Adloox in this case, Cloudflare / Google in others) removes the malicious payload. The loop's effectiveness is highly dependent on the upstream infrastructure provider's responsiveness; Adloox's same-day removal limited campaign lifetime materially.
What this example tells contributors writing future Technique pages
- Ad-network-as-distribution-surface is a discrete v0.x T6 sub-Technique candidate. The Pudgy Penguins Google-Ads campaign joins prior cases (Magic Eden Ordinals phishing via Google search ads in early 2024 per Chainalysis) as multi-incident-cohort evidence that ad-network distribution is a load-bearing modifier on the underlying T4 / T12 phishing techniques. Future T6 updates should enumerate ad-network-as-distribution as a sub-Technique; the detection-signal layer (behavioural-payload-analysis) is materially different from URL-reputation-based detection and warrants discrete naming.
- Wallet-extension fingerprinting + conditional redirect is a discrete operator capability. Future T4 / T12 worked examples should record whether the campaign used wallet-extension fingerprinting to target redirects (vs unconditional redirect), because the conditional-redirect refinement materially affects campaign lifetime and detection-rate. v0.x guidance for T4 detectors should treat the fingerprinting payload as a separate detection signal beyond the URL-level signal.
- Per-collection holder-side advisories are a collection-issuer Mitigation. Pudgy Penguins issued holder-side advisories during the active window. Per-collection issuer advisories are a discrete Mitigation surface that warrants explicit Treatment in T12 / T4.005 Mitigation enumeration. Future T12.002 / T4.005 worked examples should record whether the impersonated collection's issuer published a contemporaneous advisory and whether downstream marketplaces (OpenSea, Blur, Magic Eden) propagated the advisory to their users.
- Adjacent to OAK-G02 service-infrastructure framing. The Pudgy Penguins campaign is consistent with the broader OAK-G02 drainer-services-as-a-service category but is not individually attributable to Inferno / Angel / Pink at confirmed-strength. Future per-campaign worked examples in this category should preserve the category attribution at OAK-G02 + the infrastructure-cluster attribution at the spender-address / typosquat-domain level, while remaining explicit about the absence of per-affiliate attribution.
Public references
[scamsnifferpudgy2024](proposed) — ScamSniffer attribution of the Pudgy Penguins Google-Ads phishing campaign to the Adloox CDN ad-injection vector. https://crypto.news/scam-sniffer-malicious-google-ad-campaign-redirects-crypto-users-to-fake-pudgy-penguins-website/[invezzpudgy2024](proposed) — Invezz reporting on the Pudgy Penguins Google ad campaign. https://invezz.com/news/2024/12/26/pudgy-penguins-nft-users-targeted-by-malicious-google-ad-campaign/[coinpediapudgy2024](proposed) — Coinpedia coverage. https://coinpedia.org/news/crypto-scam-alert-pudgy-penguins-nft-users-targeted-by-google-ad-network-phishing/[icoholderpudgy2024](proposed) — ICOHolder reporting. https://icoholder.com/en/news/new-phishing-scam-targets-pudgy-penguins-nft-users-through-google-ads[itcuapudgy2024](proposed) — ITC.ua reporting. https://itc.ua/en/news/a-phishing-site-of-the-popular-nft-collection-pudgy-penguins-appeared-among-google-ads/[slowmist2024report]— broader 2024 wallet-drainer ecosystem context (~$494M aggregate; OAK-G02 service-infrastructure framing).[checkpoint2023drainers]— recurring on-chain spender addresses tied to the Inferno / Angel / Pink / Monkey / Venom successor cohort.
Discussion
The Pudgy Penguins Google-Ads campaign is the canonical December-2024 worked example for ad-network-as-distribution-surface combined with wallet-extension-fingerprinting targeting in the NFT-drainer cohort. The case complements examples/2024-10-inferno-drainer-handover.md (service-level operator-cluster framing) by anchoring a per-campaign distribution-surface case at named-collection, named-window granularity. The two layers are complementary: the operator-service writeup characterises the cohort's category-level infrastructure persistence; the per-campaign Pudgy Penguins case characterises the per-distribution-surface evasion overlay.
The ad-network distribution surface is the case's most defensively-actionable observation. URL-reputation-based defenses have no signal on Adloox's legitimate ad-tracking CDN, on Google's ad network at the parent level, or on the typosquat domain at the moment of first injection (pre-detection). The detection requirement is therefore behavioural — wallet-extension-side proactive blocking of approve-solicitations from typosquat or unverified domains, behavioural payload analysis on served ad scripts, and rapid upstream-infrastructure-provider notification. The Pudgy Penguins case demonstrates that the loop can operate at hours-scale when the defender community (ScamSniffer + ZachXBT) is engaged and the upstream provider (Adloox) is responsive.
Wallet-extension fingerprinting + conditional redirect is the case's second load-bearing structural feature. The malicious JavaScript scanned for Web3 wallet provider injections before redirecting; non-wallet-bearing visitors saw legitimate ad content. The conditional-redirect refinement is structurally significant for two reasons: it prolongs campaign lifetime by reducing detection-rate from non-target visitors, and it concentrates the operator's exposure to the wallet-bearing victim cohort that has actual extractable value. The defender-side counter operates at the wallet-extension layer — extensions like Rabby and MetaMask's transaction-simulation surfaces are at the right detection layer for blocking the eventual setApprovalForAll solicitation, even when the URL-layer signals are absent.
Per-collection targeting at high-floor collections is the third structural feature. Pudgy Penguins' $30K-50K floor in December 2024 meant per-NFT extraction-on-success was materially higher than cohort-floor collections. Future per-campaign worked examples in this category should record the floor-of-target as a load-bearing structural feature; high-floor collection targeting is a different cost-benefit ratio for the operator than cohort-floor targeting and warrants per-collection holder-side advisories during phishing-active windows as a discrete collection-issuer Mitigation.
For OAK's broader cohort coverage, the Pudgy Penguins December-2024 campaign sits alongside examples/2024-10-inferno-drainer-handover.md (service-level operator cohort writeup) and the broader OAK-G02 category. The case is the canonical 2024 NFT-collection-targeted worked example demonstrating the post-2023 evolution of the drainer-services-as-a-service category toward higher-evasion distribution surfaces (ad-network-as-substrate) and higher-targeting refinements (wallet-extension fingerprinting). v0.x updates to T4.005 and T12.002 should treat the case as anchor-evidence for the ad-network and fingerprinting sub-Techniques.