XCSSET для macOS вернулся в версии v40 и снова заражает системы разработчиков через скомпрометированные Xcode-проекты. Опасность в том, что одна зараженная сборка может испортить остальные проекты на машине и уйти дальше по цепочке исходников. Как пишет BleepingComputer, новая волна уже нацелена на тысячи пользователей macOS через проекты Xcode и репозитории на GitHub.
После нескольких месяцев тишины исследователи Unit 42 из Palo Alto Networks зафиксировали две волны активности, в середине апреля и в начале мая 2026 года. По их данным, злоумышленники берут уязвимые Git-репозитории, внедряют скрипт-загрузчик в безобидные файлы внутри Xcode-проекта и ждут, пока разработчик соберет приложение. На этапе сборки машина заражается, а затем вредонос начинает модифицировать все остальные Xcode-проекты в системе и распространяться через общий исходный код. Для команд, где шаблоны приложений, внутренние библиотеки и клиентские проекты лежат рядом, это уже не локальный инцидент на одном MacBook, а маленькая supply chain-авария.
Дальше все развивается по взрослому сценарию. XCSSET проходит четыре стадии заражения, а затем разворачивает 17 отдельных модулей. В наборе возможностей у него кража учетных данных, кейлоггер, подмена содержимого буфера обмена, угон браузера и вынос данных наружу. Проблема в том, что XCSSET для macOS не останавливается на одном зараженном проекте. Если на рабочей машине разработчика лежат текущие продукты, тестовые сборки, заготовки новых приложений и общие модули, весь этот набор быстро превращается в транспорт для дальнейшего заражения, причем без каких-то экзотических действий со стороны жертвы. Достаточно обычной рабочей рутины: скачать код, открыть проект, нажать Build.
Главное новшество версии 40, два новых компонента. Первый отвечает за угон Chrome. Он оборачивает браузер вредоносным лаунчером, включает Chrome DevTools Protocol (CDP) на локальном порту и подтягивает JavaScript с сервера управления. Это позволяет атакующим перехватывать веб-трафик, логины, cookies и даже операции MetaMask, меняя их на лету, если цель, например, в перенаправлении платежа. Тот же модуль умеет выполнять системные команды через fileless reverse shell. Google уже блокирует такой сценарий в Chrome для Windows и работает над тем, чтобы распространить защиту и на macOS. Для разработчика, у которого в браузере открыты GitHub, облачные консоли, админки, панели аналитики и криптокошелек для тестов, такой набор выглядит особенно неприятно.
Второй новый модуль бьет по Telegram Desktop. Он удаляет легитимное приложение и подменяет его зараженной версией. Исследователи не смогли извлечь зашифрованную конфигурацию, поэтому точную функциональность модуля они не подтвердили. Но сама логика ясна: помимо браузера атакующих интересует и рабочий канал общения жертвы. Для команд, где часть коммуникаций идет через Telegram, даже потенциальная подмена такого клиента выглядит отдельным риском. Особенно в сценариях, где через мессенджер обсуждают доступы, инциденты, сборки и срочные правки.
Unit 42 отдельно отмечает, что XCSSET стал лучше прятаться. Загрузчик периодически пересобирается прямо на сервере управления, входящий и исходящий трафик шифруются разными ключами, а имена функций, переменных и строки обфусцируются так, чтобы каждая сборка выглядела по-своему. Параллельно вредонос пытается отключать системные защиты macOS: XProtect, MRT, TCC и Rapid Security Response, завершает процесс CloudTelemetryService и мешает обновлению сигнатур XProtect. Это уже не попытка тихо пересидеть в системе пару дней, а довольно прямолинейная задача ослепить платформенную защиту до того, как пользователь или администратор заметят проблему.
Контекст здесь тоже важен. XCSSET известен как минимум с 2021 года и уже успевал использовать zero-day уязвимости. В сентябре 2025 года Microsoft предупреждала о кампании, где вредонос тоже распространялся через зараженные Xcode-проекты. Ранее компания находила вариант XCSSET с возможностями для кражи криптоактивов. Нынешняя версия лишь подтверждает неприятный тренд: атаки на цепочку поставки все ближе подбираются к среде разработки, потому что именно там до сих пор много доверия к чужим репозиториям, шаблонам проектов и удобным заготовкам из open source. Чем привычнее выглядит проект, тем меньше шансов, что его будут проверять как потенциальную точку входа.
Для разработчиков и руководителей вывод вполне практический. Нужно смотреть не только на EDR, MDM и стандартную гигиену рабочих станций, но и на то, как в команду попадают Xcode-проекты и внешние зависимости. Unit 42 советует отслеживать аномальную активность AppleScript, несанкционированные изменения браузеров, подозрительные записи в defaults-доменах macOS и ad hoc-подписанные приложения, обходящие Gatekeeper. Отдельно исследователи рекомендуют сканировать open source-зависимости, чтобы скомпрометированные репозитории не попадали в пайплайн разработки. И это, пожалуй, самый важный пункт: если зараженный проект проходит внутрь без проверки, дальше его начинает масштабировать уже сама инженерная рутина.
История с XCSSET для macOS неприятна тем, что бьет не по конечному пользователю, а по человеку, который собирает продукт. Чем сильнее команды завязаны на GitHub, внутренние репозитории и быстрый обмен исходниками, тем выгоднее атакующим заражать именно инструменты разработки. В такой логике Xcode-проект давно перестал быть просто папкой с кодом. Это полноценная точка входа в инфраструктуру, и относиться к ней как к безобидной заготовке уже слишком дорого.