YellowKey: Technische Analyse eines möglichen BitLocker-Recovery-Angriffs

YellowKey: Was bisher öffentlich ist

Am 12. Mai 2026 wurde unter dem GitHub-Account Nightmare-Eclipse ein Repository mit dem Namen YellowKey veröffentlicht. Beschrieben wird darin ein potenzieller Angriffspfad gegen den Festplattenverschlüsselungsschutz BitLocker in Windows 11 sowie in Windows Server 2022 und 2025. Laut Repository ist physischer Zugang zum Gerät erforderlich – ein vorbereiteter USB-Stick oder direkter Zugriff auf die EFI-Partition soll es ermöglichen, im Recovery-Kontext Zugriff auf das betroffene Volume zu erhalten.

Laut der README im Repository liegt die Ursache in einer Komponente, die nur innerhalb der Windows Recovery Environment (WinRE) aktiv ist und auf eine spezielle Ordnerstruktur namens FsTx innerhalb des System Volume Information-Verzeichnisses reagiert. Die Repository-Beschreibung selbst bezeichnet den Befund als „(potential) backdoor“; in der Danksagung werden die Microsoft-internen Teams MORSE, MSTIC und GHOST genannt – ein ungewöhnlicher Hinweis, der einen Konflikt zwischen der Researcher-Seite und dem Hersteller andeutet. Diese Bezeichnung spiegelt ausschließlich die Perspektive der veröffentlichenden Seite wider; für eine absichtliche Hintertür gibt es derzeit keinerlei belastbare Hinweise.

Die Angriffskette im Detail

Die im Repository dokumentierte Reproduktion ist erstaunlich schlank. Der Angreifer benötigt keinen Exploit-Code im klassischen Sinn, sondern lediglich eine vorbereitete Verzeichnisstruktur und physischen Zugang. Der entscheidende Trick: Die WinRE-Komponente lädt offenbar Inhalte aus einem Pfad, der unter regulärem Windows nicht beschreibbar wäre – auf einem externen Datenträger oder der EFI-Partition jedoch sehr wohl.

Eine zweite Variante kommt ganz ohne externes Medium aus: Wird die Festplatte des Zielsystems entnommen, kann der Angreifer die FsTx-Struktur direkt auf die EFI-System-Partition (ESP) kopieren. Die ESP ist standardmäßig nicht durch BitLocker verschlüsselt – sie enthält den Bootloader und ist für jedes Live-System mit Schreibrechten zugänglich. Nach dem Wiedereinsetzen der Platte greift die Schwachstelle ohne weitere Hardware.

USB-Stick (NTFS)
└── System Volume Information\
    └── FsTx\
        └── 95F62703B343F111A92A005056975458\
            └── [exploit-spezifische Dateien]

EFI-Partition (Alternative)
└── \EFI\Microsoft\Boot\...
    └── analoge Platzierung der FsTx-Struktur

Betroffene Systeme und Voraussetzungen

Die Schwachstelle soll laut Repository ausschließlich neuere Windows-Versionen betreffen. Nach aktuellem Kenntnisstand scheint Windows 10 nicht betroffen zu sein, da die betreffende WinRE-Komponente dort in einer Variante ohne die beschriebene Funktionalität ausgeliefert wird. Diese Unterscheidung wird im Repository als Indiz gewertet; eine unabhängige Bestätigung liegt nicht vor.

Warum dieser Fund relevant ist

BitLocker gilt in vielen Compliance-Rahmenwerken als technisch ausreichende Maßnahme zur Absicherung von Daten bei Geräteverlust („data at rest“). Eine funktionierende Bypass-Methode unterminiert diese Annahme – mit weitreichenden Folgen für die Bewertung von Vorfällen wie dem Verlust eines Firmen-Notebooks oder eines gestohlenen Außendienst-Tablets.

Schutzmaßnahmen und Härtung

Solange kein offizieller Patch von Microsoft vorliegt, sollten Organisationen konfigurative und organisatorische Maßnahmen evaluieren. Ein zentraler Ansatz ist die Härtung der Pre-Boot-Authentifizierung – sie verschiebt den Angriffspunkt vor die Recovery-Umgebung und reduziert die Angriffsfläche erheblich.

# Aktuelle Schutzmechanismen auflisten
Get-BitLockerVolume | Select-Object MountPoint, ProtectionStatus, KeyProtector

# Prüfen, ob TPM-only oder TPM+PIN aktiv ist
manage-bde -protectors -get C:

# WinRE-Status prüfen
reagentc /info

# WinRE temporär deaktivieren (Vorsicht: Auswirkungen auf Updates beachten)
reagentc /disable

# PowerShell: nach verdächtigen FsTx-Pfaden auf allen Volumes scannen
Get-PSDrive -PSProvider FileSystem | ForEach-Object {
  $path = Join-Path $_.Root 'System Volume Information\FsTx'
  if (Test-Path $path) {
    Write-Warning "Verdaechtige Struktur gefunden: $path"
    Get-ChildItem -Force $path | Format-List FullName, Length, CreationTime
  }
}

Einordnung und Ausblick

YellowKey ist Teil einer Doppelveröffentlichung – im gleichen Zeitraum wurde von derselben Quelle eine Local-Privilege-Escalation namens GreenPlasma publiziert. Sekundärquellen berichten, dass aus derselben Quelle zuvor bereits unter den Bezeichnungen BlueHammer und RedSun Exploits offengelegt wurden. Der Hintergrund scheint ein Konflikt mit Microsoft über den Umgang mit Schwachstellenmeldungen zu sein – die Veröffentlichungen tragen damit den Charakter einer öffentlichen Eskalation.

Für Verantwortliche in IT- und Sicherheitsorganisationen ergeben sich aus dieser Veröffentlichung zwei Hinweise: Erstens sollte das Bedrohungsmodell „verschlüsseltes Notebook ist sicher“ im Licht dieser Forschung neu bewertet werden. Zweitens bleiben Pre-Boot-Authentifizierung und Defense-in-Depth auch in einer Welt mit hardwaregestützter Verschlüsselung wesentliche Schutzebenen. Wer NIS2-Anforderungen umsetzt, könnte BitLocker-Konfigurationen explizit gegen physische Angriffsszenarien evaluieren.