Скрипт установки связывался с инфраструктурой злоумышленников и загружал троян удаленного доступа (RAT) для Windows, macOS и Linux. Поэтому обычное обновление зависимости, сборка проекта или автоматический запуск npm install могли стать первым этапом более масштабной компрометации.

Вредоносные версии оставались доступными примерно три часа. 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.

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

Скрипт установки связывался с инфраструктурой злоумышленников и загружал троян удаленного доступа (RAT) для Windows, macOS и Linux. Поэтому обычное обновление зависимости, сборка проекта или автоматический запуск npm install могли стать первым этапом более масштабной компрометации.

Вредоносные версии оставались доступными примерно три часа. 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.

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