Source: BleepingComputer — https://www.bleepingcomputer.com/news/security/glassworm-botnet-disrupted-after-resilient-c2-infrastructure-takedown/
Glassworm удалось нарушить, потому что ударили по всем четырем каналам управления#
Исследователи сообщили, что ботнет Glassworm удалось нарушить после скоординированного отключения сразу четырех command-and-control каналов. Это важная деталь: речь не о простом изъятии сервера и не о блокировке домена.
По данным BleepingComputer, операцию против инфраструктуры, через которую операторы Glassworm управляли зараженными системами разработчиков, провели CrowdStrike, Google и The Shadowserver Foundation. Ботнет заранее проектировали так, чтобы он переживал частичные сбои: логика управления была распределена между транзакциями в блокчейне Solana, сетью BitTorrent DHT, публичным календарным сервисом и обычными серверами на VPS.
Оценка CrowdStrike, которую приводит издание, звучит прямо: после скоординированных действий зараженные машины больше не могут получать новые инструкции или payloads. Сейчас скомпрометированные хосты отправляют beaconing на 164.92.88[.]210 — IP-адрес под управлением CrowdStrike. Организациям рекомендуют искать этот сетевой индикатор и устранять последствия заражения.
Но это именно нарушение работы ботнета, а не доказательство, что все прежние компрометации уже очищены. Уже зараженные машины все равно нужно расследовать. Украденные учетные данные, внедренные tokens, вредоносные пакеты и артефакты закрепления не исчезают только потому, что активный C2-канал отключили.
Целью была цепочка поставки разработки#
По данным отчета, кампании Glassworm активны с октября 2025 года. На раннем этапе злоумышленники били по разработчикам через вредоносные расширения OpenVSX и Microsoft Visual Studio Code. Эти расширения использовались для кражи криптокошельков и учетных данных разработчиков.
Позже кампания расширилась на GitHub repositories и npm packages. Одна мартовская кампания, как сообщается, затронула более 400 software artifacts. В более свежей волне участвовали десятки спящих расширений на OpenVSX: вредоносные компоненты должны были активироваться после обновления.
В этом и есть главный практический урок. Glassworm не требовалось сначала пробивать классическую уязвимость на периметре. Он атаковал рабочую среду разработчиков: расширения, repositories, packages и credentials. В современном производстве ПО это доверенные поверхности.
Вредоносное расширение для разработчика находится рядом с secrets, build scripts, исходным кодом, потоками публикации пакетов и локальными кошельками. Скомпрометированный repository или npm package может протащить атаку дальше, в другие проекты. Поэтому malware, нацеленное на разработчиков, имеет иной радиус поражения, чем обычное endpoint-malware. Один зараженный workstation или аккаунт maintainer может превратиться в проблему распространения.
C2 сделали живучим, а не красивым#
Самая заметная часть отчета — архитектура command-and-control. Glassworm использовал четыре канала:
- Транзакции в блокчейне Solana, где адреса C2-серверов кодировались в memo fields.
- Запросы BitTorrent Distributed Hash Table с hardcoded public keys для получения configuration data.
- Заголовки событий Google Calendar как dead-drop locations для Base64-encoded C2 paths.
- Прямые подключения к традиционной C2-инфраструктуре на commercial VPS providers.
Такую смесь специально трудно убрать. Memo fields в блокчейне публичны, и обычными takedown-методами их сложно стереть. У BitTorrent DHT нет центрального провайдера, к которому можно обратиться. Публичный календарный сервис может выглядеть как обычный web traffic, пока защитники не поймут паттерн. VPS-серверы — привычная часть схемы, но сами по себе они не были всей системой.
Такая конструкция давала Glassworm запасные маршруты. Если защитники убирали только VPS-серверы, зараженные хосты все еще могли получать новые инструкции через другие слои. Если один dead drop переставал работать, другой мог поддержать операцию. Публичные сервисы работали как resolution layers перед реальной payload-инфраструктурой.
Поэтому синхронность операции была критична. Частичный takedown предупредил бы операторов и оставил бы достаточно элементов системы, чтобы перестроить маршрутизацию. Нужно было одновременно ударить по blockchain-based path, peer-to-peer path, calendar-based path и прямой инфраструктуре.
Что проверить защитникам сейчас#
Главный сетевой индикатор из отчета — 164.92.88[.]210. CrowdStrike сообщает, что после нарушения работы ботнета скомпрометированные машины отправляют beaconing на этот IP. Командам безопасности стоит искать подключения к нему в логах, особенно с developer workstations, CI hosts, build systems и машин, которые используют для сопровождения пакетов или расширений для браузеров и редакторов.
Такое сетевое событие нужно считать отправной точкой, а не доказательством полного масштаба. Если хост взаимодействовал с инфраструктурой Glassworm, responders должны исходить из того, что developer credentials и локальные secrets могли утечь, пока доказательства не покажут обратное.
Практические проверки:
- Просмотреть outbound connections к 164.92.88[.]210.
- Проверить машины разработчиков на подозрительные расширения VS Code или OpenVSX.
- Проаудировать недавно установленные или обновленные расширения, особенно добавленные с октября 2025 года.
- Проверить активность публикации npm packages у затронутых maintainers.
- Ротировать credentials, tokens и wallet material, присутствовавшие на подозрительных хостах.
- Проверить GitHub repository access logs и недавние commits на неожиданные изменения.
- Использовать YARA rules, опубликованные исследователями, чтобы подтвердить подозреваемые заражения.
Также стоит посмотреть process history и persistence там, где такие данные доступны. Публичная отчетность подтверждает disruption C2 и beaconing indicator. Она не доказывает, что каждый зараженный endpoint стал безопасным.
Чего не стоит утверждать сверх фактов#
Из отчета следует четкий вывод: активную инфраструктуру управления Glassworm нарушили скоординированными действиями по четырем каналам. Но отчет не доказывает, что операторов установили, арестовали или навсегда вывели из игры. Он также не означает, что все вредоносные расширения, скомпрометированные repositories, украденные credentials или downstream package risks уже устранены.
Более сильный вывод касается архитектуры. Glassworm показывает, как supply-chain malware может использовать публичную инфраструктуру как часть control plane. Злоумышленникам не нужен сложный zero-day, чтобы создать проблему, которую трудно снести. Достаточно совместить доверенные поверхности разработки с decentralized или широко используемыми публичными сервисами — и заставить защитников координироваться между providers и protocols.
Это меняет нагрузку на защиту. Заблокировать домен недостаточно. Удалить один package недостаточно. Очистить один repository недостаточно. Для malware, нацеленного на разработчиков, ответ должен покрывать identity, endpoints, package registries, source control, build systems и outbound network behavior.
Нарушение работы Glassworm — хорошая новость. Но полезный урок жестче: malware продержался так долго потому, что его операторы понимали, где сосредоточено доверие в современной разработке ПО — и как трудно отозвать это доверие, когда оно уже разнесено по инструментам, которыми разработчики пользуются каждый день.