Beveiliging werkt pas echt wanneer aanvallers niet alleen toegang krijgen tot een systeem, maar ook vastlopen op de plekken waar je gegevens en bedrijfs- of gebruikersgeheimen moeten blijven beschermd. Dat idee staat centraal in het concept Windows VBS-enclave: een geïsoleerd stuk geheugen dat bedoeld is om “af te schermen” wat erin staat. Toch toonden onderzoekers onlangs aan dat zo’n enclave in theorie te doorbreken is—met duidelijke kanttekeningen.
In een labopstelling als proof of concept lieten Doyensec zien hoe code binnen een beschermde enclave kon worden uitgevoerd. Het ging om een fout in een component achter Enhanced Phishing Protection van Microsoft Defender SmartScreen. Microsoft heeft de kwetsbaarheid inmiddels gepatcht.
Wat is een Windows VBS-enclave en waarom is die afgeschermd?
Een Windows VBS-enclave is ontworpen als een veilige “wereld” voor gevoelige onderdelen. Microsoft beschrijft het als een geïsoleerd geheugenpad dat bedoeld is om geheimen te bewaken, zelfs als een aanvaller al verder is doorgedrongen in het systeem.
Praktisch werkt het zo dat normale applicaties een getekende library kunnen laden, maar die code of data kan niet zomaar gelezen of aangepast worden zodra de enclave draait. De scheiding wordt bewaakt door de Windows-hypervisor, waarbij het geheugen van de enclave in een meer vertrouwde context wordt gehouden (VTL1 / Isolated User Mode), terwijl reguliere code in de normale context (VTL0) niet bij die enclave kan komen.
De relevantie voor verdediging is duidelijk: als je een aanvaller al “in de buurt” hebt laten komen—bijvoorbeeld via een systeemcompromis—wil je nog steeds voorkomen dat die aanvaller zomaar direct in de beschermde wereld kan schrijven of uitvoeren.
Welke kwetsbaarheid speelde erachter en waar zat het probleem?
De onderzochte fout is geregistreerd als CVE-2026-83498. Microsoft classificeert het als een elevation-of-privilege-kwestie met een Critical ernst en een CVSS-score van 7,8.
Volgens Microsoft was de issue niet eerder publiek bekend en is er geen bewijs van misbruik gezien vóór de fix. De onderzoeksresultaten zijn gepubliceerd op 13 oktober 2026, ruim na Microsofts patch.
De aanval richtte zich op een specifieke enclavecomponent: SFAPE.dll. Die component is betrokken bij Enhanced Phishing Protection in Microsoft Defender SmartScreen.
Enhanced Phishing Protection: hoe wordt een wachtwoord afgeschermd?
Enhanced Phishing Protection probeert phishing te blokkeren door te waarschuwen als je Windows-aanmeldgegevens in een onveilige context terechtkomen. Denk aan het plakken van je inlogtekst in een programma zoals Kladblok, of in een phishingpagina.
Om te voorkomen dat wachtwoorden blootkomen, onderschept Windows het invoermoment bij de login en bewaart het in gehashte vorm binnen de enclave. Later kan Windows toetsen of nieuwe invoer overeenkomt met wat eerder als “wachtwoordachtig” is vastgelegd.
Op een Windows 11-systeem is de proceslogica voor die enclave-lader gekoppeld aan lsass.exe. Dat proces beheert aanmeldingsgegevens en draait als SYSTEM—wat het extra relevant maakt dat de enclave juist ook in die omgeving veilig moet blijven.
Waarom dit onderzoek zo opvalt: code draaien in de beveiligde wereld
Onderzoekers lieten zien dat je in een labsetting de isolatie van de enclave kunt doorbreken. Het is belangrijk dat dit niet werkt zoals een “klassieke externe hack”. De aanval heeft een lokale component: je hebt al toegang nodig tot de machine om een proces te starten dat de enclave-lading en de functies kan aanroepen.
Microsoft benadrukte ook dat er geen gebruikersinteractie nodig was. Met andere woorden: het gaat om het misbruiken van een pad dat al op het systeem aanwezig is, in plaats van een techniek waarmee je van buitenaf direct de enclave kunt benaderen.
Dat maakt het onderzoek waardevol voor verdedigers: het toont welke klasse fouten—combinaties van geheugenoperaties en timing—een veilige “gescheiden wereld” kunnen raken wanneer die wereld ondanks alles toch ergens aanroeppunten heeft.
De kern: vier-byte write, timingbug en het omzeilen van checks
De aanpak van Doyensec werd stapsgewijs opgebouwd. Een eerste stap bestond uit het tweemaal aanroepen van een Initialize-achtige functie van de enclave. In het lab resulteerde dat in het schrijven van een vast vier-byte foutwaarde naar een adres dat gecontroleerd kan worden door het aanroepende programma. Daarbij werd bij het tweede aanroepen een adrescheck overgeslagen.
Doyensec gaf zelf aan dat “arbitrary write” alleen op zichzelf niet voldoende is om volledige controle te claimen. Het echte probleem ontstond wanneer die ene gerichte corruptie net genoeg bleek om een veiligheidsmechanisme in de enclave te beschadigen: de check die onderscheid moet maken tussen enclavegeheugen en hostgeheugen viel weg.
Daarna kwam een timing bug in een andere enclavefunctie in beeld. Die fout kon leiden tot een gecontroleerde “wipe” (geheugenopschoning/omleiding) die vervolgens beïnvloedde hoe de enclave een eerder opgeslagen object opzoekt.
Het gevolg: de onderzoekers konden de interne tabel die bepaalt welke code de enclave mag uitvoeren, vervangen. Daarmee konden ze aanvallerkeuze code laten draaien binnen de enclave. Microsoft beschreef het effect in termen van data leakage uit of code execution binnen de enclave, zonder aan te tonen dat een wachtwoord van gebruikers in het onderzoek daadwerkelijk is uitgelezen of gestolen.
Wat deed Microsoft en welke systemen zijn aangepakt?
Microsoft repareerde het probleem in de cumulatieve update van 8 september 2026. Daarbij ging het om de fix in KB5124008 voor Windows 11 versies 24H2 en 25H2.
Er is geen aparte work-around genoemd: de instructie is om de update te installeren.
Bij de vergelijking van oude en nieuwe bestanden merkte Doyensec op dat de gepatchte enclave de relevante eerste adrescontrole alsnog uitvoert en ook de functie die de timingbug gebruikte strakker beperkt.
Daarnaast is er een beleid toegevoegd dat voorkomt dat de kwetsbare versie van de enclave überhaupt nog kan laden. Dat is extra relevant omdat het niet alleen een bugfix is, maar ook een guardrail: een gepatchte machine zou de oude (kwetsbare) enclave niet meer mogen uitvoeren.
Blijft er een gat over? “Bring your own vulnerable enclave”
Hoewel SFAPE.dll is geblokkeerd in de nieuwe policy, ziet Doyensec één belangrijke tekortkoming: Windows lijkt geen algemene blocklist te hebben voor alle kwetsbare enclaves, zoals het dat (in vergelijkbare vorm) wél doet bij kwetsbare drivers.
Concreet: een oudere Microsoft Edge enclave met een vergelijkbaar read/write-foutklasse (CVE-2023-36880) werd volgens de onderzoekers nog steeds toegestaan om te laden.
Of dit een bewuste keuze is of een omissie, is niet duidelijk. Wat er wél toe doet: het patroon “bring your own vulnerable enclave”—het idee dat een aanvaller een getekende maar foutieve enclave kan laten laden om beveiligingscontrole om te buigen—blijft mogelijk wanneer niet elke relevante enclave tegelijk wordt uitgefaseerd of geblokkeerd.
Praktische lessen voor organisaties
Dit onderzoek is geen reden om enclaves als concept af te schrijven. Het is wel een waarschuwing om beveiliging te blijven zien als een keten van aannames. Als een systeemcomponent uiteindelijk toch een aanroep- of initialisatiepad heeft richting een enclave, dan kunnen fouten in volgorde, timing of geheugenvalidatie een ernstig scenario opleveren.
- Patch op tijd: installeer de relevante Windows updates, in dit geval KB5124008 voor de genoemde Windows 11 versies.
- Minimaliseer lokale aanvalskansen: omdat de aanval een lokaal pad vereist, helpt het beperken van “low-level access” en het controleren van proces- en privilegepaden.
- Monitor beveiligde componenten: niet alleen voor malware, maar ook voor verdachte integraties rond beschermingscomponenten zoals SmartScreen-gerelateerde modules.
- Focus op hardening: beleid dat kwetsbare enclavevarianten blokkeert, is een voorbeeld van defense-in-depth; verwacht dit soort guardrails ook in andere componenten.
Als je daarnaast breder kijkt naar hoe “trusted execution” en bescherming in praktijk onder druk komen, kan het nuttig zijn om ook te lezen hoe Microsoft of andere partijen reageren op vergelijkbare beveiligingsketens. Bijvoorbeeld: Microsoft Patch Tuesday fixes laten zien hoe snel kwetsbaarheden in realiteit worden afgedekt.
Gerelateerde context: van phishingbescherming tot echte dreigingsketens
SFAPE.dll en Enhanced Phishing Protection zitten in de beveiligingslaag die gebruikersinput moet beoordelen zonder wachtwoorden bloot te geven. Dat maakt deze case extra interessant: het gaat niet om “algemene malwarecapabilities”, maar om een onderdeel van een beveiligingsfunctie.
Voor organisaties die phishing en credential misbruik als prioriteit behandelen, is dit type onderzoek een extra reden om te zorgen dat beveiligingscomponenten zelf up-to-date blijven en dat de omgeving niet te veel ruimte biedt aan lokale, onbedoelde interacties.
Wil je nog meer voorbeelden van hoe beveiligingsmechanismen aan het einde toch kunnen botsen op implementatie- en integratiebugs, dan sluiten onderwerpen zoals enclave-achtige bescherming en beschermingslogica vaak aan op bredere supply chain of runtime risico’s. Een vergelijkbaar denkkader rond het stoppen van misbruik van privileges met moderne controles is terug te zien in AI-gedreven privilege escalatie met runtime identity.
Conclusie
Het Windows VBS-enclave-onderzoek van Doyensec laat zien dat beveiligde enclaves in theorie te doorbreken zijn wanneer timing- en write-fouten samenkomen op een manier die veiligheidschecks ondermijnt. De impact in het beschreven labscenario ging verder dan alleen “foutjes”: de onderzoekers konden code laten draaien binnen de afgeschermde wereld, zij het zonder bewijs dat gebruikerswachtwoorden echt werden gestolen.
Voor verdedigers is de boodschap helder: installeer de patch (KB5124008) voor Windows 11 24H2 en 25H2, en beschouw enclavebescherming als onderdeel van een bredere hardeningstrategie. Tegelijkertijd blijft er aandacht nodig voor lacunes wanneer niet alle kwetsbare enclaves even strikt worden geblokkeerd.
Bron: https://thehackernews.com/2026/10/four-byte-write-and-timing-bug-let.html
