XCSSET v40 infetta i progetti Xcode e trasforma i Mac in vettori supply chain

🛡️ Executive Summary

• XCSSET v40 inserisce un downloader nei progetti Xcode e si attiva quando lo sviluppatore esegue la compilazione sul proprio Mac.
• Diciassette moduli rubano credenziali, manipolano clipboard e browser, infettano Telegram e ostacolano gli aggiornamenti di sicurezza Apple.
• La difesa richiede controllo dei repository, verifica delle build phase, monitoraggio di AppleScript e isolamento delle workstation compromesse.

XCSSET è tornato con una versione profondamente rinnovata che trasforma i computer degli sviluppatori Apple in strumenti di propagazione della supply chain. La variante v40 compromette progetti Xcode e repository Git, si attiva durante la compilazione e distribuisce un framework modulare capace di rubare credenziali, intercettare la clipboard, controllare Chrome e manipolare Telegram. Il malware introduce inoltre persistenza fileless, payload polimorfici e tecniche progettate per ostacolare XProtect, gli aggiornamenti di sicurezza e la telemetria di macOS. La nuova campagna è stata osservata dalla primavera 2026, con una particolare concentrazione di bersagli tra gli sviluppatori dell’Asia meridionale.

XCSSET v40 si attiva durante la compilazione dei progetti

La catena di infezione inizia quando gli attaccanti inseriscono un downloader all’interno di file apparentemente legittimi appartenenti a un progetto Xcode o a un repository Git compromesso. Il codice non deve necessariamente essere eseguito manualmente dalla vittima: si attiva quando lo sviluppatore apre e compila il progetto sul proprio Mac.

Questa caratteristica rende XCSSET particolarmente pericoloso perché sfrutta un’attività normale del ciclo di sviluppo e può propagarsi quando il codice viene condiviso con colleghi, collaboratori o altri repository. La famiglia utilizza questa tecnica almeno dal 2020 e aveva già mostrato una capacità costante di evoluzione, come documentato quando XCSSET aveva aggiunto Python 3 per colpire macOS Monterey. Nella nuova analisi tecnica di Unit 42 su XCSSET v40, i ricercatori spiegano che il malware è stato individuato in una prima ondata a metà aprile 2026 e in una seconda fase all’inizio di maggio, quando gli operatori hanno introdotto un insieme più ampio di moduli.

La catena comprende quattro stadi: il loader iniziale stabilisce il contatto con il comando e controllo, il secondo componente raccoglie informazioni sul sistema, il terzo crea un’applicazione temporanea e il quarto carica nella memoria il nucleo operativo. Al termine della sequenza, i processi di staging vengono chiusi e i file di installazione cancellati, lasciando attivo un orchestratore residente in memoria.

Diciassette moduli rubano dati e controllano le applicazioni

Unit 42 ha identificato 17 moduli, distribuiti dinamicamente dall’infrastruttura di comando e controllo in base al profilo del sistema compromesso. Le funzioni includono keylogging, furto di credenziali, esfiltrazione di file, monitoraggio della clipboard e manipolazione dei browser. La nuova variante aggiunge una backdoor dedicata a Google Chrome, che sfrutta il Chrome DevTools Protocol per controllare il browser attraverso funzioni legittime di debugging. XCSSET sostituisce il normale avvio di Chrome con uno script wrapper che lancia il browser con parametri scelti dagli attaccanti, permettendo al malware di interagire con schede, cookie, sessioni e contenuti visualizzati.

La tecnica riduce la necessità di decifrare direttamente i database protetti del browser, perché è Chrome stesso a restituire dati già accessibili durante la sessione dell’utente. Il malware integra anche un trojanizer per Telegram, utilizzato per modificare l’applicazione installata e ottenere accesso alle sue funzioni o ai dati trattati. La superficie si aggiunge alle capacità già osservate nelle precedenti varianti, quando Microsoft aveva rilevato nuovi moduli XCSSET contro browser, wallet e ambienti macOS. La compromissione della workstation di uno sviluppatore ha inoltre un valore superiore al furto dei soli dati personali: il computer può contenere repository privati, token GitHub, certificati di firma, segreti delle pipeline, credenziali cloud e accessi alle infrastrutture di build.

Polimorfismo e cifratura cambiano continuamente gli indicatori

XCSSET v40 adotta un’architettura polimorfica che rende meno efficaci le difese basate esclusivamente su hash e firme statiche. Il loader viene ricompilato periodicamente sul server degli attaccanti e può presentare più impronte digitali nell’arco della stessa giornata. Unit 42 ha osservato otto hash differenti consegnati a un singolo endpoint in 24 ore. I moduli vengono cifrati con AES-256-CBC, utilizzando chiavi specifiche per ogni build e vettori di inizializzazione casuali, mentre le comunicazioni in entrata e in uscita adottano chiavi separate. Anche le stringhe, i nomi delle funzioni e le variabili vengono trasformati prima della compilazione attraverso cifrari e alfabeti generati dinamicamente.

Il risultato è un malware nel quale due copie funzionalmente identiche possono apparire diverse agli strumenti di analisi. Questa capacità non rappresenta una novità assoluta nel panorama macOS, dove campagne come ClickFix hanno distribuito Atomic Stealer attraverso annunci e falsi comandi, ma XCSSET combina l’evasione con un vettore supply chain capace di contaminare automaticamente altri progetti. La sicurezza non può quindi dipendere soltanto dal controllo del file scaricato: deve osservare il comportamento della compilazione, le modifiche alle build phase, l’esecuzione inattesa di osascript, Bash e curl e la creazione di processi non previsti dal progetto.

La persistenza fileless sfrutta le preferenze di macOS

La variante v40 introduce un meccanismo di persistenza che utilizza il comando defaults, normalmente impiegato da macOS per gestire preferenze e configurazioni delle applicazioni. Il malware crea un dominio con un nome variabile e salva al suo interno un payload di staging codificato in Base64. Quando viene avviata un’applicazione trojanizzata, un progetto Xcode infetto o un browser manipolato, il codice recupera il contenuto dalle preferenze, lo decodifica e riattiva l’infezione senza dover mantenere sul disco uno script facilmente riconoscibile. XCSSET conserva parallelamente i vecchi metodi basati su hook Git, LaunchDaemon e applicazioni modificate, costruendo più percorsi di recupero. La stessa logica di esecuzione nascosta negli strumenti legittimi era stata osservata con MacSync e le campagne ClickFix contro gli utenti macOS, ma XCSSET sfrutta direttamente i meccanismi di sviluppo e le preferenze del sistema per reinfettare l’host. Gli amministratori devono quindi controllare la creazione di domini defaults anomali, valori Base64 di grandi dimensioni, nuovi LaunchDaemon e modifiche agli hook presenti nelle cartelle .git. Anche la cancellazione del progetto originariamente compromesso può essere insufficiente quando il malware ha già contaminato altri repository locali o introdotto un secondo metodo di persistenza.

XCSSET tenta di neutralizzare le difese native di Apple

Il malware modifica le impostazioni del canale SoftwareUpdate per impedire il recupero automatico degli aggiornamenti di XProtect, Malware Removal Tool e delle Rapid Security Response. Avvia inoltre un ciclo che termina CloudTelemetryService, riducendo l’invio ad Apple di dati potenzialmente utili per identificare la minaccia, e utilizza un processo Perl per mantenere un lock esclusivo sul database delle firme XProtect. Anche quando un aggiornamento raggiunge il dispositivo, il blocco può impedirne la corretta scrittura sul disco. XCSSET interviene infine sul sistema Transparency, Consent and Control, che governa autorizzazioni sensibili come l’accesso ad automazione, microfono, fotocamera e file. Se l’utente nega una richiesta AppleEvents, il malware esegue tccutil reset AppleEvents, cancella la decisione e ripropone la finestra fingendosi Impostazioni di Sistema o Xcode. Prima di distribuire i moduli principali, v40 controlla inoltre processore e caratteristiche hardware per stabilire se il sistema sia una macchina virtuale. Gli host considerati sandbox non ricevono i payload più sensibili, ostacolando l’analisi automatizzata. Queste tecniche mostrano che Gatekeeper e XProtect restano componenti importanti, ma non possono proteggere da soli una workstation sulla quale il codice viene eseguito all’interno di un progetto autorizzato dallo sviluppatore.