GhostAction: зламано близько 1 900 облікових записів GitHub, постраждали понад 30 000 репозиторіїв

У межах кампанії 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-файлів, а за двома результатами: доступи скомпрометованих облікових записів відкликано, а для решти ключів визначено перелік запусків, під час яких вони могли бути доступні, і ухвалено рішення про перевипуск. Це обсяг роботи, який можна перевірити для конкретного проєкту. Масштаб усієї кампанії сам собою не показує, які саме секрети були доступні в окремому репозиторії.

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

1. Хакеры взломали 1 900 аккаунтов GitHub и атаковали 30 000 репозиториев habr.com

Про автора

Відас Сакалаускас

бекенд-розробник

Розробляю API й відповідаю за продуктивність сервісів. Віддаю перевагу невеликим змінам із зрозумілими метриками, а не великим переписуванням «на перспективу».

Усі публікації автора