Вредоносные версии npm-пакета запускали скрытые бинарные файлы

23 сентября 2026 года вредоносные выпуски npm-пакета @memtensor/memos-cloud-openclaw-plugin версий 0.1.21, 0.1.23 и 0.1.25 содержали скрытый исполняемый полезный груз. Аналогичный загрузчик нашли в исходном дереве Python для MemoryOS 2.0.34. В обоих случаях анализ обнаружил признаки сбора данных и учётных записей, однако успешную эксфильтрацию не подтвердили.

Загрузка полезного груза и сбор данных

Пакет npm не использовал скрипты установки. Вместо этого изменённый код плагина импортировал lib/sckit.js и запускал полезный груз при старте шлюза и во время операций извлечения из памяти. При извлечении загрузчик передавал запрос пользователя через переменную окружения SCKIT_EVENT_TEXT. Он также копировал окружение хост-процесса, что потенциально могло привести к раскрытию унаследованных учётных данных дочернему процессу.

Загрузчик выбирал бинарные файлы для конкретных платформ из скрытого каталога .sckit и запускал их в отсоединённом режиме с подавлением ввода и вывода. Полезные нагрузки предназначались для Windows, Linux и macOS на архитектурах amd64 и arm64. В версии 0.1.25 появились tls-trust.js и встроенный файл CA. Они позволяли дочернему процессу использовать резервный набор сертификатов в некоторых минимальных средах Linux или CI. Это повышало надёжность HTTPS, но не отключало проверку сертификатов и не подтверждало передачу данных.

Статический анализ выявил строки и шаблоны, связанные с такими данными:

• ключи AWS и JWT;
• токены GitHub и GitLab;
• учётные данные npm и PyPI;
• токены Hugging Face и Vault;
• ключи Slack и Stripe;
• учётные данные SendGrid;
• другие значения, похожие на секреты.

Декодированная конфигурация использовала домашний каталог как корневой каталог для инвентаризации. Это соответствовало цели сбора учётных записей и локальных файлов. Вредоносные выпуски появлялись повторно вскоре после чистых выпусков. По оценке авторов отчёта, одной замены пакета недостаточно, чтобы устранить скомпрометированный доступ к публикации.

Исходный код Python и меры реагирования

В исходном дереве Python для MemoryOS 2.0.34 находились аналогичный загрузчик и шесть бинарных файлов для разных платформ. Путь инициализации журналирования мог запускать загрузчик во время импорта; дочерний процесс при этом наследовал окружение процесса Python. Пакет также включал вспомогательные средства доставки CI. Перед загрузкой и запуском эмиттера они проверяли подписанные метаданные, идентификаторы выполнения, хеши активов и встроенный ключ Ed25519.

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

Авторы отчёта рекомендуют:

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

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.