ctipilot.ch

XCSSET

malware · malware:xcsset single-source

Modular macOS malware family targeting Apple-ecosystem developers by infecting Xcode projects and Git repositories, so the payload executes when a developer builds an infected project locally. First documented by Trend Micro in 2020 with two further versions documented by Microsoft in 2025. Version 40, analysed by Unit 42 on 2026-07-31, keeps its core logic in memory and deletes its installation files, recompiles payloads polymorphically, and adds fileless persistence that stores a Base64 staging payload in a per-host macOS defaults preferences domain. It degrades platform defences by disabling the software-update configuration channel, terminating the cloud telemetry process, holding an exclusive file lock on the XProtect signature database, and resetting the TCC AppleEvents permission database to re-prompt a user who declines (Palo Alto Networks Unit 42, 2026-07-31).

Aliases: XCSSET v40

Coverage timeline
2
first 2026-08-01 → last 2026-08-02
Peak priority
notable
2 notable
Sources cited
6
4 hosts
Sections touched
2
active-threats, weekly-research
Co-occurring entities
0
no co-occurrence
ATT&CK techniques
19
pinned v19.2 · see below

ATT&CK techniques

19 techniques observed across 2 entries — derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v19.2 · compare on the matrix · Navigator layer (JSON)

Initial Access TA0001

T1195.001Supply Chain Compromise: Compromise Software Dependencies and Development Tools×1

Adversaries may manipulate software dependencies and development tools prior to receipt by a final consumer for the purpose of data or system compromise. Applications often depend on external software to function properly. Popular open source projects that are used as dependencies in many applications, such as pip and NPM packages, may be targeted as a means to add malicious code to users of the dependency. This may also include abandoned packages, which in some cases could be re-registered by threat actors after being removed by adversaries. Adversaries may also employ "typosquatting" or name-confusion by choosing names similar to existing popular libraries or packages in order to deceive a user.

Evidence: 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

Execution TA0002

T1574.001Hijack Execution Flow: DLL×1

Adversaries may abuse dynamic-link library files (DLLs) in order to achieve persistence, escalate privileges, and evade defenses. DLLs are libraries that contain code and data that can be simultaneously utilized by multiple programs. While DLLs are not malicious by nature, they can be abused through mechanisms such as side-loading, hijacking search order, and phantom DLL hijacking.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · ATT&CK page ↗

Persistence TA0003

T1543.003Create or Modify System Process: Windows Service×1

Adversaries may create or modify Windows services to repeatedly execute malicious payloads as part of persistence. When Windows boots up, it starts programs or applications called services that perform background system functions. Windows service configuration information, including the file path to the service's executable or recovery programs/commands, is stored in the Windows Registry.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · ATT&CK page ↗

T1543.004Create or Modify System Process: Launch Daemon×1

Adversaries may create or modify Launch Daemons to execute malicious payloads as part of persistence. Launch Daemons are plist files used to interact with Launchd, the service management framework used by macOS. Launch Daemons require elevated privileges to install, are executed for every user on a system prior to login, and run in the background without the need for user interaction. During the macOS initialization startup, the launchd process loads the parameters for launch-on-demand system-level daemons from plist files found in <code>/System/Library/LaunchDaemons/</code> and <code>/Library/LaunchDaemons/</code>. Required Launch Daemons parameters include a <code>Label</code> to identify the task, <code>Program</code> to provide a path to the executable, and <code>RunAtLoad</code> to specify when the task is run. Launch Daemons are often used to provide access to shared resources, updates to software, or conduct automation tasks.

Evidence: 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

T1546.004Event Triggered Execution: Unix Shell Configuration Modification×1

Adversaries may establish persistence through executing malicious commands triggered by a user’s shell. User Unix Shells execute several configuration scripts at different points throughout the session based on events. For example, when a user opens a command-line interface or remotely logs in (such as via SSH) a login shell is initiated. The login shell executes scripts from the system (<code>/etc</code>) and the user’s home directory (<code>~/</code>) to configure the environment. All login shells on a system use /etc/profile when initiated. These configuration scripts run at the permission level of their directory and are often used to set environment variables, create aliases, and customize the user’s environment. When the shell exits or terminates, additional shell scripts are executed to ensure the shell exits appropriately.

Evidence: 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

T1554Compromise Host Software Binary×1

Adversaries may modify host software binaries to establish persistent access to systems. Software binaries/executables provide a wide range of system commands or services, programs, and libraries. Common software binaries are SSH clients, FTP clients, email clients, web browsers, and many other user or server applications.

Evidence: 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

Privilege Escalation TA0004

T1055Process Injection×1

Adversaries may inject code into processes in order to evade process-based defenses as well as possibly elevate privileges. Process injection is a method of executing arbitrary code in the address space of a separate live process. Running code in the context of another process may allow access to the process's memory, system/network resources, and possibly elevated privileges. Execution via process injection may also evade detection from security products since the execution is masked under a legitimate process.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · ATT&CK page ↗

T1543.003Create or Modify System Process: Windows Service×1

Adversaries may create or modify Windows services to repeatedly execute malicious payloads as part of persistence. When Windows boots up, it starts programs or applications called services that perform background system functions. Windows service configuration information, including the file path to the service's executable or recovery programs/commands, is stored in the Windows Registry.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · ATT&CK page ↗

T1543.004Create or Modify System Process: Launch Daemon×1

Adversaries may create or modify Launch Daemons to execute malicious payloads as part of persistence. Launch Daemons are plist files used to interact with Launchd, the service management framework used by macOS. Launch Daemons require elevated privileges to install, are executed for every user on a system prior to login, and run in the background without the need for user interaction. During the macOS initialization startup, the launchd process loads the parameters for launch-on-demand system-level daemons from plist files found in <code>/System/Library/LaunchDaemons/</code> and <code>/Library/LaunchDaemons/</code>. Required Launch Daemons parameters include a <code>Label</code> to identify the task, <code>Program</code> to provide a path to the executable, and <code>RunAtLoad</code> to specify when the task is run. Launch Daemons are often used to provide access to shared resources, updates to software, or conduct automation tasks.

Evidence: 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

T1546.004Event Triggered Execution: Unix Shell Configuration Modification×1

Adversaries may establish persistence through executing malicious commands triggered by a user’s shell. User Unix Shells execute several configuration scripts at different points throughout the session based on events. For example, when a user opens a command-line interface or remotely logs in (such as via SSH) a login shell is initiated. The login shell executes scripts from the system (<code>/etc</code>) and the user’s home directory (<code>~/</code>) to configure the environment. All login shells on a system use /etc/profile when initiated. These configuration scripts run at the permission level of their directory and are often used to set environment variables, create aliases, and customize the user’s environment. When the shell exits or terminates, additional shell scripts are executed to ensure the shell exits appropriately.

Evidence: 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

T1548.006Abuse Elevation Control Mechanism: TCC Manipulation×1

Adversaries can manipulate or abuse the Transparency, Consent, & Control (TCC) service or database to grant malicious executables elevated permissions. TCC is a Privacy & Security macOS control mechanism used to determine if the running process has permission to access the data or services protected by TCC, such as screen sharing, camera, microphone, or Full Disk Access (FDA).

Evidence: 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

Stealth TA0005

T1027Obfuscated Files or Information×2

Adversaries may attempt to make an executable or file difficult to discover or analyze by encrypting, encoding, or otherwise obfuscating its contents on the system or in transit. This is common behavior that can be used across different platforms and the network to evade defenses.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

T1055Process Injection×1

Adversaries may inject code into processes in order to evade process-based defenses as well as possibly elevate privileges. Process injection is a method of executing arbitrary code in the address space of a separate live process. Running code in the context of another process may allow access to the process's memory, system/network resources, and possibly elevated privileges. Execution via process injection may also evade detection from security products since the execution is masked under a legitimate process.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · ATT&CK page ↗

T1140Deobfuscate/Decode Files or Information×2

Adversaries may use Obfuscated Files or Information to hide artifacts of an intrusion from analysis. They may require separate mechanisms to decode or deobfuscate that information depending on how they intend to use it. Methods for doing that include built-in functionality of malware or by using utilities present on the system.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

T1480.001Execution Guardrails: Environmental Keying×1

Adversaries may environmentally key payloads or other features of malware to evade defenses and constraint execution to a specific target environment. Environmental keying uses cryptography to constrain execution or actions based on adversary supplied environment specific conditions that are expected to be present on the target. Environmental keying is an implementation of Execution Guardrails that utilizes cryptographic techniques for deriving encryption/decryption keys from specific types of values in a given computing environment.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · ATT&CK page ↗

T1497.001Virtualization/Sandbox Evasion: System Checks×1

Adversaries may employ various system checks to detect and avoid virtualization and analysis environments. This may include changing behaviors based on the results of checks for the presence of artifacts indicative of a virtual machine environment (VME) or sandbox. If the adversary detects a VME, they may alter their malware to disengage from the victim or conceal the core functions of the implant. They may also search for VME artifacts before dropping secondary or additional payloads. Adversaries may use the information learned from Virtualization/Sandbox Evasion during automated discovery to shape follow-on behaviors.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · ATT&CK page ↗

T1574.001Hijack Execution Flow: DLL×1

Adversaries may abuse dynamic-link library files (DLLs) in order to achieve persistence, escalate privileges, and evade defenses. DLLs are libraries that contain code and data that can be simultaneously utilized by multiple programs. While DLLs are not malicious by nature, they can be abused through mechanisms such as side-loading, hijacking search order, and phantom DLL hijacking.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · ATT&CK page ↗

T1622Debugger Evasion×1

Adversaries may employ various means to detect and avoid debuggers. Debuggers are typically used by defenders to trace and/or analyze the execution of potential malware payloads.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · ATT&CK page ↗

Defense Impairment TA0112

T1685Disable or Modify Tools×2

Adversaries may disable, degrade, or tamper with security tools or applications (e.g., endpoint detection and response (EDR) tools, intrusion detection systems (IDS), antivirus, logging agents, sensors, etc.) to impair or reduce visibility of defensive capabilities. This may include stopping specific services, killing processes, modifying or deleting tool configuration files and Registry keys, or preventing tools from updating. This may also include impairing defenses more broadly by disrupting preventative, detection, and response mechanisms across host, network, and cloud environments.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

Credential Access TA0006

T1056.001Input Capture: Keylogging×1

Adversaries may log user keystrokes to intercept credentials as the user types them. Keylogging is likely to be used to acquire credentials for new access opportunities when OS Credential Dumping efforts are not effective, and may require an adversary to intercept keystrokes on a system for a substantial period of time before credentials can be successfully captured. In order to increase the likelihood of capturing credentials quickly, an adversary may also perform actions such as clearing browser cookies to force users to reauthenticate to systems.

Evidence: 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

T1555.003Credentials from Password Stores: Credentials from Web Browsers×1

Adversaries may acquire credentials from web browsers by reading files specific to the target browser. Web browsers commonly save credentials such as website usernames and passwords so that they do not need to be entered manually in the future. Web browsers typically store the credentials in an encrypted format within a credential store; however, methods exist to extract plaintext credentials from web browsers.

Evidence: 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

Discovery TA0007

T1082System Information Discovery×1

An adversary may attempt to get detailed information about the operating system and hardware, including version, patches, hotfixes, service packs, and architecture. Adversaries may use this information to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions. This behavior is distinct from Local Storage Discovery which is an adversary's discovery of local drive, disks and/or volumes.

Evidence: 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

T1497.001Virtualization/Sandbox Evasion: System Checks×1

Adversaries may employ various system checks to detect and avoid virtualization and analysis environments. This may include changing behaviors based on the results of checks for the presence of artifacts indicative of a virtual machine environment (VME) or sandbox. If the adversary detects a VME, they may alter their malware to disengage from the victim or conceal the core functions of the implant. They may also search for VME artifacts before dropping secondary or additional payloads. Adversaries may use the information learned from Virtualization/Sandbox Evasion during automated discovery to shape follow-on behaviors.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · ATT&CK page ↗

T1622Debugger Evasion×1

Adversaries may employ various means to detect and avoid debuggers. Debuggers are typically used by defenders to trace and/or analyze the execution of potential malware payloads.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · ATT&CK page ↗

Collection TA0009

T1056.001Input Capture: Keylogging×1

Adversaries may log user keystrokes to intercept credentials as the user types them. Keylogging is likely to be used to acquire credentials for new access opportunities when OS Credential Dumping efforts are not effective, and may require an adversary to intercept keystrokes on a system for a substantial period of time before credentials can be successfully captured. In order to increase the likelihood of capturing credentials quickly, an adversary may also perform actions such as clearing browser cookies to force users to reauthenticate to systems.

Evidence: 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

T1115Clipboard Data×1

Adversaries may collect data stored in the clipboard from users copying information within or between applications.

Evidence: 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

T1185Browser Session Hijacking×1

Adversaries may take advantage of security vulnerabilities and inherent functionality in browser software to change content, modify user-behaviors, and intercept information as part of various browser session hijacking techniques.

Evidence: 2026-08-02/weekly-w31-malware-keyed-to-the-victim-host · ATT&CK page ↗

Story timeline

  1. 2026-08-02This week's tradecraft was built against the analyst's environment, not the endpoint agent — samples that refuse to run without a keyed argument, loaders that cannot decrypt away from the host they infected, and operators driving the victim's own logged-in session
    weekly-researchFive W31 families converge on environmental keying — the sample will not detonate or decrypt outside its target
  2. 2026-08-01XCSSET v40 turns the macOS `defaults` preference system into a fileless re-infection store and holds an exclusive lock on the XProtect signature database
    active-threatsUnit 42 documents an XCSSET rebuild that lives in memory and disables macOS's own update, telemetry and signature-database channels

Where this entity is cited

  • active-threats1
  • weekly-research1

Source distribution

  • securelist.com3 (50%)
  • blackfog.com1 (17%)
  • securityweek.com1 (17%)
  • unit42.paloaltonetworks.com1 (17%)

explore in graph

Entries about XCSSET (2)

2026-08-02 · view entry permalink →

NOTABLENATOB2

This week's tradecraft was built against the analyst's environment, not the endpoint agent — samples that refuse to run without a keyed argument, loaders that cannot decrypt away from the host they infected, and operators driving the victim's own logged-in session

Most evasion research describes malware hiding from a product. This week's crop describes malware hiding from the process — refusing to reveal itself outside the exact machine it was built for, which defeats the sandbox, the shared sample repository and the offline unpack in one move.

The clearest expression is in the loaders Kaspersky documented against government, healthcare, research and law-enforcement organisations in Central Asia and Syria. OctLurk and SilkLurk both install a Windows service pointing at a malicious loader DLL, and the loader is the interesting part: "the backdoor loaders are customized for each victim and use information from the victim's machine to decrypt the payload. Both the loaders and the backdoors are heavily obfuscated, making analysis more complicated." (Kaspersky Securelist, 2026-07-30). For OctLurk one of the two decryption keys derives from the C: volume serial number and for SilkLurk from a hash of the computer name — meaning a sample pulled off a compromised host and shared with a partner organisation, a vendor or a CERT is inert cryptographic noise to everyone who did not own that machine. Kaspersky assesses a single Chinese-speaking actor behind both at medium confidence while stating it could not attribute the activity to any known group (Kaspersky Securelist, 2026-07-30).

Mirage Kitten's NightLedger applies the same principle to execution rather than decryption: it limits execution to a specific username by "hardcoding a 3-character control value that must appear as a substring in the lowercased Windows username retrieved via GetUserNameA. If the match fails, the implant silently exits, confirming per-target tailoring of each deployed binary." (Kaspersky Securelist, 2026-07-28). A detonation on any analysis VM produces a clean, silent exit — indistinguishable from a benign file. The same toolset also masquerades as SspiCli.dll to load under a legitimate AppVShNotify.exe through RPCRT4.dll's delay-load path (Kaspersky Securelist, 2026-07-28), and Kaspersky's telemetry places its victims in Middle Eastern and African countries rather than the Central Asian set above (Kaspersky Securelist, 2026-07-28).

GenieLocker adds the anti-analysis layer and one deliberate omission that is a direct answer to a common detection. It "starts a new parallel thread called watchdog. It runs in an infinite loop that performs a number of checks to detect well-known debuggers every 500 milliseconds. If at least one of the checks fails, the whole GenieLocker process immediately terminates." (Kaspersky Securelist, 2026-07-30). It also declines to leave the artifact most ransomware detection keys on: "GenieLocker doesn't save the ransom notes on the victim's system. The Trojan doesn't contain any attackers' contact info or negotiation addresses. Instead, the attackers will need to deliver the ransom demands and contacts manually during the attack." (Kaspersky Securelist, 2026-07-30) — a design decision that trades operator convenience for defeating mass-readme-creation heuristics. Its own entry into the analysed environment came through a trusted-partner OpenVPN connection using stolen but still valid credentials (Kaspersky Securelist, 2026-07-30).

The last two attack the defender's tooling and the defender's assumptions rather than their analysis. XCSSET v40 stops leaving scripts on disk between cycles, writing "a Base64-encoded staging payload into a preferences domain it generates per host" (Palo Alto Networks Unit 42, 2026-07-31), and then reaches for the platform's own defences: "the malware spawns a Perl process that tries to acquire and hold access to the endpoint's YARA-rule database (XPdb). This exclusive file lock on the XProtect signature database ensures that if the endpoint does receive a security update, its content could not be written to disk." (Palo Alto Networks Unit 42, 2026-07-31) — the signature update is delivered and then cannot land. And MedusaHVNC removes the anomaly from fraud controls entirely by operating inside the session that is already trusted: "the browser still runs on the victim's device, so it can load an existing profile, including cookies and session state." (BlackFog, 2026-07-27). Its loader is injected into charmap.exe, the standard Windows Character Map utility, using a trusted system binary as the payload host (BlackFog, 2026-07-27); hidden desktops themselves are a legitimate Windows capability used by specialised software (SecurityWeek, 2026-07-27).

Triage: because the samples are inert off-host, the detectable events are the ones the mechanism cannot avoid producing on the victim. For the keyed loaders: a Windows service or scheduled task whose target DLL sits outside the vendor's install tree, reading the volume serial number or computer name shortly before decrypting and mapping executable memory. For GenieLocker: mass file modification with no readme creation, which inverts the usual heuristic, alongside process termination correlated with debugger attachment. For XCSSET: a Perl or scripting process holding an open exclusive handle on the XProtect database, and writes to a per-host preferences domain the user never configured. For MedusaHVNC: creation of a second interactive desktop, and a browser process launched with an existing profile whose parent is a scripting or automation binary rather than the shell — legitimate specialised software does use hidden desktops, so the parent lineage and the profile reuse together are the discriminator rather than the desktop alone.

GenieLocker starts a new parallel thread called watchdog. It runs in an infinite loop that performs a number of checks to detect well-known debuggers every 500 milliseconds. If at least one of the checks fails, the whole GenieLocker process immediately terminates.

GenieLocker doesn't save the ransom notes on the victim's system. The Trojan doesn't contain any attackers' contact info or negotiation addresses. Instead, the attackers will need to deliver the ransom demands and contacts manually during the attack.

Kaspersky Securelist 2026-07-30

The backdoor loaders are customized for each victim and use information from the victim's machine to decrypt the payload. Both the loaders and the backdoors are heavily obfuscated, making analysis more complicated.

Still, it implements the same technique of limiting execution to a specific username on the infected machine by hardcoding a 3-character control value that must appear as a substring in the lowercased Windows username retrieved via GetUserNameA. If the match fails, the implant silently exits, confirming per-target tailoring of each deployed binary.

Kaspersky Securelist (GReAT) 2026-07-30

The malware spawns a Perl process that tries to acquire and hold access to the endpoint's YARA-rule database (XPdb). This exclusive file lock on the XProtect signature database ensures that if the endpoint does receive a security update, its content could not be written to disk.

Palo Alto Networks Unit 42 2026-07-31

The browser still runs on the victim’s device, so it can load an existing profile, including cookies and session state.

BlackFog 2026-07-27

Builds on: 2026-07-31/genielocker-toy-ghouls-no-ransom-note-esxi-ransomware · 2026-07-31/octlurk-silklurk-service-dll-plugin-backdoors-government · 2026-07-29/mirage-kitten-nightledger-proxy-aware-websocket-tunnelers · 2026-08-01/xcsset-v40-macos-defaults-fileless-persistence · 2026-07-28/medusahvnc-hidden-desktop-browser-session-hijacking

research02 Aug 23:57Zmulti-sourceOpen finding ↗

2026-08-01 · view entry permalink →

NOTABLENATOB2

XCSSET v40 turns the macOS `defaults` preference system into a fileless re-infection store and holds an exclusive lock on the XProtect signature database

Unit 42 published a technical analysis of XCSSET v40 on 2026-07-31, describing a rebuild of the long-running macOS family that targets Apple-ecosystem developers. The delivery model is what makes it a supply-chain problem rather than an endpoint one: the malware injects an initial downloader script into benign project files in Xcode projects and vulnerable Git repositories, and "the endpoint infection is triggered only when the developer builds that project locally" (Unit 42, 2026-07-31). Unit 42 records that "since early April 2026, the malware has spread through supply chain attacks by hiding itself in the Xcode projects of dozens of legitimate applications with thousands of active users", with a heightened volume of attacks against developers across South Asia, and states the author has upgraded its worming capability so it "can now infect all existing Xcode projects on a compromised system" (Unit 42, 2026-07-31).

The execution chain is built to leave nothing behind. It runs in four stages before the final payload — a loader script that establishes command-and-control, a fingerprinting stage that pulls further modules, a temporary staging applet that loads the final stage into volatile memory, and the core module itself; once the memory-resident core loop is active "the malware terminates its staging processes and deletes all installation files from the disk" (Unit 42, 2026-07-31). Unit 42 identified seventeen distinct modules delivered dynamically from C2 and executed in memory, and notes that payload binaries are scrambled at compile time, "switching between nested layers of different encryption mechanisms" (Unit 42, 2026-07-31). Unit 42 also describes using AI and pattern-matching to reverse the multi-layered cipher shift that concealed the malware's internal function names, recovering the operator's own naming — a defensive use of the same class of tooling the report elsewhere associates with the attacker's polymorphic generation (Unit 42, 2026-07-31).

The genuinely new tradecraft is the persistence store. Alongside its usual Git hooks, Launch Daemons and trojanised applications, v40 abuses the macOS defaults preference system: "rather than dropping additional scripts on disk between cycles, XCSSET v40 writes a Base64-encoded staging payload into a preferences domain it generates per host", under keys made to look random, and a one-liner run when the victim launches a trojanised or hijacked application retrieves and decodes the blob to re-infect the machine (Unit 42, 2026-07-31). Unit 42 notes that while families such as NetWire and FruitFly have previously misused defaults to store state data, using it as an operational configuration cache "is uncommon in the macOS malware landscape" (Unit 42, 2026-07-31). Practically, this means the re-infection payload lives in a configuration database that most macOS triage workflows do not treat as executable content.

The defence-degradation set is unusually deliberate and is the part a responder should hunt for even without knowing the family. XCSSET v40 sets the software-update configuration channel's values to false, which Unit 42 states prevents the endpoint from automatically retrieving updates to the XProtect, MRT and TCC databases and blocks access to Apple's Rapid Security Response channel (Unit 42, 2026-07-31). It runs a constant loop that hinders the cloud telemetry process from sending security data to Apple, which the report reads as "ensuring that the operator's tooling is not sampled into subsequent XProtect signature releases" (Unit 42, 2026-07-31). It belt-and-braces that with a file lock: "the malware spawns a Perl process that tries to acquire and hold access to the endpoint's YARA-rule database (XPdb). This exclusive file lock on the XProtect signature database ensures that if the endpoint does receive a security update, its content could not be written to disk" (Unit 42, 2026-07-31). And where earlier versions gave up when a user denied an automation prompt, v40 resets the user's TCC decision database for the AppleEvents service and re-presents the prompt, masquerading as System Settings or Xcode (Unit 42, 2026-07-31).

Triage: defaults write is ordinary macOS administration and appears constantly in benign automation, so the command alone is noise. The discriminators the report supports are the shape of the data and the parent: a preferences domain that does not correspond to any installed application, holding long Base64 values under keys that follow no product's naming convention, written by a script interpreter in a build or terminal process lineage rather than by the owning application. Legitimate software writes its own domain under its bundle identifier; this writes a per-host generated one. The defence-degradation cluster gives a second, independent test that needs no attribution: software-update configuration values flipped off, the cloud telemetry process repeatedly terminated, and a long-lived Perl process holding a handle on the XProtect signature database are each individually explicable and collectively not. On the delivery side, a script interpreter spawning from an Xcode build phase, and modifications to Git hooks in repositories no one has intentionally reconfigured, are the earliest points in the chain.

Since early April 2026, the malware has spread through supply chain attacks by hiding itself in the Xcode projects of dozens of legitimate applications with thousands of active users.

Rather than dropping additional scripts on disk between cycles, XCSSET v40 writes a Base64-encoded staging payload into a preferences domain it generates per host.

XCSSET v40 uses the defaults system during initial infection to store and query system information. Misusing defaults as an operational configuration cache is uncommon in the macOS malware landscape.

The malware spawns a Perl process that tries to acquire and hold access to the endpoint's YARA-rule database (XPdb). This exclusive file lock on the XProtect signature database ensures that if the endpoint does receive a security update, its content could not be written to disk.

Palo Alto Networks Unit 42 2026-07-31
threat01 Aug 04:24Zsingle-sourceOpen finding ↗