852 of 1,235 Meta ads led to 17 toll fraud apps, and Google's takedown did not stop the billing server

Sixty-nine per cent of the ads, and a server that outlived the takedown

On 14 September 2026, CERT Polska found two Facebook ads telling Polish users that their PDF application had expired. Both sent the reader to a Google Play listing for an app called Messenger Pro. Nine days later, on 23 September, one of Poland's three national CSIRTs, published its analysis: it had preserved 1,235 Meta ads, and it could tie 852 of them, shown under 60 profile names, to 17 Google Play apps through shared code or infrastructure.

That is 69.0 per cent of everything it preserved (852 divided by 1,235 is 0.6899). The figure is ours; CERT Polska gives the two counts, not the share. The ads CERT Polska could not tie to the operation are not innocent by default either: its own table sets aside 90 whose destination had gone and 82 whose app could no longer be downloaded.

The second fact matters more to a defender. CERT Polska reported Messenger Pro to Google on 15 September and Google removed the listing. The command server did not go with it. In the report's words, the infrastructure "continued to accept controlled Polish registrations and issue jobs" after the listing was removed. The jobs it issued were billing jobs: send a keyword to a premium SMS short code, or open a carrier billing page in a hidden browser window and confirm it with the PIN the network texts back.

So this is not a story about how much money was taken. It is a story about which controls touched which half of the operation, and that is a question a UK security lead can ask of their own estate this week.

How it worked, at the level a defender needs

The lure was plain. The Polish ad text translates as a warning that the reader's PDF application had expired and that they would lose access to their files unless they updated now. The ad went straight to the Play listing. Nothing on that listing mentioned PDFs. Messenger Pro presented itself as version 9.0 of a messaging app with a password lock and emoji support.

The app worked as a messenger, and that is the disguise. A messaging app can legitimately ask to become the phone's default SMS handler, and once a user accepts, Android grants it permission to read, receive and send SMS through that role. CERT Polska observed exactly that grant in its test environment. The cover app uses the permission for messaging; the downloaded code uses the same permission for billing.

The fraud code was not in the app Google reviewed in any readable form. CERT Polska describes four layers:

1. The installed app, which rebuilt an encrypted first stage in memory. The loader was a sliver of the package: 0.552 per cent of about 40 MB of the app's compiled code.
2. A country gate, which checked the SIM's mobile country code against an allowlist of 15 countries and stopped if the phone was elsewhere.
3. A router, which read a policy from a remote server and chose which payload to fetch.
4. The payload, downloaded from cloud object storage and loaded in memory, which registered the phone with the command server and polled it for work.

CERT Polska also found that the app's process could start without the user ever opening it, because Android started it to answer a routine request to one of its declared components shortly after installation. A person who installed the app, disliked it and never opened it again was not necessarily safe from it.

The command server decided what each phone should do, based on what the phone reported it could do: whether it had a mobile data path, and whether it could send and receive SMS. Two billing routes followed.

• Premium SMS. The server supplied a subscription page and a script that clicked its SMS button. The payload then sent the keyword to the short code itself, and waited for the confirmation reply to arrive so it could answer it.
• Direct carrier billing. The payload forced traffic over the mobile network, so the billing provider would see the subscriber's identity, opened the billing page in a browser view the user never saw, filled in the number, caught the PIN from the incoming text and confirmed the order.

Not every cover app could do both. Phone Cleaner Master, a utility cover in the same operation, did not ask for SMS permissions at all, so it was limited to the carrier billing route. The operator reused one payload framework and switched on whatever each cover could support.

What CERT Polska observed in controlled runs, and what it did not establish (source: CERT Polska, 23 September 2026)

Behaviour	Observed in the test runs	Not established
Ad leads to Play listing	Yes, two ads captured 14 September	How many people clicked or installed
Default SMS role grants SMS permissions	Yes, on Android 15	Whether users were prompted differently on other versions
Server accepts a Polish phone and issues jobs	Yes, including after the listing was removed	How long the server kept running after 21 September
Premium SMS to 92505, 92512, 92513	Attempted; intercepted in the lab	Any real message reaching a network
Hidden carrier billing page at 17 PLN a week	Page loaded; lookup request made	The number, PIN and confirm steps running live
Notification interception, network relay	Present in code, not activated	Use against any real phone

CERT Polska is careful about that line, and the article should be too. It says "observed" for behaviour it captured and "capability" for code that was present but not activated. Every controlled run returned a failure result. When it polled the server 50 times from one test profile, it received 41 unique jobs and nine empty responses, and it states plainly that repeated polling "cannot be used as a victim count".

The half that was counted and the half that was not

The split between six and eleven is worth keeping. Six apps exposed recovered toll fraud components or direct payload links; together they carried 532 of the ads. Eleven more contained the operation's loader, but CERT Polska could not recover their final payloads, so it will not say those eleven billed anyone. They carried the other 320. Our arithmetic across both of CERT Polska's tables reconciles: the six apps' ad counts sum to 532, the eleven to 320, and the 60 profile rows to 852.

What a victim would have paid

CERT Polska checked the three short codes the server handed out against the Polish regulator UKE's public register of premium numbers. All three, 92505, 92512 and 92513, were active registered premium SMS services at a gross price of 30.75 PLN per message, across Orange, T-Mobile, Play and Polkomtel. One captured subscription page tied to 92513 disclosed a one-time charge of 30.75 PLN for three months of access. We did not query the UKE register ourselves; those register details rest on CERT Polska.

The carrier billing route was the recurring one. A Teleaudio page reached through the server's jobs advertised 17 PLN every seven days. Over 52 weeks that is 884 PLN.

Charges named by CERT Polska, converted at the ECB euro reference rates of 28 September 2026 (EUR 1 = GBP 0.85785 = PLN 4.3730, so PLN 1 is about GBP 0.196). Sterling figures are approximate

Charge	In zloty	Approximate sterling
One premium SMS to 92505, 92512 or 92513	30.75 PLN	about 6.03 pounds
Teleaudio carrier billing, per week	17 PLN	about 3.33 pounds
Teleaudio carrier billing, 52 weeks	884 PLN	about 173 pounds

Those are per-subscriber prices, not losses. The reason they matter is the shape: a charge of a few pounds a week, labelled on a bill as a payment mechanism rather than as the fraud it is, is the kind of line that survives months of unread statements.

CERT Polska is also careful to separate the billing providers from the fraud. The companies that operate the registered short codes "are the billing providers, not the operator of the malware campaign". That is method, not accusation, and it is worth copying when these names turn up in a UK incident review.

Removal from the store is not removal from the phone

CERT Polska's account of the takedown is the most useful paragraph in the report. Removing Messenger Pro "stopped new installations through its listing but did not affect copies already installed on users' devices". Every app it found was reported to Google and removed. It reported the ads to Meta, and Meta removed those ads, but only those: others in the same operation "may have remained active" without CERT Polska's knowledge. And "new packages appeared".

The infrastructure was still being built during the takedown. All 20 parent domains behind the apps' policy servers were registered through the same registrar between 10 July and 17 September 2026, a span of 69 days. The last of those dates is two days after the report to Google. Two earlier domain pairs were registered 29 and 38 seconds apart, which CERT Polska reads as consistent with automated registration. Domains that cheap are not a control point; blocking them is housekeeping.

The report does not say whether Google took any action on devices that already had the app, and we have not seen a statement from Google or Meta on this campaign. We do not assume either way. What the record supports is narrower: a store removal is a distribution control. It is not remediation for the phones already carrying the code.

Labels that sound like controls, set against the record (sources: CERT Polska; Ofcom; EE)

The label	What it sounds like	What the record shows
Available on Google Play	Reviewed and safe	The fraud code was fetched after install, four layers down
Removed from the store	Fixed	New installs stopped; installed copies and the server carried on
Ad removed by Meta	Campaign stopped	Only the ads CERT Polska reported
Default SMS app	An ordinary messaging permission	Read, receive and send SMS, used here for billing
Premium rate bar	No premium charges	EE's 09 voice bar does not cover third-party short codes

Two platforms, one pipeline

CERT Polska puts the division of labour simply: Meta supplied paid reach aimed at Polish users, and Google Play supplied an installation path that users treat as reviewed and trustworthy. Neither half alone would have worked as well. An ad that sent people to a download from an unknown website asks the reader to take a risk they have been told not to take. An ad that sends them to Google Play does not.

CERT Polska was also disciplined about what counts as linked. It did not treat a shared advertiser profile or a similar lure as evidence. It linked ads and apps only through exact ad destinations, matching media hashes, shared loader code, or specific DNS, TLS and hosting overlaps. It set aside 98 ads from profiles that also pushed the operation's apps, because the apps in those ads were comic readers with different code. That restraint is why the 852 figure is a floor, not a guess.

What a UK reader can and cannot take from this

Start with what the code says. Messenger Pro's country gate allowed 15 mobile country codes: Thailand, Indonesia, Malaysia, Turkey, Saudi Arabia, the United Arab Emirates, Poland, Austria, Greece, Germany, Nigeria, France, Romania, Switzerland and China. The United Kingdom's codes, 234 and 235, are not on it. On that build's logic, a phone with a UK SIM would have been stopped at the gate. That is an inference from one build, and a weak comfort: the country policy was served remotely, and CERT Polska showed a later build moving Poland onto a different payload simply by changing the policy.

There is one UK thread in the report. Both of the operation's command servers told test phones to send a coded text to the same UK mobile number, and a separate code path treated incoming texts in that format as a pairing message. CERT Polska says it saw the send instruction but not the receiving side, "so the exact role of the UK number remains unconfirmed". We are not reprinting the number: it may belong to a person with no knowledge of the operation. What it does show is that UK numbering was part of the operation's plumbing in some role. It does not show UK victims.

The UK controls are real but narrower than their names. Since 1 February 2025, Ofcom has regulated premium rate services directly under its PRS Order, replacing the Phone-paid Services Authority's Code of Practice. Ofcom's consumer guidance says its rules require that nobody is charged for a premium rate service without consent. It also warns that a bill may show such charges only as "Charge-to-mobile, Operator Billing, Direct Carrier Billing or Google Play", which are payment mechanisms, not the name of whoever charged you.

On blocking, Ofcom's own wording is careful: "Some mobile networks" are able to block premium rate services on an account. Not all, and not by default. EE's published guidance shows why the name of a bar is not enough. Its barring of 09 numbers is a voice bar, and EE states that it does not bar calls to third-party voice short codes. Third-party charges on an EE bill appear under "Services from other companies" and use short codes and direct carrier billing. A security lead who has "a premium rate bar" on the corporate fleet should find out which of those it actually covers.

What to do, in the order worth doing it

Ofcom's service checker and complaints form are for identifying and reporting a provider; Ofcom says it does not investigate or resolve individual complaints. The refund conversation starts with the provider that charged you.

The question the takedown leaves open

Google removed what it was told about. Meta removed what it was told about. Both actions were real and both were fast enough to appear in a report published nine days after the first ad was found. Neither reached the phones that had already installed the apps, and nothing in the public record says how many of those there were or whether anyone told their owners.

When a store pulls a billing trojan, who tells the phones that already have it, and who tells the network that is still accepting its charges?

Key facts