Skip to content
Security & Trust

Doyensec says a 4-byte write bug was the first step to controlling a Windows enclave

Doyensec's lab attack ran from a host process it controlled; the excerpt does not show it against live Defender

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
Doyensec says a 4-byte write bug was the first step to controlling a Windows enclave
In brief
  • In a lab, from a host process it controlled, Doyensec says a four-byte write bug led to full control of an SFAPE.dll enclave instance, the code behind Enhanced Phishing Protection.
  • The excerpt we reviewed ends mid-description, shows no attack on the live LSASS-hosted enclave, and gives no patch or CVE status for the bug.
  • Ask vendors whether enclave code is independently reviewed, including repeat-call paths, and whether old vulnerable builds are blocked from loading.

A sealed box is only as good as its guard

Windows can warn you when you type your sign-in password into the wrong place. With the right Windows 11 policies enabled, typing it into Notepad should make Defender's Enhanced Phishing Protection flag it. To do this, the feature keeps a hashed copy of your password inside a VBS enclave. That is a sealed piece of code the rest of the system cannot read.

Doyensec, a security firm, studied that enclave, a file called SFAPE.dll. Its researchers describe a memory corruption attack that effectively led to full control over an enclave instance. The starting point was a bug that writes just four bytes. The value is fixed, and the caller picks the address.

Three limits apply. This is lab research from a host process the researchers controlled, not a report of attacks in the wild. The source excerpt we reviewed ends mid-description, so the full chain beyond the two bugs it shows was not available to us. It also does not say whether Microsoft has patched the bug or assigned it a CVE.

4 bytes
Size of the write primitive
Source: Doyensec (October 13, 2026)

How an enclave works

Windows was long understood as user mode and kernel mode. Virtualization-Based Security (VBS) added a second split. It uses the hypervisor to create Virtual Trust Levels. VTL0 is the normal world, including the normal kernel. VTL1 is isolated, and VTL0 cannot inspect its private memory, even with kernel privileges.

Doyensec says this isolated layer has existed for years. Until recently, though, it was largely reserved for Microsoft's own code.

Enclaves changed that. An enclave is a library that a normal process loads but that runs inside VTL1. The host decides when it loads and which functions run. It cannot read the enclave's private memory. Microsoft calls it a software-based trusted execution environment, with no need for Intel SGX. Third parties can now get the required signature through Azure Artifact Signing.

One detail matters here. The enclave can read and write its host's memory, unless a policy restricts it. So it must check every pointer the host hands over. Doyensec notes that in practice most enclaves it analyzed do not reject unfamiliar hosts. A host can therefore feed hostile input to their functions.

From one small write to control

SFAPE.dll exports ten functions. One is called Initialize. On the first call, it checks the request and its pointers closely. On a repeat call, it skips the address check. It simply writes an error code to an address the caller supplies.

10
Functions exported by SFAPE.dll
Source: Doyensec (October 13, 2026)

At first, this looked weak. Only four bytes, and a fixed value. But the enclave stores where its own memory starts. A guard function uses that value to tell enclave memory from host memory. Doyensec aimed the write at the upper half of that stored address. After that, the guard treated ordinary enclave pointers as if they were outside the enclave.

With the guard broken, a second bug became reachable. A function called ClipboardInput checks a text descriptor, then reads it again later. The host can swap the buffer and its length in between. This is a time-of-check/time-of-use flaw. Doyensec presents the combination as the route to full control. We have not seen the rest of its chain.

What this does and does not show

The attack runs from the host side. The attacker must be a process that loads the enclave and calls its exports. For SFAPE, the real host is an LSA package running inside lsass.exe as SYSTEM.

Doyensec notes that LSA protection is generally on by default in current Windows 11. It stops ordinary processes, even SYSTEM ones, from reading or injecting code into LSASS. The firm adds that policies, compatibility issues and installation history can change this.

The material we reviewed does not describe the attack against the live LSASS-hosted enclave. So read this as evidence that the enclave's checks were weak in a lab. Do not read it as proof that Defender's feature can be defeated on a running system.

Not the first enclave bug

Alex Gough of Google's Chrome Platform Security Team found an earlier case in Edge's enclave. He reported it as CVE-2023-36880. Two of its functions took pointers without checking where they pointed. Chaining them gave read and write access inside the enclave. The first repair did not fully close the hole. A separate timing flaw remained, tracked as CVE-2024-21423.

2
Earlier CVEs in Edge's enclave
Source: Doyensec (October 13, 2026), citing Alex Gough, Google Chrome Platform Security Team

Others built on that bug. Ori David of Akamai built a project called Mirage. It parked payload data in the vulnerable enclave's private memory, where endpoint detection tools watching normal memory could not look. Outflank's researchers used the same bug to hide a running implant while it slept.

Doyensec says Windows has no dedicated blocklist for vulnerable enclaves, unlike the one for drivers. The patched Edge enclave is fixed, but old copies survive in a public file archive. Doyensec loaded those old, vulnerable Edge enclave builds on multiple recent systems.

What leaders should ask

The feature's promise is simple. Even if the normal world is compromised, hashed credentials should stay private and the matching code should stay intact. This research shows how that promise can rest on a few lines of ordinary code. A repeat-call path skipped validation. The guard then relied on a cached value that a small write could overwrite.

That matters as more vendors can ship enclaves through Azure Artifact Signing. A signature lets a library load into VTL1. The lesson here is that the isolation then depends on how carefully each vendor checks what the host sends, on every call.

Put these questions to your security team and vendors. Has the enclave code been independently reviewed, including repeat-call paths? Does any check depend on a stored value that another bug could overwrite? Are old, vulnerable enclave builds blocked from loading? Is LSA protection confirmed on across your fleet? And since Akamai's Mirage hid payloads in enclave memory, what can your endpoint tools see there?

A boundary earns trust from the smallest piece of code that guards it.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Doyensec.

Share this insight