Gefälschter Zoom-Installer verschafft CloudSyncD dauerhaften Zugriff auf Macs
Gefälschter Zoom-Installer installiert CloudSyncD-Backdoor auf Macs: Tarnung, Passwortabfrage, Root-Rechte und dauerhafter Fernzugriff erklärt.
Illustration mit KI erzeugt
Bei einer kürzlich dokumentierten macOS-Kampagne wird die Backdoor CloudSyncD als Zoom-Installer getarnt. Damit sie aktiv wird, müssen Nutzer die schädliche Anwendung starten und ihr Passwort eingeben.
Forscher von Jamf beobachteten die Malware erstmals Mitte September in der Entwicklung. Innerhalb weniger Tage tauchten weitere Samples auf, deren Veränderungen auf einen Übergang von Tests hin zum Einsatz hindeuteten. In den verfügbaren Berichten wird die Aktivität weder einem bekannten Bedrohungsakteur zugeordnet noch die Zahl der möglicherweise betroffenen Systeme beziffert.
CloudSyncD ist auf dauerhaften Zugriff statt auf einmaligen Datendiebstahl ausgelegt. Nach der Installation erstellt die Malware ein Profil des Macs, sammelt System- und Nutzerdaten, kommuniziert mit einer Command-and-Control-Infrastruktur und kann als Kanal zur Auslieferung weiterer Payloads dienen.
Der Angriff beginnt mit einem gefälschten Zoom-Disk-Image
Für den Erstzugriff setzen die Angreifer auf Social Engineering. Das Opfer wird dazu verleitet, ein Disk-Image herunterzuladen, das als Volume mit dem Namen Zoom eingebunden wird. So entsteht der Eindruck, es handle sich um ein legitimes Installationspaket für Zoom auf dem Mac.
Anschließend muss das Opfer die Anwendung öffnen und aktivieren. Dabei fordert der gefälschte Installer das Nutzerpasswort an. Das ähnelt zwar einem Versuch, Zugangsdaten zu stehlen, doch laut der Analyse von Jamf wird das Passwort lokal verwendet, um die Malware mit Root-Rechten auszuführen. Den Forschern zufolge überträgt CloudSyncD das Passwort nicht an seinen Command-and-Control-Server.
Die vorliegenden Berichte enthalten keine Hinweise darauf, dass Zoom selbst kompromittiert oder dessen legitime Software verändert wurde. Vielmehr wird die Marke Zoom imitiert, um das schädliche Paket glaubwürdiger erscheinen zu lassen.
Diese Unterscheidung ist bei der Bewertung eines Vorfalls wichtig. Eine Warnung im Zusammenhang mit dem gefälschten Installer sollte nicht automatisch als Infektion mit einem herkömmlichen Infostealer oder als Beleg für den Diebstahl der Zoom-Zugangsdaten des Opfers eingestuft werden. Das beobachtete Ziel ist die privilegierte Installation einer persistenten Backdoor.
Zwei Payload-Quellen stützen die Ausführungskette des Droppers
Der Dropper enthält eine vollständige universelle Mach-O-Payload. In der von den Forschern untersuchten Entwicklungsversion war sie etwa 756 KB groß.
Der Loader von CloudSyncD kann auf zwei Quellen für dieselbe Payload zurückgreifen. Während der Ausführung kann er die eingebettete Kopie extrahieren; eine weitere Kopie liegt im Anwendungspaket auf der Festplatte. Durch diese Duplizierung hat der Dropper mehrere Möglichkeiten, bei der Installation an die ausführbare Backdoor-Datei zu gelangen.
Bei seinem ersten Ausführungsversuch vermeidet der Dropper, die Payload in eine reguläre Datei mit Namen zu schreiben. Stattdessen legt er die Mach-O-Datei in einem anonymen Dateideskriptor ab und versucht, sie von dort auszuführen. Laut Jamf scheitert diese Methode meistens am System Integrity Protection (SIP) von macOS.
Anschließend greift die Malware auf eine herkömmlichere Methode zurück. Sie schreibt die Payload vorübergehend auf die Festplatte und startet sie über sudo. Dabei verwendet sie das Passwort, das bei der Aktivierung vom Nutzer abgefragt wurde. Bei erfolgreicher Ausführung erhält sie Root-Rechte und kann sich als Daemon namens CloudSyncD dauerhaft einrichten.
SIP behindert also den bevorzugten Ausführungspfad. Die gesamte Angriffskette wird dadurch jedoch nicht verhindert, wenn das Opfer seine Zugangsdaten bereits eingegeben hat. Der Ausweichmechanismus zeigt, warum Passwortabfragen während einer scheinbar routinemäßigen Installation kritisch geprüft werden sollten – insbesondere dann, wenn die Software nicht über einen von der Organisation freigegebenen Vertriebsweg bezogen wurde.
CloudSyncD ist auf dauerhaften Zugriff ausgelegt, nicht auf typisches Infostealer-Verhalten
Nach dem Start entschlüsselt CloudSyncD Konfigurationsdaten, die in der Binärdatei enthalten sind, und nimmt seine Backdoor-Aktivitäten auf. Jamf schreibt der Malware mehrere zentrale Funktionen zu:
- Erstellen eines Profils des kompromittierten Macs;
- Sammeln von System- und Nutzerdaten;
- Auskundschaften des Hosts;
- Übermitteln der gesammelten Informationen an eine Command-and-Control-Infrastruktur;
- dauerhafte Aufrechterhaltung des Zugriffs;
- Ermöglichen der Auslieferung weiterer Payloads.
Aufgrund dieser Funktionen stufen die Forscher CloudSyncD als Backdoor und nicht als typischen Infostealer ein. Die Malware sammelt zwar Informationen über den Rechner, doch die untersuchten Funktionen entsprechen nicht dem üblichen Muster von Zugangsdaten-, Browserdaten- oder Wallet-Diebstahl, das häufig mit verbreiteten macOS-Infostealern verbunden ist.
Diese Unterscheidung schränkt auch ein, welche Schlüsse sich allein aus der Erstinfektion ziehen lassen. CloudSyncD ermöglicht die Ausführung weiterer Payloads. Aus den Berichten geht jedoch nicht hervor, welche zusätzlichen Tools gegebenenfalls auf bestimmten Systemen installiert wurden. Incident-Response-Teams sollten daher nach Folgeaktivitäten suchen, statt von einer bestimmten Malware-Familie in der zweiten Phase auszugehen.
Ein Betreiber wurde bislang nicht benannt. Bei der Bewertung der Attribution sollten die Malware-Familie, die Person oder Gruppe hinter der Malware und die konkrete Kampagne, über die diese Installer verbreitet wurden, deshalb getrennt betrachtet werden.
Entwicklungsartefakte wichen Samples mit Blick auf den Einsatz
Das älteste von Jamf untersuchte Sample wies noch auf eine aktive Entwicklung hin. Die darin hinterlegte Command-and-Control-Konfiguration verwies auf eine private Netzwerkadresse, außerdem war die ausführliche Debug-Ausgabe noch aktiviert.
Spätere Builds verwendeten andere C2-Endpunkte. Das stützt die Einschätzung der Forscher, dass das Projekt die interne Testphase hinter sich ließ. Trotz der geänderten Endpunkte wiesen die Samples zahlreiche gemeinsame Merkmale auf.
Jamf fand in den Builds dieselbe Tabelle zur String-Verschleierung, dieselben Installationspfade, denselben Daemon-Namen, dieselbe Prozess-Tarnung, denselben C2-Schlüssel, denselben Initialisierungsvektor und dieselben Seeds pro String. Diese wiederkehrenden Elemente verbinden die Samples technisch, auch wenn sich ihre Netzwerkziele unterscheiden.
Auch das gemeinsam genutzte kryptografische Material kann der Abwehr helfen. Den Forschern zufolge lässt sich mit Material aus einem beliebigen Build der erfasste Beacon-Datenverkehr verwandter Samples entschlüsseln. Einheitliche Artefakte auf den Hosts können ebenfalls die Erkennung mehrerer Versionen unterstützen, statt nur der zuerst analysierten Datei.
Die Kampagne nutzte zwei verschiedene Domains, um mehrere Builds zu hosten. Beide waren 2011 beim selben Registrar registriert worden und liefen über die Infrastruktur von Cloudflare. Daraus lässt sich keine Beteiligung von Cloudflare ableiten.
Beide Domains verwendeten außerdem denselben URI-Pfad, der wie eine Anfrage nach einem jQuery-Skript formatiert war. Offenbar sollte so der C2-Beacon-Verkehr in Netzwerkprotokollen wie der gewöhnliche Abruf von JavaScript aussehen. Im Bericht zu den Erkenntnissen von Jamf hieß es, dass für die Domains zum Zeitpunkt der Veröffentlichung keine Erkennungen gemeldet worden waren.
Die Forscher stellten eine umfangreichere IOC-Liste bereit. Das verfügbare Material enthält jedoch weder die Domainnamen noch den URI, die Endpunkte, Hashes, kryptografischen Werte oder andere konkrete Indikatoren. Diese Werte sollten weder rekonstruiert noch aus der Verhaltensbeschreibung abgeleitet werden.
Abwehrteams sollten die Abfolge vom Installer bis zum Daemon untersuchen
Diese Kampagne beruht auf der Verbreitung schädlicher Software und nicht auf einer offengelegten Schwachstelle in Zoom oder macOS. In den Berichten ist weder von einem Hersteller-Patch noch von betroffenen Produktversionen oder einer softwareseitigen Umgehungslösung die Rede.
Abwehrteams können die beobachtete Ausführungsabfolge dennoch als Leitfaden für Untersuchungen nutzen. Relevante Anhaltspunkte sind ein nicht vertrauenswürdiges Disk-Image, das als Zoom eingebunden wird, eine Passwortabfrage durch einen Installer, der fehlgeschlagene Versuch, eine Mach-O-Datei aus einem anonymen Dateideskriptor auszuführen, sowie eine anschließende Ausführung von der Festplatte über sudo.
Teams sollten betroffene Macs außerdem auf den CloudSyncD-Daemon untersuchen und dessen Einrichtung mit der Installationsaktivität, der Rechteausweitung und ausgehendem Datenverkehr abgleichen, der wie der Abruf eines jQuery-Skripts aussieht. Da die konkreten Pfad- und Netzwerkindikatoren hier nicht wiedergegeben werden, handelt es sich um Ansatzpunkte für Verhaltensanalysen und nicht um unmittelbar einsetzbare Erkennungsregeln.
Organisationen können das Risiko verringern, indem sie Nutzer auf freigegebene Software-Bezugsquellen verweisen und unerwartete Passwortabfragen durch heruntergeladene Installer als mögliche Sicherheitsvorfälle behandeln. Besteht der Verdacht auf CloudSyncD-Aktivitäten, sollten Incident-Response-Teams sowohl die Persistenzmechanismen als auch die Ausführung späterer Payloads untersuchen. Wird nur das ursprüngliche Disk-Image entfernt, ist damit eine Backdoor, die bereits mit erhöhten Rechten installiert wurde, nicht beseitigt.
Die verfügbaren Belege bestätigen eine technisch konsistente Malware-Familie und eine sich weiterentwickelnde Verbreitungsoperation. Sie belegen jedoch weder den Umfang der Kampagne noch konkrete Opfer oder die Identität des Betreibers.
Quellen
Dieser Artikel ist eine eigenständige Aufbereitung auf Basis der folgenden Quellen.




