Researchers: Marion Habiby, Joao Santos, Vikas Parthasarathy, Joao Marques, Adam Sell, Inna Vasilyeva,  Maor Elizen, Gabi Cirlig, Zach Edwards

As the classic story goes, the Trojan War ended after the Greeks tricked the Trojans into wheeling a large horse filled with soldiers into the gates of the city, whereupon the warriors escaped the horse and conquered the city. It became a metaphor for a style of cyberattack in which a user is tricked into downloading a file that, once opened, wreaks havoc on the user’s device.

The metaphor is particularly apt in the story of HUMAN’s Satori Threat Intelligence and Research Team’s latest disruption, an operation we’ve named BADBOX. BADBOX is a complex, interconnected series of fraud schemes, the scale of which is virtually invisible from the surface.

At its simplest, BADBOX is a global network of consumer products with firmware backdoors installed and sold through a normal hardware supply chain. These backdoored devices find their way into the homes and offices of unsuspecting owners, whereupon they immediately connect to a command-and-control (C2) server for instructions from the threat actors behind the scheme. Several types of fraud come from the infected devices:

• ad fraud (both through apps developed and owned by the fraudsters, and through hidden WebViews independent of any apps)
• residential proxy services (using backdoored devices as the exit points)
• fake email and messaging accounts
• remote un-permissioned code installation

The extent of BADBOX’s spread and impact is massive. HUMAN’s Satori team observed more than 74,000 Android-based mobile phones, tablets, and Connected TV boxes worldwide showing signs of BADBOX infection.

Products known to contain the backdoor have been found on public school networks throughout the United States.

HUMAN customers have been protected from PEACHPIT, the ad fraud component of the BADBOX operation, for many months. Satori has shared information about the threat actors with US law enforcement.

For a high-level overview of BADBOX and PEACHPIT, visit our blog. What follows below is a more technical description of the operations. 

Executive Summary

HUMAN’s Satori Threat Intelligence and Research Team has uncovered a vast, complex, global cybercriminal operation we’ve named BADBOX. A Chinese manufacturer (possibly many manufacturers) builds a wide variety of Android-based devices, including phones, tablets, and CTV boxes. At some point between the manufacturing of these products and their delivery to resellers, physical retail stores and ecommerce warehouses, a firmware backdoor—based on Triada malware—gets installed and the product boxes are sealed in plastic, priming these devices for fraud on arrival at their destination.

The Triada malware, first uncovered in 2016, modifies a core process of the Android OS. By doing so, Triada effectively installs itself in every app on the device, including some system functionality, like text messaging. For example, researchers have described how the trojan’s developers monetized the malware by intercepting payment-related text messages and changing the links to pay themselves instead. The root access Triada gains makes it remarkably powerful as a tool for cybercriminals.

Infected devices, once turned on, immediately connect to one of several C2 servers. The backdoor is used to inject additional modules into device memory, enabling the threat actors to extend their capabilities, perpetuate (and cover the tracks of) several types of fraud, including multiple varieties of ad fraud, the establishment of residential proxy exit nodes, creation of fake Gmail and WhatsApp accounts, and remote un-permissioned code installation. 

One of the modules deposited by the C2 servers enables BADBOX-infected smartphones, tablets, and CTV boxes to create WebViews fully hidden from the eyes of the owner. Those WebViews are used to request, render, and click on ads, spoofing the ad requests to look like they’re coming from certain apps, referred by certain websites, and rendered on certain models of smartphones, tablets, and CTVs, none of which are true. This module is one component of PEACHPIT, the ad fraud portion of BADBOX. PEACHPIT may be the element of the operation that pays for all of the others.

An additional component of PEACHPIT, expanding beyond the backdoor-based fraud, is a collection of 39 Android, iOS, and CTV-centric apps, each of which contains a hard-coded connection to a fake supply-side platform (SSP). The ad returned by the SSP loads or injects a piece of JavaScript code into a WebView within the app, spoofing details about the smartphone, tablet, or CTV the app is running on before calling for an ad.

PEACHPIT reached a peak of 121,000 infected Android devices and 159,000 infected iOS devices. These devices accounted for an average of 4 billion ad requests a day. No iOS devices were themselves impacted by the BADBOX backdoor; they were targeted only by PEACHPIT apps available for download from many major app marketplaces.

The residential proxy module of BADBOX transforms each device into an endpoint for a global residential proxy network. This allows the threat actors behind BADBOX to sell access to your home (or work or coffee shop or library) network, which in turn may result in cybercriminal activity being traced to your door.

Threat actors can also use the backdoored devices to create WhatsApp messaging accounts by stealing one-time passwords from the devices. Additionally, threat actors can use the devices to create Gmail accounts, evading typical bot detection because the account looks like it was created from a normal tablet or smartphone, by a real person. These may be useful for a number of reasons, including as a database of potential “developer” names with which to stage new fake apps, as a list of accounts with which to sign up for limited-access WhatsApp channels, or, if incorporating the residential proxy capabilities, to stage cybercrimes that would trace back to the owner of the device, rather than the actual cybercriminals.

Finally, because of the backdoor’s connection to C2 servers on BADBOX-infected smartphones, tablets, and CTV boxes, new apps or code can be remotely installed by the threat actors without the device owner’s permission. The threat actors behind BADBOX could develop entirely new schemes and deploy them on BADBOX-infected devices without any interaction from the devices’ owners.

As of this writing, PEACHPIT has been disrupted. Traffic associated with the ad fraud scheme has slowed to less than 1% of its peak following countermeasures deployed by HUMAN. The remainder of BADBOX should be considered dormant: the C2 servers powering the BADBOX firmware backdoor infection have been taken down by the threat actors. It’s likely the threat actors are adapting their attack in an attempt to circumvent the defenses HUMAN and other organizations have deployed. HUMAN customers have been protected from the impacts of PEACHPIT since their discovery. HUMAN’s Satori team will continue to monitor BADBOX and PEACHPIT for adaptation.

Unfortunately, BADBOX-infected devices are unsalvageable by an average user. Since the malware is located on a read-only (ROM) partition of the device firmware, the average user won’t be able to remove BADBOX from their product. As BADBOX affects almost entirely lower-price-point, “off-brand” devices, the Satori team recommends that users stick to familiar brands when choosing new devices.

Acknowledgements

The cybersecurity community prides itself on recognizing the research upon which new findings are built. HUMAN’s Satori Threat Intelligence and Research Team would like to acknowledge the work of the following security researchers, each of whom have published findings that correlate to elements of the BADBOX scheme:

• Kaspersky’s findings about the original Triada malware
• Daniel Milisic’s findings about backdoored T95 CTV devices
• Linus Tech Tips’ video about various backdoored devices
• Malwarebytes’ findings about backdoored T95 CTV devices
• Malwarebytes’ findings about backdoored cellphones acquired through the Lifeline program
• EFF’s findings about backdoored CTV devices
• Trend Micro’s findings about backdoored mobile devices and the group behind them

The work of these researchers has been instrumental in expanding the public’s knowledge of elements of the BADBOX scheme, and the Satori team is grateful to them for their research.

About This Research

In the spirit of the story of the Trojan Horse, we’ll examine BADBOX from two primary angles: the horses and the warriors.

We’ll begin with the horses: the devices, the backdoors built into those devices, and the marketplaces on which these infected devices were and are available.

Then we’ll look at the warriors: the various fraud schemes infected devices are capable of.

The Horses

Any examination of the vast BADBOX operation must, necessarily, begin with the boxes for which it’s named. 74,000 individual products in 227 countries and territories have exhibited signs of infection.

Building the Horses

In mid-2022, HUMAN’s Satori Threat Intelligence and Research Team (which includes security researchers, reverse engineers, data scientists, and developers of fraud detection methods for the Human Defense Platform) examined an Android app with a spoofed and malformed user-agent that appeared to be passing invalid advertising traffic. During the course of this analysis, researchers unearthed several related apps, each of which was corresponding with a server with the domain flyermobi[.]com. This wasn’t an expected behavior, and the Satori team began researching the domain and its connections to the apps.

Soon thereafter, a security researcher named Daniel Milisic posted on Reddit and other forums about a set-top product he had purchased called a T95 box. The device offers smart TV features, including a single interface from which a user can watch streaming content. Milisic used a Raspberry Pi to observe behavior of the T95 and found that it was connecting to flyermobi.

The Satori team also purchased a T95 device and confirmed Milisic’s findings while corroborating our own suspicions about flyermobi: the T95 device was compromised right out of the box.

T95 Android TV box

Importantly, the T95 looks and behaves like a straightforward TV streaming device. It has to; if it failed to do what it’s sold to do, few people would use them and the scheme would fall flat quickly.

T95 user interface

Other off-brand, BADBOX-infected devices purchased by
HUMAN’s Satori Threat Intelligence and Research Team 

These are off-brand devices, meaning any entity can place an order for these and add their own firmware before selling them via whatever resellers, distributors, or retailers they have access to.

T95 OS information

Having a T95 box in hand made it possible for Satori researchers to begin reverse-engineering the communications going to and from the device. 

corejava and libandroid

Much has been written already about corejava, an Android directory at the heart of the backdoor underpinning the BADBOX operation. In the interest of brevity, we’ll recap briefly how the backdoor worked and encourage researchers interested in a deeper dive to review the reports published by the security researchers who’ve explored T95 device infections in the recent past. These reports are linked above in the section labeled “Acknowledgements”.

In order to determine how the corejava directory was created and populated, the Satori team examined artifacts left in the device’s memory and found libandroid_runtime.so. This library—a core component of Android OS programming—is loaded into virtually every process on an uninfected Android device. In the case of BADBOX, libandroid_runtime.so was modified to contain additional, malicious functionality:

Iibandroid_runtime.so functions and instructions

com.jar

When the Satori team decrypted functions within the libandroid_runtime.so library mentioned above, they found this:

Output of a script which decrypts Cutecode strings

Note the com.jar APK referenced in the code snippet. That’s the library that, when further decrypted (as seen below), contacts a command-and-control server:

Decrypted contents showing the com.jar library

The T95 device examined by the Satori team, upon booting up, immediately injected the com.jar library into process memory and connected with a C2 server (one of several) for additional instructions.

Decrypted contents of the two initial request to cbphe[.]com

Those initial instructions included a ZIP file which, when unzipped and decrypted, includes two more files of concern: classes.png and config.make. 

Directory structure of /data/system/Corejava

classes.png, the filename of which suggests an image file, is actually an encrypted file that, when decrypted, turns into classes.dex. (If classes.dex is deleted from memory, it’s immediately restored, underscoring the persistence of the threat.)

syscall monitoring of servicemanager

config.make is another encrypted file that, when decrypted with an XOR key, is a list of launcher processes that correspond to some BADBOX-infectable device models, suggesting a list of device models for which the malware is compatible. Note com.swe.dgbluancher, which corresponds to the T95 device under examination by Satori:

Decrypted contents of config.make

 

The classes.dex file created by the decryption of classes.png is injected into the above launcher process, which kicks off the second stage of the injection by loading a collection of packages that facilitate much of the fraudulent activity that follows:

• a.a.a.a – Tracks IP Geolocation and updates proxy server settings accordingly

• com.jar – Main entry point, responsible for connecting with cbphe[.]com

• co.fm.ub 

• com.ohmy – Creates WebView to load ads and perform automatic clicks.

• com.asshow.asshow – Main package responsible for connecting and coordinating with flyermobi[.]com, found in other applications

• com.debby – Connects with proxy server via socket. Receives a new address from the proxy and uploads device information to it

• com.liberty.lib – sideloads dex or jar files obtained from peonyfast[.]com

• com.unia.y – Connects with pro[.]qazwsxedc[.]xyz/proxy in order to receive new addresses to communicate via socket and tasks to be redirected to these connections.

Filling the Horses

All of the subsequent communications to the C2 go to a second C2 server from the one that the backdoor contacts at bootup. The new server coordinates the fraudulent activities and periodically updates the malware version on the device.

Request to cbpheback[.]com

Here’s what the entire startup process looks like, preparing a BADBOX-infected device for fraudulent activity. Recall that these products come pre-installed with the backdoor, and this process occurs on first boot:

High level diagram of the startup process

Approaching the Gates

The Satori team found evidence of at least 200 distinct Android device types—mobile phones, tablets, and CTV products—that have shown signs of BADBOX infection as of the time of publishing. It’s impossible to estimate how many individual devices may be infected, as many device types were unavailable for testing by the Satori team, and as devices need to connect to the C2 servers and begin passing fraudulent traffic before they can be detected by the Human Defense Platform.

BADBOX-infected products have made their way into numerous unsuspecting hands. Many of these devices were—and are—available at resellers, physical retail stores and ecommerce warehouses. Satori is actively working with certain stores and ecommerce sites to attempt to take BADBOX-infected models off the market and slow or stop the spread of BADBOX.

In the course of this investigation, the Satori team found evidence indicating some smartphones manufactured for the US government’s Lifeline program (designed to help lower-income Americans acquire mobile phones) and participated in PEACHPIT, the ad fraud component of BADBOX. 

The Warriors

In our Trojan Horse metaphor, the horse has been built and wheeled inside the gates of the city, and now all that remains is for the warriors inside to spill out and wreak havoc. The Satori team witnessed BADBOX-infected devices committing several varieties of cybercrime, including:

• ad fraud (both through apps developed and owned by the fraudsters, and through hidden WebViews independent of any apps)
• residential proxy services (using backdoored devices as the exit points)
• fake email and messaging accounts
• remote un-permissioned code installation

We’ll explore each of these in turn, starting with the ad fraud “modules”.

Advertising Fraud: PEACHPIT

PEACHPIT is the code name given to the advertising fraud modules uncovered by Satori team researchers. In the simplest possible terms, PEACHPIT is an operation carrying out hidden advertisements, spoofed web traffic, and malvertising, both on/through iOS and Android apps published to major app marketplaces and on apps automatically downloaded to backdoored BADBOX devices. The marketplace-based apps do not require the BADBOX backdoor to be present on a device to successfully carry out fraud.

PEACHPIT app publishers staged apps on Google’s Play Store, Apple’s App Store, and on one CTV provider’s channel store. The Satori team found 20 Android apps, 16 iOS apps, and 3 CTV channels connected directly to PEACHPIT. The mechanism of fraud differs between them—for instance, Satori researchers found no evidence of iOS devices that had been backdoored. 

PEACHPIT impacted 121,000 Android devices at the operation’s peak, some of which may also have been backdoored by BADBOX. PEACHPIT also impacted a peak of 159,000 iOS devices, strictly through download of the apps associated with the scheme. HUMAN observed PEACHPIT-associated traffic from 227 countries and territories. HUMAN customers have been protected from the impacts of PEACHPIT—both the marketplace-based apps and the automatically-downloaded apps—since its discovery.

The Satori team’s evidence suggests the PEACHPIT threat actors are distinct from the BADBOX threat actors, yet likely working together in some way. Satori has identified several specific app publishers believed to be behind the PEACHPIT scheme, and while this report will not identify them in the interest of continued research, their information has been passed along to law enforcement.

PEACHPIT: Marketplace-Based Apps

PEACHPIT apps vary slightly in their fraud mechanisms. We’ll begin with one specific app—sixpack.sixpackabs.absworkout.abexercises.tv—to examine how the fraud takes place and how it appears to an unsuspecting user. This app is roughly representative of Android PEACHPIT apps.

The SixPack application declares Google’s AdMob as its only advertising SDK, but it’s not actually used in the operation of the app. That AdMob SDK, however, gives the SixPack application a library that manages the way ads are rendered on the device:

Imported library managing ad rendering

The app hardcodes a fake supply-side platform (SSP)—ads.go-workout com—for all ad calls. Notice “/sspbidder” in the URL in the screenshot below.

Hard-coded SSP

AdXLoader, another SDK, gathers information on the device’s location and user-agent (an identifier that’s a combination of browser version, OS version, and device version) to report back to the fake SSP:

Information on device collected

AdXLoader runs checks on information collected from the device, including IP address and Autonomous System Number (ASN, an internet traffic routing tool). If the checks on this information suggest the device belongs to any one of four major cloud service providers’ data centers, ads won’t render. This is presumably a mechanism intended to help prevent detection of PEACHPIT.

Cloud provider check

The location of the traffic also impacts whether ads render. In one example, changing the traffic from US-based to Bulgaria-based made a difference:

Comparison of output from ipinfo[.]io

Note also the “org” field in the lower screenshot. The information in that field doesn’t correspond with one of the four major cloud service providers the threat actors actively prohibit from ad rendering.

When the Satori team represented web traffic as coming from a CTV device based in Brazil, PEACHPIT rendered a full advertisement:

Ad traffic response from Brazil-based request

It’s unclear as of this writing how many countries are targeted (or detargeted) by the PEACHPIT threat actors.

The PEACHPIT app communicates with the hard-coded SSP following the IP, ASN, and location checks mentioned above. Notice the use of /sspbidder in the screenshot below, taken from a different PEACHPIT app, app.cobo.launcher. 

Calls to the sspbidder, part of the flyermobi C2 infrastructure

That sspbidder connection is common among PEACHPIT apps on all platforms, including those automatically downloaded as a result of the BADBOX backdoor (more on those in the following section). 

In the case of iOS devices, which are not impacted by the BADBOX backdoor, the PEACHPIT module more closely resembles the Satori team’s earlier investigation into VASTFLUX.

Below, references to sspbidder and the IP/ASN check appear in an iOS-based PEACHPIT app:

sspbidder and an ipinfo[.]io check in an iOS-based PEACHPIT app

As part of the investigation, the Satori team observed the PEACHPIT threat actors targeting iOS devices through a malvertising attack:

JavaScript payload returned following an ad call in one PEACHPIT-associated iOS app

Above, an ad call to an /sspbidder server returns an ad including a piece of JavaScript, allowing the ad slot to open a new WebView and rendering ads inside it.

At its peak, HUMAN saw roughly 121,000 Android devices impacted by PEACHPIT, some of which may have also included the BADBOX backdoor. HUMAN also saw 159,000 iOS devices impacted by PEACHPIT. The traffic from these devices originated from 227 different countries and territories, underscoring the global scale of the threat.

PEACHPIT: Automatically Downloaded Apps 

To explore the PEACHPIT apps automatically downloaded as a result of the BADBOX backdoor, we return to the classes.dex file mentioned during the initial infection. One of the modules loaded into the library by classes.dex is com.asshow.asshow. This module is the key to the entire scheme.

Encrypted contents of com.asshow.asshow.b.d

The above shows the encrypted contents of the module. Satori researchers decrypted the strings within the code and observed that its first order of business is to connect to flyermobi, the ad fraud C2 mentioned above as part of PEACHPIT and as a major pivot point for all BADBOX research.

Next, the threat actors put multiple delays and time-based checks to prevent immediate trigger of the malicious behavior and to make it more difficult to be dynamically detected.

Task from com.asshow.asshow.b.b with a 5 second delay and 600 second rerun rate.

10 hour delay from com.asshow.asshow.b.a

Following these delays, the asshow module reconnects to flyermobi and retrieves b.jar, an encrypted binary which is loaded into memory. manifest.mf references the .jar file as being associated with a package, com.mozgame.atask.task.ltask.

manifest.mf from b.jar

That’s not, however, what appears in the WebViews the scheme will shortly begin generating. In those WebViews, the package reported is one received as an instruction from flyermobi. (Notice, too, /sspbidder in the URL.)

WebView details

The com.mozgame.atask.task.ltask package gets a response from the C2 that instructs it how to stage a hidden WebView, including the URL to load in the page.

Runnable class com.mozgame.atask.I that will reach out to http[:]//adc.flyermobi[.]com/config/config.conf and parse out its contents to ASConfig

Network capture showing the contents of a server response for the above request

These ad requests took place when the rendered ad had no chance of being seen, such as when the screen was off:

Successful Ad impression while screen was off

Above and beyond loading the WebView with the hardcoded URL, PEACHPIT also includes a click fraud element within those same WebViews:

Autoclick function

Residential Proxy Nodes

Residential proxies route web traffic from one IP address to another, making the traffic appear as though it’s coming from another place entirely. The Satori team observed residential proxy activity on BADBOX-infected devices early on in the investigation, and found evidence that they connect to one another, forming a residential proxy network.

How it Works: a BADBOX-infected device opens a port that connects to one of three C2 servers and sends some basic device information. The C2 responds with two IP:PORT addresses, one that continuously feeds device information back to the C2, and another, a “proxy” address, to receive yet a third IP:PORT address.

From com.debby.i.b

Two more connections are established, one with the proxy address, and one with the third address.

From com.debby.o

The BADBOX-infected device now sits between two other addresses, serving as a proxy for each.

Method from com.debby.o that reads and sends data between the sockets

If any of the connections time out, the C2 server fires off a request to a server that responds with a 404 error and closes the proxy connection.

404 error after timeout

Satori researchers captured several requests suggesting this proxy service was actively in use:

Network traffic from the mentioned C2 servers referring instagram[.]com, jd-sports[.]com[.]au and nike[.]com respectively 

The threat actors behind BADBOX made this residential proxy service commercially available to interested customers:

Screenshots of residential proxy service based on BADBOX backdoor

With the C2s powering the initial BADBOX infection down, new nodes of the residential proxy service aren’t presently being added. But existing nodes of the service remain active.

One-Time Passwords – OTP Theft and Fake Accounts

OTPs are a common login or account creation mechanism for many high-profile platforms. The level at which BADBOX infects devices, however, allows the threat actors to intercept text messages before they reach the user.

While the Satori team isn’t certain of the specific purpose or intent of the OTP theft module of BADBOX, there are several possible explanations:

• undermining multi-factor authentication (MFA) for device owners by intercepting confirmation codes, thus facilitating account takeover
• preventing users from receiving notifications of account compromise
• enabling new/fake account creation across a host of platforms that require double opt-in/MFA

Satori researchers found that BADBOX-infected devices were capable of creating Gmail and WhatsApp accounts in the background. The reason for this particular attack is also unclear, but the module could serve any of the following purposes:

• creating a secondary-revenue stream—after the highly-profitable ad fraud scheme (described below) and the above residential proxy services—selling these accounts to other threat actors
• preparing for future astroturfing campaigns for reviews of apps developed by the threat actors, or as working email addresses for staging the apps themselves on major marketplaces
• aiding in the interception of OTPs, as some OTPs are sent via email rather than via text message

Remote Un-permissioned Code Installation

Finally, after its initial C2 connection, BADBOX-backdoored smartphones, tablets, and CTV boxes begin contacting a second C2, the purpose of which is to—without permission from the user—update software and remotely install new software or code onto the device. This connection, as noted above, periodically updates the malware on the device to ensure each device remains part of the botnet. This second C2 shares an ASN with the primary C2 delivering the fraud modules through the backdoor.

BADBOX Today

As of this writing, PEACHPIT has been disrupted, while the other components of BADBOX are dormant. Many—possibly all—of the C2s associated with the BADBOX campaign have been taken down by the threat actors. This should not be construed as “over”, though; the Satori team believes the threat actors behind BADBOX are simply reconfiguring their schemes to try to find a new way forward.

HUMAN customers have been protected from the impacts of PEACHPIT since its discovery. HUMAN’s work to protect the programmatic advertising ecosystem dramatically reduced the influence of PEACHPIT on the digital advertising supply chain, and that interruption has not gone unnoticed by the threat actors.

During the investigation, one manufacturer of BADBOX-infected devices offered over-the-air (OTA) updates to their devices for any app developer. When one of our researchers posed as an app developer and contacted the manufacturer for more information on this capability, the researcher was assured any APK could be remotely installed on the manufacturer’s devices, even without the user’s consent.

Earlier this year, the Satori team observed an update to BADBOX-infected devices.

Updated classes.dex library

After HUMAN’s early mitigation measures curtailed PEACHPIT’s effectiveness, the modules powering PEACHPIT (on BADBOX-infected devices) and other fraud were removed from the library.

The possibility of remote relaunch of BADBOX means that even with the C2s taken down and fraud modules removed, BADBOX-infected devices remain a threat. Satori researchers will continue to monitor the threat actors behind both BADBOX and PEACHPIT with the aim of shutting down the operation for good.

To that end, the Satori team uncovered considerable detail about the hardware supply chain that created, infected, and distributed BADBOX-associated devices worldwide, and about the Chinese app developers—and their American shell company counterparts—behind PEACHPIT. All of this information has been shared with law enforcement, as will any additional details uncovered in subsequent research.

Members of the Human Collective, an information- and resource-sharing organization founded in 2021, received early debriefs about BADBOX and PEACHPIT, as did select partners. These organizations are fully apprised of the threat BADBOX and PEACHPIT pose and have committed to sharing any new insights with the Satori team for further investigation.

Conclusions

While the disruption of BADBOX is a victory for the cybersecurity community, research must continue into the supply chain that allowed the threat to develop in the first place. For every fraud scheme broken up by HUMAN and others, there are more threat actors ready to fill the vacuum.

That’s what makes disrupting the economics of cybercrime so important. Raise the cost to attackers and lower the cost to defenders; shorten the window of opportunity for any given threat actor and make it less profitable. 

HUMAN is uniquely positioned to aid in that transformation with a modern defense strategy: 

• the unmatched visibility HUMAN has into internet interactions—more than 30 trillion verified each week across billions of unique devices—affords the Satori team more information from which to find new and emerging threats
• a network effect of our partners in the Human Collective and more than 500 HUMAN customers, creating a collective protection in which an attack on one becomes a defense for all
• disruptions and takedowns of attacks like BADBOX, built on decades of collective experience in fighting cybercrime

Users, too, can help with the continued fight against schemes like BADBOX in the future:

• if possible try to avoid off-brand devices like the smartphones, tablets, and CTV boxes described above as these devices were not Play Protect-certified Android devices; users can check if their device is Play Protect-certified
• be wary of copycat or clone apps, and ensure you understand the origin of any app you download
• be vigilant; if a device is behaving oddly (for example, showing ads when one wouldn’t be expected), consider restoring to factory settings to remove any compromised apps

As noted above, BADBOX-infected devices cannot be “fixed” by the average user, and given the threat of OTA updates from the manufacturer relaunching the operation, these devices should be retired to sever their connections to the C2s powering the operation.

Satori researchers will continue to monitor the manufacturers of BADBOX-infected devices, the threat actors deploying the backdoor, and the developers of the PEACHPIT apps for signs of adaptation.

Indicators of Compromise

C2 Servers

List of PEACHPIT Applications