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.

Executive Summary

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

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

Impressions

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

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

Modus Operandi

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

Key Takeaways

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

Overview

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

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

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

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

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

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

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

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

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

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

Discovery of the GhostX Ecosystem

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

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

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

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

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

ghostx-panel

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

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

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

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

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

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

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

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

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

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

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

Technical Analysis

Evolution of Droppers and Loaders

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Advanced GhostBat RAT Payload

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

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

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

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

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

Ghost Overlay

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

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

The feature is controlled through Firebase Remote Config using:

ghost_overlay_enabled

ghost_overlay_packages

The default Ghost Overlay configuration targets the following Android packages:

com.mobikwik_new

com.google.android.apps.nbu.paisa

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

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

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

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

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

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

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

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

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

Targeted Keylogging and PIN Capture

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

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

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

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

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

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

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

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

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

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

Command and Control Infrastructure

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

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

Our Recommendations

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

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

MITRE ATT&CK® Techniques

The post The GhostX Ecosystem: Forged in Transit, Licensed to Deceive 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.

Anthropic has warned some Claude users that criminals are using information stealers to take over their accounts.

Rather than guessing passwords or intercepting two-factor authentication (2FA) codes, the attackers steal the browser sessions that prove a user is already logged in.

According to a warning email shared publicly by an affected user, the attackers used common infostealer malware to copy Claude login sessions from victims’ computers. They then used those sessions to access the accounts and consume their usage.

“We recently signed you out of Claude and removed the payment method saved on your account, so you’ll need to log back in and re-add your card. We’re sorry for the disruption. Here’s what happened and what we’ve done about it.

What happened

We have recently become aware of a bad actor that is using common infostealer malware to steal Claude login sessions from people’s computers, then using those login sessions to access Claude accounts and consume their usage. Our systems detected this activity on your account, and we’ve therefore removed your card on file and signed out the sessions involved to help block further unauthorized access.

If your usage limits looked like they refilled and then drained while you weren’t using Claude, this was likely the cause.”

The message adds that Anthropic has no reason to believe the malware was “related to Claude, installed through Claude, or related to anything you did with Claude.”  

To sum this up:

• Cybercriminals are spreading infostealers. How they are doing this and whether they are targeting groups likely to use Claude professionally is unknown.
• Infostealers can bypass standard credentials and multi-factor authentication (MFA) by stealing active browser sessions and session cookies.
• Once they are able to take over a Claude account, they can consume the victim’s usage and potentially incur additional charges.
• Anthropic is signing affected users out of Claude, removing saved payment methods, and refunding charges it identifies as unauthorized.

To better understand this, you should know that paid Claude plans can offer additional “Usage credits.” When a subscriber reaches the plan’s session limit, Claude can allow them to continue using the service through consumption-based billing at standard API rates. The user must enable the feature, configure a monthly spending limit or select unlimited spending, and prepay for credits.

Users can also enable auto-reload, which automatically buys more prepaid credits when the balance falls below a threshold. So, in a session-hijacking scenario, a thief could use up the account’s included allowance and any available Usage credits. If auto-reload is enabled, they could also trigger further purchases.

The criminals’ likely motive is to use paid Claude capacity for free. The account and any exposed data could also be useful for fraud, social engineering, or follow-on attacks.

Stolen Claude capacity could be used to write and refine phishing and scam content, build campaign infrastructure, develop, modify, or obfuscate malware, improve delivery methods, and analyze stolen information. Cybercriminals can use AI to support several parts of an operation, although Claude has safeguards and abuse monitoring, and Anthropic says it has disrupted accounts used for malicious activity.

What to do

Anthropic provided advice for dealing with a possible infostealer infection. After removing the malware, we recommend you install an up-to-date, real-time anti-malware solution to help protect you against new infections.

These steps are good practice when cleaning up after infostealer malware:

1. Scan any computer you use with Claude for malware and remove any malware before logging back in or changing passwords.
2. Once the malware has been removed, secure the email account you use for Claude by changing its password, signing out of other devices, and enabling two-factor authentication (2FA).
3. Change sensitive passwords that were saved in the affected browser, including those for banking, work, and cloud services. Check your card statements if you stored payment details in the browser.
4. Only after completing these steps should you add your payment method to Claude again if you want your plan to continue renewing.

If you still see your usage changing while Claude is idle, or notice an unrecognized charge after completing these steps, contact usersafety@anthropic.com.

From reporting threats to removing them.

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

Unit 42's analysis of ClawHub revealed evasive malicious skills bypassing automated scanners to deploy infostealers and execute agentic financial fraud.

The post OpenClaw’s Skill Marketplace and the Emerging AI Supply Chain Threat appeared first on Unit 42.

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.

Unit 42 uncovers high-risk AI browser extensions. Disguised as productivity tools, they steal data, intercept prompts, and exfiltrate passwords. Protect your browser.

The post That AI Extension Helping You Write Emails? It’s Reading Them First appeared first on Unit 42.

Introduction

Findings

behash:"4acaac53c8340a8c236c91e68244e6cb"

/api/v3/files/09a8b930c8b79e7c313e5e741e1d59c39ae91bc1f10cdefa68b47bf77519be57/execution_parents

signature:"Peastaking plenipotence ductileness chilopodous codicillary."

signature:"© 2026 Eosinophil LLC"

exports:15Mmm95ml1RbfjH1VUyelYFCf exports:2dlSKEtPzvo1mHDN4FYgv

behash:5ddb604194329c1f182d7ba74f6f5946

IOCs

import "pe"

rule win_dll_sideload_eosinophil_infostealer_jan26
{
  meta:
    author = "VirusTotal"
    description = "Detects malicious DLLs (CoreMessaging.dll) from an infostealer campaign impersonating Malwarebytes, Logitech, and others via DLL sideloading."
    reference = "https://blog.virustotal.com/2026/01/malicious-infostealer-january-26.html"
    date = "2026-01-16"
    behash = "4acaac53c8340a8c236c91e68244e6cb"
    target_entity = "file"
    hash = "606baa263e87d32a64a9b191fc7e96ca066708b2f003bde35391908d3311a463"
  condition:
    (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and pe.is_dll()) and
    pe.exports("15Mmm95ml1RbfjH1VUyelYFCf") and pe.exports("2dlSKEtPzvo1mHDN4FYgv")
}