ADEX verfolgte eine aktive macOS-Infektion von einem seltsamen Prozess bis zu einer größeren Supply-Chain-Bedrohung, die sich durch Apple-Entwicklerwerkzeuge verbreitet. Der Fall konzentrierte sich auf XCSSET, eine Malware-Familie, die sich in Xcode-Projektdateien statt in fertigen Apps versteckt und darauf wartet, dass ein Entwickler ein Projekt erstellt und den Payload auslöst.
Der Hinweis, der den Fall ins Rollen brachte
Das erste Anzeichen war klein, aber seltsam: wiederholte osascript-Aktivität, die von /tmp/jl ausgeführt wurde. AppleScript selbst ist ein normales macOS-Tool, aber der Speicherort war entscheidend. Das /tmp-Verzeichnis ist ein temporärer Speicher, kein Ort, an dem saubere Software ständig kurzlebige Skripte mit großen kodierten Argumenten neu starten sollte.
ADEX kopierte die Datei, bevor sie verschwand. Nach der Sicherstellung stellte sich heraus, dass /tmp/jl ein kompiliertes AppleScript war. Der Inhalt war unter mehreren Schichten von base64-Kodierung verpackt, eine gängige Methode für Malware, um ihren nächsten Schritt vor einer schnellen Überprüfung zu verbergen.
Nach der Dekodierung offenbarte das Sample ein Shell-Skript, das Systemdetails sammelte. Es erfasste den Benutzernamen, das Gebietsschema, die macOS-Version, den CPU-Typ, den Status des Systemintegritätsschutzes, die Mac-Seriennummer und Chrome-bezogene Daten. Die Informationen wurden an riggletoy.ru gesendet, eine Command-and-Control-Domain, die laut ADEX zum damaligen Zeitpunkt nicht in öffentlichen Bedrohungsfeeds auftauchte. Eine zweite Domain, netcdndev.in – die später im GitHub-Teil der Untersuchung gefunden wurde – fehlte ebenfalls in jeder öffentlichen Indicator-of-Compromise-Liste.
Eine Build-Datei wurde zum Einfallstor
Die Gefahr von XCSSET liegt in seinem Versteck. Xcode-Projekte enthalten project.pbxproj-Dateien, die der Entwicklungssoftware von Apple mitteilen, was während eines Builds ausgeführt werden soll. Ein dort platziertes bösartiges Skript kann unter dem eigenen Konto des Entwicklers ausgeführt werden, wenn das Projekt kompiliert wird.
Das macht den Angriff unauffällig. Es wird kein seltsames Installationsprogramm benötigt. Es erscheint kein offensichtliches App-Symbol. Ein Entwickler kann ein Projekt von GitHub klonen, es in Xcode öffnen, auf „Build" drücken und der Malware den Moment geben, den sie braucht.
Die Infektion sucht dann nach anderen Xcode-Projekten auf dem Rechner. ADEX fand mehr als 20 veränderte Projekte auf der betroffenen Workstation, alle innerhalb derselben Minute geändert. Dieser Zeitpunkt deutete auf eine automatisierte Überprüfung hin, nicht auf eine manuelle Bearbeitung. Eine infizierte Workstation war bereits zu einem Ausgangspunkt für weitere Verbreitung geworden.
Persistenz war das eigentliche Problem
Das Bereinigen eines Projekts würde den Fall nicht lösen. ADEX fand eine gefälschte Launchpad.app, die in einem Benutzer-Cache-Ordner vergraben war, während das echte Launchpad unter /System/Applications/Launchpad.app zu finden ist. Dieses Detail stimmte mit einer bekannten „Dock-Methode" überein, bei der Malware ein Dock-Symbol umleitet, sodass ein Benutzer sowohl die echte App als auch den versteckten Payload öffnet, ohne es zu bemerken.
Der Bericht beschrieb zusätzliche Persistenzwege, darunter Launch-Agents, Shell-Profiländerungen und Git-Hooks. Die Lektion war klar: Die infizierten Projekte waren Symptome. Der Mechanismus, der die Infektion am Leben erhielt, musste zuerst entfernt werden.
ADEXs Bereinigungsreihenfolge war strikt. Entfernen Sie die Autostart-Punkte, starten Sie neu und stellen Sie dann Xcode-Projekte aus einem sauberen Git-Zustand wieder her. Das Umkehren dieser Reihenfolge birgt das Risiko, dass die Malware bereinigte Dateien erneut überschreibt.
GitHub zeigte die breitere Spur
Die Untersuchung bewegte sich von einem einzelnen Rechner zu öffentlichen Repositories. ADEX meldete 24 GitHub-Repositories, die XCSSET-Payload-Ketten enthielten. Zu den Beispielen gehörten PrinceMittal1/DemoForAuthFlow, zzzznick/dummy-ios und dvillegastech/ReaxBD.
Ein Repository, usamajaved357/Breezy, verwendete riggletoy.ru, dieselbe Domain, die im Live-Sample gesehen wurde. Ein weiteres, xiaoyouPrince/XYDevTool, verwendete netcdndev.In einer Domain, die ADEX als zum Zeitpunkt der Überprüfung nicht in der öffentlichen Indicator-of-Compromise-Liste vorhanden beschrieb, was darauf hindeutet, dass die Betreiber die Infrastruktur schneller rotieren, als öffentliche Bedrohungsfeeds sie verfolgen können. Zwölf der 24 Repositories erhielten Commits im Jahr 2026, wobei der jüngste nur einen Tag vor der Überprüfung lag – mehrere Repositories hatten Aktivitäten aus 2026, was darauf hindeutet, dass die Kampagne noch immer durch geteilten Code verbreitet wurde.
Die Zahlen sind wichtig, weil das Vertrauen der Entwickler Teil des Angriffspfads ist. Xcode-Projektdateien werden oft als routinemäßige Infrastruktur behandelt, weniger sichtbar als Quellcode oder Abhängigkeiten. XCSSET missbraucht diese Gewohnheit.
Das Risiko für Apple-Entwickler
Das direkte Ziel ist nicht der App-Store-Nutzer. Das Ziel ist die Person, die Software erstellt, zusammen mit den Anmeldedaten, Browser-Sitzungen, Repositories und Tokens, die auf diesem Rechner gespeichert sind.
XCSSET kann Daten aus Browsern, Keychain und Konfigurationsdateien abrufen — einschließlich Cloud-Schlüssel, AWS-Tokens, SSH-Schlüssel und Git-Anmeldedaten — kopierte Bitcoin- oder Ethereum-Wallet-Adressen ersetzen und das Browser-Verhalten durch injizierten JavaScript-Code verändern. Für ein Software-Team bedeutet das, dass ein kompromittierter Mac Quellcode, Konten und nachgelagerte Projekte gefährden kann.
Die praktische Verteidigung beginnt vor dem Build-Button. Entwickler sollten unbekannte Xcode-Build-Phasen überprüfen und project.pbxproj-Dateien in der Versionskontrolle halten, globale Git-Hooks beobachten, den Systemintegritätsschutz aktiviert lassen und unerwarteten ausgehenden Datenverkehr überwachen. Sicherheitsteams sollten Entwickler-Laptops als Teil der Supply-Chain behandeln, nicht als gewöhnliche Endpunkte.
