Фон

Solidity Pro — это расширение для VS Code, ориентированное на разработчиков Solidity/Web3. Позиционируется как инструмент для вспомогательной разработки и предоставляет такие функции, как запрос газа (Gas), цены на токены, фрагменты кода и подсказки при компиляции. Его репозиторий на GitHub также ранее рекламировал возможности безопасности, такие как AI Audit и Security Scanner.

На публичных мероприятиях Solidity Pro последовательно использовал двух publisher (посредников по публикации/издателей): helper-beeps и web3devtoolsx. Соответствующие Extension ID (уникальные идентификаторы расширения) — helper-beeps.solidity-pro и web3devtoolsx.solidity-pro. Хотя издательская идентичность со временем менялась, в последующих сборках по-прежнему сохранялись прежний publisher, адрес репозитория и информация об авторских правах, что указывает на наличие прямой инженерной преемственности между ними.

С 6 по 7 августа 2026 года эти два Extension ID последовательно были добавлены в контрольный список зловредных расширений, который используется Open VSX. По идее, при продолжении проверки в прошлое по версиям всё ещё должны были быть видны соответствующие зловредные возможности, но полученная нами Solidity Pro 4.0.0 (publisher: web3devtoolsx) показывает совершенно иной результат: в финальном bundle (упакованном исполняемом коде) остались только обычные функции вроде Gas, цены токенов и логов. Модули, которые появлялись в исторических зловредных версиях — сбор учётных данных, удалённая загрузка полезной нагрузки, выполнение дочернего процесса и удалённое обновление VSIX — исчезли.

Тогда проблема превращается в вопрос: если это плагин с уже явно подтверждённой зловредной историей, почему в последующих версиях он вдруг стал «чистым»?

В этой статье мы от 4.0.0 идём назад к предыдущим версиям Solidity Pro и изменениям publisher, анализируем два исторических зловредных образца, GitHub Clean commit, миграцию publisher и публичную временную шкалу активности, а также обсуждаем слепые зоны детектирования, которые могут возникать, если оценивать риск только по текущей версии IDE-расширения.

Этот анализ основан на статических доказательствах; образцы не запускались и не подключались к удалённой инфраструктуре.

Ответ MistEye

MistEye — платформа Web3-угроз и динамического мониторинга безопасности, разработанная SlowMist самостоятельно; она интегрирует функции безопасностного мониторинга и агрегации аналитики, предоставляя пользователям быстрые предупреждения о рисках и защиту активов в реальном времени.

MistEye выполнил связывание и сопоставление между двумя publisher-идентичностями helper-beeps.solidity-pro и web3devtoolsx.solidity-pro и соответствующими образцами. В сочетании с результатами статической деобфускации, взаимной проверкой перекрывающихся зловредных возможностей и таймлайном на публичных платформах извлечены хэши образцов, Extension ID, опасные пути запросов и поведение удалённых обновлений для предупреждения о рисках поставочной цепочки в расширениях IDE.

Первая. Текущая версия

Чтобы понять, почему 4.0.0 не срабатывает на зловредный код, нужно проверить два объекта одновременно: сам образец 4.0.0, полученный в этой статье, и состояние GitHub-репозитория, совпадающее с его bundle.

Что внутри VSIX. Финальный bundle локально восстановленного пакета 4.0.0 в основном включает ApiClient, GasTracker, PriceMonitor и Logger; сетевые обращения сосредоточены на Etherscan и CoinGecko. После активации расширения по событию onStartupFinished или в рабочем пространстве, содержащем Solidity-файлы, запускаются только Gas tracker, Price monitor и logger, и регистрируются три публичные команды; команда compile показывает только одну подсказку Hardhat/Foundry и не вызывает компилятор на самом деле. В проверенных файлах и статически достижимых путях не обнаружены четыре типа зловредных возможностей из исторических версий: сбор учётных данных, удалённая загрузка полезной нагрузки, выполнение дочернего процесса и удалённое обновление VSIX.

Что ещё есть в GitHub-репозитории. Пакет 4.0.0 сам по себе не содержит исходного кода, поэтому мы дополнительно откатились по GitHub к его публичному репозиторию. В репозитории есть коммит, где version package.json откатили до v1.0.0, commit 95dce4f, сообщение коммита — "Clean release"; при этом out/extension.js и bundle 4.0.0 имеют одинаковый размер 10 633 байта и совпадающий SHA-256.

out/extension.js этого коммита также включает только ApiClient, GasTracker, PriceMonitor и Logger; функции активации и деактивации делают лишь инициализацию и очистку. Но src/ этого же коммита выглядит иначе: src/telemetry/Web3Analytics.ts остаётся на месте; в заголовке файла написано "Sends install ping immediately, then scans for secrets"; внутри содержатся BIP39-словарь, распознавание учётных данных кошельков, конфигурация для эксфильтрации через WORKERS и лимит на масштабный сбор файлов. Также сохраняется src/services/AutoUpdater.ts: он содержит логику проверки версии по 30-минутному циклу и удалённую установку VSIX.

GitHub-репозиторий (Clean commit 95dce4f)
├── src/telemetry/Web3Analytics.ts # зловредный исходный код сборочного проекта сбора остаётся
├── src/services/AutoUpdater.ts # исходный код удалённого обновления VSIX всё ещё на месте
├── .vscodeignore # исключить src/**, scripts/**, *.ts
└── out/extension.js # чистый bundle, видимый при сборке

Почему зловредный исходный код не попал в VSIX-пакет? Здесь есть две границы.

Первый слой — точка входа выполнения: в Clean commit src/extension.ts удаляет import и стартовую логику для Web3Analytics и AutoUpdater; при сборке dependency-graph с помощью esbuild из этого входа эти два модуля больше не включаются в out/extension.js.

Второй слой — видимость внутри пакета: .vscodeignore исключает src/**, scripts/** и *.ts, но сохраняет out/**, поэтому оставшиеся исходники TypeScript тоже не попадут в VSIX, собранный по этой конфигурации в виде оригинального исходного кода. Сообщение коммита v1.0.0 записано как "Clean release", но файлы исходного зловредного модуля не удалены и не изменены в этом коммите — в итоге финальный артефакт выглядит чистым, однако зловредный модуль внутри проекта может быть повторно включён в последующих изменениях исходников или конфигурации сборки.

Второе. Исторические зловредные версии

Раз в текущей версии и в bundle Clean commit не обнаружены исходные зловредные модули, расследование нужно продолжить и отследить исторические версии Solidity Pro, появлявшиеся в двух publisher-идентичностях.

Solidity Pro не всегда использует одну и ту же зловредную реализацию. В случае publisher helper-beeps версия 2.4.1 и в случае publisher web3devtoolsx версия 3.4.0 демонстрируют две заметно разные модели исполнения: первая делает упор на задержанную загрузку и удалённое выполнение кода, вторая — на встроенный сбор учётных данных и удалённый канал обновления.

2.4.1: задержанная доставка

В образцах Solidity Pro 2.4.1, полученных в рамках этой статьи (publisher: helper-beeps), расширение активирует код в Solidity-файлах или в рабочем пространстве Hardhat/Foundry, при этом telemetry по умолчанию включён. После активации код не переходит сразу к стадии загрузки, а устанавливает случайное окно ожидания на 24–48 часов:

MIN_DELAY_MS: 86400000,
MAX_DELAY_MS: 172800000

После завершения ожидания код проверяет наличие переменных окружения, таких как CI, GITHUB_ACTIONS, JENKINS_HOME, GITPOD_WORKSPACE_ID; при совпадении он сразу выходит. Затем последовательно для шести кодированных относительных путей в домашнем каталоге выполняется фильтрация через fs.existsSync; на этой стадии эти пути используются только для проверки существования.

После фильтрации код последовательно пытается два закодированных endpoint-а и запрашивает для каждого фиксированный путь /firmware. После получения ответа проверяется длина; затем с помощью crypto.createDecipheriv (AES-GCM) выполняется расшифровка, а расшифрованный текст с ограниченными правами записывается в файл .py во временном каталоге и затем запускается через child_process.spawn в detached-режиме. Примерно через 60 секунд unlinkSync очищает временные файлы. Если /firmware фактического ответа не получено, то подробная функциональность на втором этапе неизвестна.

3.4.0: сбор учётных данных

Solidity Pro 3.4.0 (publisher: web3devtoolsx). В package.json активационные события activationEvents одновременно объявляют workspaceContains:*.sol и onStartupFinished. Расширение может автоматически перейти к activate() после завершения запуска VS Code и не требует, чтобы пользователь выполнял его публичные команды.

По умолчанию конфигурация solidity-pro.telemetry.enabled=true создаёт и запускает Web3Analytics. README заявляет, что модуль собирает только анонимизированные данные использования и не хранит private keys или исходный код, но фактические объекты сканирования, выполняемые этим модулем, покрывают ключевые активы доверенной зоны разработчика:

• Кошельки и материалы для подписей: EVM приватные ключи, BIP39 seed-фразы, keystore, Solana id.json, данные расширений браузерных кошельков (MetaMask, Phantom, Coinbase Wallet, Rabby).

• Исходный код и материалы публикации: токены GitHub ghp_/gho_/github_pat_, токены GitLab glpat-, .npmrc, токены PyPI, .netrc, Git-учётные данные.

• Облако и инфраструктура: AWS access/secret/session key, Kubernetes config, Docker-аутентификация, Azure, GCP-настройки.

• Проекты и следы взаимодействия: .env и вариации, API key, токены AI-сервисов (sk-, sk-proj-, sk-ant-), история Shell и информация о хосте.

Регулярное выражение для EVM-приватного ключа покрывает распространённые имена переменных, такие как privateKey, PRIVATE_KEY, WALLET_KEY, DEPLOYER_KEY, а также 64-битные шестнадцатеричные значения:

var _0x4e0bcc = [
  /["']privateKey["']\s*:\s*["'](?:0x)?([0-9a-fA-F]{64})["']/g,
  /(?:PRIVATE_KEY|PRIVATEKEY|ETH_KEY|ETHKEY|WALLET_KEY|WALLETKEY|DEPLOYER_KEY|OWNER_KEY)\s*=\s*["']?(?:0x)?([0-9a-fA-F]{64})["']?/gi,
  /(?:privateKey|private_key|ethKey|eth_key|walletKey|wallet_key)\s*[:=]\s*["'](?:0x)?([0-9a-fA-F]{64})["']/gi,
  /(?:priv(?:ate)?[ _-]?key|secret)[:=]\s*["']?(0x[0-9a-fA-F]{64})["']?/gi
];

Логика сбора SSH-директории перечисляет кандидатные файлы приватных ключей в ~/.ssh/, читает их содержимое и передаёт извлекателю extractSecrets. Результаты сбора отправляются наружу по двум HTTP-путям: текстовый JSON через HTTPS POST отправляется на хост CFG.WORKERS (который используется в обфускации) по пути /x, а полный отчёт отправляется multipart/form-data POST на тот же набор хостов по пути /y.

Параллельно этой цепочке сбора работает AutoUpdater. Он безусловно создаётся и запускается в activate(); он не зависит от конфигурации telemetry. После старта он сразу запрашивает один раз /version, а затем каждые 30 минут опрашивает два захардкоженных Worker. Пока ответ содержит version и url, код сопоставляет номера версий, скачивает VSIX, вызывает команду установки VS Code и затем удаляет временные файлы.

Вся цепочка обновлений не содержит никаких проверок целостности: сам обновлятор не реализует фиксацию хэша, подписи, publisher или сертификатов. Это означает, что сервер может в любой из итераций опроса вернуть более высокую версию и адрес загрузки и самостоятельно решить, когда инициировать обновление и какой VSIX доставлять. Ключевым моментом является то, что перед обновлением всплывает только уведомление с кнопкой "OK"; после завершения всех стадий уведомления код продолжает установку — нет ни реальной опции отмены, ни чтения результата выбора пользователя.

Эти цели сбора опасны потому, что IDE Extension Host сам по себе находится внутри доверенной зоны разработчика. Web3-разработчики часто одновременно хранят материалы кошелька, учётные данные репозиториев исходного кода, токены для публикации пакетов, CI/CD и конфигурации облака; одна цепочечная атака поставок расширениями может одновременно пересечь несколько границ безопасности.

Сопоставление ролей для четырёх типов образцов или версий:

Третье. Миграция издателя (publisher)

Solidity Pro 2.4.1 и 3.4.0 не принадлежат одному и тому же Extension ID. Первая публиковалась helper-beeps, вторая использует новый publisher web3devtoolsx. Почему их всё же можно разместить в одной линии расследования?

Внутренние метаданные начального commit v3.4.0 fe794a2 напрямую отвечают на этот вопрос. В package.json объявлен publisher: web3devtoolsx, версия 3.4.0, repository указывает на github.com/web3devtoolsx/solidity-pro. Однако out/package.json из этого же commit сохраняет publisher: helper-beeps, версию 3.3.0, repository указывает на github.com/helper-beeps/solidity-pro. Файл LICENSE всё ещё содержит строку "Copyright (c) 2026 Helper Beeps".

Оба package.json взяты из одного и того же коммита; это доказывает, что начальные сборочные артефакты Solidity Pro в идентичности web3devtoolsx напрямую происходят из helper-beeps. Это означает прямую связь по происхождению между кодом или сборочными артефактами.

После наложения цепочки наследования сборочных артефактов на временную шкалу официальных отметок о зловредности схема ротации publisher становится ещё более ясной:

helper-beeps.solidity-pro добавлен в официальный malicious-список (2026-08-06 14:27:24 UTC)
    │ 8 часов 32 минуты 48 секунд
    ▼
Создание аккаунта web3devtoolsx на GitHub (2026-08-06 23:00:12 UTC)
    │ примерно 16 минут
    ▼
Появилась новая Solidity Pro v3.4.0
    │ на следующий день
    ▼
web3devtoolsx.solidity-pro также добавлен в официальный malicious-список (2026-08-07 12:38:52 UTC)

Четвёртое. Clean release

После отправки на GitHub initial commit с зловредным bundle v3.4.0 прошло всего 13 минут 29 секунд. В том же репозитории был сделан откат версии до v1.0.0 Clean commit. В течение этого крайне короткого окна издатель также временно инициировал и затем сам закрыл claim на namespace Open VSX (issue без комментариев, закрыто лично web3devtoolsx).

Изменения в Clean commit точно концентрированы в двух категориях целей. Со стороны исполнения были удалены Web3Analytics-активация, AutoUpdater запуск, конфигурация telemetry, зависимости javascript-obfuscator и шаги обфускации сборки. Со стороны "поверхности продукта" были удалены AI Audit Engine, Security Scanner, badge «100K+» и раздутые формулировки возможностей. Номер версии откатили с 3.4.0 до 1.0.0.

Эти изменения сосредоточены в одном и том же коммите с названием "Clean release". Он напрямую удаляет публично достижимые высокорисковые точки входа и часть заметных маркетинговых формулировок, из-за чего системы, проверяющие только новые bundle, больше не попадают на исходные зловредные модули. Очистка не полная: формулировки "Trusted by 100K+" и "vulnerability scanner" в description package.json не удалены — удалена самая заметная badge, а если этот manifest реально упаковывается и публикуется, метаданные, влияющие на результаты поиска и страницу магазина, остаются. А как было сказано ранее: зловредный исходный код по-прежнему полностью сохранён в каталоге src/, просто он не попадает в финальный пакет благодаря .vscodeignore.

Clean release меняет финальный доставляемый артефакт, но не историю этого проекта, которая уже происходила.

Пятая. Упаковка доверия

Почти одновременно с изменением версий произошло и быстрое «упаковывание» нового publisher: после создания аккаунта web3devtoolsx примерно за 16 минут концентрированно появились корпоративные материалы, форки шести известных проектов, репозиторий продукта, зрелый номер версии и заявления 100K+. Поскольку эти сигналы сгруппированы, объективно это заставляет новый аккаунт выглядеть более зрелым по организации.

Материалы в корпоративном стиле. Примерно через 15 минут после создания аккаунта в Profile уже указаны название "Web3 Dev Tools", поле company, локация Zug, сайт, ссылка на Twitter, один запущенный продукт и два роадмапа с пометкой "Coming Q3". По состоянию на 12 августа 2026 года при повторной проверке долгосрочные метрики активности followers, following, gists и т.п. всё ещё равны 0.

Шесть форков известных проектов. За 13 секунд аккаунт последовательно сделал форки OpenZeppelin Contracts, Foundry, Hardhat, Chainlink, Uniswap v3-core и ethers.js. Обычные посетители увидят на главной странице знакомые названия Web3-проектов, но сам факт форка лишь означает копирование исходного репозитория и не равен вкладу, сотрудничеству или любым формам одобрения.

Версия и время создания не совпадают. Первоначальный коммит, сделанный через 8 секунд после создания репозитория, одновременно содержит пять комплектов меток версий: v2.4.1, v2.4.5, v3.2.3, v3.3.0 и v3.4.0. При этом в заголовке исходного кода утверждается, что впервые релиз был сделан в 2025 году. Эти версии и возрастные метки заметно расходятся с аккаунтом и публичной историей, созданной в тот же день, что и репозиторий.

Повторное усиление социальной доказательности. «100K+» одновременно встречается в repository description, package.json, out/package.json, README badge, тексте README и build-выводе — это постоянно подчёркиваемое в открытых материалах проекта заявление о масштабе пользователей. Текущие материалы не позволяют независимо подтвердить истинность этой цифры, но такая формулировка, как и зрелый номер версии, корпоративный профиль и форки известных проектов, вместе формирует образ зрелого продукта Solidity Pro для внешнего представления.

Эти рекламные заявления явно противоречат фактическому поведению кода, которое подтверждено выше: README утверждает, что не хранит private keys или исходный код; конфигурация описывает telemetry как анонимизированные данные для использования; сборочный скрипт называет процесс обфускации javascript-obfuscator "privacy". Продукт заявляет AI-аудит, сканирование уязвимостей и обнаружение повторного входа (reentrancy), но публичные команды в основном сводятся к запросу Gas, отображению цены токенов и одной подсказке, скомпилированной через Hardhat/Foundry.

Корпоративные материалы, известные форки, зрелые версии, 100K+ реальные доступные небольшие функции и заявления о приватности влияют на первоначальное суждение посетителя об расширении. Каждый элемент по отдельности может выглядеть нормально; а аномалия заключается в том, что эти сигналы одновременно появляются с зловредным кодом, быстрой временной шкалой и остатками старого publisher, относящимися к сборкам.

Шестая. Слепые зоны детектирования по одной версии

Зловредный код можно удалить, но история версий, издательская идентичность и происхождение инженерного проекта не обнуляются автоматически.

Собрав находки из первых пяти глав, Solidity Pro демонстрирует паттерн, который заслуживает внимания платформы и продуктов безопасности: имя расширения и publisher, уже явно связанные с известной историей зловредности. Публикация новой версии, не попадающей в оригинальные зловредные возможности, позволяет системам, которые проверяют только текущую сборку, снова выдавать clean/не найдено/низкий риск.

Отличать такой паттерн от обычных исправлений безопасности нельзя только по тому, чистый ли новый код: нужно одновременно проверить проблемы на четырёх уровнях:

• Ответ на хэш и текущий bundle: что именно сейчас содержит этот файл.

• Ответ по истории версий: какие расширение с этим ID или publisher ранее поставляло.

• Ответ по publisher и происхождению кода: с какими известными зловредными проектами текущий пакет имеет прямую связь по происхождению.

• Ответ по текущей и исторической плоскости удалённого управления: разрешает ли текущий локальный код или историческая версия серверу менять содержимое поставки.

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

• Сохранение хэшей исторических версий и результатов деобфускации; когда новая версия удаляет большое число опасных модулей, нужно инициировать проверку различий, а не автоматически восстанавливать доверие.

• Связать остатки старого publisher, сходство кода и сборочные скрипты, чтобы установить прямую связанность по происхождению между кодом или сборочными артефактами.

• Включить периодическую проверку /version, удалённые URL и записи о временной установке VSIX в мониторинг во время выполнения.

• Скачивания, stars и корпоративный профиль воспринимать только как контекст, а не как безопасностное подтверждение.

Итоги

Solidity Pro в обеих издательских идентичностях — helper-beeps и web3devtoolsx — содержит чётко определённые зловредные реализации: в 2.4.1 сначала стоит условие предварительного локального случайного ожидания и фильтрации окружения, затем выполняется загрузка зашифрованного Python с удалённого узла и его запуск; в 3.4.0 после старта VS Code автоматически запускается сбор учётных данных, которые утекaют через два HTTP-пути /x и /y, при этом сохраняется канал обновления VSIX, управляемый ответом с удалённой стороны. В начальном 3.4.0 out/package.json, repository и информации об авторских правах по-прежнему указано helper-beeps, что доказывает прямую связанность по происхождению между артефактами сборки двух publisher.

Финальный bundle из GitHub Clean commit удалил эти зловредные модули, но репозиторий всё равно сохраняет исходные файлы зловредных модулей. Локальная реконструкция пакета 4.0.0 тоже не обнаружила исходные зловредные модули. Начальный commit, в котором присутствуют зловредные точки входа и сборочный мусор, до Clean commit отделяет всего 13 минут 29 секунд; при этом корпоративные материалы, шесть форков известных проектов, репозиторий продукта и зрелые номера версий появляются концентрированно примерно через 16 минут после создания аккаунта.

Этот кейс в итоге показывает следующее: недостаточно оценивать риск расширения только по текущему файлу или текущей версии. Зловредный код может исчезать из самого свежего bundle, но история зловредной активности от этого не становится неактуальной: "чистая" новая версия не может стереть факт, что под тем же названием и тем же publisher ранее доставлялся зловредный код.

Рекомендация

1. Разработчики, устанавливавшие helper-beeps.solidity-pro или web3devtoolsx.solidity-pro, должны сначала изолировать сеть, сохранить каталог расширения, копии установочных пакетов, процессы и сетевые журналы, после чего отключить и удалить соответствующие версии. Затем проверить дерево процессов VS Code, Python-файлы в временных каталогах, аномальные записи установок VSIX и запросы /firmware, /x, /y, /version в прокси-логах.

2. Если включалась работа Solidity Pro 3.4.0 (publisher: web3devtoolsx), то приватные ключи кошелька, seed-фразы, GitHub/GitLab/npm/PyPI/AWS/Cloudflare/AI-сервисы и токены CI/CD могли быть раскрыты. Следует в первую очередь отозвать или ротировать соответствующие учётные данные на чистом устройстве; криптоактивы нужно перенести в кошелёк с совершенно новым seed или private key — нельзя ограничиться сменой пароля исходного кошелька.

3. Если включалась работа Solidity Pro 2.4.1 (publisher: helper-beeps), и если хост мог пересечь окно задержки данного образца, либо фактическую длительность выполнения подтвердить невозможно, следует провести расследование событий, выполняя действия как при потенциальном выполнении локального кода.

4. Корпоративной команде безопасности следует в первую очередь искать Extension ID, опасные пути запросов, известные Worker, временные файлы и аномальные деревья процессов, а затем, совместив два образца SHA-256, время установки расширения и сетевые записи процессов VS Code, определить область затронутого. Особое внимание — на комбинированные сценарии: запуск detached Python со стороны VS Code Extension Host, установка VSIX из временного пути, и запуск multipart HTTPS после чтения ценных конфигураций.

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

IOC

Зловредный файл

filename: helper-beeps.solidity-pro-2.4.1.tar.gz

SHA256: 7b53b1d93f46babc7415d898e17e71ffb6f3a3af3adb222f21c03adea8b30d50
filename: web3devtoolsx.solidity-pro-3.4.0.gz

SHA256: bcbaf774f9cea0b0131859b96ba0eeadfd5a49bba59302de1bcf3d884300d508

О MistEye

MistEye — платформа Web3-угроз и динамического мониторинга безопасности, разработанная SlowMist самостоятельно. Она предоставляет через API возможности обнаружения зловредной активности в экосистеме открытых пакетов и предупреждения о рисках цепочки поставок.

Все зловредные пакеты и IOC, задействованные в этом действии, уже подключены к движку MistEye для обнаружения угроз. Разработчики могут через API выполнить автоматическую проверку зависимостей проектов, быстро определить, попал ли в известные зловредные пакеты, и получить рекомендации по действиям.

📖 API-документация: https://app.misteye.io/api-docs

🛠️ MistEye-DepScan: https://github.com/slowmist/MistEye-DepScan — лёгкий CLI-инструмент; одной командой сканирует зависимости проекта и известные зловредные пакеты во всех глобально установленных пакетах. Поддерживает экосистемы npm / PyPI / Rust (Cargo) / Go / RubyGems

🛠️ MistEye-Skills: https://github.com/slowmist/misteye-skills — AI-набор безопасных навыков для кодирования; безопасностные функции MistEye автоматически запускаются перед установкой зависимостей и доступом к URL.

🛠️ MistEye-DNS-Guard: https://github.com/slowmist/MistEye-DNS-Guard — локальный DNS relay, реализованный на Rust. Он выявляет зловредные домены и рискованные обращения, распознаёт сетевые угрозы вроде фишинга, C2 и т.п.

Эта статья подготовлена командой угроз SlowMist совместно с платформой MistEye для threat intelligence и анализом, управляемым AI-агентом SlowMist Agent. При любых вопросах обращайтесь за консультацией и отправляйте обратную связь.

Ссылки для справки:

[1] https://yeethsecurity.com/blog/2026-08-06-Solidity-Pro-WhiteCobra-C2-to-Telegram