Исследователи нашли как минимум 24 npm-пакета, которые использовались не для атаки на цепочку поставок в привычном смысле, а как бесплатный веб-хостинг для фишинговых редиректов. Для русскоязычной IT-аудитории это неприятный, но полезный сигнал: фишинг через npm теперь маскируется не под сомнительный домен из вчерашней рассылки, а под вполне респектабельную инфраструктуру, которой разработчики доверяют по умолчанию.
По данным BleepingComputer, злоумышленники публиковали в npm пакеты, внутри которых лежали всего два файла: index.html и package.json. Никаких инфостилеров, постинсталлов и привычной supply-chain-экзотики. Смысл был в другом: зеркала npm, включая UNPKG и npmmirror, копируют содержимое пакетов и в ряде случаев позволяют открыть отдельный файл прямо в браузере. В итоге HTML-страница атакующего рендерится с домена вроде unpkg.com, а не с инфраструктуры, которую защитные системы давно бы занесли в черный список.
Эту схему еще в июле заметил исследователь inf0stache: он обнаружил пакет china_airlines, который показывал поддельную страницу проверки в стиле Cloudflare и затем уводил посетителя на вредоносный домен. Позже о той же технике сообщил IntelFusions, а затем OX Security описала уже более широкую кампанию из 24 пакетов. Здесь важна деталь: атакующие не пытались заразить машину разработчика через установку зависимости. Они использовали реестр npm как склад, а его зеркала как CDN и фронтенд для доставки страницы-приманки. Для экосистемы это плохая новость: даже если вредоносный код не исполняется при установке пакета, доверие к привычным каналам доставки контента начинает работать против пользователя.
Сама страница мимикрировала под проверку Cloudflare и встраивала легитимный сервис CAPTCHA Turnstile. То есть снаружи все выглядело почти образцово: знакомый интерфейс, узнаваемый бренд, ожидаемое поведение. Но независимо от того, проходил пользователь проверку или нет, дальше срабатывал сильно обфусцированный JavaScript и отправлял его на другой сайт. Руководитель исследовательской группы OX Security Моше Симан Тов Бустан рассказал BleepingComputer, что в июле ранние версии редиректили на microcloud[.]homes, а в августе использовали login[.]microsofte[.]live. Часть июльских переходов в итоге вела на настоящий Outlook Web Access по адресу outlook.office.com/mail. На первый взгляд это выглядит странно, но логика понятна: цепочка с легитимным финальным адресом помогает отлаживать механику, собирать трафик и не палить инфраструктуру раньше времени.
Позже схема стала аккуратнее. Некоторые пакеты перестали хранить конечный URL прямо в HTML и начали получать его через api.keyval.org — легитимный сервис для хранения данных в формате key-value. Страница загружала зашифрованное значение, расшифровывала его уже в браузере и только потом выполняла редирект. Для атакующего это почти подарок: можно менять точку назначения без перепубликации пакета и без новой активности в npm, которая попала бы в журналы и алерты. В момент исследования OX Security такой механизм перенаправлял пользователей на легитимный сайт ChatGPT, но исследователи отдельно подчеркнули, что значение можно в любой момент заменить на фишинговую страницу, загрузчик малвари или другую вредоносную цель. И это как раз тот случай, когда «сейчас ведет на безобидный сайт» ничего не гарантирует.
От классических supply-chain-атак эта история отличается неприятной практичностью. Обычно защитные команды следят за подозрительными зависимостями, скриптами установки, typosquatting-пакетами и неожиданными изменениями в популярных библиотеках. Здесь пакет может вообще не представлять риска для среды разработки при установке. Риск возникает, когда кто-то открывает HTML-файл через зеркало в браузере, получает страницу с домена, который выглядит легитимно, и доверяет увиденному чуть больше, чем следовало бы. Для SOC-команд и администраторов это отдельная проблема: фильтры, заточенные под блокировку доменов-однодневок, не всегда готовы агрессивно резать трафик к популярным зеркалам npm. А если HTML отдается с респектабельного домена, часть защит просто пожмет плечами.
Для разработчиков и компаний вывод предельно земной. Во-первых, прямые запросы HTML-файлов с доменов зеркал npm больше нельзя считать автоматически безопасными. Во-вторых, внутренние политики веб-фильтрации и secure web gateway стоит пересмотреть: зеркала пакетов нужны не только CI/CD, но и злоумышленникам, которым нравится чужая репутация. В-третьих, обучение сотрудников тоже придется слегка обновить. История про «не переходите по странным ссылкам» уже не закрывает вопрос, когда ссылка ведет на ресурс из мира разработки, а внутри еще и честно встроена настоящая CAPTCHA от Cloudflare. Фишинг через npm работает именно потому, что ломает не технику, а ожидания.
Есть и еще один нюанс, на который указывает OX Security: даже после удаления вредоносного пакета из официального реестра его копии могут оставаться на зеркалах. То есть окно жизни такой приманки не обязано совпадать с окном жизни исходного пакета в npm. Для индустрии это очередное напоминание, что борьба с вредоносными пакетами давно вышла за пределы одного реестра. Теперь вопрос не только в том, что попало в каталог, но и в том, какие вторичные сервисы готовы это раздавать дальше, кэшировать и показывать в браузере без лишних вопросов. Если тренд закрепится, зеркала open source-экосистем станут для атакующих не только каналом доставки кода, но и удобной площадкой для размещения обманчиво легитимного веб-контента. Подробнее о кампании пишет .