Найти в Дзене

Как инструменты разработки становятся средствами для кражи криптоактивов

Количество атак на цепочку поставок программного обеспечения в прошлом году выросло на 156% по сравнению с годом ранее, по данным исследования Sonatype [1]. Разберемся, как эта угроза проявляет себя в мире криптовалют, и почему привычные инструменты разработчика становятся орудием злоумышленников. Автор: Дмитрий Пойда, аналитик по расследованиям AML/KYT провайдера “Шард” В последнее время инструменты для разработки криптопроектов и экосистема Open Source оказались в зоне повышенного внимания и риска, что подтверждается серией инцидентов в 2025 г. Как правило, уязвимости в этой области связаны с двумя ключевыми факторами: открытой природой исходного кода и высокой зависимостью разработчиков от сторонних пакетов. Злоумышленники чаще всего используют фейковые версии популярных библиотек и IDE-плагины (расширения для среды разработки), чтобы распространять вредоносное ПО. Примером подобной атаки может служить кража данных у разработчика, работавшего в Cursor AI IDE с поддержкой Open VSX (о
Оглавление

Количество атак на цепочку поставок программного обеспечения в прошлом году выросло на 156% по сравнению с годом ранее, по данным исследования Sonatype [1]. Разберемся, как эта угроза проявляет себя в мире криптовалют, и почему привычные инструменты разработчика становятся орудием злоумышленников.

Автор: Дмитрий Пойда, аналитик по расследованиям AML/KYT провайдера “Шард”

Зависимость от сторонних пакетов в крипторазработке

В последнее время инструменты для разработки криптопроектов и экосистема Open Source оказались в зоне повышенного внимания и риска, что подтверждается серией инцидентов в 2025 г. Как правило, уязвимости в этой области связаны с двумя ключевыми факторами: открытой природой исходного кода и высокой зависимостью разработчиков от сторонних пакетов.

Злоумышленники чаще всего используют фейковые версии популярных библиотек и IDE-плагины (расширения для среды разработки), чтобы распространять вредоносное ПО. Примером подобной атаки может служить кража данных у разработчика, работавшего в Cursor AI IDE с поддержкой Open VSX (открытый каталог плагинов) [2]. В этом случае с помощью поддельного расширения Solidity Language (которое выглядело как обычная подсветка синтаксиса, но на самом деле запускало скрипт, устанавливающий несколько вредоносов вроде ScreenConnect, Quasar RAT и инфостилер PureLogs) преступники получили полный доступ к устройству и похитили более $500 тыс. в криптовалюте.

Другими примерами атаки на цепочку поставок в области разработки могут служить инциденты в RubyGems и npm – сервисах для скачивания библиотек [3]. Вместо IDE-плагинов злоумышленники распространили поддельные пакеты, которые перехватывали данные Telegram API, включая токены и сообщения, и передавали их на внешние серверы. Такие пакеты устанавливались как обычные зависимости, обеспечивая злоумышленникам доступ к ключам и учетным данным, что в итоге приводило к финансовым потерям.

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

Инструменты разработки против разработчиков

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

Характерный пример – npm-пакет nodejs-smtp, выполненный в стиле библиотеки nodemailer для отправки писем, – модифицировал архивы десктопных кошельков Atomic Wallet и Exodus, незаметно подменяя адреса получателей криптовалюты на адрес злоумышленника. При этом кошелек оставался полностью рабочим, что делало атаку практически невидимой для пользователя до момента отправки средств.

Встречаются инциденты, связанные с генераторами криптографических ключей и сидов для кошельков. Алгоритмы с недостаточной энтропией, вроде Mersenne Twister-32, позволяли злоумышленникам предугадывать приватные ключи и похищать средства пользователей. Несмотря на риски с предсказуемостью генераторов, их все еще используют по причине удобства и из-за недостаточного опыта разработчиков.

Наибольший риск представляют инструменты, работающие с конфиденциальными данными и финансами. Защититься от атак на Open Source-проекты можно с помощью безопасного подхода на всех этапах разработки и эксплуатации. Однако важно понимать, какие именно механизмы позволяют вредоносному коду оставаться незаметным внутри этих инструментов.

Замаскированное вредоносное ПО

Основная опасность такого ПО заключается в техниках маскировки, которые позволяют злоумышленникам получать доступ к критически важной информации.

  • Обфускация и шифрование кода. Разработчики используют сложные методы, чтобы обходить антивирусные системы. Например, шифрование кода позволяет программе оставаться невидимой для традиционных методов обнаружения, основанных на сигнатурах.
  • Полиморфизм. Программа способна менять свои алгоритмы шифрования и структуру кода при каждой новой инсталляции, сохраняя функциональность, но практически полностью исключая возможность распознавания антивирусом. Это делает заражение еще более опасным, так как вредоносное ПО может работать на устройстве долгое время, незаметно собирая пароли, логины, данные банковских карт, а также файлы с конфиденциальной информацией.

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

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

На что обратить внимание?

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

Еще одна ошибка: игнорирование инструментов, которые автоматически проверяют, насколько безопасны используемые библиотеки и зависимости, – такие как SCA. С помощью таких инструментов можно вовремя заметить устаревшие компоненты или подозрительные изменения в коде. Если этого не делать, проект может стать легкой мишенью для злоумышленников.

Последствия могут быть катастрофическими как для компаний – утечки данных клиентов, прямые финансовые потери, кража интеллектуальной собственности, – так и для частных инвесторов, которые могут лишиться доступа к своим аккаунтам и средствам.

Как изменится подход к доверию в Open Source-среде криптоиндустрии

Ожидаемо появятся стандартизированные методы проверки исходного кода и цепочек зависимостей, где каждый пакет будет проходить автоматическую и независимую проверку на безопасность и целостность. Это будет похоже на систему сертификации для Open Source: пакеты с подтвержденной безопасностью будут иметь особые метки или цифровые подписи, которые сложно подделать.

Следующим шагом станет автоматизация мониторинга и реагирования на базе ИИ, который будет отслеживать подозрительные изменения в популярных пакетах. С таким инструментом система сама сможет выявлять потенциальные угрозы, например, скрытые майнеры или кейлоггеры.

Сочетание этих двух направлений сформирует основу будущего подхода к доверию в Open Source. Но даже при наличии таких инструментов защита возможна только через комплексный подход – строгий контроль зависимостей, регулярный аудит стороннего кода и непрерывный мониторинг активности на всех этапах разработки и деплоя.