#Osquery events are disabled drivers
#Osquery events are disabled software
#Osquery events are disabled windows

Windows is kind enough to provide two general categories for this purpose: the legacy file system filter API and the more recent minifilter framework.

#Osquery events are disabled windows

Like so many other engineering challenges in Windows environments, file monitoring has a nuclear option in the form of a kernel-mode APIs. This approach also comes with numerous downsides: it requires the receiving application to maintain a window (even if it’s just a message-only window), uses some weird “item-list” view of filesystem paths, and is capped by the (limited) throughput of Windows message delivery.Īll told, the performance and accuracy issues of these APIs make them poor candidates for osquery. In other words, its internal buffer does not function as a ring, and cannot be trusted to degrade gradually or gracefully in the presence of lots of high I/O loads.Īn older solution also exists: SHChangeNotifyRegister can be used to register a window as the recipient of file notifications from the shell (i.e., Explorer) via Windows messages. Last but not least, ReadDirector圜hangesW uses a fixed-size buffer for each directory handle internally and will flush all change records before they get handled if it cannot keep up with the number of events. This GitHub issue suggests that the function’s behavior is also inconsistent between Windows versions. This SO post suggests that the final moved name can be resolved with GetFinalPathNameByHandle. ReadDirector圜hangesW can be difficult to use with the Recycling Bin and other pseudo-directory concepts on Windows. Users must also finagle with the bizarre world of OVERLAPPED in order to use ReadDirector圜hangesW safely in an asynchronous context. The actual events must be retrieved through ReadDirector圜hangesW, which takes an open handle to the watched directory and many of the same parameters as the polling functions (since it can be used entirely independently of them). These routines provide the filtering and synchronization for retrieving filesystem events, but do not expose the events themselves or their associated metadata. This, in turn, requires additional filtering if the only entry of interest in the parent is the directory itself. Consequently, the “correct” way to monitor both a directory and its entries is to invoke the function twice: once for the directory itself, and again for its parent (or drive root). These routines come with several gotchas:įindFirstChangeNotification does not monitor the specified directory itself, only its entries. Once waited for and processed, subsequent events can be queued with FindNextChangeNotification.The handle returned by FindFirstChangeNotification can be used with the standard Windows object waiting routines, like WaitForSingleObject and WaitForMultipleObjects.FindFirstChangeNotification can be used to place a set of notification filters on a particular directory’s entries (and those of all subdirectories, if requested).The Windows API provides a collection of (mostly) filesystem-agnostic functions for polling for events on a registered directory: We’ll cover the technical details of each of these approaches, as well as their advantages and disadvantages (both general and pertaining to osquery) below.

#Osquery events are disabled drivers

Filesystem filter drivers and minifilters.

Win32/WinAPI interfaces: FindFirstChangeNotification, ReadDirector圜hangesW.

Methods for file monitoring on Windows typically fall into one of three approaches:

Automated troubleshooting and remediation of non-security problems: incorrect permissions on shared files, bad network configurations, disk (over)utilizationĪ brief survey of file monitoring on Windows.

#Osquery events are disabled software

Software deployment, updating, and automated configuration across large fleets: “Does every host have Software X installed and updated to version Y?”.

Non-malicious integrity violations can also be detected through file monitoring: employees jailbreaking their company devices or otherwise circumventing security policies.

Many malicious activities are reliably sentineled or forecast by well-known and easy to identify patterns of filesystem activity: rewriting of system libraries, dropping of payloads into fixed locations, and (attempted) removal of defensive programs all indicate potential compromise.

Read the schema documentation here!įile monitoring for fleet security and management purposesįile event monitoring and auditing are vital primitives for endpoint security and management: You can use this table today to performantly monitor changes to specific files, directories, and entire patterns on your Windows endpoints. TL DR: Trail of Bits has developed ntfs_journal_events, a new event-based osquery table for Windows that enables real-time file change monitoring.