Spoofing: fake websites, apps and devices

Programmatic advertising runs on labels. A bid request tells buyers which website or app the ad will appear on, what kind of device the viewer has, and roughly where they are. Buyers bid more for premium labels: a major newspaper, a top streaming app, a smart TV. But for years nobody checked whether the label was true. Spoofing is lying on the label.

It is like selling tap water in bottles printed with a luxury brand's logo. The buyer at the wholesale market only sees the label, pays the luxury price, and never tastes the water. Spoofing works for the same reason: in an automated auction, the bid request is the label and nobody tastes the water until much later, if ever.

Three kinds of spoofing

Domain spoofing and domain laundering

In its crudest form, a fraudster simply writes a famous domain into the bid request. A subtler variant, sometimes called domain laundering, sends traffic from a low-quality or fraudulent site but declares a cleaner, higher-value site it controls or pretends to represent. The MRC lists domain laundering and falsified site location as SIVT. Because many buyers built their allow-lists around big publisher names, spoofing let fraud walk straight through the front door.

The economics are brutal. If a spoofed request claiming to be a national news site in the UK or Japan wins at a $10 CPM while the real source would fetch 50 cents, the fraudster keeps the difference on every impression, and the real publisher loses a buyer who believes they already bought that site.

App spoofing: the evil twin trick

In July 2024, HUMAN's Satori threat intelligence team disclosed Konfety. Its operators published about 250 harmless-looking decoy apps on Google Play. Separately, they spread "evil twin" apps through malicious ads outside the store. The twins claimed the decoys' app IDs and publisher IDs when requesting ads, so ad platforms believed the traffic came from legitimate, store-listed apps. HUMAN said Konfety-linked bid requests peaked at 10 billion a day. In 2025, researchers at Zimperium reported a new Konfety variant using deliberately malformed app packages to resist analysis, a reminder that disrupted schemes often return in new forms.

Device spoofing: why everyone wants to be a TV

Connected TV ads often sell at several times the CPM of mobile display, so pretending to be a TV is lucrative. In April 2021, HUMAN, with Google, Roku, The Trade Desk, Magnite, Omnicom and others, disclosed PARETO: a botnet of nearly one million infected Android phones that impersonated streaming devices running Fire OS, tvOS, Roku OS and other TV platforms. HUMAN observed an average of 650 million PARETO bid requests a day, generated by 29 Android apps spoofing more than 6,000 CTV apps.

The industry's answer: a chain of receipts

Because the problem is unverified labels, the fix is verifiable ones. The IAB Tech Lab created three standards that work together, often summarised as "who is allowed to sell, who is selling, and through whom".

1. ads.txt and app-ads.txt: who is allowed to sell meThe publisher posts a public file (ads.txt on its website, app-ads.txt on the developer site listed in the app store) naming every ad system and account ID authorised to sell its inventory, and whether each is a direct seller or a reseller. A buyer can check that the seller in the bid request is on the list.
2. sellers.json: who that seller actually isEach SSP or exchange publishes a sellers.json file identifying the businesses behind its seller account IDs, so buyers can see which company they are paying.
3. SupplyChain object: every hop in betweenThe supplyChain object (schain), carried inside the OpenRTB bid request, lists every intermediary that touched the impression. A buyer can check that each hop matches the ads.txt and sellers.json records.
4. ads.cert: signing the labelads.cert adds cryptographic signatures so key fields cannot be altered in transit. Adoption has been slow, but it targets exactly the tampering that spoofing relies on.

1. The publisher declares its sellers: news.example posts a public file, ads.txt, listing every company allowed to sell its ads and the account ID it uses, marked DIRECT or RESELLER.
2. A bid request arrives: The DSP receives a request “for news.example”, sent by SSP account 1234, with a SupplyChain object listing every hop it passed through.
3. Check 1: is this seller authorised?: The buyer checks news.example/ads.txt: is SSP account 1234 listed? If not, the request is unauthorised and is not bought.
4. Check 2: who is account 1234?: The SSP’s sellers.json names the business behind 1234 and whether it is the publisher itself or an intermediary. Hidden sellers are a warning sign.
5. A spoofer tries the same trick: A fraudster sends requests claiming to be news.example from its own junk site. This is domain spoofing. Its seller ID is not in news.example’s ads.txt.
6. Only verified paths get bought: Requests whose seller, ads.txt entry and schain all line up get bought; the spoofed ones fail. Simple public files closed one of the biggest fraud loopholes of the 2010s.

What detectors check beyond the files

• Declared vs observed: does the page URL or app bundle seen when the ad renders match what the bid request claimed?
• Volume sanity: is a small publisher suddenly selling more impressions than its known audience could produce, or through dozens of resellers?
• Device consistency: does a "smart TV" behave like a TV, with TV-like screen size, network, session length and household patterns, or like a phone?
• Reseller depth: long chains of resellers are a classic hiding place for laundered inventory, which is why supply path optimization favours short, direct paths.