Shield: Secure Host-Independent Extensible Logging for SATA/Network Storage Towards Ransomware Detection

The architecture is designed to capture meaningful data across multiple hardware levels, including the SATA interface, data storage file system, and Ethernet-based server-side NBD, all while being independent to any compromised metrics which may be obtainable from the host. This multi-layered approach provides not only fundamental measurements such as access types and sizes, but also detailed metrics unique to the file system. Although Shield can be modified to support different file systems, we qualify our case studies using the EXT4 filesystem [19]. For EXT4, this architecture can capture unique metrics like access and modification events in the superblock, which stores key disk information such as usage and block sizes; group descriptor tables (GDT), which map disk features and usage patterns; inodes, which contain file metadata and pointers to data blocks; and inode data blocks, which hold the actual file data [20, 21, 22].

Although SATA is a widely used protocol for transfer of data between a host and a memory device, proprietary SATA IP is expensive, restricting its accessibility for research and testing purposes. We implement Shield’s proof of concept with the open-source Groundhog HBA, which enables an FPGA interface between a computer and permanent storage device using Microsoft’s Simple Interface for Reconfigurable Computing (SIRC) [23, 24, 25]. Shield extends the software-side capability of the SATA HBA to become operating system agnostic and NBD compatible, no longer requiring OS primitives or software-side SIRC for communication. The SATA HBA is further developed for system mounting, formatting, and file system initialization of the storage device [26, 27].

We use the Digilent XUPV5 FPGA which has features for communication and SATA design:

• •

  High Speed Gigabit Transceiver Ports (GTP): The XUPV5 provides GTPs capable of achieving the 3 Gb/s throughput required for SATA generation 2 communication. The GTPs also enable access Ethernet functionality for server-side NBD communication [28].

• •

  On-board SATA Hardware: The XUPV5 board includes dedicated integrated circuits for SATA clock generation for GTPs, as well as physical SATA connectors, enabling direct interfacing with storage devices.

• •

  FPGA Primitives: The Virtex-5 FPGA has many logic blocks, memory, and DSP primitives, allowing for expansion when implementing detection circuitry [29, 30].

The architecture was designed to support both physical SATA devices and virtual disk images to facilitate experimentation and testing. As the addition of FPGA, Ethernet, NBD layers, and a physical hard disk drive introduces latency, virtual disk support is essential for faster prototype iterations and disk formatting. With the ultimate goal of deploying this architecture within or alongside data storage ASICs, we anticipate significantly reduced latency in the prospective ASIC implementation.

The flow through Shield components is illustrated in Fig. 1. It is initiated by an NBD client on the host, which may be a separate machine or a virtualized environment on the same system. This client connects to the NBD server , communicating over Ethernet to the FPGA , which handles measurement and logging of the desired metrics. The FPGA interfaces directly with a SATA disk , enabling low-level access to data storage and file system structures. Metrics are collected across multiple layers—including network, FPGA, and file system levels—and then observed in real-time or recorded before changes are committed to the disk. These recorded metrics are inputs for behavior fingerprinting and anomaly detection, to distinguish between benign and malicious activities . Algorithm 1 collects metrics used to capture the file system interactions in real-time.

The NBD server interfaces with the client-side host and uses either (a) an Ethernet packet generation library for FPGA communication or (b) access functions to interact with a local virtual-disk image. This setup allows the host—a separate machine or a virtualized instance—to perform standard file system operations (e.g., mounting, reading, writing) as though directly connected with a physical disk. The NBD server also captures metrics like read/write counts, access sizes, pending requests, and disk utilization to ensure consistency with hardware metrics [31].

The FPGA between the NBD server and storage device captures additional metrics for accurate software fingerprinting. Basic measurements include access type (read/write), access size, and disk location. With direct disk and data buffer access, the hardware can analyze detailed file system features, such as the superblock, group descriptor tables, and inodes, to track granular changes within the EXT4 filesystem. An overview of relevant EXT4 structures utilized by Shield is depicted in Fig. 2. Beyond these core metrics, the EXT4 filesystem offers additional data points, like journals and extent trees, though these are outside the current scope of Shield. The hardware can collect metrics in two ways: (a) actively, by using direct SATA commands to read data independently from the host, and (b) passively, by parsing buffers as data is read/written by the host. This dual approach, as outlined in Algorithm 1, allows the hardware to perform an initial file system scan during disk initialization, before the host enumerates the drive, and then switch to passive monitoring during regular host operations.

Software metrics are obtained from the server-side NBD process and system, while hardware metrics are recorded at the FPGA-Ethernet, FPGA-SATA, and EXT4 device levels. In general, software-level metrics are used to validate the accuracy of the hardware measurements, providing additional context and ensuring host independence. Table II outlines the metrics selected for this case study, although Shield can collect other metrics. Fig. 3 plots measurements for these metrics, outlining fundamental and unique metrics for software and hardware.

Metrics such as the number of reads and writes, along with their sizes, are collected (Fig. 3.a). These measurements show that ransomware tends to have a higher number of reads and larger read sizes per second compared to benign software—an indicator of malicious behavior, though not conclusive. The number of write operations and their sizes are similar for ransomware and benign software, with the latter showing a slightly higher range. This overlap limits the usefulness of write metrics. The software metrics confirm that the programs executed as expected, and serve as a baseline for comparison with hardware measurements.

Other metrics which are unique to software capture are collected (Fig. 3.b), and these include the average read request size, average write request size, average queue length, and disk utilization percentage. These metrics show similar activity patterns for both ransomware and benign programs, indicating that they are less useful for distinguishing between the two.

The hardware (Fig. 3.c), containing the number of reads, writes, and sizes, are identical to the software measurements (Fig. 3.a). Thus the metrics captured in hardware are accurate while being host-independent. The hardware level offers additional metrics that reveal clear differences (Fig. 3.d), showing which metrics can cern between ransomware and benign software:

• •

  Inodes Written: Ransomware consistently shows a high number of write operations to unique inodes, in contrast to benign software, which remains in the low single digits. This difference is a strong indicator of ransomware behavior.

• •

  Inodes Read: Ransomware generally performs read operations for unique inodes more frequently, though the average difference is less pronounced. This increased access pattern may indicate malicious activity.

• •

  Data Blocks Read: Ransomware typically reads a significantly higher number of data blocks, averaging around 150, compared to benign software, which consistently averages about 50. This difference in read activity also discerns ransomware from benign behavior.

• •

  Data Blocks Written: While the total number of data blocks written is comparable between ransomware and benign software, a key difference lies in the distribution of these writes when analyzed alongside correlated metrics. Ransomware tends to write to a large number of files (high inode access counts), whereas benign software accesses few files.

The collected metrics demonstrate strong coherence between software and hardware measurements as the number of reads and writes are identical in both count and trend (Fig 3.a and Fig 3.c). Additionally, the bytes read and written at the hardware level correspond directly to those read and written at the software level. This confirms that the hardware-level measurements are both accurate and reliable, offer the same insights as the software-level metrics, and provide additional off-host hardware-specific information while being invulnerable to tampering.

Our observations reveal that several metrics exhibit differences and may be useful when comparing ransomware with benign software, as analyzed in Fig. 4. The most distinctive metric is the total number of inode writes, which increases significantly when a program alters file metadata or pointers to data blocks at high rates. Despite testing benign programs that access all files on the drive—such as secure file deletion and file compression—the data shows that these programs only modify a limited number of inodes each second, usually in the single digits (Fig. 4.b). In contrast, ransomware consistently modifies many inodes, usually nearing the total inodes used in the entire file system. This metric appears highly promising for ransomware detection and could be enhanced by checking granular details, such as the inode elements being modified (e.g., access time, deletion time, file size, and file type).

The total inodes read and total data blocks read (Fig. 4.a and 4.c) reveal distinguishable patterns between ransomware and benign programs, both in mean values and in standard deviation ranges. Ransomware consistently shows higher values in these metrics. However, depending on the ransomware family, the number of data blocks read per inode can vary before encryption occurs, even though the total number of inodes accessed remains similar. The correlation between total inodes read and total data blocks read may serve as a potential fingerprinting method for different ransomware families, each displaying unique variations in these readings.

The metric for total data blocks written (Fig. 4.d) shows significant overlap between ransomware and benign programs. Benign programs exhibit more variability, with applications like 7-Zip and Eraser writing substantially more data blocks compared to others. Ransomware shows consistent, lower deviation in data block writes. This consistency, combined with metrics such as inode write frequency, could be a strong indicator of ransomware activity. A high inode write rate paired with stable or minimally varied data block writes, aligns with the average pattern across different ransomware samples.