101 вредоносный npm-пакет заставлял аккаунты разработчиков вступать в чужие группы и каналы без согласия владельца. Исследователи связали кампанию с набором модификаций Baileys и назвали её PhantomSub.

Проблема касается не только тех, кто ставит пакеты из открытого репозитория. Когда библиотека требует подключить личный аккаунт мессенджера к рабочему инструменту, она получает слишком широкие права и может использовать их не по назначению.

Какую проблему решаем

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

По данным исследователей, суммарно пакеты скачали 490 тыс. раз, а 116 тыс. загрузок пришлись на последние 30 дней перед публикацией отчёта. Для корпоративной среды это важный сигнал: риски возникают не только в коде, но и там, где разработчик связывает рабочие инструменты с личными аккаунтами.

Если хотите глубже разобраться, почему вредоносные зависимости так часто проходят в сборки, посмотрите наш разбор про старый вредоносный тег в GitHub Actions и материал о том, как сторонний защитный продукт может добавить слой защиты для работы из чужой сети.

Что подготовить

Понадобятся три вещи: список установленных npm-зависимостей, доступ к логам CI/CD или рабочей машины и понимание, какие пакеты требуют привязки личного аккаунта к сервису. Ещё полезно заранее выделить, кто в команде отвечает за проверку новых зависимостей.

Отдельно подготовьте правило для ревью: если библиотека просит авторизацию в мессенджере или просит больше прав, чем нужно для задачи, это повод остановиться и проверить пакет вручную.

Пошаговые действия

1. Проверьте, нет ли у вас подозрительных пакетов

Сверьте зависимости с перечнем подозрительных названий из отчёта и посмотрите, не тянутся ли они транзитивно через другие библиотеки. Особенно внимательно проверьте форки и пакеты с похожими именами, где автор меняет один-два символа.

2. Уберите пакеты, которые требуют личный аккаунт

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

3. Ограничьте установку зависимостей

Закрепите версии пакетов, включите проверку целостности и не тяните обновления вслепую. Это не уберёт риск полностью, но заметно снизит шанс, что в сборку попадёт свежая вредоносная модификация.

4. Настройте детектирование аномалий

Ищите признаки странной активности: неожиданные подписки на группы, массовые приглашения, сетевые запросы к неизвестным доменам и изменения в поведении бота после установки пакета. Для команд, которые завязаны на автоматизацию через мессенджеры, это особенно важно.

5. Изолируйте рабочие учётные записи

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

Как проверить себя

После удаления подозрительных пакетов проверьте, не состоит ли аккаунт в неизвестных группах и не подписан ли он на чужие каналы. Затем просмотрите историю установок и сравните её с тем, что зафиксировано в репозитории и lock-файлах.

Полезно ещё раз открыть параметры доступа и понять, какие инструменты действительно должны работать с личным аккаунтом. Если ответ неочевиден, права нужно урезать или вовсе убрать такой сценарий.

Что делать, если не получилось

Если вы не можете быстро понять, безопасен ли пакет, не ставьте его в рабочую среду. Перенесите проверку в изолированную среду, обновите правила ревью и дайте команде простой запрет: никаких библиотек, которые требуют лишнюю авторизацию без веской причины.

Для личного использования на публичном Wi‑Fi отдельный слой защиты тоже не помешает — особенно когда вы входите в рабочие сервисы через чужую сеть. В таких случаях удобно использовать дополнительный слой для подключения как опцию, а не как замену базовой гигиене безопасности.

Чек-лист

  • Проверить npm-зависимости на подозрительные форки и похожие названия
  • Удалить пакеты, которым не нужен личный аккаунт, но они его требуют
  • Закрепить версии и проверить lock-файлы
  • Посмотреть, не добавлял ли аккаунт неизвестные группы и каналы
  • Изолировать рабочие и личные учётные записи
  • Настроить ревью для библиотек с избыточными правами
  • Для работы из чужой сети заранее продумать дополнительный слой защиты
Поделиться: