Сразу 17 пакетов в npm и PyPI выдавали себя за SDK платёжных сервисов Paysafe, Skrill и Neteller, но вместо работы с платежами вытаскивали из окружения токены, пароли и API-ключи. Для русскоязычной IT-аудитории это не очередная страшилка про open source, а прямое напоминание: вредоносные пакеты npm теперь бьют не только по разработчикам как таковым, но и по всем, кто строит интеграции вокруг денег, CI и облаков.
О кампании сообщает BleepingComputer со ссылкой на исследование компании Socket. По данным исследователей, атакующий одновременно опубликовал 17 вредоносных пакетов: 13 в npm и 4 в PyPI. Список выглядит так, будто его собирали под поисковые запросы и привычки интеграторов: paysafe-checkout, paysafe-vault, neteller, skrill-payments, paysafe-js, paysafe-api, paysafe-node, paysafe-cards, paysafe-fraud, paysafe-kyc, skrill, skrill-sdk, paysafe-payments, а также Python-пакеты paysafe-kyc, paysafe-payments, paysafe-sdk и paysafe-api.
Сценарий атаки неприятен именно своей приземлённостью. Пакеты не ломали платёжные платформы напрямую и не пытались имитировать сложную бизнес-логику. Они изображали легитимные SDK, экспортировали ожидаемые API и возвращали фиктивные успешные ответы вместо обращения к backend-сервисам Paysafe. Для разработчика это худший тип подделки: код может не падать сразу, интеграция выглядит правдоподобно, а вредоносная нагрузка в это время уже ищет в системе секреты. В npm-версиях кража данных включалась при вызове поддельного SDK и только если в окружении находился ключ Paysafe API. В PyPI всё было ещё проще для атакующего: вредоносная логика стартовала при инициализации пакета и вообще не требовала наличия Paysafe API key.
Исследователи пишут, что собранные данные отправлялись на C2-сервер, размещённый в Amazon Web Services. В список того, что интересовало злоумышленника, вошли ключи Paysafe API, AWS-ключи, GitHub-токены, npm-токены, а также hostname, имя пользователя и метаданные об использовании API. То есть речь идёт не просто о краже одного секрета для одной интеграции. Если такой пакет оказался на машине разработчика или в CI, компрометация может перекинуться дальше по цепочке: от репозитория к пайплайну, от пайплайна к облаку, от облака к продовой инфраструктуре. Для команд, у которых платежи, деплой и облачные учётки завязаны в один контур, это уже история не про библиотеку, а про supply chain в чистом виде.
Почему это опасно не только для разработчика
Выбор брендов здесь тоже не случаен. Paysafe активно используют e-commerce-площадки, маркетплейсы, игровые сервисы, travel-бизнес и SaaS-компании. Skrill и Neteller популярны как цифровые кошельки и сервисы денежных переводов в онлайн-беттинге, криптобиржах и на Forex-платформах. Иначе говоря, злоумышленник целился не в абстрактный open source, а в сегменты, где у разработчика почти наверняка есть доступ к чувствительным ключам, тестовым и боевым средам, а иногда и к данным, связанным с движением денег. В такой конструкции даже поддельный пакет, который просто «успешно отвечает» и тихо выносит токены, оказывается вполне рабочим инструментом атаки.
Отдельная деталь из разбора Socket: у вредоносного кода были базовые антианализ-механизмы. Он прекращал работу, если видел меньше двух CPU-ядер, а также если hostname или username намекали на виртуализированную или исследовательскую среду. Ничего особенно изощрённого, но и этого достаточно, чтобы часть автоматизированных проверок пропустила образец как «пустышку». Для защитников здесь важен не уровень технического изящества, а дисциплина атакующего. Он умеет работать сразу в двух экосистемах, понимает, что ищет в окружении разработчика, и не рассчитывает только на один тип жертвы. Socket отдельно предупреждает: возможность быстро переключаться между npm и PyPI усложняет защиту компаниям, которые смотрят только в одну сторону и строят видимость безопасности вокруг одного реестра.
Что делать командам прямо сейчас
Практические рекомендации в этом случае звучат жёстко, но логично. Если любой из перечисленных пакетов был установлен, исследователи советуют немедленно перевыпустить все секреты на любой машине, где пакет импортировался или исполнялся. Не «проверить позже», не «сначала убедиться», а именно ротировать ключи и токены. Дополнительно стоит пройтись по деревьям зависимостей и запретить запросы к этим именам пакетов на уровне proxy-реестра. Для DevOps- и AppSec-команд есть ещё один конкретный индикатор: в логах CI стоит искать сочетание PAYSAFE_API_KEY с любым из названий этих пакетов. Такой поиск не исчерпывает расследование, но быстро показывает, где именно вредоносные пакеты npm или их Python-аналоги могли зацепить реальные секреты.
В более широком смысле эта история бьёт по старой иллюзии, что риск в публичных пакетных репозиториях ограничивается typosquatting'ом на малоизвестных утилитах. Здесь атакующий пошёл в понятные бизнесу и разработке сущности: платёжные SDK, KYC, checkout, fraud, payments. То есть в зоны, где имя пакета само по себе обещает «полезность», а проверка происхождения зависимости часто проигрывает срокам релиза. Для рынка это сигнал, что контроль зависимостей пора выносить из факультативной гигиены в обязательный процесс: с allowlist'ами, внутренними зеркалами, мониторингом экосистем и реакцией, которая начинается не после инцидента, а до установки очередного «удобного SDK».
Главный вопрос теперь не в том, снимут ли эти пакеты из реестров, а в том, сколько команд уже успели прогнать их через рабочие станции и CI до того, как история стала публичной. Если атакующие и дальше будут так же спокойно маскироваться под инфраструктурно важные библиотеки, следующая волна пойдёт не за абстрактными машинами разработчиков, а за доступом к конкретным бизнес-процессам и деньгам. Первоисточник публикации: .