Loading today’s stories
Security1 distinct publisher3 min readPublished
Malwarebytes took apart a tech support scam page built for iPhones rather than desktops, where the receipt values are hardcoded, the voice comes from the browser's speech API, and the only payload is a phone number.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
Apple Pay on the web has a fixed shape. The merchant requests the payment, the system puts up a payment sheet, and the user reviews and authenticates it, which is what Apple's own guidelines specify [9]. None of that runs here. The "Face ID / verifying identity" line is an HTML element sitting beside an icon, with no Apple Pay request and no biometric-authentication call behind it [8], and the splash screen it sits on removes itself on a 2.8-second timer whether the victim touches anything or not [10].
The receipt is where the sample gives itself away. Amount, transaction ID and authorization code are hardcoded at $657.00, AP-2026-08-03-14:32 and AUTH-8F3A2B1C, identical for every visitor [11]. The date field is not: JavaScript calls new Date() and formats it with toLocaleString(), so the receipt carries the victim's own clock and timezone [12]. Because the ID date is frozen and the date field renders at view time, the two only agree for someone who opens the page on 3 August 2026 [13]. Malwarebytes flags that mismatch as the contradiction a genuine transaction cannot produce [12].
The audio is the part other kits will copy. The page creates a SpeechSynthesisUtterance and hands it to window.speechSynthesis, the browser's built-in Web Speech API, and the device reads out "Unauthorized charge of six hundred fifty seven dollars from your Apple ID. Please call support immediately" [14]. No hosted file, no recording, nothing to take down. Malwarebytes notes the effect: a voice already installed on the phone sounds more like the phone than like a website [18].
Most of the remaining code is spent on the exits. The page pushes a history entry and listens for popstate, so a backward gesture triggers a warning that closing the page could expose the victim's payments and banking information [15]. Cancel that prompt and it raises another warning and pushes another history entry; accept it and the code navigates to a tel: URL holding the scam number [16]. Handlers are also registered for beforeunload, pagehide, the context menu, an edge-swipe gesture and common keys [17]. Every item on that list is a page-level event.
Scope, plainly. There is no real transaction and no biometric verification in the sample, and the analysis describes hardcoded values, browser speech, fake warnings and navigation tricks whose whole purpose is to get the victim dialling [7]. Nothing is stolen by the page. The money moves after the call connects, and this write-up stops at the tel: handoff.
The funnel is the one that has run on desktops for years behind "your computer has a virus" pages [2]. What mobile changes is the distance to the phone call: on a desktop the victim had to pick up a second device and type the number, while here the number is a tap and is never read closely [16]. That is the reason the old desktop advice has to be restated for phones, against Apple Pay, Face ID and App Store branding rather than antivirus branding [3].
Ranked by verification strength, evidence, and original report placement.
The page adds a new browser-history entry and listens for popstate so it can react when a victim navigates backward, then displays a warning claiming that closing the page could expose the victim's payments and banking information.
If the victim accepts the prompt to call support, the code navigates to a tel: URL containing the scam number; if they cancel, another warning appears and another history entry is added.
The page also registers handlers for beforeunload, pagehide, the context menu, an edge-swipe gesture and common keys.
iPhone users are being targeted in a new tech support scam that uses a fake Apple Pay notification.
Tech support scams that use fake warnings to push victims into calling a phone number have been around for years, typically as a desktop warning claiming the computer has a virus; this page was designed specifically for phones.
The scam imitates familiar iPhone features including Apple Pay, Face ID and App Store payments, uses the phone's own text-to-speech capabilities, and attempts to interfere with mobile navigation.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 27, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific code-level teardown, single unverifiable sample
The claims are unusually concrete for a scam write-up: named hardcoded strings, an exact 2.8-second timer, the specific Web Speech API calls, the history/popstate and beforeunload/pagehide handler set, and an internally consistent contradiction between the fixed transaction ID and the device-generated date. That specificity is strong evidence about the artifact examined. It is discounted because everything comes from one vendor's private sample with no published URL, hash or scam number, so no reader can independently reproduce or verify it.
No prevalence or campaign data
The only observation is one vendor's analysis of a single page. The source gives no encounter telemetry, campaign volume, geography, victim counts, losses, hosting infrastructure or takedown status, so the real-world spread of this scam cannot be quantified from the supplied material.
Framing slightly cooler than the mechanics described
The write-up debunks rather than amplifies: it states plainly that there is no real transaction and no biometric check, that the spinner and Face ID line are decoration, and that the exit-blocking tricks cannot lock the browser or device because modern browsers restrict them and beforeunload is unreliable on mobile. Against that, 'new' and 'targeted' framing carries mild novelty inflation and no prevalence is offered, which pulls the score back toward zero. Net result is close to aligned with a slight tilt toward understatement.
Commercial security vendor publishing its own sample analysis
The sole publisher is a consumer anti-malware vendor writing on its own blog about a threat its analysts examined, which creates a routine awareness-and-brand incentive and means the sample selection, framing and 'what to do' guidance are all controlled by an interested party. The score is held mid-range because the piece is technically substantive, contains no product pitch or upsell in the supplied text, and cites external authorities (Apple, the FTC) rather than only itself.
Credible mechanics, unreplicated and unmeasured
Confidence in the technical description of the analyzed page is fairly high because the details are specific, mutually consistent and consist of well-documented browser behaviour. Confidence in the broader story is limited by a single publisher, no independent corroboration, no published indicators, and no data at all on how widespread the campaign is.
Follow any of these and your For You feed starts watching them — no settings page required.
product
The $149.99 pop-up copies Apple's design system, which makes it support's problem1 distinct publisher
build
Two bits and a signature: what DeviceCheck and App Attest actually guarantee1 distinct publisher
product
Walmart caved on tap to pay, and would not say Apple's name9 distinct publishers
build
The ATT prompt only fires when the app is active, and iOS never tells you when it didn't1 distinct publisher