Дослідницька команда Socket повідомила про виявлення дев’яти шкідливих пакетів у екосистемі NuGet, у які вбудовано логіку відкладеного спрацювання. Активна фаза саботажу закладена на проміжок від 08.08.2027 до 29.11.2028 і націлена на типові операції з базами даних у .NET (SQL Server, PostgreSQL, SQLite), а також на промислову комунікацію з PLC Siemens через бібліотеку Sharp7.
Масштаб кампанії та маскування коду
Пакети публікувалися у 2023–2024 роках користувачем shanhai666. Із 12 викладених пакетів 9 містили шкідливий функціонал, решта були безпечними. Сукупно їх завантажили близько 9,5 тис. разів. За даними Socket, пакети вже видалено з NuGet, однак точна кількість проєктів, куди вони потрапили як залежності, невідома.
Шкідливий код був ретельно замаскований: приблизно 99% функціоналу виглядало та працювало як очікується, тоді як саботаж ховався у невеликій вставці приблизно на 20 рядків. Така тактика різко знижує шанси виявлення під час статичного аналізу чи швидкого рев’ю.
Як працює відкладене спрацювання та імовірнісні збої
Гачки у «methods-extensions» і перевірка дат
Зловмисники інтегрували логіку через C# extension methods, які перехоплювали типові виклики до БД та до промислових контролерів. При кожному зверненні код перевіряв системну дату на попадання у «вікно активації» серпень 2027 — листопад 2028.
Якщо дата відповідала умовам, запускався імовірнісний тригер: генерувалося число від 1 до 100, і при значенні понад 80 застосунок отримував примусове завершення процесу через Process.GetCurrentProcess().Kill(). Тобто приблизно з 20% імовірністю аварія виглядає як випадковий збій.
Цільові платформи: SQL Server, PostgreSQL, SQLite і промислові PLC
Sharp7Extend: точковий удар по ICS/OT
Найбільшу увагу дослідників привернув пакет Sharp7Extend, що маскується під розширення популярної бібліотеки Sharp7 для Ethernet-комунікацій із PLC Siemens. Розрахунок зловмисників очевидний: приставка «Extend» підвищує довіру в розробників, які шукають додаткові можливості до відомого компонента.
Для клієнтів PLC пакет реалізовує кілька сценаріїв саботажу: миттєвий розрив з’єднання з імовірністю 20% (діє до 06.06.2028), спробу прочитання відсутнього конфігураційного параметра (гарантований збій ініціалізації) та створення внутрішнього фільтра із затримкою 30–90 хвилин, після чого 80% операцій запису у PLC цілеспрямовано псуються. Комбінація «моментального» і «відкладеного» впливу формує багаторівневу атаку на ланцюг постачання з потенційним впливом на технологічні процеси в ICS/OT.
Чому виявити та розслідувати таку атаку складно
Зміщення активації на роки вперед та імовірнісний характер срацювання ускладнюють як детектування, так і форензику. На момент спрацювання залежності можуть змінити власників, команди або середовище експлуатації. У промислових системах такі інциденти часто списують на «нестабільність обладнання» чи рідкісні помилки ПЗ, що розмиває причинно-наслідковий зв’язок.
Подібні прийоми узгоджуються з трендом у ланцюгах постачання: від event-stream у npm до компрометації ua-parser-js і нещодавньої історії зі xz. Спільний знаменник — мінімальна вставка коду, довіра до екосистеми пакетів та зсув атаки «вправо» на етап експлуатації.
Практичні кроки для зниження ризиків у ланцюгу постачання ПЗ
Socket радить негайно перевірити кодову базу й артефакти збірок на наявність згаданих пакетів і при виявленні третирувати систему як ймовірно скомпрометовану. Додатково варто:
- провести інвентаризацію залежностей і сформувати SBOM із фіксацією версій;
- впровадити version pinning, приватні фіди/дзеркала, перевірку цілісності артефактів;
- посилити рев’ю стороннього коду, зокрема extension methods та сторонні хуки у критичних шляхах виконання;
- налаштувати поведінковий моніторинг і журналювання для раптових завершень процесів та аномалій у транзакціях БД/PLC;
- регулярно виконувати ретроспективний аналіз збірок і залежностей, підключити безперервне сканування на рівні CI/CD.
Виявлена кампанія підтверджує, що атаки на екосистеми пакетів стають більш прихованими і націленими на критичні процеси. Командам варто вже зараз закріпити «чисті» стани середовищ, переглянути залежності та автоматизувати контроль довіри до пакетів. Чим раніше запровадите SBOM, pinning і моніторинг, тим швидше зможете локалізувати та нейтралізувати подібні «бомби уповільненої дії» у майбутньому.
