Оператор атаки на цепочку поставок GhostAction начал фишинговую кампанию против разработчиков open source и внедряет стилер учётных данных под видом файла шрифта. На втором этапе вредоносный код может запускаться на рабочей станции разработчика и сохраняться после удаления вредоносного workflow GitHub Actions.
Исследователи OpenSourceMalware обнаружили 94 скомпрометированных репозитория с компонентами второго этапа атаки. Они принадлежат 66 владельцам. Пятнадцать репозиториев позднее удалили, переименовали или сделали приватными. По оценке исследователей, большинство доступных проектов фактически заброшено: в 65 из 79 репозиториев не было коммитов более года, а один не обновлялся свыше девяти лет.
Фишинг под уведомление GitHub
Для кампании зарегистрировали домен my-github[.]com. Он указывает на 193.32.204[.]199 — тот же IP-адрес, который используется как точка получения данных из вредоносного workflow. Домен появился 9 октября 2026 года, через 17 дней после регистрации my-gitlab[.]com.
Связь my-gitlab[.]com с GhostAction не подтверждена. В OpenSourceMalware отмечают, что оба домена следуют шаблону my-<code-host>.com, но их инфраструктура не пересекается. Для них использованы разные регистраторы, данные владельцев, пары DNS-серверов Cloudflare, IP-адреса, ASN и DNS-схемы. Исследователи также не нашли общих сертификатов и элементов учётных записей.
В день регистрации my-github[.]com применялся для рассылки письма, которое имитировало предупреждение GitHub о безопасности. Сообщение с адреса noreply@my-github[.]com направили одному из open-source-разработчиков. В нём утверждалось, что в аккаунт якобы вошли из Москвы, и предлагалось перейти по ссылке для защиты учётной записи.
Поддельная страница входа, по данным OpenSourceMalware, работала как обратный прокси и могла перехватывать пароль и код двухфакторной аутентификации. Одновременно JavaScript на странице скрытно авторизовывал OAuth-приложение с правами на изменение workflow.
Скрипт использует поток авторизации GitHub OAuth для устройств и запрашивает области доступа repo, workflow и read:org. Этот набор даёт широкие права на чтение и запись в репозиториях, изменение файлов GitHub Actions, а также доступ к данным о членстве в организациях и связанным организационным сведениям.
Механика близка к фишингу кодов устройств, но автоматизирует действия, которые обычно должен выполнить пользователь. Скрипт получает код устройства и пользовательский код, загружает страницу /login/device, извлекает формы GitHub из HTML и отправляет их через проксированную аутентифицированную сессию жертвы. Затем он подставляет пользовательский код, находит форму авторизации, добавляет параметр authorize=1 и подтверждает запрос. Жертве не нужно вручную вводить код устройства или осознанно одобрять OAuth-приложение.
Полученный OAuth-токен может стать многоразовыми учётными данными для API. Его фактический охват определяется правами скомпрометированной учётной записи и настройками организации: запрошенные области доступа позволяют работать с репозиториями и организационными данными, к которым у жертвы есть доступ. Права скрытно авторизованного приложения соответствуют возможностям GhostAction: перечислять репозитории и добавлять вредоносные workflow в каталог .github/workflows/. По оценке OpenSourceMalware, оператор может совмещать автоматизированную работу с репозиториями и адресный социальный инжиниринг против пользователей, чьи аккаунты открывают доступ к проектам, организациям, реестрам и зависимым пользователям. Токен передаётся на my-github[.]com по TCP-порту 8443.
Закрепление через задачу VS Code
Во втором этапе применены приёмы, которые ранее связывали с северокорейскими операциями. В репозитории размещаются три компонента:
- файл tasks.json для Microsoft Visual Studio Code с триггером runOn: folderOpen, запускающим задачу при открытии каталога в редакторе;
- файл public/fonts/fa-solid-400.woff2, содержащий стилер учётных данных;
- дополнительный workflow GitHub Actions, рассчитанный на случай, если стилер на устройстве разработчика не запустится.
При выборе SIEM-платформы для централизованной корреляции журналов можно отдельно изучить Security Capsule SIEM и сопоставить её с требованиями своей инфраструктуры.
Название файла шрифта fa-solid-400.woff2 совпадает с именем, применявшимся в кампании PolinRider в январе 2026 года. Само по себе это совпадение не устанавливает связь GhostAction с северокорейским оператором.
В конкретной вредоносной конфигурации задача VS Code с runOn: folderOpen может запускать стилер при открытии затронутого каталога в редакторе. Выполнение не гарантировано: оно зависит от того, открывает ли пользователь проект в VS Code, а также от политик, режима доверия рабочей области и настроек среды, которые могут блокировать запуск задачи.
Стилер ищет ключи AWS, токены PyPI и npm, учётные данные Git, данные доступа к кластерам Kubernetes, приватные SSH-ключи, а также учётные данные для Anthropic Claude и Google Gemini. Помимо сбора данных вредоносная программа создаёт задание cron, которое запускает предоставленный атакующим код каждые пять минут. Собранная информация отправляется на тот же сервер по обычному HTTP через порт 8080.
Второй CI-workflow похож на первоначальный вредоносный workflow, но дополнен новыми форматами учётных данных для поиска. Если отправить данные POST-запросом не удаётся, он использует резервный канал: загружает найденное в секретный GitHub Gist. Вредоносные workflow встречались под названиями lint.yml, ci-check.yml, build-check.yml, repo-health.yml, audit.yml, code-review.yml, test-suite.yml и cache-cleanup.yml.
Реакция GitHub и ограничения исследования
Первый этап GhostAction требует, чтобы GitHub запустил workflow. По данным OpenSourceMalware, 9 октября GitHub начал блокировать выполнение вредоносного workflow. Поэтому при атаках 10 и 12 октября извлечь секретные данные не удалось.
Локальный механизм второго этапа появился через шесть дней после введения блокировки: задача VS Code может сработать при открытии затронутого каталога при соблюдении условий выполнения и не зависит от запуска workflow на инфраструктуре GitHub. При этом резервный CI-механизм по-прежнему требует выполнения GitHub Actions. Исследователи не утверждают, что локальный триггер стал прямой реакцией на меры GitHub. Однако они отмечают, что оператор перенёс часть активности в область, на которую эти меры не распространяются.
Личность оператора GhostAction остаётся неизвестной. Соосновательница OpenSourceMalware Дженн Джайл считает, что реализация указывает на ограниченный опыт атакующего. В частности, фильтр переменных окружения в стилере пропускает большую часть API-ключей, а поиск в домашнем каталоге может завершаться по тайм-ауту и отбрасывать собственные результаты. Кроме того, один IP-адрес одновременно используется для эксфильтрации, фишинга и заметного интернет-сканирования. По словам исследовательницы, эта ошибка позволяет по IP-адресу по-прежнему находить признаки компрометации.
Что проверить разработчикам
Организациям в России и СНГ, использующим GitHub и VS Code в разработке, имеет смысл проверить репозитории на неизвестные файлы в .github/workflows/, tasks.json и подозрительные файлы в public/fonts/, включая fa-solid-400.woff2. Однако путь public/fonts/fa-solid-400.woff2, само имя fa-solid-400.woff2 или типовые названия workflow, такие как lint.yml, audit.yml и test-suite.yml, не являются самостоятельным подтверждением компрометации. Их следует сопоставлять с содержимым tasks.json и workflow, подтверждённым вредоносным кодом, механизмом cron и неожиданными сетевыми обращениями к my-github[.]com или 193.32.204[.]199.
Отдельного внимания требуют давно не сопровождаемые репозитории: их могут клонировать и открывать локально. Риск запуска возникает для затронутого проекта при открытии его в VS Code и при отсутствии ограничений среды, блокирующих задачу с runOn: folderOpen; одно лишь клонирование не означает выполнения стилера.
При подозрении на компрометацию следует работать с чистого устройства: отозвать доступ GitHub и токены, сменить пароли, провести аудит репозиториев и заменить все учётные данные, к которым могли обращаться workflow. Также необходимо предупредить пользователей, клонировавших затронутые репозитории.
Практический вывод: блокировка вредоносных GitHub Actions сама по себе не устраняет риск, если в репозитории уже есть локальный триггер для VS Code. Проверять нужно не только CI-конфигурацию, но и файлы, выполняемые при открытии проекта на машине разработчика.