XCSSET v40 у Xcode поширюється через заражені проєкти та використовує модульний ланцюжок, значна частина якого працює в пам’яті, повідомила Palo Alto Networks Unit 42 31 липня. Нова версія викрадає дані браузера й криптогаманців, втручається в роботу захисту, закріплюється через налаштування macOS і може перетворити комп’ютер розробника на ланку атаки на програмний ланцюжок постачання.
Важливо розрізняти отримання і запуск. Перегляд сторінки репозиторію або саме завантаження проєкту не названо точкою виконання. Небезпека виникає, коли розробник збирає чи запускає скомпрометований проєкт Xcode, а його конфігурація складання виконує вбудовану команду. Після цього видалити лише папку проєкту недостатньо: потрібно перевірити Mac та всі доступні йому облікові дані.
Кому загрожує XCSSET v40
| Ситуація | Ризик і наступне рішення |
|---|---|
| Ви лише переглянули репозиторій | Описаний ланцюжок не запускався. Збережіть адресу, якщо сторінка підозріла, але цього факту недостатньо, щоб вважати Mac зараженим. |
| Ви клонували або завантажили проєкт, але не збирали його | Не відкривайте й не запускайте проєкт. Зафіксуйте джерело та commit і порівняйте з довіреною версією в окремому середовищі. |
| Ви зібрали недовірений проєкт | Вважайте Mac потенційно скомпрометованим. Від’єднайте його, збережіть докази та змініть доступні секрети з чистого пристрою. |
| У спільному проєкті з’явився невідомий build script або змінений Git hook | Зупиніть складання й поширення. Визначте, коли зміна потрапила у version control і хто запускав її локально або в CI. |
Unit 42 почала відстежувати хвилю v40 у середині квітня 2026 року, а на початку травня побачила другу хвилю. Серед спостережуваних цілей були розробники у Південній Азії, але механізм не має географічного обмеження: будь-яка команда, що імпортує і збирає заражений проєкт, перетинає ту саму межу ризику.
Що змінилося у XCSSET v40
Дослідники виявили 17 модулів, які надходять через змінну командну інфраструктуру. XCSSET і далі використовує AppleScript та shell-інструменти, але нова архітектура ускладнює статичне виявлення й визначення масштабу інциденту:
- Завантажувачі в пам’яті: кілька етапів розшифровують або відновлюють наступний компонент перед виконанням, тому стабільних файлів для перевірки менше.
- Поліморфізм і два ключі: payload та внутрішні назви змінюються, а вхідний і вихідний трафік використовують різний криптографічний матеріал.
- Безфайлове закріплення: закодований stager зберігається у випадково названому домені налаштувань macOS і може знову запускатися зараженим застосунком.
- Викрадення даних браузера й гаманців: модулі перехоплюють роботу браузера, виводять дані та крадуть криптовалюту.
- Втручання у Telegram: доданий у травні модуль може троянізувати Telegram Desktop; попередні версії XCSSET також полювали на дані Telegram.
- Обхід захисту: v40 намагається завадити оновленням і телеметрії, скидає рішення AppleEvents та не передає основні модулі системам, схожим на віртуальні машини.
Повторний запит дозволу не варто вважати звичайною помилкою. Unit 42 бачила, як XCSSET скидає рішення AppleEvents і знову показує запит, маскуючись під System Settings або Xcode. Якщо користувач уже відхилив неочікуваний запит, не потрібно схвалювати другий без перевірки застосунку та його bundle.
Як працює ланцюжок із чотирьох етапів
- Проєкт запускає першу команду. Заражена конфігурація Xcode розшифровує та виконує команду, яка отримує наступний етап.
- Bash stager профілює Mac. Початкова розвідка визначає параметри системи й обирає подальшу гілку.
- Надходять додаткові завантажувачі. Dropper і wrapper виконують ще одну розвідку та готують boot-компонент.
- Модулі в пам’яті виконують атаку. Фінальний шар перехоплює браузер, виводить дані, краде криптовалюту й закріплюється у системі.
Саме тому потрібно досліджувати і проєкт, і робочу станцію. Заміна підозрілого репозиторію не прибирає stager у налаштуваннях, змінений застосунок, шкідливий Git hook, викрадену сесію браузера або секрет, який уже залишив комп’ютер.
Що робити після складання підозрілого проєкту Xcode
- Від’єднайте Mac від мережі. Не входьте у додаткові сервіси й не схвалюйте нові запити автоматизації. У корпоративному середовищі спочатку зверніться до команди безпеки, щоб правильно зберегти volatile evidence.
- Зафіксуйте проєкт. Запишіть URL репозиторію, commit hash, branch, час завантаження та складання і того, хто надав проєкт. Не запускайте cleanup script із того самого репозиторію.
- Перевіряйте з чистого середовища. Порівняйте project configuration, build phases, scripts, package references і Git hooks із відомою безпечною ревізією. Матеріал про ризик під час відкриття репозиторію пояснює, чому метадані проєкту потрібно перевіряти так само, як і вихідний код.
- Дослідіть увесь host. Перевірте неочікувані застосунки, LaunchDaemons, зміни запуску shell, Git hooks, домени налаштувань macOS, недавні запити TCC/AppleEvents, стан XProtect та індикатори зі звіту Unit 42.
- Відкличте доступ із чистого пристрою. Завершіть сесії браузера, Apple, GitHub, Telegram і хмарних сервісів. Замініть SSH keys, App Store Connect credentials, CI/CD secrets, signing і deployment keys, дані гаманців та tokens, які були на Mac.
- Оберіть очищення або перевстановлення. Якщо виконання підтверджено чи межі зараження невідомі, збережіть докази та відновіть Mac із довіреного носія замість припущення, що видалення одного preference повернуло довіру.
- Відтворіть проєкт із надійної історії. Візьміть відомий безпечний commit і перегляньте кожну пізнішу зміну. Не копіюйте build caches, hooks або неперевірені метадані на чисту систему.
Такий самий принцип зміни секретів із чистого пристрою діє для скомпрометованих пакетів. Матеріал про зламані пакети Joyfill показує, як інцидент під час build може відкрити developer tokens і downstream artifacts навіть після швидкого видалення шкідливого компонента.
Чого XCSSET v40 не доводить
- Не кожен проєкт Xcode або репозиторій GitHub заражений.
- Клонування репозиторію не дорівнює виконанню його build phase.
- Нормальний статус XProtect сам по собі не очищує Mac після підтвердженого запуску, особливо коли malware намагається завадити оновленням і телеметрії.
- Видалення підозрілого проєкту не відкликає викрадені tokens і не прибирає host persistence.
- Зміна пароля на підозрілому Mac може знову відкрити новий секрет.
Підтверджене складання потрібно розглядати як можливий інцидент з обліковими даними та цілісністю програмного забезпечення, а не лише як локальне antivirus alert. Для ширшого контексту розбір TrapDoor пояснює, чому після компрометації developer workflow потрібно перевіряти секрети CI та артефакти, а не тільки вилучати початковий файл.
Джерела
- Palo Alto Networks Unit 42. «The Xcode Assassin Returns: A Deep Dive Into the Latest XCSSET Version». Unit 42, 31 липня 2026 року. первинний технічний звіт.
- Microsoft Threat Intelligence. «New XCSSET Malware Adds New Obfuscation, Persistence Techniques to Infect Xcode Projects». Microsoft Security Blog, 11 березня 2025 року. аналіз попередньої версії та рекомендації.
- MITRE ATT&CK. «XCSSET (S0658)». MITRE, дата доступу 31 липня 2026 року. довідка про техніки й сімейство.
