Офіційні клієнтські бібліотеки для протоколу dYdX v4 в екосистемах npm і PyPI були використані як канал доставки шкідливого коду. Атака націлена насамперед на розробників і користувачів, які інтегруються з протоколом, та поєднує дві критичні загрози: крадіжку seed-фраз криптогаманців і встановлення RAT-трояна для прихованого віддаленого доступу до систем.
Supply chain-атака на офіційні клієнти dYdX v4 в npm та PyPI
За даними компанії Socket, зловмисники скомпрометували два ключові пакети, що використовуються для роботи з dYdX v4 – підписання транзакцій, виставлення ордерів і керування гаманцями:
Компрометовані версії:
npm (@dydxprotocol/v4-client-js): 3.4.1, 1.22.1, 1.15.2, 1.0.31
PyPI (dydx-v4-client): 1.1.5post1
Шкідливі релізи публікувалися через офіційні облікові записи dYdX в реєстрах, що вказує насамперед на компрометацію облікових записів розробників, а не на вразливості самих платформ npm чи PyPI. Це класичний приклад supply chain-атаки, коли зловмисник вбудовується у ланцюг постачання ПЗ та використовує довіру до “офіційних” пакетів.
З огляду на те, що сумарний торговий обсяг dYdX перевищує 1,5 трлн доларів, а добові обсяги оцінюються у сотні мільйонів, компрометація клієнтських бібліотек має стратегічне значення для безпеки всієї криптовалютної екосистеми навколо протоколу.
Шкідливий JavaScript у npm: крадіжка seed-фраз і фингерпринтинг пристроїв
У пакеті @dydxprotocol/v4-client-js шкідливий код було вбудовано у файли registry.ts та registry.js — саме ті модулі, що гарантовано виконуються при типовому використанні клієнта. Модифікована логіка перехоплювала seed-фрази криптогаманців та доповнювала їх цифровим відбитком пристрою (fingerprint).
Зібрані дані відсилалися на домен dydx.priceoracle[.]site, стилізований під легітимну інфраструктуру dYdX за допомогою тайпсквотингу (схожого написання на офіційний домен dydx.xyz). Поєднання seed-фраз із фингерпринтом дає зловмисникам змогу:
• ідентифікувати жертв при повторних компрометаціях;
• відокремлювати “цінні” акаунти для прицільних атак;
• корелювати викрадені дані з активністю в блокчейні.
RAT-троян у PyPI: прихований віддалений контроль над середовищем розробника
У Python-пакеті dydx-v4-client функціонал був ще агресивнішим. Окрім крадіжки seed-фраз, всередину коду інтегрували RAT (Remote Access Trojan), який активується автоматично одразу після імпорту бібліотеки та працює як фоновий потік.
Кожні 10 секунд троян встановлює з’єднання з тим самим керувальним доменом dydx.priceoracle[.]site, отримує довільний Python-код та виконує його в окремому процесі без видимого виводу. Для авторизації використовується жорстко зашитий токен:
490CD9DAD3FAE1F59521C27A96B32F5D677DD41BF1F706A0BF85E69CA6EBFE75
У середовищі Windows задіяно прапорець CREATE_NO_WINDOW, що дозволяє запускати процес без консолі та суттєво ускладнює візуальне виявлення активності трояна традиційними засобами моніторингу.
Ризики RAT-трояна в інфраструктурі розробників
Отримавши такий рівень доступу, зловмисники фактично мають приховану віддалену консоль у контурі розробки чи експлуатації. Потенційні сценарії включають:
• виконання довільного Python-коду з правами поточного користувача;
• крадіжку SSH-ключів, API-токенів, облікових даних до CI/CD;
• вивантаження вихідного коду та внутрішніх інструментів;
• встановлення додаткових бекдорів і шкідливого ПЗ;
• модифікацію критично важливих репозиторіїв;
• горизонтальне переміщення мережею (lateral movement).
Ознаки добре спланованої кампанії та попередні інциденти з dYdX
Структура атаки демонструє глибоке розуміння архітектури пакетів. У JavaScript-версії були змінені registry.ts / registry.js, у Python — account.py, тобто модулі, які гарантовано викликаються в типовому робочому циклі. У випадку PyPI шкідливий код додатково пройшов кілька раундів обфускації, що ускладнює аналіз та виявлення.
Socket відзначає, що атакувальник використовував узгоджений набір доменів ексфільтрації, токенів і логіки фингерпринтингу, але адаптував техніку для різних екосистем (JavaScript і Python). 28 січня 2026 року команда dYdX публічно підтвердила інцидент і заявила, що шкідливий код стосувався лише версій у npm та PyPI; вихідний код і релізи в репозиторії dydxprotocol на GitHub вважаються чистими.
Це не перший цільовий інцидент проти інфраструктури dYdX. У 2022 році було скомпрометовано npm-акаунт співробітника, що призвело до публікації шкідливих пакетів, а в 2024-му сайт dYdX v3 постраждав від DNS hijacking з перенаправленням користувачів на фішинговий ресурс. Сукупність епізодів демонструє довготривалу кампанію, орієнтовану на зловживання довіреними каналами дистрибуції: DNS, реєстрами пакетів та офіційними обліковими записами.
Практичні рекомендації з кібербезпеки для розробників і власників криптоактивів
Інцидент із dYdX v4 ще раз підкреслює: надійний захист криптоактивів неможливий без системного контролю ланцюга постачання ПЗ. Командам розробки та безпеки доцільно впровадити:
• жорсткий захист облікових записів у npm, PyPI, GitHub (FIDO2, апаратні ключі, мінімальні права доступу);
• автоматизований аналіз залежностей (SCA), порівняння нових версій пакетів і пошук аномалій у коді;
• відтворювані збірки (reproducible builds) та локальні дзеркала довірених бібліотек;
• моніторинг вихідних з’єднань розробницьких машин на предмет підозрілих доменів.
Користувачам криптовалют варто не зберігати значні суми на гаманцях, seed-фрази яких будь-коли вводилися або оброблялися у середовищі розробки, а також періодично перевіряти встановлені інструменти та залежності. Чим раніше практики безпеки ланцюга постачання стануть стандартом, тим важче буде реалізувати подібні supply chain-атаки проти екосистем на кшталт dYdX у майбутньому.
