Building a Ransomware Honeypot with CBFS Filter


Most ransomware behaves the same way once it is running: it walks accessible directories and encrypts files in bulk, usually without any particular interest in which files it touches first. That indiscriminate behavior is also its weakness. A legitimate application has a specific, predictable set of files it opens; nothing in normal operation has a reason to open a file named Q4-Financials.xlsx sitting in a folder your own software placed it in. A honeypot exploits exactly that gap: it plants bait files that no legitimate process should ever touch, and treats any access to them as a strong signal that something is walking the filesystem indiscriminately.

CBFilter supports this directly through its virtual file mechanism, described in general terms in Implementing Virtual Files with CBFS Filter. This article applies that mechanism specifically to deception-based detection.

Planting the Decoy Files

Use AddVirtualFile to register decoy files. A static virtual file registered this way appears in directory listings and can be opened like any other file, without your application needing to keep real file content on disk for it:

filter.AddVirtualFile(@"C:\Users\Public\Documents\Q4-Financials.xlsx", DateTime.UtcNow, DateTime.UtcNow, DateTime.UtcNow, DateTime.UtcNow, /* size */ 245000, /* attributes */ 0x20 /* FILE_ATTRIBUTE_ARCHIVE */);

A few constraints from AddVirtualFile itself shape where and how you can place decoys. Virtual directories are not supported, so a decoy has to be an individual file placed inside a real, already-existing directory; you cannot fabricate an entire fake folder tree of bait. The volume in the path must already be present on the system when the call is made. And the size and attributes you provide are metadata only, since no real content backs the file unless you also handle read requests for it, which is not necessary for detection purposes.

Placement matters more than the mechanism itself. Decoys should go in locations that indiscriminate, breadth-first directory-walking behavior would reach early, such as the top level of Documents, Desktop, and commonly targeted shared folders, and should use names and extensions that make them indistinguishable from real, valuable data (financial spreadsheets, credential exports, and similar). That naming and placement strategy is a security decision for you to make; CBFilter's role is limited to making the files exist and reporting who touches them.

Detecting the Touch

Add a filter rule for the decoy's path so that BeforeCreateFile and BeforeOpenFile fire for it. AddVirtualFile alone makes the file visible; the rule is what causes CBFilter to notify your application when something tries to open it:

filter.AddFilterRule(@"C:\Users\Public\Documents\Q4-Financials.xlsx", Constants.ACCESS_NONE, Constants.FS_CE_BEFORE_CREATE | Constants.FS_CE_BEFORE_OPEN, Constants.FS_NE_NONE);

In the handler, treat the access itself as the alert. There is no legitimate reason for this event to fire at all, so there is no ambiguity to resolve the way there is with, for example, monitoring a real, actively used folder:

``` void BeforeOpenFile(object sender, CBFilterBeforeOpenFileEventArgs e) { HandleTouch(e.FileName); e.ResultCode = 5; // ERROR_ACCESS_DENIED e.ProcessRequest = false; }

void BeforeCreateFile(object sender, CBFilterBeforeCreateFileEventArgs e) { HandleTouch(e.FileName); e.ResultCode = 5; // ERROR_ACCESS_DENIED e.ProcessRequest = false; }

void HandleTouch(string fileName) { string procName = filter.GetOriginatorProcessName(); int procId = filter.GetOriginatorProcessId(); RaiseHighConfidenceAlert(procName, procId, fileName); } ```

Both events need a handler. AddVirtualFile registers the decoy as an existing file, so most ordinary opens will fire BeforeOpenFile, but a process that recreates or replaces files outright (some ransomware strains write a new encrypted file and delete the original rather than modifying it in place) will fire BeforeCreateFile instead. Handling only one of the two leaves a gap in exactly the scenario this technique is meant to catch.

Responding Beyond the Single File

Denying access to the decoy stops that one operation, but a process already encrypting files will simply move on to the next one unless something stops it. CBFilter identifies the offending process; actually stopping it is standard Windows process management layered on top, using the PID from GetOriginatorProcessId: open a handle to the process with OpenProcess and terminate it with TerminateProcess. Do this deliberately rather than automatically in every deployment, since a false positive (an admin tool doing a full-disk inventory scan, for instance) means killing a process based on a single touched file.

A less drastic middle ground is to add a default rule denying that specific process ID or executable path all further write access system-wide the moment the honeypot fires, buying time for a human or a broader response system to make the termination decision instead of doing it inline in the event handler.

What a Honeypot Does Not Cover

A honeypot only detects processes that reach the bait. Targeted ransomware that enumerates specific, known file types or locations and skips unfamiliar ones may never touch a decoy at all, and a process that encrypts files in place without a full directory walk (updating an existing file's content rather than creating new ones elsewhere) is only caught if the decoy itself happens to be in its path. This technique is a detection layer to run alongside real backups and the access controls described elsewhere in this knowledge base, such as restricting write access to removable media and restricting access by user or group, not a replacement for them.

Getting Started with CBFilter

You can find an evaluation version of the SDK for your platform and programming language in the Download Center. After downloading and installing the SDK, you will receive a library, sample code, and comprehensive documentation on your system. The documentation includes a "Getting Started" section with programming instructions. Additionally, free technical support is available during the evaluation phase.

We appreciate your feedback. If you have any questions, comments, or suggestions about this article please contact our support team at support@callback.com.