Friday, February 21, 2025
HomeAndroidAndroid XHelper Malware Reinstall Itself Again & Again After Removed it Using...

Android XHelper Malware Reinstall Itself Again & Again After Removed it Using Advanced Persistence Technique

Published on

SIEM as a Service

Follow Us on Google News

Researchers uncovered a stealthy Android malware called XHelper that has unseen reinstalling capability after the malware removed from the infected Android device.

Once removed the XHelper malware from the devices, within an hour, the variants of xHelper Trojan agent was re-infecting over and over again.

We have reported the same Android Trojan xHelper in last year October when it was reportedly infected 45k Android users with similar capabilities.

Initially, researchers suspect that the reinfection occurs due to the pre-installed malware, so they run  Android Debug Bridge (adb) commands to on the infected mobile device. 

But it doesn’t work and still the malware resided in the device even they have tested the other facts including the mobile device’s system updater, and an audio app with hits on VirusTotal, a potential indicator of maliciousness and applied various rules.

Discovering xHelper Reinstalling Medium

After a long duration of testing the Android device that infected by the xHelper over and over by admitting the various infection facts, finally, they spotted the infection medium was Google Play.

So once the Google play disabled, then the malware infection was stopped, and also they suspected that the Google Play wasn’t infected with the malware and something within Google Play was triggering the re-infection—perhaps something that was sitting in storage.

Hackers using Google Play as a Smokescreen, but in reality, the Xhelper was installed from some other place, and they have started searching for anything that started with com.mufc.

Finally spotted the place in local File explorer with a directory named com.mufc.umbtts was yet another Android application package (APK). 

According to Malwarebytes report, 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.

Since there is no sign of appearing that Trojan.Dropper.xHelper.VRW is installed, researchers believe that the malware has the persistent capability of evading the detection it installed, ran, and uninstalled again within seconds.

It strongly teaches that the directories and files remain on the Android mobile device even after a factory reset.

so there are high chances of the device will keep getting infected until the directories and files are removed.

Some users said that they suppressed Xhelper activity by turning off permissions and locking them using app lock software. Some users said that “tried denying permissions to xHelper without uninstalling, but it turned on all permissions again.”

Balaji
Balaji
BALAJI is an Ex-Security Researcher (Threat Research Labs) at Comodo Cybersecurity. Editor-in-Chief & Co-Founder - Cyber Security News & GBHackers On Security.

Latest articles

SPAWNCHIMERA Malware Exploits Ivanti Buffer Overflow Vulnerability by Applying a Critical Fix

In a recent development, the SPAWNCHIMERA malware family has been identified exploiting the buffer...

Sitevision Auto-Generated Password Vulnerability Lets Hackers Steal Signing Key

A significant vulnerability in Sitevision CMS, versions 10.3.1 and earlier, has been identified, allowing...

NSA Allegedly Hacked Northwestern Polytechnical University, China Claims

Chinese cybersecurity entities have accused the U.S. National Security Agency (NSA) of orchestrating a...

ACRStealer Malware Abuses Google Docs as C2 to Steal Login Credentials

The ACRStealer malware, an infostealer disguised as illegal software such as cracks and keygens,...

Supply Chain Attack Prevention

Free Webinar - Supply Chain Attack Prevention

Recent attacks like Polyfill[.]io show how compromised third-party components become backdoors for hackers. PCI DSS 4.0’s Requirement 6.4.3 mandates stricter browser script controls, while Requirement 12.8 focuses on securing third-party providers.

Join Vivekanand Gopalan (VP of Products – Indusface) and Phani Deepak Akella (VP of Marketing – Indusface) as they break down these compliance requirements and share strategies to protect your applications from supply chain attacks.

Discussion points

Meeting PCI DSS 4.0 mandates.
Blocking malicious components and unauthorized JavaScript execution.
PIdentifying attack surfaces from third-party dependencies.
Preventing man-in-the-browser attacks with proactive monitoring.

More like this

SPAWNCHIMERA Malware Exploits Ivanti Buffer Overflow Vulnerability by Applying a Critical Fix

In a recent development, the SPAWNCHIMERA malware family has been identified exploiting the buffer...

NSA Allegedly Hacked Northwestern Polytechnical University, China Claims

Chinese cybersecurity entities have accused the U.S. National Security Agency (NSA) of orchestrating a...

ACRStealer Malware Abuses Google Docs as C2 to Steal Login Credentials

The ACRStealer malware, an infostealer disguised as illegal software such as cracks and keygens,...