Von Blaster bis BlueHammer: Wiederholt sich die Geschichte bei Microsoft?

Seit einigen Wochen gibt es ja einen ziemlichen Disput zwischen einem Sicherheitsforscher mit dem Alias Nightmare Eclipse und dem Microsoft Security Response  Center-Team (MSRC-Team). Es geht um die Art, wie Sicherheitslücken gemeldet, bewerte und behoben werden. Und es geht um die Frage, welche Priorität Sicherheit bei Microsoft heute noch – abseits von schönen "Sonntags-Papieren" wirklich hat.  Von einem Leser sind mir einige Gedanken und Erinnerungen zugegangen, die die Frage aufwerfen, ob sich eine schlechte Geschichte aus den 2000er Jahren derzeit bei Microsoft wiederholt.

Rückblick: Microsoft und seine Sicherheitskultur

Wir erleben in den letzten 3-4 Jahren ja wiederholt, dass Microsoft als Unternehmen und mit seinen Produkten "keine gute Figur macht", wenn es um Sicherheitsfragen geht. Ich erinnere an den Fall, wo die mutmaßlich chinesische Gruppe Storm-0558 Microsofts Cloud- und Outlook-Online-Konten hacken und in der Microsoft Cloud-Infrastruktur auf beliebige Konten zugreifen konnte. Den Fall hatte ich 2023 im Beitrag China-Hacker (Storm-0558) in Microsofts Cloud, Outlook Online-Konten gehackt angesprochen.

Sicherheitsfails bei Microsoft

Dann gab es kurz danach den Fall eines Angriffs der mutmaßlich russischen Gruppe Midnight Blizzard, die ebenfalls in der Microsoft-Cloud über Monate unbemerkt "umher spazieren" konnten. Ich hatte dies 2024 im Beitrag Microsoft durch russische Midnight Blizzard gehackt; E-Mails seit Nov. 2023 ausspioniert aufgegriffen. In diesen zwei herausgepickten Fällen kristallisierten sich im Nachgang haarsträubende Versäumnisse Microsofts heraus. Was macht Microsoft – man kündigt Verbesserungen an (siehe Microsoft Ankündigung einer Secure Future Initiative). Alles wird besser?

Nightmare Eclipse und das Öl ins Feuer gegossen

Springen wir ins Jahr 2026 und dem Fall Nightmare Eclipse. Die betreffende Person meldete wohl Schwachstellen an das Microsoft Security Response Center (MSRC). Dabei muss etwas vorgefallen sein, was derzeit nicht öffentlich bekannt ist, aber zu einem Zerwürfnis führte. Unter dem Strich führte dies dazu, dass Nightmare Eclipse seit März 2026 in schöner Regelmäßigkeit Schwachstellen in Microsofts Produkten als 0-days mit Exploit veröffentlicht.

Der letzte Artikel hier im Blog ist Windows Defender-Schwachstelle RoguePlanet durch Nightmare Eclipse offengelegt – aber ich habe am Beitragsende die thematisch zugehördenen Artikeln verlinkt, so dass die Themen Storm-0558, Midnight Blizzard als auch Nightmare Eclipse mit allen Verästelungen nachlesbar sind.

Statt den mit den Veröffentlichungen ins Spielfeld geworfenen Ball aufzugreifen, zu deeskalieren und zu handeln, verstieg sich das Management des MSRC zu Vorwürfen gegenüber Nightmare Eclipse, sperrte dessen GitHub-Konto, und ließ ein GitLab-Konto und mutmaßlich auch Konten auf Blogger.com offline nehmen. Gipfel war ein Post eines MSRC-Verantwortlichen, der Nightmare Eclipse ein "unverantwortliches Handeln" durch die unkoordinierte Offenlegung vorwarf und mit der Rechtsabteilung samt Strafverfolgung drohte (siehe Nightmare Eclipse auf GitLab gebannt; Microsoft nimmt Stellung).

In der Sicherheitscommunity war Microsoft in diesem Augenblick "unten durch", alles, was vielleicht über Jahre an Vertrauen aufgebaut worden war, war binnen Sekunden pulverisiert. heise hatte das die Tage in einem Beitrag mit dem Titel "Warum Microsofts Umgang mit Zero-Day-Veröffentlichungen Vertrauen zerstört" aufgegriffen (leider Paywall, daher nicht verlinkt). Im Artikel wurde die Entwicklung um Nightmare Eclipse nachgezeichnet.

Der Tenor des heise-Beitrags war ebenfalls: "Microsoft begibt sich in einen wenig rational wirkenden Zwist mit einem Sicherheitsforscher und verspielt dabei das restliche Vertrauen der Security-Community." Im Artikel wurde auch auf obigen BlueSky-Post von Katie Moussouris verwiesen. Moussouris ist Gründerin von LutaSecurity und hatte bei Microsoft das Bug Bounty-Programm etabliert. Sie schrieb, dass Microsoft nicht wieder den "Responsible Disclosure-Scheiß" hervorkramen solle.

Kein Anbieter verwende diesen Begriff, es sei denn, er will jemanden als unverantwortlich bezeichnen. Selbst wenn jemand einen 0-Day veröffentlicht: Patch installieren und weitermachen, war die Botschaft. Einen Sicherheitsforscher zu verfolgen sei ein toller Weg, um aus einer schlechten Beziehung viele schreckliche Beziehungen zu machen.

Moussuris spielt wohl auch auf den Beitrag Coordinated Vulnerability Disclosure: Bringing Balance to the Force von Microsoft aus dem Jahr 2010 an, wo es heißt: "Responsible Disclosure" sollte zugunsten eines Ansatzes aufgegeben werden, bei dem es darum geht, das eigentliche Ziel zu erreichen, nämlich die Sicherheit zu verbessern und Nutzer sowie Systeme zu schützen. Und damit sind wir beim Kern – das MSRC hat dieses Ziel wohl verlernt oder aus den Augen verloren, weil die falschen Leute an den relevanten Stellen sitzen.

Wiederholt sich die Geschichte bei Microsoft?

Kommen wir zu den Gedanken, die mir Blog-Leser Thomas Bittner kürzlich geschickt hat. Thomas ist Ex-MVP-Kollege und bezeichnet sich als "Retired IT Expert and former Investment Banker". Wir tauschen uns seit Jahren, manchmal auch mit Ex-MVP Mark Heitbrink oder MVP Frank Carius, hinter den Kulissen über Blog-Themen aus, obwohl wir beiden uns niemals (zumindest mir nicht erinnerlich) auf einem der MVP-Treffen bei Microsoft Deutschland begegnet sind.

Thomas Bittner hat die Entwicklung bei Microsoft aus Sicht eines IT-Experten seit 2000 wesentlich intensiver als meine Wenigkeit verfolgt. Während ich Bücher über Windows als "Anwendersicht" geschrieben habe, musste er sich mit dem Einsatz der Produkte in Unternehmensumgebungen herumschlagen. Aus dieser Zeit sind ihm Dinge erinnerlich, die ich vergessen habe oder nie auf dem Radar hatte. Daher freut es mich, dass Thomas Bittner mir seine Zustimmung erteilt hat, seinen nachfolgenden Beitrag, den er auf LinkedIn veröffentlicht hat (hier nicht verlinkt, da nicht ohne Konto abrufbar), hier im Blog als Gastbeitrag einstellen zu dürfen. Nachfolgend sein Text.

Retired IT Expert and former Investment Banker
June 1, 2026

Von Blaster bis BlueHammer: Wiederholt sich die Geschichte bei Microsoft?
Warum die aktuelle Zero-Day-Debatte erstaunliche Parallelen zur Sicherheitskrise Anfang der 2000er Jahre aufweist

Wer die aktuelle Auseinandersetzung zwischen Microsoft und Sicherheitsforschern rund um öffentlich diskutierte Zero-Days verfolgt, könnte den Eindruck gewinnen, es handele sich um ein modernes Problem der KI-Ära.

Tatsächlich zeigen sich jedoch bemerkenswerte Parallelen zu einer Zeit, die viele Administratoren, MVPs, IT-Profis und Sicherheitsforscher noch sehr gut in Erinnerung haben: die Sicherheitskrise von Microsoft Anfang der 2000er Jahre.

Damals wie heute steht nicht nur die Frage im Raum, ob einzelne Schwachstellen existieren. Vielmehr geht es um Verantwortung, Sicherheitskultur, organisatorische Prozesse und das Verhältnis zwischen Hersteller, Forschern und Kunden.

Der Unterschied: Vor zwanzig Jahren führte diese Debatte zu einer der größten sicherheitskulturellen Transformationen der IT-Geschichte. Die Frage ist, ob heute erneut ein solcher Wendepunkt bevorsteht.

Die Zeit vor "Trustworthy Computing"

Anfang der 2000er Jahre war Microsoft der dominierende Anbieter von Desktop-Betriebssystemen und Unternehmenssoftware. Gleichzeitig galt Windows als bevorzugtes Angriffsziel für Malware. Würmer wie:

• Code Red
• Nimda
• Blaster
• Sasser

legten weltweit Netzwerke lahm, beeinträchtigten Unternehmen und verursachten Schäden in Milliardenhöhe. Damals wurde zunehmend öffentlich formuliert: Microsoft kann sich seiner Verantwortung für die Sicherheit seiner Produkte nicht entziehen. Diese Forderung kam nicht nur von Sicherheitsforschern. Sie kam von:

• Administratoren,
• Unternehmenskunden,
• Behörden,
• MVPs,
• IT-Medien,
• und großen Teilen der Sicherheitscommunity.

Der Kern der Kritik lautete: Sicherheit darf nicht länger nachträglich eingebaut werden. Sie muss Teil des Entwicklungsprozesses sein.

Bill Gates zieht die Notbremse

Im Januar 2002 verschickte Bill Gates sein berühmtes "Trustworthy Computing"-Memo. Darin erklärte er Sicherheit und Zuverlässigkeit zur höchsten Priorität des Unternehmens.
Für Microsoft war dies ein radikaler Kurswechsel.

• Entwicklungsteams wurden teilweise gestoppt.
• Tausende Entwickler mussten Sicherheitstrainings absolvieren.
• Code wurde überprüft und überarbeitet.
• Produkte wurden verzögert ausgeliefert, um Sicherheitsmängel zu beseitigen.

Aus heutiger Sicht erscheint das selbstverständlich. [GB: Hier würde ich inzwischen sagen, es wird nur auf dem Papier als "selbstverständlich" dargestellt – die Wirklichkeit sieht leider anders aus.] Damals war es revolutionär.

Microsoft akzeptierte erstmals öffentlich: Sicherheit ist keine optionale Eigenschaft eines Produkts.

Die Folgen waren enorm

Aus dieser Phase entstanden viele Verfahren, die heute Standard sind:

• Security Development Lifecycle (SDL)
• strukturierte Threat Models
• verpflichtende Security Reviews
• sichere Standardeinstellungen
• zentralisierte Updates
• Patch Tuesday
• moderne Compiler-Schutzmechanismen
• systematische Schwachstellenanalyse

Man kann durchaus argumentieren: Ein erheblicher Teil moderner Enterprise-Sicherheit entstand aus dieser Krise.

• Die damalige Kritik hatte Wirkung.
• Nicht weil Microsoft freiwillig handelte.

Sondern weil Kunden, Experten und Öffentlichkeit ausreichend Druck erzeugten.

Die aktuelle Situation wirkt vertraut

Heute erleben wir erneut eine Phase intensiver Diskussionen über:

• ungepatchte Zero-Days,
• die Priorisierung von Schwachstellen,
• den Umgang mit Sicherheitsforschern,
• öffentliche Offenlegungen,
• Bug-Bounty-Prozesse,
• und die Kommunikation zwischen Herstellern und Forschern.

Die konkreten technischen Details unterscheiden sich von den Problemen der frühen 2000er Jahre. Die Grundfragen sind jedoch erstaunlich ähnlich:

• Wer trägt Verantwortung?
• Wie transparent wird kommuniziert?
• Werden Sicherheitsforscher als Partner oder als Störfaktor behandelt?
• Haben Sicherheitsprobleme die gleiche Priorität wie Geschäftsziele?

Diese Fragen standen bereits vor über zwanzig Jahren im Zentrum der Debatte.

Der große Unterschied: Damals war das Problem der Code

Die Sicherheitskrise der frühen 2000er Jahre war vor allem ein Problem der Softwarequalität. Viele Schwachstellen entstanden durch:

• Pufferüberläufe,
• unsichere Standardkonfigurationen,
• fehlende Eingabevalidierung,
• mangelnde Secure-Coding-Praktiken.

Das Problem war technisch greifbar [GB: und dadurch technisch lösbar]. Mehr Sicherheit bedeutete:

• besseren Code schreiben,
• Prozesse einführen,
• Entwickler schulen.

Microsoft konnte darauf reagieren. Und tat es auch.

Heute ist das Problem die Komplexität

Moderne Microsoft-Plattformen bestehen nicht mehr nur aus Windows.
Sie umfassen:

• Windows
• Microsoft 365
• Azure
• Defender
• Entra ID
• Copilot
• Cloud-Dienste
• APIs
• Open-Source-Komponenten
• KI-Modelle

Die Angriffsfläche ist exponentiell gewachsen. Gleichzeitig hängen viele Organisationen nahezu vollständig von diesem Ökosystem ab. Dadurch verändert sich die Natur der Verantwortung. Vor zwanzig Jahren musste Microsoft vor allem seine Produkte sichern.
Heute muss Microsoft ganze digitale Ökosysteme absichern.

Die KI-Revolution verschärft alles

Hier endet die historische Parallele und eine neue Phase beginnt. Vor zwanzig Jahren waren Sicherheitsforscher die knappe Ressource. Heute wird Schwachstellenanalyse zunehmend automatisiert. Moderne KI-Systeme können:

• Quellcode analysieren,
• Muster erkennen,
• Schwachstellen identifizieren,
• Exploit-Ketten vorbereiten,
• Sicherheitsprüfungen skalieren.

Die Folge:

• Die Entdeckung von Schwachstellen wird schneller.
• Patch-Prozesse bleiben jedoch weitgehend menschlich.
• Dadurch entsteht ein neues Ungleichgewicht.

Während früher die Suche nach Schwachstellen der Engpass war, werden künftig wahrscheinlich [GB: folgende Punkte]:

• Priorisierung,
• Qualitätssicherung,
• Testing,
• Freigaben,
• Kommunikation
• und Patch-Verteilung

zum eigentlichen Flaschenhals.

Die eigentliche Parallele: Es geht wieder um Kultur

Viele Diskussionen konzentrieren sich auf einzelne Zero-Days. Historisch betrachtet könnte das zu kurz greifen. Die wichtigste Parallele zu 2002 liegt möglicherweise nicht in den Schwachstellen selbst. Sondern in der Frage: Hat die Sicherheitskultur eines Unternehmens mit der Realität Schritt gehalten?

Damals führte diese Frage zu "Trustworthy Computing". Heute stellt sie sich erneut. Allerdings unter deutlich schwierigeren Bedingungen:

• größere Systeme,
• globale Cloud-Infrastrukturen,
• KI-gestützte Angriffe,
• regulatorische Anforderungen,
• geopolitische Spannungen,
• Lieferkettenrisiken.

Die technische Herausforderung ist größer als jemals zuvor.

Von der Produktsicherheit zur Infrastrukturverantwortung

Ein weiterer Unterschied ist die gesellschaftliche Bedeutung. 2002 war Microsoft ein Softwarehersteller. 2026 ist Microsoft zusätzlich:

• Cloud-Anbieter,
• Identitätsprovider,
• Sicherheitsanbieter,
• KI-Anbieter,
• Kommunikationsplattform,
• und für viele Organisationen faktisch Teil kritischer Infrastruktur.

Dadurch steigen die Erwartungen. Wenn ein dominanter Anbieter Sicherheitsprobleme hat, betrifft das nicht nur einzelne Kunden. Es betrifft:

• öffentliche Verwaltungen,
• Krankenhäuser,
• Energieversorger,
• Bildungseinrichtungen,
• Industrieunternehmen,
• und ganze Volkswirtschaften.

Die Verantwortung ist heute wesentlich größer als vor zwanzig Jahren.

Die Lehre aus der Vergangenheit

Die Geschichte zeigt etwas Bemerkenswertes: Die Sicherheitsverbesserungen bei Microsoft entstanden nicht allein durch technische Innovation. Sie entstanden durch:

• öffentliche Kritik,
• Kundenanforderungen,
• Sicherheitsforscher,
• Medienberichte,
• Community-Druck,
• und die Einsicht, dass Sicherheit zur Kernaufgabe werden musste.

Genau diese Dynamik ist heute erneut sichtbar. Die damalige Botschaft lautete: "Ihr steht in der Verantwortung und könnt Euch dieser Verantwortung nicht entziehen." Sie war vor über zwanzig Jahren richtig. Und sie ist heute möglicherweise aktueller denn je.

Fazit

Die aktuelle Zero-Day-Debatte sollte nicht isoliert betrachtet werden. Historisch betrachtet erinnert sie an den Moment, der vor über zwanzig Jahren zur Trustworthy-Computing-Initiative führte. Damals erkannte Microsoft, dass Sicherheit nicht nur ein technisches Problem war, sondern eine Frage von Kultur, Prozessen und Verantwortung.
Heute stellt sich dieselbe Frage erneut. Der Unterschied ist lediglich die Größenordnung:

• Damals ging es um Betriebssysteme.
• Heute geht es um globale digitale Ökosysteme.
• Damals suchten Menschen nach Schwachstellen.
• Heute unterstützen KI-Systeme diese Suche.
• Damals war Microsoft Softwareanbieter.
• Heute ist Microsoft Teil der digitalen Infrastruktur ganzer Staaten und Volkswirtschaften.

Gerade deshalb sind die aktuellen Diskussionen um Zero-Days, Sicherheitsforschung und Transparenz weit mehr als technische Detailfragen. Sie könnten sich rückblickend als ein ähnlicher Wendepunkt erweisen wie die Sicherheitskrise, die Anfang der 2000er Jahre zu "Trustworthy Computing" führte.

Ähnliche Artikel:
BlueHammer: Windows 0-day-Schwachstelle
BlueHammer-Nachlese: Defender-Patch vom 14.4.2026 und Analyse von Fortra
RedSun: Nächste Windows Defender 0-Day-Schwachstelle
Chaotic Eclipse zwei 0-Day-Windows Schwachstellen (YellowKey, GreenPlasma), eine in MS Teams
Nightmare Eclipse veröffentlicht MiniPlasma-Schwachstelle CVE-2020-17103
Zoff und Schwarze-Peter-Spiel zwischen 'Microslop' und Chaotic Eclipse
Nightmare Eclipse auf GitLab gebannt; Microsoft nimmt Stellung
Microsoft versus Nightmare Eclipse: Wir haben jetzt "Bitskrieg"
BlackHat 2026 in Vegas: Tritt das MSRC gerade in das nächste Fettnäpfchen?
Windows: Details zur Bitlocker-Schwachstelle "Bitskrieg"

China-Hacker (Storm-0558) in Microsofts Cloud, Outlook Online-Konten gehackt
Nachlese zum Storm-0558 Cloud-Hack: Microsoft tappt noch im Dunkeln
Nach CISA-Bericht zum Storm-0558-Hack stellt Microsoft Kunden erweitertes Cloud-Logging bereit
GAU: Geklauter AAD-Schlüssel ermöglichte (Storm-0558) weitreichenden Zugang zu Microsoft Cloud-Diensten
Microsofts Cloud-Hack: Überprüfung durch US Cyber Safety Review Board
Microsoft Cloud-Hack durch Storm-0558: US-Senatoren unter den Opfern; Prüfpflicht für europäische Verantwortliche
Mehr als 60.000 E-Mails des US-Außenministeriums beim Microsofts Storm-0558 Cloud-Hack abgegriffen

Sicherheitsrisiko Microsoft? Feuer von der US-Politik nach Microsofts Azure Cloud-GAU und Forderung zum Microsoft Exit – Teil 1
Sicherheitsrisiko Microsoft? Azure-Schwachstelle seit März 2023 ungepatcht, schwere Kritik von Tenable – Teil 2

Hewlett Packard Enterprise (HPE) von Midnight Blizzard seit Mai 2023 gehackt
Whistleblower: Microsoft ignorierte Warnungen vor Azure AD-Bug; wurde 2020 bei SolarWinds-Hack ausgenutzt
Microsoft durch russische Midnight Blizzard gehackt; E-Mails seit Nov. 2023 ausspioniert
Wie Midnight Blizzard-Hacker in Microsofts E-Mail-System eindringen konnten
Microsoft bestätigt: Russische Spione (Midnight Blizzard) haben Quellcode beim Zugriff auf Systeme gestohlen
Microsoft: Neues vom Midnight Blizzard-Hack – auch Kunden möglicherweise betroffen
Midnight Blizzard-Hack bei Microsoft: US-Behörden und Großkunden suchen Alternativen
Midnight Blizzard-Hack-Benachrichtigung: Microsoft schickt Kunden Mail die in SPAM-Ordnern landet