Кампания testmetest подготовила к запуску полезной нагрузки 42 репозитория на GitHub, принадлежащих 11 владельцам с настоящей историей разработки. Внутри появились исполняемые хуки для помощников программиста и сред разработки, а также полиморфные обёртки размером от 12,9 до 13,7 МБ. После декодирования все обёртки дают одну и ту же скрытую нагрузку, а пустых заглушек вместо неё не оказалось ни в одном из 42 репозиториев. Отдельный репозиторий, принадлежащий оператору кампании, принимает зашифрованные снимки данных.
Описание
Запуск привязан к повседневным действиям разработчика. Хук, то есть обработчик события, срабатывает при старте сессии в Claude, при открытии рабочей папки в VS Code, через настройки Cursor и Gemini; в части проектов изменены сценарии сборки пакетов и файлы сборки. По данным JFrog Security Research, десять найденных обёрток после декодирования дают побайтово совпадающую нагрузку размером около 2 МБ. Разница в размерах объясняется кодированием: смена ключа меняет долю трёхзначных десятичных значений и сдвигает размер файла на сотни килобайт.
Позднее доставку перевели на скомпилированную нативную добавку Node, то есть бинарный модуль расширения. Своей нагрузки добавка не несёт и при запуске расшифровывает лежащий рядом файл, замаскированный под остаточный кэш сборки, после чего запускает полученный сценарий отдельным процессом. Перед этим она проверяет окружение: переменные систем непрерывной интеграции, признаки контейнеров и песочниц (изолированных сред), объём памяти около 1,5 ГБ и меньше, число процессоров, наличие отладчика. Сборка для Windows дополнительно просматривает список процессов и завершается, если находит сетевой анализатор, монитор процессов или отладчик уровня пользователя; ещё одно проверяемое имя осталось неразрешённым. Поэтому нагрузка молчит на машинах автоматических сканеров пакетов и срабатывает на рабочем месте разработчика.
Второй механизм - скрытый публикатор пакетов. На короткоживущих ветках нескольких репозиториев лежал сценарий и рабочий процесс GitHub Actions с тремя переменными, привязывавшими запуск к конкретному пакету, рабочему процессу и репозиторию. После проверки окружения публикатор собирал токены GitHub, запрашивал идентификационный токен Actions с аудиторией npm, обменивал его на токен публикации и выпускал изменённую версию пакета. Связь конкретного выпуска с автоматическим запуском не подтверждена: подходящего сохранённого запуска не нашлось, а ближайшие записи относятся к другому времени. Предположительно версию опубликовали вручную либо запуск впоследствии удалили.
Хуки размещались в аккаунтах реальных разработчиков, студентов и одной действующей организации. Часть коммитов несла подделанные даты авторства: в конце сентября оператор перенёс старые сообщения и даты из настоящей истории и добавил пометку о пропуске проверок. Настоящие проверочные волны прошли в июле, когда несколько репозиториев получили вспомогательные файлы. В одном случае коммиты в чужой репозиторий подписаны учётной записью другого взломанного пользователя. По всей видимости, доступ получили через украденные права соучастника, а не через компрометацию самого владельца.
Отдельные ветки несли рабочий процесс с именем CodeQL, который не выполнял сканирование кода. Вместо этого он выгружал переменные окружения, включая токен npm, в архив артефакта со сроком хранения один день. До истечения срока сохранили 29 таких артефактов; в них нашлись три различных токена npm реального формата, менявшихся между шестью репозиториями. Остальные похожие на секреты строки оказались примерами из документации и короткими заглушками.
В том же кластере взломанных владельцев обнаружены рабочие процессы, которые скачивали двоичный файл с внешнего сервера и запускали сканирование cPanel и WHM с перебором портов. Аргументы запуска прямо указывают на попытки эксплуатации CVE-2026-41940, обхода аутентификации в cPanel & WHM и WP Squared, внесённого в каталог известных эксплуатируемых уязвимостей CISA. Ранее ту же схему и тот же сервер описывали в публичном разборе эксплуатации cPanel. Успешная эксплуатация нижестоящих систем не подтверждена, поэтому цели сканирования не считаются дополнительными жертвами.
Границы картины очерчены не полностью. Разбор репозитория-приёмника ограничился метаданными: зашифрованные снимки не расшифровывали, поэтому установить, чьи данные там оказались и сколько систем затронуто, нельзя. Наличие хуков и ветвей само по себе не доказывает, что нагрузка сработала на каждой взломанной машине. Похожие конфигурации помощников и пометки о пропуске проверок встречаются и в легитимных проектах, так что отдельные совпадения могут быть ложными. Кроме того, более ранний публичный разбор не подтверждал компрометацию сторонних пакетов и жертв, и расхождение с ним объясняется не только сроками: обёртки оказались слишком большими для поиска по коду и выдачи файлов через интерфейс платформы.
Индикаторы компрометации
