Xhelper has hit the headlines for a number of reasons
First, is the scope of the threat—it is claimed to be installed on 45,000 Android devices. Second, is its doggedly persistent nature—there are reports that Xhelper can survive a factory reset, automatically re-install itself after a factory reset, and will reinstall itself if it is removed manually.
It doesn't currently seem to have a worrying payload (it shows adverts; irritating, and "noisy", but there are worse things) but we should remain cautious about its potential future impact; payloads are supplied across an encrypted link from the command and control (C&C) servers, so could literally change to more malicious code overnight. Companies with Data Loss Prevention or anti-virus intercepting proxies will find this encrypted, malicious traffic especially difficult to examine, due to the certificate pinning discussed later.
Before we get into the details, here’s what I find puzzling: nobody seems ready to place an attribution on this. That is odd, given that normally advertisements have a tracking ID to ensure that the distributor gets paid for their efforts—doubly so given we first saw anti-virus vendors reporting this malware way back in March. After eight months, we apparently still know nothing about its origin or purpose. It has also been suggested that the activity we CAN see is a false flag operation that acts as cover for a much more tightly tailored campaign.
So what DO we know for sure?
A Symantec post outlines a typical installation of Xhelper, and details how it operates. Basically, it doesn't install as a launchable application, but as a service which auto-launches on certain common events (such as starting the phone, attaching or detaching a power cord, and so forth) and then registers as a service which interacts with the user (both in order to send notifications which are the "advertising", and to reduce the odds of being removed when memory is low.) As is common for malware, it also has the ability to restart itself if stopped.
Symantec also note that the main process is effectively a "bot"—it connects to a command-and-control server and is instructed to show its advertisements from there. This link uses a pinned certificate—a hardcoded recognition of the “machine identity” of the remote C&C server, which prevents researchers or corporate proxies from substituting their own. This would be particularly worrying if the payload changed to one which steals credentials (for example) as it would protect the exfiltration channel. Symantec also comment on the assertion made by many that the software can survive even a factory reset—that would seem to indicate that the "dropper" (installer) is integrated into the system itself. But Symantec assert there is no evidence the system image itself is compromised, suggesting instead that the reader follow their blog for possible future updates.
Malwarebytes were an early source of info on this Trojan. Back in August, they provided detail that Symantec didn’t cover—namely that the malware is "stealing" an assembly name from another (low interest, but legitimate) app store game. Indeed, the ads currently displayed lead to a browser-based game site which appears harmless. (They also point out that pay-for-click should be traceable; however, they don't appear to follow up on that.) Instead, Malwarebytes dive deeply into the installation method used by the "dropper." This drops an encrypted bytecode file which is then decrypted and pushed into a tool called "dex2oat" to install it as though it was the more common APK file type. This is an example of the all-too-common, but nonetheless nefarious use of machine identities for malicious purposes.
Symantec assert in their piece their belief that there is a "vast and varied pool" of malware on the C&C server but offer no further info on this. (This is, of course, consistent with the theory that a more focused campaign may use this same malware). They also claim to have found references to the Indian network "Jio" but this may be more a reason to mention that Jio users have free access to "Norton Mobile Security" which blocks the current version of Xhelper. There may also be some clue in that usage though—Jio is derived from a common Hindi word/saying, so it may indicate an Indian origin for the programmers?
Another point Symantec make is that a properly configured SELinux (and by extension, Android) image has a "secure boot" sequence; this ensures "bootleg" boot images cannot be installed by checking a digital signature for each one (and there is no suggestion that the attackers here have compromised the signing keys). This would be something simple for researchers to check, which makes it another thing that is odd—no vendor has explicitly stated that they have tested and eliminated this in the eight months this malware has been studied.
Malwarebytes present the interesting info that the C&C servers for Xhelper are based in the USA—giving examples of New York and Dallas. They speculate from this that the intended targets are within the USA. (But when you compare this with the Indian assertion above by Symantec; it seems unlikely to be both.)
Within the comments for the Malwarebytes piece is one of particular interest. The poster asserts that they were able to halt reinfection by removing the system browser app; this would seem to indicate that, at least on their system, this was the “dropper”. Assuming this is true, this would indicate a supply chain compromise. (Other sources, such as reddit, also suggest that factory-reset systems are clean until they perform an online update). It is observed that quite a few popular brands (such as Samsung) don’t seem to be seeing infections, while a number of low-end brands are.
Open Source Libraries are especially vulnerable to supply chain attacks. Find out out more in this video by Venafi's Jing Xie.