Злоумышленник внедрял стиллер wfx с помощью украденных токенов GitHub

С 10 ноября 2026 года злоумышленник использовал украденные токены GitHub, чтобы менять репозитории и распространять стиллер секретов CI на основе скриптов оболочки под названием wfx. К 12 ноября на GitHub обнаружили более 63 000 пробных запросов на слияние, но полезная нагрузка выполнялась только при достаточных разрешениях токена и подходящих настройках рабочих процессов репозитория.

Как стиллер попадал в рабочие процессы

Кампания начиналась с пробных запросов на слияние (pull request), часто с заголовком docs: dependency audit notes из веток вроде wfx-docs. Затем появлялись коммиты с заголовками ci: refresh build cache, chore: add ci helper и chore: add dependency audit workflow.

Стиллер объёмом около 1 500 строк внедряли в существующие рабочие процессы, обычные скрипты оболочки, например update.sh, скрытые файлы .ci-*.sh или хуки установки пакетов. Он собирал секреты и переменные репозиториев и организаций, GITHUB_TOKEN, а также содержимое памяти процессов раннера. В частности, в памяти Runner.Worker могут находиться расшифрованные секреты.

Стиллер также собирал учётные данные из переменных окружения и файлов для AWS, Azure, GCP, Docker, Kubernetes, npm, PyPI, SSH, Vault, сервисов искусственного интеллекта и агентов для написания кода. На самохостинговых раннерах он нацеливался и на учётные данные из метаданных облачных инстансов. Перед отправкой данных стиллер архивировал содержимое репозитория, историю и артефакты рабочих процессов.

Ранние образцы отправляли данные на IP-адреса, в том числе 194.150.166.244, 18.143.168.96 и 153.75.82.159. Более новые версии передавали данные только в чат Telegram через api.telegram.org.

Изменения в облачных учётных данных и расследование

Для закрепления вредоносная программа пыталась изменить политики доверия ролей AWS, разрешив доступ любому субъекту AWS, и создать ключи доступа IAM. В Azure она добавляла в приложения учётные данные федеративной идентификации с именами wfx-ci-*. Это позволяло входить с помощью GitHub Actions без хранения секретов. Скрипт также содержал функцию подделки обязательных проверок, однако в изученных образцах её не наблюдали в активном состоянии.

После выполнения атаки злоумышленник обычно отменял вредоносный коммит и удалял соответствующий запуск рабочего процесса. В нумерации запусков Actions появлялись пропуски. Некоторые полезные нагрузки сохранялись в истории Git, а рабочие процессы публикации пакетов могли привести к выпуску скомпрометированных версий.

Авторы отчёта рекомендуют расследователям считать скомпрометированными все секреты, роли облачных сред, учётные данные для публикации и учётные данные самохостинговых раннеров, доступные затронутым задачам. Также они рекомендуют проверить AWS CloudTrail, федеративные учётные данные Azure, активность идентификации рабочих нагрузок в GCP, входы в Vault и Kubernetes, ветки и проверки GitHub, а также рабочие станции разработчиков, на которых выполнялись затронутые хуки установки пакетов.

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.