Amazon’s Prime Day wrapped on June 26th — and the Amazon phishing wave around it is a case study in how attackers sidestep corporate email security. Leading up to the fourth of July weekend, PIXM observed a surge of post-sale lures — refund, delivery problem, “verify your account” — reaching employees through personal inboxes, text messages, and social feeds opened on corporate devices: channels the secure email gateway never inspects. The hosting is chosen to beat the rest of the stack: Check Point researchers counted 6,843 new Amazon-themed domains in the six months before the sale, but the phishing pages we detected in the days after it never registered a domain at all — they lived on free cPanel preview subdomains: aged, legitimate, valid-TLS infrastructure that no reputation engine will flag.
Malicious Domains Observed
From our own detections:
amzonueprimepage.2-24-217-207.cpanel[.]siteamazon-verify-account.20-14-89-220.cpanel[.]siteviruswarning0630usphtcaw.z13.web.core.windows[.]netviruswarning0702us3xvwl8.z13.web.core.windows[.]netviruswarning0702usa8cwpd.z13.web.core.windows[.]netviruswarning0706uspznz18.z13.web.core.windows[.]net
Related Amazon-themed domains reported to PhishTank the same week:
primevideo-remboursement[.]comabovideo-regularisation[.]comamazon-prime[.]appsuscribe-prime[.]infogestion-dossierclient[.]com
“Verify Your Account”: Amazon Phishing Pages With No Domain Behind Them
On July 1st, a user clicked through to a flawless Amazon sign-in page — logo, layout, footer, even the “Forgot password?” link all faithful to the real thing, with the victim’s own email address already filled into the form.
Amazon sign-in clone on a cPanel preview subdomain, victim email pre-filled (redacted), July 1st
Two days later we caught the same kit again on a fresh host, this one named to sell the pretext outright: amazon-verify-account. Credential capture is rarely where these kits stop — the Amazon phishing kit we dissected in 2025 went on to harvest SSNs and bank access numbers once past the login.
Three details make this pair worth an enterprise defender’s attention:
- The hosting is a feature, not a bug. Both pages sit on
cpanel[.]sitepreview subdomains — the hosting panel’s built-in “view your site before DNS is set up” convenience. The server’s IP address is baked right into the hostname (2-24-217-207,20-14-89-220). The attacker never registered a domain, so there is no new-domain signal to catch, no WHOIS trail, and the parent domain is legitimate, aged, and serves valid TLS. - The links are personalized. Both URLs mimic Amazon’s real sign-in path (
/desktop/ap/signin?ref=...) and carry a roughly 100-character unique token, and the form arrives with the victim’s email pre-populated — hallmarks of individually addressed email or SMS delivery rather than mass spray. - The kit rotates hosts, not code. Same page, same flow, new subdomain — the disposable layer is the infrastructure, which costs the operator nothing.
We weren’t the only ones seeing the post-sale wave. PhishTank verified dozens of Amazon-themed submissions the same week, including a French-language cluster of Prime Video “refund” and “regularization” lures (primevideo-remboursement[.]com, abovideo-regularisation[.]com), a rotating family of .pro/.top domains all serving the same loading.php flow, and — notably — Amazon phishing fronted by google[.]com/share.google redirect links, laundering the first click through a domain no filter will ever block. The Better Business Bureau issued a consumer warning to match, and the FTC has long ranked Amazon among the most-impersonated brands. Post-purchase pretexts — refunds, delivery problems, account verification — are exactly the messages shoppers expect to receive the week after a major sale. And the delivery end looks like this: Malwarebytes recently captured one of these refund lures arriving as a group text blast — an “Amazon Safety Notice” recall with an order number and a refund-eligibility link, sent over SMS/RCS where no secure email gateway will ever see it.
An Amazon “product recall” refund lure arriving as a group text — a delivery channel corporate email security never inspects. Image: Malwarebytes
Same Playbook, Different Brand: A Facebook Ad Renting Azure All Week
The Amazon pages weren’t the week’s only registration-free operation. From June 30th through July 6th we detected a tech-support scareware campaign hosted on Azure Static Web Apps, on subdomains date-stamped like a daily build: viruswarning0630..., viruswarning0702..., viruswarning0706... — a fresh Microsoft-owned hostname minted each day.
Fake Microsoft Support helpdesk with cascading error popups, a fake firewall lock, and a fake live-chat agent
The pages themselves are a full fake Microsoft Support helpdesk: cascading “System Error” popups, a counterfeit SmartScreen block, a “Windows Firewall has locked your session” password prompt, a scripted live-chat agent, and a call-center number — +1 (877) 291-7893 — repeated at every exit. Delivery came through Facebook paid ads: the June 30th and July 6th URLs carry the same paid campaign ID in their tracking parameters. One ad buy, running for a week, pointing at a new Azure site every day — the same ad-funded phishing model we broke down in June, still running on the same rails.
Why Consumer Amazon Phishing Is a CISO Problem
It’s tempting to file retail lures under personal risk — and the credential itself is the weakest reason to care. Here’s what actually matters:
- Each detection is proof of a path, not just a page. Every event above occurred on a managed corporate device. The lure arrived through a channel the email gateway never inspected — a personal inbox, a text message, a social feed — the user clicked, and the page rendered, one keystroke from harvest. The brand on the page is interchangeable: the operator who rotated
amzonueprimepagetoamazon-verify-accountin 48 hours can serve a Microsoft 365 template from the same machinery tomorrow. A consumer-brand detection is your earliest, cheapest evidence that the delivery path exists and which users take it. - Password reuse converts it — wherever MFA gaps remain. A harvested consumer password becomes a corporate problem at every password-only surface you still run: legacy auth, VPN portals, apps outside SSO. Close all of those and this risk genuinely drops toward zero; most organizations haven’t.
- Corporate purchasing looks identical. Amazon Business accounts, procurement cards, and admin logins answer to the same sign-in page these kits clone.
- Your domain-keyed controls all pass. Secure email gateway reputation lookups, newly-registered-domain blocklists, and certificate validation see an aged, legitimate parent domain with valid TLS — on
cpanel[.]site, onwindows[.]net, ongoogle[.]comredirects. The deception exists only in the rendered page, which means the browser is the last place it can be caught — the same conclusion we reached watching legitimate CAPTCHAs conceal phishing pages from automated scanners.
Mitigations
- Flag or block
*.cpanel.sitepreview hostnames and*.z13.web.core.windows.netstatic sites at the proxy unless there’s a documented business need — legitimate traffic to hosting-panel preview domains is close to zero in most enterprises. - Treat login pages with pre-populated email addresses on non-corporate infrastructure as high-signal phishing indicators in user training and detection logic.
- Brief users on post-purchase pretexts — refund, delivery-problem, and “verify your account” messages that follow major retail events, arriving by both email and SMS.
- Enforce phishing-resistant MFA on corporate identity, and pair it with password-manager policies that make consumer-site password reuse less likely.
- Deploy browser-level protection that evaluates what a page visually is at point of click, rather than trusting where it’s hosted — registration-free infrastructure is specifically chosen to defeat reputation-based controls.
If you are interested in seeing how PIXM can help prevent attacks like these for your organization, book a demo here: pixmsecurity.com/request-demo/
Recent Comments