Почти 500 скачиваний набрал вредоносный NuGet-пакет Sicoob.Sdk, который выдавал себя за C# SDK для интеграции с бразильской финансовой системой Sicoob и при этом уводил client ID, пароль от PFX и сам сертификат. Для русскоязычных команд это не экзотика про далекую Бразилию, а наглядный кейс о том, как обычная зависимость из знакомого реестра превращается в прямой канал к банковским и облачным секретам.
По данным The Hacker News, вредоносная логика была встроена в версии 2.0.0–2.0.4 пакета Sicoob.Sdk. Исследователи из Socket выяснили, что при создании объекта SicoobClient пакет считывал с диска PFX-файл, кодировал его в Base64 и отправлял на жестко заданный endpoint Sentry вместе с client ID и паролем к сертификату. То есть атакующему уходили не косвенные метаданные, а готовый набор для аутентификации в банковском API. Если компания автоматизировала через Sicoob платежи или генерацию динамических Pix QR-кодов, компрометация такого комплекта открывает дорогу к подмене интеграции от имени жертвы.
На этом авторы пакета не остановились. По данным Socket, библиотека также перехватывала сырые ответы Boleto API и отправляла их по отдельному пути в том же Sentry. Для бразильского рынка Boleto — один из стандартных способов оплаты онлайн и офлайн, поэтому в таких ответах могут оказаться статусы платежей, суммы, сроки, идентификаторы операций и данные плательщика или получателя. С практической точки зрения это уже не просто кража секрета для разработчика, а потенциальная утечка финансовых данных и операционного контекста бизнеса. После ответственного раскрытия NuGet заблокировал пакет, а аккаунт с названием sicoob, опубликовавший его, оказался связан еще с 11 пакетами, суммарно набравшими около 6 тысяч скачиваний.
Отдельно неприятен способ маскировки. Исследователи указывают на расхождение между исходниками в привязанном GitHub-репозитории и тем артефактом, который реально раздавался через NuGet. Репозиторий выглядел чисто и создавал ощущение легитимности, а вредоносная логика появлялась уже на уровне опубликованного пакета. Это важная деталь для команд, которые до сих пор считают проверку GitHub-страницы достаточной гигиеной перед установкой зависимости. Не достаточной. Если исходники и пакет не воспроизводимы из одного и того же состояния, доверять нужно не красивому README, а цепочке поставки целиком: от владельца пакета и истории версий до совпадения сборки и содержимого опубликованного артефакта.
Есть и еще один слой иронии: сам пакет, как отмечает Socket, всплыл в Google Search AI Mode как легитимная C#-библиотека для работы с API Sicoob. То есть генеративный поиск здесь не создал атаку, но помог ей масштабироваться, подсовывая разработчикам правдоподобный ответ на вполне рабочий запрос. Для рынка это неприятный сигнал. Раньше безопасники спорили о typosquatting и фальшивых README, теперь к воронке дистрибуции добавляется AI-поиск, который умеет уверенно пересказывать и легитимные, и токсичные артефакты без внятной границы между ними.
Параллельно Microsoft Defender Security Research Team обнаружила 14 вредоносных npm-пакетов, опубликованных 28 мая 2026 года одним актором под именем vpmdhaj. Эти пакеты маскировались под инструменты для OpenSearch, ElasticSearch, DevOps и конфигурации окружения, а их цель была предельно приземленной: собрать AWS-учетные данные, токены HashiCorp Vault, npm-токены и секреты из CI/CD через собственный harvester, который запускался в preinstall-hook. Список имен показателен сам по себе: opensearch-setup, search-engine-setup, env-config-manager, elastic-opensearch-helper и другие названия, которые не выглядят как опечатка, а выглядят как скучная служебная библиотека из внутреннего тулкита. Именно в этом и состоит новая норма supply chain-атак: злоумышленники больше не обязаны мимикрировать под одну букву мимо оригинала, им достаточно звучать правдоподобно в ежедневном workflow.
На этом фон не заканчивается. The Hacker News перечисляет еще несколько свежих кампаний в npm: 164 пакета в пяти scoped-неймспейсах, которые через postinstall тянули вторую стадию JavaScript и отправляли переменные окружения на внешний домен; 141 пакет, превращавший npm в бесплатный хостинг для ad-monetized веб-прокси; forge-jsxy с кейлоггингом, мониторингом буфера обмена, поиском .env, эксфильтрацией shell history, снятием скриншотов и поиском криптокошельков; а также 176 пакетов с dependency confusion и демонстративной версией 99.99.99 для загрузки платформоспецифичного payload. Sonatype на этом фоне прямо говорит: термин typosquatting уже слишком узок. Более точное описание — manufactured legitimacy, то есть искусственно сконструированная правдоподобность пакета внутри нормального процесса разработки.
Для разработчиков и ИТ-руководителей вывод неприятный, но полезный. Если пакет просит путь к сертификату, client ID, токенам облака или вообще чему-то, что потом дает доступ к деньгам, данным или пайплайну, он уже не «просто библиотека». Это элемент доверенной цепочки с правом на ущерб. В кейсе Sicoob.Sdk минимальный набор обязательных действий очевиден: удалить пакет, считать PFX-материалы скомпрометированными, перевыпустить сертификаты, сменить пароли к PFX, обновить или отключить затронутые client ID и проверить логи аутентификации и API на аномальную активность. Но стратегически вопрос шире: умеет ли ваша команда доказывать, что пакет из реестра соответствует исходникам, кто и когда одобряет новые зависимости, и что произойдет, если preinstall или postinstall внезапно решат «помочь» вашему окружению поделиться секретами наружу.
История с Sicoob и свежая волна npm-кампаний показывают, что supply chain-атаки окончательно ушли от грубых подделок в сторону тихой имитации нормальной инженерной рутины. Чем убедительнее пакет вписывается в повседневный стек, тем выше шанс, что следующая утечка начнется не с эксплойта нулевого дня, а с команды install, которую кто-то запустил без лишних вопросов.