Ботнет Glassworm, который с октября 2025 года бил по разработчикам через цепочку поставок ПО, лишился сразу четырёх каналов управления. Для рынка это важнее обычной новости про очередной takedown: ботнет Glassworm держался не на одном сервере, а на смеси Solana, BitTorrent DHT, Google Calendar и классических VPS, то есть был собран с расчётом пережить стандартное отключение инфраструктуры.
О координированной операции сообщили CrowdStrike, Google и The Shadowserver Foundation, пишет BleepingComputer. По данным исследователей, 27 мая они одновременно перекрыли четыре независимых канала command-and-control, через которые операторы Glassworm передавали заражённым машинам команды и новые полезные нагрузки. В этом и была главная сложность: если выбить только один канал, ботнет просто переключился бы на другой.
С технической точки зрения история у Glassworm почти образцово неприятная. Адреса C2-серверов прятались в memo-полях транзакций Solana, то есть в публичном и фактически неубиваемом блокчейн-слое. Конфигурация дополнительно подтягивалась через BitTorrent Distributed Hash Table по жёстко зашитым публичным ключам, без единой точки отказа. Ещё один слой маскировки строился на Google Calendar: в заголовках событий хранились Base64-кодированные пути к C2. А внизу пирамиды уже работали обычные серверы на коммерческих VPS, откуда шла финальная доставка payload. Не самый изящный стек на свете, зато очень живучий.
Это объясняет, почему ботнет Glassworm дожил до конца мая 2026 года, хотя его активность тянется как минимум с октября прошлого года. Изначально группа заражала разработчиков через вредоносные расширения для OpenVSX и Microsoft VS Code. Те воровали криптокошельки и учётные данные разработчиков. Затем операторы расширили набор инструментов: в ход пошли GitHub-репозитории и пакеты npm. Отдельная кампания в марте затронула более 400 программных артефактов. Позже атакующие разместили на OpenVSX десятки «спящих» расширений, которые сами по себе выглядели не слишком шумно, но должны были активировать вредоносный компонент после обновления. Для supply-chain атак это особенно неприятный сценарий: заражение прячется не в одном громком релизе, а в доверенной механике обновлений.
На этом месте новость перестаёт быть историей только для security-команд. Glassworm целился не в абстрактных «пользователей», а в людей и процессы, из которых собирается современная разработка: IDE, маркетплейсы расширений, репозитории, пакетные менеджеры. Иными словами, в ту часть пайплайна, где доверие часто автоматизировано, а проверка артефактов давно делегирована экосистеме. Если у злоумышленников получается закрепиться в этом слое, риск уже не ограничивается кражей кошелька отдельного разработчика. Под угрозой оказываются доступы к репозиториям, секреты сборки, токены публикации пакетов и, в конечном счёте, downstream-зависимости.
Есть и практический вывод из самой операции. CrowdStrike прямо указывает: отключать пришлось все четыре канала одновременно, иначе заражённые хосты сохранили бы управление. Это важное напоминание для тех, кто всё ещё смотрит на C2 как на один домен или один IP. Современная малварь всё чаще использует легитимные сервисы и децентрализованные сети не как запасной выход, а как базовый дизайн. Блокчейн здесь не ради хайпа, а как удобный публичный dead drop, который сложно убрать административно. P2P-сеть нужна не потому, что это красиво, а потому что у неё нет центрального рубильника. А условный календарь годится потому, что корпоративный трафик к нему редко выглядит подозрительно по умолчанию.
После срыва инфраструктуры заражённые машины, по словам исследователей, теперь beacon'ят на IP-адрес 164.92.88.210, который контролирует CrowdStrike. Для защитников это редкий случай, когда после takedown есть конкретный сетевой индикатор для быстрой проверки. Организациям советуют искать такой трафик и сразу запускать remediation. Дополнительно опубликованы YARA-правила для подтверждения заражения на подозрительных хостах. Для DevSecOps и внутренних SOC это, пожалуй, самый прикладной кусок истории: если у вас есть разработчики, которые пользуются VS Code, OpenVSX, npm и GitHub в обычном режиме, считать такую угрозу «чужой проблемой» уже не получится.
Главный вопрос теперь не в том, вернётся ли именно Glassworm в прежнем виде, а в том, сколько ещё групп уже собрали похожую многоуровневую схему управления поверх открытых и легитимных сервисов. У supply-chain атак давно сместился фокус: компрометировать один сервер недостаточно, выгоднее встроиться в привычный контур разработки так, чтобы защита выглядела запоздалой по определению. История с Glassworm показывает неприятную, но полезную вещь: охотиться придётся не только за вредоносным кодом, но и за архитектурой доверия, на которой этот код катается почти бесплатно.