У кампании Sandworm_Mode неприятная статистика: из 14 исследованных техник только девять вообще оставили заметный след в телеметрии, а до уровня надёжного алерта дотянули лишь две. Для тех, кто уже встроил AI-ассистентов, CI/CD и LLM-сервисы в повседневную разработку, это означает простую вещь: атаки на AI-инструменты начинают выглядеть как нормальная работа команды, а не как классический инцидент с мигающей красной лампой.
Как пишет Dark Reading, речь идёт о новом классе supply chain-атак, где злоумышленники не столько ломают инфраструктуру в лоб, сколько прячутся внутри доверенных AI- и DevOps-процессов. Ранним примером такого подхода исследователи называют Sandworm_Mode, самораспространяющийся вредоносный код в экосистеме npm. Идея не новая по духу, но новая по исполнению: вместо привычного living off the land с PowerShell и штатными утилитами Windows атакующие начинают жить «за счёт AI toolchain» — использовать те же инструменты, которыми разработчики пользуются каждый день.
История у Sandworm_Mode вполне приземлённая и потому особенно неприятная. В феврале 2026 года исследователи Socket Security описали кампанию, затронувшую 19 вредоносных npm-пакетов. Дальше за неё взялась CrowdStrike и попробовала ответить на практический вопрос: сколько из поведения этой малвари вообще можно поймать стандартной защитой. Ответ оказался без лишнего оптимизма. Часть действий всё же детектировалась: активность вредоносных пакетов, отдельные механизмы закрепления и некоторые эпизоды кражи данных или учётных данных. Но большой кусок цепочки почти не отличался от нормального поведения AI-ассистентов, CI-автоматики и обычных dev-инструментов.
В этом и состоит главный сдвиг. Sandworm_Mode не ограничивается банальной кражей токенов из окружения. По данным исследователей, червь нацелен на учетные данные npm, GitHub, облачных сервисов, криптокошельков и провайдеров LLM. Данные могут утекать сразу по трём каналам, включая DNS-туннелирование. Для распространения он заражает пакеты и репозитории, а для закрепления использует Git hooks. Отдельно выделяется компрометация AI-помощников вроде Cursor и Claude Code через поддельный MCP-сервер: с помощью prompt injection такой компонент может заставить ассистента тихо прочитать секреты и передать их атакующему. Если перевести это с языка отчётов на язык тимлида, получается неприятный сценарий: ваш «полезный» AI-инструмент начинает делать ровно то, для чего его и включали в процесс, только в интересах постороннего человека.
Почему старые подходы здесь буксуют
У классической защиты есть проблема масштаба и контекста. Если вредонос запускает подозрительный бинарь, лезет в нетипичное место реестра или стучится на известный C2-адрес, срабатывают давно отработанные механики. Но в случае с Sandworm_Mode значительная часть цепочки выглядит буднично: выполнение команд, чтение файлов, правка конфигураций, взаимодействие с репозиториями, вызовы API. Всё это и так делают AI-агенты, GitHub Actions, внутренние скрипты автоматизации и локальные developer tools. В CrowdStrike описывают ситуацию довольно точно: защитнику приходится искать иголку в стопке иголок, потому что телеметрия легитимной автоматизации и телеметрия атаки начинают совпадать.
Есть и ещё одна деталь, которая ломает привычную корреляцию событий. У Sandworm_Mode предусмотрена задержка от 48 до 96 часов между установкой вредоносного пакета и активацией полной полезной нагрузки. Для атакующего это почти подарок: защитные системы, которые пытаются связать установку подозрочной зависимости с дальнейшим вредоносным поведением, могут просто не склеить эти события в один инцидент. В результате команда видит не линейную атаку, а набор разрозненных действий, каждое из которых по отдельности напоминает рутину разработки. На языке бизнеса это означает рост dwell time и более дорогие расследования. На языке инженеров — больше ложного спокойствия в логах, где всё вроде бы «как обычно».
Для русскоязычных команд здесь важен не столько сам бренд Sandworm_Mode, сколько модель атаки. Многие компании уже пустили AI-ассистентов в IDE, пайплайны и внутренние инструменты, но процессы доверия к ним часто остались на уровне «это же наш approved tool». Проблема в том, что доверенным может быть не только бинарь, но и весь сценарий его использования: регистрация MCP-сервера, изменение конфигов ассистента, доступ к токенам LLM-провайдера, вызовы из CI в репозиторий и обратно. Пока у компании нет нормального базового профиля того, что считается обычным поведением для AI-ассистента, MCP-сервера или LLM API key, аномалия просто не из чего вычислять. И это не теоретическая боль SOC, а уже вполне инженерная задача для platform-, security- и DevOps-команд.
Практические выводы здесь довольно жёсткие. Во-первых, AI-разработка больше нельзя считать просто ещё одним удобным слоем над существующим SDLC: это уже отдельная поверхность атаки. Во-вторых, защита цепочки поставки должна охватывать не только зависимости и контейнеры, но и AI-конфигурации, MCP-интеграции, учётные данные разработчиков и сервисные токены, которыми живут CI/CD-процессы. В-третьих, привычная ставка на сигнатуры и разовые IOC в таких кейсах быстро упрётся в потолок. Нужны поведенческий контекст, инвентаризация AI-инструментов в разработке, более жёсткая изоляция рабочих сред и внятный контроль того, какие ассистенты куда имеют доступ. Иначе атаки на AI-инструменты будут проходить не через экзотику, а через самые «удобные» места в пайплайне.
Похоже, рынок входит в фазу, где вопрос уже не в том, будут ли злоумышленники злоупотреблять AI toolchain, а в том, насколько быстро компании научатся отличать полезную автоматизацию от враждебной. Если раньше supply chain-атака ассоциировалась с заражённой библиотекой, то теперь в цепочку доверия добавился ещё один участник — AI-агент, который умеет читать, писать, коммитить и ходить за секретами. Подробности кейса собрал .