Stell dir vor, du baust ein Haus und lieferst es ab, aber die Sicherheitsprüfung kommt erst Wochen später. In der Zwischenzeit könnte jeder einsteigen. So ist es auch bei Software: Die Lücke zwischen Auslieferung und Prüfung ist ein Risiko. Bisher hatten Angreifer oft die Nase vorn, weil moderner Code riesig, vernetzt und sich täglich ändert, während Sicherheitsüberprüfungen zu festen Zeitpunkten stattfinden.
Microsoft hat vor einigen Monaten begonnen, diese Zeitspanne zu verkürzen. Mit dem internen Projektnamen MDASH – einem multimodalen, agentenbasierten Scansystem – will das Unternehmen Sicherheitslücken automatisiert entdecken, validieren und beheben lassen. Das Ziel: KI-gestützte Erkennung in einen produktiven Verteidigungsmechanismus zu verwandeln. Das System analysiert proprietären Code von Windows, Hyper-V, Azure und Identitätssystemen. Statt sich auf ein einzelnes Modell zu verlassen, orchestriert MDASH eine Gruppe spezialisierter KI-Agenten. So können Sicherheitsteams kritische Fehler schnell und systematisch aufspüren und die menschliche Prüfung ergänzen.
Die Ergebnisse fließen in Microsoft Defender-Workflows, wo sie neben Bedrohungsinformationen und Laufzeitsignalen priorisiert werden, sowie in GitHub- und Azure-DevOps-Pipelines, wo sie validiert und behoben werden – ein geschlossener Kreislauf. Das System belegte den Spitzenplatz in einem führenden Industriestandard. Seither hat es sich weiterentwickelt. MDASH wird jetzt aktiv von Entwicklungsteams für Windows, Azure und Identitätssysteme genutzt – als Teil echter Sicherheitsworkflows. Dieser Beitrag beschreibt die Entwicklung und die gewonnenen Erkenntnisse.
Vom Labor in die Pipeline
Seit dem Start wird das System von Entwicklungsteams für Windows, Azure und Identitätssysteme genutzt. Sie lassen es parallel zu bestehenden Prozessen laufen und richten es auf schwer prüfbare Oberflächen. Ziel ist es, mit KI-gestützter Analyse tiefer und früher zu prüfen, als es herkömmliche Ansätze erlauben. Die untersuchten Komponenten gehören zu den komplexesten: Windows Kernel, Hyper-V, Azure Virtualisierung und Active Directory Domain Services. Diese Komponenten erfordern tiefes Codeverständnis, das über typische Trainingsdaten hinausgeht. Ein einziger übersehener Fehler auf dieser Ebene kann überproportionale Folgen haben. Das System ersetzt nicht die Teams, sondern erweitert ihre Reichweite.
„MDASH hilft uns, Schwachstellen in Windows mit größerer Analysetiefe zu finden als zuvor.“
– Windows-Sicherheitsteam (Kernel, Hyper-V, Netzwerkstack)
MDASH ist in die DevSecOps-Prozesse integriert. Es läuft parallel zu bestehenden Workflows. Validierte Funde erscheinen als Code-Scanning-Warnungen in GitHub Advanced Security, blockieren Pipelines in Azure DevOps und werden in Microsoft Defender priorisiert. Jeder Fund wird wie eine Codeänderung behandelt: mit Besitzer, Pull Request und Korrektur. Das stärkt den Entwicklungszyklus, ohne zusätzliche Werkzeuge.
Die Entdeckungen dieses Monats
Was ein Sicherheitssystem findet, ist sein wichtigstes Maß. Die aktuellen Patch-Tuesday-Funde umfassen Schwachstellen in Hyper-V, Windows-Kernel, Active Directory Domain Services, Remote Desktop Client, HTTP.sys, DNS-Client und DHCP-Client. Die Angriffsvektoren umfassen Remotecodeausführung, Rechteausweitung und Informationsoffenlegung. Mehrere Funde sind kritische Remotecodeausführungslücken, die manuell schwer zu finden sind. Andere zeigen subtilere Probleme wie Rechteausweitung oder Informationsoffenlegung. Alle wurden gefunden, bevor sie ausgenutzt werden konnten, in Codebereichen, die sonst viel manuelle Arbeit erfordern.
| CVE-ID | Komponente | Typ | Ausnutzungsklasse | CVSS |
|---|---|---|---|---|
| CVE-2026-45607 | Windows Hyper-V | Out-of-bounds Read | Remotecodeausführung | 8.4 |
| CVE-2026-45641 | Windows Hyper-V | Type Confusion | Remotecodeausführung | 8.4 |
| CVE-2026-47652 | Windows Hyper-V | Heap-basierter Pufferüberlauf | Remotecodeausführung | 8.2 |
| CVE-2026-41108 | Windows DNS Client | Heap-basierter Pufferüberlauf | Rechteausweitung | 7.0 |
| CVE-2026-45608 | Windows DHCP Client | Out-of-bounds Read | Informationsoffenlegung | 6.8 |
| CVE-2026-45634 | Windows DHCP Client | Out-of-bounds Read | Informationsoffenlegung | 5.5 |
| CVE-2026-45648 | Windows Active Directory Domain Services | Stack-basierter Pufferüberlauf | Remotecodeausführung | 8.8 |
| CVE-2026-47289 | Remote Desktop Client | Heap-basierter Pufferüberlauf | Remotecodeausführung | 8.8 |
| CVE-2026-45657 | Windows Kernel | Use-after-free | Remotecodeausführung | 9.8 |
| CVE-2026-47291 | HTTP.sys | Integer Overflow | Remotecodeausführung | 9.8 |
Jenseits der Schlagzeile: Was wir daraus gelernt haben
Wie sich das System verbesserte
Um ein System zu verbessern, muss man es messen. Mit CyberGym, einem Benchmark aus 1507 Schwachstellen, konnte das Team schnell Fortschritte messen. Seit der ersten Ankündigung wurde die Pipeline basierend auf Feedback und Tests neu aufgebaut. Die aktuelle Version erreicht 96,5 % (jeglicher Absturz) auf CyberGym, einschließlich Ziel- und Nicht-Ziel-Schwachstellen. Die größten Verbesserungen gab es in den frühen Phasen Prepare und Scan. Das hebt die Qualität aller späteren Schritte. Konkret: eine schärfere Abgrenzung zwischen zu prüfendem und Kontextcode, eine umfassendere Bedrohungsmodellierung zur Identifizierung von Einstiegspunkten, eine bessere Erkennung von Fuzz-Harnessen, ein zuverlässigerer Callgraph und ein intelligenteres Routing zu spezialisierten Agenten.
Die verbleibenden 3,5 % verstehen
Das System erreichte 96,55 % auf CyberGym, verfehlte aber 52 Aufgaben (3,5 %). Die Analyse zeigt, welche Pipeline-Stufe zu jedem Fehlschlag beigetragen hat: Scan-Stufe: 8 Fälle (15,4 %), Validate-Stufe: 10 Fälle (19,2 %), Prove-Stufe: 34 Fälle (65,4 %). In der Scan-Stufe traten Fehler durch ungenaue Bereichsdefinitionen aus mehrdeutigen Beschreibungen auf. Beispiel arvo:53536: „Ein Stack-basierter Pufferüberlauf tritt im Code auf, wenn ein Tag gefunden wird und die Ausgabegröße nicht überprüft wird, ob sie innerhalb der Puffergrenzen liegt.“ Das identifiziert den Typ, gibt aber kaum Hinweise, wo in einer großen Codebasis gesucht werden soll. Auch kann das System Komponenten falsch priorisieren – in arvo:23547 liegt die Schwachstelle in einer Lexer/Parser-Komponente, aber das System priorisierte andere C-Codepfade. In der Validate-Stufe wurden Funde bei hypothetischen Beschreibungen zurückgewiesen. In arvo:3569 hatte die Scan-Stufe eine Use-after-Free-Schwachstelle korrekt identifiziert, aber die Validate-Stufe sah keinen machbaren Pfad und wies sie zurück. In der Prove-Stufe stellten stark strukturierte Eingabeanforderungen ein Problem dar. Manche Ziele benötigen komplexe Binäreingaben wie IVF/AV1, WPG, Fonts, PDFs. Das System versuchte fuzzing-basierte Ansätze, die Abstürze fanden, aber keine gültigen Eingaben innerhalb der Zeitvorgaben erzeugten. In einigen Fällen wurden Abstürze lokal reproduziert, ließen sich aber nicht auf die Evaluierungsumgebung übertragen – ein Problem der Umgebungsunterschiede.
Quelle: microsoft.com
Deine Reaktion:
Artikel teilen: