A NuGet-пакет под видом Sicoob C# SDK якобы похищал данные для аутентификации банковских API, а отдельная группа npm-пакетов нацеливалась на облачные и CI/CD креденшелы. Сигнал не в том, что регистры пакетов опасны сами по себе. Суть в том, что обычная установка и интеграция теперь могут раскрыть банковские сертификаты, облачные ключи и токены пайплайнов до того, как разработчик заметит что-либо подозрительное.
Что изменилось в уведомлении#
The Hacker News сообщает, что исследователи обнаружили вредоносный NuGet-пакет под видом SDK для Sicoob, одной из крупнейших кооперативных финансовых систем Бразилии. По данным источника, версии 2.0.0–2.0.4 пакета Sicoob.Sdk содержали код для эксфильтрации чувствительных данных.
Похищенные данные не ограничиваются телеметрией. Пакет собирал client ID, PFX-файлы и PFX-пароли. Эти сертификаты используются для аутентификации бизнеса в сети Sicoob, включая мгновенные платежи и генерацию динамических Pix QR.
Механизм прост. При создании SicoobClient с client ID, путём к PFX и PFX-паролем, пакет читал PFX с диска, кодировал его в Base64 и отправлял client ID, PFX-пароль и сертификат на жёстко заданный endpoint Sentry.
Пакет также захватывал сырые ответы Boleto API через другой путь Sentry. Boleto — популярный бразильский метод оплаты. Сырые ответы могли содержать детали транзакций, суммы, сроки, идентификаторы и данные участников.
После ответственного раскрытия NuGet заблокировал пакет. Его скачали около 500 раз. Профиль «sicoob» имел ещё 11 пакетов с ~6000 загрузок.
Особое внимание: несоответствие исходника и артефакта. GitHub-репозиторий выглядел чистым, вредоносное поведение было только в NuGet-артефакте. Для команд, полагающихся только на репозиторий, это серьёзный сигнал.
Почему это важно для безопасности#
Кража банковских креденшелов через обычный рабочий процесс разработчика. Разработчику не нужно было запускать подозрительный исполняемый файл или вставлять секрет на сайт. Достаточно было установить пакет, решающий реальную задачу.
Риск не ограничен рабочей машиной. Скомпрометированные креденшелы Sicoob API могут позволить злоумышленнику выдавать себя за интеграцию жертвы, превращая инцидент из «разглашение секретов разработчика» в возможное мошенничество, утечку финансовых данных и сбои бизнес-процессов.
Отдельный момент — влияние AI-поиска. Google Search AI Mode показывал пакет как легитимную C# библиотеку для работы с API Sicoob. Это не доказывает, что AI стал причиной, но показывает проблему распространения: разработчик теперь видит сгенерированные рекомендации, а не только поиск по пакетам, GitHub и документацию.
С npm та же схема. Microsoft Defender Security Research Team обнаружил 14 вредоносных npm-пакетов, имитирующих OpenSearch, ElasticSearch, DevOps и конфигурационные библиотеки. Они использовали preinstall hook для запуска хакера, похищающего AWS-ключи, Vault-токены, npm-токены и CI/CD-секреты.
Список целей показывает приоритеты атакующих. Ключи облака, Vault-токены, npm-креденшелы и пайплайны открывают доступ к дальнейшим системам. Один вредоносный пакет может стать разведкой, кражей секретов, публикацией пакетов или доступом к production-системам.
Наблюдались несколько волн npm-пакетов: эксфильтрация env-переменных, использование npm как хостинга для рекламных страниц, кейлоггинг, мониторинг буфера обмена, сканирование .env, shell-history, скриншоты, удалённая файловая система, учёт хостов и скан кошельков криптовалют.
Атака не ограничивается typosquatting. Sonatype отмечает: «typosquatting» слишком узко. Злоумышленники создают легитимность через правдоподобные имена, scope, префиксы, версии и workflow-ориентированные названия. Важно, чтобы пакет выглядел разумно для разработчика.
Что проверить#
Команды, установившие Sicoob.Sdk версии 2.0.0–2.0.4, должны считать PFX скомпрометированным. Удалите пакет, замените сертификаты, смените PFX-пароли и отключите/смените client ID.
Проведите аудит аутентификации Sicoob и логов API на аномалии: неожиданные вызовы, странные операции с платежами, незнакомые client ID, необычные сети или изменения времени и объёма. Основной вопрос: использовались ли креденшелы после установки пакета?
Для npm: проверьте, установлены ли вредоносные пакеты на рабочих машинах, CI, build-образах или тестовых средах. Обратите внимание на preinstall-скрипты, которые выполняются до импорта пакета.
Практические проверки:
- Просмотрите lockfile и логи менеджера пакетов на подозрительные имена.
- Ищите в CI-логах неожиданные сетевые вызовы во время установки.
- Смените npm-токены, облачные креденшелы, Vault-токены и CI/CD-секреты при вероятной компрометации.
- Проверьте build-раннеры и рабочие станции, где были установлены подозрительные пакеты.
- Сравните артефакты реестра с исходным кодом, если важна прозрачность.
- По возможности отключайте install-скрипты по умолчанию, разрешая исключения вручную.
Пересмотрите подход к проверке OSS: чистый репозиторий полезен, но не равен проверенному артефакту. Если артефакт отличается от исходника, именно он выполняется.
Для деталей по операционной безопасности артефактов смотрите заметку GigaTap: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
Чего не преувеличивать#
Отчёт не доказывает, что каждая загрузка привела к кражам. Количество загрузок — не равно исполнению, исполнение — не равно использованию с реальными client ID и PFX.
Не доказано, что все пакеты под тем же профилем NuGet были вредоносными. Каждый артефакт требует отдельного анализа.
Подробность с Google AI не означает «AI вызвал атаку». Важный вывод: системы рекомендаций могут усиливать вредоносные пакеты при слабой проверке происхождения. Это проблема поиска и доверия, а не новая эксплойт-класс.
Вывод: доверие на этапе установки теперь критично для безопасности. Название пакета, ссылка на репозиторий, AI-сводка и видимая полезность — слабые сигналы. Решает артефакт, его поведение при установке, сетевая активность и доступ к секретам.