Один заражённый разработчик — и хакеры внутри тысяч компаний: ботнет Glassworm год опустошал корпоративный код
NewsMakerКак работала атака и почему целый год никто не замечал угрозы…
CrowdStrike заявила о срыве работы ботнета Glassworm , который атаковал разработчиков через расширения для редакторов кода, пакеты npm и Python, а также заражённые репозитории GitHub. Операция прошла совместно с Google и Shadowserver Foundation: специалисты одновременно ударили по четырём каналам управления, через которые операторы Glassworm передавали заражённым машинам инструкции и новые вредоносные модули.
Главная опасность Glassworm заключалась не только в масштабе ботнета. Кампания показала, насколько удобной целью для атак стали разработчики. Один заражённый рабочий компьютер может открыть преступникам доступ к исходному коду, облачным платформам, CI/CD-конвейерам , учётным данным и пакетным реестрам. После этого проблема перестаёт быть локальной: вредоносный код может уйти дальше по цепочке поставки ПО и затронуть компании, которые даже не знают о первом заражении.
По данным CrowdStrike, операторы Glassworm как минимум с начала 2025 года системно охотились за разработчиками. Злоумышленники публиковали троянизированные расширения для VSCode в каталоге OpenVSX и маскировали их под привычные инструменты вроде трекеров времени и форматтеров кода. Такие расширения били не только по VSCode, но и по Cursor, Positron, Windsurf, VSCodium и другим редакторам, совместимым с этой экосистемой.
Вторая линия атаки шла через пакеты npm и Python. Вредоносный код запускался во время обычной установки зависимостей: через хуки
Третье направление - репозитории GitHub . CrowdStrike пишет, что операторы Glassworm отравили более 300 репозиториев, используя учётные данные разработчиков, украденные при более ранних заражениях. Злоумышленники с помощью
Кампания работала на Windows, macOS и Linux. Набор возможностей включал кражу информации, сбор учётных данных и полноценный инструмент удалённого доступа на Node.js, который CrowdStrike называет GlasswormRAT. RAT в данном контексте означает remote access tool: программа даёт оператору удалённый контроль над заражённой системой.
Инфраструктура Glassworm была рассчитана на живучесть. Операторы не ограничились одним сервером управления, который можно быстро отключить через хостинг-провайдера. Вместо этого ботнет использовал 4 разных канала, каждый из которых помогал находить управляющие серверы или получать конфигурацию.
Первый канал проходил через блокчейн Solana. Адреса C2-серверов, то есть серверов управления, записывались в поля
Второй канал использовал распределённую хеш-таблицу BitTorrent, DHT. GlasswormRAT обращался к одноранговой сети BitTorrent и искал конфигурационные данные по заранее зашитым публичным ключам. У такой сети нет единой точки отказа, поэтому отключить её обычным способом намного сложнее.
Третий канал прятался в легальном веб-сервисе. Glassworm использовал заголовки событий Google Calendar как место для передачи путей к C2, закодированных в Base64. Для защитников такой трафик выглядит неприятно: календарь сам по себе не является вредоносным сервисом, а значит простая блокировка домена может задеть нормальную работу пользователей.
Четвёртый канал был ближе к классической схеме. Вредоносная инфраструктура подключалась к прямым C2-серверам, размещённым у коммерческих VPS-провайдеров. Через них операторы могли доставлять финальные вредоносные нагрузки на заражённые машины.
Сочетание блокчейна, BitTorrent, Google Calendar и обычных серверов давало Glassworm запас прочности. Если бы защитники отключили только один канал, операторы могли бы переключить заражённые системы на другой путь и быстро восстановить управление. Поэтому CrowdStrike, Google и Shadowserver Foundation синхронно нарушили работу всех 4 каналов. После этого заражённые машины потеряли возможность получать новые команды и полезные нагрузки от операторов.
CrowdStrike подчёркивает, что Glassworm развивался больше года. Операторы меняли языки программирования, переходили от JavaScript к Rust и Zig, расширяли атаки на разные экосистемы и строили запасную инфраструктуру на случай отключений. Такая настойчивость особенно опасна при атаках на разработчиков: украденные токены, доступы к репозиториям и рабочие окружения могут привести к компрометации проектов, которыми пользуются тысячи других организаций.
Компания также считает, что преступники, вероятно, связаны с безопасностью цепочки поставки. Основания приводятся косвенные: вредоносное ПО при запуске проверяло локаль, язык и часовой пояс жертвы, а затем тихо завершало работу, если система находилась в стране СНГ. Такой приём часто используют киберпреступные группы из региона, чтобы не атаковать близкие к себе цели. В исходном коде также встречались русскоязычные комментарии. CrowdStrike отдельно оговаривает, что ни один признак сам по себе не доказывает происхождение операторов: проверку локали можно скопировать, а комментарии в коде могли появиться из-за ИИ-инструментов. Но вся картина, по оценке компании, оставалась последовательной на протяжении более года наблюдений.
После срыва инфраструктуры CrowdStrike опубликовала сетевой индикатор для проверки заражений. Все машины, заражённые Glassworm, теперь обращаются к безопасному IP-адресу, которым управляет CrowdStrike:
История Glassworm показывает слабое место нынешней защиты цепочки поставки ПО. Обнаружение после факта работает слишком поздно: вредоносный пакет может установиться за секунды, а срабатывание защиты часто приходит уже после кражи токенов или выполнения вредоносного скрипта.
Проблему усиливает устройство самих экосистем разработки. npm, PyPI, OpenVSX и GitHub содержат миллионы проектов, расширений и зависимостей. Встроенные механизмы проверки ограничены, а атакующий может быстро опубликовать новый пакет, встроить вредоносный код в установочный скрипт и получить первых жертв почти сразу после появления зависимости в реестре. Glassworm использовал именно такую скорость и постоянно переходил между площадками, сохраняя доступ к машинам разработчиков.
Один только поиск вредоносных файлов не закрывает такую угрозу. Защита должна включать контроль зависимостей, проверку расширений для редакторов, ограничение прав токенов, мониторинг CI/CD-среды и быструю реакцию на украденные учётные данные. Но уже закрепившуюся инфраструктуру тоже нужно ломать: если операторы продолжают управлять заражёнными хостами, они могут снова отправить вредоносную нагрузку, сменить инструменты и продолжить атаку через другой канал.
Glassworm был построен вокруг простой идеи: добраться до разработчика, а через него получить путь к чужому коду и чужим пользователям. Операторы использовали доверие к инструментам разработки, обновлениям, пакетам и репозиториям как механизм доставки. Срыв 4 каналов управления не отменяет риск заражённых рабочих станций, но даёт компаниям окно для проверки, удаления вредоносных компонентов и смены украденных доступов.
CrowdStrike заявила о срыве работы ботнета Glassworm , который атаковал разработчиков через расширения для редакторов кода, пакеты npm и Python, а также заражённые репозитории GitHub. Операция прошла совместно с Google и Shadowserver Foundation: специалисты одновременно ударили по четырём каналам управления, через которые операторы Glassworm передавали заражённым машинам инструкции и новые вредоносные модули.
Главная опасность Glassworm заключалась не только в масштабе ботнета. Кампания показала, насколько удобной целью для атак стали разработчики. Один заражённый рабочий компьютер может открыть преступникам доступ к исходному коду, облачным платформам, CI/CD-конвейерам , учётным данным и пакетным реестрам. После этого проблема перестаёт быть локальной: вредоносный код может уйти дальше по цепочке поставки ПО и затронуть компании, которые даже не знают о первом заражении.
По данным CrowdStrike, операторы Glassworm как минимум с начала 2025 года системно охотились за разработчиками. Злоумышленники публиковали троянизированные расширения для VSCode в каталоге OpenVSX и маскировали их под привычные инструменты вроде трекеров времени и форматтеров кода. Такие расширения били не только по VSCode, но и по Cursor, Positron, Windsurf, VSCodium и другим редакторам, совместимым с этой экосистемой.
Вторая линия атаки шла через пакеты npm и Python. Вредоносный код запускался во время обычной установки зависимостей: через хуки
postinstall и установочные скрипты. Для разработчика такой процесс мог выглядеть как рядовое обновление библиотеки, хотя на машине уже выполнялся чужой код. Третье направление - репозитории GitHub . CrowdStrike пишет, что операторы Glassworm отравили более 300 репозиториев, используя учётные данные разработчиков, украденные при более ранних заражениях. Злоумышленники с помощью
force push перезаписывали ветки по умолчанию и добавляли вредоносный код туда, где другие пользователи ожидали увидеть обычный проект. Кампания работала на Windows, macOS и Linux. Набор возможностей включал кражу информации, сбор учётных данных и полноценный инструмент удалённого доступа на Node.js, который CrowdStrike называет GlasswormRAT. RAT в данном контексте означает remote access tool: программа даёт оператору удалённый контроль над заражённой системой.
Инфраструктура Glassworm была рассчитана на живучесть. Операторы не ограничились одним сервером управления, который можно быстро отключить через хостинг-провайдера. Вместо этого ботнет использовал 4 разных канала, каждый из которых помогал находить управляющие серверы или получать конфигурацию.
Первый канал проходил через блокчейн Solana. Адреса C2-серверов, то есть серверов управления, записывались в поля
memo блокчейн-транзакций. Такая схема работает как публичный тайник: данные видны в сети и не исчезают после жалобы хостеру, потому что уже записаны в блокчейн. Второй канал использовал распределённую хеш-таблицу BitTorrent, DHT. GlasswormRAT обращался к одноранговой сети BitTorrent и искал конфигурационные данные по заранее зашитым публичным ключам. У такой сети нет единой точки отказа, поэтому отключить её обычным способом намного сложнее.
Третий канал прятался в легальном веб-сервисе. Glassworm использовал заголовки событий Google Calendar как место для передачи путей к C2, закодированных в Base64. Для защитников такой трафик выглядит неприятно: календарь сам по себе не является вредоносным сервисом, а значит простая блокировка домена может задеть нормальную работу пользователей.
Четвёртый канал был ближе к классической схеме. Вредоносная инфраструктура подключалась к прямым C2-серверам, размещённым у коммерческих VPS-провайдеров. Через них операторы могли доставлять финальные вредоносные нагрузки на заражённые машины.
Сочетание блокчейна, BitTorrent, Google Calendar и обычных серверов давало Glassworm запас прочности. Если бы защитники отключили только один канал, операторы могли бы переключить заражённые системы на другой путь и быстро восстановить управление. Поэтому CrowdStrike, Google и Shadowserver Foundation синхронно нарушили работу всех 4 каналов. После этого заражённые машины потеряли возможность получать новые команды и полезные нагрузки от операторов.
CrowdStrike подчёркивает, что Glassworm развивался больше года. Операторы меняли языки программирования, переходили от JavaScript к Rust и Zig, расширяли атаки на разные экосистемы и строили запасную инфраструктуру на случай отключений. Такая настойчивость особенно опасна при атаках на разработчиков: украденные токены, доступы к репозиториям и рабочие окружения могут привести к компрометации проектов, которыми пользуются тысячи других организаций.
Компания также считает, что преступники, вероятно, связаны с безопасностью цепочки поставки. Основания приводятся косвенные: вредоносное ПО при запуске проверяло локаль, язык и часовой пояс жертвы, а затем тихо завершало работу, если система находилась в стране СНГ. Такой приём часто используют киберпреступные группы из региона, чтобы не атаковать близкие к себе цели. В исходном коде также встречались русскоязычные комментарии. CrowdStrike отдельно оговаривает, что ни один признак сам по себе не доказывает происхождение операторов: проверку локали можно скопировать, а комментарии в коде могли появиться из-за ИИ-инструментов. Но вся картина, по оценке компании, оставалась последовательной на протяжении более года наблюдений.
После срыва инфраструктуры CrowdStrike опубликовала сетевой индикатор для проверки заражений. Все машины, заражённые Glassworm, теперь обращаются к безопасному IP-адресу, которым управляет CrowdStrike:
164.92.88[.]210. Компания советует организациям проверить сетевые журналы и телеметрию рабочих станций. Любое совпадение с этим адресом означает, что хост требует немедленной проверки и очистки. Индикатор Glassworm: 164.92.88[.]210 Что проверить: - сетевые журналы; - телеметрию конечных устройств; - обращения рабочих станций разработчиков к указанному адресу; - машины, где недавно устанавливали расширения OpenVSX, npm-пакеты или Python-пакеты из непроверенных источников.История Glassworm показывает слабое место нынешней защиты цепочки поставки ПО. Обнаружение после факта работает слишком поздно: вредоносный пакет может установиться за секунды, а срабатывание защиты часто приходит уже после кражи токенов или выполнения вредоносного скрипта.
Проблему усиливает устройство самих экосистем разработки. npm, PyPI, OpenVSX и GitHub содержат миллионы проектов, расширений и зависимостей. Встроенные механизмы проверки ограничены, а атакующий может быстро опубликовать новый пакет, встроить вредоносный код в установочный скрипт и получить первых жертв почти сразу после появления зависимости в реестре. Glassworm использовал именно такую скорость и постоянно переходил между площадками, сохраняя доступ к машинам разработчиков.
Один только поиск вредоносных файлов не закрывает такую угрозу. Защита должна включать контроль зависимостей, проверку расширений для редакторов, ограничение прав токенов, мониторинг CI/CD-среды и быструю реакцию на украденные учётные данные. Но уже закрепившуюся инфраструктуру тоже нужно ломать: если операторы продолжают управлять заражёнными хостами, они могут снова отправить вредоносную нагрузку, сменить инструменты и продолжить атаку через другой канал.
Glassworm был построен вокруг простой идеи: добраться до разработчика, а через него получить путь к чужому коду и чужим пользователям. Операторы использовали доверие к инструментам разработки, обновлениям, пакетам и репозиториям как механизм доставки. Срыв 4 каналов управления не отменяет риск заражённых рабочих станций, но даёт компаниям окно для проверки, удаления вредоносных компонентов и смены украденных доступов.