Eine neue XCSSET Variante macht derzeit wieder von sich reden. Sicherheitsforscher berichten, dass die Schadsoftware Tausende macOS-Nutzer über kompromittierte Xcode-Projekte sowie GitHub-Repositories angreift. Für Entwickler ist das besonders kritisch, weil die Infektion nicht primär durch einen klassischen Download passiert, sondern beim Bauen (Build) der betroffenen Projekte.
Die Malware war über Monate weitgehend inaktiv, tauchte dann jedoch mit einer aktualisierten Version wieder auf. In der Analyse von Unit 42 (Palo Alto Networks) steht die Version v40 im Fokus – mit verbesserten Techniken zur Umgehung von Sicherheitsmechanismen und zwei neuen Modulen.
Wie die XCSSET Variante macOS-Entwickler erreicht
Der Einstieg verläuft über die Entwicklungswerkzeuge selbst. Die Angreifer kompromittieren dafür anfällige Git-Repositories und integrieren einen Downloader in ansonsten harmlose Dateien innerhalb von Xcode-Projekten. Wer solche Projekte aus einem manipulierten Quellpaket herunterlädt und anschließend baut, kann unabsichtlich die Infektion auslösen.
Der zentrale Hebel: Sobald das Projekt erstellt wird, kann XCSSET in der Folge andere Xcode-Projekte auf dem System kompromittieren. Dadurch entsteht eine Art “Seitwärtsbewegung” innerhalb der lokalen Entwicklungsumgebung – und später auch darüber hinaus, etwa wenn gemeinsam genutzter Quellcode weitergegeben wird.
Angriffsfenster und bisherige Ausrichtung
Unit 42 beobachtete, dass Version v40 in zwei separaten Angriffswellen eingesetzt wurde: einmal Mitte April und erneut Anfang Mai. XCSSET richtet sich dabei nicht erst seit gestern gegen macOS.
Die Bedrohung ist spätestens seit 2021 gegen macOS aktiv. In einigen Fällen sollen dabei auch Zero-Day-Schwachstellen ausgenutzt worden sein, um die Angriffe durchzuziehen.
Vier Stufen bis zur eigentlichen Schadfunktion
Die analysierte Infektionskette folgt laut den Forschern vier Stufen, bevor die Malware ihre eigentlichen Module ausspielt. Anschließend werden 17 separate Module aktiviert, die unterschiedliche Ziele verfolgen – darunter das Ausspähen von Zugangsdaten, Keylogging, Manipulation der Zwischenablage, Umleitungen im Browser sowie das Exfiltrieren von Daten.
Auf diese Weise kann die XCSSET Variante mehrere Spuren abdecken: von Credential-Theft über laufende Überwachung bis hin zum Abtransport sensibler Informationen.
Neue Funktionen in v40: Chrome-Hijacker und Telegram-Trojan
Die XCSSET Variante bringt zwei neue Module mit. Das erste Modul wird als Chrome-Hijacker beschrieben. Es “verpackt” den Chrome-Browser in einen bösartigen Launcher und aktiviert über einen lokalen Port das Chrome DevTools Protocol (CDP), um JavaScript aus der Infrastruktur der Angreifer abzurufen.
Mit dieser Kopplung können Angreifer Webverkehr abfangen – inklusive Credentials, Cookies und sogar Interaktionen rund um MetaMask-Transaktionen. Dadurch lassen sich Zahlungen potenziell zur Umleitung anpassen.
Kommandos ohne klassische Dateispuren
Darüber hinaus ermöglicht der Hijacker offenbar die Ausführung von Systembefehlen über eine fileless reverse shell. Unit 42 ordnet das im Kontext der Chrome-Schutzmechanismen ein: Google blockiert vergleichbare Ansätze in Chrome für Windows, arbeitet aktuell aber daran, diesen Schutz auch für macOS auszubauen.
Für Verteidiger ist das deshalb relevant, weil “fileless” oft bedeutet, dass traditionelle Indikatoren wie neu geschriebene Dateien weniger sichtbar sind.
Telegram-Trojanisierung durch Austausch der Desktop-App
Das zweite neue Modul wird als Telegram-Trojanizer beschrieben. Bei betroffenen Systemen wird dabei die legitime Telegram Desktop-Anwendung gelöscht und durch eine bösartige Version ersetzt. Damit schaffen die Angreifer eine Grundlage, um Kommunikationsinhalte potenziell mitzulesen oder zu manipulieren.
Unit 42 konnte die verschlüsselte Konfiguration nicht auslesen. Deshalb bleibt die konkrete Funktionsbreite dieses Moduls vorerst unklar.
Wodurch sich die XCSSET Variante besser versteckt
Neben neuen Modulen betonen die Forscher auch verbesserte Erkennungsumgehung. Unter anderem soll die Malware den Loader regelmäßig neu kompilieren, und zwar auf dem C2-Server (Command-and-Control). Zusätzlich sollen für eingehende und ausgehende Kommunikation unterschiedliche Verschlüsselungsschlüssel verwendet werden.
Für weitere Hürden sorgen Obfuskationsmechanismen: Funktionsnamen, Variablen und Strings werden verdeckt, wobei build-eindeutige Ciphers genutzt werden.
Angriffe auf Sicherheitsfunktionen in macOS
Ein besonders alarmierender Punkt ist, dass XCSSET aktiv versucht, Schutzmechanismen in macOS zu beeinträchtigen. Die Malware richtet sich dabei gegen Komponenten wie XProtect, MRT, TCC und sogar Rapid Security Response. Außerdem sollen Angreifer den Prozess der Apple CloudTelemetryService beenden und verhindern, dass XProtect-Signaturupdates nachgeladen werden.
Gerade diese Mischung aus “Sicherheitsbremsung” und aktiver Kontrolle des Systems erhöht das Risiko, dass andere Erkennungswege ins Leere laufen.
Empfohlene Indikatoren: Worauf Teams achten sollten
Die Forscher empfehlen, verschiedene Arten von Anomalien zu beobachten. Dazu gehören unter anderem ungewöhnliche AppleScript-Aktivität, unautorisierte Änderungen an Browser-Konfigurationen sowie Auffälligkeiten rund um macOS defaults Domains.
Auch Ad-hoc-signierte Anwendungen, die Gatekeeper umgehen, werden als konkretes Warnsignal genannt. Wer also in den Betriebs- und Endpunktdaten nach solchen Mustern sucht, kann die Wahrscheinlichkeit erhöhen, dass ein kompromittierter Build- oder Entwicklungsprozess sichtbar wird.
Schutzstrategie: Den Build-Prozess absichern
Weil die XCSSET Variante über kompromittierte Projektpakete und Repositories in die Umgebung gelangt, sollte der Fokus auf dem Entwicklungs- und Pipeline-Prozess liegen. Ein entscheidender Ansatz ist daher: Abhängigkeiten und Open-Source-Komponenten prüfen, damit kompromittierte Repositories nicht unbemerkt in die Softwareentwicklungspipeline gelangen.
Praktisch bedeutet das, Quellen und Inhalte stärker zu validieren, Prozesse zur Integritätsprüfung zu etablieren und verdächtige Änderungen an Projektdateien oder Build-Artefakten früh zu erkennen.
Warum Tests in mehreren Ebenen helfen
Selbst wenn einzelne Kontrollen “normalerweise” funktionieren, können Angreifer durch Lücken rutschen. Unit 42 verweist zudem auf Erfahrungen, wonach Teams einen Teil erfolgreicher Angriffe protokollieren, aber nur einen kleineren Anteil rechtzeitig alarmiert.
Der daraus abgeleitete Ansatz ist, Sicherheitsprüfungen und Simulationen so auszurichten, dass Regeln und Erkennungsmechanismen im Alltag wirklich greifen – bevor ein Angreifer sie ausnutzen kann.
Fazit: XCSSET Variante rückt Entwicklerworkflows in den Fokus
Die neue XCSSET Variante zeigt, wie stark moderne Angriffe von der Softwareentwicklung selbst profitieren. Durch die Kompromittierung von Git-Repositories und die Manipulation von Xcode-Projekten entsteht ein realistischer Infektionsweg, der beim Build ausgelöst wird. Mit v40 kommen zusätzliche Module hinzu, darunter ein Chrome-Hijacker und ein Telegram-Trojanizer, ergänzt durch Maßnahmen zur Erkennungsevasion und das gezielte Beeinträchtigen von macOS-Sicherheitsfunktionen.
Wer Entwicklerteams schützt, muss daher nicht nur Endpunkte betrachten, sondern besonders den Softwarelieferprozess: Abhängigkeiten prüfen, verdächtige Änderungen im Repository-Umfeld ernst nehmen und Indikatoren wie Browser- und Script-Anomalien konsequent überwachen.
