We first stumbled upon the nasty Android Trojan xHelper, a stealthy malware dropper, in May 2019. By mid-summer 2019, xHelper was topping our detection charts—so we wrote an article about it. After the blog, we thought the case was closed on xHelper. Then a tech savvy user reached out to us in early January 2020 on the Malwarebytes support forum:
“I have a phone that is infected with the xhelper virus. This tenacious pain just keeps coming back.”
_“I'm fairly technically inclined so I'm comfortable with common prompt or anything else I may need to do to make this thing go away so the phone is actually usable!” _
— _forum user misspaperwait, _Amelia
Indeed, she was infected with xHelper. Furthermore, Malwarebytes for Android had already successfully removed two variants of xHelper and a Trojan agent from her mobile device. The problem was, it kept coming back within an hour of removal. xHelper was re-infecting over and over again.
Photo provided by Amelia
If it wasn’t for the expertise and persistence of forum patron Amelia, we couldn’t have figured this out. She has graciously has allowed us to share her journey.
Before we share the culprit behind this xHelper re-infection, I'd like to highlight the tactics we used to investigate the situation, including the many dead ends we hit prior to figuring out the end game. By showing the roadblocks we encountered, we demonstrate the thought process and complexity behind removing malware so that others may use it as a guide.
First off, Amelia was clever enough to do a factory reset before reaching out to us. Unfortunately, it didn’t resolve the issue, though it did give us a clean slate to work with. No other apps (besides those that came with the phones) were installed besides Malwarebytes for Android, thus, we could rule out an infection by prior installs (or so we thought).
We also ruled out any of the malware having device admin rights, which would have prevented our ability to uninstall malicious apps. In addition, we cleared all history and cache on Amelia's browsers, in case of a browser-based threat, such as a drive-by download, causing the re-infection.
Since we had a clean mobile device and it was still getting re-infected, our first assumption was that pre-installed malware was the issue. This assumption was fueled by the fact that the mobile device was from a lesser-known manufacturer, which is often the case with pre-installed malware. So Amelia tested this theory by going through the steps to run Android Debug Bridge (adb) commands to her mobile device.
With adb command line installed and the mobile device plugged into a PC, we used the workaround of uninstalling system apps for _current user. _This method renders system apps useless even though they still technically reside on the device.
Starting with the most obvious to the least, we systematically uninstalled suspicious system apps, including the mobile device’s system updater and an audio app with hits on VirusTotal, a potential indicator of maliciousness. Amelia was even able to grab various apps we didn’t have in our Mobile Intelligence System to rule everything out. After all this, xHelper’s persistence would not end.
Photo provided by Amelia of xHelper running on mobile device
We then noticed something strange: The source of installation for the malware stated it was coming from Google PLAY. This was unusual because none of the malicious apps downloading on Amelia's phone were on Google PLAY. Since we were running out of ideas, we disabled Google PLAY. As a result, the re-infections stopped!
We have seen important pre-installed system apps infected with malware in the past. But Google PLAY itself!? After further analysis, we determined that, no, Google PLAY was not infected with malware. However, something within Google PLAY was triggering the re-infection—perhaps something that was sitting in storage. Furthermore, that something could also be using Google PLAY as a smokescreen, falsifying it as the source of malware installation when in reality, it was coming from someplace else.
In the hopes that our theory held true, we asked Amelia to look for suspicious files and/or directories on her mobile device using a searchable file explorer, namely, anything that started with _com.mufc., _the malicious package names of xHelper. And then…eureka!
Hidden within a directory named _com.mufc.umbtts _was yet another Android application package (APK). The APK in question was a Trojan dropper we promptly named Android/Trojan.Dropper.xHelper.VRW. It is responsible for dropping one variant of xHelper, which subsequently drops more malware within seconds.
Here’s the confusing part: Nowhere on the device does it appear that Trojan.Dropper.xHelper.VRW is installed. It is our belief that it installed, ran, and uninstalled again within seconds to evade detection—all by something triggered from Google PLAY. The "how" behind this is still unknown.
It's important to realize that unlike apps, directories and files remain on the Android mobile device even after a factory reset. Therefore, until the directories and files are removed, the device will keep getting infected.
If you are experiencing re-infections of xHelper, here’s how to remove it:
This is by far the nastiest infection I have encountered as a mobile malware researcher. Usually a factory reset, which is the last option, resolves even the worst infection. I cannot recall a time that an infection persisted after a factory reset unless the device came with pre-installed malware. This fact inadvertently sent me down the wrong path. Luckily, I had Amelia's help, who was as persistent as xHelper itself in finding an answer and guiding us to our conclusion.
This, however, marks a new era in mobile malware. The ability to re-infect using a hidden directory containing an APK that can evade detection is both scary and frustrating. We will continue analyzing this malware behind the scenes. In the meantime, we hope this at least ends the chapter of this particular variant of xHelper.
Stay safe out there!
The post Android Trojan xHelper uses persistent re-infection tactics: here's how to remove appeared first on Malwarebytes Labs.