Ein Standard-Benutzer, der die Registry eines Administrators liest und manipuliert — ohne Exploit-Kette, sondern über einen legitimen Windows-Dienst. Genau das demonstriert LegacyHive, und Microsoft hat dafür noch keinen Patch geliefert.
Am 14. Juli 2026 veröffentlichte der Forscher Nightmare-Eclipse (neuer Alias MSNightmare) den LegacyHive-PoC. Er nutzt eine Schwäche im Windows User Profile Service (ProfSvc) und der Art, wie dieser Registry-Hives lädt: Über einen fein getimten Path-Switching-Trick mountet ein normaler Standard-Benutzer die Registry-Hive eines anderen Nutzers — auch eines Administrators — in seine eigene HKU\…\Classes (Current User Classes Root). Daraus lässt sich bis zur vollständigen Systemübernahme eskalieren.
Warum das ernst ist
- 1Funktioniert auf allen unterstützten Windows-Versionen — inklusive dem Juli-2026-Patch-Tuesday-Stand. Das reguläre Monatsupdate schließt die Lücke nicht.
- 2Kein CVE, kein Microsoft-Advisory, kein Patch (Stand dieses Beitrags). Ein bestätigtes Ausnutzen in freier Wildbahn ist bislang nicht belegt.
- 3Der PoC ist bewusst „stripped down": Er verlangt aktuell ein zweites Standard-User-Credential und einen dritten Usernamen. Der Autor betont, das Original habe keine Fremd-Credentials gebraucht und sei nicht auf usrclass.dat beschränkt gewesen — das öffentliche Bild unterschätzt die reale Tragweite also eher.
Worauf es jetzt ankommt: Erkennung
Ohne Patch ist Erkennung die primäre Gegenmaßnahme. Unsere Laboranalyse (in einer isolierten, pro Thema frisch aufgesetzten Umgebung) zeigt die tragfähigen Indikatoren:
- Stärkster IOC: ein Hive-Load, bei dem eine fremde User-Hive nach
HKU\S-1-5-21-…_Classesgeladen wird — durch einen Prozess, der kein Windows-Systemdienst ist (nicht svchost/lsass/services/winlogon). - Ergänzend: Zugriff auf eine fremde
NTUSER.DAT/UsrClass.dat(C:\Users\<anderer>\…) durch einen untypischen Prozess. - Konkrete Regeln liefern wir mit: eine Sysmon-Konfiguration für die relevanten Registry-/Datei-Ereignisse und eine Wazuh-Detektionsregel (Level 12, MITRE T1547.001/T1055), die auf genau dieses Muster feuert.
<rule id="100300" level="12"> <if_sid>61614,61615</if_sid> <field name="win.eventdata.targetObject" type="pcre2">(?i)(?:\\+REGISTRY\\+USER\\+|HKU\\+)S-1-5-21-[0-9-]+_Classes</field> <field name="win.eventdata.image" negate="yes" type="pcre2">(?i)\\(svchost|lsass|services|winlogon|csrss|wininit)\.exe$</field> <description>LegacyHive: fremde User-Hive nach HKU\...\Classes durch nicht-privilegierten Prozess</description> <mitre><id>T1547.001</id><id>T1055</id></mitre> </rule>
Diese Regel haben wir in einer isolierten Laborumgebung gegen echte Sysmon-Ereignisse validiert — der Hive-Load-Zugriff durch einen Nicht-System-Prozess löste zuverlässig einen Alarm der Stufe 12 aus.
Härtung, solange kein Patch existiert
- Least Privilege für lokale Standard-Konten; keine geteilten Standard-Credentials (der PoC braucht ein zweites Konto).
- Die obigen IOCs mit hoher Priorität überwachen und alarmieren, bis Microsoft einen Fix liefert.
- Nachweisbarkeit sicherstellen: Wer privilegierte Aktionen ausführt, muss revisionssicher protokolliert sein — gerade bei einer Technik, die Admin-Kontext missbraucht.
So begleiten wir das
Für den letzten Punkt lohnt der Blick auf die eigene Nachweis- und Zugriffsarchitektur: Mit unserem Independent Log Vault landen sicherheitsrelevante Ereignisse manipulationssicher und von den protokollierten Administratoren unabhängig — genau das, was eine Eskalation über fremde Hives sonst verwischen könnte. Und kontrollierten, lückenlos auditierten Administrationszugriff bündelt unsere Privileged Access Bridge. Wer die Erkennung strukturiert aufsetzen will, den begleitet ein externer ISB bzw. unser detection-zentriertes Vorgehen dabei, aus IOCs belastbare Alarme zu machen.