Fuyao Android TV boxes became proxies and ad-fraud workers

Bitsight researchers have documented the Fuyao ecosystem: some low-cost Android TV boxes shipped with firmware-bundled applications that spoofed hardware identity, performed advertising fraud and turned the owner’s broadband connection into a SOCKS5 exit node.

Over 24 hours, a sinkhole received 65,957 reports representing roughly 38,000 unique MAC addresses. That is not a physical device count. Profiles and identifiers rotated, and the researchers could see only a subset of older models from one brand.

How Fuyao was discovered

In the primary Bitsight analysis, Pedro Falé describes registering an expired domain used by the devices for backend and telemetry functions. Sinkholing the domain provided visibility into reporting applications without issuing tasks to the boxes.

The most commonly identifiable model was H96_MAX_V11, but the data does not establish a complete product list. Google told reporters that the off-brand products were not Play Protect-certified Android devices. “Android TV box” in a marketplace title does not by itself mean Google TV certification.

Pretending to be a phone

The system downloaded complete phone profiles for brands including Samsung, Huawei, Xiaomi and Vivo. Configuration merged a base identity with per-model differences and removed properties that exposed an underlying Rockchip, Amlogic or Allwinner board.

The objective was economic. Advertising networks value mobile and TV traffic differently, detect unusual devices and limit repetitive clicks. Emulating many phones:

• changes the hardware fingerprint;
• creates apparently independent users;
• complicates activity clustering;
• lets operators select profiles for a campaign;
• hides the real firmware platform.

Spoofed properties can also mislead asset inventory on the owner’s network.

AI in the fraud workflow

The Script application included a YOLOv8s model that identified screen elements such as banners and advertising widgets. It combined computer vision with Android accessibility data and Google ML Kit OCR.

This is a narrow, practical use of AI. The model did not plan the campaign; it helped automation locate where to click as page layouts changed. Operators also used Blockly—a visual language associated with teaching children to code—to assemble modular tasks pushed to devices.

Combining computer vision, OCR, accessibility information and rules produces a more resilient bot than fixed screen coordinates.

Home broadband as SOCKS5

The Center application ran a local proxy server. A box fetched backconnect server addresses and maintained a tunnel capable of multiplexing multiple SOCKS5 sessions.

Bitsight observed overlap with residential-proxy data for at least one in six Fuyao boxes over 24 hours and one in four over seven days. Researchers assess that the operators probably monetised bandwidth through proxy providers.

Logic changed roles according to HDMI state:

• with the television in use, the box tended to act as a proxy;
• with HDMI off, it returned to ad-fraud tasks.

The owner might see no change on screen while third-party traffic left through their IP address.

Why residential proxy abuse matters

To an external service, requests originate from the user’s household address. They may be used for automation, geolocation bypass, account creation or other abuse. Consequences can include:

• IP blocks and repeated CAPTCHAs;
• abuse complaints from the ISP;
• additional bandwidth use;
• attribution of third-party activity to the household;
• an untrusted appliance inside the local network;
• access by system applications to storage, microphones or accounts, depending on model and permissions.

The Fuyao report does not establish that every proxied request was criminal or that every low-cost TV box contains these applications.

Checking and reducing exposure

1. identify vendor, model, firmware and certification status;
2. review system applications and permissions;
3. place the box in an isolated IoT network with no path to laptops or NAS devices;
4. block inbound access from that zone to user networks;
5. restrict DNS and egress to required services;
6. observe long-lived tunnels and unusual ports;
7. measure traffic while the device appears idle;
8. do not sign in with a primary Google account;
9. disable debugging and unknown-source installation;
10. replace the device if firmware has no trustworthy update channel.

A factory reset may not help when applications reside in the system image. Remediation then requires trusted vendor firmware or replacement.

Procurement lessons

A low purchase price may be subsidised by data, advertising or use of customer infrastructure. Before buying a fleet, request:

• exact component and application inventories;
• certification evidence;
• supported lifetime;
• signed updates;
• a vulnerability policy;
• telemetry domains and purposes;
• terms governing traffic and data monetisation;
• operation without vendor cloud.

Our third-party risk-management guide and software supply-chain attack guide provide a broader assurance model.

Sources versus Breachroad conclusions

Bitsight confirms bundled applications, profile spoofing, ad automation, SOCKS5 proxying and sinkhole observations. MAC and report counts do not equal physical devices and do not describe the entire market.

Breachroad’s conclusion is to treat a consumer appliance as an unmanaged service provider inside the network. Segmentation limits impact but does not repair the trust model. Where firmware, update provenance and connection purpose cannot be verified, replacement is the safest option.

Organisational cybersecurity training helps procurement and IT recognise risk in turnkey devices. An IT security audit can assess IoT segmentation, egress monitoring and hardware admission policy.