Rufus unter Malware-Verdacht: Was an den Vorwürfen dran ist
Rund um Rufus gibt es derzeit eine ziemlich unangenehme Sicherheitsdiskussion.
Auslöser sind Berichte, nach denen beim Einsatz der bekannten Software zum Erstellen bootfähiger USB-Sticks zahlreiche Trojaner-Warnungen aufgetaucht sein sollen. Schnell steht bei solchen Meldungen natürlich die Frage im Raum:
Wurde Rufus selbst kompromittiert?
Nach dem aktuellen Stand vom 24. Oktober 2026 gibt es dafür jedoch keinen belastbaren Beweis.
Die vorhandenen Hinweise sprechen momentan eher dagegen, dass die offizielle Rufus-Version über einen Lieferkettenangriff manipuliert wurde. Die beobachteten Warnungen sollte man trotzdem ernst nehmen – nur eben nicht vorschnell mit einem kompromittierten Rufus-Download gleichsetzen.
Ausgangspunkt sind Berichte über zahlreiche Trojaner-Warnungen
Der Sicherheitsjournalist Brian Krebs berichtete, dass nach dem Download von Rufus von der offiziellen Webseite zahlreiche Malware-Warnungen auf seinem Rechner aufgetaucht seien.
Zusätzlich soll das mit Rufus erzeugte Installationsmedium beim Booten durch eine Sicherheitsrichtlinie blockiert worden sein.
Das klingt zunächst natürlich alarmierend.
Gerade Rufus wird von sehr vielen Anwendern genutzt, um Windows- oder Linux-Installationsmedien zu erstellen.
Wenn ausgerechnet dieses Werkzeug manipuliert wäre, hätte das potenziell enorme Auswirkungen.
Genau deshalb lohnt sich ein genauerer Blick auf das, was tatsächlich belegt ist.
Rufus-Entwickler reagiert direkt
Pete Batard, der Entwickler von Rufus, hat sich inzwischen ausführlich zu den Vorwürfen geäußert.
Dabei nennt er mehrere Punkte, die aus seiner Sicht gegen die bisherige Interpretation sprechen.
Der erste Punkt ist ziemlich simpel:
Rufus besitzt keinen klassischen Installer.
Das offizielle Programm wird als ausführbare EXE gestartet.
Wenn also von einer eigentlichen „Installation“ die Rede ist, muss zunächst geklärt werden, was genau damit gemeint war.
Rufus lädt tatsächlich zusätzliche Dateien herunter
Dass Rufus während der Arbeit Internetverbindungen aufbaut oder zusätzliche Komponenten herunterlädt, ist zunächst kein ungewöhnliches Verhalten.
Je nach verwendetem Installationsabbild benötigt das Programm beispielsweise zusätzliche:
GRUB-Komponenten
Syslinux-Bootloader
Secure-Boot-Informationen
Sperrlisten für widerrufene UEFI-Komponenten
Solche Downloads gehören zu bestimmten Rufus-Funktionen und sind dokumentiert.
Nur weil während der Erstellung eines USB-Sticks weitere Dateien auftauchen, bedeutet das also noch nicht, dass Rufus heimlich Schadsoftware nachlädt.
Die verwendete ISO ist entscheidend
Einer der größten offenen Punkte ist das verwendete Installationsabbild.
Bislang ist nicht ausreichend dokumentiert, welche ISO-Datei bei dem betroffenen Vorgang eingesetzt wurde.
Das ist wichtig.
Rufus nimmt schließlich die Dateien einer ISO und kopiert beziehungsweise verarbeitet sie für das Zielmedium.
Enthält das verwendete Image Programme oder Werkzeuge, die von einem Virenscanner als verdächtig eingestuft werden, tauchen entsprechende Meldungen genau während dieses Vorgangs auf.
Das wäre dann keine Malware, die Rufus heruntergeladen hat, sondern Inhalt des verwendeten Images.
Der Rufus-Entwickler hält genau dieses Szenario für eine mögliche Erklärung.
Bewiesen ist allerdings auch diese Erklärung bislang nicht.
Secure-Boot-Blockade ist ebenfalls kein Malware-Beweis
Auch der fehlgeschlagene Start eines erstellten USB-Mediums beweist zunächst wenig.
Secure Boot arbeitet mit Sperrlisten.
Wird ein älterer oder inzwischen als unsicher eingestufter Bootloader verwendet, kann moderne UEFI-Firmware dessen Ausführung verhindern.
Dann erscheint eine Sicherheitsmeldung, obwohl auf dem Stick nicht zwangsläufig Malware vorhanden ist.
Gerade ältere Windows- oder Linux-Images können solche inzwischen widerrufenen Bootkomponenten enthalten.
Eine Secure-Boot-Warnung ist deshalb ein Grund, genauer hinzusehen.
Sie ist aber kein automatischer Trojaner-Nachweis.
Was sagt die ANY.RUN-Analyse?
Im Zusammenhang mit den Vorwürfen wurde Rufus außerdem in der Sandbox ANY.RUN untersucht.
Der Bericht wurde dort als verdächtig beziehungsweise bösartig eingestuft.
Eine solche Klassifizierung klingt deutlich.
Sie beweist aber nicht automatisch, dass das untersuchte Programm tatsächlich Malware installiert.
Bestimmte Aktionen eines Programms können in einer Sandbox verdächtig wirken, obwohl sie für dessen eigentliche Aufgabe notwendig sind.
Bei Rufus gehören dazu unter anderem Datenträgerzugriffe und verschiedene Arbeiten mit Windows-Systemkomponenten.
Auch vds.exe, der Windows Virtual Disk Service, taucht dabei auf.
Der entscheidende Haken an der Analyse:
Nach den vorliegenden Informationen wurde dort offenbar gar kein vollständiges bootfähiges Installationsmedium erzeugt.
Damit reproduziert dieser Test den ursprünglich beschriebenen Ablauf nicht vollständig.
Eine zweite Sandbox schlägt ebenfalls an
Interessanterweise existiert noch eine weitere Analyse.
Bereits am 12. September 2026, also deutlich vor der aktuellen Diskussion, wurde Rufus 4.15 in der Triage-Sandbox untersucht.
Das Ergebnis bekam dort einen Risiko-Score von:
5 von 10
Die Sandbox markierte verschiedene Aktivitäten als verdächtig.
Dazu gehörten unter anderem:
UPX-Packing
Zugriffe auf Systemrichtlinien
Datenträgererkennung
sicherheitsrelevante Windows-Funktionen
Auffällig war allerdings auch:
Es wurden keine Netzwerkverbindungen beobachtet.
Das passt nicht besonders gut zu der Vorstellung eines Programms, das nach dem Start massenhaft Trojaner aus dem Internet nachlädt.
Ein echter Rufus-Fehler wurde tatsächlich gefunden
Die Sandbox-Beobachtungen führen allerdings zu einem interessanten Nebenthema.
Rufus 4.15 greift tatsächlich auf:
C:\Windows\System32\GroupPolicy\Machine\Registry.polzu.
Der Hintergrund ist eine Funktion, über die Rufus lokale Gruppenrichtlinien vorübergehend verändert, um bestimmte automatische Windows-Reaktionen auf USB-Laufwerke zu unterdrücken.
Dabei wurde tatsächlich ein Fehler entdeckt.
Rufus 4.15 kann lokale Startskripte beeinflussen
Am 3. September wurde ein Problem gemeldet, bei dem die Wiederherstellung lokaler Gruppenrichtlinien durch Rufus unbeabsichtigt konfigurierte Start- und Herunterfahrskripte deaktivieren konnte.
Pete Batard bestätigte diesen Fehler.
Die entsprechende Gruppenrichtlinien-Logik wurde am 21. September 2026 aus dem Entwicklungszweig entfernt.
Zum Zeitpunkt der Analyse war diese Korrektur allerdings noch nicht in einer neuen öffentlichen Version erschienen.
Das ist ein echtes Rufus-Problem.
Aber:
Es ist kein Hinweis auf Malware und kein Beweis für einen Lieferkettenangriff.
Diese beiden Themen sollte man sauber auseinanderhalten.
Die offizielle Rufus-Datei lässt sich über den Hash prüfen
Wer selbst Rufus 4.15 heruntergeladen hat, kann zumindest kontrollieren, ob seine Datei der bereits bekannten offiziellen Veröffentlichung entspricht.
Für die reguläre 64-Bit-Version:
rufus-4.15.exelautet der dokumentierte SHA-256-Hash:
84c8a437f8af89257524478489e5c85f1edf25f761d299e2bcde46ac0afbe106Dieser Hash war bereits vor der aktuellen Kontroverse in unabhängigen Softwarearchiven dokumentiert.
Das ist wichtig.
Wenn die Datei auf den Rufus-Servern nachträglich gegen eine manipulierte Version ausgetauscht worden wäre, müsste sich auch deren Hash verändern.
Rufus-Datei mit PowerShell überprüfen
Unter Windows lässt sich der Hash beispielsweise mit PowerShell kontrollieren:
Get-FileHash .\rufus-4.15.exe -Algorithm SHA256Zusätzlich lässt sich die digitale Signatur prüfen:
Get-AuthenticodeSignature .\rufus-4.15.exeBei der bekannten offiziellen Datei sollte die Signatur zum legitimen Herausgeber Akeo Consulting gehören.
Stimmen Hash und Signatur, entspricht die Datei zumindest der bekannten offiziellen Veröffentlichung.
Das ist ein starkes Indiz gegen einen nachträglichen Austausch.
Ein absoluter Beweis dafür, dass jede denkbare Softwarekomponente fehlerfrei oder sicher ist, ist ein Hash natürlich trotzdem nicht.
Unabhängige Gegenprobe konnte das Verhalten nicht reproduzieren
Inzwischen wurde außerdem eine unabhängige Gegenprobe veröffentlicht.
Dabei wurde Rufus frisch heruntergeladen und erneut untersucht.
Nach dieser Prüfung:
war die EXE korrekt von Akeo Consulting signiert
entsprach der SHA-256-Hash der bekannten Rufus-Version 4.15
ließ sich das ursprünglich beschriebene Verhalten nicht reproduzieren
Auch das spricht momentan gegen einen allgemeinen Angriff auf die offizielle Rufus-Distribution.
Theoretisch denkbar wäre natürlich ein gezielter Angriff auf einen einzelnen Download oder Rechner.
Dafür gibt es derzeit aber ebenfalls keinen Beleg.
Was weiterhin fehlt
Und genau hier liegt für mich das eigentliche Problem der aktuellen Diskussion.
Für eine eindeutige technische Rekonstruktion fehlen wichtige Daten.
Vor allem wären interessant:
SHA-256-Hash der ursprünglich heruntergeladenen Rufus-Datei
genaue Rufus-Version
verwendete ISO-Datei samt Hash
konkrete Defender- beziehungsweise Antivirus-Funde
Pfade der gefundenen Dateien
Prozesszuordnung der Warnmeldungen
Ohne diese Informationen lässt sich nur schwer feststellen, ob die Malware-Warnungen tatsächlich von Rufus, dem verwendeten ISO-Abbild oder einem bereits bestehenden Problem auf dem Rechner stammten.
Rufus ist aktuell Version 4.15
Zum Zeitpunkt der erneuten Analyse ist Rufus 4.15 weiterhin die aktuelle offizielle Version.
Sie stammt vom 30. Juni 2026.
Gerade dieser zeitliche Abstand ist interessant:
Der bekannte Hash der EXE wurde bereits Monate vor der aktuellen Kontroverse dokumentiert.
Damit existiert eine brauchbare Referenz, gegen die sich heutige Downloads vergleichen lassen.
Was ich derzeit von der Lage halte
Ich würde Rufus momentan nicht pauschal als kompromittiert einstufen.
Dafür fehlen schlicht die Belege.
Die bekannten Sandbox-Warnungen sind real.
Auch der Fehler bei lokalen Gruppenrichtlinien ist real.
Beides reicht aber nicht aus, um daraus einen Angriff auf die Rufus-Lieferkette abzuleiten.
Genau diese Unterscheidung finde ich wichtig.
Security-Tools schlagen bei Programmen wie Rufus schneller an als bei einem Taschenrechner.
Rufus läuft mit erhöhten Rechten, verändert Datenträger, schreibt Bootsektoren, arbeitet mit UEFI-Komponenten und greift teilweise tief in Windows-Funktionen ein.
Für eine heuristische Erkennung sieht so etwas zwangsläufig interessanter aus als Notepad.
Das bedeutet nicht, dass jede Warnung ignoriert werden sollte.
Es bedeutet nur, dass sie technisch eingeordnet werden muss.
Wer besonders vorsichtig sein möchte
Wer Rufus derzeit verwenden möchte, kann einige relativ einfache Maßnahmen treffen.
Die Datei sollte nur über die offizielle Rufus-Seite beziehungsweise das offizielle GitHub-Projekt heruntergeladen werden.
Danach können Hash und digitale Signatur kontrolliert werden.
Für Installationsmedien würde ich zusätzlich eine ISO verwenden, deren Herkunft und Prüfsumme bekannt sind.
Und wer Rufus auf einem besonders sensiblen Administrations-PC einsetzt, sollte den bekannten Fehler rund um lokale Gruppenrichtlinien berücksichtigen.
Alternativ kann vorübergehend auch Microsofts eigenes Media Creation Tool verwendet werden.
Fazit
Die Behauptung, die offizielle Rufus-Version sei aktuell über einen Lieferkettenangriff kompromittiert, ist nach dem derzeitigen Stand nicht belegt.
Es gibt Berichte über zahlreiche Malware-Warnungen und Sandbox-Systeme markieren verschiedene Rufus-Aktivitäten als verdächtig.
Gleichzeitig sprechen mehrere Punkte gegen eine manipulierte offizielle EXE:
der bekannte Rufus-4.15-Hash ist bereits seit Monaten dokumentiert
die offizielle Datei ist digital signiert
unabhängige Tests konnten das beschriebene Verhalten bislang nicht reproduzieren
einige vermeintlich verdächtige Aktionen gehören zum normalen Funktionsumfang
die verwendete ISO des ursprünglichen Falls ist bislang nicht ausreichend dokumentiert
Ein tatsächliches Problem gibt es dennoch:
Rufus 4.15 besitzt einen bestätigten Fehler im Umgang mit lokalen Gruppenrichtlinien, der Start- beziehungsweise Herunterfahrskripte beeinflussen kann.
Das ist unschön und sollte behoben werden.
Es ist aber etwas völlig anderes als ein versteckter Trojaner.
Mein aktueller Stand deshalb:
Vorsicht ist angebracht – Panik nicht.
Wer die offizielle, signierte Rufus-Datei nutzt, deren Hash kontrolliert und ein vertrauenswürdiges ISO-Abbild verwendet, hat nach der derzeitigen Beweislage keinen konkreten Grund, von einer kompromittierten Rufus-Version auszugehen.
Was für eine endgültige Klärung noch fehlt, sind vor allem die technischen Details des ursprünglichen Vorfalls.
Quellen
Rufus GitHub – Stellungnahme von Pete Batard:
Brian Krebs' post about official Rufus being malware – Issue #3064
https://github.com/pbatard/rufus/issues/3064
Rufus GitHub – bestätigter Gruppenrichtlinienfehler:
SetLGP() restore removes the Scripts CSE from gpt.ini – Issue #3042
https://github.com/pbatard/rufus/issues/3042
Triage – Sandbox-Analyse von Rufus 4.15:
https://tria.ge/260912-sa124s1zaw/behavioral2
Fossies – Rufus 4.15 und dokumentierter SHA-256-Hash:
https://fossies.org/windows/misc/rufus-4.15.exe/
Rufus – offizielle Webseite:
https://rufus.ie/