Cybersecurity agencies across the Pacific region are sharing concerns about the ransomware group INC Ransom’s expanding activities and the growing influence of its affiliate network.

A joint advisory issued by the Australian Cyber Security Centre (ACSC), National Computer Emergency Response Team Tonga (CERT Tonga), and the New Zealand National Cyber Security Centre (NCSC) highlights how the INC Ransom ecosystem has become an active threat to organizations in Australia, New Zealand, and Pacific Island states.

The advisory from the agencies down under is designed for both technical specialists and general network defenders. It outlines how INC Ransom operates, the techniques its affiliates use, and the steps organizations can take to reduce their exposure. Officials from the three agencies are urging both government ministries and private organizations to review the mitigation measures outlined in the guidance to strengthen defenses against INC Ransom activity.

What distinguishes this campaign is not only the ransomware itself, but the operational structure behind it. The INC Ransom ecosystem relies on a distributed affiliate model, enabling a broad range of cybercriminal operators to conduct attacks using shared tools and infrastructure.

The INC Ransom Affiliate Model and the RaaS Ecosystem

The operational structure of INC Ransom, which functions as a Ransomware-as-a-Service (RaaS) platform. The model allows external affiliates to deploy ransomware against victims while the core operators manage extortion negotiations and payment collection. 

INC Ransom first emerged in mid-2023 as a financially motivated cybercriminal group believed to be based in Russia. Since then, the group has built an affiliate network that distributes ransomware to attackers targeting organizations worldwide. Within this structure, affiliates perform the technical intrusion and deployment of the malware, while the core INC Ransom operators handle victim communication and ransom demands. 

The group is also known by other threat-intelligence labels, including Tarnished Scorpion and GOLD IONIC. 

According to the advisory from ACSC, NCSC, and CERT Tonga, INC Ransom operations are particularly focused on organizations that manage sensitive or high-value information. Health care providers have become a prominent target globally, likely due to the operational pressure these organizations face when systems become unavailable. 

Although earlier activity concentrated on victims in the United States and the United Kingdom, threat intelligence collected by ACSC, NCSC, and CERT Tonga indicates that the group has shifted attention toward the Pacific region since early 2025. 

INC Ransom Incidents in Australia

In Australia, ACSC has tracked a series of incidents linked to INC Ransom affiliates. 

Between 1 July 2024 and 31 December 2025, the ACSC responded to 11 incidents attributed to the ransomware operation. These incidents primarily affected organizations in professional services and the health care sector. 

Since January 2025, analysts at the ACSC have observed INC Ransom affiliates targeting Australian health care entities through compromised user accounts. Once access is obtained, attackers typically escalate privileges by creating new administrator-level accounts. They then move laterally through internal systems to expand control within the network. 

During these operations, INC Ransom affiliates have deployed malicious payloads using filenames such as “win.exe.” Investigations conducted by the ACSC have also identified cases in which attackers exfiltrated personally identifiable information and medical records before launching the encryption phase. 

Victims typically discover ransom notes containing instructions and links to the INC Ransom Tor-based data leak site (DLS) where negotiations occur. 

Health Infrastructure Disruption in Tonga 

One of the most disruptive incidents linked to INC Ransom occurred in the Kingdom of Tonga. 

On 15 June 2025, the ICT environment of the Tongan Ministry of Health was hit by a ransomware attack that disrupted the national health care network and rendered several core services inaccessible. Investigators from CERT Tonga, working with regional partners including ACSC and NCSC, discovered a ransom note associated with INC Ransom embedded within the ministry’s file systems. 

On 26 June 2025, the INC Ransom group publicly claimed responsibility for the incident on its dark-web data leak site. 

The advisory further identifies Roman Khubov, a cybercriminal also known as “blackod,” as the individual controlling the malicious infrastructure used to exfiltrate data during the Ministry of Health breach. 

Ransomware Incident in New Zealand 

Ransomware activity remains a persistent problem in New Zealand, where multiple sectors of the economy have experienced disruptions. 

In May 2025, the NCSC received a report from a health-sector organization that had suffered a major ransomware intrusion. According to the notification, attackers encrypted a large number of servers and endpoint devices while also stealing significant volumes of data. 

The NCSC investigation determined that INC Ransom was responsible for the incident. After the organization refused to meet the extortion demand, the attackers published the stolen dataset on the INC Ransom data leak site. 

The event reinforced concerns among cybersecurity officials at NCSC, ACSC, and CERT Tonga that the group’s tactics are targeting organizations whose operations are highly sensitive to disruption. 

Technical Tactics Used by INC Ransom 

Technical analysis from ACSC, NCSC, and CERT Tonga shows that INC Ransom affiliates rely on several common intrusion techniques to gain initial access to victim networks. 

The most frequently observed entry points include: 

• Spear-phishing campaigns targeting employees 

• Exploitation of unpatched internet-facing systems 

• Purchased credentials from initial access brokers 

Once inside the network, INC Ransom affiliates often rely on legitimate software tools rather than custom malware to perform key tasks. This tactic allows malicious activity to blend into normal administrative operations. 

For example: 

• 7-Zip and WinRAR are used to compress data before theft. 

• The file synchronization tool rclone is frequently used to transfer stolen data outside the network. 

After data exfiltration, attackers deploy the encryption component of INC Ransom. A ransom note is then left on affected systems with payment instructions and contact details. 

If the targeted organization refuses to pay, INC Ransom operators initiate double-extortion tactics by publishing both the victim’s name and stolen information on the group’s leak site. 

Security analysts note that the tactics, techniques, and procedures (TTPs) used by INC Ransom share similarities with other ransomware operations such as Lynx, Nemty, Nemty X, Karma, and Nokoyawa. 

Defensive Measures Recommended by ACSC, NCSC, and CERT Tonga 

The joint advisory from ACSC, NCSC, and CERT Tonga outlines several practical security measures designed to reduce the risk of INC Ransom compromise. 

Key defensive actions include: 

• Maintain Reliable Backups: Organizations should maintain regular, tested backups of critical systems and store them securely to prevent unauthorized modification or deletion. 

• Restrict Network Traffic: Network administrators should limit inbound and outbound traffic to only what is necessary for operations. Firewalls and filtering technologies can help reduce exposure to phishing campaigns and malicious attachments. 

• Harden Remote Access: Virtual private networks (VPNs) and other remote access systems should be carefully configured to ensure only authorized users can reach sensitive resources. 

• Implement Multi-Factor Authentication: The advisory from ACSC, NCSC, and CERT Tonga emphasizes implementing phishing-resistant multi-factor authentication (MFA) for internet-facing services and privileged accounts. 

• Manage Privileged Access: Administrative privileges should be tightly controlled. Unique accounts for administrators improve accountability and reduce the impact of credential compromise. 

• Maintain Strong Vulnerability Management: Regular vulnerability scanning and rapid patching of exposed systems remain critical, particularly for internet-facing services that ransomware actors commonly target. 

Growing Regional Collaboration Against the INC Ransom 

The joint advisory reflects cooperation among cybersecurity agencies across the Pacific. By sharing intelligence and incident data, organizations such as ACSC, NCSC, and CERT Tonga are building a more coordinated response to ransomware threats like INC Ransom. 

The rise of affiliate-driven ransomware operations has significantly lowered the barrier to entry for cybercriminal activity. In this environment, the INC Ransom ecosystem demonstrates how distributed attacker networks can rapidly shift focus across geographic regions. 

For organizations in Australia, New Zealand, and the Pacific islands, the advisory from the Australian Cyber Security Centre (ACSC), New Zealand National Cyber Security Centre (NCSC), and National Computer Emergency Response Team Tonga (CERT Tonga) highlights the need to strengthen access controls, monitor network activity, and maintain a tested incident response plan to limit the impact of ransomware attacks. 

Threat intelligence from Cyble helps organizations track ransomware activity, monitor dark web exposure, and identify indicators of compromise earlier. 

Schedule a demo with Cyble to see how its threat intelligence platform supports ransomware detection and response. 

References:

• https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/inc-ransom-affiliate-model-enabling-targeting-of-critical-networks 

• https://www.cyber.gov.au/about-us/view-all-content/news/inc-ransom-and-affiliate-network-operating-in-australia-new-zealand-and-the-pacific-island-states 

The post Australia, New Zealand, Tonga, Warn of Rising INC Ransom Attacks Targeting Pacific Networks appeared first on Cyble.

Cyble – ​Read More

Executive Summary

In early February 2026, Cyble Research & Intelligence Labs (CRIL) identified a new Linux malware strain delivered through a loader structure previously associated with ShadowHS activity. While ShadowHS samples deployed post-exploitation tooling, the newly observed payload is operationally different. We have named it ClipXDaemon, an autonomous cryptocurrency clipboard hijacker targeting Linux X11 environments.

At the time of this writing, there is no evidence that ShadowHS and ClipXDaemon originate from the same malware author or campaign. The structural overlap in the loader stems from the use of bincrypter, an open-source shell-script encryption framework hosted on GitHub. Both campaigns appear to have leveraged this public tool independently.

ClipXDaemon differs fundamentally from traditional Linux malware. It contains no command-and-control (C2) logic, performs no beaconing, and requires no remote tasking. Instead, it monetizes victims directly by hijacking cryptocurrency wallet addresses copied in X11 sessions and replacing them in real time with attacker-controlled addresses.

It employs stealth techniques, including process masquerading and Wayland session avoidance, in which the attack chain operates entirely locally, without network communication, infrastructure, or operator interaction after execution, making detection and response significantly more challenging.

The campaign is particularly relevant now, given the growing adoption of Linux among developers, traders, and crypto users, many of whom rely on X11-based GUI environments. This represents an evolution in Linux financial malware: autonomous, C2-less, stealthy, and user-focused.

Key Takeaways

• The previously observed ShadowHS-style loader is reused to deploy a different payload — a Linux X11 cryptocurrency clipboard hijacker.
• The campaign uses a three-stage infection chain:
  • Encrypted loader
  • Memory-resident dropper
  • On-disk ELF clipboard hijacker

• The Dropper is entirely staged in memory via a bincrypter-generated loader that uses AES-256-CBC decryption and gzip decompression.
• The malware avoids modern Wayland sessions and operates exclusively in X11 environments, demonstrating intentional defense evasion.
• Implements stealth techniques including double-fork daemonization, /proc masquerading, and PR_SET_NAME process renaming.
• The payload is a fully autonomous daemon that monitors the clipboard every 200ms and replaces cryptocurrency addresses with attacker-controlled wallets, targeting Bitcoin, Ethereum, Litecoin, Monero, Tron, Dogecoin, Ripple, and TON wallets.
• Encrypted regex is ChaCha20-based, with embedded static keys and 64-byte block decryption, ensuring payload secrecy.
• Payload is autonomous with no communication with external C2 (functions entirely locally), relying only on clipboard replacement for monetization.
• Persistence is achieved via ~/.profile modification.
• The campaign illustrates increasing operational reliance on open-source tooling in modern malware development.

Background & Threat Landscape

The ShadowHS malware family, documented in January 2026, used encrypted shell loaders to execute an in-memory, weaponized hackshell payload targeting server environments and was associated with post-exploitation tooling.

ClipXDaemon reflects a strategic pivot. While the staging wrapper remains structurally similar, the delivered payload is entirely different: an autonomous cryptocurrency clipboard hijacker focused on Linux users.

Both ShadowHS samples and ClipXDaemon leverage the publicly available bincrypter framework to encrypt and wrap shell payloads. However, the reuse of a commodity open-source obfuscation tool does not constitute evidence of actor overlap. This indicates a broader trend where attackers are increasingly weaponizing legitimate open-source utilities to reduce development overhead.

This case illustrates several macro-level shifts in the threat landscape. Linux malware is becoming more specialized, targeting financial workflows directly rather than deploying general-purpose remote access tools.

Operational exposure is minimized by eliminating network communication entirely. Modular reuse of publicly available encryption wrappers allows rapid payload swapping without rebuilding infrastructure.

ClipXDaemon therefore represents both a tactical evolution in Linux clipboard hijacking and a strategic example of open-source tool weaponization in financially motivated campaigns.

Technical Analysis

Bincrypt Obfuscated Loader

The initial loader used in this campaign matches the structural output generated by bincrypter. The wrapper script stores an encrypted payload blob inline, base64-decodes it at runtime, strips non-printable characters, derives AES-256-CBC decryption parameters, decompresses via gzip, and executes the decrypted stage directly from memory. (See Figure 1)

The decryption stub, variable naming conventions (short uppercase variables such as P and S), OpenSSL invocation pattern, and execution via /proc/self/fd align with bincrypter-generated output. When replicated in a controlled environment using bincrypter, the structural characteristics match closely. (See Figure 2)

However, the presence of bincrypter does not imply shared authorship between ShadowHS and ClipXDaemon. Bincrypter is a public, open-source tool. Its reuse reflects convenience and operational efficiency rather than coordinated campaign lineage.

The same loader logic is retained across versions. Differences are confined to the embedded base64 password (P), the salt (S), the encrypted configuration blob (C), the payload offset (R), and the derived AES key.

Component	ShadowHS loader	ClipXDaemon loader
P (base64)	U014VW9KeTh5SGhtSXR2QQo=	SXlFWndTTzBZclRmRzRTbgo=
Decoded Password	SMxUoJy8yHhmItvA	IyEZwSO0YrTfG4Sn
Salt (S)	92KemmzRUsREnkdk	96vN4N7cG87KIHzD
C (encrypted config)	S1A76XhLvaqIQ+7WsT+Euw==	MqxlKG3gEwF0BmQiV63bPQ==
R (offset)	4817	7452
Final AES key	92KemmzRUsREnkdk-SMxUoJy8yHhmItvA	96vN4N7cG87KIHzD-IyEZwSO0YrTfG4Sn

This indicates that the loader functions as a reusable staging framework, with payloads swapped at build time rather than behavioral modification.

In-Memory Dropper Execution

Once the loader decrypts and decompresses an intermediate dropper, it does not write the script to disk. Instead, it executes it directly through a file descriptor under /proc/self/fd. This avoids static inspection of the decrypted stage and minimizes disk artifacts.

Upon execution, the decrypted dropper writes a message to STDOUT for purely cosmetic purposes, thereby disguising itself as legitimate software. (See Figure 3)

Subsequently, it contains an embedded base64-encoded ELF binary, which is decoded & written to a file with a randomized name (between eight and nineteen characters, with a numeric suffix). (See Figure 4)

The ELF binary is dropped at ~/.local/bin/<random_name>. The path selection is deliberate, considering that it resides in userland, requires no elevated privileges, and allows blending with legitimate user-installed binaries. (See Figure 5)

Persistence

After writing the file, the dropper marks it executable, launches it in the background, and appends an execution line to ~/.profile. (See Figure 6)

By modifying ~/.profile, the implant ensures it is executed during future interactive login sessions. This is a user-level persistence mechanism that does not require cron jobs, systemd services, or root access. This indicates that the targeting profile is more consistent with Linux environments than with servers.

Payload Architecture: X11-Dependent Design

The deployed ELF binary is a 64-bit Linux executable dynamically linked against X11 libraries. At the time of writing, it goes undetected by security vendors on VirusTotal. (See Figure 7)

Execution begins with a simple environmental gate: the program checks whether the WAYLAND_DISPLAY environment variable is present.

• If Wayland is detected, execution terminates immediately.
• If Wayland is absent, execution proceeds.

This is done because Wayland’s design prevents global clipboard scraping as X11 allows. By explicitly disabling itself in Wayland sessions, it avoids runtime failure and reduces noise. This indicates that the implant is designed specifically for X11. This environmental awareness indicates familiarity with modern Linux architecture. (See Figure 8)

Daemonization and Process Masquerading

After passing the environment check, the payload performs a double-fork daemonization sequence. It detaches from the controlling terminal, creates a new session, forks again, closes standard file descriptors, changes the working directory to root, and resets the file mode mask. (See Figure 9)

Immediately afterward, it calls prctl(PR_SET_NAME, …), altering its process name to resemble a kernel worker thread — specifically mimicking kworker/0:2-events. It also modifies argv[0] to reinforce this disguise. (See Figure 10)

This technique is designed to reduce suspicion during casual inspection with tools such as ps or top, as kernel worker names are familiar to Linux administrators and are often ignored.

This technique is not intended to defeat forensic examination; rather, it aims at camouflage rather than perfect stealth.

Clipboard Monitoring Loop

Once daemonized, the implant connects to the X server using standard X11 APIs. If a display connection cannot be established, execution halts. If successful, the program enters a continuous polling loop that iterates every 200 milliseconds, retrieving the contents of the CLIPBOARD selection. (See Figure 11)

Clipboard retrieval is implemented using the native X11 selection protocol rather than a shortcut API. The malware resolves the “CLIPBOARD” and “UTF8_STRING” atoms, creates a hidden 1×1 window, and calls XConvertSelection to request clipboard data in UTF-8 format. It then blocks on SelectionNotify events via XNextEvent until the clipboard owner responds.

Once delivered, the data is extracted with XGetWindowProperty, duplicated into process memory, and the temporary window is destroyed. This ensures clean, synchronous acquisition of human-readable clipboard text without visible UI artifacts. (See Figure 12)

The retrieved text is evaluated against a set of regular expressions corresponding to cryptocurrency wallet formats. If a match is detected, the malware transitions from passive monitoring to active hijacking. It claims clipboard ownership using XSetSelectionOwner, again through a hidden window, and waits for SelectionRequest events.

When a paste operation occurs, the implant responds by supplying the attacker-controlled wallet address via XChangeProperty and XSendEvent, gracefully completing the X11 selection handshake. (See Figure 13)

The 200ms polling interval balances responsiveness and resource invisibility. Replacement occurs fast enough to precede typical paste actions while maintaining low CPU usage. The implant does not intercept keystrokes or monitor network traffic; it simply abuses X11’s trust model — reading clipboard contents, matching wallet patterns, and serving malicious replacements at paste time.

Configuration Protection Using ChaCha20

Wallet regex patterns and replacement addresses are not stored in plaintext. They are encrypted in binary using a ChaCha20 stream cipher with a static 256-bit key and a counter. This avoids revealing configuration buffers during static analysis.

At runtime, a static 256-bit key and counter are used to decrypt configuration buffers in memory. Only after decryption are the regular expressions compiled and replacement wallet addresses stored in memory. (See Figure 14)

This prevents trivial extraction using static string analysis but does not protect communications, as no command-and-control channel exists. The cryptographic implementation is functional rather than advanced. It is sufficient to defeat naive inspection but offers limited resistance to dynamic analysis.

Cryptocurrency Targeting

Dynamic instrumentation revealed that the payload matches multiple cryptocurrency wallet formats. Below is an example showing a Monero address match (See Figure 15)

Below are the regex being matched (extracted post-decryption) :

Ethereum:     “^0x[0-9a-fA-F]{40}$”
Monero:          “^[4][0-9AB][1-9A-HJ-NP-Za-km-z]{93}$”
Bitcoin:         “^(bc1|[13])[a-km-zA-HJ-NP-Z1-9]{25,34}$”
Dogecoin:      “^D{1}[5-9A-HJ-NP-U]{1}[1-9A-HJ-NP-Za-km-z]{32}$”
TON:             “^(EQ|UQ)[A-Za-z0-9_-]{46}$”
Litecoin:      “^([LM3]{1}[a-km-zA-HJ-NP-Z1-9]{26,33}||ltc1[a-z0-9]{39,59})$”
Ripple:     “^r[1-9A-HJ-NP-Za-km-z]{25,34}$”
Tron:            “^T[A-Za-z1-9]{33}$”

The implant operates entirely offline, with encrypted replacement addresses hardcoded and static. Upon detection, the clipboard is overwritten with attacker wallet addresses embedded in the binary (in encrypted form). (See Figure 16)

Observed replacement wallets include:

Cryptocurrency	Attacker Wallet Address
Ethereum	0x502010513bf2d2B908A3C33DE5B65314831646e7
Monero	424bEKfpB6C9LkdfNmg61pMEnAitjde8YWFsCP1JXRYhfu4Tp5EdbUBjCYf9kRBYGzWoZqRYMhWfGAm1N5h6wSPg8bSrbB9
Bitcoin	bc1qe8g2rgac5rssdf5jxcyytrs769359ltle3ekle
Dogecoin	DTkSZNdtYDGndq1kRv5Z2SuTxJZ2Ddacjk
TON	(monitored only – NO replacement found)
Litecoin	ltc1q7d2d39ur47rz7mca4ajzam2ep74ccdwvqre6ej
Ripple (XRP)	(monitored only – NO replacement found)
Tron	TBupDdRjUscZhsDWjSvuwdevnj8eBrE1htn

Additional regex patterns indicate monitoring of TON and Ripple wallet formats, although replacement addresses were not observed for those assets.

Absence of Command-and-Control Infrastructure

No network communication was observed during analysis. The binary does not initiate DNS queries, HTTP requests, or socket connections and carries no embedded domains or IP addresses.

This C2-less architecture fundamentally alters the traditional malware kill chain. There is no beaconing stage, no tasking loop, no data exfiltration channel, and no infrastructure to dismantle. Monetization occurs directly at the endpoint when a victim pastes a manipulated wallet address and executes a cryptocurrency transaction.

This model reduces the attacker’s operational risk. Since there are no servers to seize, no traffic to sinkhole, and no indicators derived from network telemetry, the detection strategy must rely on host-based behavioral analysis rather than network security controls.

The campaign illustrates a growing trend: financially motivated malware that eliminates the need for infrastructure. Combined with the reuse of publicly available tools such as bincrypter for payload staging, this approach lowers development costs, accelerates deployment, and complicates attribution.

ClipXDaemon is therefore notable not only for its technical design but for what it represents — the increasing weaponization of open-source tooling and the emergence of autonomous, infrastructure-less financial malware targeting Linux users.

Conclusion

The analysis of ClipXDaemon reflects a meaningful shift in Linux malware tradecraft — not in the sophistication of exploitation, but in operational design. The threat eliminates the need for command-and-control infrastructure entirely, collapsing the traditional kill chain into a localized, self-contained monetization loop.

There are no external beacons, tasking servers, or data exfiltration channels. Revenue generation depends solely on clipboard interception and user transaction behavior.

While ClipXDaemon reuses the same loader framework previously observed in ShadowHS reporting, there is no evidence of convergence in attribution. The shared component – bincrypter- is an openly available obfuscation framework.

Its reuse highlights a broader trend in the threat landscape; adversaries increasingly operationalize legitimate open-source tooling to accelerate development cycles and standardize staging mechanisms. This modular reuse model lowers barriers to entry while complicating campaign clustering and attribution analysis.

ClipXDaemon’s strength lies in precision targeting, environmental awareness, and architectural minimalism. As Linux adoption grows within cryptocurrency and developer communities, financially motivated userland implants such as this are likely to increase in frequency.

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

Our Recommendations

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

From a detection standpoint, this architectural choice significantly reduces conventional visibility. Network-based detections, domain-reputation feeds, and infrastructure takedown strategies are ineffective against implants that never communicate externally. Instead, detection must pivot toward behavioral telemetry within the endpoint. Given the absence of network indicators, defensive strategies must prioritize endpoint visibility and behavioral controls.

Harden Linux Environments

• Where operationally feasible, transition from X11 (permissive model) to Wayland-based sessions. Wayland’s security model restricts global clipboard scraping, thereby reducing this attack surface.
• Restrict execution from user-writable directories such as ~/.local/bin/ where possible through application control policies.

Monitor Userland Persistence

• Audit modifications to ~/.profile, ~/.bashrc, and other user-level autostart mechanisms.
• Establish baselines for legitimate binaries within ~/.local/bin/ and alert on newly created executables.

Detect Process Masquerading

• Identify processes with kernel-thread naming conventions (e.g., kworker/*) running under non-root user contexts.
• Correlate prctl(PR_SET_NAME) modifications with suspicious execution ancestry.

Instrument X11 API Abuse

• Monitor for abnormal or repetitive use of:
  • XConvertSelection
  • XSetSelectionOwner
  • XGetWindowProperty

• High-frequency clipboard polling (e.g., ~200ms intervals) originating from background daemons should be investigated.

Implement Behavioral EDR Controls

• Alert on execution of ELF binaries dropped from interpreted shell scripts via /proc/self/fd.
• Detect double-fork daemonization sequences initiated from user shell contexts.
• Flag base64-decoded ELF writes followed by immediate execution.

User Awareness Controls

• Encourage manual verification of cryptocurrency addresses before transaction confirmation.
• Where possible, utilize hardware wallet confirmation mechanisms that display recipient addresses independently of the host system.

Organizations operating Linux environments in cryptocurrency-sensitive roles should consider clipboard manipulation threats as part of their baseline threat model.

MITRE ATT&CK® Techniques

Tactic	Technique ID	Procedure
Execution	Command and Scripting Interpreter (T1059.004)	The initial loader runs via a shell wrapper generated with bincrypter, which decrypts and launches the embedded dropper.
Defense Evasion	Obfuscated Files or Information (T1027)	The loader uses AES-256-CBC encryption and gzip compression to conceal payload contents. The ELF configuration is further encrypted with ChaCha20.
Defense Evasion	Reflective Code Loading (T1620)	The intermediate dropper executes directly from /proc/self/fd, avoiding on-disk script artifacts.
Persistence	Shell Configuration Modification (T1547)	The dropper adds execution of the ELF payload to ~/.profile, enabling persistence upon user login.
Discovery	System Information Discovery (T1082)	The payload checks for the presence of Wayland (WAYLAND_DISPLAY) to determine whether execution is viable.
Defense Evasion	Masquerading (T1036)	The payload renames itself using prctl(PR_SET_NAME) to mimic kernel worker threads.
Credential Access / Collection	Clipboard Data (T1115)	The payload abuses X11 selection APIs to retrieve clipboard contents and monitor cryptocurrency wallet patterns.
Impact	Data Manipulation (T1565)	The malware modifies clipboard data in transit by replacing legitimate wallet addresses with attacker-controlled addresses.

Indicators of Compromise (IOCs)

Indicators	Indicator Type	Description
87ab42a2a58479cf17e5ce1b2a2e8f915d539899993848e5db679c218f0e7287	SHA-256	Bincrypter loader script
23099eea9c4f85ff62a4f43634d431bbed0bf6b039a3f228b1c047f1c2f0cd11	SHA-256	Dropper Script
b6bb28160532400eafad532842e4ba9add6d6bbba4f7e7c85e3dbb650369eb00	SHA-256	ClipXDaemon ELF binary
0x502010513bf2d2B908A3C33DE5B65314831646e7	Ethereum	Attacker Wallet Address
424bEKfpB6C9LkdfNmg61pMEnAitjde8YWFsCP1JXRYhfu4Tp5EdbUBjCYf9kRBYGzWoZqRYMhWfGAm1N5h6wSPg8bSrbB9	Monero	Attacker Wallet Address
bc1qe8g2rgac5rssdf5jxcyytrs769359ltle3ekle	Bitcoin	Attacker Wallet Address
DTkSZNdtYDGndq1kRv5Z2SuTxJZ2Ddacjk	Dogecoin	Attacker Wallet Address
ltc1q7d2d39ur47rz7mca4ajzam2ep74ccdwvqre6ej	Litecoin	Attacker Wallet Address
TBupDdRjUscZhsDWjSvuwdevnj8eBrE1ht	Tron	Attacker Wallet Address

The post ClipXDaemon: Autonomous X11 Clipboard Hijacker Delivered via Bincrypter-Based Loader appeared first on Cyble.

Cyble – ​Read More

• Cisco Talos is disclosing UAT-9244, who we assess with high confidence is a China-nexus advanced persistent threat (APT) actor closely associated with Famous Sparrow.
• Since 2024, UAT-9244 has targeted critical telecommunications infrastructure, including Windows and Linux-based endpoints and edge devices in South America, proliferating access via three malware implants.
• The first backdoor, “TernDoor,” is a new variation of the previously disclosed, Windows-based, CrowDoor malware.
• Talos also discovered that UAT-9244 uses “PeerTime,” an ELF-based backdoor that uses the BitTorrent protocol to conduct malicious operations on an infected system.
• UAT-9244’s third implant is a brute force scanner, which Talos tracks as “BruteEntry.” BruteEntry is typically installed on network edge devices, essentially converting them into mass-scanning proxy nodes, also known as Operational Relay Boxes (ORBs) that attempt to brute force into SSH, Postgres, and Tomcat servers.

---

Introducing TernDoor: A variant of CrowDoor

UAT-9244 used dynamic-link library (DLL) side-loading to activate multiple stages of their infection chain. The actor executed “wsprint[.]exe”, a benign executable that loaded the malicious DLL-based loader “BugSplatRc64[.]dll”. The DLL reads a data file named “WSPrint[.]dll” from disk, decrypts its contents, and executes them in memory to activate TernDoor, the final payload.

TernDoor is a variant of CrowDoor, a backdoor deployed in recent intrusions linked to China-nexus APTs such as FamousSparrow and Earth Estries. CrowDoor is a variant of SparrowDoor, another backdoor attributed to FamousSparrow. CrowDoor has also been observed in previous Tropic Trooper intrusions,  indicating a close operational relationship with FamousSparrow. Based on the overlap in tooling; tactics, techniques, and procedures (TTPs); and victimology, we assess with high confidence that UAT-9244 closely overlaps with FamousSparrow and Tropic Trooper.

Although UAT-9244 and Salt Typhoon both target telecommunications service providers, Talos has not been able to verify or establish a solid connection between the two clusters.

The DLL-based loader

The DLL-based loader, “BugSplatRc64.dll”, will load the “WSPrint.dll” file from the current directory, which will be decoded using the key “qwiozpVngruhg123”.

The decoded shellcode is position-independent and decodes and decompresses the final payload. The final payload is the TernDoor implant.

TernDoor

The final shellcode consists of the TernDoor backdoor. TernDoor is a variant of CrowDoor, actively developed and used by UAT-9244 since at least November 2024. TernDoor deviates from CrowDoor in the following aspects:

• TernDoor consists of command codes that are different from previously disclosed variants of CrowDoor.
• The TernDoor shellcode also consists of an embedded Windows driver (SYS file). The driver is encrypted using AES in the shellcode. The driver is used to suspend, resume, and terminate processes.

Persistence

The TernDoor infection chain is persisted on the system using either a scheduled task or the Registry Run key.

The scheduled task is named “WSPrint” and created using the command:

schtasks /create /tn WSPrint /tr "C:ProgramDataWSPrintWSPrint.exe" /ru "SYSTEM" /sc onstart /F

Furthermore, TernDoor modifies the following task-related registry keys to hide the task:

• Deletes HKLMSOFTWAREMicrosoftWindows NTCurrentVersionScheduleTaskCacheTreeWSPrint | SD
• Modifies HKLMSOFTWAREMicrosoftWindows NTCurrentVersionScheduleTaskCacheTreeWSPrint | Index = from 1 to 0

A Registry Run key may also be set to run the executable on user login:

HKCUSoftwareMicrosoftWindowsCurrentVersionRun | Default = C:ProgramDataWSPrintWSPrint.exe

Command line switch

Unlike CrowDoor, TernDoor only supports one command line switch: “-u”, passed to WSPrint.exe. This is the switch for uninstalling the malware from the system and it deletes all malware files from the operating directory, as well as terminates malicious processes.

Decoding the configuration

Like previous variants of CrowDoor, TernDoor also checks to ensure it has been injected into “msiexec[.]exe”. The implant decodes its configuration that can specify the following information:

• Command and control (C2) IP address
• Number of tries to connect to the C2
• C2 port number
• User-Agent to use while connecting to C2 (if applicable)

TernDoor functionality

TernDoor’s capabilities resemble those of previously disclosed CrowDoor samples:

• Communicates with the C2 IP address
• Creates processes and runs arbitrary commands via remote shell and independently
• Reads and writes files
• Collects system information such as computer and user name, IP address information, and OS bitness
• Uninstalls itself from the infected system
• Deploys the accompanying driver to hide malicious components and perform process management

The accompanying Windows driver, WSPrint.sys, is dropped to disk and then activated using a windows service:

 The driver creates a device named “\Device\VMTool” and symbolically links it to “\DosDevices\VMTool”. It can terminate, suspend, or resume processes specified by TernDoor — likely a means of evasion.

TernDoor infrastructure

All the C2 IP addresses discovered by Talos were associated with the following SSL certificate on port 443:

SSL_fingerprint_sha256= 0c7e36683a100a96f695a952cf07052af9a47f5898e1078311fd58c5fdbdecc8
SSL_fingerprint_SHA1= 2b170a6d90fceba72aba3c7bc5c40b9725f43788
Data:
Version: V3
Serial Number: 1
Thumbprint: 2b170a6d90fceba72aba3c7bc5c40b9725f43788
 
Signature Algorithm:
Issuer: C=US ST=Some-State O=Internet Widgits Pty Ltd CN=8.8.8.8
Validity
Not Before: 2022-09-04 12:54:51
Not After: 2023-09-04 12:54:51
Subject: C=US ST=Some-State O=Internet Widgits Pty Ltd CN=8.8.8.8

Pivoting off this certificate, Talos found an additional 18 IPs likely being used by UAT-9244. This list is provided in the indicators of compromise (IOCs) section.

One of the DLL-based loaders was also hosted on the IP “212.11.64[.]105”. On this server, we discovered a set of shell scripts and an accompanying malware family we track as “PeerTime.”

PeerTime: UAT-9244’s peer-to-peer (P2P) backdoor

PeerTime is an ELF based backdoor that is compiled for a variety of architectures such as ARM, AARCH, PPC, MIPS etc., indicating that UAT-9244 can use it to infect a variety of embedded systems.

PeerTime is deployed through a shellscript that downloads the PeerTime loader ELF binary and an instrumentor binary.

The instrumentor ELF binary will check for the presence of docker on the compromised host using the commands docker and docker –q.

If docker is found, then the PeerTime loader is executed using:

docker <path_of_PeerTime_loader_ELF>

The instrumentor consists of debug strings in Simplified Chinese, indicating that it is a custom binary created and deployed by Chinese-speaking threat actors:

获取当前程序路径错误:     //Error retrieving current program path:
删除当前程序错误:                // Error deleting current program:

PeerTime consists of a loader that will decrypt and decompress the final PeerTime ELF payload and run it in memory. The PeerTime loader has the ability to rename its process to a benign process to evade detection.

PeerTime uses the BitTorrent protocol to obtain C2 information, download files from its peers, and execute them on the infected host. The payloads are written to disk and copied to the specified locations using BusyBox. As of now, PeerTime consists of two versions: one written in C/C++ and a newer version written in Rust.

PeerTime is also known as “angrypeer” and can be tracked in VirusTotal using the “malware_config:angrypeer” query. Malware configurations in VirusTotal are identified using Mandiant’s/GTIG’s Backscatter tool.

Setting up ORBs via BruteEntry

Infrastructure used by UAT-9244 also hosts another set of shell scripts and payloads designed to establish compromised Linux based systems including edge devices as operational relay boxes (ORBs) that scan and brute force Tomcat, Postgres, and SSH servers.

The shell script will download two components:

• An instrumentor and daemon process that activates the actual brute forcer
• The actual brute forcer (named BruteEntry) that obtains target IPs from the C2 server and scans the IPs

The instrumentor binary

The instrumentor binary is an ELF file written in GoLang. It checks if the BruteEntry is already running on the system using “pgrep”:

pgrep <path_to_BruteEntry>

And then starts the brute forcer agent:

./<path_to_BruteEntry>

BruteEntry

BruteEntry is also written in GoLang and begins by registering with the C2 server by providing it with the infected system’s IP address and computer name:

{“ip”:“value”, “hostname”:“value”}

 The C2 responds with a JSON that assigns an agent_id to the infected host:

{“agent_id”:“value”, “server”:“value”}

where “server” = version string of BruteEntry such as “brute-force-server-v1.0”

 BruteEntry will then ask the C2 for tasks to perform by sending a GET request to the C2 at the URI, where limit=1000 is the maximum number of vulnerable IPs to scan:

/tasks/<agent_id>?limit=1000

The C2 responds with a JSON that consists of “tasks” containing the list of IPs to brute force:

{"tasks":[
{"id":,"target":":","type":""},
{"id":,"target":":","type":""},
. . . . .
] }

 The “type” field in the json defines the type of scan to conduct — either “tomcat”,“postgres”, or “ssh”.

The agent will then use a set of embedded credentials to attempt to brute force into either a Tomcat server application at the URL “https[://]<IP>:<Port>/manager/html”, or will brute force into a Postgres instance, either defined in the JSON (<IP><Port>) from the C2 or using the port 5432 if no port is specified.

Any successful logins are then POSTED back to the C2:

{"batch":[
{"task_id":<task_id>,"success":<true/false>,"note":" <notes on the task>"},
{"task_id":<task_id>,"success":<true/false>,"note":" <notes on the task>"},
......
]}

 In this instance, “success” indicates if the brute force was successful (true or false), and “notes” provides specific information on whether the brute force was successful. If the login failed, the note reads “All credentials tried.” If it succeeded, the note reads “Cracked by agent <agent_id> | Version <agent_version>”.

Coverage

The following ClamAV signatures detect and block this threat:

• Win.Loader.PeerTime
• Win.Malware.TernDoor
• Unix.Malware.BruteEntry
• Txt.Malware.PeerTime
• Unix.Malware.PeerTime

The following SNORT® rules (SIDs) detect and block this threat: 65551

IOCs

TernDoor Loader DLL

711d9427ee43bc2186b9124f31cba2db5f54ec9a0d56dc2948e1a4377bada289
3c098a687947938e36ab34b9f09a11ebd82d50089cbfe6e237d810faa729f8ff
f36913607356a32ea106103387105c635fa923f8ed98ad0194b66ec79e379a02

 Encoded TernDoor payload

A5e413456ce9fc60bb44d442b72546e9e4118a61894fbe4b5c56e4dfad6055e3
075b20a21ea6a0d2201a12a049f332ecc61348fc0ad3cfee038c6ad6aa44e744
1f5635a512a923e98a90cdc1b2fb988a2da78706e07e419dae9e1a54dd4d682b

Windows driver

2d2ca7d21310b14f5f5641bbf4a9ff4c3e566b1fbbd370034c6844cedc8f0538

UAT-9244 C2 IPs used by TernDoor

154[.]205[.]154[.]82:443
207[.]148[.]121[.]95:443
207[.]148[.]120[.]52:443
212[.]11[.]64[.]105

Suspected UAT-9244 IPs

149[.]28[.]25[.]33
154[.]205[.]154[.]194
154[.]205[.]154[.]65
154[.]205[.]154[.]70
154[.]223[.]21[.]130
154[.]223[.]21[.]194
158[.]247[.]238[.]240
216[.]238[.]112[.]222
216[.]238[.]123[.]242
216[.]238[.]94[.]37
38[.]54[.]125[.]134
38[.]60[.]199[.]34
45[.]32[.]106[.]94
45[.]77[.]34[.]194
45[.]77[.]41[.]141
47[.]76[.]100[.]159
64[.]190[.]113[.]170
64[.]95[.]10[.]253

PeerTime installation script

ebcb2691b7c92cdf2b2ff5e2d753abeea8cb325c16596cd839e6bd147f80e38a
00735a8a50d2856c11150ef1e29c05acebce7ad3edad00e37c7f043aacb46330
74fbc8360d4c95d64d7acaa4d18943dce2d41f91d080b0b5e435d8bce52861a5
babc81fc9c998e9dc4ab545f0e112e34d2641e1333bc81aaa131abd061a5b604
e34c9159e6e78c59518a14c5b96bddfee094b684f99d4f69b13371284a014e87
2c3f2261b00ea45e25eb4e9de2b7ff8e41f311c0b3d986461f834022c08b3b99
3fcced9332301ff70b20c98c9434c858400013d659afa6bb5149cffb0206357d
a313f76fca50fff1bcd6f2c6cbc1268985f8c0a3a05fe7f43c4fc0ac3aff84dc
03eac9eb7f4b4bc494ef0496ee23cabbf38f883896838ed813741d8f64ac9fde
17652d7bb5fe0454023db4fc7f608df0dbe6af237be31258e16ba52f0e895e26
74d1a678bdc4bb9f33321e94e3bd1bc1740472ed734231fc46af720072ecb77e

PeerTime instrumentor binary

c9fc2af30f769d856b88b3051f19fdb663b3e0a0916279df9bbcba93c6a110c9

PeerTime malware

34d64b3cd9430e85edefcb883973a086dd5de9917e05fabec89b1f4ab9627e91
1cedf01dd4b7e50181d0e781825c66957b862941395d77c8bd7705114f319c80
bfc35f12d00fa4b40c5fbce9e37d704e12a52262709bcbdf09f97890bc40cad5
f3e899789b56429f483e5096e1f473335024f1f763e2d428132338e30352b89e
6ec070457d1f6f239cb02c5e1576a3660cca98f3a07eec6e4e107f698d7fe555
15d937803f90c2b9e277ff94d3e98ff30015ecc7f4623a158e3c98861e5cb278
7b70cd956f082b1029d02b4cb7608893f2de7fa9c500d7d7febdd0f745ac3cb6
d78b3c6df8f3756a7e310cf7435fdba201dd03ec9f97420a0db683489a01a7c9
3fcadde4b414a18b2fed56c1ec59d97977123615fbbf411a1c78425445a6e71c
3d9fbfc2c056eac857ba54e5ed134aa45a4b8322ee9f9353ba32e5b2ca71b0e3
c9a42423ef08bd7f183915780d39530eba5e4e25968c51965ff8bb3026965a28
38eeaa4eaad72feb3f8e6993565fcc548d8e7bb93642590f00fa24aacc0e2862
56bead2933e91366e4a0d5761daf5b238a7f2c22e597664ef67b3ecae20ab326
6a2d23cc8746a83e9a3b974788fce0e414706b8e75ff390426dd7e10b19967b3
9a7225c17e4bad3ffe7f080530d36f4f8aca5c116b913caa91ab9b0cee85638e
870e791af14caaf395c56028176a9c3f4c1ff0318ef3112d57ecd3d4a1be2ef9

PeerTime remote locations

185[.]196[.]10[.]247
xtibh[.]com
xcit76[.]com

PeerTime C2s

bloopencil[.]net
185[.]196[.]10[.]38

BruteEntry installation script

1fcdd5a417db31e5e07d32cecfa69e53f0dce95b7130ad9c03b92249f001801d

BruteEntry instrumentor binary

66ce42258062e902bd7f9e90ad5453a901cfc424f0ea497c4d14f063f3acd329
d5eb979cb8a72706bfa591fa57d4ebf7d13cecdc9377b0192375e2f570f796df

BruteEntry agent

66adeedfb739774fcc09aa7426c8fad29f8047ab4caee8040d07c0e84d011611
66bdce93de3b02cf9cdadad18ca1504ac83e379a752d51f60deae6dcbafe4e31

BruteEntry infrastructure

212[.]11[.]64[.]105
185[.]196[.]10[.]247

Additional malicious scripts

023467e236a95d5f0e62e26445d430d749c59312f66cf136e6e2c2d526c46ba1
f8066833e47814793d8c58743622b051070dac09cb010c323970c81b59260f84
06b23d84fd7afd525dfd7860ebd561dcdd72ccbeb51981d5d9a75acf068d0a2a

Cisco Talos Blog – ​Read More

In 2022, we dived deep into an attack method called browser-in-the-browser — originally developed by the cybersecurity researcher known as mr.d0x. Back then, no actual examples existed of this model being used in the wild. Fast-forward four years, and browser-in-the-browser attacks have graduated from the theoretical to the real: attackers are now using them in the field. In this post, we revisit what exactly a browser-in-the-browser attack is, show how hackers are deploying it, and, most importantly, explain how to keep yourself from becoming its next victim.

What is a browser-in-the-browser (BitB) attack?

For starters, let’s refresh our memories on what mr.d0x actually cooked up. The core of the attack stems from his observation of just how advanced modern web development tools — HTML, CSS, JavaScript, and the like — have become. It’s this realization that inspired the researcher to come up with a particularly elaborate phishing model.

A browser-in-the-browser attack is a sophisticated form of phishing that uses web design to craft fraudulent websites imitating login windows for well-known services like Microsoft, Google, Facebook, or Apple that look just like the real thing. The researcher’s concept involves an attacker building a legitimate-looking site to lure in victims. Once there, users can’t leave comments or make purchases unless they “sign in” first.

Signing in seems easy enough: just click the Sign in with {popular service name} button. And this is where things get interesting: instead of a genuine authentication page provided by the legitimate service, the user gets a fake form rendered inside the malicious site, looking exactly like… a browser pop-up. Furthermore, the address bar in the pop-up, also rendered by the attackers, displays a perfectly legitimate URL. Even a close inspection won’t reveal the trick.

From there, the unsuspecting user enters their credentials for Microsoft, Google, Facebook, or Apple into this rendered window, and those details go straight to the cybercriminals. For a while this scheme remained a theoretical experiment by the security researcher. Now — real-world attackers have added it to their arsenals.

Facebook credential theft

Attackers have put their own spin on mr.d0x’s original concept: recent browser-in-the-browser hits have been kicking off with emails designed to alarm recipients. For instance, one phishing campaign posed as a law firm informing the user they’d committed a copyright violation by posting something on Facebook. The message included a credible-looking link allegedly to the offending post.

Interestingly, to lower the victim’s guard, clicking the link didn’t immediately open a fake Facebook login page. Instead, they were first greeted by a bogus Meta CAPTCHA. Only after passing it was the victim presented with the fake authentication pop-up.

Naturally, the fake Facebook login page followed mr.d0x’s blueprint: it was built entirely with web design tools to harvest the victim’s credentials. Meanwhile, the URL displayed in the forged address bar pointed to the real Facebook site — www.facebook.com.

How to avoid becoming a victim

The fact that scammers are now deploying browser-in-the-browser attacks just goes to show that their bag of tricks is constantly evolving. But don’t despair — there’s a way to tell if a login window is legit. A password manager is your friend here, which, among other things, acts as a reliable security litmus test for any website.

That’s because when it comes to auto-filling credentials, a password manager looks at the actual URL, not what the address bar appears to show, or what the page itself looks like. Unlike a human user, a password manager can’t be fooled with browser-in-the-browser tactics, or any other tricks, like domains having a slightly different address (typosquatting) or phishing forms buried in ads and pop-ups. There’s a simple rule: if your password manager offers to auto-fill your login and password, you’re on a website you’ve previously saved credentials for. If it stays silent, something’s fishy.

Beyond that, following our time-tested advice will help you defend against various phishing methods, or at least minimize the fallout if an attack succeeds:

• Enable two-factor authentication (2FA) for every account that supports it. Ideally, use one-time codes generated by a dedicated authenticator app as your second factor. This helps you dodge phishing schemes designed to intercept confirmation codes sent via SMS, messaging apps, or email. You can read more about one-time-code 2FA in our dedicated post.
• Use passkeys. The option to sign in with this method can also serve as a signal that you’re on a legitimate site. You can learn all about what passkeys are and how to start using them in our deep dive into the technology.
• Set unique, complex passwords for all your accounts. Whatever you do, never reuse the same password across different accounts. We recently covered what makes a password truly strong on our blog. To generate unique combinations — without needing to remember them — Kaspersky Password Manager is your best bet. As an added bonus, it can also generate one-time codes for two-factor authentication, store your passkeys, and synchronize your passwords and files across your various devices.

Finally, this post serves as yet another reminder that theoretical attacks described by cybersecurity researchers often find their way out into the wild. So, keep an eye on our blog, and subscribe to our Telegram channel to stay up to speed on the latest threats to your digital security and how to shut them down.

Read about other inventive phishing techniques scammers are using day in day out:

• Phishing and spam: the wildest campaigns of 2025
• What happens to data stolen using phishing?
• How phishers and scammers use AI
• Turnkey phishing
• Progressive phishing: how PWAs can be used to steal passwords

Kaspersky official blog – ​Read More