CPUID gehackt, Vertrauen missbraucht: Was der Supply-Chain-Angriff auf CPU-Z und HWMonitor dir sagen sollte

Tools wie CPU-Z oder HWMonitor sind ein bisschen wie der Blick unter die Motorhaube: schnell, praktisch, vertraut. Aber wenn selbst ein etabliertes Diagnose-Tool plötzlich als Trojaner-Taxi endet, ist das ein Reminder mit Presslufthammer:

Vertrauen ist in der IT leider kein Sicherheitskonzept.

Anfang April 2026 wurde die offizielle CPUID-Website kompromittiert. In einem kurzen Zeitfenster zwischen dem 9. und 10. April wurden dort manipulierte Download-Links ausgegeben.

CPUID selbst erklärte, dass nicht die original signierten Dateien kompromittiert waren, sondern ein „secondary feature“, also eine Art Side-API, die für ungefähr sechs Stunden missbraucht wurde und zufällig bösartige Links auf Dritt-Domains ausspielte.

Das klingt erst einmal nach „nur sechs Stunden, wird schon nicht so wild sein“. Leider doch. Genau in diesem Zeitraum haben Nutzer statt CPU-Z, HWMonitor, HWMonitor Pro oder PerfMonitor trojanisierte Installer heruntergeladen.

Analysen von Kaspersky und weiteren Forschern zufolge enthielten diese Pakete eine bösartige CRYPTBASE.dll, die per DLL-Sideloading nachgeladen wurde. Der finale Payload war STX RAT, ein mehrstufiger, speicherresidenter Trojaner mit starker Tarnung und Fokus auf Datendiebstahl.

Und jetzt kommt der Teil, der für IT-Entscheider relevant ist: Solche Angriffe zielen nicht auf „irgendwen“.

Sie treffen genau die Menschen, die mit Admin-Rechten arbeiten, Tools testen, Systeme prüfen oder Software bewerten.

Also die Leute, bei denen ein kompromittierter Download nicht nur einen einzelnen Laptop betrifft, sondern im schlimmsten Fall Identitäten, Sessions, Credentials und damit gleich den Seiteneingang ins Unternehmen.

Das macht Supply-Chain-Angriffe so fies: Sie nutzen nicht nur Technik, sondern unsere Gewohnheit. „Offizielle Website“ klingt schließlich nach „sicher“. 

Was genau passiert ist

Nach aktuellem Stand wurden die Download-Links auf der CPUID-Seite auf fremdgehostete Dateien umgebogen. Mehrere Berichte nennen Cloudflare-R2-Storage als Zwischenstation für die manipulierten Dateien.

Nutzer bemerkten teils verdächtige Anzeichen wie falsche Dateinamen oder sogar russischsprachige Installationsdialoge. Das ist ungefähr so vertrauenerweckend wie ein Paketbote, der deine Kontodaten wissen will. 

Die Schadsoftware lief über eine Sideloading-Kette, zu einer C2-Infrastruktur auf ungewöhnlichen High Ports funkte und dass sich Verbindungen zu früheren Kampagnen zeigten, darunter eine FileZilla-bezogene Verteilung mit ähnlicher Infrastruktur und ähnlicher Technik.

Beim Angriff, so die Hypothese von Low Level, könnte ein älteres Apache-Setup beziehungsweise dessen Rewrite-Mechanik beim Umleiten auf Konfigurationsdateien eine Rolle gespielt haben – ausdrücklich als moderate Einschätzung, nicht als gesicherte Abschlussursache.

Warum dieser Vorfall größer ist als „bloß Malware auf einer Website“

Weil ein Grundproblem jedes Unternehmen betrifft, das Drittanbieter-Software nutzt. Also praktisch jedes Unternehmen.

Wenn Angreifer es schaffen, an einem vertrauenswürdigen Punkt der Software-Lieferkette anzusetzen, dann greifen klassische Vorsichtsregeln nicht.

„Nur von der Herstellerseite herunterladen“ ist sinnvoll, aber eben nicht unfehlbar. „Datei ist signiert“ hilft, aber auch das schützt nicht, wenn der Installer drumherum manipuliert oder ein legitimer Prozess für DLL-Sideloading missbraucht wird.

Hinzu kommt: Der CPUID-Fall steht nicht isoliert. Mehrere Analysen sehen Überschneidungen mit einer früheren FileZilla-Kampagne und verorten die Aktivität in einer länger laufenden Serie, die mindestens bis 2025 zurückreicht.

Selbst wenn die Attribution noch unscharf bleibt, ist das Muster klar: wiederverwendete Infrastruktur, ähnliche Malware-Komponenten, ähnliche Tarnung. Das riecht nicht nach Zufall, sondern nach System. 

Was IT-Entscheider daraus lernen sollten

1. Vertrauenswürdige Quelle heißt nicht automatisch vertrauenswürdiger Download

Viele Sicherheitskonzepte behandeln „offizielle Herstellerseite“ fast wie ein Gütesiegel. Der CPUID-Vorfall zeigt, dass du an dieser Stelle trotzdem prüfen musst: Hashes, Signaturen, EDR-Erkennung, Download-Reputation, Sandbox-Checks und notfalls Freigabeprozesse auch für Admin-Tools.

Sonst rutschen kleine Tools gern an den Kontrollen vorbei, weil sie „nur mal eben schnell“ installiert werden. Und genau dieses „mal eben“ ist der Lieblingsmoment der Angreifer. 

2. Admin- und Helfer-Tools sind Hochrisiko-Ziele

CPU-Z und HWMonitor sind keine Exoten. Sie werden von Technikern, Enthusiasten, Support, Admins und in manchen Unternehmen auch in Troubleshooting-Prozessen genutzt.

Wer solche Zielgruppen kompromittiert, bekommt Geräte mit erhöhten Rechten, erweiterten Zugängen und wertvollen Browser-Sessions. 

3. Supply Chain ist nicht nur ein Dev-Thema

Wenn du bei „Supply Chain“ sofort nur an npm, Python-Pakete oder Build-Pipelines denkst, ist das verständlich, aber zu eng. Der CPUID-Fall war im Kern ein Software-Lieferkettenproblem auf Download-Ebene.

Das heißt: Auch klassische IT-Betriebe, Managed Clients, Helpdesks und Infrastrukturteams müssen dieses Risiko auf dem Zettel haben. Nicht nur die Entwickler. 

Was du jetzt konkret prüfen solltest

Wenn in deinem Unternehmen am 9. oder 10. April 2026 Tools von CPUID heruntergeladen wurden, würde ich nicht auf „wird schon gut gegangen sein“ setzen. Prüfe lieber aktiv:

• Wurden CPU-Z, HWMonitor, HWMonitor Pro oder PerfMonitor in diesem Zeitraum installiert?
• Stimmen Dateiname, Herkunft und Signatur mit den offiziellen Paketen überein?
• Gab es verdächtige Installer, DLL-Beilagen oder ungewöhnliche Netzwerkverbindungen?
• Sind auf betroffenen Geräten Browser-Credentials, Session-Tokens oder Admin-Konten potenziell exponiert?
• Gibt es EDR-, Proxy- oder Firewall-Hinweise auf verdächtige C2-Kommunikation? 

Wenn du einen Verdacht hast, denke nicht nur an Malware-Bereinigung. Behandle den Fall wie eine mögliche Identity Compromise: Tokens widerrufen, Passwörter zurücksetzen, privilegierte Konten prüfen, Browserdaten bewerten, Seitwärtsbewegungen analysieren.

Ein Infostealer ist selten höflich genug, nach dem Diebstahl die Tür wieder zu schließen. 

Vertrauen als Schwachstelle

Der Fall passt leider sehr gut zu dem, was wir hier im Blog immer wieder sehen: Angreifer suchen nicht den lautesten Weg, sondern den bequemsten. Mal ist es ein Supply-Chain-Angriff, mal ein täuschend echter Login-Flow, mal eine Benutzerinteraktion, die harmlos aussieht und am Ende teuer wird.

Die Methode variiert, das Muster bleibt: Vertrauen wird missbraucht, Routinen werden ausgenutzt, und technische Schutzmaßnahmen allein reichen nicht, wenn Prozesse und Aufmerksamkeit nicht mitziehen.

Das Thema gehört nicht in die Schublade „interessanter Security-Newsfall“, sondern in die Praxis: Software-Freigaben, Admin-Härtung, Monitoring, Awareness für IT-Teams und saubere Reaktionspläne.

Mein Fazit

Der CPUID-Angriff ist ein lehrbuchartiges Beispiel dafür, wie moderne Supply-Chain-Angriffe funktionieren: kurzer Zeitraum, hohe Glaubwürdigkeit, geschickte Tarnung, wertvolle Zielgruppe.

Deshalb sollte jedes Unternehmen hinschauen.

Letzten Endes ist die unangenehme Wahrheit: Nicht jede kompromittierte Software kommt aus dubiosen Ecken des Internets. Manchmal kommt sie geschniegelt direkt von der Seite, der du gestern noch blind vertraut hast.