Атака на Axios у npm і підроблені застосунки Claude оголили нову проблему довіри до програм

Заражені версії залишалися доступними приблизно три години. Google Threat Intelligence Group зафіксувала активність з 00:21 до 03:20 UTC 31 березня, тоді як інші звіти описують схоже вікно тривалістю від двох до трьох годин.

Axios є однією з найпоширеніших JavaScript-бібліотек: різні джерела оцінюють її використання на рівні приблизно від 80 мільйонів до понад 100 мільйонів завантажень на тиждень. Оцінки різняться, але в обох випадках потенційний радіус ураження залишається значним.

Як було використано акаунт мейнтейнера

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

Ця різниця важлива. Атака перетнула межу довіри між повноваженнями мейнтейнера та процесом випуску пакетів у npm. Оскільки заражені релізи були опубліковані через легітимний акаунт, розробники й автоматизовані системи мали менше підстав сприймати їх як підозрілі.

Що робила шкідлива залежність

plain-crypto-js@4.2.1 маскувалася під звичайну залежність, але фактично існувала для запуску скрипта postinstall. Він звертався до командного сервера, а потім завантажував другий етап шкідливого навантаження, підібраний для операційної системи хоста.

Отже, розробнику не потрібно було власноруч запускати очевидно підозрілий виконуваний файл. Достатнім міг бути звичайний запуск встановлення залежностей протягом періоду доступності заражених версій. Фахівці з безпеки радять вважати потенційно скомпрометованими всі системи, на яких було встановлено одну з цих версій Axios.

Чи стояла за атакою BlueNoroff

Атрибуція поки що не є остаточно встановленою. Частина публікацій пов’язує операцію з північнокорейськими угрупованнями, зокрема BlueNoroff або спорідненими кластерами, тоді як Microsoft назвала відповідальним угруповання Sapphire Sleet.

Тому ці оцінки не варто подавати як одну підтверджену версію. Подібність коду, інфраструктури чи методів роботи може бути підставою для гіпотези, але сама по собі не доводить, яка саме група провела атаку.

Найобережніший висновок такий: компрометація Axios включала захоплений акаунт мейнтейнера, заражені релізи та кросплатформений RAT. Водночас відповідальний за операцію зловмисник у публічних оцінках визначається по-різному.

Як SilverFox використовувала підроблені застосунки Claude

SilverFox обрала інший шлях проникнення — поширювала підроблені застосунки Claude для Windows, macOS і Linux. Кампанія була спрямована на організації промислового, консалтингового, торговельного та транспортного секторів в Індії, Індонезії, Південній Африці та Росії.

Ці програми лише імітували бренд Claude від Anthropic і не були легітимними інсталяторами. Схема розраховувала на правдоподібний робочий сценарій: працівник шукає AI-інструмент для підвищення продуктивності, завантажує застосунок, який виглядає знайомо, і натомість встановлює шкідливе програмне забезпечення. Kaspersky описує цю кампанію як частину активності SilverFox, яку спостерігають у кількох хвилях із грудня 2025 року.

Від фішингу на тему податків до AI-приманок

Кампанія продовжила попередню тактику SilverFox із фішинговими листами на податкову тематику. У січні та лютому 2026 року дослідники зафіксували понад 1 600 шкідливих листів, які видавали себе за офіційні повідомлення про податкову перевірку або містили нібито списки податкових порушень.

Змінювався канал доставки, але сигнал довіри залишався тим самим. Податкове повідомлення створює відчуття терміновості й авторитетності, а відомий AI-помічник — актуальності та зручності. В обох випадках користувача намагаються підштовхнути відкрити вкладення, завантажити архів або встановити програму до перевірки її походження.

SilverFox застосовувала багатоступеневу модель доставки, використовуючи окрему інфраструктуру для різних етапів проникнення. Це може ускладнювати захисникам блокування або виявлення всього ланцюга атаки за одним доменом чи індикатором.

Спільний урок: довіра теж належить до поверхні атаки

Axios і SilverFox атакували різні довірчі зв’язки:

• Довіру до мейнтейнера: релізи Axios виглядали так, ніби їх опублікував авторизований користувач npm.
• Довіру до залежностей: менеджер пакетів сприйняв шкідливий компонент як частину звичайного процесу встановлення.
• Довіру до бренду: підроблені інсталятори запозичили впізнаваність Claude.
• Довіру до робочих процесів: розробники та працівники виконували рутинні дії — оновлювали залежності або встановлювали продуктивне програмне забезпечення.

Інцидент з Axios показує, чому короткий період доступності не означає низький ризик. Пакети можуть автоматично встановлюватися на машинах розробників, у CI/CD-системах і під час збірок, тому кількість потенційно уражених середовищ не обмежується людьми, які вручну перевіряють кожен реліз.

Кампанія SilverFox демонструє те саме з боку кінцевих пристроїв: популярні категорії програм швидко перетворюються на переконливі приманки для зловмисників.

Що організаціям варто зробити

У випадку Axios потрібно перевірити lock-файли, маніфести пакетів, журнали збірок, кеші та інвентаризацію залежностей на наявність axios@1.14.1, axios@0.30.4 і plain-crypto-js@4.2.1. Кожен комп’ютер, де заражену версію було встановлено в період доступності, слід перевірити на наявність завантажених payload-файлів, несанкціонованої персистентності та викрадених облікових даних. Рекомендації безпеки прямо радять вважати такі середовища потенційно скомпрометованими.

Для AI-програм організаціям варто дозволяти встановлення лише з перевірених каналів, перевіряти видавця та домен завантаження, а також блокувати або поміщати в карантин несанкціоновані інсталятори.

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

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