MacSync is a relatively young, rapidly evolving family of crypto/info stealers. First advertised on the dark web in 2025 as Mac.c, the stealer was later renamed to MacSync by its creators. The initial versions were implemented as AppleScripts and closely resembled the AMOS stealer family, but over time, MacSync developed distinctive features of its own, including a backdoor module. In this report, we discuss a new infection chain that differs significantly from previous variants. We first spotted it in the wild in September 2026.

Key points:

• The developers of this family have overhauled their approach to payload delivery by replacing script-based droppers with binary ones.
• The main malicious payload now consists of modules written in Objective-C and Swift.
• At one stage of infection, the attackers use iCloud to deliver the next

Kaspersky solutions detect the threats described below under the following verdicts:

• HEUR:Trojan.OSX.MacSync.*
• HEUR:Trojan-PSW.OSX.MacSync.*
• HEUR:Trojan-Dropper.OSX.MacSync.*
• HEUR:Trojan-Downloader.OSX.MacSync.*

Technical details

Infection chain

MacSync is an infostealer distributed under the malware-as-a-service (MaaS) model, so the specific delivery method for the first stage of the infection chain is up to the operators. Recent public reports on MacSync have mostly focused on modules delivered through social engineering and ClickFix-style attacks. However, both then and now, the malware has also spread disguised as free or cracked versions of popular applications, as well as under the guise of new software. For example, we found MacSync masquerading as a nonexistent crypto wallet app called Toria; the attackers not only created a dedicated web page for it but also promoted it on X and Telegram:

The latest version of the infostealer we discovered starts the infection chain with malicious DMG images. Even within a single campaign built around one fake application, we found two different ways the infostealer and backdoor modules were delivered to the victim’s device. In one, the payload inside the DMG was a compiled JXA script that, once launched, decoded a shell script and passed it directly to the interpreter without writing it to disk. In the other version of the application, the same script appeared at a later stage of infection, after a chain of droppers and loaders had run. We’ll take a look at the second infection chain in detail, since it is more complex and technically interesting. The infection scheme is shown below:

It’s worth noting right away that MacSync shows shared traits at almost every stage:

• All temporary files are placed in the /tmp directory. The same directory is where *.lock files are created to prevent the malware from running again.
• Once its task is complete, the module removes traces of its activity: temporary files, its own logs, and so on.
• All binary files are in the FAT Mach-O format and target devices with both Apple and Intel processors.

Loader, Calendar, and Two Simple Droppers

In this infection chain, the payload on the disk image is an .APP application. When started, it first checks whether the whole bundle has the com.apple.quarantine extended quarantine attribute, and if it finds one, it runs the xattr -cr <app_name> command to remove all attributes. Next, it extracts an XOR-encrypted URL from its overlay and decrypts it with the key 73 6f 6e 6f 6d 61 62 6c 64 07. After the encrypted data, there are 8 bytes indicating the length of the ciphertext, followed by the magic word SONOMAC1. It’s worth noting that the malware reads the overlay backwards: it first locates the magic word, then reads the data size, and then uses the size to determine the boundaries of the data block containing the ciphertext.

The resulting URL is a link to the next-stage downloader script. In some cases, this link pointed directly to a file hosted on an attacker-controlled server; however, in at least one sample, the link pointed to a public iCloud calendar:

hxxp://caldav.icloud[.]com/published/2/MTk1NDMwMDMzNTUxOTU0M1aHCZ-nMxiyGzBTzPiodOf44DtKJ6PpjftAG28_ui2NCYMpL_vu4pF4ddsJ8ysg0QI7pR0VEIEbZYdilVZRw08

After retrieving the calendar file from the server, the downloader creates an anonymous pipe, launches the interpreter to read commands from standard input (zsh -s), sets the pipe as standard input, and redirects the contents of the calendar into it line by line. Since a calendar is normally not a command, the interpreter treats the lines as invalid commands until it reaches the malicious payload after the DESCRIPTION: line. These commands ultimately download a .TAR.GZ archive from iCloud that contains an .APP bundle. The downloader removes the quarantine attribute from it, signs it with an ad-hoc signature, and executes it.

We don’t know the contents of the scripts distributed from the attacker’s server, but they are very likely the same script found in the calendar event description.

The downloaded application is a dropper. The malicious payload it extracts is a zlib-compressed executable encrypted with AES in CBC mode, using the following key and initialization vector:

cb09ff86cabde4f8cee2d3cdec370c623bfa6c2b72ae9750fc9a7b299c65d7ca
3a1af2b397c6958e6c3ba3c75912d60e

The dropper decrypts and unpacks it, then places it at /tmp/.sys-<16-digit random value>.

Inside is another dropper, but unlike the previous stages, this one includes anti-debugging protection. In particular, it checks whether it’s running on a virtual machine by making sysctl queries with the kern.hv_vmm_present and machdep.cpu.brand_string parameters. It also sets the PT_DENY_ATTACH flag with ptrace to prevent a debugger from attaching to the process. The payload is a shell script encrypted with AES in CBC mode, using the following key and initialization vector:

3744f975113dfc552df982dcae699f9154a448e05a743bdfb641a463352bc13a
8d371f8a7a6dcc2655544ae13cbca03d

As shown in the screenshot above, the second dropper delivers a downloader script that retrieves the next-stage payload from the command-and-control server, decrypts it with AES in CBC mode using the following key and initialization vector, and then executes it in memory:

ff664112d3215c5d184689fc836e0dc6c1a47e42c34e70b2c3d356864bc4cb4c
09425f72de8bba18893dcd6f04115891

A couple more scripts

Inside the retrieved script, we can immediately spot several familiar indicators associated with the MacSync malware family:

• The main function in the script is named daemon_function.
• The stolen data is uploaded to the command-and-control server via PUT requests. The data in the requests is sent in 90-megabyte chunks. In earlier versions, the chunk sizes differed.
• One way to establish persistence on a system it uses is to inject a malicious command into the .ZSHRC, the configuration file for the ZSH interpreter, which contains commands that run each time the interpreter starts.
• The URL path where the backdoor executable is stored on the command-and-control server begins with the /loader/ directory.

The script performs the following tasks:

• Downloading and decrypting additional malicious modules: an infostealer, a backdoor, and a special utility for generating encryption keys and decrypting downloaded executable files
• Gaining persistence on the system
• Uploading data received from the infostealer module to the command-and-control server

One detail stands out: instead of the usual encryption algorithms (XOR, AES, and so on), the attackers took a different approach to delivering malicious modules at this stage. It involves a selfmade utility called pkgunpack that implements two commands: genkey and decrypt. The malicious payload is decrypted as follows:

1. The malware generates a public and private encryption key pair using genkey command from pkgunpack, whose generation function relies on an open implementation of the elliptic-curve Diffie-Hellman protocol on Curve25519: curve25519_donna.
2. The public key is encoded in base64 and sent to the command-and-control server together with a one-time code generated by the command $(date +%s)-${RANDOM}-$$.
3. The server responds with the following JSON:
   

   {
       "ok": true,
       "dek_wrap_b64":  <base64_encoded_encrypted_key> ,
       "build_pub_b64": "pFSxn/Uwg9bS45aVKCzA+8exSMfDHXpbpHC/f7G472w=",
       "crypto": "v2.5"
   }

   
   Here, build_pub_b64 is the server’s public key, which is also predefined in the script itself, and dek_wrap_b64 is a base64-encoded string that contains the payload encryption key. This key is encrypted on the server side with a shared secret computed from the public key generated with pkgunpack on the victim’s device.
4. Then decrypt command from pkgunpack utility decrypts the key:
   1. A shared secret is computed from the server’s known public key and the private key for the current session, using the same ECDH Curve25519 key exchange scheme that was used to generate the keys.
   2. The resulting shared secret is concatenated with the string sn-dek-wrap-v1, and a SHA-256 hash is computed from the result.
   3. Next, the dek_wrap_b64 block received from the server is decoded. It has the following structure:
      1. The first 5 bytes: additional authenticated data (AAD)
      2. The next 12 bytes: the initialization vector (IV)
      3. The rest: the ciphertext
   4. The ciphertext is decrypted with AES in GCM mode using the previously obtained key, IV, and AAD.
      

      Decoded dek_wrap_b64

5. The result is the key for decrypting the downloaded malicious payload. The payload, in turn, also contains an AAD and an IV in its header and is encrypted with AES GCM. The utility decrypts it and terminates.

Note that at each individual stage, the utility zeros out buffers after using encryption keys and data, apparently to impede forensic data collection and dynamic analysis of samples.

As mentioned earlier, at this stage, the script downloads only two modules: an infostealer and a backdoor. Once decrypted, both are .TAR.GZ archives; their contents are extracted, stripped of all extended attributes (such as com.apple.quarantine), and signed with an ad-hoc signature. The infostealer module runs first: it collects the data it needs, places it in a temporary folder, and compresses it into a .TAR.GZ archive, which the script then sends to the attackers’ server. Next, before launching the backdoor, the script sets up persistence for it and creates a backup copy. The backup copy, along with the other files it needs to operate, is placed in $HOME/Library/Application Support/System. This directory doesn’t exist in macOS by default; the script creates it. The backdoor disguises itself as the Finder application and achieves persistence in the system through the following methods:

• A LaunchAgent named com.apple.finder.agent
• Injection of a command that runs the .repair-run script when the ZSH interpreter starts from the .ZSHRC
• Injection of a similar command, which also runs the .repair-run script, into the global GIT pre-commit and post-checkout hooks

The .repair-run script checks whether the backdoor files exist, restores them from a backup if they are missing, and re-creates and reloads the LaunchAgent. At the same time, it kills the BTMNotificationAgent, NotificationCenter, and BackgroundTaskManagementAgent system processes to prevent the system from notifying the user about the new LaunchAgent.

One last thing worth noting about the script at this stage is its use of a custom HTTP header, X-Upload-Token, without which the C2 server responds to requests with errors. During our research, we observed the use of the following tokens: b8b4b88205a8f594b95a841bc37342898f34cad8a5a9e4a22ce69a31a1208650 and ff3ab9ef841630364818396f62e696b72aed162cf0b895b6643ef25dad79b51d. The backdoor later uses these same tokens to communicate with the C2 server.

Infostealer

The infostealer module ships as an .APP application, with its main executable written in Swift. As with previous AppleScript-based versions, the malware first asks the user for the administrator password. It adapts the window it displays to match the application it is impersonating. After the password is entered, the user sees a window that imitates a system notification about a corrupted application, offering to move it to the trash.

Interestingly, instead of the method most macOS malware families use to verify a password, the dscl utility, the attackers used the Pluggable Authentication Modules (PAM) API. This is a fairly new technique for macOS malware, first observed in the wild in July 2026 in the Pam Stealer family. It apparently caught the attention of malware authors, and we may see it used more often going forward.

Many strings in the stealer (file names, directory names, team IDs, and so on) are XOR-encrypted and stored in static arrays. The encryption keys differ between samples and are generated based on the ciphertext length.

The set of data the stealer collects has expanded slightly compared to previous versions. The generalized list is as follows:

• Browser data: browsing history, cookies, crypto wallet extension data, saved logins and passwords, and Local State files
• Crypto wallet application data
• Telegram data
• Device login and password
• Keychain file
• System information: list of installed applications and running processes, device model, hardware, UUID, and so on
• Configuration files for SSH, ZSH, AWS, Kubernetes, GIT, and other services/programs
• ZSH and Bash command history
• Current user profile picture

The collected data is saved to a hidden directory in /tmp/.

The stealer module also has one interesting feature, disabled in all samples discovered so far and apparently still in development. Its purpose is to check whether the malicious application’s resources contain a file called KcHelper at <app_path>/Contents/Resources/Helpers, and, if the file is present, launch it with certain parameters. If this file is missing, a fallback function, _kc_grab_storage_item, is executed instead. Since KcHelper was not present among the application’s resources at the time of our research, we can only speculate about its purpose based on our analysis of this function. It first runs a command that modifies the partition_id of the keychain entry for a specific service so that three categories of applications can access it without user confirmation and without the keychain password:

• teamid: the application is signed with a certificate that has a specific teamID (in this case, the target application’s developer)
• apple: the application is an Apple service
• apple-tool: the application is an Apple command-line utility

security set-generic-password-partition-list -a <account_name> -s <service_name> -S <application_groups> -k <keychain_password> <keychain_path>

The stealer then uses the Security.framework API to try and retrieve the secret’s contents on its own, which still ends up triggering a confirmation request for the operation. It appears the threat actors plan to refine this feature in the future to gain unimpeded access to secrets even if the keychain password changes, but at this point, they haven’t managed to do so, which is why the feature is disabled. In the stealer’s encrypted strings, we saw examples of arguments for the command that modifies partition_id, which indicate that the attackers are after browser secrets. Example:

Chrome Safe Storage|Chrome|ChromeStorage|apple-tool:,apple:,teamid:EQHXZ8M8AV
Brave Safe Storage|Brave|BraveStorage|apple-tool:,apple:,teamid:KL8N8XSYF4

Backdoor

The backdoor is a Fat Mach-O executable written in Objective-C. It has two launch modes: a regular one and one with the --persist-status flag. In the second mode, it only checks how it was added to the persistence objects: as a Login Item or as a LaunchAgent. In standard mode, before proceeding to its main functionality, the backdoor also checks whether it has been added to autorun in any way. If not, it uses the same persistence mechanism as the parent script. However, for macOS versions older than 13.0, a separate helper executable stored inside the backdoor’s body is used regardless of whether autorun objects are present. The helper performs a single task: it uses the CoreServices.framework API to add the executable file passed to it as an argument to the Login Items.

As with the droppers from the early stages of the infection chain, the configuration for communicating with the C2 is stored in the executable’s overlay and encrypted with XOR using the same key. It consists of several strings separated by null bytes:

• AGNT1: a magic constant confirming that the configuration was decrypted correctly
• C2 server URL
• Access token: the same one used in the parent script
• BLD-150: the backdoor build number

The malware also writes logs to $HOME/Library/Logs/.sysnotif-agent.log and supports extended logging when launched with the LAUNCHER_DEBUG environment variable. Communication with the C2 takes place over HTTP. The server’s response should be a JSON file.

Method	URL path	Request parameters	Description
GET	/v1/agent/ping	tag: the victim’s unique ID combined with the backdoor build number build: backdoor build number	Used to receive a command. The response is expected to contain a cmd field with the command to execute. If a 403 error is received, meaning the access token has expired, the backdoor tries to refresh it with a request to /v1/agent/refresh.
POST	/v1/agent/refresh	tag build old_token: previous token	The response is expected to contain an upload_token field, whose value becomes the new token.
POST	/v1/asset/<upload_id>/init	upload_id: an identifier for the object being uploaded, generated randomly based on a timestamp, the process ID, and a random four-byte number	Used to create a file on the server, into which the file from the victim’s device is later uploaded in parts. When the file is created, its size is passed in the X-File-Size header, and its SHA-256 hash is passed in X-File-Sha256.
PUT	/v1/asset/<upload_id>		The request that actually uploads the file to the server.
POST	/v1/agent/<command_status>	command_status: a status unique to the commands the agent executes tag upload_id: the ID of the file uploaded to the server (if any) phase: information about the command being executed or its stage message: a message active: command in-progress flag (true = still running; false = finished)	This URL endpoint is accessed at various stages of the backdoor’s operation. Information about command execution status serves as a telemetry source for the attackers.

Although the backdoor offers several different commands, they all boil down to the same action: extract the base64-encoded AppleScript script from the script_b64 field in the server’s response and execute it. Individual command handlers then act as wrappers around the scripts, correctly populating telemetry and sending requests to the C2 server. Based on the command names and the messages sent to the server during their execution, we can reconstruct their purpose without having the scripts on hand. The backdoor supports the following commands:

• deploy_ext: deploy an extension downloaded from the server into the victim’s browser.
• deploy_ledger: replace the installed Ledger wallet with the version from the server.
• regrab: collect system information and/or specific files again. This time, the collected data is packaged into an archive typical for the MacSync family, at /tmp/osalogging.zip, unless a different path is specified in the archive_path field sent along with the command.
• live_browser: the only command executed without an AppleScript script. The backdoor checks for the presence of the sn_relay file among its resources, and if it’s not found, downloads and executes it. Its content and purpose remain a mystery to us, but based on the command name and the messages sent to the server, we can assume that the attackers somehow implement a MitM attack on traffic originating from the victim’s browser.

Takeaways

The new version of the MacSync infostealer differs quite significantly from its previously observed variants. The attackers have substantially overhauled their approach to executing the stealer’s and backdoor’s main malicious payload, moving from AppleScripts to full-fledged executable files written in Swift and Objective-C. It’s also worth noting the more complex infection chain: instead of obfuscated shell scripts delivered through ClickFix attacks, this version used binary droppers and loaders, some of which leveraged Apple’s infrastructure as one of the intermediate stages for delivering the malicious payload.

The nature of the data attackers seek to collect from a victim’s device, as well as the categories of applications the stealer disguises itself as, clearly indicates that this malware family primarily targets developers, crypto enthusiasts, and other users associated in some way with IT and the crypto space. MacSync’s compromise of software developers’ devices poses particular security risks for both end users and corporate systems, opening up expanded opportunities for attackers to further their intrusion.

Indicators of compromise

Stage one loader
26a0f7cdb9f7dc5ace9a40af825b1538
2d69812584269699fade26622e6490c5
7df1049cbd56c0bfa4a3364a379b4c2c
9f15fe9c4415cd668334339f705b94d8
fb90887592655a8c989e443c640167aa
6791dad263cac6d63ebba6a4b57e7d71

Malicious calendar (stage two)
3ded1d71a822b53b12c3b67bcaf633f5

Stage three dropper
781ce50001d4b449600afa347c9b0208
8e84b01d5ac9624f0b181ade0e737193
980e2134679bc0c609f7659882883d77
4203ec932bfcc0907f91732440d6d997
eb760d5c88f13f7ee0f8f86ba3407123
f9f70096aabb4d22a6657014f4853a53

Stage four dropper
3deeed48fd38f22e369f5c3092bd68a1

Stage five script
f97d24212fa6a21be0c4d211e10f044c

Stage six script
00d12d842596bf5ee1805effb4571d30
9a0043d900a9ac78c886c59c9a328fd0

Auxiliary .repair-run script
7212229c85852c3bffaf9740002b2f39

Infostealer
c53d0ea45dbc622afb7f16ea3eec78bc

Backdoor
fc3ba5ed282d77127efd0b0f2403531b

Auxiliary autorun tool
8dc8561349d144d4661bc66f2ec49f9f

URL
hxxps://toria[.]app/
hxxps://warpcast[.]asia/Toria.dmg
hxxps://streamyard.appstore.com[.]mx/installer.sh
hxxps://slack.apple03cloudstore[.]com/installer.sh
hxxps://toria.apple03cloudstore[.]com/
hxxps://waaako.appstore.com[.]mx/installer.sh
hxxps://toria.apple03cloudstore[.]com/e3c1a6b00bc31e14/stage2.enc hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/stage2.enc
hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/CoreUpdate.pkg.enc
hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/Helper.pkg.enc
hxxps://caldav.icloud[.]com/published/2/MTk1NDMwMDMzNTUxOTU0M1aHCZ-nMxiyGzBTzPiodOf44DtKJ6PpjftAG28_ui2NCYMpL_vu4pF4ddsJ8ysg0QI7pR0VEIEbZYdilVZRw08
hxxps://gateway.icloud[.]com/caldav/1_MTk1NDMwMDMzNTUxOTU0M0pybtJB186GzhogprwCQUjY3oZNiDFHH8WVo6bmgUtI/attach/4GE4TKNBTGAYDGMZVGUYTSNJUGOAALDAFMDOJBGWNUCYJLZRNDCLCO2YMQ3I64RLGMNXVG3KYBPWQOGYIEI7MPBDDYHECFDYVENTXIYFNDCPOVRMCTYI236RCYZAE63V5U3RTUYGUMO2CO7PKCLWMCXE73M7OPTHSGRWH5DXQ4PCUQU4ELZTLW54JSTK2H7VQ6PD26WOA2R7PPIQ6RTJWDEWP34U3HB4YWMXXC6EJ6PKWILSPYRSDEVY6QGMWSIUN6PR5W35KO3D4QZE7CFPUVBAEKI/Loader.app.tar.gz/YXR0YWNoYXR0YWNoYXR0YRhrE8mQ0E-b_dTUSGStQgTQ0ULFxCanei3Ke-EuEyQL

C2
hxxps://docsend.appstore[.]com[.]mx
hxxps://toria.apple03cloudstore[.]com

MacSync is a relatively young, rapidly evolving family of crypto/info stealers. First advertised on the dark web in 2025 as Mac.c, the stealer was later renamed to MacSync by its creators. The initial versions were implemented as AppleScripts and closely resembled the AMOS stealer family, but over time, MacSync developed distinctive features of its own, including a backdoor module. In this report, we discuss a new infection chain that differs significantly from previous variants. We first spotted it in the wild in September 2026.

Key points:

• The developers of this family have overhauled their approach to payload delivery by replacing script-based droppers with binary ones.
• The main malicious payload now consists of modules written in Objective-C and Swift.
• At one stage of infection, the attackers use iCloud to deliver the next

Kaspersky solutions detect the threats described below under the following verdicts:

• HEUR:Trojan.OSX.MacSync.*
• HEUR:Trojan-PSW.OSX.MacSync.*
• HEUR:Trojan-Dropper.OSX.MacSync.*
• HEUR:Trojan-Downloader.OSX.MacSync.*

Technical details

Infection chain

MacSync is an infostealer distributed under the malware-as-a-service (MaaS) model, so the specific delivery method for the first stage of the infection chain is up to the operators. Recent public reports on MacSync have mostly focused on modules delivered through social engineering and ClickFix-style attacks. However, both then and now, the malware has also spread disguised as free or cracked versions of popular applications, as well as under the guise of new software. For example, we found MacSync masquerading as a nonexistent crypto wallet app called Toria; the attackers not only created a dedicated web page for it but also promoted it on X and Telegram:

The latest version of the infostealer we discovered starts the infection chain with malicious DMG images. Even within a single campaign built around one fake application, we found two different ways the infostealer and backdoor modules were delivered to the victim’s device. In one, the payload inside the DMG was a compiled JXA script that, once launched, decoded a shell script and passed it directly to the interpreter without writing it to disk. In the other version of the application, the same script appeared at a later stage of infection, after a chain of droppers and loaders had run. We’ll take a look at the second infection chain in detail, since it is more complex and technically interesting. The infection scheme is shown below:

It’s worth noting right away that MacSync shows shared traits at almost every stage:

• All temporary files are placed in the /tmp directory. The same directory is where *.lock files are created to prevent the malware from running again.
• Once its task is complete, the module removes traces of its activity: temporary files, its own logs, and so on.
• All binary files are in the FAT Mach-O format and target devices with both Apple and Intel processors.

Loader, Calendar, and Two Simple Droppers

In this infection chain, the payload on the disk image is an .APP application. When started, it first checks whether the whole bundle has the com.apple.quarantine extended quarantine attribute, and if it finds one, it runs the xattr -cr <app_name> command to remove all attributes. Next, it extracts an XOR-encrypted URL from its overlay and decrypts it with the key 73 6f 6e 6f 6d 61 62 6c 64 07. After the encrypted data, there are 8 bytes indicating the length of the ciphertext, followed by the magic word SONOMAC1. It’s worth noting that the malware reads the overlay backwards: it first locates the magic word, then reads the data size, and then uses the size to determine the boundaries of the data block containing the ciphertext.

The resulting URL is a link to the next-stage downloader script. In some cases, this link pointed directly to a file hosted on an attacker-controlled server; however, in at least one sample, the link pointed to a public iCloud calendar:

hxxp://caldav.icloud[.]com/published/2/MTk1NDMwMDMzNTUxOTU0M1aHCZ-nMxiyGzBTzPiodOf44DtKJ6PpjftAG28_ui2NCYMpL_vu4pF4ddsJ8ysg0QI7pR0VEIEbZYdilVZRw08

After retrieving the calendar file from the server, the downloader creates an anonymous pipe, launches the interpreter to read commands from standard input (zsh -s), sets the pipe as standard input, and redirects the contents of the calendar into it line by line. Since a calendar is normally not a command, the interpreter treats the lines as invalid commands until it reaches the malicious payload after the DESCRIPTION: line. These commands ultimately download a .TAR.GZ archive from iCloud that contains an .APP bundle. The downloader removes the quarantine attribute from it, signs it with an ad-hoc signature, and executes it.

We don’t know the contents of the scripts distributed from the attacker’s server, but they are very likely the same script found in the calendar event description.

The downloaded application is a dropper. The malicious payload it extracts is a zlib-compressed executable encrypted with AES in CBC mode, using the following key and initialization vector:

cb09ff86cabde4f8cee2d3cdec370c623bfa6c2b72ae9750fc9a7b299c65d7ca
3a1af2b397c6958e6c3ba3c75912d60e

The dropper decrypts and unpacks it, then places it at /tmp/.sys-<16-digit random value>.

Inside is another dropper, but unlike the previous stages, this one includes anti-debugging protection. In particular, it checks whether it’s running on a virtual machine by making sysctl queries with the kern.hv_vmm_present and machdep.cpu.brand_string parameters. It also sets the PT_DENY_ATTACH flag with ptrace to prevent a debugger from attaching to the process. The payload is a shell script encrypted with AES in CBC mode, using the following key and initialization vector:

3744f975113dfc552df982dcae699f9154a448e05a743bdfb641a463352bc13a
8d371f8a7a6dcc2655544ae13cbca03d

As shown in the screenshot above, the second dropper delivers a downloader script that retrieves the next-stage payload from the command-and-control server, decrypts it with AES in CBC mode using the following key and initialization vector, and then executes it in memory:

ff664112d3215c5d184689fc836e0dc6c1a47e42c34e70b2c3d356864bc4cb4c
09425f72de8bba18893dcd6f04115891

A couple more scripts

Inside the retrieved script, we can immediately spot several familiar indicators associated with the MacSync malware family:

• The main function in the script is named daemon_function.
• The stolen data is uploaded to the command-and-control server via PUT requests. The data in the requests is sent in 90-megabyte chunks. In earlier versions, the chunk sizes differed.
• One way to establish persistence on a system it uses is to inject a malicious command into the .ZSHRC, the configuration file for the ZSH interpreter, which contains commands that run each time the interpreter starts.
• The URL path where the backdoor executable is stored on the command-and-control server begins with the /loader/ directory.

The script performs the following tasks:

• Downloading and decrypting additional malicious modules: an infostealer, a backdoor, and a special utility for generating encryption keys and decrypting downloaded executable files
• Gaining persistence on the system
• Uploading data received from the infostealer module to the command-and-control server

One detail stands out: instead of the usual encryption algorithms (XOR, AES, and so on), the attackers took a different approach to delivering malicious modules at this stage. It involves a selfmade utility called pkgunpack that implements two commands: genkey and decrypt. The malicious payload is decrypted as follows:

1. The malware generates a public and private encryption key pair using genkey command from pkgunpack, whose generation function relies on an open implementation of the elliptic-curve Diffie-Hellman protocol on Curve25519: curve25519_donna.
2. The public key is encoded in base64 and sent to the command-and-control server together with a one-time code generated by the command $(date +%s)-${RANDOM}-$$.
3. The server responds with the following JSON:
   

   {
       "ok": true,
       "dek_wrap_b64":  <base64_encoded_encrypted_key> ,
       "build_pub_b64": "pFSxn/Uwg9bS45aVKCzA+8exSMfDHXpbpHC/f7G472w=",
       "crypto": "v2.5"
   }

   
   Here, build_pub_b64 is the server’s public key, which is also predefined in the script itself, and dek_wrap_b64 is a base64-encoded string that contains the payload encryption key. This key is encrypted on the server side with a shared secret computed from the public key generated with pkgunpack on the victim’s device.
4. Then decrypt command from pkgunpack utility decrypts the key:
   1. A shared secret is computed from the server’s known public key and the private key for the current session, using the same ECDH Curve25519 key exchange scheme that was used to generate the keys.
   2. The resulting shared secret is concatenated with the string sn-dek-wrap-v1, and a SHA-256 hash is computed from the result.
   3. Next, the dek_wrap_b64 block received from the server is decoded. It has the following structure:
      1. The first 5 bytes: additional authenticated data (AAD)
      2. The next 12 bytes: the initialization vector (IV)
      3. The rest: the ciphertext
   4. The ciphertext is decrypted with AES in GCM mode using the previously obtained key, IV, and AAD.
      

      Decoded dek_wrap_b64

5. The result is the key for decrypting the downloaded malicious payload. The payload, in turn, also contains an AAD and an IV in its header and is encrypted with AES GCM. The utility decrypts it and terminates.

Note that at each individual stage, the utility zeros out buffers after using encryption keys and data, apparently to impede forensic data collection and dynamic analysis of samples.

As mentioned earlier, at this stage, the script downloads only two modules: an infostealer and a backdoor. Once decrypted, both are .TAR.GZ archives; their contents are extracted, stripped of all extended attributes (such as com.apple.quarantine), and signed with an ad-hoc signature. The infostealer module runs first: it collects the data it needs, places it in a temporary folder, and compresses it into a .TAR.GZ archive, which the script then sends to the attackers’ server. Next, before launching the backdoor, the script sets up persistence for it and creates a backup copy. The backup copy, along with the other files it needs to operate, is placed in $HOME/Library/Application Support/System. This directory doesn’t exist in macOS by default; the script creates it. The backdoor disguises itself as the Finder application and achieves persistence in the system through the following methods:

• A LaunchAgent named com.apple.finder.agent
• Injection of a command that runs the .repair-run script when the ZSH interpreter starts from the .ZSHRC
• Injection of a similar command, which also runs the .repair-run script, into the global GIT pre-commit and post-checkout hooks

The .repair-run script checks whether the backdoor files exist, restores them from a backup if they are missing, and re-creates and reloads the LaunchAgent. At the same time, it kills the BTMNotificationAgent, NotificationCenter, and BackgroundTaskManagementAgent system processes to prevent the system from notifying the user about the new LaunchAgent.

One last thing worth noting about the script at this stage is its use of a custom HTTP header, X-Upload-Token, without which the C2 server responds to requests with errors. During our research, we observed the use of the following tokens: b8b4b88205a8f594b95a841bc37342898f34cad8a5a9e4a22ce69a31a1208650 and ff3ab9ef841630364818396f62e696b72aed162cf0b895b6643ef25dad79b51d. The backdoor later uses these same tokens to communicate with the C2 server.

Infostealer

The infostealer module ships as an .APP application, with its main executable written in Swift. As with previous AppleScript-based versions, the malware first asks the user for the administrator password. It adapts the window it displays to match the application it is impersonating. After the password is entered, the user sees a window that imitates a system notification about a corrupted application, offering to move it to the trash.

Interestingly, instead of the method most macOS malware families use to verify a password, the dscl utility, the attackers used the Pluggable Authentication Modules (PAM) API. This is a fairly new technique for macOS malware, first observed in the wild in July 2026 in the Pam Stealer family. It apparently caught the attention of malware authors, and we may see it used more often going forward.

Many strings in the stealer (file names, directory names, team IDs, and so on) are XOR-encrypted and stored in static arrays. The encryption keys differ between samples and are generated based on the ciphertext length.

The set of data the stealer collects has expanded slightly compared to previous versions. The generalized list is as follows:

• Browser data: browsing history, cookies, crypto wallet extension data, saved logins and passwords, and Local State files
• Crypto wallet application data
• Telegram data
• Device login and password
• Keychain file
• System information: list of installed applications and running processes, device model, hardware, UUID, and so on
• Configuration files for SSH, ZSH, AWS, Kubernetes, GIT, and other services/programs
• ZSH and Bash command history
• Current user profile picture

The collected data is saved to a hidden directory in /tmp/.

The stealer module also has one interesting feature, disabled in all samples discovered so far and apparently still in development. Its purpose is to check whether the malicious application’s resources contain a file called KcHelper at <app_path>/Contents/Resources/Helpers, and, if the file is present, launch it with certain parameters. If this file is missing, a fallback function, _kc_grab_storage_item, is executed instead. Since KcHelper was not present among the application’s resources at the time of our research, we can only speculate about its purpose based on our analysis of this function. It first runs a command that modifies the partition_id of the keychain entry for a specific service so that three categories of applications can access it without user confirmation and without the keychain password:

• teamid: the application is signed with a certificate that has a specific teamID (in this case, the target application’s developer)
• apple: the application is an Apple service
• apple-tool: the application is an Apple command-line utility

security set-generic-password-partition-list -a <account_name> -s <service_name> -S <application_groups> -k <keychain_password> <keychain_path>

The stealer then uses the Security.framework API to try and retrieve the secret’s contents on its own, which still ends up triggering a confirmation request for the operation. It appears the threat actors plan to refine this feature in the future to gain unimpeded access to secrets even if the keychain password changes, but at this point, they haven’t managed to do so, which is why the feature is disabled. In the stealer’s encrypted strings, we saw examples of arguments for the command that modifies partition_id, which indicate that the attackers are after browser secrets. Example:

Chrome Safe Storage|Chrome|ChromeStorage|apple-tool:,apple:,teamid:EQHXZ8M8AV
Brave Safe Storage|Brave|BraveStorage|apple-tool:,apple:,teamid:KL8N8XSYF4

Backdoor

The backdoor is a Fat Mach-O executable written in Objective-C. It has two launch modes: a regular one and one with the --persist-status flag. In the second mode, it only checks how it was added to the persistence objects: as a Login Item or as a LaunchAgent. In standard mode, before proceeding to its main functionality, the backdoor also checks whether it has been added to autorun in any way. If not, it uses the same persistence mechanism as the parent script. However, for macOS versions older than 13.0, a separate helper executable stored inside the backdoor’s body is used regardless of whether autorun objects are present. The helper performs a single task: it uses the CoreServices.framework API to add the executable file passed to it as an argument to the Login Items.

As with the droppers from the early stages of the infection chain, the configuration for communicating with the C2 is stored in the executable’s overlay and encrypted with XOR using the same key. It consists of several strings separated by null bytes:

• AGNT1: a magic constant confirming that the configuration was decrypted correctly
• C2 server URL
• Access token: the same one used in the parent script
• BLD-150: the backdoor build number

The malware also writes logs to $HOME/Library/Logs/.sysnotif-agent.log and supports extended logging when launched with the LAUNCHER_DEBUG environment variable. Communication with the C2 takes place over HTTP. The server’s response should be a JSON file.

Method	URL path	Request parameters	Description
GET	/v1/agent/ping	tag: the victim’s unique ID combined with the backdoor build number build: backdoor build number	Used to receive a command. The response is expected to contain a cmd field with the command to execute. If a 403 error is received, meaning the access token has expired, the backdoor tries to refresh it with a request to /v1/agent/refresh.
POST	/v1/agent/refresh	tag build old_token: previous token	The response is expected to contain an upload_token field, whose value becomes the new token.
POST	/v1/asset/<upload_id>/init	upload_id: an identifier for the object being uploaded, generated randomly based on a timestamp, the process ID, and a random four-byte number	Used to create a file on the server, into which the file from the victim’s device is later uploaded in parts. When the file is created, its size is passed in the X-File-Size header, and its SHA-256 hash is passed in X-File-Sha256.
PUT	/v1/asset/<upload_id>		The request that actually uploads the file to the server.
POST	/v1/agent/<command_status>	command_status: a status unique to the commands the agent executes tag upload_id: the ID of the file uploaded to the server (if any) phase: information about the command being executed or its stage message: a message active: command in-progress flag (true = still running; false = finished)	This URL endpoint is accessed at various stages of the backdoor’s operation. Information about command execution status serves as a telemetry source for the attackers.

Although the backdoor offers several different commands, they all boil down to the same action: extract the base64-encoded AppleScript script from the script_b64 field in the server’s response and execute it. Individual command handlers then act as wrappers around the scripts, correctly populating telemetry and sending requests to the C2 server. Based on the command names and the messages sent to the server during their execution, we can reconstruct their purpose without having the scripts on hand. The backdoor supports the following commands:

• deploy_ext: deploy an extension downloaded from the server into the victim’s browser.
• deploy_ledger: replace the installed Ledger wallet with the version from the server.
• regrab: collect system information and/or specific files again. This time, the collected data is packaged into an archive typical for the MacSync family, at /tmp/osalogging.zip, unless a different path is specified in the archive_path field sent along with the command.
• live_browser: the only command executed without an AppleScript script. The backdoor checks for the presence of the sn_relay file among its resources, and if it’s not found, downloads and executes it. Its content and purpose remain a mystery to us, but based on the command name and the messages sent to the server, we can assume that the attackers somehow implement a MitM attack on traffic originating from the victim’s browser.

Takeaways

The new version of the MacSync infostealer differs quite significantly from its previously observed variants. The attackers have substantially overhauled their approach to executing the stealer’s and backdoor’s main malicious payload, moving from AppleScripts to full-fledged executable files written in Swift and Objective-C. It’s also worth noting the more complex infection chain: instead of obfuscated shell scripts delivered through ClickFix attacks, this version used binary droppers and loaders, some of which leveraged Apple’s infrastructure as one of the intermediate stages for delivering the malicious payload.

The nature of the data attackers seek to collect from a victim’s device, as well as the categories of applications the stealer disguises itself as, clearly indicates that this malware family primarily targets developers, crypto enthusiasts, and other users associated in some way with IT and the crypto space. MacSync’s compromise of software developers’ devices poses particular security risks for both end users and corporate systems, opening up expanded opportunities for attackers to further their intrusion.

Indicators of compromise

Stage one loader
26a0f7cdb9f7dc5ace9a40af825b1538
2d69812584269699fade26622e6490c5
7df1049cbd56c0bfa4a3364a379b4c2c
9f15fe9c4415cd668334339f705b94d8
fb90887592655a8c989e443c640167aa
6791dad263cac6d63ebba6a4b57e7d71

Malicious calendar (stage two)
3ded1d71a822b53b12c3b67bcaf633f5

Stage three dropper
781ce50001d4b449600afa347c9b0208
8e84b01d5ac9624f0b181ade0e737193
980e2134679bc0c609f7659882883d77
4203ec932bfcc0907f91732440d6d997
eb760d5c88f13f7ee0f8f86ba3407123
f9f70096aabb4d22a6657014f4853a53

Stage four dropper
3deeed48fd38f22e369f5c3092bd68a1

Stage five script
f97d24212fa6a21be0c4d211e10f044c

Stage six script
00d12d842596bf5ee1805effb4571d30
9a0043d900a9ac78c886c59c9a328fd0

Auxiliary .repair-run script
7212229c85852c3bffaf9740002b2f39

Infostealer
c53d0ea45dbc622afb7f16ea3eec78bc

Backdoor
fc3ba5ed282d77127efd0b0f2403531b

Auxiliary autorun tool
8dc8561349d144d4661bc66f2ec49f9f

URL
hxxps://toria[.]app/
hxxps://warpcast[.]asia/Toria.dmg
hxxps://streamyard.appstore.com[.]mx/installer.sh
hxxps://slack.apple03cloudstore[.]com/installer.sh
hxxps://toria.apple03cloudstore[.]com/
hxxps://waaako.appstore.com[.]mx/installer.sh
hxxps://toria.apple03cloudstore[.]com/e3c1a6b00bc31e14/stage2.enc hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/stage2.enc
hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/CoreUpdate.pkg.enc
hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/Helper.pkg.enc
hxxps://caldav.icloud[.]com/published/2/MTk1NDMwMDMzNTUxOTU0M1aHCZ-nMxiyGzBTzPiodOf44DtKJ6PpjftAG28_ui2NCYMpL_vu4pF4ddsJ8ysg0QI7pR0VEIEbZYdilVZRw08
hxxps://gateway.icloud[.]com/caldav/1_MTk1NDMwMDMzNTUxOTU0M0pybtJB186GzhogprwCQUjY3oZNiDFHH8WVo6bmgUtI/attach/4GE4TKNBTGAYDGMZVGUYTSNJUGOAALDAFMDOJBGWNUCYJLZRNDCLCO2YMQ3I64RLGMNXVG3KYBPWQOGYIEI7MPBDDYHECFDYVENTXIYFNDCPOVRMCTYI236RCYZAE63V5U3RTUYGUMO2CO7PKCLWMCXE73M7OPTHSGRWH5DXQ4PCUQU4ELZTLW54JSTK2H7VQ6PD26WOA2R7PPIQ6RTJWDEWP34U3HB4YWMXXC6EJ6PKWILSPYRSDEVY6QGMWSIUN6PR5W35KO3D4QZE7CFPUVBAEKI/Loader.app.tar.gz/YXR0YWNoYXR0YWNoYXR0YRhrE8mQ0E-b_dTUSGStQgTQ0ULFxCanei3Ke-EuEyQL

C2
hxxps://docsend.appstore[.]com[.]mx
hxxps://toria.apple03cloudstore[.]com

Introduction

ExifTool is a widely adopted utility for reading and writing metadata in image, PDF, audio, and video files. It is available both as a standalone command-line application and as a library that can be embedded in other software. In this article, we break down CVE-2026-3102, an ExifTool vulnerability discovered by Kaspersky’s Global Research and Analysis Team (GReAT) in February 2026 and patched by the developers within the same month. Affecting macOS systems with ExifTool version 13.49 and earlier, this flaw could let an attacker run arbitrary commands by hiding instructions inside an image file’s metadata.

This investigation originated from revisiting an n-day vulnerability I first examined years ago: CVE-2021-22204. That flaw exploited weak regex-based sanitization before feeding user input into an eval sink. By auditing adjacent input validation routines across ExifTool codebase for similar oversights, I discovered CVE-2026-3102. Successful exploitation of CVE-2026-3102 enables an attacker to execute arbitrary shell commands with the privileges of the user invoking ExifTool, potentially leading to full system compromise.

Technical details

Disclaimer

Exploiting CVE-2026-3102 requires the -n (also known as -printConv) flag and outputs machine-readable data without additional processing.

Tracing the vulnerable sink

Taint analysis (aka tainted data analysis) allows for the detection of “dirty” data that reaches dangerous locations without validation. In this context, a “sink” is a point or function in a program where data or a parameter marked as “tainted” or originating from an untrusted source (e.g., user input) can affect the program’s behavior. In ExifTool, these functions are eval and system, both of which are capable of executing system commands. While CVE-2021-22204 exploited an eval function as a sink, this vulnerability (CVE-2026-3102) targets the system function. Knowing the vulnerable sink, we needed to trace how user-controlled data reaches it. Below, we break down the details.

Finding an unsanitized date value

The screenshot above shows where the system() sink resides within the SetMacOSTags function. Tracing backward from system(), we identified the $cmd variable as the source of the executed command. This variable is assembled from three inputs: $file (properly sanitized), $setTags (processed iteratively), and $val (user-controlled and, crucially, left unsanitized in the vulnerable branch).

In ExifTool, a tag is a named metadata field. When parsing an image, the utility extracts date and time values from standard EXIF records or macOS filesystem attributes. To handle file creation dates on macOS, ExifTool relies on the Spotlight system attribute MDItemFSCreationDate. Within the program code, this attribute maps to the internal alias $FileCreateDate. These two identifiers govern how the file creation date is stored and applied.

This creates a critical link to the vulnerability: when parsing an image, ExifTool iterates through the discovered tags. The current tag’s name is assigned to the $tag variable, while its text content (e.g., a date string) is assigned to $val. The vulnerable code path is triggered only when $tag matches MDItemFSCreationDate or $FileCreateDate. At this point, the tag’s content flows into $val and is passed to the SetMacOSTags function. As shown in the screenshot below, the filename parameter is properly escaped, but the date value ($val) is not. Because the date is extracted directly from file metadata, an attacker can inject quotes into this field. This breaks the command structure and allows the payload to execute via the system() sink.

The following screenshots show some of the tags that can be modified. With the vulnerable parameter identified, the next challenge was delivery: how to place our payload into FileCreateDate without triggering early validation? We found the answer in the official documentation.

Planning the payload delivery

Let’s refer to the documentation to understand how ExifTool handles tag operations and identify a legitimate feature that can be repurposed for exploitation. Specifically, we need to find a way to deliver our payload into the vulnerable FileCreateDate parameter. When looking for macOS-related tags as well as FileCreateDate, we can find the following information:

• To write or delete metadata, tag values are assigned using –TAG=[VALUE], and/or the -geotag, -csv= or -json=
• To copy or move metadata, the -tagsFromFile feature is used.

(You can find the useful info on tag operations above and how it relates under the hood in ExifTool in the dedicated section of the documentation and on the ExifTool description page.)

To trigger the vulnerability, we need to copy a string (date format: MM/DD/YYYY) using the -tagsFromFile feature, as this operation invokes the SetMacOSTags function where the unsanitized $val parameter reaches the system() sink.

Why copy instead of writing directly? Because the vulnerable code path (SetMacOSTags) is only triggered when metadata is copied into FileCreateDate — not when it is written directly. By using -tagsFromFile, we can prepare a “source” tag (e.g., DateTimeOriginal) that accepts arbitrary values and copy that value into FileCreateDate, thereby invoking the vulnerable function with our controlled input.

Furthermore, we want to introduce single quotes (since they are not being escaped in $val). For starters, we can look for date-time tag and copy via -tagsFromFile by searching the EXIF tag table. Direct assignment to FileCreateDate is heavily validated, so we looked for a source tag that accepts raw values and can be copied into the target field. The following snippet shows the beginning of said table.

When doing the analysis, I made use of DateTimeOriginal though I believe you can also use CreateDate which is 0x9004 (see the following screenshot). Initial attempts to inject malformed dates failed: ExifTool’s built-in filter rejected the input. To bypass this, we examined how the tool handles raw metadata.

Bypassing the filter

To confirm that the PrintConvInv filter rejects invalid dates when written directly, I ran the following command, where evil_benign.jpg is a normal JPG with an invalid date time format. We are greeted with the error message: Invalid date/time. This requires the time as well. The next screenshot confirms that direct exploitation fails: ExifTool’s date validation detects the malformed input and rejects the change, activating the internal PrintConvInv filter.

That said, it is possible to ignore the formatting and use the -n flag which accepts raw values instead of human-readable value.  The -n flag skips the PrintConvInv conversion step, which is exactly where input sanitization occurs. This confirmed we could park unsanitized data in a source tag. The final step was to trigger the vulnerable code path by copying that data into FileCreateDate. This means we should now be able to modify the DateTimeOriginal tag with the invalid date time format with an -n flag. Examining the EXIF metadata tag, we can confirm that we can store a raw value without a proper human readable format that ExifTool accepts:

Triggering the exploit

To inject commands, we have to revisit the single quote injection into this datetime related tag.

The following screenshot shows that we have successfully set the datetime metadata with the single quote. With the payload safely stored in a source tag, the next step was to copy it into FileCreateDate, triggering the vulnerable system() call.

The next step now is to copy the datetime tag to a file which invokes SetMacOSTags. According to the documentation, this is how we can copy the data from the SRC tag to the FileCreateDate tag as seen in the SetMacOSTags with the -tagsFromFile feature.

exiftool [_OPTIONS_] -tagsFromFile _SRCFILE_ [-[_DSTTAG_<]_SRCTAG_...] _FILE_...

Therefore, we can craft our final command:

cp evil_benign.jpg pwn.jpg;
../../exiftool -n -tagsFromFile evil_benign.jpg "-FileCreateDate<DateTimeOriginal" pwn.jpg

Here, we confirm that the payload has been executed! Note that when copying tags in MacOS (Darwin), the /usr/bin/setfile command is used. To view the full $cmd value before the injection, I have added the debugging statement to displaying the actual command that is executed within the system function.

Upon injection, we can see that our command gets executed via command substitution. The single quotes that we added helped to make the entire command syntactically valid. The following shows a more detailed labelling and their roles in making this command line injection successful:

Such an image can appear completely benign and easily find its way into a newsroom or any organization that processes photos on macOS using ExifTool. Once processed, an attacker could silently deploy a Trojan for covert data exfiltration, drop additional malware, or use the compromised machine as a foothold to expand the attack within the victim’s network.

Patch analysis

After verifying successful exploitation, we examined how the maintainer addressed the flaw in version 13.50. In the vulnerable version of ExifTool, commands were sanitized before being concatenated together. This means that it is possible to concatenate single quotes which led to the exploitation. However, by abstracting the system call into a dedicated wrapper and requiring a list of arguments instead of concatenated string, the fix removes the need for any manual escaping altogether.

1. Replacing string form to argument list form:

#### BEFORE
$cmd = "/usr/bin/setfile -d '${val}' '${f}'";
system $cmd;
  
#### AFTER
system('/usr/bin/setfile', '-d', $val, $file);

2. Create new System() wrapper. In version 13.49, the output is piped to /dev/null . To maintain that logic, the wrapper would temporarily redirect STDOUT/STDERR to /dev/null and restore them after the call.

# Call system command, redirecting all I/O to /dev/null
# Inputs: system arguments
# Returns: system return code
sub System
{
    open(my $oldout, ">&STDOUT");
    open(my $olderr, ">&STDERR");
    open(STDOUT, '>', '/dev/null');
    open(STDERR, '>', '/dev/null');
    my $result = system(@_);
    open(STDOUT, ">&", $oldout);
    open(STDERR, ">&", $olderr);
    return $result;
}

How to protect against ExifTool vulnerability

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.

ExifTool, like any software, may contain additional vulnerabilities of this class. To harden defenses, I recommend using Kaspersky Open Source Software Threats Data Feed for continuous monitoring of open-source components in your software supply chain, and Kaspersky for macOS as comprehensive endpoint protection. Additionally, isolate processing of untrusted files on dedicated machines or virtual environments with strictly limited network and storage access. If you work with freelancers, contractors, or allow BYOD, enforce a policy that only devices with an active macOS security solution can access your corporate network.

Conclusions

CVE-2026-3102 highlights the risks of inconsistent input sanitization in tools that bridge high-level metadata parsing with platform-specific utilities. While exploitation requires explicit flag usage (-n) and is restricted to macOS, the vulnerability underscores the danger of manual escaping routines in evolving codebases. The transition to list-form system execution provides a robust, architecture-level fix that eliminates shell interpretation risks entirely. This case reinforces a core security principle: replacing fragile string concatenation with secure, list-based API calls remains the most reliable mitigation against command injection.

Introduction

ExifTool is a widely adopted utility for reading and writing metadata in image, PDF, audio, and video files. It is available both as a standalone command-line application and as a library that can be embedded in other software. In this article, we break down CVE-2026-3102, an ExifTool vulnerability discovered by Kaspersky’s Global Research and Analysis Team (GReAT) in February 2026 and patched by the developers within the same month. Affecting macOS systems with ExifTool version 13.49 and earlier, this flaw could let an attacker run arbitrary commands by hiding instructions inside an image file’s metadata.

This investigation originated from revisiting an n-day vulnerability I first examined years ago: CVE-2021-22204. That flaw exploited weak regex-based sanitization before feeding user input into an eval sink. By auditing adjacent input validation routines across ExifTool codebase for similar oversights, I discovered CVE-2026-3102. Successful exploitation of CVE-2026-3102 enables an attacker to execute arbitrary shell commands with the privileges of the user invoking ExifTool, potentially leading to full system compromise.

Technical details

Disclaimer

Exploiting CVE-2026-3102 requires the -n (also known as -printConv) flag and outputs machine-readable data without additional processing.

Tracing the vulnerable sink

Taint analysis (aka tainted data analysis) allows for the detection of “dirty” data that reaches dangerous locations without validation. In this context, a “sink” is a point or function in a program where data or a parameter marked as “tainted” or originating from an untrusted source (e.g., user input) can affect the program’s behavior. In ExifTool, these functions are eval and system, both of which are capable of executing system commands. While CVE-2021-22204 exploited an eval function as a sink, this vulnerability (CVE-2026-3102) targets the system function. Knowing the vulnerable sink, we needed to trace how user-controlled data reaches it. Below, we break down the details.

Finding an unsanitized date value

The screenshot above shows where the system() sink resides within the SetMacOSTags function. Tracing backward from system(), we identified the $cmd variable as the source of the executed command. This variable is assembled from three inputs: $file (properly sanitized), $setTags (processed iteratively), and $val (user-controlled and, crucially, left unsanitized in the vulnerable branch).

In ExifTool, a tag is a named metadata field. When parsing an image, the utility extracts date and time values from standard EXIF records or macOS filesystem attributes. To handle file creation dates on macOS, ExifTool relies on the Spotlight system attribute MDItemFSCreationDate. Within the program code, this attribute maps to the internal alias $FileCreateDate. These two identifiers govern how the file creation date is stored and applied.

This creates a critical link to the vulnerability: when parsing an image, ExifTool iterates through the discovered tags. The current tag’s name is assigned to the $tag variable, while its text content (e.g., a date string) is assigned to $val. The vulnerable code path is triggered only when $tag matches MDItemFSCreationDate or $FileCreateDate. At this point, the tag’s content flows into $val and is passed to the SetMacOSTags function. As shown in the screenshot below, the filename parameter is properly escaped, but the date value ($val) is not. Because the date is extracted directly from file metadata, an attacker can inject quotes into this field. This breaks the command structure and allows the payload to execute via the system() sink.

The following screenshots show some of the tags that can be modified. With the vulnerable parameter identified, the next challenge was delivery: how to place our payload into FileCreateDate without triggering early validation? We found the answer in the official documentation.

Planning the payload delivery

Let’s refer to the documentation to understand how ExifTool handles tag operations and identify a legitimate feature that can be repurposed for exploitation. Specifically, we need to find a way to deliver our payload into the vulnerable FileCreateDate parameter. When looking for macOS-related tags as well as FileCreateDate, we can find the following information:

• To write or delete metadata, tag values are assigned using –TAG=[VALUE], and/or the -geotag, -csv= or -json=
• To copy or move metadata, the -tagsFromFile feature is used.

(You can find the useful info on tag operations above and how it relates under the hood in ExifTool in the dedicated section of the documentation and on the ExifTool description page.)

To trigger the vulnerability, we need to copy a string (date format: MM/DD/YYYY) using the -tagsFromFile feature, as this operation invokes the SetMacOSTags function where the unsanitized $val parameter reaches the system() sink.

Why copy instead of writing directly? Because the vulnerable code path (SetMacOSTags) is only triggered when metadata is copied into FileCreateDate — not when it is written directly. By using -tagsFromFile, we can prepare a “source” tag (e.g., DateTimeOriginal) that accepts arbitrary values and copy that value into FileCreateDate, thereby invoking the vulnerable function with our controlled input.

Furthermore, we want to introduce single quotes (since they are not being escaped in $val). For starters, we can look for date-time tag and copy via -tagsFromFile by searching the EXIF tag table. Direct assignment to FileCreateDate is heavily validated, so we looked for a source tag that accepts raw values and can be copied into the target field. The following snippet shows the beginning of said table.

When doing the analysis, I made use of DateTimeOriginal though I believe you can also use CreateDate which is 0x9004 (see the following screenshot). Initial attempts to inject malformed dates failed: ExifTool’s built-in filter rejected the input. To bypass this, we examined how the tool handles raw metadata.

Bypassing the filter

To confirm that the PrintConvInv filter rejects invalid dates when written directly, I ran the following command, where evil_benign.jpg is a normal JPG with an invalid date time format. We are greeted with the error message: Invalid date/time. This requires the time as well. The next screenshot confirms that direct exploitation fails: ExifTool’s date validation detects the malformed input and rejects the change, activating the internal PrintConvInv filter.

That said, it is possible to ignore the formatting and use the -n flag which accepts raw values instead of human-readable value.  The -n flag skips the PrintConvInv conversion step, which is exactly where input sanitization occurs. This confirmed we could park unsanitized data in a source tag. The final step was to trigger the vulnerable code path by copying that data into FileCreateDate. This means we should now be able to modify the DateTimeOriginal tag with the invalid date time format with an -n flag. Examining the EXIF metadata tag, we can confirm that we can store a raw value without a proper human readable format that ExifTool accepts:

Triggering the exploit

To inject commands, we have to revisit the single quote injection into this datetime related tag.

The following screenshot shows that we have successfully set the datetime metadata with the single quote. With the payload safely stored in a source tag, the next step was to copy it into FileCreateDate, triggering the vulnerable system() call.

The next step now is to copy the datetime tag to a file which invokes SetMacOSTags. According to the documentation, this is how we can copy the data from the SRC tag to the FileCreateDate tag as seen in the SetMacOSTags with the -tagsFromFile feature.

exiftool [_OPTIONS_] -tagsFromFile _SRCFILE_ [-[_DSTTAG_<]_SRCTAG_...] _FILE_...

Therefore, we can craft our final command:

cp evil_benign.jpg pwn.jpg;
../../exiftool -n -tagsFromFile evil_benign.jpg "-FileCreateDate<DateTimeOriginal" pwn.jpg

Here, we confirm that the payload has been executed! Note that when copying tags in MacOS (Darwin), the /usr/bin/setfile command is used. To view the full $cmd value before the injection, I have added the debugging statement to displaying the actual command that is executed within the system function.

Upon injection, we can see that our command gets executed via command substitution. The single quotes that we added helped to make the entire command syntactically valid. The following shows a more detailed labelling and their roles in making this command line injection successful:

Such an image can appear completely benign and easily find its way into a newsroom or any organization that processes photos on macOS using ExifTool. Once processed, an attacker could silently deploy a Trojan for covert data exfiltration, drop additional malware, or use the compromised machine as a foothold to expand the attack within the victim’s network.

Patch analysis

After verifying successful exploitation, we examined how the maintainer addressed the flaw in version 13.50. In the vulnerable version of ExifTool, commands were sanitized before being concatenated together. This means that it is possible to concatenate single quotes which led to the exploitation. However, by abstracting the system call into a dedicated wrapper and requiring a list of arguments instead of concatenated string, the fix removes the need for any manual escaping altogether.

1. Replacing string form to argument list form:

#### BEFORE
$cmd = "/usr/bin/setfile -d '${val}' '${f}'";
system $cmd;
  
#### AFTER
system('/usr/bin/setfile', '-d', $val, $file);

2. Create new System() wrapper. In version 13.49, the output is piped to /dev/null . To maintain that logic, the wrapper would temporarily redirect STDOUT/STDERR to /dev/null and restore them after the call.

# Call system command, redirecting all I/O to /dev/null
# Inputs: system arguments
# Returns: system return code
sub System
{
    open(my $oldout, ">&STDOUT");
    open(my $olderr, ">&STDERR");
    open(STDOUT, '>', '/dev/null');
    open(STDERR, '>', '/dev/null');
    my $result = system(@_);
    open(STDOUT, ">&", $oldout);
    open(STDERR, ">&", $olderr);
    return $result;
}

How to protect against ExifTool vulnerability

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.

ExifTool, like any software, may contain additional vulnerabilities of this class. To harden defenses, I recommend using Kaspersky Open Source Software Threats Data Feed for continuous monitoring of open-source components in your software supply chain, and Kaspersky for macOS as comprehensive endpoint protection. Additionally, isolate processing of untrusted files on dedicated machines or virtual environments with strictly limited network and storage access. If you work with freelancers, contractors, or allow BYOD, enforce a policy that only devices with an active macOS security solution can access your corporate network.

Conclusions

CVE-2026-3102 highlights the risks of inconsistent input sanitization in tools that bridge high-level metadata parsing with platform-specific utilities. While exploitation requires explicit flag usage (-n) and is restricted to macOS, the vulnerability underscores the danger of manual escaping routines in evolving codebases. The transition to list-form system execution provides a robust, architecture-level fix that eliminates shell interpretation risks entirely. This case reinforces a core security principle: replacing fragile string concatenation with secure, list-based API calls remains the most reliable mitigation against command injection.

IT threat evolution in Q1 2026. Non-mobile statistics
IT threat evolution in Q1 2026. Mobile statistics

The statistics in this report are based on detection verdicts returned by Kaspersky products unless otherwise stated. The information was provided by Kaspersky users who consented to sharing statistical data.

Quarterly figures

In Q1 2026:

• Kaspersky products blocked more than 343 million attacks that originated with various online resources.
• Web Anti-Virus responded to 50 million unique links.
• File Anti-Virus blocked nearly 15 million malicious and potentially unwanted objects.
• 2938 new ransomware variants were detected.
• More than 77,000 users experienced ransomware attacks.
• 14% of all ransomware victims whose data was published on threat actors’ data leak sites (DLS) were victims of Clop.
• More than 260,000 users were targeted by miners.

Ransomware

Quarterly trends and highlights

Law enforcement success

In January 2026, it was reported that the FBI had seized the domains of the RAMP cybercrime forum, a major platform used extensively by ransomware developers to advertise their RaaS programs and to recruit affiliates. There has been no official statement from the FBI, nor is it clear if RAMP servers were seized. In a post on an external website, a RAMP moderator mentioned law enforcement agencies gaining control over the forum. The takedown disrupted a key element of the RaaS ecosystem, creating ripple effects for ransomware operators, affiliates, and initial access brokers.

A man suspected of links to the Phobos group was apprehended in Poland. He was charged with the creation, acquisition, and distribution of software designed for unlawfully obtaining information, including data that facilitates unauthorized access to information stored within a computer system.

In March, a Phobos ransomware administrator pleaded guilty to the creation and distribution of the Trojan, which had been used in international attacks dating back to at least November 2020.

In March, the U.S. Department of Justice charged a man who had acted as a negotiator for ransomware groups. The company he worked for specializes in cyberincident investigations. The prosecution alleges the suspect colluded with the BlackCat threat actor to share privileged insights into the ongoing progress of negotiations. Additionally, the suspect is alleged to have had a prior direct role in BlackCat attacks, serving as an affiliate for the RaaS operation.

In a separate development this March, a U.S. court sentenced an initial access broker associated with the Yanluowang ransomware group to 81 months of imprisonment. According to the U.S. Department of Justice, the convict facilitated dozens of ransomware attacks across the United States, resulting in over $9 million in actual loss and more than $24 million in intended loss.

Vulnerabilities and attacks

The Interlock group has been heavily exploiting the CVE-2026-20131 zero-day vulnerability in Cisco Secure FMC firewall management software since at least January 26, 2026. The vulnerability enabled arbitrary Java code execution with root privileges on the affected device. This campaign demonstrates the ongoing reliance on zero-day vulnerabilities for initial access, a focus on network appliances as high-value entry points, and the rapid weaponization of new vulnerabilities within the ransomware ecosystem.

The most prolific groups

This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS. This quarter, the Clop ransomware (14.42%) returned to the top of the rankings, displacing Qilin (12.34%), which had held the leading position in the previous reporting period. Following closely is a new threat actor, The Gentlemen (9.25%). Emerging no later than July 2025, the group had already surpassed the activity levels of mainstays such as Akira (7.25%) and INC Ransom (6.13%).

Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)

Number of new variants

In Q1 2026, Kaspersky solutions detected six new ransomware families and 2938 new modifications. Volumes have returned to Q3 2025 levels following a surge in Q4 2025.

Number of new ransomware modifications, Q1 2025 — Q1 2026 (download)

Number of users attacked by ransomware Trojans

Throughout Q1, our solutions protected 77,319 unique users from ransomware. Ransomware activity was highest in March, with 35,056 unique users encountering such attacks during the month.

Number of unique users attacked by ransomware Trojans, Q1 2026 (download)

Attack geography

TOP 10 countries and territories attacked by ransomware Trojans

	Country/territory*	%**
1	Pakistan	0.79
2	South Korea	0.64
3	China	0.52
4	Tajikistan	0.40
5	Libya	0.38
6	Turkmenistan	0.36
7	Iraq	0.35
8	Bangladesh	0.33
9	Rwanda	0.30
10	Cameroon	0.28

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.

TOP 10 most common families of ransomware Trojans

	Name	Verdict	%*
1	(generic verdict)	Trojan-Ransom.Win32.Gen	33.90
2	(generic verdict)	Trojan-Ransom.Win32.Crypren	6.38
3	WannaCry	Trojan-Ransom.Win32.Wanna	5.87
4	(generic verdict)	Trojan-Ransom.Win32.Encoder	4.68
5	(generic verdict)	Trojan-Ransom.Win32.Agent	3.80
6	LockBit	Trojan-Ransom.Win32.Lockbit	2.80
7	(generic verdict)	Trojan-Ransom.Win32.Phny	1.99
8	(generic verdict)	Trojan-Ransom.MSIL.Agent	1.96
9	(generic verdict)	Trojan-Ransom.Python.Agent	1.93
10	(generic verdict)	Trojan-Ransom.Win32.Crypmod	1.89

* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.

Miners

Number of new variants

In Q1 2026, Kaspersky solutions detected 3485 new modifications of miners.

Number of new miner modifications, Q1 2026 (download)

Number of users attacked by miners

In Q1, we detected attacks using miner programs on the computers of 260,588 unique Kaspersky users worldwide.

Number of unique users attacked by miners, Q1 2026 (download)

Attack geography

TOP 10 countries and territories attacked by miners

	Country/territory*	%**
1	Senegal	3.19
2	Turkmenistan	3.06
3	Mali	2.63
4	Tanzania	1.62
5	Bangladesh	1.06
6	Ethiopia	0.95
7	Panama	0.88
8	Afghanistan	0.79
9	Kazakhstan	0.77
10	Bolivia	0.75

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.

Attacks on macOS

In Q1 2026, Google uncovered a new cryptocurrency theft campaign. The scammers directed victims to a fraudulent video call, prompting them to execute malicious scripts under the guise of technical support fixes for connection problems.

In March, researchers with GTIG and iVerify reported the discovery of an in-the-wild exploit chain targeting both iOS and macOS devices. The exploit kit was apparently marketed on the dark web, providing threat actors with a suite of spyware capabilities alongside specialized cryptocurrency exfiltration modules. The exploit was delivered via drive-by downloads when victims visited various compromised websites. Our analysis confirmed that the toolkit included an updated version of a component previously identified in the Operation Triangulation attack chain.

Devices running macOS were similarly impacted by the high-profile supply chain attack targeting the Axios npm package, a widely used HTTP client for JavaScript. The installation of the infected package led to the deployment of a backdoor on macOS devices.

TOP 20 threats to macOS

Unique users* who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)

* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.

The share of PasivRobber spyware attacks is beginning to decline, giving way to more traditional adware and Monitor-class software capable of tracking user activity. The popular Amos stealer also maintains its presence within the TOP 20.

Geography of threats to macOS

TOP 10 countries and territories by share of attacked users

Country/territory	%* Q4 2025	%* Q1 2026
China	1.28	1.97
France	1.18	1.07
Brazil	1.13	0.98
Mexico	0.72	0.52
Germany	0.71	0.45
The Netherlands	0.62	0.75
Hong Kong	0.49	0.53
India	0.42	0.48
Russian Federation	0.34	0.37
Thailand	0.24	0.27

* Unique users who encountered threats to macOS as a percentage of all unique Kaspersky users in the country/territory.

IoT threat statistics

This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.

In Q1 2026, the share of devices attacking Kaspersky honeypots via the SSH protocol saw a significant increase compared to the previous reporting period.

Distribution of attacked services by number of unique IP addresses of attacking devices (download)

The distribution of attacks between Telnet and SSH maintained the ratio observed in Q4 2025.

Distribution of attackers’ sessions in Kaspersky honeypots (download)

TOP 10 threats delivered to IoT devices

Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)

The primary shifts in the IoT threat distribution are linked to the activity of various Mirai botnet variants, although members of this family continue to account for the majority of the list. Furthermore, a new variant, Mirai.kl, surfaced in the rankings. We also observed a significant decline in NyaDrop botnet activity during Q1.

Attacks on IoT honeypots

The United States, the Netherlands, and Germany accounted for the highest proportions of SSH-based attacks during this period.

Country/territory	Q4 2025	Q1 2026
United States	16.10%	23.74%
The Netherlands	15.78%	17.57%
Germany	12.07%	10.34%
Panama	7.72%	6.34%
India	5.32%	6.05%
Romania	4.05%	5.82%
Australia	1.62%	4.61%
Vietnam	4.21%	3.50%
Russian Federation	3.79%	2.35%
Sweden	2.25%	2.09%

China continues to account for the largest proportion of Telnet attacks, though there was a marked increase in activity originating from Pakistan.

Country/territory	Q4 2025	Q1 2026
China	53.64%	39.54%
Pakistan	14.27%	27.31%
Russian Federation	8.20%	8.25%
Indonesia	8.58%	6.71%
India	4.85%	4.66%
Brazil	0.06%	3.30%
Argentina	0.02%	2.51%
Nigeria	1.22%	1.38%
Thailand	0.01%	0.55%
Sweden	0.54%	0.55%

Attacks via web resources

The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. These malicious pages are purposefully created by cybercriminals. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.

TOP 10 countries and territories that served as sources of web-based attacks

The following statistics show the distribution by country/territory of the sources of internet attacks blocked by Kaspersky products on user computers (web pages redirecting to exploits, sites containing exploits and other malicious programs, botnet C&C centers, and so on). One or more web-based attacks could originate from each unique host.

To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).

In Q1 2026, Kaspersky solutions blocked 343,823,407 attacks launched from internet resources worldwide. Web Anti-Virus was triggered by 49,983,611 unique URLs.

Web-based attacks by country/territory, Q1 2026 (download)

Countries and territories where users faced the greatest risk of online infection

To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location on whose computers Web Anti-Virus was triggered during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.

This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

	Country/territory*	%**
1	Venezuela	9.33
2	Hungary	8.16
3	Italy	7.58
4	Tajikistan	7.48
5	India	7.21
6	Greece	7.13
7	Portugal	7.10
8	France	7.05
9	Belgium	6.83
10	Slovakia	6.80
11	Vietnam	6.62
12	Bosnia and Herzegovina	6.57
13	Canada	6.56
14	Serbia	6.50
15	Tunisia	6.36
16	Qatar	6.01
17	Spain	5.95
18	Germany	5.95
19	Sri Lanka	5.89
20	Brazil	5.88

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users targeted by web-based Malware attacks as a percentage of all unique users of Kaspersky products in the country/territory.

On average during the quarter, 4.73% of users’ computers worldwide were subjected to at least one Malware web attack.

Local threats

Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.

Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media. The statistics are based on detection verdicts from the On-Access Scan (OAS) and On-Demand Scan (ODS) modules of File Anti-Virus and include detections of malicious programs located on user computers or removable media connected to the computers, such as flash drives, camera memory cards, phones, or external hard drives.

In Q1 2026, our File Anti-Virus detected 15,831,319 malicious and potentially unwanted objects.

Countries and territories where users faced the highest risk of local infection

For each country and territory, we calculated the percentage of Kaspersky users whose computers had the File Anti-Virus triggered at least once during the reporting period. This statistic reflects the level of personal computer infection in different countries and territories around the world.

Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

	Country/territory*	%**
1	Turkmenistan	47.96
2	Tajikistan	31.48
3	Cuba	31.03
4	Yemen	29.59
5	Afghanistan	28.47
6	Burundi	26.93
7	Uzbekistan	24.81
8	Syria	23.08
9	Nicaragua	21.97
10	Cameroon	21.60
11	China	21.09
12	Mozambique	21.02
13	Algeria	20.64
14	Democratic Republic of the Congo	20.63
15	Bangladesh	20.44
16	Mali	20.35
17	Republic of the Congo	20.23
18	Madagascar	20.00
19	Belarus	19.78
20	Tanzania	19.52

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers local Malware threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.

On average worldwide, Malware local threats were detected at least once on 11.55% of users’ computers during Q1.

Russia scored 11.92% in these rankings.

IT threat evolution in Q1 2026. Non-mobile statistics
IT threat evolution in Q1 2026. Mobile statistics

The statistics in this report are based on detection verdicts returned by Kaspersky products unless otherwise stated. The information was provided by Kaspersky users who consented to sharing statistical data.

Quarterly figures

In Q1 2026:

• Kaspersky products blocked more than 343 million attacks that originated with various online resources.
• Web Anti-Virus responded to 50 million unique links.
• File Anti-Virus blocked nearly 15 million malicious and potentially unwanted objects.
• 2938 new ransomware variants were detected.
• More than 77,000 users experienced ransomware attacks.
• 14% of all ransomware victims whose data was published on threat actors’ data leak sites (DLS) were victims of Clop.
• More than 260,000 users were targeted by miners.

Ransomware

Quarterly trends and highlights

Law enforcement success

In January 2026, it was reported that the FBI had seized the domains of the RAMP cybercrime forum, a major platform used extensively by ransomware developers to advertise their RaaS programs and to recruit affiliates. There has been no official statement from the FBI, nor is it clear if RAMP servers were seized. In a post on an external website, a RAMP moderator mentioned law enforcement agencies gaining control over the forum. The takedown disrupted a key element of the RaaS ecosystem, creating ripple effects for ransomware operators, affiliates, and initial access brokers.

A man suspected of links to the Phobos group was apprehended in Poland. He was charged with the creation, acquisition, and distribution of software designed for unlawfully obtaining information, including data that facilitates unauthorized access to information stored within a computer system.

In March, a Phobos ransomware administrator pleaded guilty to the creation and distribution of the Trojan, which had been used in international attacks dating back to at least November 2020.

In March, the U.S. Department of Justice charged a man who had acted as a negotiator for ransomware groups. The company he worked for specializes in cyberincident investigations. The prosecution alleges the suspect colluded with the BlackCat threat actor to share privileged insights into the ongoing progress of negotiations. Additionally, the suspect is alleged to have had a prior direct role in BlackCat attacks, serving as an affiliate for the RaaS operation.

In a separate development this March, a U.S. court sentenced an initial access broker associated with the Yanluowang ransomware group to 81 months of imprisonment. According to the U.S. Department of Justice, the convict facilitated dozens of ransomware attacks across the United States, resulting in over $9 million in actual loss and more than $24 million in intended loss.

Vulnerabilities and attacks

The Interlock group has been heavily exploiting the CVE-2026-20131 zero-day vulnerability in Cisco Secure FMC firewall management software since at least January 26, 2026. The vulnerability enabled arbitrary Java code execution with root privileges on the affected device. This campaign demonstrates the ongoing reliance on zero-day vulnerabilities for initial access, a focus on network appliances as high-value entry points, and the rapid weaponization of new vulnerabilities within the ransomware ecosystem.

The most prolific groups

This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS. This quarter, the Clop ransomware (14.42%) returned to the top of the rankings, displacing Qilin (12.34%), which had held the leading position in the previous reporting period. Following closely is a new threat actor, The Gentlemen (9.25%). Emerging no later than July 2025, the group had already surpassed the activity levels of mainstays such as Akira (7.25%) and INC Ransom (6.13%).

Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)

Number of new variants

In Q1 2026, Kaspersky solutions detected six new ransomware families and 2938 new modifications. Volumes have returned to Q3 2025 levels following a surge in Q4 2025.

Number of new ransomware modifications, Q1 2025 — Q1 2026 (download)

Number of users attacked by ransomware Trojans

Throughout Q1, our solutions protected 77,319 unique users from ransomware. Ransomware activity was highest in March, with 35,056 unique users encountering such attacks during the month.

Number of unique users attacked by ransomware Trojans, Q1 2026 (download)

Attack geography

TOP 10 countries and territories attacked by ransomware Trojans

	Country/territory*	%**
1	Pakistan	0.79
2	South Korea	0.64
3	China	0.52
4	Tajikistan	0.40
5	Libya	0.38
6	Turkmenistan	0.36
7	Iraq	0.35
8	Bangladesh	0.33
9	Rwanda	0.30
10	Cameroon	0.28

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.

TOP 10 most common families of ransomware Trojans

	Name	Verdict	%*
1	(generic verdict)	Trojan-Ransom.Win32.Gen	33.90
2	(generic verdict)	Trojan-Ransom.Win32.Crypren	6.38
3	WannaCry	Trojan-Ransom.Win32.Wanna	5.87
4	(generic verdict)	Trojan-Ransom.Win32.Encoder	4.68
5	(generic verdict)	Trojan-Ransom.Win32.Agent	3.80
6	LockBit	Trojan-Ransom.Win32.Lockbit	2.80
7	(generic verdict)	Trojan-Ransom.Win32.Phny	1.99
8	(generic verdict)	Trojan-Ransom.MSIL.Agent	1.96
9	(generic verdict)	Trojan-Ransom.Python.Agent	1.93
10	(generic verdict)	Trojan-Ransom.Win32.Crypmod	1.89

* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.

Miners

Number of new variants

In Q1 2026, Kaspersky solutions detected 3485 new modifications of miners.

Number of new miner modifications, Q1 2026 (download)

Number of users attacked by miners

In Q1, we detected attacks using miner programs on the computers of 260,588 unique Kaspersky users worldwide.

Number of unique users attacked by miners, Q1 2026 (download)

Attack geography

TOP 10 countries and territories attacked by miners

	Country/territory*	%**
1	Senegal	3.19
2	Turkmenistan	3.06
3	Mali	2.63
4	Tanzania	1.62
5	Bangladesh	1.06
6	Ethiopia	0.95
7	Panama	0.88
8	Afghanistan	0.79
9	Kazakhstan	0.77
10	Bolivia	0.75

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.

Attacks on macOS

In Q1 2026, Google uncovered a new cryptocurrency theft campaign. The scammers directed victims to a fraudulent video call, prompting them to execute malicious scripts under the guise of technical support fixes for connection problems.

In March, researchers with GTIG and iVerify reported the discovery of an in-the-wild exploit chain targeting both iOS and macOS devices. The exploit kit was apparently marketed on the dark web, providing threat actors with a suite of spyware capabilities alongside specialized cryptocurrency exfiltration modules. The exploit was delivered via drive-by downloads when victims visited various compromised websites. Our analysis confirmed that the toolkit included an updated version of a component previously identified in the Operation Triangulation attack chain.

Devices running macOS were similarly impacted by the high-profile supply chain attack targeting the Axios npm package, a widely used HTTP client for JavaScript. The installation of the infected package led to the deployment of a backdoor on macOS devices.

TOP 20 threats to macOS

Unique users* who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)

* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.

The share of PasivRobber spyware attacks is beginning to decline, giving way to more traditional adware and Monitor-class software capable of tracking user activity. The popular Amos stealer also maintains its presence within the TOP 20.

Geography of threats to macOS

TOP 10 countries and territories by share of attacked users

Country/territory	%* Q4 2025	%* Q1 2026
China	1.28	1.97
France	1.18	1.07
Brazil	1.13	0.98
Mexico	0.72	0.52
Germany	0.71	0.45
The Netherlands	0.62	0.75
Hong Kong	0.49	0.53
India	0.42	0.48
Russian Federation	0.34	0.37
Thailand	0.24	0.27

* Unique users who encountered threats to macOS as a percentage of all unique Kaspersky users in the country/territory.

IoT threat statistics

This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.

In Q1 2026, the share of devices attacking Kaspersky honeypots via the SSH protocol saw a significant increase compared to the previous reporting period.

Distribution of attacked services by number of unique IP addresses of attacking devices (download)

The distribution of attacks between Telnet and SSH maintained the ratio observed in Q4 2025.

Distribution of attackers’ sessions in Kaspersky honeypots (download)

TOP 10 threats delivered to IoT devices

Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)

The primary shifts in the IoT threat distribution are linked to the activity of various Mirai botnet variants, although members of this family continue to account for the majority of the list. Furthermore, a new variant, Mirai.kl, surfaced in the rankings. We also observed a significant decline in NyaDrop botnet activity during Q1.

Attacks on IoT honeypots

The United States, the Netherlands, and Germany accounted for the highest proportions of SSH-based attacks during this period.

Country/territory	Q4 2025	Q1 2026
United States	16.10%	23.74%
The Netherlands	15.78%	17.57%
Germany	12.07%	10.34%
Panama	7.72%	6.34%
India	5.32%	6.05%
Romania	4.05%	5.82%
Australia	1.62%	4.61%
Vietnam	4.21%	3.50%
Russian Federation	3.79%	2.35%
Sweden	2.25%	2.09%

China continues to account for the largest proportion of Telnet attacks, though there was a marked increase in activity originating from Pakistan.

Country/territory	Q4 2025	Q1 2026
China	53.64%	39.54%
Pakistan	14.27%	27.31%
Russian Federation	8.20%	8.25%
Indonesia	8.58%	6.71%
India	4.85%	4.66%
Brazil	0.06%	3.30%
Argentina	0.02%	2.51%
Nigeria	1.22%	1.38%
Thailand	0.01%	0.55%
Sweden	0.54%	0.55%

Attacks via web resources

The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. These malicious pages are purposefully created by cybercriminals. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.

TOP 10 countries and territories that served as sources of web-based attacks

The following statistics show the distribution by country/territory of the sources of internet attacks blocked by Kaspersky products on user computers (web pages redirecting to exploits, sites containing exploits and other malicious programs, botnet C&C centers, and so on). One or more web-based attacks could originate from each unique host.

To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).

In Q1 2026, Kaspersky solutions blocked 343,823,407 attacks launched from internet resources worldwide. Web Anti-Virus was triggered by 49,983,611 unique URLs.

Web-based attacks by country/territory, Q1 2026 (download)

Countries and territories where users faced the greatest risk of online infection

To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location on whose computers Web Anti-Virus was triggered during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.

This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

	Country/territory*	%**
1	Venezuela	9.33
2	Hungary	8.16
3	Italy	7.58
4	Tajikistan	7.48
5	India	7.21
6	Greece	7.13
7	Portugal	7.10
8	France	7.05
9	Belgium	6.83
10	Slovakia	6.80
11	Vietnam	6.62
12	Bosnia and Herzegovina	6.57
13	Canada	6.56
14	Serbia	6.50
15	Tunisia	6.36
16	Qatar	6.01
17	Spain	5.95
18	Germany	5.95
19	Sri Lanka	5.89
20	Brazil	5.88

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users targeted by web-based Malware attacks as a percentage of all unique users of Kaspersky products in the country/territory.

On average during the quarter, 4.73% of users’ computers worldwide were subjected to at least one Malware web attack.

Local threats

Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.

Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media. The statistics are based on detection verdicts from the On-Access Scan (OAS) and On-Demand Scan (ODS) modules of File Anti-Virus and include detections of malicious programs located on user computers or removable media connected to the computers, such as flash drives, camera memory cards, phones, or external hard drives.

In Q1 2026, our File Anti-Virus detected 15,831,319 malicious and potentially unwanted objects.

Countries and territories where users faced the highest risk of local infection

For each country and territory, we calculated the percentage of Kaspersky users whose computers had the File Anti-Virus triggered at least once during the reporting period. This statistic reflects the level of personal computer infection in different countries and territories around the world.

Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

	Country/territory*	%**
1	Turkmenistan	47.96
2	Tajikistan	31.48
3	Cuba	31.03
4	Yemen	29.59
5	Afghanistan	28.47
6	Burundi	26.93
7	Uzbekistan	24.81
8	Syria	23.08
9	Nicaragua	21.97
10	Cameroon	21.60
11	China	21.09
12	Mozambique	21.02
13	Algeria	20.64
14	Democratic Republic of the Congo	20.63
15	Bangladesh	20.44
16	Mali	20.35
17	Republic of the Congo	20.23
18	Madagascar	20.00
19	Belarus	19.78
20	Tanzania	19.52

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers local Malware threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.

On average worldwide, Malware local threats were detected at least once on 11.55% of users’ computers during Q1.

Russia scored 11.92% in these rankings.