a friend got burned by a fake fitness tracker. then he sent me the APK.

this started on IRC with a friend telling me, more or less, "I fell for something stupid and I still have the APK."

he had already figured out it was a scam by the time he came to me.

the part he wanted from me was the malware analysis.

what the fuck did he actually install, what could it do, and how bad did he need to treat the phone afterward.

what actually happened

he uses Prolific to do paid research studies.

according to him, this started from one of those study flows.

he had literally just completed another app-download study shortly before this one. that one was legitimate, worked, paid, and did not ask him to hand his phone to Satan.

then he got another offer. about six bucks for maybe five minutes.

that one redirected him to a fake Google Play landing page.

he hesitated because he knew that looked wrong.

then the very human part happened: he had just done basically the same kind of study successfully, it appeared to be coming through a service he trusted to screen this shit, and the reward was enough to make "this is probably fine" win over "this looks fucking wrong."

the app presented itself as a fitness tracker.

then it started doing the classic escalation routine.

install fitness tracker
  -> "install Google Play Services"
     -> "update Android"
        -> keep granting the thing more control

by the time he realized how bad it was, the apps had already been on the phone.

he later reported that $101 was taken from his PayPal account.

PayPal closed his unauthorized-access case, apparently because the transaction looked like it came from his phone and location.

he had already filed complaints elsewhere and was pissed off, but what he still had that was actually useful to me was the original archive.

0t46hk.7z

he sent it over IRC and asked me to tear it apart.

important distinction here: I am not claiming Prolific wrote this malware, knowingly distributed it, or was the operator.

the fact I have is his account that the malicious flow began from a paid study he accessed through Prolific and then redirected him to a fake Google Play page.

it could have been a malicious study operator, a compromised account, impersonation, or something else upstream. I did not investigate that part of the chain.

I investigated the APK.

my initial reaction was basically "ooo malicious APKs"

he had already opened both the outer APK and the embedded one in JADX and noticed enough weird shit to know this was not going to be a normal app.

I opened it and immediately saw the second APK too.

then the decoy DEX files.

he asked whether he should just run the thing in Android Studio and watch the traffic.

maybe eventually.

but malware knows emulators exist, and I still had a lot of static surface left before I needed to execute anything.

so I stayed static.

that turned out to be enough.

first problem: the APK did not want to be an APK

the archive contained app.apk.

normally at this point you unzip it, feed it to the usual Android tooling, and start reading.

this one immediately started being an asshole.

normal ZIP parsing choked on malformed central-directory extra fields.

then the archive listing claimed there were 434 files named like classes00*.dex, each conveniently advertised as exactly 1 MiB.

there were piles of junk-looking assets too.

blindly asking a decompiler to eat all of that is basically volunteering to waste your own time.

classes001.dex    1048576
classes002.dex    1048576
classes003.dex    1048576
...
[431 more pieces of bullshit]

the actual outer code was just three real DEX files.

classes.dex
classes2.dex
classes3.dex

parse the local file headers, look for actual DEX magic, ignore the advertised garbage, and the thing becomes substantially less mysterious.

this is not sophisticated in the sense of being elegant.

it is sophisticated in the sense that it knows a lot of analysis tooling will obediently walk directly into the tarpit.

of course there was another APK inside the APK

the real outer code eventually led to this:

uknown/flykdzt9azm=.apk

yes, uknown.

package name:

io.xbslmmmp.clientf92mf

the outer package was:

com.harvdouh.clienttdkar

both were signed with the same certificate, so this was not some random library accidentally bundled into the first app.

the second manifest was already enough to stop pretending this was normal software.

camera. SMS read/write/send/receive. notification listener. accessibility service. device admin. boot receivers. media projection. an overlay process. separate UI task affinities for pattern, PIN, and password screens.

subtle.

then the second APK had another payload inside it

inside stage two was HSb.jar.

encrypted.

the unpacker was kind enough to contain both the filename and the key.

payload: HSb.jar
key:     IdCB

the routine is RC4.

decrypt the blob with IdCB and suddenly HSb.jar is a completely valid JAR containing three more DEX files.

0t46hk.7z
  -> app.apk
     -> malformed/padded APK
     -> 434 fake DEX entries
     -> real outer DEX
        -> uknown/flykdzt9azm=.apk
           -> io.xbslmmmp.clientf92mf
           -> encrypted HSb.jar
              -> RC4 key: IdCB
              -> decrypted HSb.jar
                 -> classes.dex
                 -> classes2.dex
                 -> classes3.dex
                    -> RAT

at this point I was done fighting the packaging and could finally look at what the thing actually does.

this is where the fucking thing stopped being coy

most of the interesting custom RAT code is in the recovered classes2.dex.

and the strings are not exactly trying to preserve plausible deniability.

addHtmlInjectionConfig
collectSmsNow
enableUninstallProtection
disableUninstallProtection
startVncScreenSharing
startCamera
startSmsCollection
getKeyguardInfo
socks5_enable
socks5_status_request
KeylogBatch
KeylogEntry
Only adb shell commands are supported

that is about the point where "is this malware" stops being an interesting question.

the HTML injection system is for credential overlays. it can receive injection configuration and collect data submitted through fake UI.

the keylogger is not me inferring something from an Accessibility permission. there are actual KeylogBatch and KeylogEntry implementations.

SMS theft is backed by the permissions, receivers, and explicit collection commands.

screen sharing is explicit.

camera control is explicit.

uninstall protection is explicit.

there is also a SOCKS5 tunnel manager, meaning the infected phone can be turned into a residential proxy node for somebody else's traffic.

because apparently stealing your credentials and driving your phone remotely was not enough utility per victim.

and yes, it has a shell

this build also contains a substantial wireless ADB implementation.

not just a string containing the word adb. an actual Java ADB client, pairing/identity handling, and code paths for running shell commands.

:wireless-adb-identity:v1
ADB shell command cannot be blank
ADB shell command exceeds 500 characters
ADB shell command failed
ADB shell command must be a single line
ADB shell command returned no data
Only adb shell commands are supported

if the malware gets the device into the state it expects, that is a real remote shell capability.

good.

great.

where it phones home

the recovered config points at vbnsajiqlas.com.

control and bulk data are split across separate WebSockets, with HTTPS polling as a fallback.

wss://vbnsajiqlas.com:27911/control?sessionId=...
wss://vbnsajiqlas.com:45598/data?sessionId=...
https://vbnsajiqlas.com:31192/api/device/poll

protocol strings include:

AndroidClient-Control/1.0
AndroidClient-Data/1.0
AndroidClient-HttpPoll/1.0
X-Channel-Type
X-Session-ID

I did not connect to any of it.

this was static analysis. I wanted to know what the sample was, not introduce myself to the operator.

once I had the C2 and the recovered command set, I sent my friend the domain with a giant "do not visit this" attached to it and told him to factory reset the phone.

he had already uninstalled the apps in safe mode.

I still told him to reset it, set it up as a new device instead of restoring blindly from backup, and change account credentials from a trusted device.

with a RAT like this, "I uninstalled the visible app" is not where I would choose to stop.

so what family is it

high confidence: Mirax/Cifrat lineage.

Cleafy's Mirax writeup documents the same split control/data WebSocket design and the same unusually specific command vocabulary.

CERT Polska's Cifrat analysis describes an extremely similar chain: multistage Android dropper, embedded second APK, encrypted final payload, Accessibility abuse, HTML injection, SMS theft, camera, screen streaming, SOCKS5, and dual WebSocket C2.

their published samples use different packages, hashes, encryption keys, and C2.

so I am not claiming I found one of their exact APKs.

I did not.

this looks like another build/repack/campaign instance from the same family.

which was actually useful: the sample my friend sent me did not match the exact outer APK hash I found in the public writeups.

so at least I got something interesting out of the whole mess.

what about persistence

it has plenty of normal Android userspace persistence.

boot receivers. Accessibility. Device Admin. battery-optimization bypass requests. WorkManager/system jobs. uninstall protection.

it wants to stay installed and it has multiple ways to make ordinary removal annoying.

I did not find evidence in the recovered sample of boot image, recovery, /system, /vendor, or firmware modification.

reboot:                 survives
ordinary user removal: actively resists it
genuine factory reset: should remove it
full trusted reflash:  stronger cleanup if system compromise is suspected

that is an assessment of this code, not a metaphysical guarantee that no separate exploit could ever have been used on the phone.

back to the $101

the question was never really "is this APK sketchy."

by the time he sent it to me he already knew he had been scammed.

the useful questions were what the APK actually was and whether it had capabilities that could plausibly explain an account compromise performed from his own phone.

on that second part: yes, absolutely.

credential overlays, keylogging, SMS collection, screen capture, remote interaction, notification access, and a RAT control channel are exactly the sort of capabilities that make "the transaction came from your phone" a pretty shitty reassurance.

but I still cannot prove from static analysis alone that this exact APK caused that exact $101 PayPal transaction.

I do not have the PayPal session logs, the infected phone's historical telemetry, or the operator-side records.

so the clean version is:

reported incident:
  victim installs fake fitness-tracker / fake Play Services chain
  victim later reports $101 stolen from PayPal

what I established:
  supplied APK is a multistage Android RAT
  RAT has credential-theft and remote-control capability
  sample is high-confidence Mirax/Cifrat lineage

what I did not establish:
  forensic attribution of the specific $101 transaction

that is as far as the evidence goes.

what I actually published

I am not putting the live malware sample in the repo.

there is no reason to make this easier for somebody who just wants the APK.

the repo contains the hashes, IOCs, unpacking notes, and the full static report.

he came to me embarrassed because he knew better and clicked through it anyway.

honestly, that part is not technically interesting.

people get tired. people are distracted. a thing resembles something legitimate they did ten minutes ago. a trusted platform lowers the alarm threshold. six bucks for five minutes sounds harmless.

then some asshole has a RAT on your phone.

the technically interesting part was what was hiding under the fake fitness tracker.

and that part was extremely fucking bad.