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

The geopolitical landscape of the Middle East has entered one of its most volatile phases in decades. On February 28, 2026, tensions that had been simmering for years erupted into a full‑blown conflict involving the Islamic Republic of Iran, the United States, and Israel. A confluence of diplomatic stalemate, military posturing, and covert cyber preparations set the stage for what would evolve from a localized confrontation into an expansive, multi‑domain campaign.  

The conflict’s opening salvo — codenamed Operation Epic Fury by the US and Operation Roaring Lion by Israel — was not just a conventional military assault. It was a synchronized hybrid offensive in which cyber operations were integrated as a co‑equal domain with kinetic strikes, psychological messaging, and information warfare. Over the course of the first 72 hours, from February 28 to March 3, kinetic blows and digital disruptions merged in ways that revealed both the strengths and vulnerabilities of actors across the region.  

Throughout this critical period, Cyble Research and Intelligence Labs (CRIL) has been meticulously tracking the movements, attacks, claims, and associated cyber activity between Iran, Israel, and the US, providing real‑time insights into both the kinetic strikes and the evolving threat landscape.  

Prelude to Conflict: Buildup and Diplomatic Gridlock 

In the days leading up to February 28, the Middle East witnessed a massive US military buildup, the largest since the 2003 Iraq invasion. Aircraft carriers, fighter wings, and intelligence assets positioned themselves within striking range of Iran’s borders. At the same time, indirect nuclear negotiations in Geneva appeared, momentarily, to offer a diplomatic pathway, with Iran publicly agreeing to halt enrichment stockpiling under International Atomic Energy Agency (IAEA) supervision. However, distrust and strategic imperatives among the US, Israel, and Tehran rendered the diplomatic exercise insufficient to prevent escalation.  

Day 1: February 28 — Operation Epic Fury 

At approximately 06:27 GMT, the first concerted wave of strikes hit Iran. US‑Israeli forces began a broad assault across more than two dozen provinces, targeting nuclear facilities, IRGC command centers, ballistic missile launchers, and secure compounds tied to the Iranian leadership. The offensive reportedly included the targeted killing of Supreme Leader Ayatollah Ali Khamenei, a moment that marked a profound turning point in the conflict.  

What set the opening apart from traditional air campaigns was its immediate cyber component. For the first time on such a scale, network disruption was planned to coincide with a kinetic impact. Independent monitors observed Iranian internet connectivity collapse to roughly 1–4% of normal levels as cyberattacks crippled state media, government digital services, and military communications. 

Popular local services, including widely used mobile applications and prayer tools, were reportedly compromised to sow confusion and prompt defections, while defaced state news sites delivered messages contradicting official Iranian narratives.  

Before the current situation, MuddyWater, long associated with Iran‑linked cyber campaigns, remained a critical piece of the pre‑existing threat landscape. Alongside other advanced persistent threat (APT) groups — such as APT42 (Charming Kitten), Prince of Persia / Infy, UNC6446, and CRESCENTHARVEST — these campaigns had already been active before February 28, conducting phishing, exploitation of public servers, and information theft targeting Israeli, US, and regional networks.  

While Iran’s domestic internet infrastructure faltered, the US‑Israeli offensive extended psychological operations into Israeli territory. Threatening messages referencing national ID numbers and fuel shortages arrived in civilians’ inboxes, and misinformation campaigns amplified anxieties even as authorities worked to blunt digital interference. 

Day 2: March 1 — Retaliation and the Surge of Hacktivism 

Iran’s kinetic retaliation was swift and forceful. From March 1 onward, waves of ballistic missiles and drones launched at Israel, Gulf Cooperation Council (GCC) states, and US military bases reinforced that Tehran’s response would not be limited to symbolic posturing. The UAE alone intercepted hundreds of projectiles, resulting in civilian casualties and infrastructure damage, including at Dubai’s international airport and an AWS cloud data center within its mec1‑az2 availability zone.  

On the cyber front, March 1 started the dramatic expansion of hacktivist activity across the region. More than 70 groups — spanning ideological spectrums and even blending pro‑Iranian and pro‑Russian motivations — activated operations in parallel with state responses. An Electronic Operations Room organized by Iraqi‑aligned hackers, such as Cyber Islamic Resistance / Team 313 began orchestrating distributed denial‑of‑service (DDoS) attacks, website defacements, and theft of credentials across national government portals and key infrastructure systems in Turkey, Poland, and GCC states. 

One of the most technically significant artifacts of March 1 was a malicious RedAlert APK observed by Unit 42 analysts. Designed to mimic Israel’s official missile alert app, this payload was distributed via Hebrew‑language SMS links. Once installed, it collected sensitive device and user information — contacts, SMS logs, IMEI numbers, and email credentials — with encrypted exfiltration mechanisms and anti‑analysis protections, providing a rare glimpse of tradecraft resembling state‑level cyber operations at a time when Iranian domestic internet access was severely limited.  

Beyond MuddyWater and other established APTs, opportunistic cybercriminals exploited the chaos through social engineering campaigns in the UAE.  

Day 3: March 2–3 — Strikes, Blackouts, and Enduring Hybrid Threats 

The kinetic campaign broadened on March 2 with the destruction of the IRGC’s Malek‑Ashtar headquarters in Tehran. By March 3, Israeli forces had struck Iran’s state broadcaster, further constraining Tehran’s ability to manage domestic information and cyber operations. The extended internet blackout — persisting well into the third day — continued to isolate Iranian networks, allowing external campaigns to operate with limited interference.  

Several digital fronts emerged during this period: 

• Hacktivist and Propaganda Operations: Groups such as Handala Hack Team claimed exfiltration of terabytes of financial data; others like DieNet and OverFlame targeted GCC critical infrastructure portals and governmental systems in coordinated disruptive campaigns. 

• Pro‑Russian Opportunistic Convergence: Entities, including NoName057(16) and Russian Legion, shifted their focus from Ukraine‑related operations to anti‑Israel actions supportive of Iran, albeit with mixed credibility. 

• Cybercrime Opportunism: The blend of hacktivism and ransomware was exemplified by groups like INC Ransomware, which targeted industrial entities and combined extortion‑style tactics with ideological messaging. 

Throughout March 1–3, analysts noted that most observed cyber activity fell into the realm of DDoS attacks, exposed CCTV feeds, and information operations rather than destructive intrusions into industrial control systems — although unverified claims of SCADA manipulation circulated widely in pro‑Iranian forums.  

Broader Regional and Strategic Implications 

The first 72 hours of Operation Epic Fury reveal several critical insights about modern conflict dynamics in the Middle East: 

1. Cyber as a Co‑Equal Domain: Cyber operations were planned and executed in lockstep with kinetic strikes, demonstrating that modern warfare no longer segregates digital and physical arenas. 

2. Hacktivist Amplification: With over 70 groups active within days, the hacktivist ecosystem has become a force multiplier of psychological and disruptive operations that can transcend national borders. 

3. Opportunistic Exploitation: As seen in social engineering and ransomware campaigns, broader conflict can catalyze financially motivated cybercrime that piggybacks on geopolitical uncertainty. 

These dynamics suggest that defenders in the region — from government CERTs to multinational enterprises — must maintain heightened vigilance across both technical and psychological threat vectors, with particular emphasis on credential harvesting, DDoS mitigation, and proactive monitoring of emerging malware campaigns. 

Conclusion 

The events from February 28 to March 3 highlight that the US‑Israeli offensive against Iran — launched as Operation Epic Fury — is not merely a military confrontation but a hybrid engagement across kinetic, cyber, and informational domains. While Iran’s internet infrastructure remains degraded, sophisticated pre‑positioned capabilities could still be activated in the coming weeks, particularly if connectivity is restored. Meanwhile, the hacktivist theatre continues to grow in both volume and geographic scope, even as the technical sophistication of most operations remains limited. 

In this environment, security practitioners and strategic planners must be prepared for adaptive threat behavior that blends political motivations with opportunistic cybercrime — a reality that defines the 21st‑century battlespace in the Middle East and beyond. 

References: 

• https://unit42.paloaltonetworks.com/iranian-cyberattacks-2026/ 

• https://www.sophos.com/en-us/blog/cyber-advisory-increased-cyber-risk-amid-u-s-israel-iran-escalation 

• https://www.ncsc.gov.uk/news/ncsc-advises-uk-organisations-take-action-following-conflict-in-middle-east 

• https://www.cybersecuritydive.com/news/iran-hackers-threat-level-us-allies/813494/ 

• https://flashpoint.io/blog/escalation-in-the-middle-east-operation-epic-fury/ 

• https://www.anomali.com/blog/cyber-threat-briefing-iran-retaliatory-posture 

• https://blog.checkpoint.com/research/what-defenders-need-to-know-about-irans-cyber-capabilities/ 

• https://www.khaleejtimes.com/uae/dubai-police-warn-scammers-impersonating-government-officials 

The post Middle East on the Brink: Iran-US-Israel Hostilities Trigger Cyber-Kinetic Conflict appeared first on Cyble.

Cyble – ​Read More

Can a computer be infected with malware simply by processing a photo — particularly if that computer is a Mac, which many still believe (wrongly) to be inherently resistant to malware? As it turns out, the answer is yes — if you’re using a vulnerable version of ExifTool or one of the many apps built based on it. ExifTool is a ubiquitous open-source solution for reading, writing, and editing image metadata. It’s the go-to tool for photographers and digital archivists, and is widely used in data analytics, digital forensics, and investigative journalism.

Our GReAT experts discovered a critical vulnerability — tracked as CVE-2026-3102 — which is triggered during the processing of malicious image files containing embedded shell commands within their metadata. When a vulnerable version of ExifTool on macOS processes such a file, the command is executed. This allows a threat actor to perform unauthorized actions in the system, such as downloading and executing a payload from a remote server. In this post, we break down how this exploit works, provide actionable defense recommendations, and explain how to verify if your system is vulnerable.

What is ExifTool?

ExifTool is a free, open-source application addressing a niche but critical requirement: it extracts metadata from files, and enables the processing of both that data and the files themselves. Metadata is the information embedded within most modern file formats that describes or supplements the main content of a file. For instance, in a music track, metadata includes the artist’s name, song title, genre, release year, album cover art, and so on. For photographs, metadata typically consists of the date and time of a shot, GPS coordinates, ISO and shutter speed settings, and the camera make and model. Even office documents store metadata, such as the author’s name, total editing time, and the original creation date.

ExifTool is the industry leader in terms of the sheer volume of supported file formats, as well as the depth, accuracy, and versatility of its processing capabilities. Common use cases include:

• Adjusting dates if they’re incorrectly recorded in the source files
• Moving metadata between different file formats (from JPG to PNG and so on)
• Pulling preview thumbnails from professional RAW formats (such as 3FR, ARW, or CR3)
• Retrieving data from niche formats, including FLIR thermal imagery, LYTRO light-field photos, and DICOM medical imaging
• Renaming photo/video (etc.) files based on the time of actual shooting, and synchronizing the file creation time and date accordingly
• Embedding GPS coordinates into a file by syncing it with a separately stored GPS track log, or adding the name of the nearest populated area

The list goes on and on. ExifTool is available both as a standalone command-line application and an open-source library, meaning its code often runs under the hood of powerful, multi-purpose tools; examples include photo organization systems like Exif Photoworker and MetaScope, or image processing automation tools like ImageIngester. In large digital libraries, publishing houses, and image analytics firms, ExifTool is frequently used in automated mode, triggered by internal enterprise applications and custom scripts.

How CVE-2026-3102 works

To exploit this vulnerability, an attacker must craft an image file in a certain way. While the image itself can be anything, the exploit lies in the metadata — specifically the DateTimeOriginal field (date and time of creation), which must be recorded in an invalid format. In addition to the date and time, this field must contain malicious shell commands. Due to the specific way ExifTool handles data on macOS, these commands will execute only if two conditions are met:

• The application or library is running on macOS
• The -n (or –printConv) flag is enabled. This mode outputs machine-readable data without additional processing, as is. For example, in -n mode, camera orientation data is output simply, inexplicably, as “six”, whereas with additional processing, it becomes the more human-readable “Rotated 90 CW”. This “human-readability” prevents the vulnerability from being exploited

A rare but by no means fantastical scenario for a targeted attack would look like this: a forensics laboratory, a media editorial office, or a large organization that processes legal or medical documentation receives a digital document of interest. This can be a sensational photo or a legal claim — the bait depends on the victim’s line of work. All files entering the company undergo sorting and cataloging via a digital asset management (DAM) system. In large companies, this may be automated; individuals and small firms run the required software manually. In either case, the ExifTool library must be used under the hood of this software. When processing the date of the malicious photo, the computer where the processing occurs is infected with a Trojan or an infostealer, which is subsequently capable of stealing all valuable data stored on the attacked device. Meanwhile, the victim could easily notice nothing at all, as the attack leverages the image metadata while the picture itself may be harmless, entirely appropriate, and useful.

How to protect against the ExifTool vulnerability

GReAT researchers reported the vulnerability to the author of ExifTool, who promptly released version 13.50, which is not susceptible to CVE-2026-3102. Versions 13.49 and earlier must be updated to remediate the flaw.

It’s critical to ensure that all photo processing workflows are using the updated version. You should verify that all asset management platforms, photo organization apps, and any bulk image processing scripts running on Macs are calling ExifTool version 13.50 or later, and don’t contain an embedded older copy of the ExifTool library.

Naturally, ExifTool — like any software — may contain additional vulnerabilities of this class. To harden your defenses, we also recommend the following:

• Isolate the processing of untrusted files. Process images from questionable sources on a dedicated machine or within a virtual environment, strictly limiting its access to other computers, data storage, and network resources.
• Continuously track vulnerabilities along the software supply chain. Organizations that rely on open-source components in their workflows can use Open Source Software Threats Data Feed for tracking.

Finally, if you work with freelancers or self-employed contractors (or simply allow BYOD), only allow them to access your network if they have a comprehensive macOS security solution installed.

Still think macOS is safe? Then read about these Mac threats:

• Banshee: A stealer targeting macOS users
• Are Macs safe? Threats to macOS users
• Infostealer has entered the chat
• AirBorne: Attacks on Apple devices through vulnerabilities in AirPlay
• Hacking Android, macOS, iOS, and Linux through a Bluetooth vulnerability

Kaspersky official blog – ​Read More