В апреле 2026 года специалисты по информационной безопасности зафиксировали новую волну атак на цепочки поставок программного обеспечения, нацеленную на разработчиков. Речь идёт о кластере из 73 вредоносных расширений для магазина Open VSX, связанных с операцией GlassWorm. Это событие - не просто очередной инцидент, а качественный сдвиг в тактике злоумышленников, которые всё активнее охотятся на среду разработки.
Описание
Почему это важно? Разработчики - привлекательная цель для атакующих. Компрометация инструментов, которыми пользуются программисты, позволяет внедрять вредоносный код в тысячи проектов одновременно. Магазин Open VSX - открытая альтернатива официальному магазине для Visual Studio Code, и его популярность среди разработчиков, ценящих открытый исходный код, делает его удобной площадкой для распространения заражённых расширений.
Первая крупная волна атак GlassWorm была обнаружена ещё в марте 2026 года. Тогда исследователи описали 72 подозрительных расширения, которые использовали механизм зависимостей для скрытой установки вредоносных загрузчиков. Однако апрельский кластер демонстрирует, что злоумышленники учатся на своих ошибках и совершенствуют методы обхода защиты.
Ключевое новшество - стратегия "спящих" расширений. Так называют поддельные пакеты, которые публикуются в магазине задолго до того, как начнут выполнять вредоносные действия. Изначально такие расширения выглядят совершенно безобидно: они копируют функциональность популярных инструментов, используют те же иконки и описания, меняя только имя издателя. Это позволяет набрать доверие и накопить установки. Атакующие терпеливо ждут - иногда неделями или месяцами, - а затем через обновление внедряют полезную нагрузку.
Один из характерных примеров - поддельный пакет турецкого языка для Visual Studio Code. Он почти не отличался от оригинала: те же иконка земного шара и описание, смена лишь имени разработчика. Разработчик, ищущий локализацию, легко мог установить такую копию, не заподозрив подвоха. Из 73 новых расширений как минимум шесть уже активированы и начали распространять вредоносное программное обеспечение.
Эволюция механизмов доставки заслуживает отдельного внимания. В предыдущей волне атак расширения сразу содержали видимый вредоносный код. Теперь же злоумышленники перешли к схеме с тонким загрузчиком: само расширение выполняет лишь минимальные действия по загрузке внешней полезной нагрузки. Малициозный код больше не хранится непосредственно в файлах расширения, что значительно снижает вероятность обнаружения антивирусами и системами анализа.
Исследователи обнаружили два основных метода выполнения атак. Первый - использование нативных бинарных файлов: внутрь расширения прячут файлы с расширением .node. Простой скрипт на JavaScript запускает этот бинарник, который содержит встроенные URL-адреса для скачивания вредоносных пакетов .vsix. Эти пакеты устанавливаются не только в Visual Studio Code, но и в альтернативные среды разработки, такие как Cursor. Второй метод - обфускация JavaScript: весь вредоносный код сильно запутан и не опирается на бинарные файлы. Расшифровка происходит только во время выполнения, после чего скрипт получает полезную нагрузку из релиза на GitHub и устанавливает её через командную строку.
Такая тактика позволяет атакующим обходить стандартные проверки безопасности, которые сканируют исходный код расширений при загрузке. Если вредоносная логика проявляется только после установки и запуска, автоматические сканеры её попросту не видят.
Каковы последствия для разработчиков и компаний? Компрометация среды разработки - это классическая атака на цепочку поставок. Установив заражённое расширение, программист может невольно внедрить бэкдор в свои проекты, что приведёт к утечке кода, учётных данных или даже к получению доступа к внутренним системам работодателя. Особенно опасна ситуация, если вредоносное расширение используют в крупной команде: заражение может распространиться на множество репозиториев и конвейеров непрерывной интеграции.
Рекомендации для специалистов по информационной безопасности сводятся к нескольким пунктам. Во-первых, стоит ограничить использование сторонних расширений в корпоративной среде, разрешив только проверенные из внутреннего каталога. Во-вторых, необходимо внедрить мониторинг поведения расширений в runtime, чтобы выявлять подозрительные сетевые соединения или запуск бинарных файлов. В-третьих, разработчикам следует проверять издателя расширения и обращать внимание на любые расхождения в имени автора или дате публикации.
Операция GlassWorm - яркий пример того, как атаки на цепочки поставок становятся всё изощрённее. Использование "спящих" расширений говорит о долгосрочном планировании и высокой мотивации злоумышленников. Разработчикам и администраторам магазинов расширений придётся адаптировать свои методы защиты: одной лишь статической проверки кода больше недостаточно. Нужны динамический анализ, поведенческие детекторы и постоянное отслеживание аномалий в обновлениях популярных пакетов.
В конечном счёте эта история напоминает: безопасность начинается с каждого отдельного разработчика. Внимательность при установке любого инструмента, пусть и из доверенного источника, может предотвратить серьёзные последствия для всей организации. Атаки на цепочки поставок - не абстрактная угроза, а реальность, с которой приходится сталкиваться всё чаще. И чтобы ей противостоять, нужно понимать тактику противника, которая, как показывает случай с GlassWorm, меняется быстрее, чем многие думают.
Индикаторы компрометации
URLs
- github.com/SquadMagistrate10/wnxtgkih
SHA256
- 1b62b7c2ed7cc296ce821f977ef7b22bae59ef1dcdb9a34ae19467ee39bcf168
- 97c275e3406ad6576529f41604ad138c5bdc4297d195bf61b049e14f6b30adfd
