Скоординированная кампания TrapDoor использует пакеты npm, PyPI и Crates.io для кражи учетных данных разработчиков, кошельков, ключей и cloud-секретов. По данным исследования Socket, на которое ссылается The Hacker News, обнаружено более 34 вредоносных пакетов в более чем 384 версиях. Самая ранняя зафиксированная активность — 22 мая 2026 года в 20:20 UTC.
Цель кампании — разработчики, работающие с crypto, DeFi, Solana, Sui, Move и AI-инструментами. Это не случайный выбор. В таких средах один утекший токен, ключ кошелька, SSH-доступ или cloud-секрет может открыть путь к коду, деньгам, инфраструктуре или пользователям ниже по цепочке.
Эта активность TrapDoor не связана с другой кампанией под тем же названием, о которой на прошлой неделе сообщила команда HUMAN Satori. Там речь шла о рекламном мошенничестве через Android-приложения в Google Play. Название одно, операция другая.
Что известно о TrapDoor#
Кампания охватывает три крупных экосистемы open source-пакетов: npm для JavaScript, PyPI для Python и Crates.io для Rust. По данным Socket, пакеты публиковались волнами с группы аккаунтов и получали имена, похожие на нормальные инструменты для рабочих процессов разработчиков, а не на очевидную приманку.
Темы пакетов, о которых сообщают исследователи: сканирование crypto-учетных данных, prompt engineering, настройка локальной среды, security-инструменты и утилиты для blockchain-разработчиков. Логика простая: прийти туда, где разработчики и так устанавливают инструменты.
npm-пакеты, по данным отчета, разворачивают общий JavaScript-payload с именем trap-core.js. Socket пишет, что он ищет учетные данные и секреты разработчика, проверяет AWS и GitHub-токены через API-вызовы, пытается двигаться дальше по SSH и закрепляется на машине несколькими локальными способами.
Среди таких способов закрепления упоминаются .cursorrules, CLAUDE.md, Git hooks, shell hooks, systemd, cron и SSH. Часть приемов давно знакома по операторской практике. Часть уже ближе к современным средам с AI-помощниками для кода.
Python-пакеты идут другим путем. Они рассчитаны на выполнение при import, затем загружают JavaScript с контролируемого атакующим домена GitHub Pages и запускают его через node -e. Такая схема позволяет менять поведение после публикации без выпуска новой версии в PyPI. Пакет становится загрузчиком, а не полным payload.
Rust-крейты используют build.rs — механизм build script в Rust — чтобы запустить вредоносный код. По данным отчета, они ищут локальные keystore, шифруют данные жестко заданным XOR-ключом и отправляют их в GitHub Gists. Это не сложная криптография. Ей и не нужно быть сложной: практическая цель — быстро спрятать и вывести украденные локальные данные.
Самая острая часть: AI-инструкции как канал атаки#
Необычный элемент кампании — предполагаемое использование файлов .cursorrules и CLAUDE.md со скрытыми инструкциями, которые должны влиять на AI-помощников для программирования. Socket сообщает, что участник кампании открывал GitHub pull requests в популярные AI- и developer-проекты, включая browser-use/browser-use, langchain-ai/langchain и langflow-ai/langflow.
Похоже, цель была шире, чем просто опубликовать зараженные пакеты. Атакующий проверял, могут ли вредоносные project-level instruction files попасть в репозитории через обычный open source-процесс contribution, а затем быть прочитаны AI-инструментами как доверенный контекст.
Это важно, потому что AI-помощники часто работают внутри локальной среды разработчика, где рядом лежат секреты, shell-доступ, метаданные репозитория и проектные инструкции. Если помощник воспринимает файл из репозитория как инструкцию, а не как недоверенный контент, сам репозиторий становится каналом доставки prompt.
Содержание таких инструкций, по отчету, довольно прямолинейное: убедить помощника запустить «security scan», который находит и выводит секреты наружу. Формулировка эффективна, потому что выглядит как защитная задача. Она также эксплуатирует привычку разработчиков разрешать инструментам смотреть локальное дерево проекта: инструмент ведь должен помогать.
Это не доказывает, что все AI-помощники для кода одинаково уязвимы к такой тактике. В исходных материалах нет подтверждения успешного компромета через эти pull requests. Более точный и полезный вывод уже сам по себе серьезен: AI-специфичные проектные файлы стали достаточно привлекательной целью, чтобы атакующие проверяли их в open source-пути contribution.
Почему такая кампания выгодна атакующим#
TrapDoor сочетает несколько моделей выполнения, а не опирается на слабость одной экосистемы.
В npm postinstall и поведение package lifecycle давно считаются рискованным путем: код может запускаться прямо во время установки. В PyPI выполнение при import превращает безобидный на вид import библиотеки в триггер. В Rust build.rs дает крейтам легитимный механизм выполнения на этапе сборки, которым можно злоупотребить, когда разработчики или CI-системы компилируют зависимости.
В некоторых местах кампания также отделяет доставку от payload. PyPI-пакет, который тянет удаленный JavaScript, легче обновлять после публикации. Пакет, проверяющий украденные AWS или GitHub-токены, может отделять полезные секреты от шума до того, как оператор потратит на них время. SSH lateral movement превращает скомпрометированную рабочую станцию из источника секретов в точку перехода дальше.
Выбор целей объясняет эти решения. У crypto- и DeFi-разработчиков могут быть материалы кошельков или проектные учетные данные. AI-разработчики часто работают в репозиториях, связанных с cloud API и провайдерами моделей. Open source-мейнтейнеры могут иметь GitHub-токены, права публикации пакетов или доступ к CI/CD. Ноутбук разработчика часто контролируется слабее, чем production-инфраструктура, хотя может хранить ключи к обеим.
Чего не стоит утверждать сверх данных#
Доступные публикации не дают подтвержденного числа жертв. Они не доказывают, что все перечисленные пакеты набрали значимые установки, что каждый способ закрепления сработал или что AI-инструкции привели к успешной краже секретов через выполнение помощником.
Эту кампанию также не стоит смешивать с не связанной с ней Android-кампанией рекламного мошенничества, у которой оказалось то же имя TrapDoor. В threat reporting такие совпадения названий случаются. Технические детали здесь указывают на supply-chain-операцию против разработчиков через package registries, а не на кластер mobile ad fraud.
Самое сильное подтвержденное утверждение: атакующий скоординированно публиковал пакеты в нескольких экосистемах и использовал native-механизмы выполнения этих экосистем для кражи секретов разработчиков. Более перспективный, но тоже важный вывод: атакующие уже проверяют AI coding workflows как часть software supply chain.
Что командам проверить сейчас#
Командам, использующим npm, PyPI или Crates.io, стоит сначала поискать имена пакетов, указанные Socket и The Hacker News, в dependency manifests, lockfiles, локальных package caches, CI-логах и на рабочих станциях разработчиков. Два имени, видимые в исходном материале: crypto-credential-scanner и prompt-engineering-toolkit. Но защитникам лучше использовать полный список indicators от Socket, если он доступен, а не ограничиваться частичными примерами.
Практические проверки:
- Просмотрите недавние установки и сборки с 22 мая 2026 года, особенно в проектах, связанных с crypto, DeFi, Solana, Sui, Move и AI.
- Проверьте выполнение lifecycle-кода пакетов: npm
postinstall, поведение Python при import и Rust-скриптыbuild.rs. - Ищите неожиданные
.cursorrules,CLAUDE.md, Git hooks, изменения shell startup, записи cron, systemd services и изменения SSH-конфигурации. - Ротируйте GitHub, AWS, cloud, wallet, SSH-учетные данные и права публикации пакетов, если подозрительный пакет запускался локально или в CI.
- Проверьте GitHub audit logs, cloud API logs и паттерны SSH-доступа на попытки проверки токенов или lateral movement после времени установки.
- Относитесь к AI assistant instruction files в pull requests как к исполняемому влиянию, а не как к безобидной документации.
Защитный вывод не в том, что «open source использовать нельзя». Вывод в другом: review пакета больше не может заканчиваться на имени и README. Build scripts, install hooks, поведение при import, загрузка удаленного payload, repo-level assistant instructions и CI execution context должны входить в модель доверия.
TrapDoor — кампания по краже учетных данных. И еще одно напоминание: рабочая станция разработчика стала активом рядом с production. Если она может публиковать код, обращаться к cloud API, подписывать коммиты, открывать SSH-сессии или направлять AI-агента, она часть supply chain.