[English]Ende Juni 2025 gab es Meldungen (habe ich jedenfalls so interpretiert), dass Virenscanner in "Bälde" nicht mehr den Kernelmode von Windows verwenden dürfen. Der CrowdStrike-Fall, der Millionen Windows-Systeme lahm legte, war laut Microsoft die endgültige Warnung, den Schritt einzuleiten. Die Frage ist nun, ob wir einen Paradigmenwechsel erleben oder ob es sich um eine Mogelpackung handelt, und was hinter dem Ganzen steckt.
Rückblick: Das CrowsStrike-Desaster
Zum 19. Juli 2024 kam es (ab den frühen Morgenstunden) weltweit zu Ausfällen von ca. 8,5 Millionen Windows-Systemen, auf denen die EDR-Software CrowdStrike Falcon installiert war. CrowdsStrike Falcon ist eine weit verbreitete Enterprise Detection und Response (EDR) Schutzsoftware für Endgeräte.
Die Ursache war ein vom Hersteller ausgerolltes Update für die CrowdsStrike Falcon Sensoren. In Folge wurde auf den betroffenen Systemen ein Bluescreen of Death (BSOD) (mit der Fehlermeldung PAGE_FAULT_IN_NONEPAGED_AREA) ausgelöst. Verantwortlich war die Datei csagent.sys und eine per Update verteilte, fehlerhafte sys-Datei, die von diesem Treiber geladen wurde.
Windows-Systeme, die für einen automatischen Neustart nach einem fatalen Fehler konfiguriert waren, verfielen in eine BSOD-Restart-Schleife. Systeme, die auf dem BSOD verharrten, zeigten den berühmten blauen Bildschirm (BSOD). Ich hatte ausgiebig über dieses Ereignis berichtet (siehe Links am Artikelende) und eine grobe Analyse des Sachverhalts im Beitrag Nachlese des CrowdStrike-Vorfalls, der bisher größten Computerpanne aller Zeiten veröffentlicht.
Microsoft reagiert mit Plänen …
Später gab Microsoft dann zu Protokoll dass man an seiner Windows-Kernelarchitektur Änderungen vornehmen will, um solchen "Kollateralschäden" vorzubeugen (ich hatte dies im Beitrag Microsofts Analyse des CrowdStrike-Vorfalls und Empfehlungen angedeutet).
Zum 12. September 2024 stellte David Weston, Vice President Enterprise and OS Security bei Microsoft, Pläne in dieser Richtung im Beitrag Taking steps that drive resiliency and security for Windows customers vor. Hintergrund war der Windows Endpoint Security Ecosystem Summit am 10. September 2024. Dieses von Microsoft veranstaltete Forum brachte eine Gruppe von Endpunktsicherheitsanbietern und Regierungsmitgliedern aus den USA und Europa zusammen, um Strategien zur Verbesserung der Widerstandsfähigkeit und zum Schutz der kritischen Infrastruktur der gemeinsamen Kunden zu diskutieren.
Microsoft sei von Kunden und Anbietern von Sicherheitslösungen aufgefordert worden, mehr für die Kernelsicherheit zu tun und Mechanismen bereitzustellen, die einen CrowdStrike-Fall verhindern, hieß es. Ich hatte dies im Beitrag Nach CrowdStrike: Microsoft plant Security-Lösungen aus dem Windows-Kernel zu entfernen nachgezeichnet.
Es geht angeblich an die Umsetzung
Zum 26. Juni 2025 erschien bei Microsoft der Artikel The Windows Resiliency Initiative: Building resilience for a future-ready enterprise von David Weston. Dort erwähnte er die Windows Resiliency Initiative (WRI) und die Microsoft Virus Initiative (MVI). Was in Deutschland die "Arbeitskreise" sind, findet bei Microsoft in "Initiativen" ihr Gegenstück. In der MVI sind Hersteller von Antivirus-Software vertreten.
Microsoft verlangt im MVI 3.0-Programm von den Partnern, dass sie sich verpflichten, bestimmte Maßnahmen zur Verbesserung der Sicherheit und Zuverlässigkeit von Windows zu ergreifen. Zu den Anforderungen gehören das Testen von Prozessen zur Reaktion auf Vorfälle und die Einhaltung von SDP-Verfahren (Safe Deployment Practices) für Updates auf Windows-Endpunkten.
Im Juli 2025 stellt Microsoft einer Reihe von MVI-Partnern eine nicht öffentliche Vorschau der Windows-Endpunkt-Sicherheitsplattform zur Verfügung. Die MVI-Partner können damit Lösungen so entwickeln, dass sie außerhalb des Windows-Kernels laufen. Dies bedeutet laut Microsoft, dass Sicherheitsprodukte wie Antiviren- und Endpunktschutzlösungen im Benutzermodus ausgeführt werden können, genau wie Anwendungen.
Der Artikel The Windows Resiliency Initiative: Building resilience for a future-ready enterprise enthält noch Stellungnahmen diverser Hersteller von Antivirus-Lösungen, die das mehr oder weniger freudig begrüßen (und Anbieter Sophos ist erst gar nicht aufgeführt). Zudem gibt Weston noch einen Ausblick auf weitere "Innovationen" aus dem Haus Microsoft (vereinfachte UI für Abstürze von Windows, Microsoft Connected Cache, Universal Print etc.).
In den Medien kam meinem Eindruck nach nur "Microsoft verbannt Virenscanner aus dem Windows-Kernel" an. Heise titelte Microsoft wirft Antivirensoftware aus dem Windows-Kernel, bei WinFuture hieß es Neues Security-Konzept für Windows: Kein Kernel-Zugang für Antivirus, wobei dort der Satz steht, dass sich viele Anbieter vorsichtig geben. Eine klare Verpflichtung zur vollständigen Verlagerung ihrer Sicherheitslösungen aus dem Kernel-Raum gibt es bislang nicht, heißt es. Für Chip ist dagegen klar: Windows radikal: Stehen Virenscanner bald vor dem Aus?
Möchte ich alles nicht klein reden, aber es kommt darauf an, dass alle Sicherheitsanbieter der Branche mitziehen und ihre Virenscanner bzw. Sicherheitslösungen aus dem Kernel raushalten. Martin Geuß von Dr. Windows hat das im Artikel Windows Kernel-Zugriff für Antivirenprogramme: Die Faulheit darf nicht erneut siegen thematisiert und eine interessante Hintergrundinformation beigesteuert. Dort erfährt man, dass die Möglichkeit für Sicherheitssoftware, im Windows Kernel zu laufen, auf Druck der EU zustande kam. Antivirus-Hersteller hatten sich beschwert, als Microsoft mit dem Defender in Windows als Konkurrent auftrat. Während der Defender im Kernel lief, bangten die Sicherheitsanbieter mit ihren User-Mode-Scannern ins Hintertreffen zu gelangen. Jetzt also wieder die Rolle rückwärts und raus aus dem Kernel? Das scheint der – zumindest so kommunizierte – Plan von Microsoft zu sein.
Sicherheitsexperte zur neuen Initiative
Mir ist vor wenigen Stunden dieser Tweet von Sicherheitsexperte Florian Roth untergekommen, in dem er auch nachfolgend das "Versprechen, Virenscanner aus dem Windows-Kernel zu verbannen" aufgegriffen hat.
Roth schreibt, dass Microsofts neue "Sicherheitsinitiative für den Benutzermodus" auf den ersten Blick wie eine notwendige Reaktion auf ein weit verbreitetes architektonisches Risiko aussieht. Doch bei näherem Hinsehen handele es sich hauptsächlich um eine kosmetische Maßnahme. Die Darstellung impliziere, dass die Möglichkeit, Sicherheitslösungen außerhalb des Windows-Kernels laufen zu lassen, irgendwie neu ist – oder dass die meisten Anbieter die ganze Zeit unverantwortlich auf Kernel-Ebene gearbeitet hätten.
Das sei aber nicht wahr, denn die meisten modernen Sicherheitsanbieter führen die Erkennungslogik der Virenscanner bereits im Benutzermodus aus und verwenden nur wenige Kernel-Komponenten für den Selbstschutz. Das sei eine gängige Praxis, so Florian Roth. Worum geht es bei dieser Initiative also wirklich?
Roth schält dann im Tweet heraus, dass es um einen Anbieter – CrowdStrike – geht, dessen Architektur sich über diesen Standard hinwegsetzt. Das Unternehmen bettete die Anpassungslogik in einen Kernel-Mode-Treiber ein. Ein ein fehlerhaftes Update, ausgerollt ohne dass eine ordnungsgemäße interne Prüfung oder ein Test, brachte weltweit Millionen Computer zum Absturz.
Diese eine Entscheidung von CrowdStrike verursachte den weltweiten Ausfall. Microsoft habe den Vorfall nicht verursacht – aber es nutzt ihn jetzt, um seine Botschaft zu unterstreichen: "Der Zugriff von Drittanbietern auf den Kernel ist riskant. Wären sie im Benutzermodus geblieben oder hätten sie unseren Defender verwendet, wäre das alles nicht passiert."
Das Ergebnis? Eine neue Initiative, die sich eher wie eine strategische Positionierung anfühlt als eine Antwort auf einen umfassenden technischen Bedarf, schreibt Roth. Sie befasse sich mit einem Problem, das für die meisten Anbieter nicht existiert (wer setzt schon CrowdStrike ein). Aber jetzt werde es von Microsoft so dargestellt, als ob das Problem existiert und die Sicherheit von Windows bedroht. CrowdStrike war nicht die Norm, so Roth, das Produkt ware der Ausreißer. Und Microsoft hat gerade eine ganze Strategieänderung auf diesem Versagen eines Anbieters aufgebaut.
Lässt zwei Schlüsse für mich zu: Microsoft steht wegen vieler Sicherheitsvorfälle und weiterer Problem mächtig unter Druck. Und die andere Sichtweise könnte zum Schluss kommen, dass die EU-Vorgabe, den Kernel für Sicherheitsanbieter zu öffnen, jetzt auf die elegante Art ins Grab geschickt wurde. Bringt mich zum Schluss, dass da eine schöne Magier-Show veranstaltet wurde, aber unter dem Strich so etwas wie eine Mogelpackung auf der Bühne herum gereicht wird.
Kommentar von Sicherheitsanbieter
Philip Lieberman, CEO und Gründer von Sicherheitsanbieter Analog Informatics hat mir folgenden Kommentar zu obigem Thema zukommen lassen.
Der Schutz der Kernel-Ring-0-Änderung des Windows-Betriebssystems kommt mehr als 30 Jahre zu spät. Wir alle, die in den 1990er Jahren mit Windows NT auf Intel-Prozessoren gearbeitet haben, waren verblüfft, dass Microsoft die Gerätetreiber oberhalb von Ring 0 (privilegierteste) nicht isoliert hat.
Das Design war ein Kompromiss, um frühe Versuche zu unterstützen, Windows plattformübergreifend zu machen und Nicht-Intel-Prozessoren zu unterstützen. Jeder, der Gerätetreiber entwickelt, weiß, dass der kleinste Fehler das Betriebssystem zum Absturz bringt und die Fehlersuche in diesen Treibern bis heute zu einem Albtraum macht.
Es gibt ähnliche Kompromisse aus dieser Zeit, wie z. B. die Tatsache, dass die C2-Sicherheitsarchitektur nie fertiggestellt wurde, um eine bessere Kontrolle von Verschlusssachen zu ermöglichen.
Die Fertigstellung der obligatorischen Zugangskontrollteile des Betriebssystems würde es kommerziellen Unternehmen ermöglichen, den Zugang zu sensiblen Informationen ordnungsgemäß zu kontrollieren, anstatt auf alberne Hacks und Zusatzsoftware angewiesen zu sein, die kaum funktionieren.
Cutler und sein Team haben ein für die damalige Zeit fantastisches Betriebssystem entwickelt. Aber man hat ihnen nie erlaubt, die Vision zu Ende zu führen.
Microsoft hat unsäglich viel Zeit seines eigenen Unternehmens und seiner Kunden damit verschwendet, alberne Benutzeroberflächen einzuführen und Industriestandardtechnologien für die Plattformentwicklung aufzugeben (d. h. das Geschäft mit Windows Phone und eingebetteten Betriebssystemen mit ihren .NET- und Metro-Oberflächen zu zerstören).
Durch diese Fehlentscheidungen und das Versäumnis, auf seine Entwickler und Kunden zu hören, hat Microsoft es Google und Apple ermöglicht, im übertragenen Sinne sein Mittagessen zu essen.
Ihr jüngster Schritt, Windows 10-Nutzer auf dem Altar der "Sicherheit" im Stich zu lassen, ist tragisch komisch, wenn man bedenkt, dass sie jetzt endlich dazu übergehen, den Kern des Betriebssystems zu schützen.
Ähnliche Artikel:
Ausfall von Microsoft 365 und weltweite Störungen – wegen CrowdStrike-Update, was zum BSOD führt?
Wieso weltweit zahlreiche IT-Systeme durch zwei Fehler am 19. Juli 2024 ausfielen
CrowdStrike-Analyse: Wieso eine leere Datei zum BlueSceen führte
Nachlese des CrowdStrike-Vorfalls, der bisher größten Computerpanne aller Zeiten
CrowdStrike: Untersuchungsbericht; Schadenssumme und Entschädigungen; Schuldzuweisungen
Microsofts Analyse des CrowdStrike-Vorfalls und Empfehlungen
Kommunal IT-Dienstleister Südwestfalen-IT nach Cybervorfall und CrowdStrike Bremsspuren endlich wieder arbeitsfähig
CrowdStrike-Nachlese: Neuer Bericht, aktueller Status, Klagen und deren Konter
Erneut Probleme mit CrowdStrike (22. August 2024)
Nach CrowdStrike: Microsoft plant Security-Lösungen aus dem Windows-Kernel zu entfernen




MVP: 2013 – 2016




Virenscanner im Kernel sind immer eine Sicherheitslücke.
https://youtu.be/ZxzvHXT0NXw?si=rqDzrGNIAnDo9oQg
Ist da diese "Anti-Cheat" Software für OnlineGames mit drin?
Ich meine das die auch nicht mehr auf den KernelMode zugreifen darf.
Da werden die Hersteller der Anticheat / Kopierschutz Lösungen schon was finden um darum zu kommen.
Für die Linux Gaming Welt wäre natürlich wünschenswert das sämtliche AntiCheat Lösungen somit stumm geschaltet werden, dann könnte man dem Kram nämlich so implementieren das die Linux Gamer (ich gehöre da auch dazu) mal mehr kompetetive Games zocken können.
Der Witz ist ja, dass diverse AntiCheat Lösungen durchaus Linux kompatibel sind, allerdings müssten die Spielehersteller das bei der Implementierung aktivieren. Und das machen anscheinend nicht so viele.
Ist also mitnichten ein grundsätzlich technisches Problem, sondern die Spielehersteller wollen das nicht.
0patch verwendet auch einen Kernel-Treiber.
Wenn Microsoft Kernel-Treiber sperrt, dann funktioniert 0patch nicht mehr und es gibt mehr Kunden für ESU.
Das ist der interessanteste Punkt an der Angelegenheit!
> 0patch verwendet auch einen Kernel-Treiber. <
Jein.
Die KI sagt: "The driver, named 0patchDriver (either 0patchDriver32.sys or 0patchDriver64.sys), is included with the 0patch Agent. Its sole purpose is to detect when a new user-space process is launched and then load the 0patch DLL into that process … Importantly: … The kernel driver does not process or apply patches itself. All patching happens in user space via the DLL."
Also ohne Kernel Treiber keine 0 Patch Funktionalität? Das dürfte gemeint sein.
> Also ohne Kernel Treiber keine 0 Patch Funktionalität? <
Nein.
Betr. "to detect when a new user-space process is launched" nach 'minimum required permissions' befragt, sagt die KI: "None beyond a standard user account".
ACROS d.o.o. wird sich also einer alffälligen Microsoftschen Verschärfung im Quellcode problemlos anpassen können.
Die "KI" vergisst zu erwähnen, dass 0 Patch mitbekommen MUSS, wenn ein "new user-space process" gestartet wird und über den Kernel Treiber dann seinen Patchcode dort in den user-space Prozess einfügt.
Insofern sieht es schon so aus, dass ohne den Kernel Treiber keine 0 Patch Funktionalität gegeben ist.
Man darf selbst mitdenken, die "KI" erzählt viel, wenn der Tag lang ist…
Ein "standard user account" darf die Betriebssystemdateien im RAM patchen?
Das glaube ich nicht.
Das wäre eine riesige Sicherheitslücke.
Die Betriebssystemdateien auf dem NTFS-Datenträger gehören laut Rechteverwaltung dem "SYSTEM" und nicht dem "Benutzer".
Ein Benutzer hat das Recht zum lesen und ausführen, aber nicht zum ändern.
Ist das im RAM etwa anders und die Rechte werden dort ignoriert?
Bleibt auch die Frage, ob der Defender dann auch angepasst wird und denselben Zugang nutzt wie alle andere.
Wir haben in den letzten Jahren drei Pentests von verschiedenen Firmen durchführen lassen und alle meinten, dass der integrierte Windows Defender sicherer ist als Third-Party-Lösungen. Ich bin mir unschlüssig, was ich davon halten soll.
Ich hatte auch einen Bericht von einem RED-Team gelesen. Die schrieben das Defender XDR das System so gut schützen soll so das ein Pentest nicht funktioniert. Der Defender XDR müsse vorher mit Ausnahmen behandelt werden. Bitte nicht mit dem standard Defender verwechseln.
Was Sie davon halten können: Sie sind gut beraten worden. Eine Angriffsfläche weniger.
Kann ich soweit bestätigen. Man kann den aber nur ernsthaft nutzen, wenn man einen Microsoft-Tenant hat. Denn die Verwaltung funktioniert eigentlich nur per Intune. Ohne zentrales Management ist der Einsatz von Defender Blindflug, weil man die Bedrohungslage im Unternehmen nicht mitbekommt. Außerdem kann man die XDR-Funktionen nicht nutzen und es gibt auch keine Kontrolle über USB-Geräte, soweit ich noch weiß, ist letzteres aber auch im Tenant ziemlich schwer umzusetzen. Das können AVs von Drittanbinder besser.
Bedauerlicherweise existiert beim Thema 'Virenscanner und Kernelzugriff' quer durch alle Fachmedien ein wüstes begriffliches Durcheinander. Ich empfehle Konsultation einer KI der Wahl mit Prompt (1)!
__
(1) Concerning Windows: What is the difference between 'running in Kernel', 'running in Kernel Mode' and 'using Kernel API calls'?
Und woher weiss ich, ob das was die KI sagt jetzt stimmt oder zusammen halluzinierter Bullshit ist?
Ich halte das nicht für realistisch, das wird wie der S mode laufen, es wird eine option für manche sein ein System zu haben in dem nur MS Treiber laufen, einige werden das auch nutzen, die allermeisten werden es links liegen lassen wie vegane Würstchen im Regal.
Es ist so ein unglaublicher Witz.
Die Maßnahmen zur Reparatur solcher "gutwilliger" Crashes sind Augenwischerei geblieben.
Und Security Software wird ausgesperrt. m
Was bleibt, sind alle erfolgreichen Exploits auf dieses nie fertig gehärtete Flickwerk. Weil, ka. Es gab viele lustige Exploits von AV Software, doch wie viel mehr gehen direkt gegen Windows? Wie viele JEDES Jahr?
Und das wird als gut verkauft und die Kunden danken es am Ende noch. Weil ein Bluescreen mehr stört als eine geklaute SAM.
Es ist unglaublich. Aber ich hab 1998 im Helpdesk/ Support angefangen und die Windows Admins damals waren *exakt* gleich drauf… warum, werd ich wohl nie verstehen.