You Threw the Intruder Out. He Had Already Built Another Door: Inside RatHat’s Android Persistence
Imagine discovering an intruder inside your house.
You catch him.
You force him through the front door.
You lock it behind him.
For a moment, everything looks normal again.
Except the intruder had been busy before you found him.
While moving through the house, he discovered the maintenance controls. He unlocked a hidden entrance, created his own access route and connected it to a tunnel leading outside.
So when you throw him out through the door he originally entered, he does not actually lose access.
He simply comes back through the door he built himself.
That is the persistence model behind RatHat, a newly identified Android malware assessed by Zimperium as being operated by China-based threat actors.
And its architecture makes the analogy unusually literal.
The malicious application is only the original entrance.
Once inside, RatHat attempts to create something much more powerful: independent shell-level access through Android Debug Bridge.
Here is how the intruder moves through the house.
Phase 1 — Convince the Owner to Open the Front Door
RatHat does not begin by smashing a window.
It persuades the victim to let it inside.
The malware is distributed through targeted smishing, malvertising and third-party forums that lead users toward deceptive download portals containing malware-laced APK files.
The downloaded application acts as the dropper for the rest of the infection chain.
The intruder arrives disguised as something the homeowner has chosen to bring inside.
And once the APK is installed, the front door has been opened from within.
Phase 2 — Blind the Security Cameras
Before exploring the house, RatHat tries to make life difficult for anyone attempting to inspect it.
Its APK contains multiple anti-analysis mechanisms.
Container tampering manipulates the package structure so some files are interpreted differently by Android and common analysis tools.
Manifest bombing introduces undocumented headers capable of crashing or delaying automated analysis pipelines.
DEX bytecode poisoning introduces malformed elements intended to break disassembly.
And dual string encryption makes static inspection harder.
Think of the intruder covering cameras, switching labels on doors and rearranging the floor plan before the security team arrives.
The objective is not simply to enter.
It is to make reconstructing the entry considerably harder.
Phase 3 — Steal the Master Controls
Now RatHat begins looking for something more valuable than the permissions of an ordinary application.
It abuses Android Accessibility Services.
With that visibility and control, the malware can navigate the interface and enable Developer Options.
Then it activates Wireless Debugging.
Then it extracts the six-digit ADB pairing code.
That sequence is critical.
Android normally keeps applications inside sandboxes designed to limit what one app can do to the wider device.
RatHat is trying to move beyond that room.
By autonomously pairing with the local Android Debug Bridge daemon, it gains a path toward shell-level privileges.
The intruder no longer wants permission to stay in the guest room.
He wants the maintenance keys to the building.
Phase 4 — Build a Door Behind the Door
This is where RatHat becomes particularly interesting.
Its architecture contains three main components:
the malicious Android application,
a Go Agent masquerading as liblocal-service.so,
and an FRP reverse-proxy client.
The application gets the operation started.
But the other components allow the intrusion to become increasingly independent from it.
The Go Agent uses the shell access obtained through the local ADB daemon to execute commands and establish persistence.
The FRP client then receives configuration from the command-and-control infrastructure and establishes a persistent reverse tunnel back to the attackers.
The original APK has effectively served its purpose.
It brought the intruder inside long enough to construct another entrance.
Phase 5 — Dig a Tunnel Under the House
The FRP tunnel changes what that entrance means.
Instead of relying solely on whatever features researchers happened to discover inside the Android malware, attackers gain access to the ADB daemon through what Zimperium describes as a general-purpose road into the device.
That road can carry whatever the operator chooses.
The tunnel runs from the compromised device back toward attacker-controlled infrastructure.
So the house now has two very different entrances.
The visible front door was the malicious application.
The second is underground.
And the victim may not even know it exists.
Phase 6 — Throw the Intruder Out
Eventually, the victim notices something is wrong.
Perhaps the suspicious application is found.
Perhaps they uninstall it.
The icon disappears.
The APK is gone.
Problem solved?
Not necessarily.
Because RatHat’s shell access is no longer completely dependent on the original application.
According to Zimperium, the attacker can use the local service to determine whether the malware remains installed.
If it has been removed, it can reinstall it.
The homeowner has thrown the intruder out through the front door.
Outside, the intruder walks around the building.
Finds the hidden entrance.
And walks straight back inside.
Phase 7 — The Intruder Brings an AI Guide
RatHat adds another unusual capability to the operation.
The malware serializes Android’s live Accessibility tree into XML and communicates with a popular generative AI assistant.
The AI is not described as performing the malicious actions itself. Instead, according to Zimperium, it is used for navigation-related tasks such as identifying the center coordinates of a named object on the screen, determining the actual text displayed by an interface element and returning commands such as SCROLL_DOWN.
In our house, the intruder now has someone whispering directions into an earpiece.
“The switch you need is on the right.”
“Scroll down.”
“That button is here.”
Instead of every possible Android interface needing to be rigidly scripted in advance, the system can interpret what is currently on screen and determine where to interact.
The intruder is no longer simply following a fixed map. He has a guide helping him navigate the house as he sees it.
Phase 8 — Search Every Room
Once RatHat has established its position, the surveillance capabilities become extensive.
The malware can collect SMS messages, credentials, files, screenshots and installed-app information.
It can capture lock-screen PINs, patterns or passwords.
It can intercept keystrokes, including URLs typed into browser address bars.
It can record the screen through Android’s MediaProjection API.
It can place overlays over targeted applications to harvest credentials.
And its Go Agent includes a hardware-level keylogger capable of recording finger presses on the screen.
The attacker is no longer standing at the entrance.
He is moving from room to room.
Reading messages.
Watching screens.
Collecting keys.
Photographing documents.
And recording where the owner places their fingers.
Phase 9 — Put a Fake Sign on the Exit
RatHat can even interfere when the user attempts to install applications.
It can display a fake failure overlay impersonating the Google Play Store.
The victim believes Android or Google Play has rejected the action.
But the message they are seeing may actually have been placed there by the malware.
The intruder has progressed from hiding inside the house to changing the signs on its walls.
And that makes the victim’s own interface part of the deception.
Phase 10 — Find the Door You Cannot See
RatHat demonstrates why mobile remediation becomes significantly more complicated once malware escapes the assumptions of the normal application lifecycle.
Traditional thinking is straightforward:
Malicious app detected.
Malicious app removed.
Threat removed.
RatHat breaks that equation.
The APK can establish another component.
That component can leverage ADB.
ADB provides shell access.
The Go Agent can persist independently.
The FRP client can maintain a reverse tunnel.
And that infrastructure can potentially help bring the malicious application back.
So defenders need to investigate more than the package that originally appeared on the device.
Unexpected Accessibility privileges matter.
Developer Options matter.
Wireless Debugging matters.
ADB pairing matters.
Persistent native processes matter.
And evidence of shell-level compromise fundamentally changes the confidence defenders should place in simply uninstalling an application.
The Most Dangerous Door Is the One You Don’t Know Exists
RatHat is ultimately a story about persistence beyond the visible malware.
The phishing page is merely the driveway.
The APK is the front door.
Accessibility gets the intruder through the hallway.
Developer Options expose the maintenance panel.
Wireless Debugging opens another mechanism.
ADB provides the hidden entrance.
The Go Agent keeps it operational.
FRP digs the tunnel outside.
And AI helps the intruder understand where to move next.
That architecture challenges one of the most reassuring moments in mobile security:
“I deleted the malicious app.”
Because removing what you can see does not necessarily remove what it created while you were not looking.
The real question after an intrusion is therefore not simply:
Did we throw the attacker out?
It is:
How many doors did they build before we found them?
The Hacker News
Comentarios