{"id":17718,"date":"2020-02-12T11:10:13","date_gmt":"2020-02-12T19:10:13","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2020\/02\/12\/news-11453\/"},"modified":"2020-02-12T11:10:13","modified_gmt":"2020-02-12T19:10:13","slug":"news-11453","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2020\/02\/12\/news-11453\/","title":{"rendered":"Android Trojan xHelper uses persistent re-infection tactics: here’s how to remove"},"content":{"rendered":"

Credit to Author: Nathan Collier| Date: Wed, 12 Feb 2020 18:15:59 +0000<\/strong><\/p>\n

We first stumbled upon the nasty Android Trojan xHelper, a stealthy malware dropper<\/a>, in May 2019. By mid-summer 2019, xHelper was topping our detection charts\u2014so we wrote an article about it<\/a>. 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<\/a>:<\/p>\n

\u201cI have a phone that is infected with the xhelper virus. This tenacious pain just keeps coming back.\u201d<\/em><\/p>\n

\u201cI’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!\u201d <\/em><\/p>\n

\u2014 <\/em>forum user misspaperwait, <\/em>Amelia<\/p>\n

Indeed, she was infected with xHelper. Furthermore, Malwarebytes<\/a> for Android<\/a> 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.<\/p>\n

\n
\"\"
Photo provided by Amelia<\/figcaption><\/figure>\n<\/div>\n

If it wasn\u2019t for the expertise and persistence of forum patron Amelia, we couldn\u2019t have figured this out. She has graciously has allowed us to share her journey. <\/p>\n

All the fails<\/h2>\n

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. <\/p>\n

Clean slate<\/h4>\n

First off, Amelia was clever enough to do a factory reset before reaching out to us. Unfortunately, it didn\u2019t 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). <\/p>\n

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. <\/p>\n

The usual suspect: pre-installed malware<\/h4>\n

Since we had a clean mobile device and it was still getting re-infected, our first assumption was that pre-installed malware<\/a> was the issue. This assumption was fueled by the fact that the mobile device was from a lesser-known manufacturer<\/a>, which is often the case with pre-installed malware.  So Amelia tested this theory by going through the steps to run Android<\/a> Debug Bridge (adb) commands<\/a> to her mobile device.  <\/p>\n

With adb<\/em> command line installed and the mobile device plugged into a PC, we used the workaround of uninstalling system apps for current user. <\/em>This method renders system apps useless even though they still technically reside on the device.  <\/p>\n

Starting with the most obvious to the least, we systematically uninstalled suspicious system apps, including the mobile device\u2019s 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\u2019t have in our Mobile Intelligence System to rule everything out. After all this, xHelper\u2019s persistence would not end.<\/p>\n

\n
\"\"
Photo provided by Amelia of xHelper running on mobile device<\/figcaption><\/figure>\n<\/div>\n

Triggered: Google PLAY <\/h4>\n

We then noticed something strange: The source of installation for the malware stated it was coming from Google PLAY. This was unusual because none <\/strong>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!<\/p>\n

We have seen important pre-installed system apps infected with malware<\/a> in the past. But Google PLAY itself!? After further analysis, we determined that, no, Google PLAY was not<\/strong> infected with malware. However, something within Google PLAY was triggering the re-infection\u2014perhaps 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.<\/p>\n

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., <\/em>the malicious package names of xHelper. And then…eureka! <\/p>\n

\n