Кампания Flooding Dropper: в npm обнаружено более 800 пакетов с RAT и инфостилером

Коротко: в начале августа 2026 года в реестре npm появилось от 800 до 1033 вредоносных пакетов с именами-опечатками (typosquatting). При импорте пакета через require() запускается загрузчик WEL1DROPPER, который определяет ОС и скачивает совместимую полезную нагрузку — кросс-платформенный RAT и инфостилер. На Linux дополнительно устанавливается фреймворк Sliver C2. Кампанию отслеживают Sonatype, Palo Alto Networks Unit 42 и независимый исследователь Пол Маккарти.

Что такое Flooding Dropper

Flooding Dropper — это кампания по массовой публикации вредоносных пакетов в реестр npm, зафиксированная около 7 августа 2026 года. Её первым описал исследователь Пол Маккарти (OpenSourceMalware), а детальный анализ опубликовали Sonatype и Palo Alto Networks Unit 42.

Масштаб кампании оказался значительным: по данным Sonatype, на момент публикации к ней относились не менее 800 пакетов; обновлённые данные Unit 42 от 11 августа 2026 года подняли планку до 1033 уникальных пакетов. Все они опубликованы под именами, имитирующими популярные библиотеки через опечатки, — техника, которую называют typosquatting. Имена генерировались с помощью ИИ, что позволило быстро создать большой словарь правдоподобных вариантов.

Исследователи допускают, что кампания связана с более ранней операцией Moika (апрель 2026 года) — тогда в npm и PyPI было опубликовано 250+ пакетов с использованием атаки на путаницу зависимостей (dependency confusion). Косвенные признаки указывают на возможную нацеленность на российские финансовые организации, хотя жертвы могут быть гораздо шире.

Вектор атаки: require() вместо хуков

Большинство вредоносных npm-пакетов используют lifecycle-хуки — прежде всего preinstall и postinstall, — которые автоматически запускаются при выполнении npm install. Именно этот вектор перекрыла платформа в выпуске npm 12, отключившей install-скрипты по умолчанию.

Flooding Dropper использует иной подход: пакет выглядит как обычная библиотека, а вредоносный код запускается лишь тогда, когда разработчик явно импортирует пакет через стандартный вызов require() в своём коде. Инструкция по импорту включена прямо в файл README — разработчик видит её как обычную документацию и выполняет сам.

Полезная нагрузка первого уровня — загрузчик WEL1DROPPER. Он определяет операционную систему и архитектуру процессора, после чего запрашивает совместимую полезную нагрузку второго уровня. Загрузка происходит с одного из трёх доменов на Cloudflare Workers; если они недоступны, WEL1DROPPER обращается к резервному каналу через DNS TXT-записи домена wel1[.]ru, прописанные под каждую ОС отдельно.

Что делает вредонос на каждой платформе

Финальная полезная нагрузка зависит от целевой операционной системы и включает кросс-платформенный RAT (Remote Access Trojan) и инфостилер:

Часть пакетов в кампании содержит имитацию телеметрических SDK — компоненты, которые на первый взгляд выглядят как сборщик метрик, но внутри скрывают тот же загрузчик WEL1DROPPER.

После заражения машины вредонос собирает переменные среды и учётные данные — в первую очередь интересуют токены доступа к облачным сервисам и CI/CD-системам. Подобная схема уже применялась при атаке на цепочку поставок через взломанные пакеты keyv и cacheable, хотя тогда вектор был иным — компрометация аккаунта мейнтейнера, а не typosquatting.

Почему это касается всех, кто работает с пакетами

npm-пакет — это по сути архив с кодом (формат .tgz, то есть gzip-сжатый tar). Когда вы устанавливаете зависимость, менеджер пакетов скачивает этот архив, проверяет контрольную сумму и распаковывает его в папку node_modules. С точки зрения файловых операций — это та же распаковка архива, только с автоматическим выполнением кода.

Flooding Dropper наглядно показывает, что вредонос в пакете — это файловая угроза нового рода: он не выглядит как .exe или .vbs, не срабатывает при установке, не даёт антивирусу явного сигнала в момент загрузки. Полезная нагрузка запускается позже — при первом вызове в коде. Принцип безопасности «проверь файл перед открытием» здесь работает лишь частично: надо проверять не только наличие пакета в реестре, но и точность его имени.

Что делать разработчику

Единственная надёжная защита от typosquatting — это тщательная проверка имени пакета перед установкой и привязка зависимостей к точным версиям. Вот конкретные шаги:

1. Проверьте имена зависимостей. Сравните каждое имя пакета в package.json с официальным именем на npmjs.com. Опечатка в одну букву — уже другой пакет.
2. Заморозьте версии. Используйте точные версии и фиксируйте package-lock.json в системе контроля версий. Это снижает риск незаметного обновления до заражённого пакета.
3. Сканируйте перед установкой. Инструменты вроде npm audit, Sonatype Lifecycle или аналогичные OSS-сканеры умеют помечать известные вредоносные пакеты до того, как они попадут в node_modules.
4. Изолируйте CI-окружение. В пайплайнах сборки ограничивайте исходящие сетевые запросы: WEL1DROPPER не сможет скачать полезную нагрузку из Cloudflare Workers или запросить DNS TXT, если у процесса нет доступа наружу.
5. Применяйте --ignore-scripts как дополнительный слой. Хотя для этой кампании флаг не решает проблему, он всё равно блокирует обычные lifecycle-атаки и снижает общую поверхность атаки при установке зависимостей.

Общие принципы безопасной работы с файлами и загрузками — в разделе безопасность на Loadfile.

Источники

• The Hacker News — Nearly 800 Malicious npm Packages Deliver Cross-Platform RAT and Infostealer (7 августа 2026, обновлено 11 августа)
• SC World — Nearly 800 malicious npm packages deliver cross-platform malware (10 августа 2026)