Android Trojan xHelper uses persistent re-infection tactics: here’s how to remove

Posted: February 12, 2020 by Nathan Collier
Last updated: February 13, 2020


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.
All the fails

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.
Clean slate

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.
The usual suspect: pre-installed malware

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
Triggered: Google PLAY

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!

Photos provided by Amelia
The culprit

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.
How to remove xHelper re-infections

If you are experiencing re-infections of xHelper, here’s how to remove it:
We strongly recommend installing Malwarebytes for Android (free).
Install a file manager from Google PLAY that has the capability to search files and directories.
Amelia used File Manager by ASTRO.
Disable Google PLAY temporarily to stop re-infection.
Go to Settings > Apps > Google Play Store
Press Disable button
Run a scan in Malwarebytes for Android to remove xHelper and other malware.
Manually uninstalling can be difficult, but the names to look for in Apps info are fireway, xhelper, and Settings (only if two settings apps are displayed).
Open the file manager and search for anything in storage starting with com.mufc.
If found, make a note of the last modified date.
Pro tip: Sort by date in file manager
In File Manager by ASTRO, you can sort by date under View Settings
Delete anything starting with com.mufc. and anything with same date (except core directories like Download):

Re-enable Google PLAY
Go to Settings > Apps > Google Play Store
Press Enable button
If the infection still persists, reach out to us via Malwarebytes Support.
Mobile malware hits a new level

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!

Πώς να κάνετε δωρεάν αναβάθμιση στα win10!! video

Αν δεν ξέρετε πώς να κάνετε δωρεάν αναβάθμιση στα 10, ή γνωρίζετε κάποιον που χρειάζεται βοήθεια, δείτε αναλυτικά τη διαδικασία video

Posted by DASOS security info on Thursday, February 13, 2020

Critical Android Bluetooth Flaw Exploitable without User Interaction

By
Ionut Ilascu February 6, 2020 07:44 PM 3






Android users are urged to apply the latest security patches released for the operating system on Monday that address a critical vulnerability in the Bluetooth subsystem.

An attacker could leverage the security flaw, now identified as CVE-2020-0022 without user participation to run arbitrary code on the device with the elevated privileges of the Bluetooth daemon when the wireless module is active.
Short-distance worm

Discovered and reported by Jan Ruge at the Technische Universität Darmstadt, Secure Mobile Networking Lab, the bug is considered critical on Android Oreo (8.0 and 8.1) and Pie (9) because exploiting it leads to code execution.

According to Ruge, attackers could use this security fault to spread malware from one vulnerable device to another, like a worm. However, the transmission is limited to the short distance covered by Bluetooth.

The Android security bulletin notes that CVE-2020-0022 "could enable a remote attacker using a specially crafted transmission to execute arbitrary code within the context of a privileged process."

The only prerequisite for taking advantage of the issue is knowing the Bluetooth MAC address. This is not difficult to find, though.

"For some devices, the Bluetooth MAC address can be deduced from the WiFi MAC address," says the researcher on the the blog site of German IT security consultant ERNW.

On Android 10, the severity rating drops to moderate since it all it does is crash the Bluetooth daemon, the researcher says. Android versions earlier than 8.0 may also be affected but the impact on them has not been assessed.
Technical details, PoC to be published

The severity of the issue is what keeps the researcher from disclosing technical details and proof of concept (PoC) code demonstrating the findings.

Despite a patch being available, OEM vendors and mobile carriers also have to push it to user terminals. For devices still under support, it can take weeks until the update rolls out.

If a patch does not become available, Ruge recommends enabling Bluetooth only "if strictly necessary." If you need to activate it, consider keeping the device non-discoverable, a feature that hides it from other gadgets looking for a pair.

Ruge says that a technical report will be available for this vulnerability "as soon as we are confident that patches have reached the end users."

Νέο κύμα του Emotet Malware χακάρει δίκτυα Wi-Fi!

10 Φεβρουαρίου, 2020, 5:36 μμ by Teo Ehc Leave a Comment


Ένα νέο κύμα του malware Emotet με το νέο Wi-Fi Spreader εκμεταλλεύεται το interface wlanAPI για να απαριθμήσει όλα τα δίκτυα Wi-Fi στην περιοχή και να εξαπλωθεί η μόλυνση.

Το Emotet είναι ένα Trojan banking που εντοπίστηκε το 2014 και σχεδιάστηκε για να κλέβει ευαίσθητες και ιδιωτικές πληροφορίες.

Είναι ένα από τα πιο επικίνδυνα malware και είναι σε θέση να αποδώσει payloads βασισμένα σε συγκεκριμένα tasks.

Το Emotet διανέμεται κυρίως μέσω τεχνικών social engineering όπως τα emails με links για να κατέβει το malware.

Με τη νέα καμπάνια Emotet καταφθάνει ένα νέο Wi-Fi Spreader module που μεταφορτώνεται στο σύστημα C:\ProgramData. Το ληφθέν δυαδικό αρχείο περιέχει ένα RAR αυτόματης εξαγωγής που διαθέτει δυο δυαδικά αρχεία (service.exe και worm.exe) για τη διάδοση του μέσω Wi-Fi.



Το worm.exe είναι το εκτελέσιμο αρχείο που χρησιμοποιείται για την εξάπλωση του malware, αφού εκτελείται, αντιγράφει το service.exe σε μια μεταβλητή για τη χρήση του κατά τη διάδοση.

Στη συνέχεια καλεί την κλάση wlanAPI.dll που χρησιμοποιείται από το Native Wi-Fi για τη διαχείριση των προφίλ και των συνδέσεων ασύρματου δικτύου για τη διάδοση του malware σε άλλα δίκτυα.



“Το Worm απαριθμεί όλες τις συσκευές Wi-Fi που είναι επί του παρόντος ενεργοποιημένες στον τοπικό υπολογιστή, το οποίο επιστρέφει σε μια σειρά δομών. Αυτές οι δομές περιέχουν όλες τις πληροφορίες που σχετίζονται με τη συσκευή Wi-Fi, συμπεριλαμβανομένου του GUID και της περιγραφής της συσκευής”, διαβάζουμε στην ανάλυση του worm.


Συγκεντρώνει πιθανές πληροφορίες από όλα τα διαθέσιμα δίκτυα Wi-Fi που υπάρχουν στη λίστα των δικτύων.



Σπάζοντας το αδύναμο δίκτυο Wi-Fi

Μόλις συνδεθεί με το δίκτυο Wi-Fi, απαριθμεί τους χρήστες και επιχειρεί brute-force για όλους τους χρήστες του δικτύου.

Στη συνέχεια, το Service.exe είναι το payload που έχει εγκατασταθεί από το worm.exe στο μηχάνημα, μόλις εγκατασταθεί επικοινωνεί με το server C2 και εκτελεί το δυαδικό ενσωματωμένο στο service.exe.

Προηγουμένως, το Emotet, ο οποίος γνωρίζει ότι διανέμεται μόνο μέσω δικτύων malspam και μολυσμένων δικτύων, με αυτόν τον νέο loader εξαπλώνεται μέσω κοντινών ασύρματων δικτύων που χρησιμοποιούν αδύναμους κωδικούς πρόσβασης.

Phishing Attack Disables Google Play Protect, Drops Anubis Trojan

By
Sergiu Gatl an February 6, 2020 02:36 PM 1





Android users are targeted in a phishing campaign that will infect their devices with the Anubis banking Trojan that can steal financial information from more than 250 banking and shopping applications.

The campaign uses a devious method to get the potential victims to install the malware on their devices: it asks them to enable Google Play Protect while actually disabling it after being granted permissions on the device.

To deliver the malware, the attackers use a malicious link embedded within the phishing email that will download an APK file camouflaged as an invoice as Cofense found.

After being asked if he wants to use Google Play Protect and installing the downloaded APK, the victim's device will be infected with the Anubis Trojan.
Google Play Protect used as cover (Cofense)
Targets over 250 financial applications

Cofense discovered that, once the Android smartphone or tablet is compromised, Anubis will start harvesting "a list of installed applications to compare the results against a list of targeted applications.

The malware mainly targets banking and financial applications, but also looks for popular shopping apps such as eBay or Amazon.

Once an application has been identified, Anubis overlays the original application with a fake login page to capture the user’s credentials."

After analyzing the malware's source code, Cofense found that the banking Trojan has a wide range of capabilities included but not limited to:


• capturing screenshots
• toggling off and altering administration settings
• disabling Google's Play Protect built-in malware protection for Android
• recording audio
• making calls and sending SMS
• stealing the contact list
• stealing the contacts from the addressbook
• receiving commands from its operators via Telegram and Twitter
• controlling the device over a VNC
• opening URLs
• locking device screen
• and collecting device and location information

The malware also comes with a keylogger module that can capture keystrokes from every app installed on the compromised Android device.

However, this keylogging module has to be specifically enabled by the attackers via a command sent through Anubis' command and control (C2) server.
Also comes with a ransomware module

On top of all of these, Anubis is also capable of encrypting files on the internal storage and from external drives using the RC4 stream cipher with the help of a dedicated ransomware module, adding the .AnubisCrypt extension to the encrypted files and sending it to the C2 server.

Anubis Trojan samples with ransomware capabilities are not new, as Sophos previously discovered Anubis-infected apps in the Play Store in August 2018 that also added the .AnubisCrypt file extension to the encrypted files.

"Remember, this runs on a phone, which is even less likely to be backed up than a laptop or desktop, and more likely to have personal photos or other valuable data," Sophos said at the time.
AnubisCrypt encrypted files

According to the Cofense report, "this version of Anubis is built to run on several iterations of the Android operating system, dating back to version 4.0.3, which was released in 2012."

Trend Micro's researchers also found in January 2019 that the Anubis Trojan was used in a campaign that targeted 377 bank apps from 93 countries all over the globe, with banks like Santander, Citibank, RBS, and Natwest, as well as shopping apps such as Amazon, eBay, and PayPal being listed as targets.

An extensive list of indicators of compromised (IOCs) including hashes of the malicious APK installer used in the campaign, associated URLs, and all application IDs for the apps targeted by this Anubis sample is available at the end of Cofense's report.