Кампания GhostAction внедрила вредоносные GitHub Actions в 30 000 репозиториев

Кампания GhostAction затронула около 1 900 учетных записей GitHub. Получив доступ к аккаунтам разработчиков, злоумышленники внедрили вредоносные процессы GitHub Actions более чем в 30 000 репозиториев. Их целью были токены CI/CD, ключи доступа к облачной инфраструктуре и API-ключи ИИ-провайдеров.

‹›

Наибольшая активность пришлась на 8 и 9 октября: за этот период атакующие попытались извлечь 3 174 секрета. По данным аналитиков StepSecurity, вероятным источником компрометации стали ранее утекшие персональные токены доступа GitHub (PAT), однако точный вектор атаки пока не подтвержден.

Вредоносные процессы маскировались под проверки безопасности

Атака отличалась от эксплуатации уязвимостей в самом механизме GitHub Actions. Злоумышленники использовали украденные учетные данные разработчиков, чтобы напрямую изменять файлы рабочих процессов в репозиториях. Новые задачи оформлялись как обычные проверки безопасности и получали незаметные имена вроде security-audit.yml или github_actions_security.yml.

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

Атакующие использовали actions/checkout@v4 с параметром fetch-depth: 0. Это позволяло получить полный рабочий каталог и историю коммитов, включая данные, давно удаленные из актуальной версии проекта. В результате под угрозой оказались AWS-ключи, токены Anthropic, OpenAI и OpenRouter, а также другие учетные данные, которые могли оставаться действительными после удаления из исходного кода. Более поздние версии скриптов дополнительно анализировали соседние строки, чтобы сопоставить идентификаторы AWS-ключей с секретными ключами доступа.

Все собранные данные отправлялись на IP-адрес 193.32.204.199. Исследователи GitGuardian зафиксировали случаи утечки учетных данных во время октябрьской кампании, но точный объем похищенной информации пока неизвестен.

Массовое внедрение и повторное использование старой инфраструктуры

Атака разворачивалась поэтапно. Сначала вредоносный код доставили примерно 160 уже известным жертвам, а через 20 минут начали массово добавлять его в еще 28 000 репозиториев. При этом злоумышленники повторно использовали 92 рабочих процесса, применявшихся в предыдущих атаках. Часть связанной с кампанией инфраструктуры оставалась активной с сентября 2025 года.

Первые эпизоды GhostAction исследователи наблюдали в августе и сентябре. Тогда вредоносные процессы обнаружили в 772 публичных репозиториях. Из 3 669 запусков успешно завершились 336, что привело к краже 26 секретов из 13 репозиториев. Встроенные механизмы одобрения GitHub блокировали значительную часть вредоносных действий, однако повторное использование уже существующих процессов помогло атакующим обойти эти ограничения.

Очистка пострадавших репозиториев также шла медленно. К 5 октября удалить вредоносный код успели только 124 владельца из 772 — около 16%. Само удаление файла не гарантирует устранения последствий: похищенные ключи могли сохранять действительность, а сведения о них — оставаться в истории Git.

Что проверить администраторам

• Изучить журналы аудита GitHub и активность PAT, чтобы определить, какие учетные записи изменяли файлы в каталоге .github/workflows/.
• Проверить историю запусков GitHub Actions и установить, какие секреты могли быть доступны вредоносным процессам.
• Немедленно отозвать учетные данные всех скомпрометированных аккаунтов с правом записи, даже если подозрительный процесс уже удален.
• Обновить и перевыпустить облачные ключи, учетные данные для развертывания, токены реестров и API-ключи ИИ-провайдеров.
• Заменить пароли и ключи, удаленные из кода месяцы назад: они могли сохраниться в истории Git и оставаться действительными.

Ситуация показывает, что защита CI/CD не ограничивается настройками самих GitHub Actions. Компрометация учетной записи с правом записи позволяет изменить доверенный процесс сборки и получить доступ к секретам уже на этапе выполнения. Поэтому после обнаружения вредоносного workflow необходимо проверять не только текущие файлы, но и историю изменений, журналы аудита и все связанные с репозиторием учетные данные.