Дві незалежні команди безпеки — Aikido Security та SafeDep — зафіксували масштабну кампанію з викрадення хмарних та інфраструктурних облікових даних через екосистему GitHub. За даними Aikido, зловмисник використав облікові дані 4837 зламаних акаунтів, щоб впровадити шкідливий скрипт у репозиторії, доступні цим користувачам для запису. Скрипт, за оцінкою компанії, спрацював як мінімум у 1806 репозиторіях. Окремий аналіз SafeDep виявив 8093 репозиторії, що отримали шкідливі зміни в період з 12:46 UTC у вівторок до 04:36 UTC 12 листопада. Важливо, що ця цифра враховує всі виявлені репозиторії зі шкідливими комітами, а не лише ті, де скрипт фактично виконався. При цьому перевірка охоплювала лише основні гілки публічних проектів, тому реальний масштаб інциденту, як визнають аналітики, може бути більшим.
Як починалася атака: тестовий pull request
Кампанія стартувала з розвідки: зловмисник надсилав тестовий запит на злиття змін (pull request) із заголовком «docs: dependency audit notes» із гілки wfx-docs, перевіряючи, чи може скомпрометований акаунт дійсно змінювати вміст репозиторію. Подібні запити з'явилися у 61 764 проектах, після чого в частині з них додавався викрадач секретів. SafeDep виявила 7309 випадків впровадження скрипта в існуючі робочі процеси GitHub Actions та ще 771 випадок, коли шкідливий код поширювався через механізм npm postinstall — автоматичне виконання коду при встановленні пакета. В останньому випадку скрипт міг запускатися не лише у хмарній інфраструктурі проекту, а й безпосередньо на комп'ютері розробника. Зазвичай після впровадження зловмисник відкатував зміни через кілька хвилин, а журнали виконання видалялися разом із самими запусками, тому відсутність видимих слідів атаки ще не означає, що дані не були викрадені.
Що саме викачував скрипт
Шкідливий код збирав практично всі доступні йому облікові дані: секрети GitHub Actions, токени GITHUB_TOKEN, тимчасові токени OIDC та Actions Runtime, ключі ШІ-сервісів, а також дані з файлів конфігурації AWS, Azure, Google Cloud, Kubernetes, npm, PyPI та SSH. Додатково скрипт копіював вміст репозиторію, останні 100 комітів та нещодавні артефакти робочих процесів. На власних серверах компаній (self-hosted runners) він міг отримувати додаткові хмарні облікові дані з метаданих віртуальних машин, відомості про Docker-контейнери та конфігурації systemd. Викрадена інформація надсилалася через HTTP POST на віддалені сервери або в Telegram: при перевірці 200 шкідливих комітів приблизно у 20% випадків використовувався виключно Telegram.
Закріплення у хмарній інфраструктурі
Особливу небезпеку становили механізми закріплення (persistence) у хмарі. Отримавши токени GitHub OIDC, зловмисник міг обмінювати їх на сеанси доступу до AWS, Google Cloud та Azure, створювати постійні ключі AWS і змінювати політики довіри хмарних ролей. В Azure він міг додавати федеративні облікові дані з префіксом wfx-ci-, що дозволяють робочим процесам авторизуватися без збереженого пароля. Ключова проблема в тому, що такі механізми могли продовжувати працювати навіть після відкликання початкових токенів та зміни ключів, що робить стандартні заходи реагування недостатніми без повного аудиту політик довіри.
Зв'язок із атакою GhostAction
Aikido також виявила перетин з атакою GhostAction, проведеною в жовтні: акаунти, що постраждали тоді, приблизно в 1000 разів частіше ставали учасниками нової кампанії. При цьому компанія поки що не пов'язує обидві атаки з одним і тим самим зловмисником, оскільки в них використовувалися різні інструменти та інфраструктура. Для постраждалих організацій це означає необхідність термінового відкликання всіх токенів і ключів, аудиту політик довіри хмарних ролей, перевірки робочих процесів GitHub Actions та npm-залежностей, а також моніторингу аномальних авторизацій, у тому числі федеративних облікових даних із підозрілими префіксами.
