ADEX prześledzył aktywną infekcję systemu macOS – od jednego podejrzanego procesu po szersze zagrożenie w łańcuchu dostaw, przenikające przez narzędzia dla deweloperów Apple. Sprawa skupiała się na XCSSET, rodzinie złośliwego oprogramowania ukrywającej się w plikach projektów Xcode, a nie w gotowych aplikacjach – czekającej, aż deweloper zbuduje projekt i uruchomi ładunek.
Wskazówka, która zapoczątkowała sprawę
Pierwszy sygnał był niewielki, lecz niepokojący: powtarzająca się aktywność osascript uruchamiana z /tmp/jl. AppleScript samo w sobie jest normalnym narzędziem systemu macOS, jednak lokalizacja miała znaczenie. Katalog /tmp to przestrzeń tymczasowa – nie miejsce, w którym czyste oprogramowanie powinno wielokrotnie uruchamiać krótkotrwałe skrypty z dużymi zakodowanymi argumentami.
ADEX skopiował plik, zanim zniknął. Po przechwyceniu okazało się, że /tmp/jl to skompilowany AppleScript. Jego zawartość była ukryta pod wieloma warstwami kodowania base64 – powszechna metoda stosowana przez złośliwe oprogramowanie w celu ukrycia kolejnego kroku przed szybką inspekcją.
Po zdekodowaniu próbka ujawniła skrypt powłoki zbierający szczegóły systemowe. Zbierał nazwę użytkownika, ustawienia regionalne, wersję systemu macOS, typ procesora, status System Integrity Protection, numer seryjny komputera Mac oraz dane związane z Chrome. Informacje były wysyłane do riggletoy.ru – domeny command-and-control, która według ADEX nie pojawiała się wówczas w publicznych źródłach informacji o zagrożeniach. Druga domena, netcdndev.in – odkryta później podczas analizy repozytoriów GitHub — również nie figurowała na żadnej publicznej liście wskaźników kompromitacji.
Plik build stał się furtką
Niebezpieczeństwo XCSSET tkwi w jego kryjówce. Projekty Xcode zawierają pliki project.pbxproj, które informują oprogramowanie deweloperskie Apple, co ma być uruchamiane podczas budowania. Złośliwy skrypt umieszczony w tym miejscu może zostać wykonany na koncie samego dewelopera podczas kompilacji projektu.
To sprawia, że atak jest dyskretny. Nie jest potrzebny żaden podejrzany instalator. Nie pojawia się żadna oczywista ikona aplikacji. Deweloper może sklonować projekt z GitHuba, otworzyć go w Xcode, nacisnąć Build i dać złośliwemu oprogramowaniu chwilę, której potrzebuje.
Infekcja następnie szuka innych projektów Xcode na komputerze. ADEX znalazł ponad 20 zmodyfikowanych projektów na zainfekowanej stacji roboczej – wszystkie zmienione w tej samej minucie. Taki czas wskazywał na automatyczne przeszukiwanie, nie ręczną edycję. Jedna zainfekowana stacja robocza stała się już punktem wyjścia do dalszego rozprzestrzeniania się.
Trwałość była prawdziwym problemem
Wyczyszczenie jednego projektu nie rozwiązałoby sprawy. ADEX odkrył fałszywą aplikację Launchpad.app ukrytą w folderze pamięci podręcznej użytkownika, podczas gdy prawdziwy Launchpad znajduje się w /System/Applications/Launchpad.app. Ten szczegół odpowiadał znanej „metodzie doku", w której złośliwe oprogramowanie przekierowuje ikonę Docka, tak że użytkownik otwiera jednocześnie prawdziwą aplikację i ukryty ładunek, nie zauważając tego.
Raport opisywał dodatkowe mechanizmy trwałości, w tym agenty uruchamiania, zmiany profilu powłoki oraz git hooks. Wniosek był jasny: zainfekowane projekty były jedynie objawami. Najpierw należało usunąć mechanizm podtrzymujący infekcję.
Procedura czyszczenia ADEX była ściśle określona. Usuń punkty automatycznego uruchamiania, uruchom ponownie komputer, a następnie przywróć projekty Xcode z czystego stanu git. Odwrócenie tej kolejności grozi ponownym nadpisaniem przez złośliwe oprogramowanie już wyczyszczonych plików.
GitHub ujawnił szerszy ślad
Dochodzenie przeniosło się z jednego komputera do publicznych repozytoriów. ADEX zgłosił 24 repozytoria GitHub zawierające łańcuchy ładunków XCSSET. Wśród przykładów znalazły się PrinceMittal1/DemoForAuthFlow, zzzznick/dummy-ios oraz dvillegastech/ReaxBD.
Jedno repozytorium, usamajaved357/Breezy, korzystało z riggletoy.ru – tej samej domeny, którą zauważono w aktywnej próbce. Inne, xiaoyouPrince/XYDevTool, korzystało z netcdndev.In – domeny, którą ADEX opisał jako nieobecną na publicznej liście wskaźników kompromitacji w czasie inspekcji, co wskazuje, że operatorzy rotują infrastrukturą szybciej, niż publiczne źródła informacji o zagrożeniach są w stanie to śledzić. Dwanaście z 24 repozytoriów otrzymało commity w 2026 roku, a najnowszy zaledwie jeden dzień przed inspekcją – kilka repozytoriów wykazywało aktywność w 2026 roku, co sugeruje, że kampania wciąż przemieszczała się przez współdzielony kod.
Liczby mają znaczenie, ponieważ zaufanie deweloperów jest częścią ścieżki ataku. Pliki projektów Xcode są często traktowane jako rutynowe elementy infrastruktury, mniej widoczne niż kod źródłowy czy zależności. XCSSET wykorzystuje ten nawyk.
Ryzyko dla deweloperów Apple
Bezpośrednim celem nie jest użytkownik App Store. Celem jest osoba tworząca oprogramowanie, wraz z danymi uwierzytelniającymi, sesjami przeglądarki, repozytoriami i tokenami przechowywanymi na tym komputerze.
XCSSET może pobierać dane z przeglądarek, Keychain i plików konfiguracyjnych — w tym klucze chmurowe, tokeny AWS, klucze SSH i dane uwierzytelniające Git — zastępować skopiowane adresy portfeli Bitcoin lub Ethereum oraz modyfikować zachowanie przeglądarki poprzez wstrzyknięty kod JavaScript. Dla zespołu programistycznego oznacza to, że jeden zaatakowany Mac może narazić na ryzyko kod źródłowy, konta i projekty downstream.
Praktyczna obrona zaczyna się przed naciśnięciem przycisku build. Deweloperzy powinni sprawdzać nieznane fazy budowania Xcode i przechowywać pliki project.pbxproj w kontroli wersji, obserwować globalne git hooks, utrzymywać włączoną ochronę System Integrity Protection oraz monitorować nieoczekiwany ruch wychodzący. Zespoły ds. bezpieczeństwa powinny traktować laptopy deweloperów jako część łańcucha dostaw, a nie zwykłe punkty końcowe.
