On October 8, Bitdefender Labs published research on Midnight Mimosa, a malware family found preinstalled in the firmware of low-cost Android phones. Over roughly two years it showed up on thousands of devices in more than 150 countries, with Mexico, France and Italy at the top, followed by the United States, Germany, Brazil and Spain. It lives in the system partition, it is there before the first boot, and the owner cannot uninstall it.

Most coverage treated it as a consumer security story. For programmatic it is something more uncomfortable: a clean demonstration that the device itself can be the fraud, and that most of the checks the industry relies on are looking in the wrong place.

How the scheme makes money

Bitdefender's write-up is unusually detailed about the monetization layer. Reduced to its essentials:

  • A platform-signed system app silently installs and rotates a set of “cover apps”: weather, app-lock, notes and OCR utilities that look like ordinary low-end tools.
  • The cover apps load real ads through a legitimate ad SDK, so the ad network credits them with the revenue.
  • A fraud plugin opens full-screen ads and overlays without any user action, triggered by screen-state changes or remote commands, and marks them as secure windows so they never appear in screenshots.
  • Clicks are synthetic and throttled by remote config: silent-click percentage, minimum click interval, tap placement, daily caps. A “conversion” is reported about sixty seconds after an ad is shown.
  • The same devices are enrolled as residential proxy nodes, renting out their home IP addresses for other traffic.

Thirteen apps carrying the same fraud markers were also found on Google Play, as genuine builds that had passed review.

Why the usual checks pass

Walk this traffic through a typical pre-bid stack and see what gets flagged.

  • IP reputation: residential, consumer ISP, not a datacenter. Clean.
  • Device: a physical phone with a real Android build, not an emulator. Clean.
  • App: a real bundle with a store listing, possibly correctly authorized in app-ads.txt. Clean.
  • SDK: a legitimate, known ad SDK making ordinary requests. Clean.
  • Behavior: clicks capped and spaced specifically to look organic. Mostly clean.

That is the core lesson. app-ads.txt and sellers.json answer one question: is this seller authorized to sell this app? They say nothing about whether a human was looking at the screen. Datacenter and proxy lists are built to catch traffic pretending to come from a phone. Here the traffic really does come from a phone. The phone just isn't working for its owner.

The damage also leaks beyond in-app. Because infected devices rent out their IPs, a residential address that looks trustworthy for web or CTV traffic may be relaying somebody else's bot.

What the bid request still gives away

Firmware fraud hides from the user, not from the data. Most of its tells are visible on the supply side, as long as you look at combinations of fields rather than each field on its own.

  • Devices that don't exist. Many infected handsets are counterfeits reporting flagship names (“S25 Ultra”, “i17 Pro Max”, spoofed Samsung model codes) while running on budget MediaTek chipsets. A device that claims to be a flagship but arrives with an entry-level OS build, an unusual screen resolution or a hardware string no real flagship ships with is a consistency failure, not a rounding error.
  • Rare hardware with outsized volume. The two highest-volume models in Bitdefender's data were budget rugged phones. When a niche device model suddenly makes up a meaningful share of a bundle's requests, that ratio is a signal.
  • Utility apps that monetize like games. Weather, app-lock and OCR tools with modest install bases rarely generate heavy full-screen inventory. Request volume per active device, interstitial share and session shapes that don't match the app category deserve a second look.
  • Ads with no session around them. Impressions fired on screen unlock, or while the device is otherwise idle, cluster in time in a way human sessions do not.
  • Engagement that is too regular. Throttled synthetic clicks produce suspiciously stable CTRs per device, and conversions land at a fixed delay after the impression. Click-to-conversion timing is one of the clearest tells for the advertiser and its measurement partner.
  • Bundles that travel together. Cover apps are installed and rotated as a set. When the same small group of unrelated utilities keeps appearing on the same devices and the same models, it is a mesh, not a coincidence.

None of these is proof on its own. Together, they turn an impression that passes every single-field check into one that fails a consistency check.

Why this is a supply-side job

A single DSP sees its own wins. A single advertiser sees its own conversions. The supply side sees every request, across buyers, bundles and device models, before anyone bids. That makes it the natural place to correlate device consistency, bundle behavior and timing patterns, and to act on them before the impression ever reaches an auction.

Third-party IVT verification remains essential and belongs in the path. But firmware fraud is a reminder that verification works best when it is fed richer signals, and that “clean IP, real device, authorized seller” is no longer the same thing as “real audience”.

A short checklist for buyers

  • Ask supply partners how they validate device model consistency, not just IP type.
  • Break down in-app spend by device model and app category, and flag rare models with an outsized share.
  • Check click-to-conversion timing distributions, not just CTR.
  • Put small utility apps with game-like ad volume into a review queue.
  • Remember that app-ads.txt is about authorization, not about who is holding the phone.

Where Meazy stands

This is why we build around signals rather than volume. Enriching each bid request with SDK, supply and third-party signals is not a feature for its own sake: it is how an impression that looks clean field by field gets checked as a whole. Midnight Mimosa's footprint also overlaps with the markets we serve. France, Italy, the United States, Germany and Spain are all on Bitdefender's top list, which is one more reason we treat device-level consistency as part of supply quality rather than an afterthought.

The takeaway

For years, ad fraud was a traffic problem: fake users, datacenter IPs, emulators. Midnight Mimosa shows the next version: real phones, real apps and real SDKs, compromised before the box is opened. You cannot blocklist your way out of that. You have to ask whether everything in the bid request agrees with everything else. The fraud lives in the firmware, but its fingerprints are still in the data.

Source: Bitdefender Labs, “The phone was compromised before the user turned it on: the rise of Midnight Mimosa” (October 2026).