Расширение Solidity Pro для VS Code скрывало кражу криптокошельков и после блокировки "отмылось" в новой версии

Вредоносная логика была устроена по-разному в зависимости от версии. Расширение 2.4.1, опубликованное под идентичностью helper-beeps, после активации не атаковало сразу, а выжидало от суток до двух суток. Затем код проверял, не запущена ли среда автоматизированной сборки, например, облачные сервисы CI/CD, и если она не обнаруживалась, обращался к двум зашифрованным адресам в интернете, запрашивал у них некий файл, расшифровывал его и запускал на исполнение в виде Python-скрипта. Спустя примерно минуту временный файл удалялся. Что именно выполнял скачанный код, установить не удалось, поскольку на момент анализа серверы не отвечали на запросы.

Версия 3.4.0, вышедшая уже под новой идентичностью web3devtoolsx, работала иначе. Расширение активировалось автоматически после запуска VS Code, без каких-либо действий пользователя, и сразу приступало к сбору данных. Как показал разбор, вредоносный модуль искал на диске криптовалютные ключи и фразы восстановления доступа, включая материалы кошельков EVM, данные Solana, файлы MetaMask, Phantom, Coinbase Wallet и Rabby. Помимо этого, он собирал учётные данные из систем контроля версий: токены GitHub, GitLab, npm, PyPI, а также параметры доступа к облакам AWS, Azure, Google Cloud и конфигурации Kubernetes. В зону сбора попадали и .env-файлы, ключи API и секреты сервисов искусственного интеллекта, история команд и данные хоста. Собранное отправлялось на управляющие серверы двумя способами, при этом ни о каком "только анонимном сборе статистики", как заявляло описание расширения, речи не шло.

Параллельно версия 3.4.0 запускала механизм удалённого обновления. Каждые 30 минут расширение обращалось к двум зашифрованным серверам, запрашивало актуальную версию, и если сервер отвечал - скачивало новую версию расширения и устанавливало её. Проверка подлинности при этом отсутствовала: ни подписи, ни сверки хэша, ни привязки к издателю. Управляющий сервер в любой момент мог заменить полезную нагрузку на произвольную. По данным анализа MistEye - платформы киберразведки компании SlowMist, единственное предупреждение перед установкой представляло собой уведомление с кнопкой "OK", причём клик пользователя никак не влиял на дальнейшие действия: установка продолжалась в любом случае.

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

Хронология событий усиливает подозрения. Идентичность helper-beeps.solidity-pro была добавлена в официальный список вредоносных расширений 6 августа 2026 года. Через 8,5 часов на GitHub была создана учётная запись web3devtoolsx, а уже через 16 минут в ней появились корпоративный профиль, форки шести известных блокчейн-проектов, репозиторий продукта и сразу несколько версионных меток. Уже на следующий день новая идентичность также была внесена в список вредоносных. То есть смена издателя происходила стремительно и явно под давлением блокировок.

При этом новая версия 4.0.0, которую автору удалось собрать из публичных материалов, не содержала ни модуля сбора ключей, ни механизма удалённого обновления, ни других вредоносных функций. Объяснение обнаруживается в GitHub-коммите с показательным названием "Clean release", сделанном через 13 минут после публикации вредоносной версии. В этом коммите код, запускающий вредоносные модули, был исключён из процесса сборки, а сами исходники вредоносных модулей остались в репозитории. Финальный пакет расширения собирался только из "чистых" файлов, причём специальный файл-список исключений не позволял упаковщику включить в VSIX исходный код, где вредоносная логика всё ещё хранилась.

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

Разработчикам, у которых установлено расширение helper-beeps.solidity-pro или web3devtoolsx.solidity-pro, рекомендуется рассматривать обе версии как потенциально опасные. Особенно это касается версии 3.4.0: если она хотя бы раз запускалась, есть основания полагать, что были скомпрометированы приватные ключи и пароли. В таком случае нужно отозвать или сменить все учётные данные, касающиеся криптокошельков, систем контроля версий, облаков и CI/CD, и сделать это с чистого устройства. Простая смена пароля от кошелька не поможет - требуется перенос средств на адреса, созданные заново. Для версии 2.4.1, если машина оставалась включённой дольше 24-48 часов, инцидент стоит расследовать как возможное выполнение произвольного кода.

Для корпоративных команд важны не только поиск вредоносного расширения на компьютерах сотрудников, но и анализ истории версий, смена издателей и следы удалённого управления. Расширение, которое раньше значилось в чёрном списке, а ныне выглядит чистым, не должно автоматически получать статус безопасного: при сравнении нового и старого пакетов важно обращать внимание на то, какие опасные модули исчезли и куда они делись. Цифры загрузок, звёзды и корпоративные профили издателей при такой оценке стоит рассматривать лишь как контекст, который может быть искусственно создан, а не как гарантию легитимности.

SHA256

• 7b53b1d93f46babc7415d898e17e71ffb6f3a3af3adb222f21c03adea8b30d50
• bcbaf774f9cea0b0131859b96ba0eeadfd5a49bba59302de1bcf3d884300d508