Un falso installer di Zoom usa CloudSyncD per mantenere l’accesso ai Mac

Falso installer Zoom su macOS installa la backdoor CloudSyncD: chiede la password per ottenere privilegi root e mantenere accesso persistente.

Un falso installer di Zoom usa CloudSyncD per mantenere l’accesso ai Mac
Malware

Immagine illustrativa generata con AI

Una campagna per macOS documentata di recente camuffa la backdoor CloudSyncD da installer di Zoom e fa leva sugli utenti, che devono avviare l’applicazione dannosa e inserire la propria password.

I ricercatori di Jamf hanno individuato il malware per la prima volta a metà settembre, quando era ancora in fase di sviluppo. Nel giro di pochi giorni sono comparsi altri campioni, con modifiche che indicano il passaggio dai test alla distribuzione. Le informazioni disponibili non attribuiscono l’attività a un gruppo di minaccia noto né stimano quanti sistemi potrebbero essere stati colpiti.

CloudSyncD è progettato per mantenere l’accesso nel tempo, non per sottrarre dati una tantum. Una volta installato, raccoglie informazioni sul Mac, sul sistema e sull’utente, comunica con l’infrastruttura di comando e controllo e può fungere da canale per la distribuzione di altri payload.

L’attacco inizia con un’immagine disco contraffatta di Zoom

L’operazione sfrutta l’ingegneria sociale per ottenere l’accesso iniziale. La vittima viene indotta a scaricare un’immagine disco che, una volta montata, appare come un volume denominato Zoom, dando l’impressione di contenere il pacchetto d’installazione legittimo di Zoom per Mac.

La vittima deve quindi aprire e avviare l’applicazione. Durante questa procedura, l’installer contraffatto chiede la password dell’utente. Anche se la richiesta può far pensare a un furto di credenziali, l’analisi di Jamf ha rilevato che la password viene usata localmente per eseguire il malware con privilegi di root. Secondo i ricercatori, CloudSyncD non invia la password al proprio server di comando e controllo.

Le fonti citate non indicano che Zoom sia stata violata o che il suo software legittimo sia stato modificato. Il marchio Zoom viene usato per rendere più credibile il pacchetto dannoso.

La distinzione è importante nella gestione degli incidenti. Un avviso relativo al falso installer non dovrebbe essere classificato automaticamente come un’infezione da infostealer tradizionale né considerato una prova del furto delle credenziali Zoom della vittima. L’obiettivo osservato è installare una backdoor persistente con privilegi elevati.

Due copie del payload alimentano la catena di esecuzione del dropper

Il dropper contiene un payload Mach-O universale completo. Nella versione in sviluppo esaminata dai ricercatori, il payload pesava circa 756 KB.

Il loader di CloudSyncD dispone di due copie dello stesso payload. Può estrarre quella incorporata durante l’esecuzione; un’altra è archiviata sul disco all’interno del bundle dell’applicazione. In questo modo, durante l’installazione il dropper può recuperare l’eseguibile della backdoor da più di una fonte.

Il primo metodo di esecuzione evita di scrivere il payload in un normale file con nome. Il dropper lo inserisce in un descrittore di file anonimo e prova ad avviarlo da lì. Jamf riferisce che il metodo in genere non funziona a causa della System Integrity Protection di macOS, o SIP.

Il malware passa quindi a una procedura più convenzionale: scrive temporaneamente il payload su disco e lo avvia tramite sudo, fornendo la password inserita dall’utente durante l’attivazione. Se l’esecuzione riesce, il malware ottiene i privilegi di root e può installarsi come daemon denominato CloudSyncD.

La SIP ostacola quindi il metodo di esecuzione preferito, ma non blocca da sola l’intera catena se la vittima ha già fornito le proprie credenziali. La procedura alternativa mostra perché sia importante prestare attenzione alle richieste di password durante installazioni apparentemente ordinarie, soprattutto quando il software proviene da fonti non approvate dall’organizzazione.

CloudSyncD è progettato per mantenere l’accesso, non per rubare dati

Una volta attivo, CloudSyncD decifra i dati di configurazione incorporati nel binario e avvia le proprie operazioni di backdoor. Jamf attribuisce al malware diverse funzionalità principali:

  • raccogliere informazioni sul Mac compromesso;
  • acquisire dettagli sul sistema e sull’utente;
  • effettuare attività di ricognizione sull’host;
  • inviare le informazioni raccolte all’infrastruttura di comando e controllo;
  • mantenere l’accesso nel tempo;
  • consentire la distribuzione di payload successivi.

Sulla base di queste funzionalità, i ricercatori classificano CloudSyncD come una backdoor, non come un tipico infostealer. Il malware raccoglie informazioni sulla macchina, ma le funzionalità analizzate non corrispondono al modello classico di furto di credenziali, dati del browser o portafogli digitali, comune agli stealer per macOS di largo consumo.

Questa distinzione limita anche ciò che si può dedurre dalla sola infezione iniziale. CloudSyncD permette di distribuire altri payload, ma le fonti non specificano quali altri strumenti, se presenti, siano stati installati sui singoli sistemi. Chi interviene dovrebbe quindi esaminare le attività successive, senza dare per scontata una specifica famiglia di malware di secondo stadio.

Non è stato identificato alcun operatore. Nelle valutazioni di attribuzione è quindi opportuno tenere distinti la famiglia di malware, la persona o il gruppo che la controlla e la specifica campagna che ha distribuito gli installer.

Dagli artefatti di sviluppo ai campioni pronti per la distribuzione

Il primo campione esaminato da Jamf mostrava ancora segni di sviluppo attivo. La configurazione di comando e controllo indicava un indirizzo di rete privato e l’output di debug dettagliato era ancora abilitato.

Le build successive utilizzavano endpoint C2 diversi, a sostegno della valutazione dei ricercatori secondo cui il progetto stava superando la fase dei test interni. Nonostante i cambiamenti agli endpoint, i campioni mantenevano numerose caratteristiche comuni.

Jamf ha rilevato la stessa tabella di offuscamento delle stringhe, gli stessi percorsi d’installazione, nome del daemon, travestimento del processo, chiave C2, vettore di inizializzazione e seed per stringa in tutte le build. Questi elementi ricorrenti collegano tecnicamente i campioni, anche quando le destinazioni di rete sono diverse.

Il materiale crittografico condiviso è utile anche a fini difensivi. Secondo i ricercatori, il materiale recuperato da una qualsiasi build permette di decifrare il traffico beacon acquisito e associato ai campioni correlati. Anche la coerenza degli artefatti presenti sugli host può favorire il rilevamento di più versioni, non soltanto del primo file analizzato.

La campagna ha usato due domini distinti per ospitare più build. Entrambi erano stati registrati nel 2011 tramite lo stesso registrar e operavano dietro l’infrastruttura di Cloudflare. Questo non indica un coinvolgimento di Cloudflare.

Entrambi usavano inoltre lo stesso percorso URI, formattato per sembrare una richiesta di uno script jQuery. L’obiettivo apparente era far passare i beacon C2 per normali richieste di file JavaScript nei log di rete. Secondo le fonti sui risultati dell’analisi di Jamf, al momento della pubblicazione i domini non risultavano associati a rilevamenti.

I ricercatori hanno fornito un elenco IOC più ampio, ma le informazioni disponibili non riportano i nomi dei domini, l’URI, gli endpoint, gli hash, i valori crittografici o altri indicatori precisi. Questi dati non vanno ricostruiti né dedotti sulla base della descrizione comportamentale.

Indagare la sequenza che porta dall’installer al daemon

Questa campagna si basa sulla distribuzione di software dannoso, non su una vulnerabilità di Zoom o di macOS resa nota. Le fonti non descrivono patch del fornitore, versioni del prodotto interessate o soluzioni alternative.

I difensori possono comunque usare la sequenza di esecuzione osservata come modello d’indagine. Tra gli elementi da verificare figurano il montaggio di un’immagine disco non attendibile come Zoom, la richiesta di una password da parte dell’installer, un tentativo fallito di avviare un Mach-O da un descrittore di file anonimo e la successiva esecuzione da disco tramite sudo.

I team dovrebbero anche verificare la presenza del daemon CloudSyncD sui Mac interessati e correlare la sua creazione con le attività d’installazione, l’elevazione dei privilegi e il traffico in uscita che imita il recupero di script jQuery. Poiché qui non sono riportati i percorsi e gli indicatori di rete precisi, questi elementi sono spunti per l’indagine comportamentale, non regole di rilevamento già pronte.

Le organizzazioni possono ridurre il rischio indirizzando gli utenti verso canali di distribuzione software approvati e trattando come potenziali eventi di sicurezza le richieste di password inattese da parte di installer scaricati. In caso di sospetta attività di CloudSyncD, chi interviene dovrebbe verificare sia la persistenza sia l’eventuale esecuzione di payload successivi. Eliminare soltanto l’immagine disco originale non basta se la backdoor è già stata installata con privilegi elevati.

Le prove disponibili documentano una famiglia di malware tecnicamente coerente e un’operazione di distribuzione in evoluzione. Non permettono invece di stabilire l’ampiezza della campagna, l’identità delle vittime o quella dell’operatore.

Dossier sicurezza

Leggi anche

Fonti

Questo articolo è una rielaborazione originale basata sulle fonti seguenti.

Torna alla home

Ultime notizie di cybersecurity

Tutte le notizie di cybersecurity →