Нова вълна от кампанията за атака по веригата за доставки GhostAction компрометира 772 публични хранилища в GitHub, използвайки фалшиви конфигурационни файлове за GitHub Actions, за да открадне идентификационни данни от CI/CD среди.
Активността се проведе от 31 август до 30 септември 2026 г. и беше насочена към 2 577 конфиденциални данни (secrets) в 373 потребители и организации в GitHub, включително облачни ключове, SSH данни за автентификация, данни за вход в регистри за контейнери, пароли за бази данни и GitHub токени.
Разследването на GitGuardian показва, че кампанията използва откраднат достъп до профили в GitHub, за да добавя злонамерени работни процеси (workflows) от името на самата жертва.
Злонамерените файлове изглеждат като стандартни актуализации на автоматизацията, което ги прави лесни за пропускане при бърз преглед на кода. В повечето случаи атакуващият е добавял работен процес с име github_actions_security.yml с съобщение при комит Add Github Actions Security workflow.
Работният процес изчаква нормално изпращане на промени (push) към хранилището, прочита избрани конфиденциални данни от GitHub Actions и ги изпраща към контролирана от атакуващия инфраструктура чрез curl POST заявка.
Тази техника наподобява по-ранни активности за кражба на идентификационни данни чрез фалшиви CI актуализации, при които промени в работните процеси, изглеждащи рутинни, бяха използвани за достъп до токени и облачни данни за достъп.
Анализаторите от GitGuardian идентифицираха най-новата активност на GhostAction, след като изследователи от Cynative независимо забелязаха подозрителни комити и се свързаха с компанията.
GitGuardian разкри за първи път GhostAction през септември 2025 г., когато кампанията компрометира 817 публични хранилища и събра най-малко 3 325 конфиденциални данни.
Най-новите констатации показват, че това не е било краткотрайно събитие: злонамерени работни процеси от по-ранни вълни са останали в някои хранилища и по-късно са били актуализирани с нови крайни точки за кражба на данни.
Кампанията за атака по веригата за доставки GhostAction използва злонамерени GitHub Actions
GhostAction не събира просто всяка променлива, налична за изпълнителя на работния процес (workflow runner). Вместо това изглежда, че работният процес проверява съществуващата история на работните процеси и конфигурациите на хранилището за референции към конфиденциални данни във формат ${{ secrets.NAME }}.
След това той вмъква същите тези имена на конфиденциални данни в добавения работен процес. Това прави злонамерения файл по-целенасочен и му позволява да събира идентификационни данни, които е вероятно да са полезни за внедряване (deployment), публикуване, управление на облачни среди или достъп до изходния код.
Най-новият злонамерен код (payload) изпраща данни по незащитен HTTP протокол към 193.32.204.199, заменяйки по-старата инфраструктура на GhostAction. По-малък вариант, забелязан в седем хранилища, използва security-check.yml, показва име на работния процес „Security Check“ и използва съобщение при комит Add security check workflow.
Този вариант изпраща данни към API крайна точка, съдържаща уникален идентификатор на инжекцията, което подсказва, че операторът може да проследява откраднатите идентификационни данни по хранилище или по инстанция на работния процес.
Използването на скрити работни процеси за осигуряване на устойчивост (persistence) също съответства на атаката по веригата за доставки в npm Shai-Hulud, която инжектираше GitHub Actions файлове, за да продължи събирането на конфиденциални данни след първоначалното компрометиране.
GitGuardian регистрира три големи пика в новата вълна: 143 хранилища на 31 август; около 400 хранилища между 2 и 5 септември, включително 294 само на 5 септември; и 103 хранилища на 15 септември. От прегледаните 3 669 изпълнения на работни процеси в 605 хранилища, GitHub е задържал повечето от тях за одобрение.
Въпреки това 499 са се изпълнили в 32 хранилища, а 336 изпълнения са завършили успешно, което е позволило кражбата на 26 конфиденциални данни от 13 хранилища. Най-често атакуваните стойности са били частни SSH ключове и данни за автентификация към сървъри за внедряване, представляващи 446 референции към конфиденциални данни.
Данни за достъп до Azure са били обект на атака 218 пъти, докато данни за достъп до Docker Hub и GitHub Container Registry са се появили 142 пъти.
Работните процеси са търсили също пароли за бази данни, AWS ключове за достъп, FTP данни за автентификация, данни за достъп до Google Cloud и Firebase, GitHub токени и API токени за услуги като Cloudflare, npm, PyPI, Slack, Telegram, Discord и AI платформи.
Това отразява нарастващия риск, описан при злоупотребата с доверени инструменти за разработка, където системите на разработчиците и конвейерите за изграждане (build pipelines) се използват като път за достъп до облачни среди и изходен код.
Кампанията GhostAction никога не е спирала напълно
Най-силният знак за устойчивост на кампанията е, че в 92 случая киберпрестъпникът не е създал нов работен процес. Вместо това той е актуализирал вече компрометиран файл, използвайки съобщението при комит Update Github Actions Security workflow.
Тези файлове са оцелели от по-ранни периоди на кампанията и са били модифицирани да използват новия сървър за събиране на данни. Изследователите свързаха същия модел на работен процес с по-стари крайни точки, включително bold-dhawan.45-139-104-115.plesk.page, carte-avantage.com, 170.39.218.2 и Interactsh домейни от вида *.oast.fun.
Едва 124 от 772-те засегнати хранилища (или 16%) са били ефективно изчистени в публичната история на комитите към 5 октомври. Тази цифра е от значение, тъй като злонамерен работен процес може да се задейства отново всеки път, когато разработчик изпрати легитимен комит.
Затова организациите трябва да третират премахването на работния процес само като част от мерките за реакция. Те трябва да установят как атакуващият е получил права за запис в хранилището, да отменят компрометираните данни за достъп в GitHub, да прегледат изпълненията на работните процеси и логовете за одит, и да подменят (rotate) всички конфиденциални данни, които може да са били достъпни за изпълнителя.
GitHub съветва екипите да ограничават всеки работен процес и GITHUB_TOKEN до минимално необходимите разрешения, да одитират изходния код на работните процеси и действията от трети страни (third-party actions), и да фиксират действията към пълен SHA хеш на комита, което осигурява неизменяема референция.
Организациите трябва също така да използват механизми за одобрение на средата (environment approval controls) за чувствителни конфиденциални данни за внедряване и внимателно да преглеждат новодобавените или модифицирани файлове в директорията .github/workflows/. На насоките на GitHub за безопасна употреба се отбелязва, че разкрити конфиденциални данни трябва да бъдат подменени, дори когато са били маскирани в логовете.
GitGuardian откри и майнер за криптовалута в хранилището kuafuai/DevOpsGPT, което по-късно бе засегнато от GhostAction. Изследователите обаче не приписват двете събития на един и същ оператор.
Майнерът е използвал фалшифициран имейл на автор, персонализиран злонамерен код, изпълним файл на XMRig, маскиран като /usr/local/bin/pyworker, и различен оперативен стил, докато GhostAction разчита на широкомащабно, автоматизирано инжектиране на работни процеси чрез GitHub API.
Припокриването все пак подчертава един ключов проблем: откраднати идентификационни данни от GitHub могат да бъдат преизползвани от няколко несвързани групи от злонамерени субекти. Компрометиран профил на поддържащ проекта (maintainer) може да бъде използван за събиране на конфиденциални данни от CI/CD, инжектиране на злонамерен код, публикуване на променени пакети или изпълнение на задачи за копаене на криптовалута.
Както показва скорошната активност от заплахи по веригата за доставки на софтуер, профилът на един-единствен разработчик може да се превърна в входна точка към системи за изграждане, облачни профили, регистри за пакети и среди на крайни клиенти.
За защитниците основният урок е контролът върху самоличността. Екипите трябва не само да премахнат съмнителните файлове с работни потоци и да ротират облачните ключове, но и да отменят компрометираните токени за личен достъп (PAT) в GitHub, да наложат устойчива на фишинг двуфакторна автентификация, да изискват преглед при промени в работните потоци, да прилагат принципа на минималните привилегии и да наблюдават изходящия мрежов трафик от машините за изпълнение на CI/CD (CI runners).
При инцидентите с GhostAction оставянето на оригиналните откраднати идентификационни данни за GitHub активни би могло да позволи на същия атакуващ — или на друг субект, разполагащ с тези данни — да се върне отново.
Индикатори за компрометиране (IoCs):-
| Тип IoC | Индикатор | Контекст |
|---|---|---|
| Зловреден файл на работен поток | github_actions_security.yml | Основен GhostAction работен поток, инжектиран в хранилищата на жертвите |
| Показвано име на работния поток | Github Actions Security | Име, използвано от основния зловреден работен поток |
| Съобщение при ъпдейт (commit message) | Add Github Actions Security workflow | Често срещано съобщение при ъпдейт, използвано за добавяне на работния поток |
| Съобщение при ъпдейт (commit message) | Update Github Actions Security workflow | Използвано за модифициране на съществуващ зловреден работен поток |
| Вариант на файл на работен поток | security-check.yml | Вариант, наблюдаван в седем хранилища |
| Вариант на име на работен поток | Security Check | Име, използвано от по-малкия вариант на работния поток |
| Вариант на съобщение при ъпдейт | Add security check workflow | Съобщение при ъпдейт, използвано от варианта |
| Текущ IP адрес за източване на данни | 193[.]32[.]204[.]199 | Plain-HTTP дестинация за откраднати тайни (secrets) |
| Вариант на крайни точки на API (API endpoint) | hxxp://193[.]32[.]204[.]199:3000/api/workflow/receive?inj=<id> | Крайна точка за събиране на данни при отделно инжектиране |
| Историческа крайна точка | bold-dhawan.45-139-104-115[.]plesk[.]page | Инфраструктура на GhostAction, използвана през 2025 г. |
| Историческа крайна точка | carte-avantage[.]com | Инфраструктура на GhostAction, използвана през 2025 г. |
| Исторически IP адрес | 170[.]39[.]218[.]2 | Крайна точка, използвана от октомври–декември 2025 г. и март 2026 г. |
| Исторически модел на домейн | *.oast[.]fun | Модел на крайна точка на базата на Interactsh, използван в края на 2025 г. и началото на 2026 г. |
| Съмнително поведение на работния поток | curl -s -X POST -d | Модел на команда, използван за външно изпращане на избрани тайни от GitHub Actions |
Забележка: IP адресите и домейните са нарочно дезактивирани (напр. [.]), за да се предотврати случайно разрешаване на имена или създаване на хипервръзки. Възстановете ги само в рамките на контролирани платформи за анализ на заплахи като MISP, VirusTotal или вашата SIEM система.