While looking for phishing sites, I came across a suspicious Cloudflare Pages site hosted at:
hxxps://zipsage.pages[.]dev
The site presents itself as an “Adobe Activation Guide” and instructs users to manually execute a PowerShell command, a technique commonly associated with ClickFix malware delivery.
Fake Adobe Activation Page
The landing page attempts to socially engineer users into copying and executing a malicious PowerShell command under the pretense of activating Adobe software.
The page instructs users to execute the following command:
The Base64-decoded command is:
This uses Invoke-RestMethod (irm) to download a remote PowerShell script and immediately execute it in memory using Invoke-Expression (iex).
PowerShell Stage
The retrieved PowerShell script downloads and launches a JavaScript file from the same infrastructure.
Script.ps1:
The script downloads script.js into the temporary directory and executes it silently using wscript.exe.
JavaScript Downloader
The downloaded JavaScript file is heavily obfuscated and acts as a downloader/dropper.
The script downloads:
hxxps://get-1o8.pages[.]dev/putty.exe
The payload is stored as:
%TEMP%\putty.exe
Behavior observed from the JavaScript:
Downloads putty.exe
Executes the file
Waits for execution to finish
Deletes the payload afterward
Deletes the script itself
This cleanup behavior likely attempts to reduce forensic evidence on infected systems.
Lumma Stealer Network Activity
During execution, the sample generated multiple DNS and HTTP requests associated with Lumma Stealer infrastructure.
Recently, I came across another ClickFix-style campaign pretending to install a Chrome security update. The campaign was hosted on:
teams-net-calls[.]com
The site impersonates a legitimate Microsoft Teams download page and attempts to trick users into manually executing a malicious PowerShell command under the guise of installing a browser security update.
When accessing the site, the victim initially sees what appears to be a legitimate Microsoft Teams download page. The page itself looks clean and convincing, using Microsoft branding and a fake Teams download interface.
However, the malicious behavior does not trigger immediately. The ClickFix flow is activated only after the user interacts with the page by clicking somewhere on it. After the click, the site displays a fake Chrome update popup claiming that a critical browser security update is required.
Requiring user interaction before displaying the malicious prompt may help the campaign avoid automated sandbox analysis and reduce detection by security crawlers that do not fully interact with page elements.
The popup then walks the user through a series of steps instructing them to manually execute a PowerShell command:
Press Win + X
Open PowerShell / Terminal
Paste the copied command
Press Enter
This social engineering approach avoids traditional browser download warnings because the victim manually executes the payload themselves.
After following the instructions, the victim ends up executing the following PowerShell command:
At first glance, the script looks somewhat harmless because it downloads a legitimate old Node.js package directly from the official Node.js website:
However, the second downloaded archive reveals the actual payload:
hxxps://instantwebupdate[.]com/get_update?i=77669
The script extracts both archives into:
C:\ProgramData\
and silently launches:
using hidden PowerShell execution flags such as:
-ExecutionPolicy Bypass -WindowStyle Hidden
The JavaScript payload itself is interesting because it uses a large fake “poem” style wordlist to hide embedded files. Instead of storing binaries directly, the malware reconstructs files from mapped words and writes them to disk during execution.
The bundled DLLs (msvcp140.dll, vcruntime140.dll, and vcruntime140_1.dll) appear to be legitimate Visual C++ runtime dependencies rather than standalone malicious DLLs. They were likely included to ensure the dropped executable runs properly on victim systems.
At the time of analysis, no obvious C2 URLs were identified inside the EXE itself. Most visible URLs were related to Microsoft or DigiCert certificate infrastructure.
While continuing to monitor the infrastructure used in that campaign, I discovered several additional URLs hosted on Google Cloud Storage (storage[.]googleapis[.]com) that appear to be part of the same ecosystem. These pages act as intermediate redirectors, sending victims to a wide variety of phishing and scam sites hosted primarily on the .autos TLD.
What is interesting is that a single Google Cloud Storage page appears to function as a central redirect hub, distributing victims across multiple scam themes such as fake surveys, reward scams, antivirus alerts, job offers, and account storage warnings.
Newly Observed Google Cloud Storage URLs
The following URLs were identified during the investigation:
These pages typically present users with messages claiming they have been selected for a Netflix reward or promotional giveaway, encouraging them to complete a short survey to claim their prize.
Like the other scams in this campaign, the pages ultimately attempt to collect personal or payment information, often under the pretext of paying a small shipping fee or verifying eligibility.
Fake Dell Laptop Giveaway Survey
Another variation promotes a Dell laptop giveaway, typically claiming that users can win a Dell 16 DC16250 laptop worth $699.99.
During testing, this page was observed redirecting users to multiple phishing domains across different scam themes.
This suggests it is functioning as a traffic distribution or redirect infrastructure, allowing attackers to rotate phishing destinations while keeping the initial delivery URL stable.
Using Google Cloud Storage also adds a layer of trust, as the domain belongs to a legitimate cloud provider.
Another interesting observation is that a single .autos domain can serve multiple phishing page themes after redirection from the Google Cloud Storage page. Depending on the redirection path or parameters, the same domain may host different scams such as:
Fake surveys
Reward scams
Storage full alerts
Antivirus subscription warnings
Job offer lures
This behavior indicates that the attackers are likely using a shared phishing kit or centralized backend infrastructure, allowing them to quickly rotate scam themes while reusing the same domains.
Another observation is the high volume of phishing emails currently being distributed using this infrastructure. Over the past few days, I have been receiving around 40–50 phishing emails within a 24-hour period, many of which contain links to Google Cloud Storage pages that act as redirectors to the phishing ecosystem described in this report.
This campaign demonstrates how attackers continue to abuse trusted cloud infrastructure such as Google Cloud Storage to host redirectors that distribute victims to multiple phishing pages.
By using legitimate cloud services as part of the attack chain, threat actors can increase credibility and reduce the likelihood of immediate blocking.
The use of large numbers of disposable .autos domains further allows attackers to rotate phishing pages frequently while keeping the delivery infrastructure intact.
In addition, the system appears to restrict repeated access attempts from the same IP address. After a user successfully reaches a phishing page through the redirector, subsequent attempts to access similar URLs from the same IP may result in the page failing to load or redirecting to unrelated sites. This behavior suggests the presence of IP-based filtering or traffic distribution logic, commonly used in malicious traffic distribution systems (TDS) to control how often a visitor can access the phishing infrastructure.
In recent weeks, a highly organized phishing campaign has surfaced, characterized by its use of legitimate Google infrastructure to bypass standard security filters. I have identified more than 25 distinct phishing emails targeting a single account, all of which ultimately direct users to a specific URL:
The URL in question is hosted on Google Cloud Storage (GCS). To the average user or basic email security gateway, the domain googleapis.com appears trustworthy because it is a legitimate Google-owned domain used for hosting cloud assets.
In this specific exploit:
The Bucket: whilewait is a unique storage container created by the attacker within a Google Cloud project.
The Payload: comessuccess.html is a script-heavy file designed to act as a “gatekeeper” or “redirector“.
By hosting the initial link on Google’s servers, the attackers ensure the email passes authentication checks like SPF and DKIM. Once a user clicks, the HTML file on Google’s server silently redirects the browser to a third-party malicious site, often used for credit card harvesting or malware distribution.
Diversity of Social Engineering Tactics
More than 25 emails captured in this study demonstrate an exhaustive range of “hooks” designed to appeal to different psychological triggers. While the underlying technical path is identical, the presentation varies wildly:
Security Fears: Alerts regarding a “Critical Threat Detected” or “Antivirus Protection Expired“.
Retail Incentives: Reward offers from brands such as Lowe’s, T-Mobile, and State Farm.
Lifestyle & Health: Promotions for “Homemade Recipes“, “Harry & David Gift Baskets“, “Blood Sugar Watch” or “Neuropathy Pain” solutions.
Despite these different themes, the goal remains consistent, drive traffic to the whilewait storage bucket to initiate a fraudulent transaction or steal sensitive information.
The Final Objective: Credit Card Harvesting
Following the redirect from the Google Cloud link, users are typically presented with a “shipping fee” or “service charge” for their reward or security update. This is the Credit Card (CC) Harvesting phase. Any payment information entered on these secondary sites is captured by the attackers, leading to immediate financial fraud. This specific lure mirrors the tactics identified in recent threat research (link given below), where scareware emails are increasingly used to push users toward these fraudulent “subscription” or “service” portals.
To defend against this specific style of “Trusted-Platform Phishing“, the following steps are recommended:
Inspect the Redirect Path: Be aware that a link starting with storage.googleapis.com is not an official communication from Google, it is a file hosted by a third party using Google’s tools.
Verify Sender Metadata: Even if the link looks legitimate, the “From” address in these 25 plus samples often consists of unrelated, randomized alphanumeric strings.
Submit Infrastructure Abuse Reports: These campaigns rely on the longevity of the storage bucket. Reporting the whilewaitbucket to the Google Cloud Abuse Team is the most effective way to dismantle the entire 25 plus email network at once.
I identified a long-running redirect infrastructure abusing Cloudflare Pages (pages.dev) to host benign-looking SEO articles (for example, celebrity “net worth” blogs or gaming help content) that display a forced “Continue reading / Continue Read” pop-up shortly after page load.
Once the user clicks the button, the browser is redirected into downstream infrastructure that may lead to:
More than 250 URLs were observed using the same visual template and behavior, and historical evidence from URLScan shows activity persisting for 5 months, suggesting deliberate reputation building and SEO indexing.
Initial Infection Vector: Benign SEO Content on Cloudflare Pages
The landing pages appear as normal blog articles but automatically display a modal message:
“Continue reading by clicking the button below.”
This design ensures the redirect is user-initiated, helping bypass automated scanners and reputation systems.
Common characteristics
Hosted on: *.pages.dev
SEO-style article content
Modal overlay appears a few seconds after page load
Redirect only occurs after button click
Scale, Persistence, and Search Engine Exposure
Across the analyzed samples, more than 250 distinct URLs were identified showing identical UI and UX behavior, indicating the use of the same phishing template or kit deployed across different article topics. The activity has remained visible for approximately five months based on URLScan observations, suggesting persistence rather than short-lived campaigns. Additionally, some of these pages have been indexed in Google search results, significantly increasing the likelihood of exposure to real users and amplifying the overall risk posed by the operation.
Redirect Logic (Click-Gated Pre-Lander Behavior)
The redirect mechanism is implemented using delayed modal display and a click-triggered JavaScript redirect.
Key Observation
Across many different pages, most samples use the same redirect destination inside window.open()
This is important because it shows that the pages.dev sites are probably not standalone phishing pages created one by one. Instead, they appear to work more like traffic pre-landers that quietly direct visitors to a shared backend system. The key= parameter in the URL also looks intentional rather than random, and it is likely being used for tracking or routing within the campaign, possibly as a campaign ID, an affiliate tracking token, or even a value used to classify or group potential victims.
In short:
Multiple benign-looking SEO pages are acting as entry points into a centralized redirect infrastructure.
likely serves as a Traffic Distribution System (TDS) decision node, responsible for:
Geo/IP filtering
Proxy/VPN detection
User-agent validation
Campaign routing
Conditional payload delivery
Simplified Kill Chain
Anti-Analysis Behavior: Proxy / VPN Detection
During testing, downstream pages performed VPN/Proxy checks.
If anonymity was detected, the page displayed:
“Anonymous Proxy detected.”
and stopped further redirection.
Security Impact
From a security perspective, this behavior is particularly concerning because it makes deeper analysis much harder. By blocking or redirecting automated environments, it can prevent sandboxes and researchers from ever reaching the real payload, which in turn leads to very low antivirus detection rates. As a result, automated scans may incorrectly appear clean, creating a false sense of safety even though malicious activity may still be present behind the scenes.
Observed Downstream Outcomes
1) Fake File Download Funnel – S3 ZIP Payload
One redirect path showed a “Your File Download Is Ready” page, leading to:
Final payload stored on Amazon S3 (SetupFile-xxxx.zip)
2) Fake Browser Diagnostics – Opera Download Lure
Another branch displayed a fake compatibility/diagnostics score (e.g., 40/100) urging users to:
“Download Opera Browser”
This pattern feels very similar to the affiliate-driven browser installation funnels often seen in malvertising campaigns, where traffic is quietly redirected through multiple steps before reaching the final payload or monetization stage.
3) QR Code / Fake CAPTCHA Social Engineering
Some redirects presented:
“Prove you are not a robot”
QR code requiring mobile scan
Flows like this are commonly designed to move victims step by step toward the attacker’s real objective. In many cases, the final destination can be a phishing page that steals credentials, a subscription fraud scheme that silently charges the user, or even the delivery of mobile malware disguised as a legitimate download.
Payload Example and Low Detection Context
One observed executable sample (adware/PUP classification):
What makes this particularly notable is that the overall setup closely matches how modern malvertising Traffic Distribution Systems (TDS) typically operate. The infrastructure shows several familiar patterns, such as abusing a trusted hosting platform like Cloudflare Pages, allowing pages to be indexed by search engines to attract organic traffic, and using click-gated redirects to evade automated analysis. Behind the scenes, everything appears to funnel through a centralized redirect endpoint where the final payload can be delivered conditionally, depending on the visitor. This kind of design also supports multiple monetization paths rather than a single outcome. Taken together, it suggests we are not looking at just one phishing kit, but a broader shared redirect ecosystem designed to distribute traffic at scale.
This campaign highlights how attackers carefully blend several techniques to stay under the radar and keep their operation running for long periods. By abusing legitimate hosting services, leveraging SEO poisoning to attract real users, using click-triggered redirects to avoid automated detection, and routing visitors through a centralized traffic system, they create a stealthy and resilient infrastructure capable of quietly delivering malware or other malicious outcomes over time
