Злоумышленник, стоящий за атакой на цепочку поставок GhostAction, вышел за рамки внедрения вредоносных рабочих процессов GitHub Actions в скомпрометированные проекты, начав фишинговые атаки на разработчиков открытого исходного кода и распространяя вредоносное ПО-стилер, замаскированное под файл шрифта. Последняя эволюция, подробно описанная OpenSourceMalware, свидетельствует об активной доработке злоумышленниками своих методов в ответ на меры, предпринятые GitHub для предотвращения выполнения рабочего процесса. По данным платформы Threat Intelligence, злоумышленник зарегистрировал домен “my-github[.]com” и направил его на IP-адрес “193.32.204[.]199”, который также используется для эксфильтрации данных, собранных в результате выполнения вредоносного рабочего процесса. Домен был зарегистрирован 9 октября 2026 года, через 17 дней после регистрации домена “my-gitlab[.]com”. Неясно, управляется ли последний домен, связанный с хостингом кода, тем же злоумышленником. “Он следует тому же шаблону именования my-.com, что делает его полезным для дальнейших действий, но текущая инфраструктура напрямую не связывает его с GhostAction”, — сказал исследователь безопасности Пол Маккарти. “Они используют разные регистраторы, записи о регистрантах, пары DNS-серверов Cloudflare, IP-адреса, ASN и DNS-дизайн, и не было обнаружено никаких общих сертификатов или артефактов учетных записей”. С тех пор домен “my-github[.]com” использовался в фишинговом письме, имитирующем оповещение безопасности GitHub, для нацеливания на мейнтейнера открытого исходного кода в тот же день, когда он был зарегистрирован. Сообщение, отправленное с адреса “noreply@my-github[.]com”, предупреждало о новом входе в учетную запись GitHub из Москвы, Россия, и предлагало перейти по ссылке для защиты учетной записи. Обманчивая страница, по данным OpenSourceMalware, действовала как обратный прокси, собирая пароль жертвы и код двухфакторной аутентификации (2FA), а также внедряла JavaScript, который авторизовал OAuth-приложение с разрешениями на изменение рабочих процессов, чтобы облегчить атаку в стиле GhostAction. Поддельная страница входа также содержит JavaScript для скрытой авторизации потока устройств GitHub OAuth с областями действия repo, workflow и read:org, предоставляя широкие разрешения на чтение/запись репозиториев, изменение файлов рабочих процессов Actions и получение информации о членстве в организации и связанных с ней данных. Идея заключается в том же, что и при фишинге с использованием кодов устройств, когда конечная цель состоит в том, чтобы получить токен доступа от GitHub и эксфильтровать его на “my-github[.]com” по TCP/8443. “Скрипт получает код устройства и пользовательский код, загружает /login/device, извлекает формы GitHub из возвращаемого HTML и автоматически отправляет их”, — объяснил Маккарти. “Он вставляет пользовательский код, находит форму авторизации, добавляет authorize=1 и отправляет одобрение через аутентифицированную прокси-сессию жертвы”. “Жертве не нужно вводить код устройства или сознательно одобрять OAuth-приложение. Этот набор идет дальше, автоматизируя шаги с пользовательским кодом и авторизацией через сессию с обратным прокси”. Кража OAuth-токена с областью действия репозитория предоставляет злоумышленнику многоразовый учетный идентификатор API. Кроме того, разрешения, предоставленные посредством скрытой авторизации OAuth, соответствуют способности GhostAction перечислять репозитории и внедрять вредоносные файлы рабочих процессов в папку “.github/workflows/”. “Теперь злоумышленник может сочетать автоматизацию в масштабе репозитория с индивидуальным социальным инжинирингом против людей, чьи учетные записи предоставляют доступ к проектам, организациям, реестрам и нижестоящим пользователям”, — заявили в OpenSourceMalware. Что еще хуже, кампания также была замечена с использованием компонента второй стадии, который сохраняется на машинах разработчиков даже после удаления вредоносного рабочего процесса. В частности, этот подход заимствует из тактики Северной Кореи, фиксируя три разных файла. Это приводит к автоматическому запуску VS Code для кражи учетных данных, который, помимо сбора данных, устанавливает cron-задачу, выполняющую код, предоставленный злоумышленником, каждые пять минут. Собранные данные отправляются на тот же сервер по незашифрованному HTTP на порт 8080. Всего было выявлено 94 скомпрометированных репозитория со вторым компонентом. Что касается второго рабочего процесса CI, то он такой же, как и исходный вредоносный рабочий процесс, но с добавленными форматами учетных данных для поиска и резервным вариантом, который загружает результаты в секретный GitHub gist, если POST-запрос не удается. Второй рабочий процесс имеет следующие названия: OpenSourceMalware сообщил, что 94 репозитория принадлежат 66 владельцам, из которых 15 были удалены, переименованы или сделаны приватными. Из все еще доступных репозиториев большинство оказались в значительной степени заброшенными, причем один из них не трогали более девяти лет. Шестьдесят пять из 79 не имели коммитов более года. “Для первой стадии требуется, чтобы GitHub запускал рабочий процесс”, — заявили в OpenSourceMalware. “9 октября GitHub начал предотвращать запуск вредоносного рабочего процесса, и волны 10 и 12 октября не извлекли никаких секретов. Вторая стадия добавляет загрузчик, которому вообще не нужен раннер, и он появился через шесть дней после блокировки. Мы не можем сказать, что блокировка стала причиной. Мы можем сказать, что оператор переместился туда, куда не достают средства контроля GitHub”. Для смягчения угрозы разработчикам следует отозвать доступ GitHub и токены с чистого устройства, сменить пароли, проверить свои репозитории, ротировать все учетные данные, к которым могут получить доступ рабочие процессы, и предупредить пользователей, которые клонировали репозитории. “Мы не знаем, кто оператор, но его работа предполагает ограниченный опыт”, — сказала Дженн Гил, соучредитель OpenSourceMalware, The Hacker News. “Фильтр переменных среды стилера пропускает большинство API-ключей, его поиск в домашнем каталоге может истечь и отбросить собственные результаты, а один IP-адрес обрабатывает эксфильтрацию, фишинг и шумное сканирование интернета. Последняя ошибка — причина, по которой поиск по IP-адресу все еще находит заражения”.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
