Fermer ce champ de recherche.

Vous êtes victime d’un incident de sécurité ? Contactez notre CERT


Blog technique

Windows filter communication ports

Adrien Chevalier

Brief technical analysis of the Microsoft Windows « filter communication port » kernel communication mechanism with filtering drivers.

Filter communication ports are a communication mechanism between usermode processes and filesystem filter drivers. When accessible by unprivileged users, it may offer privilege escalation vulnerabilities. We did not understand why we could not find opened handles in client process, and as we did not find documentation on how it is implemented in Windows, we took a quick look and wrote this blog post :). Keep in mind that it is a quickly written blog post, several asumptions may be wrong. If you find such mistakes, just let us know :).

Filter communication ports are handled by the fltlib.dll module. The FilterConnectCommunicationPort function will create the port handle. It opens a new handle on the \Global??\FltMgrMsg symbolic link, which points over the FileSystemFiltersFltMgrMsg device object. Actually, the NtCreateFile syscall will also be provided with one or two extended attributes.

The following struct represents NTFS Extended Attributes (the attribute’s value follows directly EaName, after EaValueLength bytes):

typedef struct _FILE_FULL_EA_INFORMATION {
  ULONG  NextEntryOffset;
  UCHAR  Flags;
  UCHAR  EaNameLength;
  USHORT EaValueLength;
  CHAR   EaName[1];


In this case, the first attribute will be:

  • Flag: 0x700 (undocumented) ;
  • EaName: FLTPORT ;
  • EaValue: filter communication port name (PortName parameter), as a UNICODE_STRING pointer.

A third extended attribute may be present, and will contain the Context data, which is provided to the FilterConnectCommunicationPort, and which will be sent to the driver.

When a driver creates the filter communication port using the FltCreateCommunicationPort function, a new object will be created with:

  • The provided object attributes, and thus the provided port name. The OBJ_KERNEL_HANDLE attribute must be set.
  • The « KernelMode » AccessMode.
  • The « KernelMode » ProbeMode.

This newly created object is a FLT_MSG_CONNECTION (undocumented, we chose a new name 🙂 ), which follows this scheme:

					typedef struct _FLT_MSG_OBJECT_CALLBACKS {
    PFLT_FILTER             Filter;
    ULONGLONG               ServerPortCookie;
    PFLT_CONNECT_NOTIFY     ConnectNotifyCallback;
    PFLT_DISCONNECT_NOTIFY  DisconnectNotifyCallback;
    PFLT_MESSAGE_NOTIFY     MessageNotifyCallback;

typedef struct _FLT_MSG_CONNECTION {
    LIST_ENTRY              List;
    PFLT_CONNECT_NOTIFY     ConnectNotifyCallback;
    PFLT_DISCONNECT_NOTIFY  DisconnectNotifyCallback;
    PFLT_MESSAGE_NOTIFY     MessageNotifyCallback;
    PFLT_FILTER             Filter;
    ULONG                   undefined;
    ULONG                   ConnectionCount;
    ULONG                   MaximumConnections;


The FLT_MSG_CONNECTION is also added to the Filter object (FLT_FILTER), in its ConnectionList item.

Now, when the IRP_MJ_CREATE reaches the FltMgr.sys driver for \.FltMgrMsg, a custom IRP handler is called for this particular device object, and a specific function handles this IRP. Before that, ntoskrnl will parse the EaBuffer NtCreateFile parameter, and will copy its contents into an newly allocated pool buffer (IoEa tag) and will check this buffer using the IoCheckEaBufferValidity(PVOID EaBuffer, ULONG EaLength, PULONG DwEaAttributesCount). This functions only checks if there is no overflow with the offsets and sizes.

We did not search where the extended attributes checks are performed by the kernel, we only know it is correctly checked (we tried providing bad structs and pointers, without any problem).

This routine will verify that a « FLTPORT » extended attribute is present, and will retrieve its EaValue (the communication port name). This name will be passed to ObReferenceObject (which seems to perform the access check), with an AccessMode set to ExGetPreviousMode(). The MaximumConnections is checked, and a new unnamed kernel object will be created. Then, the ConnectNotifyCallback routine of the port object will be called. If this call is successful, the FsContext2 item of the referenced FileObject (FILE_OBJECT struct) will also be created, and will have several of his members initiliazed, and will point over these objects (filter object, etc.). This struct has not been fully analyzed, and will not be detailed here.

When sending a filter message using the FilterSendMessage function from the userland, an IOCTL is sent to the opened device object. In this case, the 0x8801B CTL code will be used (DISK_FILE_SYSTEM , METHOD_NEITHER, FILE_WRITE_ACCESS, Function 6). For FltGetMessage, the 0x8401F CTL code will be used. They are sent with the NtDeviceIoControlFile function, but several other ones may be sent through NtFsControlFile (the control codes begin with 0x90000).

The FltMsg.sys driver will handle these IOCTLs by first checking the provided userland buffer pointers with ProbeForRead and ProbeForWrite calls, but will NOT copy these buffers into newly allocated areas, and that’s why states « Note that OutputBuffer is a pointer to a raw, unlocked user-mode buffer. This pointer is valid only in the context of the user-mode process and must only be accessed from within a try/except block ». On FltSendMessage IOCTLs, the callback function pointer is retrieved using the referenced file object (FILE_OBJECT) and its FsContext2 member. The original FLT_MSG_CONNECTION structure pointer may be found at *(*(FsContext2 + 0x8) + 0x10)


To summarize, filter communication ports relay on METHOD_NEITHER IOCTLs. It seems that it is actually not possible to retrieve, from userland, which process opens which filter communication port, as the only handles which may be found are the FltMgrMsg device object, and an unamed one. If you have any insight on how it could be possible to list them from userland, let us know!

Like METHOD_NEITHER IOCTLs, supplied message buffers must be probed and locked (or copied in kernel buffers) by the message notify routine: unlike these IOCTLs, attackers cannot provide kernel addresses (a ProbeForRead/Write is made by default by FltMgr) but TOCTOU attacks may also be present. And like any other IOCTL handling, the notify routine should never store userland pointers in these buffers (or, in this case, handle them with the same security considerations).

Voir les derniers articles du Blog technique

11 avril 2024
M&NTIS Platform est une solution SaaS destinée au test d'efficacité de produits de défense (AV, EDR, sondes réseau/NDR, SIEM, XDR, ...) et d'architectures de supervision. Une nouvelle version majeure de la plateforme vient de sortir.
25 mars 2024
Through this article, we propose a way to find LPE in Windows applications, by using SysInternals tools. What and how to look at? How to exploit in an easy and quick way?
31 janvier 2024
During the inter-CESTI challenge organized by ANSSI, many vulnerabilities were included to test our abilities to find them and, if possible, to exploit them. In this article, we explore one vulnerability that we found during the original challenge, and explainhow we exploited it: can we find a secret key from a singlesignature?
4 décembre 2023
Find here the crypto and reverse challenges that our teams created for the European Cyber Week pre-qualification and qualification tests of CTF, a recognized cybersecurity event that took place in Rennes from November 21 to 23, 2023.
29 mars 2023
On the 24th of January, AMOSSYS and Malizen put together a Blue Team CTF, for the SupSec seminar organized by Inria. In this blog post, we explain how we, at AMOSSYS, generated the dataset used in this challenge.
20 décembre 2022
Find here the crypto and web challenges that our teams created for the European Cyber Week pre-qualification tests of CTF, a recognized cybersecurity event that took place in Rennes from November 15 to 17, 2022.
22 novembre 2022
Find here the write-ups of the crypto and web challenges that our teams created for the European Cyber Week pre-qualification tests of CTF
14 septembre 2022
This article starts with a quick overview on NIDS (Network Intrusion Detection System) evasions to remind what it is and why it could happen.
31 mars 2021
Essor du numérique, diversification des surfaces d’exposition, multiplication des cyberattaques… Depuis plusieurs années, la sécurité informatique est devenue une composante essentielle de l'administration d'un Système d'Information (SI).
18 septembre 2020
Depuis plusieurs années, l'écosystème informatique a dû faire face à une recrudescence de compromissions de systèmes d'informations par des rançongiciels, ou cryptolockers, qui s'introduisent principalement par des méthodes automatiques (_spear phishing_, etc.).