CPUID-Hack: Trojanisierte CPU-Z- und HWMonitor-Downloads

CPUID, der Hersteller hinter CPU-Z und HWMonitor, hat bestätigt, dass seine Website kurzzeitig kompromittiert war und statt legitimer Downloads trojanisierte Dateien auslieferte. Wichtig für die Einordnung: Nach aktuellem Stand wurden nicht die eigentlichen, signierten Original-Builds manipuliert, sondern die Download-Links auf der Website.

Für Unternehmen ist das mehr als eine kuriose News aus der Hardware-Ecke. Solche Tools landen häufig auf Admin-Workstations, Entwickler-PCs, Helpdesk-Systemen oder Werkstatt-Rechnern und werden oft ad hoc von der Herstellerseite geladen. Genau deshalb ist ein Vorfall wie dieser ein klassischer Supply-Chain- beziehungsweise Watering-Hole-Fall: Wer dem offiziellen Download-Pfad vertraut hat, konnte sich trotz legitimer Quelle Malware einfangen.

Was ist passiert?

Laut CPUID wurde eine Nebenfunktion beziehungsweise Side-API kompromittiert. Dadurch zeigte die Hauptseite für einen begrenzten Zeitraum zufällig bösartige Download-Links an. Die Angaben von CPUID und Kaspersky passen gut zusammen: Kaspersky beobachtete den Austausch legitimer Download-URLs etwa von 9. April 2026, 15:00 UTC bis 10. April 2026, 10:00 UTC.

Betroffen waren nach bisherigem Stand CPU-Z 2.19, HWMonitor 1.63, HWMonitor Pro 1.57 und PerfMonitor 2.04. Die trojanisierten Pakete enthielten laut Kaspersky jeweils ein legitimes signiertes Programm und zusätzlich eine bösartige CRYPTBASE.dll, die über DLL-Sideloading den weiteren Infektionspfad startete.

Die technische Analyse spricht für einen Angriff, der bekannte Infrastruktur und bekannte Malware-Bausteine wiederverwendete. Kaspersky sieht Überschneidungen mit einer früheren Kampagne rund um eine gefälschte FileZilla-Seite; als finale Nutzlast wurde STX RAT identifiziert.

Wer sollte jetzt die Betroffenheit prüfen?

Entscheidend ist weniger, ob Ihr Unternehmen generell CPU-Z oder HWMonitor einsetzt, sondern ob Downloads oder Updates im betroffenen Zeitfenster stattgefunden haben. Das gilt besonders für Systeme, die nicht sauber zentral gemanagt werden:

Kaspersky berichtet von mehr als 150 beobachteten Opfern, überwiegend Privatnutzer, aber auch Organisationen aus mehreren Branchen. Die geographische Häufung lag zwar bei Brasilien, Russland und China, daraus folgt aber keine Entwarnung für andere Regionen: Wer in dem Zeitfenster den manipulierten Pfad getroffen hat, kann betroffen sein.

IOCs und schnelle Checks für die ersten 30 Minuten

Für einen ersten Hunt reichen oft schon Dateinamen, DNS-/Proxy-Treffer und Dateisystemspuren. Kaspersky nennt unter anderem die Domains cahayailmukreatif.web[.]id, pub-45c2577dbd174292a02137c18e7b1b5a.r2[.]dev, transitopalermo[.]com, vatrobran[.]hr sowie Folgekommunikation zu welcome.supp0v3[.]com.

# Quick Check für Downloads und DLL-Artefakte auf einem Windows-Host
# Für Massenprüfungen über EDR/SIEM/Softwareverteilung ausrollen.

$roots = @(
  "$env:USERPROFILE\Downloads",
  "$env:TEMP",
  "$env:LOCALAPPDATA\Temp"
)

$patterns = @(
  "HWiNFO_Monitor_Setup.exe",
  "cpu-z_2.19-en.zip",
  "hwmonitor_1.63.zip",
  "HWMonitorPro_1.57_Setup.exe",
  "PerfMonitor2_Setup.exe",
  "CRYPTBASE.dll"
)

Get-ChildItem -Path $roots -Recurse -Force -ErrorAction SilentlyContinue |
  Where-Object { -not $_.PSIsContainer -and $patterns -contains $_.Name } |
  Select-Object FullName, Name, Length, LastWriteTime |
  Sort-Object LastWriteTime -Descending

Dieser Check ersetzt keine Forensik, gibt aber schnell ein erstes Bild. Wenn Treffer auftauchen, sollten Sie den Host nicht nur neu herunterladen lassen, sondern beweissichernd und nachvollziehbar weiterarbeiten.

Sofortmaßnahmen: sauber reagieren, ohne Aktionismus

Der wichtigste Punkt: Nicht nur neu installieren. Wenn die trojanisierte Variante ausgeführt wurde, kann bereits ein nachgelagerter Loader oder eine RAT aktiv geworden sein. Die Reihenfolge der Maßnahmen ist deshalb wichtiger als Geschwindigkeit um jeden Preis.

Was Unternehmen aus dem CPUID-Vorfall lernen sollten

Der wichtigste Learning ist nicht „Nie wieder CPU-Z“. Das eigentliche Problem ist strukturell: Direkte Einzel-Downloads von Herstellerseiten bleiben in vielen Unternehmen ein blinder Fleck. Gerade kleine Utilities für Diagnose, Remote-Support oder Benchmarks werden häufig außerhalb des klassischen Patch- und Softwareverteilungsprozesses genutzt.

Sinnvolle Gegenmaßnahmen sind deshalb:

• Zentrale Softwarebereitstellung statt ad hoc Downloads durch Endnutzer oder Admins.
• DNS- und Proxy-Logs mit ausreichender Vorhaltezeit, damit kurze Zeitfenster später noch nachvollziehbar sind.
• Hash-, Signatur- oder Paketquellen-Validierung für besonders häufig genutzte Utilities.
• Klare Ausnahmeregeln für Diagnose-Tools auf Admin-Workstations und Werkstattrechnern.