Вредоносные образы Docker KICS и расширения vs code в цепочке поставок Checkmarx — Supply Chain
«Компрометация Docker-образов Checkmarx KICS и расширений VS Code показывает, как атакующие используют доверие к официальным репозиториям для кражи учётных данных и распространения вредоносного кода через цепочку поставок.» https://thehackernews.com/2026/04/malicious-kics-docker-images-and-vs.html
Что произошло с репозиторием checkmarx kics
Исследователи Socket и Docker обнаружили подменённые образы в официальном репозитории checkmarx/kics на Docker Hub. Злоумышленники перезаписали существующие теги v2.1.20 и alpine, а также добавили новый тег v2.1.21, которому не соответствует ни один официальный релиз.
Анализ отравленного образа показал, что встроенный бинарный файл KICS был модифицирован. В него добавили функции сбора данных и их передачи на внешний сервер. Вредонос мог генерировать отчёт сканирования без цензуры, шифровать его и отправлять на командный сервер.
SHA256 для образа v2.1.20 с архитектурой amd64: d186161ae8e33cd7702dd2a6c0337deb14e2b178542d232129c0da64b1af06e4. Если ваш образ совпадает с этим хешем, система скомпрометирована.
[√] Образ получен из официального репозитория checkmarx/kics
[ ] Хеш образа не совпадает с опубликованными индикаторами компрометации
[ ] Сканирование проводилось с файлами, содержащими учётные данные
Как работает вредонос mcpaddon js в расширениях vscode
Атака затронула не только контейнеры. Исследователи нашли подозрительный код в расширениях VS Code от Checkmarx. Версии cx-dev-assist 1.17.0 и 1.19.0, а также ast-results 2.63.0 и 2.66.0 загружали и выполняли внешний файл mcpAddon.js через среду выполнения Bun [[15]].
Файл mcpAddon.js весит около 10 мегабайт. Он был добавлен в репозиторий через поддельный коммит 68ed490b, который выглядел так, будто создан в 2022 году. Атакующие использовали технику манипуляции историей Git, чтобы скрыть вредоносную вставку.
Когда расширение активируется, оно скачивает mcpAddon.js с жёстко прописанного адреса на GitHub. Файл сохраняется в ~/.checkmarx/mcp/ и сразу запускается. Программа не запрашивает подтверждение у пользователя и не проверяет целостность загруженного кода.
Интересно, почему имя файла содержит аббревиатуру MCP. Возможно, это попытка замаскировать вредонос под легитимную функцию Model Context Protocol. Или просто совпадение. Я не нашёл официальных комментариев от авторов расширения на этот счёт.
[√] Расширение установлено из VS Code Marketplace, а не Open VSX
[ ] Версия расширения не входит в список скомпрометированных
[ ] В директории ~/.checkmarx/ отсутствует файл mcpAddon.js
Какие данные собирает вредонос и куда их отправляет
Вредонос mcpAddon.js действует как похититель учётных данных. Он использует оболочку системы (PowerShell или Bash) для перечисления и извлечения чувствительной информации.
Список извлекаемых данных включает токены аутентификации GitHub, учётные данные AWS, токены Microsoft Azure, базы данных учётных данных Google Cloud, конфигурационные файлы NPM, SSH-ключи, переменные окружения и файлы конфигурации Claude и других систем MCP [[15]].
На Windows вредонос запускает команды вроде gh auth token для получения токена GitHub или gcloud config config-helper --format json для извлечения учётных данных Google Cloud. Для Azure используется PowerShell-скрипт, который извлекает токены доступа к управлению ресурсами.
Собранные данные сжимаются, шифруются и отправляются двумя путями. Первый — внешний конечный пункт https://audit.checkmarx[.]cx/v1/telemetry. Второй — публичные репозитории GitHub, созданные в аккаунтах жертв с использованием украденных токенов.
Закономерность в именах созданных репозиториев следуют шаблону <слово> - <слово> -<3 цифры>. Примеры: gesserit-melange-813, prescient-sandworm-556. Лексика явно отсылает к вселенной Дюны Фрэнка Герберта. Это либо фирменный стиль группы атакующих, либо попытка скрыть каналы эксфильтрации среди множества легитимных репозиториев.
Как вредонос использует github actions для распространения
После кражи учётных данных вредонос переходит к следующему этапу. Он использует украденные токены GitHub для внедрения вредоносного рабочего процесса в репозитории жертвы.
Атакующий создаёт новую ветку в целевом репозитории. В эту ветку добавляется файл .github/workflows/format-check.yml. GitHub Actions автоматически обнаруживает и выполняет любой файл рабочего процесса в этой директории при событии push.
Внедрённый рабочий процесс извлекает все секреты репозитория через выражение ${{ toJSON(secrets) }}. Это выражение сериализует весь контекст секретов в JSON-строку. Затем данные записываются в файл и загружаются как артефакт рабочего процесса.
Атакующий может скачать этот артефакт через API GitHub, используя любой токен с правом actions:read. Артефакты хранятся до 90 дней, что даёт злоумышленнику достаточно времени для сбора данных.
После выполнения вредоносный рабочий процесс и ветка удаляются. Это скрывает следы активности. Я проверил логи нескольких репозиториев — без детального аудита такие изменения легко пропустить.
[√] В репозитории отсутствуют неожиданные рабочие процессы в .github/workflows/
[ ] Нет артефактов с именами вроде format-results
[ ] История веток не содержит удалённых веток с подозрительными именами
Как происходит распространение через экосистему npm
Финальная стадия атаки переключается на распространение через npm. Вредонос использует украденные учётные данные npm для поиска пакетов, которые жертва может публиковать.
Программа читает файл .npmrc жертвы. Если в нём есть токен аутентификации с правами на публикацию, атакующий получает возможность изменять пакеты жертвы.
Сначала вредонос запрашивает список пакетов через API npm: /-/org/ /package. Он фильтрует пакеты с правами write. Если аутентифицированный запрос не срабатывает, используется поисковый запрос: https://registry.npmjs.org/-/v1/search?text=maintainer: &size=250.
Собранный список пакетов используется для повторной публикации каждого пакета с внедрённым вредоносным кодом. Это создаёт эффект червя в экосистеме npm — каждый скомпрометированный пакет становится новым источником распространения.
Если ваш пакет был перепубликован без вашего ведома, вы можете не заметить это сразу. Версия изменилась, но имя осталось прежним. Только внимательный аудит истории публикаций или сравнение хешей может выявить подмену.
Какие индикаторы компрометации нужно проверить
Для обнаружения атаки проверьте следующие индикаторы.
Сетевые индикаторы включают домен audit.checkmarx[.]cx и IP-адрес 94.154.172.43. Любое исходящее соединение с этими адресами из среды разработки или CI/CD должно рассматриваться как признак компрометации.
Хеши файлов для mcpAddon.js: SHA256 24680027afadea90c7c713821e214b15cb6c922e67ac01109fb1edb3ee4741d9. Для бинарного файла kics: SHA256 2a6a35f06118ff7d61bfd36a5788557b695095e7c9a609b4a01956883f146f50.
Для расширений VS Code проверьте версии. Скомпрометированы: checkmarx/cx-dev-assist версий 1.17.0 и 1.19.0, checkmarx/ast-results версий 2.63.0 и 2.66.0 [[15]].
Для Docker-образов проверьте дайджесты. Например, тег alpine имел дайджест индекса sha256:2588a44890263a8185bd5d9fadb6bc9220b60245dbcbc4da35e1b62a6f8c230d.
Попробуйте выполнить простую проверку:
$ find ~/.checkmarx -name "mcpAddon.js" 2>/dev/null
Если файл найден, система скомпрометирована. Удалите файл и проведите полный аудит.
Кто стоит за атакой на цепочку поставок checkmarx
Исследователи связывают атаку с группой угроз TeamPCP. Эта группа уже атаковала Checkmarx в марте 2026 года, скомпрометировав рабочие процессы GitHub Actions [[21]].
Аккаунт @pcpcats в социальной сети X опубликовал сообщение: «Thank you OSS distribution for another very successful day at PCP inc.». Это сообщение появилось вскоре после публикации деталей инцидента.
TeamPCP специализируется на атаках на цепочки поставок открытого исходного кода. Группа использует украденные учётные данные для внедрения вредоносного кода в легитимные артефакты. Цель — не просто кража данных, а создание новых каналов распространения через скомпрометированные аккаунты разработчиков.
Невозможно с уверенностью сказать, почему эта группа выбирает именно инструменты безопасности вроде KICS. Возможно, это ирония. Или попытка получить доступ к самым чувствительным данным через сканеры инфраструктуры.
Как защитить систему после инцидента с checkmarx
Если вы использовали скомпрометированные артефакты, предпримите следующие шаги.
Немедленно удалите затронутые расширения, рабочие процессы и образы контейнеров из систем разработчиков и сред сборки. Не просто обновите — полностью удалите и переустановите из проверенных источников.
Ротируйте все учётные данные, которые могли быть доступны скомпрометированным средам. Это включает токены GitHub, токены npm, учётные данные облачных провайдеров, SSH-ключи и секреты CI/CD.
Проверьте GitHub на наличие несанкционированного создания репозиториев или подозрительных рабочих процессов. Ищите репозитории с описанием «Checkmarx Configuration Storage» или именами по шаблону <слово> - <слово> -<3 цифры>.
Проведите аудит npm на предмет несанкционированных публикаций пакетов. Сравните хеши опубликованных версий с локальными копиями.
В облачных средах проверьте журналы доступа на предмет необычного использования секретов, токенов или вновь выданных учётных данных.
[√] Все скомпрометированные артефакты удалены из сред разработки
[ ] Все потенциально затронутые учётные данные ротированы
[ ] Проведён аудит репозиториев GitHub и публикаций npm
Закрепляйте зависимости по хешу, а не по тегу. Используйте короткоживущие учётные данные. Ограничивайте права токенов минимально необходимыми разрешениями.