Apple Xcode

product · product:apple-xcode single-source

Coverage

first 2026-08-01 → last 2026-08-01

Latest activity

2026-08-01

Unit 42 documents an XCSSET rebuild that lives in memory and disables macOS's own update, telemetry and…

Peak priority

notable

1 notable

Targets

technology

sectors: technology, public-sector · regions: apac

Sources cited

1 hosts

Defender insights

What each entry about Apple Xcode tells a defender to do, newest first.

2026-08-01NOTABLEUnit 42 documents an XCSSET rebuild that lives in memory and disables macOS's own update, telemetry and signature-database channels

Defender takeaway

For a public-sector estate the relevant exposure is not the general macOS fleet but the developer subset, anyone building iOS or macOS software in-house or through a supplier, and anyone pulling Xcode projects from public repositories. The infection is triggered by a routine local build, so the control point is what enters the developer's project tree, not what the user clicks. Unit 42's own mitigation list is behavioural: watch for abnormal AppleScript instances, monitor browser launcher paths and block unauthorised file writes there, identify and block creation and modification of abnormal local defaults domains, track ad-hoc-signed applications and untrusted local code signers that bypass Gatekeeper, and run automated supply-chain dependency scanning so poisoned repositories are intercepted before they reach internal pipelines (Unit 42, 2026-07-31). Note also the second-order effect worth checking on any suspect Mac: a host whose macOS signature databases have quietly stopped updating is not merely out of date, it may be held that way.

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.

Story timeline

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

Hunting pivots

Releases covered

Apple Xcode

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 ↗

Persistence TA0003

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

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

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

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

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×1

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-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

T1140Deobfuscate/Decode Files or Information×1

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-01/xcsset-v40-macos-defaults-fileless-persistence · ATT&CK page ↗

Defense Impairment TA0112

T1685Disable or Modify Tools×1

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-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 ↗

Collection TA0009

T1056.001Input Capture: Keylogging×1

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 ↗

Entries about Apple Xcode (1)

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

Defender takeaway

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 →

Sources: Palo Alto Networks Unit 42

Co-occurring entities

Derived: referenced by the same focused operational entries (weekly summaries and report roundups don't count); ×N counts the shared entries.

XCSSET×1
malwaremalware:xcsset

Where this entity is cited

Threats1

Source distribution

unit42.paloaltonetworks.com1 (100%)

All cited sources (1)

unit42.paloaltonetworks.comPalo Alto Networks Unit 42https://unit42.paloaltonetworks.com/xcsset-v40-malware-analysis/
source profile · cited in 2026-08-01