GhostAction: взломаны около 1 900 аккаунтов GitHub, затронуты более 30 000 репозиториев
Кампания GhostAction затронула около 1 900 аккаунтов GitHub и более 30 000 репозиториев. Злоумышленники пытались похитить секреты CI/CD, облачные ключи и API-ключи ИИ-сервисов.
Злоумышленники в рамках кампании GhostAction скомпрометировали около 1 900 аккаунтов GitHub и внедрили вредоносные процессы GitHub Actions более чем в 30 000 репозиториев. Как сообщается в материале Selectel на Хабре, пик активности пришёлся на 8–9 октября. Атакующие пытались получить секреты CI/CD, облачные ключи и API-ключи ИИ-провайдеров.
Как атакующие использовали GitHub Actions
В этой кампании злоумышленники не эксплуатировали уязвимость самого механизма Actions. Получив доступ к учётным записям разработчиков, они напрямую меняли файлы рабочих процессов в репозиториях. Аналитики StepSecurity предполагают, что первоначальный доступ могли дать утёкшие персональные токены доступа (PAT), но точный путь компрометации пока не подтверждён.
Вредоносные файлы назывались security-audit.yml и github_actions_security.yml — по имени они походили на обычные проверки безопасности. При запуске такой процесс обращался к секретам, которые уже использовались в легитимных сборках, собирал учётные данные и отправлял их на сервер атакующих. Поэтому оценивать файл только по его названию недостаточно: важно проверить содержимое и то, кто внёс изменение.
Октябрьский вариант искал не только секреты, доступные рабочему процессу. Злоумышленники применяли actions/checkout@v4 с параметром fetch-depth: 0, чтобы получить всю историю коммитов и просканировать её вместе с рабочим деревом. Ключ, удалённый из текущего кода, всё ещё мог находиться в старых версиях файлов. Это делает проверку только последнего состояния репозитория неполной.
Скрипты искали ключи AWS, PAT от GitHub и GitLab, данные доступа Google и Firebase, API-ключи Anthropic, OpenAI и OpenRouter. В поздних вариантах при поиске AWS-ключей скрипт забирал также соседние строки кода, чтобы связать идентификатор ключа с секретной частью. Найденные данные отправлялись по HTTP на IP-адрес 193.32.204.199.
Что известно о масштабе и результате
Атака шла поэтапно: сначала код доставили 160 уже известным жертвам, а через 20 минут началось внедрение в 28 000 новых репозиториев. Исследователи насчитали попытки извлечь 3 174 секрета. Это не число подтверждённых краж: точный объём похищенных данных в октябрьской кампании неизвестен, хотя исследователи GitGuardian зафиксировали факты утечки.
Для сравнения, в августе и сентябре вредоносные процессы нашли в 772 публичных репозиториях. Из 3 669 запусков успешно завершились 336; тогда были похищены 26 секретов из 13 репозиториев. Эти результаты относятся к предыдущим эпизодам и не позволяют оценить потери октябрьской волны.
Встроенные механизмы одобрения GitHub блокируют большинство вредоносных действий. Однако атакующие повторно использовали 92 процесса из прошлых атак, включая инфраструктуру, активную с сентября 2025 года. К 5 октября вредоносный код удалили лишь из 124 ранее пострадавших репозиториев — около 16% от 772. Удаление файла прекращает его дальнейшее использование в репозитории, но не возвращает уже раскрытые учётные данные.
Что проверить владельцам проектов и разработчикам
Для сайта или сервиса последствия могут выходить за пределы репозитория. Если процесс получил доступ к ключу развёртывания, облачному аккаунту или внешнему API, исправление YAML-файла само по себе не решает вопрос с этим доступом. Сначала нужно отделить подтверждённую компрометацию аккаунтов от перечня остальных секретов, которые могли попасть в запуски Actions.
Учётные данные скомпрометированных аккаунтов с правом записи следует отозвать немедленно, даже если вредоносный процесс уже удалён. Параллельно стоит проверить журналы аудита GitHub и активность PAT: какие аккаунты меняли файлы в .github/workflows/. История запусков Actions поможет определить, какие процессы выполнялись и к каким секретам они могли обратиться.
Затем нужно обновить и перевыпустить потенциально затронутые облачные ключи, данные для развёртывания, токены реестров и API-ключи ИИ-провайдеров. Старые пароли и ключи тоже входят в проверку, если они были удалены из кода, но остались действующими: полное сканирование истории Git позволяло атакующим их найти. Похожую проблему с секретами в публичных репозиториях уже разбирали в блоге.
Мой вывод: файл не равен границе инцидента
Я бы оценивал работу не по числу удалённых YAML-файлов, а по двум результатам: доступы скомпрометированных аккаунтов отозваны, а для остальных ключей установлен перечень возможных запусков и принято решение о перевыпуске. Это проверяемый объём работы для конкретного проекта. Масштаб всей кампании сам по себе не показывает, какие именно секреты были доступны в отдельном репозитории.
Источники
Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.
backend-разработчик
Разрабатываю API и отвечаю за производительность сервисов. Предпочитаю небольшие изменения с понятными метриками большим переписываниям «на перспективу».
Все публикации автораПохожие статьи
В публичных репозиториях GitHub нашли 543 тысячи действующих секретов
Truffle Security изучила 224 млн публичных репозиториев GitHub и нашла 543 тысячи действующих секретов. Многие из них оставались открытыми годами, а часть не распознаёт встроенная блокировка утечек.
Через DNS DebugBear злоумышленники подменили скрипт мониторинга сайтов
После атаки на инфраструктуру DebugBear злоумышленники подменили скрипт Real User Monitoring. Владельцам сайтов, подключившим сервис для отслеживания Core Web Vitals, рекомендуют удалить тег и проверить учётные записи.
ISPsystem выпустила обновления VMmanager после атаки через уязвимость нулевого дня
ISPsystem выпустила обновления безопасности VMmanager и переработала защитную архитектуру после атаки через уязвимость нулевого дня. Проверка инфраструктур провайдеров продолжается.
Обсуждение 5
Фаррух Умаров
Практически важная деталь: при проверке стоит смотреть не только на текущие workflow-файлы, но и на историю изменений и логи запусков. Вредоносный файл могли удалить, а уже выполненный workflow — успеть отправить секреты; поэтому после подозрительного запуска токены и ключи нужно считать раскрытыми и отозвать.
Завен Эдигарян
@f.umarov, уточню: при отзыве нужно считать раскрытыми все секреты, доступные workflow, или только те, которые могли попасть в его окружение? Вредоносные файлы маскировались под security-аудит, но фактический набор доступных им секретов мог отличаться.
Видас Сакалаускас Автор публикации
Считать раскрытыми нужно секреты, которые workflow мог прочитать: доступные ему через контекст запуска, окружение и права GITHUB_TOKEN. Но границу лучше проверить по конфигурации и логам конкретного запуска, а не только по имени файла; стоимость лишней ротации обычно меньше, чем разбор утечки.
Лукас Марин
Тогда для ревизии важен не только список секретов в настройках репозитория: у workflow могли быть секреты уровня организации и широкие права GITHUB_TOKEN. Верно ли, что при разборе запуска нужно проверять эффективные права токена именно в том событии и контексте, в котором сработал вредоносный файл?
Самат Ганиев
Верно ли, что при проверке нужно восстановить права GITHUB_TOKEN именно на момент запуска, включая настройки события и ограничения репозитория? Для небольшого проекта важно понять, можно ли это надёжно установить по логам, если workflow уже удалён.