"Reached" is the key word. The findings show exposure to the scam, not confirmed breaches at all 80 organizations. The scam works by getting a person to pick up the phone, so the harm starts after the page loads.
What was found
A user clicks an ad on a legitimate website and lands on a randomly named Azure Static Website. The destination is typically under *.z13.web.core.windows.net. It shows fake "System Error" alerts, Windows Firewall warnings and an imitation Microsoft Support chat. Every element on the page points to one toll-free number.
PIXM said the adhelper back end accounts for 11 of the 80 organizations. The same fake page kit is also used by other operations. So 11 is not the total exposure, and it is not a count of victims.
How the page gets its phone number
Page code captured on July 23, 2026 shows how the number is chosen:
- JavaScript requests a telephone number from call.adhelper[.]cc/api/get-phone.php through JSONP, passing an ads_manager identifier.
- The operators can swap numbers across every live page at once. That keeps a number working after it has been reported.
- A fallback number remains available when the request fails, so disrupting the number service does not necessarily remove the scam's call option.
- A separate tracking request to adhelper[.]one records the displayed number, campaign, publisher domain and advertising exchange.
PIXM says this is the same data a legitimate pay-per-call marketer uses to see which ads produce calls. That is PIXM's reading of what the system does. It does not prove who the operators are or how they are paid.
A team, not a lone scammer
The code lists ad managers. Three (eooo, sooo, mooo) appear in May, and a fourth, xiaofeng, is added by July. Three managers were active across the captured pages. PIXM reads this, together with manager-specific numbers and campaign tracking, as an organized operation.
PIXM also looked at the phone numbers. Most of those it could check in public toll-free registry data were controlled by one provider, Fractel, in the month they appeared. Many were bought in sequential blocks. PIXM said it has no sign the provider knew of the abuse, and toll-free customers are often resellers.
China-related clues, and their limits
PIXM lists several clues that point toward Mandarin-speaking developers:
- Code comments and error messages are in Simplified Chinese.
- A page captured April 3, 2026 showed Chrome's "press Esc to exit full screen" notice in Chinese.
- adhelper[.]one was registered on March 10, 2026 with a self-reported Hubei province address.
- The number service's root showed the default page of BaoTa, a Chinese server control panel.
- The ad-manager name xiaofeng is a softer clue.
These clues suggest an association. They do not identify the operators, their nationality or where they are. Registration details are self-reported and easy to fake.
Where the ads ran
PIXM's captures and public scan data named placements on Whitepages, Legacy.com, Us Weekly, MSN, KMBC, WordHippo, Juno webmail and US News & World Report's health section. PIXM says these publishers are not complicit. The ads came through programmatic exchanges, and a reviewer may not see the same ad or redirect a victim sees. The same applies to Azure: attackers used it as a throwaway host, and nothing in the research says Microsoft was involved.
Why IT admins should care
PIXM warns that 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. On a work PC, that call becomes a corporate incident.
Microsoft's 2024 research on a different actor, Storm-1811, shows how this plays out. That group misused Quick Assist after impersonating IT or Microsoft support by phone. The Quick Assist session lets the helper view the screen and, if the user approves, take control. Microsoft noted that Quick Assist is installed by default on Windows 11. It is not linked to this 2026 campaign. It does show why an unsolicited support call plus a remote-access request is dangerous.
What to do
PIXM's campaign-specific advice, plus Microsoft's Quick Assist guidance:
- Block the infrastructure at DNS or your secure web gateway. Include call.adhelper[.]cc, adhelper[.]cc, aff.adhelper[.]cc, img.czlbb[.]site and the landing-page patterns message{MMDD}js{NNN}.z13.web.core.windows[.]net and viruswarning{MMDD}us.z13.web.core.windows[.]net. Blocking the number API alone may not neutralize a page, because of the fallback number. PIXM says adhelper[.]one has been on registrar hold since October 22, and that it will share the full host list with defenders on request.
- Tell staff the basics. Microsoft does not put a phone number in a browser pop-up. Closing the tab or force-quitting the browser is safe.
- Restrict remote-access tools on managed devices to approved workflows. Microsoft advises blocking or uninstalling Quick Assist where it is not needed. If you use another sanctioned tool such as Remote Help, remove Quick Assist.
- Tell users to accept remote help only when they started the contact with Microsoft Support or their own IT staff. If someone is acting maliciously on a session, disconnect and report it internally.
- Look at rendered page content, not just hostname reputation. Throwaway Azure hostnames will not appear on reputation lists.
Context and caveats
This is not the first Azure-hosted scam this year. Netskope reported a February Bing-ads campaign that hit 48 US organizations with fake Azure support pages on Azure Blob Storage. PIXM's story differs because of the call-routing back end behind the pages.
Keep the source in mind. The 80-organization count, the 11-organization figure and the attribution clues all come from PIXM, which sells browser-security products. No independent party has verified them, and the research does not report confirmed intrusions. Even so, the infrastructure details are specific and checkable by defenders, and the defensive advice is sound regardless of who is behind the campaign.