Threat Actors Use Google Ads to Target Ledger Users With Recovery Phrase Phishing

Zscaler ThreatLabz has detailed a phishing campaign that used fraudulent Google advertisements to target users searching for Ledger hardware wallet-related terms.

According to ThreatLabz, the campaign was analyzed in August 2026. The attack used a multi-stage redirect chain involving Google Cloud Storage, Vercel and Google Sites before presenting victims with a phishing page impersonating Ledger.

The final phishing page used a fake device verification process to persuade users to submit their secret recovery phrases, which can be used to restore cryptocurrency wallets.

ThreatLabz observed the campaign targeting users in the United States, Europe and parts of Asia. During the researchers' observation period, the Vercel domain used in the redirect chain appeared to change approximately every 15 to 20 minutes.

The campaign is notable because the malicious advertising did not simply send users directly to a suspicious domain. Instead, it used legitimate web services as multiple stages in the delivery chain.

How the Attack Chain Worked

The campaign followed a sequence designed to move users from a search result to the fraudulent Ledger interface.

The observed chain was:

Google Search → Malicious Google Ad → Google Cloud Storage → Vercel → Google Sites → Ledger Phishing Page → Recovery Phrase Submission

ThreatLabz says the Google Sites page displayed the phishing content inside an iframe, while Vercel-hosted domains were also used to serve the phishing content.

The researchers observed that the Vercel domain referenced by the JavaScript redirect changed during the campaign. This allowed the operators to alter part of the delivery infrastructure while continuing to use the same Google Cloud Storage page.

The Malicious Ads Appeared in Search Results

ThreatLabz observed malicious sponsored advertisements when searching for Ledger-related terms.

The ads targeted users across several regions, including the United States, Europe and parts of Asia.

The researchers noted that the malicious advertisement displayed google.com along with a "10L+ visits in the past month" figure. Zscaler explains that "10L" represents 1 million in the Indian numbering system.

According to ThreatLabz, the displayed visit count appeared to refer to Google itself rather than the phishing destination, which may have made the advertisement appear more credible.

The advertisement was associated with a long-standing, verified advertiser account that had no observed history of malicious advertising. ThreatLabz said the threat actor may have compromised the account to conduct the campaign. That possibility was not presented as a confirmed attribution.

Legitimate Cloud Services Became Parts of the Redirect Chain

After clicking the malicious advertisement, users were directed to a Google Cloud Storage URL.

That page redirected the browser to a Vercel-hosted page. The Vercel page then redirected the user to a Google Sites page.

The Google Sites page displayed the phishing content inside an iframe.

Vercel-hosted domains were also used to serve the phishing page itself.

This structure gave the campaign several layers between the initial advertisement and the credential theft page. ThreatLabz observed that the Vercel domain referenced in the JavaScript redirect changed approximately every 15 to 20 minutes during the analysis period.

Why the Changing Redirect Matters

Analysis: The changing Vercel destination meant that defenders relying heavily on the reputation of a single domain could have a harder time tracking the complete campaign infrastructure.

However, the researchers did not claim that domain rotation alone made the campaign undetectable. The report specifically describes it as making detection based on domain reputation harder.

The campaign continued using the same Google Cloud Storage page even as parts of the delivery infrastructure changed.

The Phishing Page Recreated the Ledger Experience

The final phishing page was designed to look like the official Ledger interface.

ThreatLabz observed that the page offered download options for Windows, macOS, Linux and mobile devices.

The page also collected device metadata and monitored interactions such as:

• Keypresses

• Touch interactions

• Mouse movements

That information was sent to a Vercel-hosted endpoint.

ThreatLabz said the collection could potentially help the operators distinguish real visitors from automated analysis tools.

The page also contained a Cloudflare Web Analytics beacon, beacon.min.js, configured with an analytics token.

A Fake Device Verification Process Led to the Recovery Phrase

The phishing workflow was designed to make the recovery phrase request appear to be part of a device verification process.

Users could first select their device type when attempting to download the Ledger application.

The page then displayed messages including:

• "Connecting your Ledger"

• "Initializing Firmware Update"

It subsequently claimed that the Ledger device was connected and asked the user to confirm device ownership.

The next step presented a form asking for the user's secret recovery phrase.

This was the central credential theft stage of the campaign.

Why the Secret Recovery Phrase Was the Target

A secret recovery phrase, or SRP, can be used to restore a cryptocurrency wallet.

ThreatLabz explains that an attacker who obtains the phrase can restore the wallet in compatible software and potentially transfer funds without possessing the victim's physical Ledger device.

The phishing page attempted to make the recovery phrase entry appear more legitimate by implementing autocomplete functionality.

ThreatLabz found that the page retrieved the 2,048-word BIP-39 English wordlist from:

api/bip39-english.txt

The wordlist was used to provide matching suggestions as users entered words into the recovery phrase fields.

The interface therefore reproduced an interaction that could appear familiar to someone who expected a wallet-related recovery process.

The Campaign Sent Recovery Phrases to an Attacker-Controlled Endpoint

ThreatLabz observed that the phishing page sent the submitted recovery phrase to an attacker-controlled Vercel domain.

The page also initialized an invisible hCaptcha widget during the submission process.

After the first submission, the page displayed the message:

"Invalid seed. Please re-enter your recovery phrase carefully."

The user was then prompted to submit the phrase again.

ThreatLabz observed that the second submission was also sent to the attacker-controlled endpoint. The page subsequently redirected the user back to the initial landing page.

Importantly, ThreatLabz said it did not observe server-side logic comparing the two submissions.

This suggests that the repeated entry was part of the phishing workflow rather than a demonstrated validation mechanism for determining whether the phrase was actually correct.

The Campaign Used Infrastructure That Could Be Changed Quickly

One of the more notable elements of the campaign was the separation between its initial delivery point and the infrastructure serving the final phishing content.

The Google Cloud Storage page remained part of the chain while the Vercel destination changed during the researchers' observation.

This architecture allowed parts of the campaign to be updated without requiring the same final destination to remain in place.

Analysis: For defenders, this illustrates why monitoring only final phishing domains can provide an incomplete view of an advertising-based phishing campaign. Redirect relationships, hosting infrastructure and the original advertisement can provide additional context.

The report does not provide evidence that this infrastructure design was intended specifically to bypass a particular security product. ThreatLabz instead describes the changing domains in the context of making reputation-based detection more difficult.

Indicators of Compromise

Zscaler published several indicators associated with the campaign.

Google Cloud Storage URLs

storage[.]googleapis[.]com/apf-leg-ad-23798/
storage[.]googleapis[.]com/ledg-leg1-79230/
storage[.]googleapis[.]com/apf-leg-ad-22076/
storage[.]googleapis[.]com/apf-leg-ad-32595/

Google Sites URLs

sites[.]google[.]com/view/start-ledger-wallet
sites[.]google[.]com/view/apps-ledger-wallet
sites[.]google[.]com/view/download-ledger-wallet-pc

Vercel Domains

soyyoo-cwpc5n0e[.]vercel[.]app
rpc-gbz5[.]vercel[.]app
whyavc-qwmv6stx[.]vercel[.]app
router-wdoi[.]vercel[.]app
node-f1ey[.]vercel[.]app

Zscaler identifies the campaign with the threat name HTML.Phish.Ledger in its own security platform.

Zscaler's Detection Coverage

Zscaler says its multilayered cloud security platform detects indicators associated with the campaign at various levels.

The published threat name for this campaign is:

HTML.Phish.Ledger

This coverage statement comes directly from Zscaler and describes the company's own detection capability.

What Users Should Watch For

The campaign demonstrates several warning signs that users can use when evaluating search advertisements and wallet-related websites.

Users should be cautious when:

• A sponsored result appears to imitate a cryptocurrency wallet provider.

• A page asks for a secret recovery phrase.

• A website claims that a physical hardware wallet needs to be verified through a browser form.

• A supposed wallet update requires entering recovery credentials.

• A page redirects through several unrelated domains before reaching its final destination.

• A website asks for sensitive wallet information during an application download or device setup process.

Most importantly, users should never disclose a secret recovery phrase to a website or person requesting it as part of a verification process.

What the Campaign Shows About Search-Based Phishing

The campaign highlights a broader shift in how phishing operations can combine advertising, cloud hosting and familiar brand interfaces.

Instead of relying solely on a newly registered phishing domain, the observed campaign used a chain involving widely recognized online services.

The initial malicious advertisement also appeared under a verified advertiser profile, according to ThreatLabz. The researchers said the account may have been compromised, but this was not confirmed.

Analysis: For security teams, the incident reinforces the value of looking beyond domain reputation alone. A malicious destination can be embedded within a larger sequence involving legitimate infrastructure, redirects and branded content.

For users, the important distinction is between recognizing a familiar service and verifying the destination and request itself. A familiar search engine, cloud provider or hosting platform does not by itself establish that the final page is trustworthy.

Conclusion

Zscaler ThreatLabz has documented a phishing campaign that used fraudulent Google advertisements to target Ledger users and route them through Google Cloud Storage, Vercel and Google Sites.

The final phishing page imitated Ledger's interface and used a fake device verification sequence to persuade users to submit their secret recovery phrases.

ThreatLabz observed device and interaction data collection, BIP-39 word autocomplete, invisible hCaptcha initialization and the transmission of submitted recovery phrases to an attacker-controlled Vercel endpoint.

The researchers also observed that the Vercel redirect destination changed approximately every 15 to 20 minutes during their analysis while the campaign continued using the same Google Cloud Storage page.

The report provides multiple infrastructure indicators, including Google Cloud Storage URLs, Google Sites URLs and Vercel domains, and identifies the campaign in Zscaler's platform as HTML.Phish.Ledger.

For cryptocurrency users, the key lesson is straightforward: a secret recovery phrase is not a routine device-verification credential. A website requesting it should be treated as a major security warning.