> For the complete documentation index, see [llms.txt](https://7-stars-servers.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://7-stars-servers.gitbook.io/docs/windows-internals/mini-filter-drivers.md).
# Mini-Filter Drivers
*Mini-Filter Drivers* play a central role in how the operating system securely manages, monitors, and modifies file system activity. They are an evolution of older *File System Filter Drivers*, providing a structured, safer, and more efficient way for developers to interact with file operations.
### 1. File System Filter Drivers
Before Mini-Filter Drivers existed, *File System Filter Drivers* were used to inspect, modify, or even block I/O operations between applications and the underlying file system. Microsoft defines them as:
> “A file system filter driver can filter I/O operations for one or more file systems or file system volumes. Depending on the nature of the driver, filter can mean log, observe, modify, or even prevent.”
In simpler terms, these drivers act as intermediaries. When a user-mode program (like Notepad or Explorer) opens, reads, or writes a file, the request travels through several kernel-mode layers before reaching the disk. Filter drivers intercept these I/O Request Packets (IRPs), giving them the power to analyze or alter data in real time.
Typical use cases include:
* Antivirus programs scanning file reads and writes.
* Encryption software encrypting or decrypting data on the fly.
* Backup and compression utilities managing file access transparently
In the traditional model, the request flow looks like this:
```
User Application → I/O Manager → Filter Driver(s) → File System Driver (e.g., NTFS)
```
Each filter driver sits on top of another, forming a *stack*. The problem? There was no built-in mechanism to control the order in which these drivers processed I/O requests. This made the system fragile:
* **Conflicts** occurred when multiple filters tried to modify the same request.
* **Performance issues** emerged from inefficient request handling.
* **System instability** was common because a poorly written filter could crash the system.
* **Complex load management** made maintaining compatibility between drivers nearly impossible.
Each driver had to manually forward IRPs, register completion routines, and handle edge cases, leaving significant room for human error.
As the number of security, backup, and monitoring tools increased, these conflicts became unsustainable.
### 2. the Filter Manager
To fix this, Microsoft introduced the *Filter Manager* (fltmgr.sys)—a kernel-mode component that standardizes how file system filtering is done. Instead of letting every driver manually handle stacking, the Filter Manager took over the orchestration.
It provided:
* **A controlled framework** for communication between drivers and the file system.
* **Automatic IRP routing** to ensure proper request propagation.
* **Dynamic attachment** to volumes without requiring complex configuration.
* **Improved stability and load order management.**
This innovation paved the way for a new type of filter driver, the *Mini-Filter Driver*.
Mini-Filter Drivers are compact, modular, and easier to manage than their legacy counterparts. They rely on the Filter Manager to do the heavy lifting, allowing developers to focus on the actual logic of their filtering rather than worrying about kernel-level plumbing.
In this architecture:
1. A user-mode application requests access to a file.
2. The *I/O Manager* creates an I/O Request Packet (IRP).
3. Instead of going directly to file system drivers or legacy filters, the IRP is routed through the *Filter Manager*.
4. The *Filter Manager* distributes the request to the registered Mini-Filter Drivers according to their **altitudes** (their assigned priorities).
5. Finally, the request reaches the file system driver (e.g., `ntfs.sys`).
This model introduces a well-defined, layered system of control.
### 3. Altitudes
One of the most critical design improvements of Mini-Filter Drivers is the use of **altitudes**—numerical values that determine the order of processing.
* A **higher altitude** means the Mini-Filter operates closer to user mode and intercepts I/O requests earlier.
* A **lower altitude** means the Mini-Filter processes requests later, closer to the actual file system.
For example:
* An antivirus Mini-Filter (altitude: `320000`) will inspect a file before an encryption Mini-Filter (altitude: `150000`) modifies it.
* Backup software with an even lower altitude might process the already scanned and encrypted data afterward.
Microsoft strictly manages these altitude values to maintain consistency and prevent conflicts. You can view the active Mini-Filter stack on your system by running:
```
fltmc
```
This command lists each Mini-Filter, its altitude, and its current state.
The execution order is predictable:
* **Pre-operation callbacks** run from the *highest* to the *lowest* altitude.
* **Post-operation callbacks** run in reverse—from *lowest* to *highest*.
This ensures that each Mini-Filter can reliably inspect or modify both the request and its result in a controlled sequence.
#### **3.1 Example: Who Intercepts First**
Let’s visualize a typical scenario with three Mini-Filters:
| Mini-Filter | Function | Altitude | Stage |
| ----------- | ----------------- | -------- | ------ |
| AVProtect | Antivirus scanner | 328000 | High |
| CryptGuard | File encryption | 180000 | Medium |
| BackupAgent | Backup utility | 135000 | Low |
When a process opens a file:
1. **AVProtect (328000)** inspects the file for threats before anything else.
2. **CryptGuard (180000)** encrypts or decrypts the file after AVProtect approves it.
3. **BackupAgent (135000)** copies the now-clean, decrypted data for backup.
On the way back (post-operation), the callbacks fire in reverse—BackupAgent first, CryptGuard second, AVProtect last—preserving the logic of the original chain.
#### 3.2 Load Order Groups
Altitudes are grouped by function types called **Load Order Groups**. Each group covers a logical category of filters—for example:
| Load Order Group | Typical Altitude Range | Example |
| --------------------------- | ---------------------- | ------------------------- |
| FSFilter Anti-Virus | 320000–329999 | Windows Defender |
| FSFilter Encryption | 140000–149999 | BitLocker |
| FSFilter Backup | 130000–139999 | Volume Shadow Copy |
| FSFilter HSM (Storage Mgmt) | 100000–109999 | Storage tiering utilities |
This structured design prevents chaos. An antivirus always operates before encryption or backup, ensuring malware cannot hide beneath encrypted or compressed layers.
#### 3.3 Altitude sickness
Altitude sickness describes the instability that arises when the Mini-Filter stack becomes overcrowded or mis-ordered.\
It happens when multiple vendors install drivers at overlapping or poorly chosen altitudes, causing chaos in the I/O path.
This can be used for EDRs and AVs evasion.
You first need to load a mini filter driver with the same altitude of the edr mini filter's so that way both the drivers don't have the chance to load.
This attack requires you to have administrator access to load it (you'd have also to steal the singing certificate for your driver to load properly).
But this method became obsolete as EDRs minifilter drivers generate random altitude at system boot.
The goto method currently is to make a mini-filter driver (with whatever altitude) that blacklists the loading of the EDR agent in user mode.
This way the EDR will not be able to load at the first place.
