CPU-Z i HWMonitor to narzędzia, które informatycy, administratorzy systemów i entuzjaści sprzętu pobierają bez zastanowienia. Znają je od lat. Wiedzą gdzie znaleźć plik. Ufają stronie cpuid.com z tego samego powodu, z którego ufają większości oprogramowania, którego używają od dekady — bo nigdy nie było powodu, żeby nie ufać.
9 kwietnia 2026 roku, przez niecałe dziewiętnaście godzin, ten mechanizm zaufania działał przeciwko nim.
Co się wydarzyło
Ktoś uzyskał dostęp do pobocznego interfejsu programistycznego w infrastrukturze CPUID — pobocznej funkcji, jak określił to sam producent w oświadczeniu na platformie X. Nie złamał podpisanych plików wykonywalnych. Nie przejął całego serwera. Zmienił tylko jedno: adresy URL, pod które prowadził oficjalny serwis do pobrania oprogramowania.
Od mniej więcej 15:00 UTC 9 kwietnia do 10:00 UTC 10 kwietnia ktokolwiek wchodził na cpuid.com i klikał pobierz dla CPU-Z, HWMonitor, HWMonitor Pro lub PerfMonitor — dostawał złośliwy plik. Nie ze spreparowanej kopii strony, nie z podrobionej domeny. Z oficjalnego adresu. Przeglądarka raportowała właściwy URL, strona wyglądała znajomo, nazwa pliku była przekonująca.
Kaspersky szacuje, że złośliwą wersję pobrało ponad 150 osób. Wśród nich były organizacje z sektorów handlu detalicznego, produkcji, doradztwa, telekomunikacji i rolnictwa — głównie w Brazylii, Rosji i Chinach.
Jak działało złośliwe oprogramowanie
Archiwum, które trafiało do ofiar, zawierało legalne, podpisane pliki wykonywalne CPUID. Obok nich znajdował się jeden dodatkowy plik: złośliwa biblioteka cryptbase.dll umieszczona w tym samym katalogu co aplikacja.
Mechanizm jest klasyczny, ale skuteczny. System Windows przy wczytywaniu bibliotek DLL przeszukuje najpierw katalog, z którego uruchamiana jest aplikacja — dopiero potem katalogi systemowe. Legalna biblioteka cryptbase.dll siedzi głęboko w systemie; wersja umieszczona przez atakujących obok pliku HWMonitor ładowała się pierwsza. Aplikacja działała normalnie. W tle zaczynał działać złośliwy kod.
Łańcuch uruchomienia był pięcioetapowy, działający wyłącznie w pamięci — bez zapisywania pośrednich etapów na dysku. Każdy etap odszyfrowywał i uruchamiał kolejny przez odbicie PE, szyfrowanie XOR i warstwowe transformacje bitowe. Ostateczny ładunek kontaktował się z serwerem sterującym welcome[.]supp0v3[.]com i przesyłał metadane o zainfekowanej maszynie — rodzaj programu, z którego pochodziło zakażenie, i numer kampanii.
Tym ostatecznym ładunkiem był STX RAT — trojan zdalnego dostępu z rozbudowanymi możliwościami kradzieży danych: HVNC, rejestrowanie naciśnięć klawiszy, przechwytywanie ekranu, eksfiltracja plików, uruchamianie kodu w pamięci, tunelowanie ruchu. Głównym celem były dane uwierzytelniające przechowywane w przeglądarkach — złośliwy kod próbował między innymi uzyskać dostęp do interfejsu COM przeglądarki Chrome, żeby skopiować i odszyfrować zapisane hasła.
To nie był jednorazowy atak
Jest jeden szczegół, który zmienia charakter tej historii z incydentu w sygnał.
Infrastruktura serwerów sterujących użyta w tym ataku — ta sama domena supp0v3[.]com — była wcześniej wykorzystana w kampanii z marca 2026 roku, gdzie złośliwy kod był dystrybuowany przez sfałszowane instalatory FileZilla. Kaspersky wprost określił to jako błąd operacyjny atakujących: ponowne użycie tej samej infrastruktury i łańcucha zakażenia pozwoliło powiązać oba przypadki.
Firma analityczna Breakglass Intelligence poszła dalej w czasie wstecz i ustaliła, że ta sama infrastruktura była przygotowywana od co najmniej listopada 2025 roku — na podstawie dat pierwszego pojawienia się podomen. Kompromitacja CPUID nie była przypadkową okazją. Była planowaną operacją, której wykonanie zajęło kilka miesięcy przygotowań.
Cztery odrębne znaczniki kampanii zidentyfikowane w metadanych wywołań serwera sterującego — tbs, tbs2, tbs3, snip — wskazują na to, że atakujący śledzą i segmentują swoje ofiary według źródła zakażenia. To nie jest improwizacja. To jest zorganizowana operacja z jasno określoną infrastrukturą i metodologią.
Poboczny interfejs, nie główny system
Oświadczenie CPUID zawiera zdanie, które warto zatrzymać: incydent wynikał z kompromitacji "pobocznej funkcji (w zasadzie bocznego interfejsu API)", która spowodowała, że główna strona losowo wyświetlała złośliwe odnośniki.
To zdanie opisuje wzorzec, który cyberflux opisywał przy okazji case'u HackerOne i Crunchyroll: atak nie trafia do głównego systemu — trafia do czegoś, co jest z nim połączone, co obsługuje część funkcji, co ma dostęp do wystarczającej ilości danych, żeby wyrządzić poważną szkodę. Poboczny interfejs API, który obsługiwał adresy URL plików do pobrania, nie był centrum operacyjnym CPUID. Był tylko jednym komponentem, który kontrolował jedną funkcję. Ale ta jedna funkcja była tym, na co miliony użytkowników patrzyło decydując, co pobrać.
W klasycznym modelu bezpieczeństwa koncentrujemy się na ochronie głównych systemów. Przypadki takie jak CPUID pokazują, że atakujący coraz częściej szukają komponentów peryferyjnych — tych, które nie są objęte najwyższymi standardami bezpieczeństwa, ale mają wystarczający wpływ na zachowanie głównej usługi.
Zaufanie do źródła, nie do pliku
Jest jeszcze jeden wymiar tego incydentu, który jest ważny z perspektywy tego, jak użytkownicy myślą o bezpieczeństwie pobierania oprogramowania.
Podpisane pliki wykonywalne CPUID nie zostały zmodyfikowane. Jeśli ktoś sprawdziłby podpis cyfrowy pobranego pliku HWMonitor.exe — byłby prawidłowy. Złośliwy kod nie był w pliku wykonywalnym. Był w dodatkowym pliku DLL dołączonym do archiwum.
To jest precyzyjne omijanie jednego z podstawowych mechanizmów weryfikacji, na którym polegają użytkownicy: "jeśli podpis się zgadza, plik jest bezpieczny." Podpis zgadzał się. Aplikacja działała. Dodatkowy plik po cichu robił swoje.
To samo dotyczy narzędzi do automatycznego zarządzania pakietami jak Scoop. Wersje CPU-Z i HWMonitor w repozytorium Scoop Extras zaczęły wcześniej generować błędy weryfikacji skrótów — ale były początkowo traktowane jako typowe rozbieżności haszów. Dopiero powiązanie z szerszym incydentem pokazało, że to były sygnały kompromitacji, a nie losowe błędy.
Kto jest w grupie ryzyka
CPU-Z jest jednym z najpopularniejszych narzędzi diagnostycznych sprzętu na świecie — pobranym setki milionów razy przez całą swoją historię. HWMonitor jest standardowym narzędziem w zestawach administratorów, techników IT i dostawców usług zarządzanych. Wersja przenośna (ZIP bez instalacji) jest regularnie uruchamiana bezpośrednio z pamięci USB na maszynach produkcyjnych — bez przechodzenia przez żadne filtry instalatora.
To oznacza, że złośliwy plik mógł trafić dokładnie tam, gdzie dostęp jest najcenniejszy: na stacje robocze administratorów, do środowisk centrum danych, na maszyny serwisowe z dostępem do wielu systemów. Jeden zainfekowany komputer administratora to wejście do całej infrastruktury, którą zarządza.
Co zrobić jeśli pobierałeś w tym oknie
Jeśli pobierałeś CPU-Z, HWMonitor, HWMonitor Pro lub PerfMonitor ze strony cpuid.com w okolicach 9-10 kwietnia 2026 roku — szczególnie między 15:00 UTC 9 kwietnia a 10:00 UTC 10 kwietnia — należy przyjąć założenie, że maszyna może być zainfekowana.
Złośliwy kod instaluje cztery osobne mechanizmy trwałości: zadanie zaplanowane z wieloletnim harmonogramem, klucz rejestru Run wskazujący na MSBuild.exe z argumentem pliku projektu, skrypty w lokalizacjach startowych. Usunięcie pobranego pliku nie usuwa zakażenia jeśli do niego doszło.
Pliki wskaźnikowe, których obecność sugeruje zakażenie: cryptbase.dll w katalogu aplikacji CPUID (nie w System32), pliki c_3791.proj, CommonBuild.proj, ActiveX.sct, Clippy.sct, autorun.ps1 w lokalizacjach wykonawczych.
Wszystkie hasła przechowywane w przeglądarkach na potencjalnie zainfekowanych maszynach należy traktować jako skompromitowane i natychmiast zmienić — dotyczy to szczególnie kont administratorskich, VPN i poczty.
Podsumowanie
Incydent CPUID nie jest historią o podatności w oprogramowaniu do monitorowania sprzętu. Jest historią o tym, jak zaufanie do nazwy i adresu strony może stać się wektorem ataku — gdy atakujący uzyska dostęp nie do głównego systemu, ale do jednego pobocznego komponentu odpowiedzialnego za dystrybucję.
Oryginalne pliki były czyste. Podpisy się zgadzały. Strona wyglądała normalnie. Złośliwy kod trafił do środka razem z zaufanym narzędziem — dokładnie dlatego, że to narzędzie było zaufane.
To jest różnica między atakiem na bezpieczeństwo systemu a atakiem na zaufanie do systemu. Pierwsze można wykryć narzędziami. Drugiego nie.
Źródła
The Hacker News — pierwotne omówienie incydentu z analizą Kaspersky i eSentire: https://thehackernews.com/2026/04/cpuid-breach-distributes-stx-rat-via.html
CYDERES / Howler Cell — szczegółowa analiza techniczna łańcucha ataku i infrastruktury: https://www.cyderes.com/howler-cell/how-cpuids-hwmonitor-supply-chain-was-hijacked-to-deploy-stx-rat
BleepingComputer — opis incydentu z danymi o ofiarach i telemetrią: https://www.bleepingcomputer.com/news/security/supply-chain-attack-at-cpuid-pushes-malware-with-cpu-z-hwmonitor/
Tom's Hardware — oświadczenie CPUID i reakcja społeczności: https://www.tomshardware.com/tech-industry/cyber-security/hwmonitor-and-cpu-z-developer-cpuid-breached-by-unknown-attackers
