Атака на Axios и поддельный Claude: как доверие к софту превратилось в уязвимость

Вредоносные версии оставались доступными примерно три часа. Google Threat Intelligence Group зафиксировала активность с 00:21 до 03:20 по всемирному координированному времени (UTC) 31 марта; другие отчеты описывают сопоставимое окно продолжительностью от двух до трех часов.

Axios — одна из наиболее распространенных JavaScript-библиотек. Разные источники оценивают ее популярность в 80–100 и более миллионов загрузок npm в неделю, хотя конкретные цифры расходятся. Даже короткий период доступности зараженных релизов поэтому создавал значительный радиус поражения: пакеты могли автоматически попасть на компьютеры разработчиков, в системы CI/CD и корпоративные сборочные среды.

Как злоумышленники использовали аккаунт мейнтейнера

Публичные материалы указывают прежде всего на захват аккаунта или учетных данных сопровождающего, а не на уязвимость в самой библиотеке Axios. Один из отчетов говорит об использовании давно действовавшего токена доступа npm ведущего мейнтейнера; другие описывают ситуацию более обобщенно — как компрометацию учетной записи или учетных данных для публикации пакетов.

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

Что делала вредоносная зависимость

plain-crypto-js@4.2.1 выглядела как обычная зависимость, но была создана для запуска скрипта postinstall. Он обращался к серверу управления и загружал вторую стадию вредоносной программы, адаптированную под операционную систему устройства.

Таким образом, пользователю не нужно было запускать явно подозрительный исполняемый файл. Достаточно было установить зависимость в момент, когда зараженные версии находились в реестре. Специалисты рекомендуют считать потенциально скомпрометированными все системы, на которых устанавливался Axios версий 1.14.1 или 0.30.4.

Кто стоял за атакой на Axios

Атрибуция операции пока не выглядит окончательно установленной. В одних публикациях ее связывают с северокорейскими группировками, включая BlueNoroff или близкие к ней кластеры; Microsoft приписала компрометацию группе Sapphire Sleet.

Эти версии не следует преподносить как единый подтвержденный вывод. Сходство кода, инфраструктуры и методов работы может указывать на возможного исполнителя, но само по себе не доказывает, какая именно группа провела атаку. Наиболее осторожная формулировка такова: в инциденте были задействованы захваченный аккаунт сопровождающего, зараженные релизы Axios и кроссплатформенный RAT, тогда как ответственность конкретной группировки остается предметом разных публичных оценок.

Как SilverFox маскировала вредоносное ПО под Claude

SilverFox выбрала другой путь проникновения в организации: группировка распространяла поддельные приложения Claude для Windows, macOS и Linux. Кампания затронула организации промышленного, консалтингового, торгового и транспортного профиля в Индии, Индонезии, Южной Африке и России.

Речь шла не о настоящих установщиках Claude, а о программах, имитировавших бренд Anthropic. Сценарий атаки был рассчитан на реалистичную рабочую ситуацию: сотрудник ищет инструмент на базе ИИ, скачивает приложение, которое выглядит знакомо, и вместо полезной программы устанавливает вредоносное ПО. По данным Kaspersky, активность SilverFox наблюдалась несколькими волнами начиная с декабря 2025 года.

От фишинга под видом налоговой проверки к ИИ-приманке

Ранее SilverFox использовала фишинговые письма на налоговую тему. В январе и феврале 2026 года исследователи зафиксировали более 1 600 вредоносных сообщений, которые выдавали себя за официальные уведомления о налоговых проверках или предлагали открыть список налоговых нарушений.

Канал доставки изменился, но принцип остался прежним. Налоговое уведомление играет на ощущении срочности и официальности, а брендированный ИИ-инструмент — на удобстве и актуальности. В обоих случаях пользователя подталкивают открыть вложение, скачать архив или установить программу до того, как он успеет проверить источник.

SilverFox применяла многоступенчатую схему доставки и разделяла инфраструктуру для разных этапов атаки. Это может усложнить защиту: блокировка одного домена или индикатора не обязательно перекрывает всю цепочку проникновения.

Общий вывод: доверие стало частью поверхности атаки

Axios и SilverFox атаковали разные отношения доверия:

• Доверие к сопровождающему. Релизы Axios выглядели опубликованными авторизованным владельцем пакета.
• Доверие к зависимостям. Менеджер пакетов воспринимал вредоносную библиотеку как часть обычного процесса установки.
• Доверие к бренду. Поддельные установщики Claude использовали узнаваемое имя Anthropic.
• Доверие к рабочему процессу. Разработчики и сотрудники выполняли привычные действия — обновляли зависимости или устанавливали продуктивное приложение.

Атака на Axios показывает, почему короткое окно доступности не означает низкий риск. Сборки и задания CI/CD запускаются автоматически, поэтому число затронутых систем не ограничивается людьми, которые вручную проверяли релиз. Кампания SilverFox демонстрирует тот же принцип на конечных устройствах: быстрое распространение ИИ-инструментов создает для злоумышленников убедительные новые приманки.

Что организациям стоит сделать

Для проверки последствий атаки на Axios следует проанализировать lock-файлы, манифесты пакетов, журналы сборки, кэши и перечни зависимостей. В них нужно искать axios@1.14.1, axios@0.30.4 и plain-crypto-js@4.2.1. Любой компьютер, на котором зараженная версия устанавливалась в период доступности пакетов, необходимо проверить на наличие загруженных вредоносных компонентов, механизмов закрепления и утекших учетных данных. Рекомендации по инциденту советуют считать такие системы потенциально скомпрометированными.

Для ИИ-приложений организациям стоит:

• разрешать установку настольных программ только из одобренных каналов;
• проверять издателя и домен загрузки;
• блокировать или помещать в карантин несанкционированные установщики;
• отслеживать появление новых ИИ-инструментов в корпоративной среде.

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

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