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.

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.

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.

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]

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)

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:

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

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.

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.

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.

Infostealer malware is behind a large share of today's credential compromise — and it usually doesn't start with a breach at all. When a security team hears "data breach," the instinct is to look for the moment a database was exfiltrated or a network was penetrated. But more often, the real starting point is a single endpoint infection, often on a personal device, that has nothing to do with the organization's perimeter.

By the time stolen credentials show up in a breach notification or a dark web alert, they've already passed through several distinct, mechanical stages. Understanding that pipeline — rather than waiting for the final alert — is what separates reactive security teams from ones that catch exposure early.

How Infostealer Malware Powers the Credential Theft Pipeline?

What follows is a stage-by-stage breakdown of that journey — from the moment infostealer malware first executes on a device, through the log assembly and enrichment steps that add value along the way, to the final point where credentials are packaged and sold on the open market. Each section builds directly on the one before it, showing exactly how a single infection turns into an inventoried, priced, and marketable product.

Execution and Harvesting 

The pipeline begins with infostealer malware — a lightweight piece of software designed to do one thing efficiently: grab whatever credentials, cookies, and session tokens are sitting in a browser or application on the infected machine. This is the core mechanism behind modern credential harvesting, and these tools typically arrive through cracked software installers, fake game cheats, malicious browser extensions, or phishing lures disguised as invoices or shipping notices. 

Once executed, the stealer doesn't loiter. It targets browser credential stores, autofill data, saved payment details, cryptocurrency wallet files, FTP client configurations, and any session cookies that could allow an attacker to bypass login screens entirely. Many stealers also grab system fingerprinting data — IP address, hardware ID, installed software — which becomes useful later for building convincing sessions or bypassing device-based fraud checks. 

The output of this stage is a "log": a structured folder of text files, often just a few kilobytes, containing everything the malware could pull from that one machine. These stealer logs are the raw currency of the entire pipeline that follows. 

Aggregation and Log Assembly 

A single log is not particularly valuable on its own. Its worth comes from volume. Threat actors operating stealer campaigns typically run panels — command-and-control dashboards — that collect incoming logs from hundreds or thousands of infected machines simultaneously. These logs get bundled into larger archives, sometimes labeled by infection date, campaign, or targeted region. 

This is the point where individual credential theft becomes an inventory problem for the attacker. Logs get sorted, deduplicated, and screened for anything obviously valuable — corporate VPN logins, SaaS admin panels, banking portals — versus low-value consumer accounts. 

Parsing and Enrichment 

Raw logs are messy, so a parsing step usually follows before anything is sold or shared. Automated tools and, in some cases, manual review are used to extract structured fields: username, password, URL, and associated cookies, organized into searchable formats. This is also where enrichment happens — cross-referencing a log against previously leaked datasets to add context like a person's employer, job title, or other accounts tied to the same email address. 

Enrichment matters because it changes the value proposition. A raw password paired with a login URL is interesting. That same credential paired with confirmation that it belongs to an IT administrator at a mid-sized company is something else entirely — and priced accordingly.  

It's also at this stage that enriched credentials become prime material for credential stuffing campaigns, where attackers automate login attempts across dozens of unrelated services in the hope that a password was reused. 

Marketplace Listing 

The final stage is distribution. Parsed and enriched logs are listed for sale on dark web marketplaces and forums, sometimes as full archives ("bulk logs") and sometimes broken apart and sold as individual access credentials to specific platforms — a corporate email account, a cloud console login, a remote desktop session. Listings often include partial samples as proof of authenticity, along with metadata like infection date, geography, and browser type, to help buyers judge freshness and relevance. 

This is usually the first point where an outside observer — including a security team — has a realistic chance of spotting exposure, provided they're actually looking at this layer of the ecosystem rather than waiting for a breach disclosure further downstream. 

Why the Earlier Stages Matter More Than the Alert? 

Most detection strategies are built around the last step: someone notices a listing or a breach compilation and issues an alert. But by then, the credential may have already changed hands, been tested against multiple services, or been bundled into a larger fraud operation. The earlier stages — infection, log assembly, and enrichment — are where exposure actually originates, and where it can be caught closer to the source. 

For SOC teams and identity security leads, the practical takeaway is that credential exposure isn't a single event to monitor for — it's a pipeline to monitor across. Visibility into stealer logs, marketplace chatter, and enrichment activity gives a much earlier warning than waiting for a finished, packaged breach. 

Your Credentials Are Probably Already for Sale. You Just Don't Know It Yet. 

Somewhere right now, an infostealer log sits in a marketplace listing with your company's name attached to it — and nobody on your team has seen it. That's not a scare tactic. It's the default state for most organizations, because credential exposure happens quietly, on devices you don't control, long before it ever becomes "your" incident. 

The only real question is whether you find out from a threat feed, or from a breach headline. 

See what's already exposed — before someone else finds it first. Run a free check with Cyble and get a real answer, not a guess. 

The post From Infostealer Log to Marketplace Listing: A Technical Walkthrough of the Credential Theft Pipeline 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.

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

Indicators of Compromise (IOCs)

The post Glitch SPY: An Emerging Android RAT Distributed Through a Fake Polish Rental App 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.

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.

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.

`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.

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.

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

Indicators of Compromise (IOCs)

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