Full Report
Huntress uncovers the mechanics of the Windows Projected File System. Explore the ProjFS driver, virtualization roots, and the PowerShell commands.
Analysis Summary
# Research: The Phantom File System: Inside the Windows ProjFS
## Metadata
- **Authors:** Jonathan Johnson
- **Institution:** Huntress
- **Publication:** Huntress Blog
- **Date:** February 5, 2026
## Abstract
This research explores the mechanics of the Windows Projected File System (ProjFS), a feature introduced in Windows 10 (version 1809) that allows user-mode applications to virtually project data into the file system. The study examines the architectural requirements of ProjFS, its "hydration" process for fetching on-demand data, and the potential for these mechanisms to be utilized for both legitimate development purposes and malicious activity.
## Research Objective
The research aims to deconstruct the internal workings of the Windows Projected File System, identify how it differs from standard NTFS operations, and evaluate the security implications of its callback and notification systems.
## Methodology
### Approach
The researcher conducted a technical deep dive by enabling the ProjFS feature, developing a custom user-mode "provider" application using documented Microsoft APIs, and monitoring the interaction between the provider and the Windows kernel-mode driver.
### Dataset/Environment
- **Operating System:** Windows (post-1809 architecture).
- **Environment:** A controlled lab environment where the ProjFS optional feature was activated.
### Tools & Technologies
- **PowerShell:** Used for feature enablement (`Enable-WindowsOptionalFeature`).
- **ProjFS API:** Microsoft’s library for creating providers.
- **Custom Provider (ProjFS.exe):** A tool developed to register virtualization roots and handle callback notifications.
- **TiWorker.exe:** Identified as the mechanism for downloading the required ProjFS driver.
## Key Findings
### Primary Results
1. **Virtualization Root:** ProjFS creates a "virtualization root" where files appear to exist to the user/OS but occupy no space on disk until accessed.
2. **On-Demand Hydration:** Data is only "hydrated" (written to disk or memory) when a `GetFileDataCallback` is triggered by a file read operation.
3. **Active Interception:** The provider can intercept and block specific file system operations (Delete, Rename, Hardlink) by returning error codes in "PRE" notification callbacks.
### Supporting Evidence
- **Empirical Demonstration:** The researcher successfully demonstrated blocking a file deletion by returning an "access denied" status through the `PRJ_NOTIFICATION_PRE_DELETE` callback.
- **Process Visibility:** Monitoring showed that the provider receives metadata about the triggering process (e.g., PowerShell.exe and its PID), allowing for granular access control.
### Novel Contributions
- **Analysis of the "PRE" Callbacks:** Detailed identification of how `PRJ_NOTIFICATION_PRE_DELETE`, `PRE_RENAME`, and `PRE_SET_HARDLINK` can be used to control file system state from user-mode.
- **Security Context:** Documentation of the driver installation process through `TiWorker.exe` upon feature activation.
## Technical Details
ProjFS operates as a bridge between the kernel and user-mode. When a user queries a directory, the kernel-mode driver (`ProjFS.sys`) calls the user-mode provider. The provider supplies the file metadata. If a user attempts to read a file, the provider receives a `GetFileDataCallback`, at which point it uses `PrjWriteFileData` to supply the actual byte stream. This allows for "phantom" files that can represent remote cloud storage or dynamic databases as local files.
## Practical Implications
### For Security Practitioners
- ProjFS can be used to create highly controlled environments where certain files are "protected" from deletion or modification by a background user-mode process.
### For Defenders
- **Visibility:** Defenders should monitor for the enablement of the `Client-ProjFS` optional feature, as it is disabled by default.
- **Detection:** Unusual provider processes (like a random executable acting as a ProjFS provider) should be flagged, as they can manipulate what a user or another security tool "sees" in a specific directory.
### For Researchers
- Further investigation is needed into how ProjFS might be used to hide malicious payloads or evade EDR (Endpoint Detection and Response) by serving different data to security scanners than to the execution engine.
## Limitations
- The research requires the ProjFS feature to be manually enabled (requires administrative privileges).
- The study focuses on the functional mechanics and does not provide an exhaustive list of exploit bypasses.
## Comparison to Prior Work
This research builds upon work by Pavel Yosifovich, moving beyond basic API implementation to explore the notification triggers and the security-centric view of how "PRE" operations can be used to intercept system calls.
## Real-world Applications
- **Use Cases:** Virtualizing large source code repositories (like Git VFS), cloud storage integration, and creating "honey-pots" that look like sensitive file directories.
- **Implementation Considerations:** Providers must be highly performant; latency in the user-mode callback can cause system-wide hangs in the virtualization root.
## Future Work
- Exploring the possibility of using ProjFS for anti-forensics or malware persistence.
- Investigating if ProjFS can be used to bypass directory file integrity monitoring (FIM).
## References
- Yosifovich, P. "Projected File System." `scorpiosoftware[.]net`
- Microsoft Documentation: "Windows Projected File System (ProjFS)."
- Huntress Blog: `huntress[.]com/blog/windows-projected-file-system-mechanics`