CrowdStrike и Google ликвидировали Glassworm. Что теперь проверить разработчикам?

26 мая 2026 года в 14:00 UTC команда Counter Adversary Operations компании CrowdStrike совместно с Google и Shadowserver Foundation провела скоординированную ликвидацию ботнета Glassworm — одновременно нейтрализовав все четыре его канала управления и контроля. Glassworm действовал как минимум с начала 2025 года, целенаправленно атакуя разработчиков программного обеспечения через цепочку поставок открытого исходного кода. Ликвидация — это нарушение работы, а не полное уничтожение. Вот что стоит понять и проверить разработчикам и небольшим командам с разработчиками.

Что делал Glassworm

Glassworm целенаправленно атаковал разработчиков программного обеспечения, поскольку они являются высокоценными целями. Скомпрометированная рабочая станция разработчика может открыть доступ к репозиториям исходного кода, облачным платформам, CI/CD-пайплайнам, реестрам пакетов и сборочной инфраструктуре. Компрометация одного разработчика способна вызвать цепную реакцию в виде инцидента в цепочке поставок, затрагивающего тысячи конечных пользователей.

Кампания использовала несколько векторов атаки. По данным CrowdStrike, более 300 репозиториев GitHub были заражены с использованием украденных учётных данных разработчиков, полученных в ходе более ранних заражений Glassworm — вредоносный код принудительно вносился в основные ветки. Операция затронула системы Windows, macOS и Linux; был развёрнут полнофункциональный инструмент удалённого доступа на Node.js под названием GlasswormRAT, а также модули кражи информации и перехвата учётных данных.

C2-инфраструктура Glassworm была спроектирована с расчётом на устойчивость: четыре отдельных канала, включая систему конфигурирования на основе BitTorrent DHT (без единой точки отказа) и заголовки событий Google Calendar, используемые как «мёртвый ящик» для закодированных путей C2. Одновременный удар по всем четырём каналам и сделал ликвидацию эффективной.

Что означает «ликвидация» на практике

CrowdStrike описывает это как отключение операторов от заражённых машин и лишение их возможности доставлять новые вредоносные нагрузки. Это не означает, что каждая заражённая машина была очищена. Это не означает, что угрозы окончательно остановлены. Это означает, что операционная инфраструктура, координировавшая ботнет, была нейтрализована по состоянию на 26 мая 2026 года.

Машины, заражённые до ликвидации, могут по-прежнему быть скомпрометированы. Учётные данные, токены и ключи, перехваченные RAT до нейтрализации, потенциально всё ещё скомпрометированы. Стоящие за Glassworm злоумышленники со временем могут восстановить инфраструктуру.

Что проверить сейчас

Практическая реакция для разработчиков и небольших команд с доступом к разработке — не паника, а использование этого события как повода для проверки гигиены, которая в любом случае должна быть в порядке:

Доступ к аккаунтам:

• Проверьте, у кого есть права администратора в GitHub, GitLab, Bitbucket или других системах хостинга кода
• Включите MFA или passkey на всех аккаунтах хостинга кода, облачных консолях, реестрах пакетов и CI-инструментах — если это ещё не сделано, нужно сделать
• Удалите доступ для бывших сотрудников, неактивных подрядчиков или аккаунтов, которые больше не используются

Учётные данные и токены:

• Ротируйте API-токены, deploy-ключи и учётные данные сервисных аккаунтов, которые устарели, имеют избыточные права или используются совместно
• Проверьте секреты CI/CD — убедитесь, что они хранятся в менеджере секретов, а не захардкожены в конфигурационных файлах или видны в логах сборки
• Проведите аудит расширений браузера и локальных инструментов разработки на предмет всего, что вы не узнаёте или давно не обновляли

Гигиена пакетов и репозиториев:

• Если вы поддерживаете публичные пакеты или репозитории с открытым исходным кодом, просмотрите последние коммиты на предмет неожиданных изменений — особенно в основных ветках
• Проверьте права на публикацию пакетов: кто может опубликовать новую версию в npm, PyPI или других реестрах, которые вы используете?
• Проверьте GitHub Actions или права CI на предмет рабочих процессов с правом записи в репозитории или реестры

Защита конечных точек и устройств:

• Убедитесь, что на рабочих машинах разработчиков запущена защита конечных точек — в том числе на macOS и Linux, а не только на Windows
• Если ваша команда использует управление устройствами (MDM или аналогичное), проверьте актуальность покрытия

Кому это важнее всего

Наивысший приоритет: разработчики с правом коммита в публичные или широко используемые пакеты или библиотеки; инженеры с правами администратора на облачную инфраструктуру, реестры пакетов или CI-системы; основатели или подрядчики, владеющие учётными данными администратора в репозиториях клиентов; DevOps-команды, управляющие общими пайплайнами деплоя.

Более низкий приоритет: нетехнические члены команды без доступа к коду, облаку или административным системам. Вектор атаки на цепочку поставок, использованный Glassworm, не актуален для людей, не работающих с инструментами разработчика.

Чего это не требует

Вам не нужно сканировать на предмет специфических индикаторов Glassworm, если у вас нет инструментов безопасности, способных сделать это корректно. CrowdStrike опубликовал подробную техническую информацию в блоге Counter Adversary Operations, если у вас есть команда безопасности, анализирующая степень воздействия. Для большинства небольших команд без выделенного персонала по безопасности приведённый выше чеклист охватывает практическую реакцию.

Этот инцидент напоминает, что гигиена цепочки поставок открытого исходного кода — тщательное управление доступом, ротация учётных данных и мониторинг изменений в репозиториях — это постоянная работа, а не разовая настройка.