Julia Wolf
BlueHammer ist eine Zero-Day-Lücke in Windows 11, für die es keinen Patch gibt – und der Exploit-Code liegt seit Wochen öffentlich auf GitHub. Willkommen im Alltag der Windows-Sicherheit 2026.
Kein CVE. Kein Patch. Kein offizielles Statement mit konkretem Zeitplan. Dafür: funktionierender Proof-of-Concept-Code, bestätigt durch unabhängige Sicherheitsforschende, ausführbar in unter einer Minute. Das ist die Ausgangslage bei BlueHammer – und sie ist, wenig überraschend, alles andere als komfortabel für die rund 1,4 Milliarden Windows-Nutzenden weltweit.
Plot Twist: Die Schwachstelle nutzt keine Kernel-Bugs, keine Memory Corruption, keine obskuren Systemaufrufe. BlueHammer hebelt legitime Windows-Komponenten aus. Das macht sie besonders unangenehm – und besonders schwer zu stopfen.
BlueHammer ist eine lokale Privilegieneskalation, kurz LPE. Das bedeutet: Wer einen Low-Privilege-Account auf einem Windows-10- oder Windows-11-System hat, kann sich damit zur mächtigsten Instanz des Systems hocharbeiten – NT AUTHORITY\SYSTEM. Vollständige Kontrolle. Game over.
Der technische Unterbau ist dabei durchaus elegant, wenn man das bei einer Sicherheitslücke so nennen darf. BlueHammer kombiniert drei Angriffsvektoren: einen TOCTOU-Fehler (Time-of-Check to Time-of-Use), eine Dateipfad-Verwechslung und eine Schwäche in Windows Defenders Update-Prozessen. Beteiligt sind der Volume Shadow Copy Service, die Cloud Files API und sogenannte Opportunistic Locks. Alles legitime Windows-Komponenten. Alles Features, kein Bugs – bis auf den einen entscheidenden Moment, in dem sie zusammenspielen.
Was BlueHammer nicht ist: ein Remote-Exploit. Angreifende brauchen lokalen Zugriff. Das klingt nach einer Entwarnung. Ist es aber nicht. Denn lokaler Zugriff ist in der Praxis erschreckend oft vorhanden – als interner Mitarbeitender, als kompromittiertes Konto, als Gast im Büronetzwerk, als jemand, der kurz unbeaufsichtigt am Rechner saß.
Will Dormann, Principal Vulnerability Analyst bei Tharros, bestätigte gegenüber WinFuture die Funktionsfähigkeit der Lücke: TOCTOU-Angriff plus Path Confusion ergeben SAM-Zugriff und vollständige Systemkontrolle. Die SAM-Datenbank – Security Account Manager – enthält NTLM-Passwort-Hashes. Wer darauf zugreift, hat die Schlüssel zum Königreich.
Das Pikante daran: BlueHammer ist nicht durch einen klassischen Angriff bekannt geworden. Der Forscher hinter dem Pseudonym Chaotic Eclipse hat den Exploit-Code selbst veröffentlicht – auf GitHub, öffentlich zugänglich, inklusive Proof-of-Concept.
Der Grund: Unzufriedenheit mit Microsofts Sicherheitsteam MSRC (Microsoft Security Response Center). Statt der üblichen koordinierten Offenlegung nach 90 oder 180 Tagen entschied sich Chaotic Eclipse für den direkten Weg. Zu langsam, zu wenig Reaktion, zu viel Hinhalten – so lautet, sinngemäß, der Vorwurf.
Microsoft wiederum betont weiterhin das Prinzip der koordinierten Offenlegung. Schön. Nur hilft das im Moment niemandem, dessen System gerade exponiert ist. Das ist das klassische Disclosure-Dilemma: Forscher frustriert über Vendor-Reaktionen, Vendor frustriert über vorzeitige Veröffentlichungen, und dazwischen: Millionen betroffene Systeme.
Dieser Trend beschleunigt sich. Immer mehr Sicherheitsforschende wählen den öffentlichen Druck als letztes Mittel, wenn interne Meldewege versanden. Das erhöht kurzfristig das Angreiferrisiko erheblich – erzwingt aber langfristig schnellere Patch-Zyklen. Ob das ein fairer Tausch ist, darüber lässt sich trefflich streiten. Meine Meinung: Wenn Hersteller wie Microsoft Monate brauchen, um kritische LPE-Lücken auch nur zu bestätigen, darf man sich über ungeduldige Forscher nicht wundern.
Wer verstehen will, warum BlueHammer brisant ist, muss kurz in die Technik einsteigen. Keine Angst – es wird kein Kernel-Seminar.
Der Angriff beginnt mit einem normalen Nutzerkonto ohne erhöhte Rechte. BlueHammer triggert dann einen Race Condition zwischen zwei Systemoperationen – das ist der TOCTOU-Kern. In dem Moment, in dem Windows prüft, ob eine Datei vertrauenswürdig ist (Time-of-Check), und dem Moment, in dem sie tatsächlich verwendet wird (Time-of-Use), gibt es ein Fenster. Klein, aber ausreichbar.
Über die Dateipfad-Verwechslung wird dieser Moment genutzt, um den Windows Defender Update-Prozess mit einer manipulierten Komponente zu füttern. Der Volume Shadow Copy Service und die Cloud Files API dienen als Hebel, um den Zugriff auf die SAM-Datenbank zu erzwingen. Das Resultat: NTLM-Passwort-Hashes auslesbar, Admin-Passwörter änderbar, SYSTEM-Shell spawnbar.
Kein Kernel-Bug. Keine Memory Corruption. Alles innerhalb der normalen Windows-Funktionsgrenzen. Die Analyse von Cyderes/Howler Cell bringt es auf den Punkt: Die Schwäche entsteht durch das Zusammenspiel legaler Komponenten – genau das macht eine Erkennung per Signatur unzureichend. Die TTPs (Tactics, Techniques, Procedures) des Angriffs bleiben durch klassische Signaturen unentdeckt.
Microsoft Defender erkennt den originalen PoC-Code mittlerweile als Exploit:Win32/DfndrPEBluHmr.BB. Modifizierte Varianten umgehen diese Erkennung jedoch. Das ist die Crux: Wer den GitHub-Code leicht abändert, fliegt unter dem Radar. Und das ist keine Raketenwissenschaft.
BlueHammer funktioniert bestätigt auf Windows 10 und Windows 11. Auf Windows Server-Systemen ist die Ausnutzbarkeit eingeschränkt oder nicht gegeben. Das klingt zunächst beruhigend für Unternehmensinfrastrukturen – bis man daran denkt, dass die meisten Endgeräte in Unternehmen Client-Systeme mit Windows 10 oder 11 sind.
Ein Angreifender braucht also nur Zugang zu einem einzigen schlecht gesicherten Endgerät. Von dort aus: BlueHammer, SYSTEM-Rechte, Passwort-Hashes, laterale Bewegung im Netzwerk. Der klassische Einstiegsvektor für größere Angriffe. Wenig überraschend, dass das Sicherheitsforschende als erhebliches Risiko einstufen – trotz der Voraussetzung des lokalen Zugriffs.
Zu beachten: Ein CVE wurde bislang nicht zugewiesen. Das erschwert das Tracking in Vulnerability-Management-Systemen erheblich. Wer auf automatische CVE-basierte Warnungen vertraut, wartet hier im Zweifel vergeblich.
Der unbefriedigende Stand der Dinge: Es gibt keinen offiziellen Patch. Der nächste Patch Tuesday ist der nächste Hoffnungsschimmer – aber kein garantierter. Was also tun?
BlueHammer erfordert lokalen Zugriff. Das ist die einzige echte Begrenzung des Exploits. Konsequenz: Least-Privilege-Prinzip konsequent umsetzen. Kein Nutzender bekommt mehr Rechte als nötig. Gastkonten deaktivieren. Physischen Zugang zu Geräten einschränken. Klingt trivial. Ist es auch. Und wird trotzdem in erschreckend vielen Umgebungen ignoriert.
Der originale PoC wird erkannt. Das ist immerhin etwas. Defender-Signaturen regelmäßig aktualisieren – das sollte Pflicht sein, ist es aber nicht überall. Automatische Updates aktivieren, wo noch nicht geschehen.
Da Signatur-Erkennung bei modifizierten BlueHammer-Varianten versagt, ist verhaltensbasierte Erkennung der richtigere Ansatz. EDR-Lösungen (Endpoint Detection and Response), die anomales Verhalten erkennen – etwa ungewöhnliche Prozesse, die plötzlich SYSTEM-Rechte anfordern oder auf die SAM-Datenbank zugreifen – sind hier überlegen. Wer noch mit klassischem Antivirus arbeitet: Das ist 2026. Zeit für ein Upgrade.
Da BlueHammer den Volume Shadow Copy Service nutzt, lohnt es sich, VSS-bezogene Aktivitäten zu überwachen. Ungewöhnliche VSS-Aufrufe von Low-Privilege-Konten sollten Alarm auslösen. Das ist kein Hexenwerk, aber es erfordert konfigurierte SIEM-Regeln.
Mehr zum Thema, wie Unternehmen sich strukturell gegen solche Angriffsvektoren absichern, lesen Sie in unserer Analyse zu Cyberprotection und was wirklich vor Angriffen schützt.
BlueHammer steht nicht allein. Es gibt einen wachsenden Trend zu Exploits, die keine Kernel-Bugs brauchen, sondern legitime Systemfunktionen missbrauchen. Living-off-the-Land-Angriffe, die mit bordinternen Windows-Tools arbeiten. Shadow Copy Exploits. Cloud Files API-Missbrauch.
Das ist der Clou: Je mehr Funktionalität ein Betriebssystem bietet, desto mehr Angriffsfläche entsteht zwangsläufig. Windows ist über Jahrzehnte gewachsen und trägt entsprechend viel Legacy-Ballast. Jede neue Funktion, jede API, jeder Service ist potenziell ein neuer Hebel.
Die Howler-Cell-Analyse formuliert es klar: Keine Signatur-Fix löst das eigentliche Problem. Die Root Cause muss gepatcht werden. Das erfordert tiefgreifende Änderungen an Windows-Komponenten – und das braucht Zeit. Zeit, die angreifende Akteure nutzen.
Dass in der Sicherheitscommunity bereits aktiv über BlueHammer diskutiert wird, zeigt: Das Bewusstsein für die Lücke ist da. Jetzt fehlt nur noch der Patch.
Das Problem mit lokalen LPEs via legitimen Features ist auch deshalb besonders hartnäckig, weil sie oft tief in der Prioritätenliste der Hersteller versinken. Remote-Exploits bekommen die Aufmerksamkeit, lokale Privilegieneskalationen werden als „geringeres Risiko“ eingestuft – bis sie Teil einer längeren Angriffskette werden. Dann plötzlich: Krisenmodus. Das Muster wiederholt sich. Zuverlässig.
Microsoft hat sich zum Zeitpunkt der Veröffentlichung dieses Artikels nicht mit einem konkreten Patch-Zeitplan geäußert. Das MSRC betont koordinierte Offenlegung – aber der Code liegt bereits öffentlich. Das Schiff ist abgefahren.
Kein CVE bedeutet auch: keine automatische Priorisierung in Patch-Management-Systemen, kein CVSS-Score zum Einordnen, keine offizielle Einschätzung des Schweregrades. Für IT-Abteilungen, die auf strukturierte Vulnerability-Daten angewiesen sind, ist das ein echtes operatives Problem.
Meine Einschätzung: Microsoft wird BlueHammer patchen. Wann, ist die Frage. Und bis dahin ist der PoC-Code öffentlich, die Technik bekannt, und Angreifende haben prinzipiell genug Zeit, das auszunutzen. Das ist keine Panik-Rhetorik, das ist schlicht die Realität von ungepatchten Zero-Days mit öffentlichem PoC.
Wer wissen will, wie Deutschland insgesamt als Angriffsziel dasteht und warum lokale Schwachstellen wie BlueHammer in einem größeren Kontext zu sehen sind, findet im Darktrace Report 2026 über Deutschland als Hackerziel Nr. 1 in Europa erhellende Zahlen.
BlueHammer ist kein Hollywood-Exploit mit Feuerbällen und dramatischer Musik. Es ist eine handwerklich solide Zero-Day-Lücke, die legitime Windows-Funktionen zu etwas Bösen kombiniert, für die es keinen Patch gibt und deren PoC-Code frei verfügbar ist. Das ist die nüchterne Wahrheit.
Lokaler Zugriff als Voraussetzung klingt beruhigend – ist es aber nicht. Insider-Bedrohungen, kompromittierte Konten, physischer Zugang: All das existiert in realen Unternehmensumgebungen täglich. Und wer BlueHammer als Zwischenschritt in einer größeren Angriffskette nutzt, braucht diesen lokalen Zugang nur einmal.
Die eigentliche Frage ist nicht, ob Microsoft irgendwann patcht. Das wird passieren. Die Frage ist: Was machen Unternehmen und IT-Verantwortliche in der Zwischenzeit? Abwarten? Auf Defender-Signaturen vertrauen, die modifizierte Varianten nicht erkennen? Oder den Schutz tatsächlich aus der Tiefe heraus aufbauen – Least Privilege, Behavior Detection, Access Monitoring?
BlueHammer ist ein weiterer Hinweis darauf, dass reaktive Sicherheit – warten auf den Patch, Signatur aktualisieren, fertig – nicht reicht. Nie gereicht hat. Und 2026 erst recht nicht.
Haben Sie BlueHammer bereits in Ihrem Threat-Monitoring auf dem Schirm – oder wartet Ihre IT-Abteilung noch auf den offiziellen CVE?
