- Атака на CPUID скомпрометувала API завантаження, а не підписані бінарні файли, що дозволило перенаправити легітимні завантаження CPU-Z та HWMonitor на шкідливі інсталятори.
- Ланцюг зараження використовував захоплення DLL-бібліотек (CRYPTBASE.dll), виконання в пам'яті та розширену інфраструктуру C2 для розгортання STX RAT з крадіжкою облікових даних та віддаленим доступом.
- Цей інцидент підкреслює зростаючу загрозу атак на ланцюги поставок, коли метою є інфраструктура розповсюдження програмного забезпечення, а не вихідний код.
- Користувачі та організації повинні посилити контроль: перевіряти завантаження, не ігнорувати сповіщення антивіруса та посилити процеси CI/CD та безпеку API та серверів.
В останні місяці CPUID — компанія, що розробляє такі популярні інструменти, як CPU-Z та HWMonitor — потрапила в заголовки газет про кібербезпеку через атаку на ланцюг поставок , яка глибоко розчарувала тисячі користувачів. Тривожним аспектом є не лише саме шкідливе програмне забезпечення, а й той факт, що все це сталося через завантаження з офіційного веб-сайту, що зловживає величезною довірою технічної спільноти до цих утиліт.
Цей інцидент доповнює інші нещодавні випадки, такі як компрометація програми OpenAI для macOS через маніпуляційну бібліотеку Axios , і підтверджує тривожне усвідомлення: простої перевірки того, чи є веб-сайт «офіційним» або чи підписано виконуваний файл, більше недостатньо, щоб почуватися в безпеці. Зловмисники вдосконалюють свої методи ланцюга поставок, атакуючи саме ту ланку розповсюдження програмного забезпечення, де вона найбільше завдає шкоди.
Що саме сталося з CPUID, CPU-Z та HWMonitor?
CPUID — це компанія-ветеран, заснована наприкінці 90-х років, відома тим, що пропонує безкоштовні утиліти для діагностики та моніторингу обладнання для Windows. CPU-Z надає детальну інформацію про процесор, пам'ять та материнську плату, тоді як HWMonitor використовується для моніторингу температури, напруги та вентиляторів. Ці інструменти повсюдно використовуються в ремонтних майстернях, центрах обробки даних, ігрових системах та тестових середовищах.
У квітні 2026 року офіційний веб-сайт компанії було скомпрометовано в результаті атаки ланцюга поставок , яка вплинула на завантаження CPU-Z та HWMonitor. Критичним аспектом справи є те, що зловмисники отримали доступ не до вихідного коду чи підписаних бінарних файлів, які CPUID легально розповсюджує, а до набагато тонкішого компонента: вторинного API, відповідального за керування посиланнями для завантаження та певними внутрішніми робочими процесами.
Між 9 та 10 квітня 2026 року, протягом приблизно шести годин, згідно з деякими джерелами, та до 19 годин, згідно з іншими, більш глибокими аналізами, цей API бічної панелі почав перенаправляти легітимні запити на завантаження до інфраструктури, контрольованої зловмисниками. Користувач відвідував cpuid.com, натискав офіційну кнопку завантаження, і, на перший погляд, все здавалося нормальним.
Протягом цього часу кілька користувачів помітили дивну поведінку: інсталятори з незвичайними назвами, такими як «HWiNFO_Monitor_Setup.exe» замість типового hwmonitor_*.exe, та попередження антивіруса, які багато людей, на жаль, ігнорували, вважаючи їх хибнопозитивними. Саме тоді правда почала розкриватися.
За оцінками, потенційно величезна кількість користувачів може бути вразлива , оскільки CPU-Z та HWMonitor не є нішевими програмами: вони накопичили десятки мільйонів історичних завантажень і щодня використовуються технічними спеціалістами, системними адміністраторами, оверклокерами та ІТ-фахівцями. Періоду атаки тривалістю лише кілька годин, розподіленого по різних часових поясах світу, достатньо, щоб спричинити серйозні наслідки.
Ланцюги поставок: чому ця атака така небезпечна
Особливо тривожним у випадку з CPUID є те, що це була хірургічна атака на ланцюжок розповсюдження програмного забезпечення , а не на оригінальні бінарні файли. Іншими словами, проблема полягала не в репозиторії коду чи підписаних виконуваних файлах, а в інфраструктурі, яка вирішує, який файл доставляється кожному користувачеві.
Ця закономірність узгоджується з чіткою тенденцією останніх років: атаки на ланцюжок постачання програмного забезпечення , коли зловмисник намагається безпосередньо скомпрометувати не кожен пристрій кінцевого користувача, а спільну ланку, яка доставляє програмне забезпечення тисячам або мільйонам машин. Такі випадки, як SolarWinds та Codecov, вже продемонстрували, наскільки руйнівними можуть бути маніпуляції з одним компонентом на шляху розповсюдження.
Зловмисники зазвичай використовують вразливості безпеки в API, веб-серверах або потоках CI/CD для впровадження шкідливих посилань, маніпульованих бібліотек або троянських корисних навантажень. CPUID визначив «додаткову функцію» або «додатковий API» як точку входу, а не центральне сховище чи систему підпису. Цей API дозволив би зловмисникам змінювати пункт призначення посилань для завантаження, не помічаючи при цьому нічого підозрілого у своєму браузері.
Подібний інцидент нещодавно стався з OpenAI, коли робочий процес GitHub Actions , який підписав додаток macOS, завантажив шкідливу версію бібліотеки Axios 31 березня. У цьому випадку OpenAI довелося відкликати сертифікат додатка macOS як превентивний захід, незважаючи на запевнення користувачів, що жодні дані користувачів чи внутрішні системи не були скомпрометовані. Це ще один приклад того, як одна слабка ланка в автоматизованому процесі може забруднити весь ланцюг.
З технічної точки зору, ці вторгнення зазвичай використовують такі вразливості, як слабкі облікові дані, API без надійної автентифікації, застарілі сервери або відсутність моніторингу в критично важливих системах. Ще більш тривожним є те, що вони часто залишаються непоміченими протягом кількох годин або днів, поки спільнота або інструменти безпеки не почнуть масово виявляти аномальну поведінку.
Як поширювалося шкідливе програмне забезпечення у випадку CPUID
Згідно з різними публічними аналізами, в інциденті з CPUID було виявлено два тісно пов'язані варіанти ланцюжка атак. У найбільш задокументованих випадках зловмисники розміщували легітимний бінарний файл CPU-Z разом зі шкідливою DLL-бібліотекою в тому ж каталозі встановлення.
Ця DLL-бібліотека, ідентифікована як CRYPTBASE.dll (та сама назва, що й у легітимної бібліотеки Windows), була скомпільована в Zig та використовувала порядок пошуку DLL-бібліотек Windows: перебуваючи в тому ж каталозі, що й легітимний виконуваний файл CPU-Z, система спочатку завантажила шкідливу версію замість оригіналу з C:\Windows\System32. Це класичний випадок захоплення DLL-бібліотек.
Після завантаження підробленої DLL-бібліотеки було ініційовано досить складний ланцюжок атак. Шкідливе корисне навантаження виконало другу , зашифровану DLL-бібліотеку безпосередньо в пам'яті за допомогою методів рефлективного впровадження, що дозволило уникнути запису на диск і залишити дуже мало слідів для подальшого аналізу. Така поведінка призвела до того, що деякі просунуті агенти безпеки негайно позначили активність як «виявлено фреймворк проникнення або шелл-код».
Звідти зв'язок із сервером командування та управління (C2) встановлювався через DNS-over-HTTPS до версії 1.1.1.1 , що було розроблено для обходу багатьох традиційних систем моніторингу DNS. Крім того, ланцюжок включав створення таких процесів, як запуск PowerShell csc.exe та cvtres.exe, що абсолютно незвично для такого інструменту, як CPU-Z.
Щоб гарантувати, що інфекція витримає перезавантаження та спроби часткового очищення, шкідливе програмне забезпечення використовувало до трьох надлишкових механізмів персистентності : ключ Run у реєстрі Windows, заплановане завдання, яке запускається кожні 68 хвилин і триває до 20 років, та файли проекту MSBuild, приховані в AppData\Local. Такий підхід надзвичайно ускладнює її видалення, якщо ви не знаєте точно, що шукати.
Фінальне корисне навантаження було ідентифіковано як STX RAT , троян віддаленого доступу з прихованими можливостями VNC, введенням даних з клавіатури та миші, крадіжкою облікових даних з кількох браузерів (Chrome, Firefox, Edge, Brave), вилученням даних Windows Vault та доступом до криптовалютних гаманців. Це було не просто рекламне ПЗ, а бекдор з широким спектром можливостей шпигунства та контролю.
Що шукало шкідливе програмне забезпечення: облікові дані, дистанційне керування та інше
Весь дизайн атаки чітко показує, що основною метою було непомітне викрадення конфіденційної інформації та постійний віддалений доступ , а не безпосередня шкода для користувача (як, наприклад, у випадку програм-вимагачів). Ця відмінність є ключовою, оскільки вона ускладнює виявлення атаки та потенційно робить її більш прибутковою для зловмисників.
Серед можливостей, пов'язаних з STX RAT, та корисного навантаження, виявленого під час інциденту, виділяються кілька функцій, типових для інфо-викрадачів та просунутих RAT : вилучення паролів та файлів cookie, що зберігаються в браузерах, доступ до активних сеансів (електронна пошта, онлайн-банкінг, цифрові магазини), збір системної інформації та можливе підвищення привілеїв у середовищах, де користувач мав високі дозволи.
У деяких звітах також згадується розгортання додаткових корисних навантажень у .NET та використання PowerShell, що знаходиться в пам'яті, для завантаження більшої кількості модулів з віддалених серверів, що є поширеною практикою в кампаніях, що прагнуть модульності : встановлюється відносно легкий перший імплантат, і, як тільки зловмисник підтверджує, що машина цікавить його, завантажуються додаткові компоненти для вилучення певних даних або переміщення по мережі.
Вибір CPU-Z та HWMonitor як векторів не випадковий. Типовий профіль тих, хто встановлює ці інструменти, сильно перекошений у бік ІТ-фахівців, системних адміністраторів та людей з привілейованим доступом до корпоративних мереж. Компрометація одного системного адміністратора з правами домену може мати радикально більший вплив, ніж зараження домашнього користувача без привілеїв.
Таким чином, хоча кількість підтверджених прямих жертв може здаватися відносно низькою (близько ста добре задокументованих випадків, за даними деяких постачальників EDR), потенціал пошкодження в корпоративних середовищах та критично важливих інфраструктурних середовищах був високим. Все, що потрібно одному з цих техніків, це мати облікові дані для серверів, хмарних панелей або мережевих пристроїв, щоб відкрити дуже небезпечні двері.
Як дізнатися, чи це могло вас вразити
Якщо ви завантажили CPU-Z або HWMonitor з офіційного веб-сайту CPUID приблизно 9-10 квітня 2026 року, вам слід швидко перевірити свої завантаження та системи , щоб виключити цю можливість. Немає причин для паніки, але варто перевірити кілька ключових моментів.
Перше, що потрібно перевірити, це назва завантаженого вами файлу . Якщо ваш інсталятор HWMonitor мав дивну назву, наприклад, «HWiNFO_Monitor_Setup.exe» або будь-який інший варіант, який не відповідає звичайному шаблону hwmonitor_*.exe, це серйозний тривожний сигнал. Багато користувачів коментували саме ці невідповідності в назвах на форумах та в соціальних мережах.
По-друге, вам слід перевірити журнали антивіруса на наявність цих дат. Якщо Захисник Windows, Malwarebytes, Kaspersky або інше рішення безпеки видало сповіщення під час завантаження або встановлення, а ви його проігнорували, зараз саме час переглянути цю історію та побачити, що саме було виявлено. Попередження з такими термінами, як «підозрілий», «шкідливе програмне забезпечення» або «ненадійна програма» (PUA), потребують ретельнішого вивчення.
Також варто перевірити історію завантажень вашого браузера , щоб знайти будь-які виконувані файли з cpuid.com за цей час. Якщо ви знайдете щось підозріле, збережіть копію файлу для аналізу (наприклад, завантаживши його на VirusTotal пізніше) та уникайте його повторного запуску за жодних обставин.
Якщо ви більше схильні до технічних питань і маєте обґрунтовані сумніви щодо того, що ваша система може бути скомпрометована, одним із варіантів є завантаження з чистого образу Linux на USB-накопичувачі та сканування диска Windows ззовні . Це не те, що потрібно більшості користувачів, але в критичних середовищах це може допомогти знайти такі файли, як CRYPTBASE.dll, поза System32, незвичайні заплановані завдання або артефакти в AppData.
Рекомендовані кроки, якщо ви завантажили програмне забезпечення у скомпрометоване вікно
Якщо під час перевірки дат та імен файлів ви бачите, що завантажили CPU-Z або HWMonitor саме між 9 та 10 квітня 2026 року, розумно припустити, що існує принаймні розумна ймовірність зараження , і діяти відповідно, навіть якщо аналіз пізніше покаже, що фактичного зараження не було.
Перший крок – видалити уражені версії з Панелі керування Windows або Налаштувань. Немає сенсу зберігати програми, яким ви не довіряєте, поки проводите розслідування. Після видалення також гарною ідеєю буде очистити всі залишки папок у Program Files та AppData, намагаючись не видалити нічого, щодо чого ви не впевнені.
Далі запустіть повне (не швидке) антивірусне сканування вашої системи. Сучасні рішення безпеки, особливо ті, що мають поведінкове виявлення, можуть знаходити сліди цього типу шкідливого програмного забезпечення, навіть якщо частина корисного навантаження знаходилася лише в пам’яті. Якщо можливо, використовуйте комбінацію оновленого Захисника Windows та додаткового інструменту, такого як Malwarebytes, для отримання другої думки.
Водночас слід враховувати, що будь-які облікові дані, що зберігаються в браузері протягом цього періоду, можуть бути скомпрометовані. Це означає, що бажано змінити паролі для електронної пошти, онлайн-банкінгу, хмарних сервісів та будь-яких критично важливих платформ, до яких здійснюється доступ через Chrome, Firefox, Edge або Brave. Зробіть це після сканування та очищення системи, а не раніше.
Також гарною ідеєю буде переглянути історію підозрілої активності у ваших основних облікових записах (наприклад, Gmail, Amazon, Dropbox або на панелі керування вашого банку), щоб побачити, чи були вхідні дані з незвичайних місць або пристроїв. А якщо ви зберігали дані картки у своєму браузері, має сенс повідомити свій банк, щоб вони могли стежити за будь-якою незвичайною активністю або, в крайньому випадку, запросити заміну картки.
Відповідь CPUID та поточний стан ваших завантажень
Після того, як інцидент став відомим, CPUID опублікувала заяви, в яких пояснила, що атака вплинула на вторинну функцію її інфраструктури — відомий сторонній API — і що підписані бінарні файли та репозиторії коду не були скомпрометовані. Вони заявили, що виявили та виправили вразливість у скомпрометованому API та відновили нормальну роботу платформи завантаження.
Згідно з наявною інформацією, поточні виконувані файли CPU-Z та HWMonitor знову належним чином підписані та обслуговуються з чистої інфраструктури . Станом на сьогодні завантаження цих інструментів з офіційного веб-сайту, тепер, коли проблему вирішено, вважається безпечним, за умови дотримання звичайних запобіжних заходів для будь-якого програмного забезпечення, отриманого з Інтернету.
Незважаючи на це, інцидент залишає певний рівень недовіри. Багато організацій ставлять під сумнів, чи є сенс продовжувати розгортати сторонні утиліти, такі як CPUID, на виробничих серверах або в надзвичайно чутливих середовищах . У деяких випадках вони обирають добре перевірені альтернативи з відкритим кодом (такі як lm-sensors на Linux або OpenHardwareMonitor) або нативні інструменти від постачальників хмарних технологій та обладнання.
Зі свого боку, CPUID доведеться працювати над відновленням довіри спільноти , не лише виправляючи конкретний інцидент, але й демонструючи, що вони посилили свою внутрішню безпеку: регулярні аудити, суворіший контроль доступу, моніторинг аномалій завантаження та публікація перевірених хешів для кожної версії, серед інших заходів.
Загалом, ці типи атак підштовхують галузь до впровадження таких практик, як SBOM (Software Bill of Materials - Специфікація матеріалів програмного забезпечення) , які вимагають документування всіх компонентів програмного забезпечення, та моделей архітектури нульової довіри, де внутрішній код навіть не вважається надійним, якщо він не проходить постійний контроль.
Ключові уроки для користувачів та галузі
Інцидент із CPUID — це неприємне нагадування про те, що сліпої довіри офіційному вебсайту більше недостатньо . Зловмисники зрозуміли, що слабкою ланкою часто є не користувач, який натискає на посилання, а інфраструктура розповсюдження, яку ми всі вважаємо безпечною.
Для кінцевих користувачів є кілька ключових висновків. По-перше: не ігноруйте попередження антивіруса лише тому, що файл походить з відомого веб-сайту. Сучасні методи виявлення залежать від поведінки та глобальної репутації; якщо сповіщення з’являється під час завантаження чогось із cpuid.com у певну дату, це цілком може бути ознакою того, що на серверній частині провайдера відбувається щось незвичне.
По-друге: зверніть увагу на очевидні деталі, такі як назва виконуваного файлу . Інсталятор під назвою HWiNFO_Monitor_Setup.exe, коли ви очікували запустити HWMonitor, має одразу викликати підозри. Потрібно дві секунди уваги, щоб запобігти серйозному зараженню.
Для програмних компаній такі інциденти підсилюють необхідність посилення процесів CI/CD, доступу до серверів завантаження та допоміжних API. Інструменти сканування залежностей, такі як Semgrep або інші системи SCA , правила Sigma, що застосовуються до журналів CI/CD, та статичний/динамічний аналіз перед підписанням бінарних файлів, більше не є «приємним» доповненням: вони є необхідними.
Зрештою, спільнота кібербезпеки прагне до більш складних рішень: використання надійних криптографічних бібліотек для забезпечення цілісності та автентичності в процесі підписання, EDR в пам'яті, здатний розривати ланцюжки атак, подібні до тих, що спостерігаються в CPU-Z, та культура, де будь-яка аномалія в масових завантаженнях негайно розслідується , а не ігнорується як окрема помилка.
Все, що сталося з атакою на ланцюг поставок CPUID, чітко показує, що стратегія компрометації дистрибутива, а не безпосередньо вихідного коду, залишається актуальною. Користувачам та організаціям необхідно підвищити планку своєї цифрової гігієни: перевіряти хеші, коли це можливо, звертати увагу на імена файлів та сертифікати, бути пильними, коли бачать знайомий логотип, і, перш за все, швидко реагувати на будь-які підозри, щоб одноразовий інцидент не перетворився на довгострокову проблему.