WASM-вредонос в VS Code: блокчейн Solana как канал управления
Команда Socket сообщила о новой вредоносной кампании, в которой скомпилированное WebAssembly (WASM) вредоносное ПО встраивалось в троянизированные расширения Visual Studio Code (VS Code). Эти расширения распространялись через маркетплейс Open VSX и маскировались под легитимные инструменты для разработчиков, хотя на деле служили каналом для выполнения вредоносных команд.
По данным исследования, вредоносный компонент, идентифицированный как snqpkebiwrxmoivl.wasm, запускался при активации расширения через загрузчик TinyGo. Для запуска использовался вызов go.run(), после чего модуль получал доступ к дальнейшей цепочке исполнения.
Как работает вредоносный модуль
Отдельного внимания заслуживает схема сокрытия. Модуль WASM шифрует все значимые строки с помощью ChaCha20, что затрудняет обнаружение традиционными сигнатурными средствами. Такой подход повышает устойчивость вредоносного кода к анализу и усложняет его выявление в составе пакетов.
Во время исполнения деобфусцированный модуль взаимодействует с блокчейном Solana, опрашивая JSON-RPC API на предмет транзакций, отправленных на кошелек, контролируемый злоумышленником. Команды извлекаются из поля SPL Memo и затем используются для формирования и выполнения платформозависимых команд через утилиту child_process в Node.
Solana как канал управления
Кампания использует нетипичную инфраструктуру управления и контроля (C2): вместо привычных серверов злоумышленники задействуют блокчейн Solana как своеобразную мёртвую точку. Такой механизм снижает риски изъятия инфраструктуры и позволяет поддерживать работу полезной нагрузки без централизованного C2-сервера.
Каждый полезный груз может быть динамически обновлён за счёт публикации новых транзакций в блокчейне. Использование фиксированного адреса кошелька позволяет вредоносному ПО получать операционные инструкции напрямую из сети, избегая жёстко закодированных серверов управления, которые обычно становятся целью для блокировки.
Имитация легитимных расширений
Распространение строилось на троянизированных расширениях, которые копировали внешний вид и описание легитимных инструментов VS Code. Злоумышленники воспроизводили точные идентификаторы издателей и элементы описания, чтобы эксплуатировать доверие к проверенным сущностям на других реестрах.
Среди упомянутых образцов — ExarGD/vsblack и noellee-doc/flint-debug. Они были повторно опубликованы недавно созданным аккаунтом, что, по оценке исследователей, указывает на заранее спланированную стратегию Impersonation.
Кроссплатформенные команды и загрузка payload
Вредоносное ПО использует преимущественно кроссплатформенные команды. В зависимости от операционной системы оно выполняет HTTP-запросы через cURL или PowerShell, после чего загружает и запускает вторичные payload, размещённые на динамически назначенных доменах.
По сути, это даёт злоумышленникам гибкий механизм для доставки следующих этапов атаки и упрощает адаптацию инфраструктуры под разные среды исполнения.
Связь с GlassWorm
Атрибуция кампании, по данным Socket, вероятно связана с группой разработчиков GlassWorm. Эта группа уже была известна схожими техниками уклонения и использованием Solana в качестве канала C2.
Исследователи отмечают, что данный вариант вредоносного ПО демонстрирует заметный прогресс в тактиках обфускации по сравнению с предыдущими действиями GlassWorm. Ключевыми признаками остаются извлечение метаданных из блокчейна и динамическая генерация команд.
Что рекомендуют организациям
Для снижения рисков специалистами рекомендуется:
- отслеживать характерные шаблоны команд, связанные с данной кампанией;
- усилить обнаружение угроз на основе WASM в программных пакетах;
- особенно внимательно анализировать пакеты, которые объединяют JavaScript и WebAssembly;
- проверять расширения и зависимости, распространяемые через сторонние реестры, включая Open VSX.
История с троянизированными расширениями VS Code показывает, что злоумышленники всё активнее комбинируют обфускацию, блокчейн-инфраструктуру и доверие к developer-экосистемам. В таких условиях особую роль играет анализ не только исполняемого кода, но и скрытых зависимостей, в том числе WebAssembly-компонентов.
Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.
Ознакомиться подробнее с отчетом можно по ссылке.
