RansomGuard : an anti-ransomware filter driver

Ransomware is one of the simplest, yet significant threats facing organizations today. Unsuprisingly, the rise and continuing development of ransomware led to a plentitude of research aimed at detecting and preventing it. AV vendors, independent security reseachers and academies all proposing various solutions to mitigate the threat. In this blogpost we introduce RansomGuard, a filesystem minifilter driver designed to stop ransomware from encrypting files through the use of the filter manager. We also discuss the concepts and ideas that led to the design of RansomGuard, and the challenges we encountered in its implementation. RansomGuard’s source can be found here

The filter manager (FltMgr.sys) is a system-supplied kernel-mode driver that implements and exposes functionality commonly required in file system filter drivers. It provides a level of abstraction allowing driver developers to invest more time into writing the actual logic of the filter rather than writing a body of “boiler plate” code. Speaking of boiler plate code , writing a legacy file-system filter driver that does nothing can take up to nearly 6,000 lines of code. The filter manager essentially serves as a comprehensive “framework” for writing file system filter drivers. The framework provides the one legacy file system filter driver necessary in the system (fltmgr.sys), and as I/O requests arrive at the filter manager legacy filter device object, it invokes the registered minifilters using a call out model. After each minifilter processes the request, the filter manager then calls through to the next device object in the device stack, if any. Putting it simply, we can use the filter manager to register callbacks to be invoked pre and post a file-system operation as if our driver was part of the file-system device stack. In case you are not familiar with the filter manager API I suggest to review the related docs before proceeding with the article, mainly FLT_REGISTRATION. It’s important to note that easy to write does not mean easy to design, which remains a fairly complex task with minifilters, of course - depending on the minifilter’s task in hand. Nevertheless it makes it possible to go from design to a working filter in weeks rather than months, which is great.

A context is a structure defined by a minifilter driver that can be associated with an object. The filter manager provides support for minifilter drivers to associate contexts with objects and preserve state across I/O operations. Contexts are extremley useful, and can be attached to the following objects : - Files - Instances - Streams - Stream Handles (File Objects…) - Transactions - Volumes

Leave a Comment