Morphisec exposes a LuaJIT XLoader infostealer campaign. Learn how the XLoader infostealer abuses JScript and shared-section injection.
Related Posts:
The post LuaJIT XLoader Infostealer Spreads via Fake Orders appeared first on Daily CyberSecurity.
Cisco Talos has analyzed a new Windows infostealer called VOLTA, which calls itself VOLTA-AUTODOXER. It steals the usual data, then hands the loot to a large language model that ranks what the victim is worth. Ryan Fetterman laid it out in a Talos report, after the malware turned up through the CAIRN research effort.
“There is a new idea in the cybercrime world — cast a wide net, steal everything, and let AI sort out the specifics. A new malware self-named “VOLTA-AUTODOXER,” surfaced through the CAIRN research effort, is a self-deleting Windows infostealer that augments its post-theft workflow with an LLM-powered victim-profiling stage.” reads the report published by Talos.
The malware deletes itself after running and does not use servers controlled by the attacker. Instead, it uses third-party systems to carry out its activities.
The malicious code supports data-stealing features are advanced. It collects browser passwords, cookies and saved payment card details from Chromium browsers, as well as data from Firefox, Thunderbird and Outlook. It also steals Slack workspace information and login sessions from Discord, Telegram, Steam, Battle.net and Roblox.
The malware also collects Microsoft OAuth tokens, SSH keys, cloud service credentials, screenshots and all saved Wi-Fi passwords. For crypto wallets, it tries to crack the wallet password directly on the infected device and saves the results in its report. To steal some browser tokens, it must bypass Chrome’s App-Bound Encryption.
But VOLTA goes further. It also builds a detailed profile of the victim. This includes their location and home address, employer and company domain, estimated year of birth, the last four digits of payment cards, Slack workspaces and information about who created documents. It also looks for signs of iPhone backups and checks the current value of the victim’s Roblox account.
“After harvesting the standard stealer haul, including browser passwords; cookies; payment cards; cryptocurrency wallet seed phrases; Discord, Telegram, Steam, and Roblox sessions; Microsoft OAuth tokens; SSH and cloud-provider keys; Wi-Fi profiles; and screenshots, VOLTA builds a structured evidence bundle about the person behind the machine.” states the report.
It uses the victim’s own logged-in sessions to fill the gaps. It searches Gmail for receipts from Amazon, DoorDash, Uber Eats, Grubhub, Walmart and PayPal to confirm a home address, pulls order histories from Uber Eats and DoorDash, and adds detail to the victim’s Discord profile. Even a takeout history can now count as evidence.
The bundle goes to OpenRouter, a routing service for AI models, with a system prompt that tells the model to act as a forensic intelligence analyst drafting a target assessment.
“The required output includes a section titled “WHAT THEY’RE WORTH” with valuables ranked by monetization with a low/medium/high tier, and a section on “THEIR OPSEC” containing an assessment of the victim’s security posture and password hygiene.” states the report. “The model is the operator’s triage analyst; it turns a raw credential log into a prioritized and citation-backed dossier of the victim and their monetizable assets.”
It also needs a section called “THEIR OPSEC”, rating the victim’s security habits and password hygiene. In short, it’s a performance review for the person it just robbed.
The prompt asks for something agents do well: connecting scattered facts. It pushes the model to link names, addresses or universities to patterns in the victim’s passwords. The model isn’t hunting for new data, only stretching what the malware already took. The operator wants a short, blunt assessment with a trail of citations.
By default VOLTA calls Anthropic’s Claude Opus 4.6. If the model refuses, which VOLTA spots by scanning replies for phrases like “I can’t” or “I’m not able”, it moves on to Moonshot AI’s Kimi K2 and then Google’s Gemini 2.5 Flash. A low temperature setting of 0.2 keeps the output consistent.
The requests are hand-built JSON with no software kit, and the malware still runs without the AI stage if no API key is present.
Talos sees the fallback system as evidence that the malware’s author expected security protections and designed ways to bypass them.
The AI analysis runs directly on the victim’s computer, using their own internet connection, before any data is sent out. The malware creates a file called Identity_Report.txt, receives the AI’s response in AI_Analysis.txt, and sends both files together in a ZIP archive called volta_dox.zip.
The stolen data can be sent to the attacker in up to three stages. The first archive, volta_log.zip, contains the information collected by the malware. The second, volta_dox.zip, contains the AI analysis. A third archive, volta_doxnet.zip, is created if the malware finds additional network information. The attacker receives everything through a Telegram channel.
The malware also has six configurable fields that can be changed when it is built. This suggests that its author may offer a builder service, allowing customers to create their own customised versions.
The credentials stored in these fields are encrypted, but the encryption is weak because the key is stored inside the malware itself. Anyone who analyses the file can recover them.
If VOLTA is sold as a commercial product, its AI feature could allow even inexperienced criminals to identify valuable victims and receive detailed, ranked profiles directly through Telegram.
For defense, Talos suggests an application control policy that restricts which processes can launch Chrome with the –headless flag, which would block the App-Bound Encryption bypass. At minimum, alert when Chrome starts with –headless from any process outside a known developer set. Storing credentials in hardware-backed stores also helps.
If you’re compromised, the main program may have deleted itself, but try to keep %APPDATA%\volta_debug.txt. It’s a timestamped log of what was collected and whether the AI call worked. Revoke any exposed tokens and change passwords. If a wallet’s seed phrase sat in plaintext on disk, treat the wallet as fully compromised and move the funds to a new wallet whose seed was generated on an air-gapped device.
“VOLTA is a mature stealer with a late-stage AI layer added for one purpose: relieving the operator of analytical work. The axis of AI improvement here is not speed or scale but effort displacement; the same logic visible in CLOSEDQUORUM, though applied to a different phase.” concludes the post. “These implants reflect the same underlying logic: Identify the step that requires the most sustained human attention and replace it with a model call. The question for defenders is not whether this pattern will appear elsewhere, but which phase it touches next.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, malware)
Cisco Talos uncovers the NIK C2 framework. This Windows NIK C2 framework abuses OpenAI APIs to analyze stolen victim data and deploy screen lockers.
Related Posts:
The post NIK C2 Framework Integrates OpenAI API to Analyze Stolen Data in Live Attacks appeared first on Daily CyberSecurity.
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.
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.
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.
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.
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.
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.
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.
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.
EntrarRewriteEngine 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.
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.
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)
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.
| 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.
The takeover script truncates logs, then deletes them, and clears shell and database history, so evidence shrinks with every run:
Then clean, in this order
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.
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 |
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 |
The post From Hijacked PBX to Stolen Trunk: INJ3CTOR3’s Campaign Evolves appeared first on Cyble.
Zscaler uncovers an SEO poisoning campaign using fake Chocolatey and Massgrave sites to drop Armorsteal malware and Python Armorsteal malware modules.
Related Posts:
The post Fake Chocolatey and Massgrave Sites Deliver Python Armorsteal Malware via SEO Poisoning appeared first on Daily CyberSecurity.
Symantec reveals the Aoki infostealer. The Aokigahara Aoki infostealer steals API keys and session files from Claude, Codex, Cursor, and Gemini.
Related Posts:
The post Aoki Infostealer Harvests API Keys and Tokens From AI Coding Assistants appeared first on Daily CyberSecurity.
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.
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.
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.
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:
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.
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:
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.
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.
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.
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.
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:
| 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.
A fake Web3 accelerator used malicious npm packages to drop stealers on macOS and Windows and reroute AI coding agent traffic to its servers.
Related Posts:
The post Malicious npm Packages From Fake Web3 Accelerator Apex Deliver Stealers and Hijack AI Coding Agents appeared first on Daily CyberSecurity.
Warden Stealer, a fast-growing Rust infostealer, steals AI agent tokens, browser data, and crypto while bundling its own loader and clipper.
Related Posts:
The post Warden Stealer Rust Infostealer Targets AI Coding Agent Tokens and Browser Data appeared first on Daily CyberSecurity.
Trump Mobile data breach: BYOD leaks Trump Mobile customer data for 3,615 people, including Trump allies, via an infostealer and no MFA.
Related Posts:
The post Trump Mobile Data Breach Exposes 3,615 Customers in BYOD Leak appeared first on Daily CyberSecurity.
2CLoader malware dodges sandboxes and security tools to deliver Vidar and Remus infostealers. See how it works and how to detect it.
Related Posts:
The post New 2CLoader Malware Delivers Vidar and Remus Infostealers While Dodging Sandboxes appeared first on Daily CyberSecurity.
A new MacSync macOS infostealer spreads via fake apps. Learn how the MacSync macOS infostealer abuses iCloud to compromise Apple systems.
Related Posts:
The post New MacSync macOS Infostealer Targets Crypto Wallets appeared first on Daily CyberSecurity.
A new PamStealer macOS infostealer spreads via fake Wavel apps. Learn how the PamStealer macOS infostealer steals system passwords and browser data.
Related Posts:
The post PamStealer macOS Malware Spreads via Fake Wavel Crypto App appeared first on Daily CyberSecurity.
Someone impersonated LastPass on GitHub, got users to download a fake authenticator, and ended up killing 145 different antivirus and EDR products using a driver that Microsoft itself had signed. That last part is the one worth sitting with.
LastPass’s Threat Intelligence, Mitigation, and Escalation team spotted the fake GitHub organization on August 13, 2026. It appeared high in search results for “LastPass Authenticator download” and used real LastPass logos and branding to look legitimate. The download page also displayed fake trust badges, including “VirusTotal Approved.” The badges were meaningless and were simply there to make users feel safe enough to download the file.
Once LastPass brought in Delphos Labs for payload analysis, the picture got a lot bigger than one fake page. They found a shared kit actively impersonating more than 40 different companies, all running through the same infrastructure. This wasn’t a one-off phishing attempt, it was a malware-as-a-service operation with LastPass as just one of many skins on the same underlying product.
“LastPass Threat Intelligence, Mitigation, and Escalation (TIME) Team, in partnership with Delphos, identified and disrupted a multi-stage malware delivery campaign impersonating at least 40 companies on GitHub.” reads the report published by LastPass. “The payload it delivered survived controls that were built to stop exactly this, with a Microsoft Windows Hardware Compatibility Publisher chain signature and a clean VirusTotal score. LastPass is internally tracking the infostealer as Rapuncel.”
Worth stating plainly, since brand impersonation attacks like this tend to get misattributed to the company being spoofed. LastPass wasn’t breached here. Its name was borrowed, which is a different and honestly more common problem: attackers don’t need to break into a company, they just need a logo people trust.
“This was opportunistic brand impersonation. No LastPass system, service, or customer vault was involved or compromised. The lure was distributed entirely outside LastPass channels. Official LastPass Authenticator is available through lastpass.com and the official app stores.” continues the report. “GitHub is not a LastPass distribution channel. This was opportunistic use of a recognizable name.”
The download process was more sophisticated than it first appeared. When victims clicked the download button, they were sent through two other GitHub Pages accounts that looked like broken 404 pages but secretly used JavaScript to redirect them to the next step.
A separate server behind Cloudflare then chose where to send the final malware. This meant the attackers could switch to a new malware server without changing the GitHub pages. The endpoint also changed between August 27 and September 10, showing that the attackers were still actively maintaining the campaign.
The ZIP file itself uses an old trick that still works: padding. Two large junk DLLs inflate the archive past the size limit most automated scanners bother checking, so the real malware slips through hidden among plausible looking files. Delphos has seen this exact size-padding move before in an unrelated 55MB stealer sample, so it’s not new, it’s just still effective because scanners haven’t closed that gap.
Once opened, the fake installer was actually a Microsoft debugging tool that had been renamed. It automatically loaded a malicious DLL placed in the same folder. The malware then gained SYSTEM privileges and installed a kernel driver disguised as an NVIDIA component.
The driver had a valid Microsoft Windows Hardware Compatibility Publisher signature. That trusted signature helped it bypass security checks and then disable the antivirus and EDR products installed on the victim’s system.
“The signature was ineffective at halting this campaign because a signature merely asks whether a file matches something already discovered to be malicious. This driver was signed, timestamped, and clean on VirusTotal, and its dangerous twin was hiding behind a different filename. Every signal a signature-based control reads came back green.” continues the report. “The Microsoft signature proves the driver passed through a trust pipeline. It does not prove the driver is safe.”
That’s the whole failure mode in one sentence. The driver was clean on VirusTotal, properly signed, and not on Microsoft’s blocklist, because it wasn’t the same file as the one everyone was already watching for. Delphos traced it back to CcProtect.sys, a known Chinese disk-encryption driver already catalogued on LOLDrivers with public proof-of-concept killer code freely available on GitHub. The attackers just renamed the file to Alinubx.sys, and that single change was enough to dodge every hash-based detection built around the original name.
“A user-mode stealer steals credentials. A trusted kernel driver clears the runway.” continues the report. “This is an abuse-by-design driver rather than a memory-corruption exploit. The process-kill interface appears to be product functionality exposed by a host-defense driver. The control is policy enforcement: block the driver, deny the signer or lineage, or prevent the drop. If the driver is trusted and not blocklisted, administrator rights are enough to install and use it.”
Once the driver killed security software from kernel level, the actual credential theft was almost mundane by comparison. Passwords from more than 25 browsers, wallet files from over 30 crypto apps, Discord tokens, Steam sessions, Telegram data, anything in Windows Credential Manager, screenshots of every connected monitor. For Chrome and Edge specifically, the malware injected code directly into the browser process to call the browser’s own decryption service from the inside, defeating Google’s 2024 app-bound encryption by simply asking nicely from a trusted position.
Delphos flagged the sample to Microsoft on August 19. MSRC responded that the driver behavior doesn’t meet its definition of a security vulnerability, since it’s not a Microsoft-owned component, and redirected the report to the separate blocklist submission channel instead. As of publication, Alinubx.sys still wasn’t on that blocklist. Bureaucracy moves at bureaucracy speed, malware doesn’t wait for it.
The bigger lesson is not just about this campaign. It is about the assumptions that no longer hold. A well-known brand on GitHub does not mean the repository is official. A Microsoft signature does not automatically mean a driver is safe. A clean VirusTotal result does not prove a file is harmless. And a blocklist can only stop threats that have already been identified.
In this case, attackers managed to exploit all four trust assumptions at the same time, using a toolkit that is currently targeting around 40 other companies.
If you or someone on your team downloaded an authenticator or security tool from a GitHub link in the past few weeks, it is worth spending 15 minutes checking the system now. It could save you from a much bigger problem later.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, LastPass)
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.
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.
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.
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.
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.
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.
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.
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.
