Threat Investigation · Threat Research
A large-scale fake Microsoft support scam, hosted on Azure, shielded by Cloudflare, and delivered through ads on US publishers, traces back to Chinese developers and a domain registered in Hubei, China.
Summary
- Between March and October 2026, PIXM tracked a fake Microsoft support kit hosted on Microsoft’s own Azure cloud that reached users at 80 organizations. New landing pages were still appearing daily as of November 2.
- The back end behind it, which was hidden behind Cloudflare, strongly suggests an organized operation that includes Mandarin-speaking developers and ad buyers, with ties back to Hubei, China.
Where we left off
In Anatomy of a Phish: How Tech-Support Scams Buy Their Way Onto Your Screen, we traced how fake Microsoft support pages reach victims through paid ads. Those pages run on throwaway Azure Static Websites on Microsoft’s own cloud. The back end we trace here hides behind Cloudflare. This post follows the code of the pages themselves back to the infrastructure and operators behind them.
We start with the script that fetches each page’s phone number, then lay out the Chinese-language evidence behind the back end and what its code reveals about a team of ad buyers. From there we look at where the ads ran and what defenders can do.
1. The page that phones home
A victim clicks an ad on a legitimate website and lands on a randomly named Azure Static Website (*.z13.web.core.windows[.]net). The site fills the screen with fake “System Error” and “Windows Firewall” pop-ups and a fake Microsoft Support chat. Every element points to one toll-free number.
Below we examine the code used to generate the phone number on the page.
window.adsManagers = ["eooo","sooo","mooo","xiaofeng"];
window.currentAdsManager = "xiaofeng";
window.phoneNumber = "(888)XXX-XXXX"; // fallback number (redacted)
//跟踪展示 ("track impression")
function trackingImpression(phone){
img.src = "https://adhelper[.]one/impression/ce895b1f-…?siteid=JS723-" + phone
+ "-" + campaign + "&domain=" + domain + "&exchange=" + exchange;
}
// JSONP 回调 ("JSONP callback")
function handlePhone(data){ if (data && data.phone) window.phoneNumber = data.phone; … }
// JSONP 请求 ("JSONP request")
script.src = 'https://call.adhelper[.]cc/api/get-phone.php?callback=handlePhone'
+ '&ads_manager=' + currentAdsManager;
script.onerror = function(){ console.log('获取号码失败,使用默认号码'); … };
// "failed to get number, using default number"The design shows several things:
- Numbers are assigned centrally. The operator can swap numbers across every live page at once without touching the pages, which keeps a number working even after it has been reported.
- Every impression is tracked. The pixel records which phone number was shown, which campaign, which publisher site the ad ran on, and which ad exchange sold the placement. That is the same data a legitimate pay-per-call marketer uses to work out which ads produce calls.
- Calls are attributed to people. The
ads_managervalue tells the back end whose page this is, so it returns that person’s number.
2. Clues pointing to China
Below we lay out evidence suggesting Mandarin-speaking developers and ties to mainland China.
The developers’ comments. The loader’s comments and error messages are in Simplified Chinese: 跟踪展示 (“track impression”), 加载 React 主程序 (“load the main React app”), 默认号码(兜底) (“default number (fallback)”).
The registration. adhelper[.]one was registered on March 10, 2026, through Gname, with a registrant address in Hubei province, China. The first adhelper-tracked page we captured followed two weeks later. Registration details are self-reported, so on its own this isn’t conclusive.
The mistake victims could see. On a separate family of pages, the kit draws a fake browser bar telling the victim the page is in full-screen mode. It makes a frozen browser look official. The developers copied that notice from their own browser, which was set to Chinese, so English-speaking victims were shown this:


The server panel. The root of call.adhelper[.]cc shows 恭喜,站点创建成功! (“Congratulations, the site was created successfully!”). That is the default page of BaoTa (宝塔), a server control panel popular in China. BaoTa has an English international edition, aaPanel, and the operator installed the Chinese one.
A fifth, softer signal: one of the ads managers in the loader is named xiaofeng, a common Chinese given name written in pinyin.
3. A team, not a lone scammer
The ads-manager list changes over time. In May the loader names three managers (eooo, sooo, mooo). In July a fourth, xiaofeng, is added. Across the pages we captured, users at 11 organizations saw pages from this back end, and three different managers are active. Each page is built for one manager, and the back end returns that manager’s number. The same fake page is also used by other operations. Of the 80 organizations where we saw it, the adhelper back end accounts for 11.
The phone numbers point the same way. For the numbers on these pages that we could look up in public toll-free registry data, most were controlled by the same toll-free provider, Fractel, in the month they appeared. Many were bought in sequential blocks. We have no indication that the provider is aware of the abuse. Customers of toll-free providers are often resellers.
Taken together, it looks like an organized operation. Developers maintain the back end, several ad buyers run campaigns, phone numbers come mostly from one provider, and each buyer gets their own number, so every call can be credited to the buyer who generated it. That is consistent with the pay-per-call model documented in US prosecutions of tech-support fraud, where pop-up publishers were paid for the calls they delivered to call centers.3
4. Where the ads ran
The tracking data inside the pages names the sites where the scam ads appeared. In our captures and public scan data these include Whitepages, Legacy.com, Us Weekly, US News & World Report (health), MSN, KMBC, WordHippo, and Juno webmail. These publishers are not complicit. The ads were bought through programmatic ad exchanges, and the page a reviewer sees is not the page a victim lands on.
Why this matters beyond consumers
The page is after more than credentials. Harm starts on the phone. The usual playbook is to get the caller to install a remote-access tool, charge for a fake fix, then escalate to “refund” and bank-impersonation scams. Older adults lose the most. On a work device the same call is a corporate incident. Ransomware operators have posed as IT help desks to talk employees into opening Microsoft’s Quick Assist, which gave them a way into the network.5
What to do
- Block the infrastructure in Table 1 at DNS or the secure web gateway. Blocking
call.adhelper[.]ccbreaks number delivery on the pages that use it. - Treat ad-delivered pages as an attack surface. See our delivery-side analysis for the ad networks involved.
- Tell staff that Microsoft never puts a phone number in a pop-up. Closing the tab, or force-quitting the browser, is always safe.
- Restrict remote-access tools (Quick Assist, AnyDesk and similar) on managed devices to approved support workflows.
- Inspect what the page renders, not where it is hosted. PIXM’s computer vision recognizes a counterfeit Microsoft Support screen at the point of click, whichever ad network delivered it and whichever throwaway Azure hostname it sits on.
Indicators
Table 1. Indicators. The full host list is available to defenders on request.
| Indicator | Type | Role |
|---|---|---|
| call.adhelper[.]cc | Hostname | Phone-number API (/api/get-phone.php) |
| adhelper[.]cc · aff.adhelper[.]cc | Domain | Back end / affiliate subdomain |
| adhelper[.]one | Domain | Impression tracker (on registrar hold since Oct 22) |
| ce895b1f-f630-4bd5-acd1-e3b9b76addea | Account ID | adhelper tracking account |
| img.czlbb[.]site | Hostname | Second impression tracker |
| 38c0f7e2-0e29-48e2-b097-c87ec2e542d7 | Account ID | czlbb tracking account |
| 6808f1a5753e2219109a9cc4 | tawk.to property | Live chat, w…what… pipeline |
| message{MMDD}js{NNN}*.z13.web.core.windows[.]net | Hostname pattern | Landing pages (live) |
| viruswarning{MMDD}us*.z13.web.core.windows[.]net | Hostname pattern | Landing pages (Mar–Sep 2026) |
References
- Anatomy of a Phish: How Tech-Support Scams Buy Their Way Onto Your Screen, PIXM, October 2026.
- Dial One for Scam: A Large-Scale Analysis of Technical Support Scams, Miramirkhani et al., NDSS 2017.
- Three Sentenced In International Multi-Million Dollar Tech Support Fraud Scheme, U.S. Attorney’s Office, W.D.N.C., February 2026.
- Malicious Bing Ads Lead to Widespread Azure Tech Support Scams, Netskope Threat Labs, February 2026.
- Threat actors misusing Quick Assist in social engineering attacks leading to ransomware, Microsoft Threat Intelligence, May 2024.
Questions, or want the full indicator set? Contact [email protected]. To see PIXM’s point-of-click protection, request a demo.