27 мая CrowdStrike вместе с Google и Shadowserver Foundation одновременно отключили четыре канала управления, на которых держался ботнет Glassworm. Для разработчиков и компаний, которые собирают ПО из npm-, Python-пакетов и расширений IDE, это важная новость: атаки на цепочку поставок уже бьют не только по продуктам, но и по тем, кто их пишет.
Операцию провели во вторник в 14:00 UTC, сообщает The Register. По данным CrowdStrike, команда Counter Adversary Operations синхронно ударила по всем четырём командным каналам Glassworm, чтобы отрезать операторов от заражённых машин и лишить их возможности доставлять новый вредоносный код. Глава аналитики Google Threat Intelligence Group Джон Халтквист подтвердил участие Google в срыве инфраструктуры, но дополнительных деталей о роли компании публично не раскрыл.
История здесь интересна не только самим фактом ликвидации. Ботнет Glassworm с начала 2025 года был нацелен именно на разработчиков и распространялся через отравленные программные пакеты. В октябре 2025-го его впервые публично описала компания Koi. Тогда стало понятно, что речь не о банальном стилере в случайном npm-пакете, а о самораспространяющемся черве, который умеет красть учётные данные, заражать новые компоненты и превращать машины разработчиков в прокси-узлы для преступной инфраструктуры. Позже вредонос переключился с расширений VS Code в каталоге OpenVSX на npm- и Python-пакеты, а затем с помощью ранее украденных учётных данных заразил более 300 репозиториев на GitHub.
Glassworm работал сразу на Windows, macOS и Linux, то есть бил почти по всей типовой инженерной среде без любимой индустрией сказки про «мы на Mac, нас это не касается». Помимо кражи чувствительных данных, червь разворачивал собственный инструмент удалённого доступа на Node.js — GlasswormRAT. Отдельная неприятность в том, что заражённая машина разработчика здесь становится не только жертвой, но и новым этапом распространения. Для атакующих это почти идеальная экономика: один компрометированный аккаунт или пакет даёт выход и в исходники, и в CI/CD, и в экосистему зависимостей, которую потом тащит за собой ещё десяток команд.
Почему операцию пришлось проводить настолько точно по времени, тоже понятно. Архитектура управления у Glassworm была собрана с явным расчётом на живучесть после попыток блокировки. Один канал использовал блокчейн Solana: адреса C2-серверов шифровались в memo-полях транзакций, так что снять такую часть инфраструктуры привычным способом было сложно. Второй канал прятал пути к C2 в заголовках событий Google Calendar в виде Base64-строк — аккуратный dead drop на платформе, которую большинство компаний не воспринимает как элемент вредоносной сети. Третий опирался на децентрализованную BitTorrent DHT, где конфигурация GlasswormRAT хранилась по жёстко зашитым публичным ключам. Четвёртый был более приземлённым: обычные C2-серверы на коммерческих VPS, через которые доставлялись финальные полезные нагрузки.
Именно поэтому отключить только один сегмент было бы бессмысленно. CrowdStrike прямо говорит: если бы упал лишь один канал, остальные позволили бы операторам быстро пересобрать управление. После операции все заражённые устройства теперь обращаются к безопасному IP-адресу 164.92.88[.]210, который контролирует CrowdStrike. Компания рекомендует организациям проверить сетевые журналы и телеметрию конечных точек на соединения с этим адресом: такой трафик — индикатор того, что в среде был или остаётся Glassworm.
Контекст у этой истории совсем не утешительный. Рынок уже несколько месяцев живёт в режиме «черви для разработчиков — новый нормальный кошмар». The Register напоминает о Mini Shai-Hulud, который тоже самораспространялся через open source, о сериях отравлений GitHub-репозиториев и npm-пакетов и о волне атак на инструменты разработчиков. Сам Glassworm появился примерно через месяц после того, как другой самораспространяющийся вредонос, Shai Hulud, начал ползти по npm-пакетам, включая пакеты, сопровождаемые CrowdStrike. То есть перед нами уже не экзотика и не редкий proof of concept, а оформляющийся класс атак: злоумышленники идут туда, где код собирается, подписывается и публикуется, а не только туда, где он потом исполняется.
Для бизнеса это неприятно по двум причинам. Первая: ущерб выходит за пределы одной команды или одной машины. Если заражён разработчик, под ударом оказываются репозитории, секреты, токены публикации, внутренние пакеты и доверие к релизному процессу. Вторая: классическая защита периметра здесь помогает слабо, потому что многие сигналы маскируются под легитимные действия в обычных сервисах и open source-инструментах. Когда командный канал живёт в блокчейне, календаре и DHT одновременно, SOC получает не один очевидный IOC, а набор косвенных симптомов, который легко пропустить, если телеметрия по рабочим станциям разработчиков и пакетным реестрам собрана кое-как.
Для самих разработчиков вывод ещё прозаичнее. Проверка зависимостей, изоляция токенов, минимальные права для публикации пакетов, защита аккаунтов GitHub и контроль расширений IDE перестают быть бюрократией из чек-листа комплаенса. Это уже гигиена сборочной линии. На практике атаки вроде Glassworm ломают старую удобную иллюзию, что supply-chain security — забота только платформенной команды или безопасников. Когда червь идёт через OpenVSX, npm, Python-пакеты и украденные креды, граница между «инфраструктурой» и «обычной разработкой» исчезает довольно быстро.
История с Glassworm важна ещё и как сигнал о новой фазе противостояния. Атакующие явно делают ставку на децентрализованные и резервируемые каналы управления, а защитникам приходится отвечать не точечной блокировкой доменов, а координированными операциями сразу между несколькими игроками. Чем глубже разработка завязана на внешние пакеты, маркетплейсы расширений и облачные сервисы, тем чаще именно рабочее место разработчика будет самым коротким маршрутом к цепочке поставок.