Tech Analysis: Channel File May Contain Null Bytes

Key Points

CrowdStrike has observed instances internally and in the field in which the content of one or more channel files on disk is all zeroes.
This has been observed in the context of a channel file being written to disk shortly before a machine crashes.
The file containing zero content observed after a reboot is an artifact of the way in which the Windows operating system manages files on disk to satisfy its security design.

Context

CrowdStrike has observed instances internally and in the field in which the content of one or more channel files on disk is all zeroes (“NULL bytes”). This has been observed in the context of a channel file being written to disk shortly before a machine crashes.

In all of these situations, the CrowdStrike Falcon® sensor wrote valid (non-zero) data to the file prior to the machine crash. The zero content observed after a reboot is an artifact of the way in which the Windows operating system manages files on disk to satisfy its security design, more details of which can be found in the write up below.

Windows Behavior

Modern Windows operating systems (such as Windows Vista and later) are built on the Windows NT core that Microsoft developed in the late 1980s to satisfy a growing need for a Windows application-compatible, resilient, scalable and secure system architecture. As part of these requirements, Microsoft chose to follow the most open and stringent set of requirements available at the time, which was the Trusted Computer System Evaluation Criteria (“Orange Book”) published by the United States Department of Defense [https://csrc.nist.gov/files/pubs/conference/1998/10/08/proceedings-of-the-21st-nissc-1998/final/docs/early-cs-papers/dod85.pdf].

Within these criteria, at the Division Level (C) that Microsoft sought to attain, C2 Class (Controlled Access Protection) imposes a requirement (2.2.1.2) labeled “Object Reuse.” As part of this, the software component (in this case, the operating system’s file system stack) must guarantee that no prior information (in this case, existing sector data on disk) is available to use by a new actor. In layman’s terms, for a file system scenario, this means that although the disk may contain previously used data at a given sector where new data is about to be written, such data must first be erased before releasing the buffer to the user for further new writes.

In other words, every time you create a new file to write data into, Windows file systems will first erase any allocated sectors on disk matching the location of this new file. To simplify matters, the Windows cache controller (“cache manager”) implements a routine called CcZeroData [https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-cczerodata] that is meant to be used for this purpose. For security reasons, this is done synchronously as soon as a write attempt on top of dirty (previously used) data is made.

Conversely, for performance reasons, Windows (like many other operating systems), will delay writes to disks, both at the file system as well as the physical disk layer. This is why Windows will always recommend you “Eject” a USB key through the user interface before removing it from your computer.

Although many of us have experienced this scenario when forcibly removing external media, the same can happen with internal media when it too is “forcibly removed” — as in the case of a so-called “blue screen of death” (BSOD). In such a situation, it’s possible for the file system and storage driver’s flushing code not to have run (and in some cases, the hard drive can have its own firmware-based delayed write mechanism), such that no bytes will ever make it to disk.

While people might expect no file to exist — or a partial file, or a file full of “garbage” (dirty data) — the reality is that the Controlled Access Protection requirement (later replaced by Common Criteria guidance under the ISO) will force files to first be filled full of zeroes (NULL bytes) synchronously, such that any missed delayed file writes due to a kernel crash result in a zeroed-out file instead.

It’s important to realize that while the file on disk may not have been written yet, the “writes” that a Windows application and/or driver think they have done will still be visible to any readers, due to the fact that the cache manager will have held the data in memory (RAM). This results in the following regular Windows scenario, which translated to the Falcon sensor means that the expected channel file was downloaded and parsed, but the operating system crashed before it was fully written to persistent storage: