The emergence of XCSSET version 40 demonstrates how attackers are increasingly targeting software developers and the trusted development environments used to build and distribute applications. Rather than depending on conventional phishing attachments or fake software installers, the malware spreads by inserting malicious code into legitimate Xcode projects and activating when a developer builds the compromised project. 

Xcode is Apple’s official development environment for creating applications across macOS, iOS and other Apple platforms. Developers commonly download sample projects, clone repositories, reuse open-source code and exchange projects with colleagues. XCSSET exploits this normal workflow by hiding its downloader inside project files that appear to be part of an ordinary software-development process.

When a developer builds an infected project, the hidden script downloads and activates the malware. XCSSET then searches the compromised Mac for additional Xcode projects and infects them as well. If those projects are later uploaded to a repository or shared with another developer, the malware can continue spreading through the software-development community.

This makes XCSSET more than an endpoint malware infection. It creates a software supply-chain risk in which one compromised developer can unknowingly distribute malicious project files to colleagues, customers and downstream contributors.

Compromised repositories become the initial delivery channel

Researchers found that the attackers gained access to vulnerable Git repositories and injected downloader scripts into otherwise legitimate files within Xcode projects. Developers who trusted and downloaded those repositories could become infected simply by compiling the code.

This approach is effective because source-code repositories are central to modern development. Developers are accustomed to cloning projects and building them locally, particularly when evaluating libraries, testing examples or contributing to open-source applications.

A project hosted on a familiar platform may appear trustworthy because it has a legitimate history, known contributors and normal source files. However, a compromised maintainer account, exposed access token or vulnerable repository can allow attackers to insert malicious build instructions without creating an obviously fraudulent project.

The attack also benefits from the fact that developers expect build systems to execute scripts. Xcode projects can include build phases, shell commands and configuration logic required to compile and package an application. Malicious commands hidden within these mechanisms may therefore execute through functionality that is entirely legitimate from Xcode’s perspective.

Developers should treat project build instructions as executable code rather than harmless configuration. Building an unfamiliar project can provide that project with an opportunity to run commands under the developer’s account.

The infection spreads from one Xcode project to another

After compromising the developer’s Mac, XCSSET searches for other Xcode projects stored on the system and inserts its payload into them.

This propagation method allows one initial infection to contaminate multiple projects belonging to the same developer or organization. Some of those projects may later be committed to Git repositories, shared with coworkers or distributed as sample code.

The malware therefore uses the developer’s normal collaboration workflow as its distribution infrastructure. It does not need to compromise every repository or developer directly when infected project files can carry it into new environments.

This creates a particularly difficult incident-response challenge because the affected organization must investigate not only the infected Mac but also every project that the developer opened, modified, built or shared during the compromise period.

Deleting the malware from the endpoint does not automatically remove malicious scripts already inserted into source repositories, local branches, archived project copies or shared development folders.

Organizations must identify which projects were contaminated, determine whether they were committed to central repositories and examine whether other developers subsequently built them.

A clean developer machine can become reinfected if it later builds a project that still contains the malicious XCSSET loader.

The latest version uses a four-stage infection process

The analysed XCSSET variant uses a four-stage infection chain before deploying its wider collection of malicious modules.

Separating the attack into stages allows the operators to keep the initial project-based payload relatively small while downloading additional capabilities only after the developer’s system has been successfully compromised.

This design also gives the attackers flexibility. Individual components can be updated or replaced on the command-and-control server without modifying every infected project.

Security tools examining only the first embedded script may see a downloader rather than the full information-stealing and remote-control functionality. The later modules can arrive after the initial build process has completed.

Organizations should therefore correlate Xcode build activity with subsequent script execution, downloads, process creation and network connections. An Xcode project launching AppleScript, shell commands or unfamiliar network requests during compilation should receive immediate scrutiny.

Build processes usually have predictable behaviour. A project unexpectedly contacting an unknown server, downloading encrypted content or modifying user applications is not a normal compilation requirement, regardless of how confidently the project’s README insists otherwise.

Seventeen modules support extensive information theft

The latest XCSSET version deploys 17 separate modules capable of credential theft, keylogging, clipboard monitoring, browser manipulation and data exfiltration.

A modular architecture allows the attackers to perform different actions according to the infected system and the information available on it. Some modules may target browsers, while others focus on cryptocurrency activity, messaging applications or local files.

Developers are particularly valuable targets because their Macs may contain source-code access, cloud credentials, API tokens, signing certificates, SSH keys and active sessions for internal systems.

A developer’s browser may also contain authentication cookies for code repositories, cloud consoles, project-management platforms and corporate applications. Stealing those sessions can give attackers access without requiring the account password or repeating the original multi-factor authentication process.

Keylogging can capture credentials and sensitive information as the user types, while clipboard monitoring can identify copied passwords, commands and cryptocurrency addresses.

The malware’s ability to exfiltrate files also creates a risk to proprietary source code, product plans, internal documentation and customer information stored within project directories.

Chrome hijacking provides deep browser access

One of the two new components in XCSSET v40 is a Chrome hijacker that wraps the legitimate browser inside a malicious launcher.

The component starts Chrome with the Chrome DevTools Protocol enabled on a local port. The malware then retrieves JavaScript from its command-and-control infrastructure and uses the browser’s debugging interface to manipulate activity within Chrome.

The Chrome DevTools Protocol is a legitimate feature used by developers, testing tools and automation frameworks. It provides powerful control over browser tabs, page content, network requests and JavaScript execution.

When abused by malware, the same functionality can allow attackers to observe and modify web activity from inside the browser.

The XCSSET component can reportedly intercept credentials, cookies and web traffic. It can also target MetaMask cryptocurrency transactions and alter them while the user is interacting with the browser.

Because the manipulation occurs within the browser session, the victim may see the expected website and believe that the transaction or login process is operating normally.

The malware can potentially modify information immediately before submission, allowing an attacker to change a cryptocurrency destination or capture credentials without displaying an obviously fake website.

Browser cookies can bypass password and MFA protection

The theft of browser cookies is especially serious because session cookies are often issued after the user has successfully entered a password and completed multi-factor authentication.

An attacker who obtains a valid session token may be able to access the associated account as an already authenticated user. Depending on the service’s security controls, the attacker may not need to know the password or repeat MFA.

Organizations responding to an XCSSET infection should therefore revoke active browser sessions rather than relying only on password changes.

Important accounts should be reviewed for new devices, authentication methods, application permissions and suspicious activity. Repository, cloud and developer-platform tokens stored in the browser may also require rotation.

Services should use device-bound sessions and require fresh authentication for sensitive actions where possible. Sign-ins involving a valid cookie from an unfamiliar device or location should not automatically be treated as legitimate.

The browser has become one of the most important authentication stores on a modern workstation. Protecting the password while ignoring the authenticated session created afterward leaves attackers with an easier prize.

MetaMask transactions can be manipulated

The Chrome hijacker can monitor and modify MetaMask cryptocurrency transactions, potentially changing transaction details before they are authorised.

Cryptocurrency transfers are particularly attractive to attackers because they are generally irreversible. Once funds are sent to an attacker-controlled address, there may be no financial institution capable of cancelling or recovering the payment.

Users may believe they are approving the address shown by a legitimate application, while malware operating within the browser changes the underlying destination.

For high-value transactions, users should verify the destination address on an independent trusted device or hardware-wallet screen rather than relying solely on information displayed in the potentially compromised browser.

A small test transaction can also reduce the risk of transferring the complete amount to an incorrect address, although it cannot protect against malware that waits and alters only later transactions.

Anyone who used cryptocurrency applications or browser wallets on an infected Mac should assume that relevant credentials and transaction information may have been exposed. Wallet funds may need to be migrated to new keys created on a trusted device.

A fileless reverse shell expands attacker control

The Chrome hijacking component also supports system-command execution through a fileless reverse shell.

A reverse shell gives the attacker an interactive command channel on the infected device. Commands can be executed, files can be inspected and additional malware can be deployed remotely.

Fileless execution reduces the amount of malicious content written permanently to disk, making detection through ordinary file scanning more difficult.

The attacker may operate through legitimate processes and memory-resident scripts rather than installing one clearly identifiable backdoor application.

Google has introduced protections against this type of Chrome-based command execution on Windows and is working to extend similar protections to macOS. However, organizations should not depend entirely on browser-level corrections when the underlying Mac is already compromised.

Endpoint monitoring should identify unusual Chrome launch arguments, unexpected use of debugging ports and browser processes initiating shell commands or communicating with unfamiliar local services.

Chrome should not normally function as a remote command console. When it begins behaving like one, the correct response is investigation rather than admiration for browser extensibility.

Telegram is replaced with a trojanized version

The second new component removes the legitimate Telegram Desktop application and replaces it with a malicious version.

Replacing a trusted messaging application gives attackers an opportunity to intercept communications, capture authentication information or monitor activity within the victim’s account.

Unit 42 could not retrieve the module’s encrypted configuration, so its complete functionality has not been established publicly. The component should therefore be described as potentially capable of intercepting Telegram activity rather than claiming specific unconfirmed behaviour.

The technique nevertheless demonstrates how XCSSET extends persistence and surveillance by modifying applications that users already trust and open regularly.

A malicious Telegram application may retain the expected icon, name and visible functionality. The user could continue sending messages without realizing that the installed application has been replaced.

Organizations should verify application signatures and installation paths during an investigation. An application that appears legitimate in the Dock or Applications folder may still have been altered or substituted.

Users should reinstall affected applications from verified official sources only after the underlying malware has been removed.

The malware attacks macOS security controls

XCSSET attempts to weaken several macOS security technologies, including XProtect, the Malware Removal Tool, Transparency, Consent and Control protections, and Rapid Security Response.

The malware also terminates Apple’s CloudTelemetryService and attempts to prevent XProtect signature updates.

XProtect provides built-in malware detection, while the Malware Removal Tool supports removal of known threats. TCC controls access to sensitive resources such as files, the camera, microphone and accessibility functions.

Disabling or interfering with these controls can help XCSSET operate longer, access protected information and avoid detection by updated signatures.

The attempt to stop Rapid Security Response and XProtect updates is particularly important because it can prevent the device from receiving new protections after Apple or security researchers identify the malware.

Organizations should monitor changes to macOS security settings and processes. Attempts by user-level scripts to disable security services, terminate telemetry or alter update behaviour should be treated as high-risk activity.

Users should not be able to disable endpoint protection or system security controls without generating administrative alerts.

The fact that malware tries to disable these features also demonstrates that built-in macOS protections matter. Attackers would not invest effort in neutralising controls that provided no obstacle.

Frequent recompilation helps evade signature detection

The latest variant periodically recompiles its loader on the command-and-control server, producing changing versions that may have different file hashes.

Hash-based detection depends on identifying a known malicious file. Recompiling the same functionality can generate a new binary that no longer matches the earlier signature.

The malware also obfuscates function names, variables and strings and uses build-specific encryption ciphers. These changes make static analysis more difficult and reduce the usefulness of indicators based only on one sample.

Separate encryption keys are used for inbound and outbound communication, further complicating inspection and analysis.

Security teams must therefore focus on behaviour rather than waiting for an exact hash match.

An Xcode build modifying unrelated projects, a browser launching with an unexpected debugging port, Telegram being replaced and macOS security services being disabled remain suspicious regardless of how many times the attacker recompiles the loader.

Behavioural detection is more resilient because it identifies what the malware does rather than only what one version looks like.

AppleScript activity deserves monitoring

Unit 42 recommends monitoring for unusual AppleScript execution because XCSSET uses scripting as part of its infection and post-compromise activity.

AppleScript is a legitimate macOS automation language capable of controlling applications, interacting with the user interface and running shell commands.

Developers and administrators may use it for valid automation, which means organizations cannot classify all AppleScript activity as malicious.

The relevant context includes which process launched AppleScript, which commands it executed and whether the activity followed the build of an unfamiliar Xcode project.

Xcode launching obfuscated AppleScript that modifies browser applications, security settings or shell configuration is not a normal development operation.

Endpoint products should record script content or command-line arguments where possible and correlate them with project builds and network activity.

Ad hoc-signed applications may indicate Gatekeeper bypass

Researchers also recommend watching for ad hoc-signed applications that may bypass or weaken normal Gatekeeper expectations.

Code signing allows macOS to verify the identity associated with an application and whether its contents have changed. Ad hoc signing provides code-signing structure without establishing a trusted developer identity.

Attackers may use it to make modified applications appear technically signed while avoiding the requirements and accountability associated with a valid Apple developer certificate.

Security teams should investigate unfamiliar ad hoc-signed applications, particularly when they imitate Chrome, Telegram, System Settings or other trusted software.

Signature status should be considered together with the application path, download origin and behaviour. A valid or technically present signature does not automatically make an application legitimate.

Organizations can use application-control and endpoint-security policies to restrict unsigned or ad hoc-signed software outside approved development workflows.

Developers may legitimately build unsigned test applications, so controls need to distinguish trusted project directories and tools from unexpected applications appearing in temporary or user-controlled locations.

Developer workstations are privileged assets

The campaign reinforces that developer Macs should be treated as privileged enterprise systems.

Developers often possess access to private repositories, software-signing credentials, cloud platforms, build infrastructure and internal testing environments.

Compromise of a developer device can therefore lead to source-code theft, malicious repository changes, unauthorized releases and wider supply-chain compromise.

Organizations sometimes give developer systems fewer restrictions because development requires installing tools, running scripts and compiling untrusted code. That flexibility is operationally necessary but must be balanced with stronger monitoring and isolation.

Developer endpoints should use managed security software, full-disk encryption, strong authentication and centralized logging. Sensitive credentials should be stored in secure credential managers rather than plaintext configuration files or shell histories.

Production credentials and signing keys should not remain continuously accessible on ordinary development workstations.

Privileged release activity should occur through protected build systems with reviewed workflows and short-lived credentials.

A compromised developer laptop should not automatically provide authority to publish production software.

Repositories must be inspected before building

Developers should review Xcode projects obtained from public repositories, external contributors or unfamiliar sources before opening and compiling them.

The review should include project build phases, shell scripts, `.pbxproj` configuration, package dependencies and hidden or unusually encoded files.

Unexpected scripts that contact external servers, decode Base64 data, use `curl`, execute AppleScript or modify other projects should receive immediate scrutiny.

Repository history can help identify when suspicious changes were introduced and which account committed them. However, a trusted contributor name or signed commit should not replace inspection of the actual change.

Organizations should use automated repository scanning to identify dangerous build commands and changes to Xcode project configuration.

Dependency and source-code scanning should occur before projects enter the approved development pipeline.

A project should not be considered safe merely because it builds successfully. In this campaign, successful compilation is precisely what starts the infection.

Incident response must include source repositories

When XCSSET is detected on a developer Mac, the response must extend beyond cleaning the endpoint.

Security teams should identify every Xcode project present on the system and determine whether the malware modified it.

Local branches, cloned repositories, archived projects and removable media should be reviewed. Central Git repositories should be searched for malicious build phases and downloader scripts.

Commits made by the affected developer during the compromise period should receive additional scrutiny, even when they appear unrelated to the original infected project.

Other developers who cloned or built potentially contaminated projects should have their systems examined.

CI/CD runners that processed affected projects must also be treated as potentially compromised. The malware may execute anywhere the Xcode project is built, not only on the original developer’s Mac.

Published applications produced from affected projects should be reviewed to determine whether malicious components entered the final build.

The precise propagation behaviour must be established before the organization can confidently return the repository to normal use.

Credential rotation must follow containment

Credentials accessible from the infected Mac should be considered potentially compromised. These may include Git tokens, SSH keys, cloud credentials, Apple developer certificates, package-registry tokens and application passwords.

Active browser sessions should be revoked, particularly for source-code repositories, email, cloud platforms and administrative services.

Credential rotation should occur from a separate trusted device after the infected endpoint has been isolated. Changing credentials while the malware remains active may simply expose the new values.

Repository access logs should be reviewed for unusual cloning, token creation, commits and authentication from unfamiliar locations.

Apple developer accounts should be checked for unknown certificates, provisioning profiles and application submissions.

If code-signing keys may have been exposed, organizations should evaluate revocation and replacement. Software signed during the compromise period may require review because attackers could use legitimate keys to make malicious code appear authentic.

Rebuilding may be safer than limited cleanup

XCSSET modifies projects, applications, browser behaviour and macOS security controls while deploying numerous modules. This makes reliable manual cleanup difficult.

Where complete system integrity cannot be established, rebuilding the Mac from a trusted image is safer than deleting selected files and assuming the threat has been removed.

User data and source code should be restored only after inspection to avoid reintroducing infected Xcode projects.

Applications should be reinstalled from official sources, and the device should receive current macOS and security updates before returning to service.

Rebuilding removes local malware but does not reverse credential theft or repository contamination. Those parts of the response must continue independently.

Enhanced monitoring should remain in place after recovery because attackers may retain access through stolen tokens, compromised accounts or infected shared projects.

The broader cybersecurity lesson

The new XCSSET variant demonstrates how software-development workflows can become malware-distribution systems when trusted projects are compromised.

The attacker does not need to convince a developer to run an unfamiliar application. The developer performs the expected action by building source code, and the malicious project uses that trusted process to execute.

Once active, XCSSET contaminates additional projects, steals credentials, hijacks Chrome, replaces Telegram, manipulates cryptocurrency activity and weakens macOS security protections.

The result is both an endpoint compromise and a potential supply-chain incident.

Organizations must therefore secure source repositories, development endpoints and build pipelines as one connected environment.

Developers should inspect projects before building them, while security teams should monitor unusual build scripts, AppleScript activity, browser modifications and changes to system security services.

Source repositories should be scanned continuously, and development credentials should be short-lived, narrowly scoped and separated from production authority.

The incident also reinforces that macOS is not inherently protected from malware merely because it includes strong built-in controls. XCSSET actively targets those controls and exploits the trust placed in development tools and shared code.

The most dangerous part of the campaign is not one new malware module. It is the propagation model.

A compromised project can infect a developer, the infected developer can contaminate more projects and those projects can reach additional developers and build environments.

That cycle converts ordinary collaboration into a distribution chain for the attacker.

Software development depends on sharing code, but shared code must never receive automatic trust. Every project, dependency and build instruction introduces executable behaviour into a privileged environment.

When developers build software, they are not merely producing an application. They are granting the project an opportunity to operate on the machine performing the build.

XCSSET succeeds by hiding malicious behaviour inside that opportunity. Defending against it requires treating the development process itself as part of the organization’s security perimeter.

A new version of the XCSSET malware is targeting thousands of macOS users through compromised Xcode projects and GitHub repositories. [...]

Source: New XCSSET variant targets macOS devs via compromised Xcode projects via Bleeping Computer — published 04 Aug 2026.