Массовая атака wfx-loot: хакеры внедрили похититель секретов в десятки тысяч репозиториев GitHub

Исследователи в области безопасности приложений раскрыли масштабную кампанию на GitHub под названием wfx-loot. Злоумышленники использовали учётные данные тысяч взломанных аккаунтов, чтобы внедрить в репозитории вредоносный скрипт, ворующий секреты CI/CD и ключи облачных сервисов. По разным оценкам, под удар попали десятки тысяч проектов, а кража секретов подтверждена более чем у 1,8 тысячи целей.

Как начиналась атака

По данным компании Aikido Security, кампания стартовала 10 ноября 2026 года. Атакующий располагал учётными данными 4837 скомпрометированных аккаунтов GitHub и с их помощью проверял, к каким репозиториям у него есть доступ на запись. Для этого в 61 764 проектах создавались тестовые запросы на слияние (pull request) с безобидным заголовком «docs: dependency audit notes» из ветки wfx-docs.

Примерно 92% таких запросов до сих пор остаются открытыми — судя по всему, владельцы репозиториев просто не заметили подозрительной активности. Там, где права позволяли, злоумышленник добавлял похититель секретов, а затем быстро откатывал изменения.

Что делает вредоносный скрипт

Основная полезная нагрузка — shell-скрипт объёмом около 1,5 тысячи строк. SafeDep обнаружила 7309 случаев внедрения скрипта в существующие рабочие процессы GitHub Actions и ещё 771 случай распространения через npm postinstall — механизм, который автоматически выполняет код при установке пакета. Во втором случае вредонос мог запускаться не только в облачной инфраструктуре, но и прямо на машине разработчика.

Скрипт собирал практически все доступные учётные данные:

  • секреты GitHub Actions, токены GITHUB_TOKEN, временные токены OIDC и Actions Runtime;
  • учётные данные AWS, Azure и Google Cloud, в том числе из метаданных виртуальных машин на self-hosted раннерах;
  • ключи и переменные окружения, файлы .env, приватные ключи, данные Git, SSH, GPG, Docker, Kubernetes, npm, PyPI, Vault и Terraform;
  • ключи доступа к сервисам ИИ — OpenAI, Anthropic, Gemini, Hugging Face, Cursor и GitHub Copilot;
  • содержимое репозитория, последние 100 коммитов и свежие артефакты рабочих процессов.

Собранные данные сжимались в архивы и отправлялись через HTTP POST на подконтрольные злоумышленнику серверы или в Telegram — при проверке 200 вредоносных коммитов примерно в каждом пятом случае использовался только Telegram.

Закрепление в облачной инфраструктуре

Особую опасность представляли механизмы закрепления. Обменивая токены GitHub OIDC на временные сеансы AWS, Google Cloud и Azure, атакующий мог создавать долгосрочные ключи AWS и менять политики доверия облачных ролей. В Azure добавлялись федеративные учётные данные с префиксом wfx-ci-, позволяющие рабочим процессам авторизоваться без сохранённого пароля. Такие ловушки могли продолжать действовать даже после отзыва первоначальных токенов и смены ключей.

Aikido также отметила пересечение с октябрьской кампанией GhostAction: аккаунты, пострадавшие тогда, примерно в тысячу раз чаще становились участниками новой атаки. При этом связать обе кампании с одним злоумышленником пока нельзя — использовались разные инструменты и инфраструктура.

Частые вопросы

Кто пострадал от атаки wfx-loot?

Среди взломанных аккаунтов были учётные записи организаций из списка Fortune 100, Управления общих служб США, правительства Франции, а также проектов Nextcloud и WebdriverIO. Около 50 аккаунтов имели права на публикацию пакетов в npm, PyPI, Go, crates и Packagist.

Как понять, что мой репозиторий затронут?

Исследователи рекомендуют проверить ветку wfx-docs, запрос на слияние с заголовком probe и подозрительные «дыры» в нумерации запусков рабочих процессов GitHub Actions.

Что делать, если вредоносный код выполнялся?

Все секреты и облачные роли, доступные затронутым рабочим процессам, следует считать скомпрометированными и немедленно заменить, а также проверить доверенные политики облачных ролей на предмет посторонних федеративных учётных данных.

Это та же группировка, что и GhostAction?

Пока нет. Aikido обнаружила пересечение по пострадавшим аккаунтам, но связать обе кампании с одним атакующим невозможно из-за разных инструментов и инфраструктуры.

Источники: ixbt.com, habr.com, aikido.dev

Рекомендованные статьи