Thursday, March 6, 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

Implementing Identity First Security for Zero Trust Architectures

Zero Trust is a security framework that operates under the assumption that no implicit...

InvokeADCheck – New Powershell Module for Active Directory Assessment

Orange Cyberdefense has announced the development of InvokeADCheck, a new PowerShell module designed to...

Detecting Malicious Activities With Traffic Distribution Systems

Traffic Distribution Systems (TDS) have emerged as critical tools for both legitimate and malicious...

Hackers Deploy Advanced Social Engineering Tactics in Phishing Attacks

Cybercriminals are evolving their phishing methods, employing more sophisticated social engineering tactics to deceive...

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

BadBox Malware Infects 50,000+ Android Devices via 24 Apps on Google Play

HUMAN's Satori Threat Intelligence and Research team has uncovered a complex cyberattack dubbed "BADBOX...

Hackers Exploit ‘Any/Any’ Communication Configurations in Cloud Services to Host Malware

Recent research by Veriti has uncovered a disturbing trend in cybersecurity: malicious actors are...

PrintSteal Cybercrime Group Mass-Producing Fake Aadhaar & PAN Cards

A large-scale cybercrime operation dubbed "PrintSteal" has been exposed, revealing a complex network involved...