Более года хакеры незаметно отравляли инструменты, которыми пользуются миллионы программистов. В результате один заражённый сотрудник открывал преступникам доступ к коду сотен и тысяч других организаций. Только сейчас международной коалиции удалось разрушить инфраструктуру ботнета Glassworm.
Масштабная операция по ликвидации угрозы
Вечером 26 мая 2026 года компания CrowdStrike, специализирующаяся на кибербезопасности, совместно с Google и некоммерческой организацией Shadowserver Foundation объявила о успешном срыве работы ботнета Glassworm. Операция готовилась несколько месяцев и потребовала координации действий по всему миру. Специалисты одновременно нанесли удары по четырём каналам управления, через которые злоумышленники передавали заражённым компьютерам вредоносные инструкции и новые модули.
Glassworm — это не просто очередной вирус. Это сложная, многоуровневая инфраструктура, нацеленная на разработчиков программного обеспечения. По данным CrowdStrike, ботнет функционировал как минимум с начала 2025 года, а возможно и дольше — следы более ранних атак теряются в истории пакетных реестров.
Почему разработчики — идеальная цель
Главная опасность Glassworm заключалась даже не в его технической сложности, а в самом объекте атаки. Разработчики программного обеспечения обладают доступом к наиболее критическим активам любой ИТ-компании: исходному коду продуктов, облачным платформам, CI/CD-конвейерам (системам непрерывной интеграции и доставки), учётным данным для пакетных реестров и токенам доступа к репозиториям.
Один заражённый рабочий компьютер разработчика становился для хакеров «золотым билетом». Через него злоумышленники могли проникнуть в системы, к которым у самого разработчика был легальный доступ. Но на этом цепочка заражения не обрывалась.
Вредоносный код, попадая в инструменты и библиотеки, которые разработчик использовал в своей работе, мог отправиться дальше — в готовые программные продукты. А оттуда — на компьютеры и серверы компаний-клиентов, которые даже не подозревали, что скачали заражённое приложение. Таким образом, проблема одного разработчика превращалась в проблему тысяч организаций по всей цепочке поставки ПО.
Три вектора атаки: как хакеры проникали в системы
Операторы Glassworm действовали методично и использовали три основных канала доставки вредоносного кода. Каждый из них по отдельности был эффективен, но вместе они создавали почти непреодолимую для защиты стену.
Первый вектор: заражённые расширения для редакторов кода
Самым изощрённым способом стала публикация троянизированных расширений для Visual Studio Code (VSCode) — самого популярного редактора кода в мире, которым пользуются десятки миллионов разработчиков. Злоумышленники размещали свои вредоносные расширения в каталоге OpenVSX, который является альтернативой официальному магазину расширений Microsoft. OpenVSX используется многими корпоративными средами, где ограничен доступ к внешним репозиториям, что делало атаку ещё более эффективной.
Расширения маскировались под безобидные и даже полезные инструменты: трекеры рабочего времени, форматтеры кода (программы, автоматически приводящие код к единому стилю), темы оформления и сниппеты — небольшие заготовки кода для ускорения работы. Разработчик, ища удобное расширение для своих задач, скачивал его, даже не подозревая, что вместе с полезным функционалом на его компьютер попадает вредоносный код.
Примечательно, что атака не ограничивалась одним VSCode. Благодаря совместимости экосистемы, заражённые расширения работали и в других редакторах: Cursor, Positron, Windsurf, VSCodium и многих других.
Второй вектор: отравленные пакеты npm и Python
Вторая линия атаки проходила через системы управления пакетами — npm (стандартный менеджер пакетов для языка JavaScript) и PyPI (реестр для Python). Это базовые инструменты любого современного веб-разработчика и специалиста по данным.
Хакеры публиковали в этих реестрах пакеты с полезными на первый взгляд функциями, но внутри каждого из них были спрятаны вредоносные скрипты. Запуск кода происходил в момент обычной установки пакета через специальные «хуки» — postinstall-скрипты, которые выполняются автоматически после завершения установки. Для разработчика процесс выглядел как рядовая работа: он набирал привычную команду npm install или pip install, наблюдал за бегущими строками установки зависимостей и даже не замечал, что на его машине уже выполняется чужой, опасный код.
Третий вектор: подмена кода в репозиториях GitHub
Самым наглым способом стала прямая атака на репозитории GitHub. Согласно отчёту CrowdStrike, операторы Glassworm отравили более трёхсот публичных репозиториев. Для этого они использовали учётные данные разработчиков, украденные во время более ранних заражений.
Заполучив доступ к аккаунту владельца репозитория, хакеры с помощью команды force push перезаписывали основную ветку проекта. Эта команда позволяет полностью заменить историю изменений, уничтожив старые коммиты и внедрив свой код. Другие разработчики, которые пользовались этим репозиторием как библиотекой или примером, скачивали уже заражённую версию, думая, что работают с оригинальным, проверенным кодом.
Кроссплатформенный арсенал: что умел Glassworm
Вредоносная программа работала на всех трёх основных операционных системах: Windows, macOS и Linux. Такой охват делал её универсальным оружием против любой команды разработчиков, независимо от того, какие компьютеры они предпочитают.
Функционал Glassworm включал три основных компонента:
- Информационный вор (Infostealer) — собирал данные с заражённой машины: файлы, скриншоты, историю браузера, установленное программное обеспечение.
- Кража учётных данных (Credential Harvester) — охотился за паролями, токенами доступа, SSH-ключами и файлами конфигурации, где часто в открытом виде хранятся секреты.
- Удалённый доступ (GlasswormRAT) — самый опасный компонент. RAT (Remote Access Tool) давал оператору полный контроль над заражённой системой в реальном времени: запуск любых команд, скачивание и загрузку файлов, наблюдение за экраном и клавиатурой.
Инфраструктура-феникс: почему Glassworm было так трудно уничтожить
Уникальность Glassworm заключалась не только во вредоносном коде, но и в том, как были построены каналы управления заражёнными машинами. Операторы предусмотрели, что их серверы могут быть обнаружены и отключены, поэтому создали целых четыре независимых канала связи, каждый из которых использовал разные технологии.
Канал первый: блокчейн Solana
Самый технологически продвинутый канал. Адреса серверов управления (C2) операторы записывали в служебные поля memo обычных транзакций в блокчейне Solana. Эта схема работала как публичный тайник: данные видны всем участникам сети и, что самое важное, их нельзя удалить. Даже если хостинг-провайдер блокировал найденные C2-серверы, информация о новых адресах уже лежала в блокчейне, и заражённые машины могли получить к ней доступ в любой момент.
Канал второй: BitTorrent DHT
Второй канал использовал распределённую хеш-таблицу (DHT) сети BitTorrent. GlasswormRAT обращался к этой одноранговой сети и искал конфигурационные данные по заранее заданным публичным ключам. У DHT нет единого сервера, нет центра, который можно отключить. Это аналог «теневого интернета» внутри самого BitTorrent, и обезвредить его обычными методами почти невозможно.
Канал третий: Google Calendar
Самый хитрый и неожиданный канал. Операторы использовали заголовки событий в Google Calendar как место для хранения закодированных в Base64 адресов C2. Для защитников такой трафик выглядит как обычное обращение к легальному сервису Google. Блокировать домены Google целиком невозможно — это парализовало бы работу тысяч других сервисов и приложений. Таким образом, вредоносное ПО пряталось внутри разрешённого, доверенного трафика.
Канал четвёртый: классические VPS-серверы
Самый простой канал — прямое подключение к коммерческим VPS-серверам (виртуальным выделенным серверам) у обычных провайдеров. Через них операторы могли доставлять финальные полезные нагрузки, если остальные каналы по каким-то причинам не работали.
Синхронный удар: как разрушили инфраструктуру
Такая многоканальная архитектура давала Glassworm колоссальную живучесть. Если защитники обнаруживали и отключали один канал управления, операторы просто переключали заражённые машины на другой. Для полного уничтожения ботнета нужно было нарушить работу всех четырёх каналов одновременно.
Именно это и сделали CrowdStrike, Google и Shadowserver Foundation в ходе согласованной операции. Синхронно, в один момент, были блокированы публикации новых адресов в блокчейне Solana, нарушена работа DHT-узлов, отключены учётные записи Google Calendar, использовавшиеся для передачи команд, и заблокированы прямые C2-серверы у VPS-провайдеров.
После этого заражённые компьютеры потеряли возможность получать новые инструкции и дополнительные вредоносные модули от операторов. Ботнет был обезглавлен.
Русский след: косвенные улики
CrowdStrike в своём отчёте приводит несколько косвенных признаков, указывающих на возможное происхождение операторов Glassworm из русскоязычного региона. Эти улики не являются прямыми доказательствами, но в совокупности создают последовательную картину на протяжении более чем года наблюдений.
Первый признак: вредоносное ПО при запуске проверяло локаль (региональные настройки), язык операционной системы и часовой пояс компьютера жертвы. Если система оказывалась настроенной на страны СНГ (Россия, Беларусь, Украина, Казахстан и другие), вредоносный код тихо завершал свою работу, не причиняя вреда. Такой приём часто используют киберпреступные группы из постсоветского пространства, чтобы случайно не атаковать компьютеры в «родных» странах и не привлекать внимание местных правоохранителей.
Второй признак: в исходном коде GlasswormRAT исследователи обнаружили комментарии на русском языке. Например, одна из функций содержала фразу «задержка перед отправкой» (написано с небольшой орфографической ошибкой) и «не трогать, работает».
Однако CrowdStrike отдельно подчёркивает, что ни один из этих признаков сам по себе не является доказательством. Проверку локали могут скопировать любые хакеры, желающие подставить другую страну, а русскоязычные комментарии могли появиться из-за того, что операторы использовали генераторы кода на основе больших языковых моделей (ChatGPT и аналоги), которые часто генерируют комментарии на разных языках в зависимости от обучающей выборки.
Что делать сейчас: индикатор заражения
После разрушения инфраструктуры Glassworm компания CrowdStrike опубликовала простой способ проверить, была ли заражена конкретная машина. Все компьютеры, ранее заражённые ботнетом, после потери связи с оригинальными серверами управления теперь обращаются к специально созданному безопасному IP-адресу, который контролирует CrowdStrike: 164.92.88.210
Организациям рекомендуется срочно проверить:
- Сетевые журналы (логи трафика) рабочих станций, особенно тех, которые используются разработчиками.
- Телеметрию конечных устройств (логи антивирусов и систем обнаружения вторжений).
- Любое обращение к указанному IP-адресу изнутри корпоративной сети.
Если в журналах найдены записи о контакте с 164.92.88.210 — это почти стопроцентный признак того, что хост был заражён Glassworm. Такую машину необходимо немедленно изолировать от сети, провести полную проверку и, в идеале, переустановить операционную систему, а также сменить все пароли и токены доступа, которые хранились на этом компьютере.
Для более глубокой диагностики CrowdStrike опубликовала два YARA-правила — специальные сигнатуры для поиска вредоносных файлов по их содержимому. Первое правило ищет характерные строки в скрипте самого GlasswormRAT. Второе правило помогает находить обфусцированный (запутанный, замаскированный) Python-установщик Glassworm, который использовался на ранних этапах заражения.
Уроки Glassworm: как защитить цепочку поставки ПО
История Glassworm обнажила системную проблему современной разработки программного обеспечения. Экосистемы npm, PyPI, OpenVSX и GitHub содержат миллионы проектов, расширений и зависимостей. Встроенные механизмы проверки безопасности в этих реестрах либо отсутствуют, либо крайне ограничены.
Киберпреступник может за считанные минуты опубликовать новый пакет с вредоносным кодом, замаскировать его под полезную библиотеку и получить первых жертв уже в течение часа после публикации. Glassworm использовал эту скорость постоянно, переключаясь между разными площадками каждый раз, когда подозрительная активность начинала привлекать внимание.
Традиционный подход «обнаружить и удалить» работает слишком поздно. Вредоносный пакет устанавливается за секунды, и за это время он уже может украсть токены доступа, отправить их операторам и загрузить дополнительные модули. К моменту, когда срабатывает антивирус или система безопасности сообщает об угрозе, ущерб уже нанесён.
Что нужно делать компаниям:
- Контроль зависимостей — автоматически проверять все пакеты перед установкой, вести список разрешённых библиотек (allowlist), не допускать установки из непроверенных источников.
- Проверка расширений — ограничить, какие расширения для редакторов кода могут устанавливать сотрудники; требовать одобрения безопасности для каждого нового расширения.
- Минимизация прав токенов — использовать принцип наименьших привилегий: токен доступа разработчика не должен иметь прав на запись в критический репозиторий или деплой в production.
- Мониторинг CI/CD — фиксировать каждую сборку, проверять изменения в коде, подписывать коммиты.
- Быстрая реакция — иметь план на случай кражи учётных данных: процедуры отзыва токенов, смены паролей, аудита доступа.
Итог
Glassworm был построен вокруг простой, но пугающей идеи: добраться до разработчика, а через него — до чужого кода и чужих пользователей. Операторы использовали доверие к инструментам разработки, обновлениям, пакетам и репозиториям как главный механизм доставки.
Синхронный срыв четырёх каналов управления не отменяет риск уже заражённых рабочих станций. Однако он даёт компаниям временное окно для проверки своих систем, удаления вредоносных компонентов и смены украденных доступов. Вопрос в том, сколько организаций воспользуется этим шансом до того, как операторы Glassworm восстановят инфраструктуру или создадут новую, ещё более совершенную.
