3
Windows-Security-Eventlog war umgehbar
Ich grüße Euch.
Da Microsoft ja die Dokumentation seiner Updates seit einigen Jahren stark heruntergefahren hat, entgeht mir so manche haarsträubende (nun aber gefixte) Lücke wie die folgende. Ich kann über Google auch keine Advisories bei Microsoft finden, die über diese Lücke berichten: https://www.youtube.com/watch?v=Wx7gIO71HBg
Der Video-Autor ist ein versierter Windowsexperte und scheint einer der ersten zu sein, dem aufgefallen ist, dass das bloße Erstellen des Registrykeys HKLM\SYSTEM\CurrentControlSet\Control\MiniNT (Adminrechte erforderlich) ausreicht, um nach einem Reboot (oder, was er nicht erwähnt, noch schlimmer sogar bei Neustart des Dienstes "Windows Eventlog") das Sicherheitseventlog und ebenso die anderen Systemlogs anzuhalten. Es wird nichts mehr aufgezeichnet! Das ist insofern krass, als dass Microsoft das Sicherheitslogging seit Windows 2000 für so schützenswert hält, dass sie ja seit Ewigkeiten anbieten, eine Policy zu aktivieren, die den Rechner sofort runterfährt, wenn das Sicherheitslog nicht mehr arbeitet:
Problem damit: auch das arbeitet in diesem Fall nicht korrekt! Das machte diesen minint-Trick zur Trumpfkarte für alle Hacker, die Ihre Spuren verschleiern wollten. Keine Ahnung, seit wann das so gearbeitet hat, aber mittlerweile ist es gepatcht - das Logging trägt die Events zumindest nach, nachdem man den Minint-Key wieder entfernt hat und neu gestartet hat.
Im Video ist dies ausfürhlich dargestellt. Wer's mal selbst austesten will, nimmt z.B. einen naturbelassenen Server 2019 (Build 17763.1 oder .55).
Und was soll der MiniNT-Key überhaupt? Er ist für Windows-Setup (WinPE) und Recoveryenvironments gedacht und wird dort automatisch gesetzt, um kein unnötiges Logging anlaufen zu lassen. Da Microsoft bequem ist, nehmen sie den selben Code in WinPE wie in Windows und MiniNT wirkt in beiden, obwohl MS das nie und nimmer beabsichtigt.
Da Microsoft ja die Dokumentation seiner Updates seit einigen Jahren stark heruntergefahren hat, entgeht mir so manche haarsträubende (nun aber gefixte) Lücke wie die folgende. Ich kann über Google auch keine Advisories bei Microsoft finden, die über diese Lücke berichten: https://www.youtube.com/watch?v=Wx7gIO71HBg
Der Video-Autor ist ein versierter Windowsexperte und scheint einer der ersten zu sein, dem aufgefallen ist, dass das bloße Erstellen des Registrykeys HKLM\SYSTEM\CurrentControlSet\Control\MiniNT (Adminrechte erforderlich) ausreicht, um nach einem Reboot (oder, was er nicht erwähnt, noch schlimmer sogar bei Neustart des Dienstes "Windows Eventlog") das Sicherheitseventlog und ebenso die anderen Systemlogs anzuhalten. Es wird nichts mehr aufgezeichnet! Das ist insofern krass, als dass Microsoft das Sicherheitslogging seit Windows 2000 für so schützenswert hält, dass sie ja seit Ewigkeiten anbieten, eine Policy zu aktivieren, die den Rechner sofort runterfährt, wenn das Sicherheitslog nicht mehr arbeitet:
Audit: Shut down system immediately if unable to log security audits
This security setting determines whether the system shuts down if it is unable to log security events.
If this security setting is enabled, it causes the system to stop if a security audit cannot be logged for any reason
This security setting determines whether the system shuts down if it is unable to log security events.
If this security setting is enabled, it causes the system to stop if a security audit cannot be logged for any reason
Problem damit: auch das arbeitet in diesem Fall nicht korrekt! Das machte diesen minint-Trick zur Trumpfkarte für alle Hacker, die Ihre Spuren verschleiern wollten. Keine Ahnung, seit wann das so gearbeitet hat, aber mittlerweile ist es gepatcht - das Logging trägt die Events zumindest nach, nachdem man den Minint-Key wieder entfernt hat und neu gestartet hat.
Im Video ist dies ausfürhlich dargestellt. Wer's mal selbst austesten will, nimmt z.B. einen naturbelassenen Server 2019 (Build 17763.1 oder .55).
Und was soll der MiniNT-Key überhaupt? Er ist für Windows-Setup (WinPE) und Recoveryenvironments gedacht und wird dort automatisch gesetzt, um kein unnötiges Logging anlaufen zu lassen. Da Microsoft bequem ist, nehmen sie den selben Code in WinPE wie in Windows und MiniNT wirkt in beiden, obwohl MS das nie und nimmer beabsichtigt.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5265049819
Url: https://administrator.de/knowledge/windows-security-eventlog-war-umgehbar-5265049819.html
Ausgedruckt am: 02.04.2025 um 22:04 Uhr
3 Kommentare
Neuester Kommentar
Interesant an diesem Patch ist, dass ich nun einige Clients habe wo das Log innerhalb kurzer Zeit volläuft und das Überschreiben der Logs sich immer wieder deaktiviert nach einem Neustart. Es gibt zwar einen Workaround, allerdings hoffe ich das MS das bald patcht.
Minint ist schon ca. seit 6 Monaten gepatcht. Seitdem hast du dieses Problem?
Update:
Auf Server 2022 und vNext läuft die Option "Runterfahren wenn nicht geloggt werden kann" immerhin soweit, dass der Server wie gedacht bluescreent, wenn das Security-Log voll läuft. Auf Server 2019 (gepatcht) funktioniet das weiterhin nicht. Somit müsste ein Angreifer mit lokalen Adminrechten nur den Dienst "Windows Eventlog" killen, dann das Log vollschreiben mit Murks und wenn der Dienst dann wieder startet, kann der Angreifer nach Belieben schalten und walten, ohne das geloggt wird. Ggf. gesetzte Tasktrigger für bestimmte Events werden nicht nachgeholt auf Server 2019 (auf 2022 und vNext schon!). Das ist ein schwaches Bild auf 2019 Server.
Auf Server 2022 und vNext läuft die Option "Runterfahren wenn nicht geloggt werden kann" immerhin soweit, dass der Server wie gedacht bluescreent, wenn das Security-Log voll läuft. Auf Server 2019 (gepatcht) funktioniet das weiterhin nicht. Somit müsste ein Angreifer mit lokalen Adminrechten nur den Dienst "Windows Eventlog" killen, dann das Log vollschreiben mit Murks und wenn der Dienst dann wieder startet, kann der Angreifer nach Belieben schalten und walten, ohne das geloggt wird. Ggf. gesetzte Tasktrigger für bestimmte Events werden nicht nachgeholt auf Server 2019 (auf 2022 und vNext schon!). Das ist ein schwaches Bild auf 2019 Server.
