// Веб

PhantomRaven: как вредоносные npm-пакеты сами зарабатывают на bug bounty

Схема: заражённый npm-пакет крадёт секреты CI/CD, доступ используют чтобы найти уязвимость и получить выплату по bug bounty

У большинства стилеров скучная бизнес-модель. Украл логины, слил их на теневой рынок логов, получил копейки за штуку. Оператор кампании PhantomRaven эту схему просто выкинул. В свежем разборе CrowdStrike (вышел в сентябре) украденные данные не нашли ни на одной подпольной площадке. Зато похоже, что оператор искал с их помощью реальные дыры в тех же компаниях, чьи разработчики попались на заражённый пакет, а затем подавал находки через легальные bug bounty программы и получал выплату как обычный исследователь.

И вот это, а не сама малварь, делает историю интересной. С малварью всё довольно тривиально: обычный набор трюков supply chain атаки. Любопытно то, что происходит после кражи, и то, что CrowdStrike с высокой уверенностью считает код малвари написанным языковой моделью, а не человеком.

Как пакеты попадают на машину разработчика

PhantomRaven работает с ноября 2022 года, публично о нём заговорили Koi Security и DCODX в октябре 2025-го. За это время оператор (с целым кластером связанных npm-аккаунтов, среди которых jpd12, jpd13, jpd15, npmhell, npmpackagejpd и jpdhackerone11) выложил на npm больше сотни пакетов. Два подтверждённых примера: transform-jsbi-to-bigint и sort-imports-es6-autofix. Названия подобраны так, чтобы отличаться от настоящих на один символ опечатки.

Этот трюк с названиями стоит разобрать отдельно, потому что это уже не классический тайпсквоттинг. Растущая доля таких кампаний строится на слопсквоттинге: имени пакета, которого не существует в реестре до тех пор, пока его не зарегистрирует злоумышленник, но которое всё равно всплывает, потому что его подсказал разработчику AI-ассистент. Спросите модель про библиотеку для задачи X, и она иногда с полной уверенностью придумает правдоподобно звучащее название, которого никогда не было. Кто зарегистрирует его первым на npm, тот оказывается прямо на пути установки у каждого, кто доверился подсказке без проверки. Мы не можем утверждать, что именно так была засеяна конкретно эта кампания, а не через обычные опечатки, но паттерн укладывается в общий тренд. И это ещё один повод не относиться к автодополнению пакетного менеджера или подсказке ассистента как к истине в последней инстанции.

А выживать в реестре годами пакетам помогает техника, которую в отчёте называют remote dynamic dependency. Сам опубликованный пакет почти безобиден: в нём просто installer-хук, который при установке обращается к внешнему серверу и на месте подтягивает настоящую нагрузку. Статический анализ опубликованного кода ничего не находит, потому что вредоносной логики в самом пакете нет. Она приходит позже, с инфраструктуры, которую контролирует атакующий. Эту инфраструктуру он в любой момент может обновить, сменить или вовсе выключить, если почувствует, что к нему подбираются. Кто хоть раз в жизни делал SCA-анализ по работе, сразу узнает эту проблему: можно проверить код, который поставляется в пакете, но нельзя проверить код, который прилетает через тридцать секунд после npm install.

Что реально утекает

Дальше нагрузка снимает почти полную перепись машины разработчика. Из git и npm-конфига вытаскивается почта, из раннеров GitHub Actions, GitLab CI, Jenkins и CircleCI: переменные окружения CI/CD, плюс публичный IP, имя пользователя и метки времени. По отдельности ничего экзотического. Опасность в сумме: дамп переменных окружения из настоящего пайплайна — это редко пароль к одной системе, а чаще ключи сразу к нескольким — токен публикации в реестр, облачные креды с правами на деплой, иногда токен GitHub App с доступом на запись сразу в несколько репозиториев.

Это ровно та же слабость, о которой мы писали в разборе червя ChainDrop, отдельной кампании, которая задела 444 пакета и утащила креды через собственный C2 в смарт-контракте. А ещё раньше был Shai-Hulud, заразивший 1300+ версий пакетов с двумя миллиардами загрузок в месяц. Три разные истории с одной и той же целью — это уже не случайность, а прямое указание на то, где в современной разработке настоящее слабое место. И это не прикладной код, на который тратится основной бюджет безопасности.

Часть, из-за которой должны напрячься bug bounty программы

Здесь PhantomRaven перестаёт быть обычным стилером. По данным отчёта, оператор утверждает, что получил выплаты от не менее девяти организаций из технологического, розничного и гостиничного секторов, а в августе 2025-го сообщил об RCE-уязвимости, найденной через вредоносный npm-пакет, который сам же и опубликовал.

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

Мы не видели текста самих заявок, поэтому не можем утверждать, что все девять выплат прошли именно по этой схеме. Но отсутствие данных PhantomRaven на теневых рынках логов — самый сильный сигнал во всём отчёте. Преступники продают то, что не могут использовать сами. Этот оператор ничего не продал, а значит нашёл украденным данным применение получше.

Наш взгляд. Мы регулярно видим на серверах взломщиков захардкоженные логины, ключи и скрытые пути, ровно те грехи, за которые сами атакующие годами ругают обычных разработчиков. Здесь та же небрежность работает по-другому: не продать украденное, а обналичить его через легальную программу, которая по определению верит новым исследователям на слово.

Малварь, которую написала модель, а не человек

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

Это действительно новый тип форензик-сигнала, и работает он в обе стороны. Пока небрежный, перекомментированный, шаблонный код — это тревожный флаг, который помогает исследователям быстрее атрибутировать кампании. Но этот флаг существует только потому, что автор PhantomRaven не удосужился причесать код после модели. С тем же самым мы сталкиваемся каждый раз, когда разбираем инструменты атакующих, собранные таким способом: рабочий код без единой правки, которую человек внёс бы просто по привычке, а не из осторожности. Операторы таких кампаний обращаются с выводом ассистента буквально так же, как торопливый разработчик в легальной компании: сдают в прод и идут дальше. Следующий, кто потратит вечер на чистку комментариев, такого следа не оставит, и атрибуция снова усложнится. Тем, кто решает, сокращает ли ИИ разрыв между защитниками и атакующими или расширяет его, стоит задержаться на этой мысли: прямо сейчас происходит и то, и другое, просто по разные стороны одной кампании.

Что это значит на практике

Дерево зависимостей стоит считать живой поверхностью атаки, а не пунктом, который закрыли один раз при согласовании. Пакет, который выглядел чистым в день апрува, всё равно может подтянуть новый код при каждой установке. Именно эту слепую зону закрывает регулярный аудит DevSecOps-процессов сборочных и install-скриптов, причём делать его нужно на регулярной основе, а не один раз при онбординге.

Долгоживущие ключи с высокими правами не должны лежать там, где их прочитает скомпрометированный ноутбук разработчика. Статичные токены публикации и широкие облачные креды в переменных окружения CI, ровно то, что искала эта малварь. Аудит облачной инфраструктуры быстрее всего покажет, какой реальный радиус поражения у одной украденной переменной CI в вашем окружении, и лучше узнать это заранее, а не по факту.

Если у вас есть программа bug bounty или VDP, стоит добавить в приёмку немного здорового недоверия. Отчёт, который приходит слишком быстро, с нового аккаунта и с неожиданно точными внутренними деталями, заслуживает второго взгляда: как исследователь вообще мог узнать об этом так точно. Мы разбирали похожую слабость пайплайна в материале про взлом JetBrains Cadence через непропатченный TeamCity, и логика та же: лазейка к выплате за баг и лазейка в прод часто оказываются одной и той же дверью. Разница между таким «случайным» отчётом и настоящей проверкой в том, что второй заказываете вы сами и знаете, кто и как её проводит — это то, что даёт обычный пентест.

Стоит считать, что где-то точка входа уже есть, и искать её самостоятельно. Если разработчики тянут пакеты из публичных реестров (а это почти все), честный вопрос не «уязвимы ли мы», а «узнали бы мы, если бы уже были взломаны». Именно на этот вопрос отвечает реагирование на инциденты, поставленное заранее, а не после факта.

Вывод

PhantomRaven ничем не примечателен как эксплойт или как малварь: и то, и другое в 2026 году довольно обыденно. Примечательно то, что здесь замкнулся полный цикл: модель помогает написать инструмент, инструмент собирает настоящий доступ в настоящие компании, а этот доступ конвертируется не в продажу на чёрном рынке, а в легальный, оплаченный доход по bug bounty. Каждый из этих шагов был возможен и раньше сам по себе. Стоит запомнить именно момент, когда они собрались в бизнес-модель одного оператора. И вспомнить об этом в следующий раз, когда отчёт об уязвимости придёт с аккаунта без истории и с ответами, которые появились чуть быстрее, чем должны бы.

← назад в блог