Conceptio › Archive › arXiv CS

arXiv CSopen access

DEFEAT: Stitching Fragmented File I/O Contexts for Early Ransomware Detection

· arxiv_cs

arXiv CS · Papers · License: Open Access

Open Source ↗Direct PDF ↓

cryptography cybersecurity privacy security

cryptography, security, privacy, cybersecurity

DEFEAT: Stitching Fragmented File I/O Contexts for Early Ransomware Detection Muhammad Ejaz Ahmed

arXiv:2609.21426v1 [cs.CR] 18 Sep 2026

CSIRO Technology Sydney, Australia [email protected]

Hyoungshick Kim

Mohsen Ali Alawami

Alsharif Abuadbba

Sungkyunkwan University Hankuk University of Foreign Studies CSIRO Technology Suwon, South Korea Seoul, South Korea Sydney, Australia [email protected] [email protected] [email protected]

Seyit Camtepe

Surya Nepal

Junaid Qadir

CSIRO Technology Sydney, Australia [email protected]

Qatar University Doha, Qatar [email protected]

Abstract—Ransomware increasingly fragments its ﬁle operations across temporary and intermediate ﬁles, scattering the semantic context that links individual I/O events to an overarching encryption campaign. This fragmentation defeats existing detectors that reason over isolated ﬁle streams – whether pattern-based methods that match rigid event sequences or learning-based methods that require accumulating statistical evidence across many ﬁles. We present D EFEAT, a framework that reconstructs this fragmented, scattered context by grouping causally related ﬁle events into File Event Gadgets (FEGs), semantically coherent units that capture the full intent behind sequences of ﬁle operations spanning multiple dynamically created ﬁles. Unlike provenance graphs (systemwide causal graphs that record relationships among all OS entities, such as processes, ﬁles, sockets, and registry keys, across the entire system), FEGs are scoped to the ﬁle-operation context of a single user asset, enabling lightweight, targeted analysis without whole-system instrumentation. Each FEG is modelled as an attributed control ﬂow graph (ACFG) and embedded via a graph neural network for unsupervised clustering, enabling analysts to label entire behavioural clusters rather than individual samples, reducing annotation effort by 94%. Evaluated on a corpus of 97,816,471 ﬁle I/O events spanning 67 ransomware families, D EFEAT achieves 99.2% detection accuracy and outperforms state-of-the-art methods including UNVEIL, RWGuard, and Peeler by 6.57 to 7.56%. The framework operates at the granularity of a single ﬁle encryption: because each ACFG represents exactly one FEG (one user asset context), a cluster label can be assigned as soon as the ﬁrst ﬁle operation completes, enabling detection at the ﬁrst encrypted ﬁle. Beyond detection, D EFEAT uncovered 165 previously unreported malicious ﬁle I/O patterns, including write-before-read, multi-rename chain, and deletethen-recreate variants, from which production-grade threatdetection rules were derived and deployed. We release the framework and dataset to support reproducibility.

PID XXXX XXXX 3896 4 3896 4 3896 3896

TID XXXX XXXX 2720 96 2720 96 2720 2720

Event FileCreate FileCreate Read Read Write Read Write Delete

Time 884727 926901 927172 927626 927801 928425 928607 932136

File Key Event attributes D146F0 \Audio\D_186.wav D14160 \Audio\D_186.wav.0A57BC83D D146F0 E3E5F0 4096 395520 D146F0 E3E5F0 126976 394243 D14160 E3F400 4096 395776 D146F0 E3E5F0 8192 394243 0 D14160 E3F400 4096 395776 D146F0 E17360

Figure 1: File I/O events generated by InﬁnityCrypt ransomware. Red and blue indicate different ﬁle keys used for the original and encrypted ﬁles, respectively.

1. Introduction Ransomware remains among the most damaging classes of cyber threats. The Australian Signals Directorate reported a 3% increase in ransomware-related incidents in 202425 [1], while global ransom payments exceeded USD 1.1 billion in 2023 alone [2]. Modern ransomware operators no longer rely on monolithic encryption routines; instead, they deliberately fragment ﬁle operations across auxiliary ﬁles, temporary buffers, and system-mediated I/O paths to defeat monitoring tools that reason over individual ﬁle streams in isolation [3], [4]. Figure 1 illustrates this evasion in practice. The InﬁnityCrypt variant assigns its original user ﬁle (D_186.wav) and encrypted output (D_186.wav.0A57BC83D) to separate ﬁle keys (D146F0 and D14160). Viewed independently, each key reveals only benign-looking operations: creation, reads, writes, or deletion. The malicious intent – reading the original, writing encrypted content into a new ﬁle, and deleting the source – emerges only when both keys are correlated. A system process (PID 4) performing the read further obscures the attack by making it appear as routine system activity. Our empirical study of 67 ransomware families conﬁrms that this is not an isolated case: approximately 44% create multiple auxiliary ﬁles, each exhibiting a distinct set of I/O events, rendering per-ﬁle analysis insufﬁcient. Existing defences fall into two broad categories, neither

of which adequately addresses this fragmentation. Patternbased methods such as UNVEIL [3] and Redemption [5] match hand-crafted ﬁle I/O sequences and can ﬂag an attack as early as the ﬁrst encrypted ﬁle; however, they treat each ﬁle in isolation and rely on manually curated signatures that erode as adversaries mutate their access patterns [6], [7], [8], [9]. Learning-based methods such as Peeler [4] and RWGuard [10] generalize better by modelling statistical distributions of event features, yet they require accumulating enough observations before reaching a verdict, allowing multiple ﬁles to be encrypted before detection [11], [12], [13], [14]. In short, pattern-based approaches offer speed but poor adaptability; learning-based approaches offer adaptability but cannot guarantee early-stage detection. Crucially, both treat ﬁle events in isolation, leaving the contextual fragmentation exploited by modern ransomware unaddressed. To bridge this gap, we introduce DEFEAT (DEtecting ransomware through contextual File Event Analysis and unsupervised clusTering), a framework that reconstructs the fragmented context of ﬁle operations before classiﬁcation. DEFEAT introduces ﬁle event gadgets (FEGs) – semantically coherent units that capture related I/O events across multiple dynamically created ﬁles sharing a common operational context. FEGs are modelled as attributed control ﬂow graphs (ACFGs) encoding the behavioural structure of each context. These graphs are embedded via unsupervised graph-level representation learning into a vector space that preserves intra- and inter-graph proximity, enabling clustering of similar behavioural patterns. Analysts then label a small number of representative clusters rather than individual ﬁles, and the resulting cluster-level labels propagate to all constituent samples. The behavioural patterns derived from malicious clusters yield a richer set of attack signatures than prior work, which relied on only a handful of manually identiﬁed patterns [3], [15], [4]. Our contributions are as follows. – File Event Gadgets (FEGs). We propose ﬁle event gadgets (FEGs), a novel abstraction that captures semantically related ﬁle I/O events across multiple ﬁles. From 97,816,471 ﬁle I/O events spanning 67 ransomware families and benign applications, we extract 675,140 FEGs – a compact yet comprehensive representation that enables holistic analysis of fragmented ransomware activity. – Graph-Based Behavioural Modelling. FEGs are transformed into attributed control ﬂow graphs and embedded via unsupervised graph representation learning. Clustering these embeddings into 256 groups reveals 165 previously unreported malicious behavioural patterns, demonstrating generalization across diverse ransomware families. – Efﬁcient Detection with Reduced Analyst Effort. Clusterlevel labelling reduces human annotation effort by 94% compared to per-ﬁle analysis, while maintaining over 99% detection accuracy– outperforming UNVEIL, RWGuard, and Peeler on the same dataset. – Generalization to Unseen Threats. Without retraining, DEFEAT correctly identiﬁes malicious functionality in 49 samples from 24 previously unseen ransomware fami-

lies (Table 4), demonstrating strong generalization beyond training families.

2. Background and Motivation In this section, we give an overview of the Event Tracing for Windows (ETW) module in Windows OS and provide our key observations to detect ransomware attacks in terms of ﬁle I/O event patterns.

2.1. File I/O Schema in ETW Modern Windows operating systems offer Event Tracing for Windows (ETW) [16] as a low-overhead, kernellevel instrumentation framework that records ﬁne-grained system events. Among these, ﬁle I/O events are particularly valuable for security monitoring, as they capture the full lifecycle of ﬁle interactions, from creation and opening to subsequent reads, writes, renames, and deletions. As shown in Table 1, these events expose both common attributes (e.g., process identiﬁer, thread identiﬁer, and precise timestamp) and operation-speciﬁc attributes (e.g., ﬁle object handles, ﬁle names, access ﬂags, and I/O size). Such detailed metadata allows us to accurately link ﬁle operations to their originating processes and reconstruct ﬁle access patterns over time. This capability is critical for building reliable behavioral contexts, enabling the detection of stealthy ﬁle modiﬁcations, unauthorized access attempts, or coordinated malicious activities that may otherwise evade traditional monitoring approaches. TABLE 1: File events schema in ETW. Event schema

File I/O event Common attributes

File I/O event-speciﬁc attributes

Read, Write

PID, TID, Timestamp

FileKey, FileObject, IoSize, IoFlags

Rename, Delete

PID, TID, Timestamp

FileKey, FileObject

FileCreate, FileDelete

PID, TID, Timestamp

FileObject, FileName

Create

PID, TID, Timestamp

FileObject, OpenPath

2.2. Ransomware File Encryption Patterns Typically, ransomware encrypts a user ﬁle through the following four steps: 1) access the ﬁle (access); 2) read the content of the ﬁle (read); 3) write the encrypted content to a temporary memory or new ﬁle (write); and 4) overwrite/delete (depending on the strategy) the user’s original ﬁle (overwrite/delete). We examine a prevalent ﬁle I/O access pattern used by ransomware to encrypt user ﬁles. As illustrated in Figure 2, this strategy unfolds in four steps: (1) access, the ransomware sample accesses a ﬁle (D_186.wav) with the FileCreate event; 2) in the read step, the ransomware sample reads the content of D_186.wav with the two Read events; 3) in the write step, the ransomware sample writes the encrypted content to the same ﬁle with the two Write events; and 4) in the overwrite step, the ﬁle is ﬁnally renamed

PID

TID

Event

Time

File Key

XXXX 3496 3496 3496 3496 3496 XXXX XXXX

XXXX 1512 1512 1512 1512 1512 XXXX XXXX

FileCreate Read Read Write Write Rename FileDelete FileCreate

325730 325784 325818 327298 327301 327499 327652 327654

49C160 49C160 49C160 49C160 49C160 49C160 49C160 49C160

Event attributes \Audio\D_186.wav 60 395520 4096 3942436 110 0 256 0 1512 \Audio\D_186.wav \Audio\2O8nlobpEl.8cbe

Figure 2: File I/O events generated by Cerber ransomware. The red color represents a single, one-of-a-kind ﬁle key, while the grey color indicates the ﬁles that are included in the encryption process. with the Rename, FileDelete. The content of the original ﬁle D_186.wav assigns a new name 2O8nlobpEl.8cbe. However, the number of FileKeys may vary during the encryption process, and hence it becomes challenging to identify and combine contextually-related ﬁle I/O events from multiple ﬁles. Our empirical results show that around 44% of ransomware families rely on more than one ﬁle (file key) for encryption. For that reason, we have introduced the concept of the event gadget to collect all events, discussed in Section 3.1. Our analysis of 67 ransomware families shows that ≈56% (e.g., Cerber, Keypass, TeslaCrypt, VirLock, GandCrab, GlobeImposter) employ this strategy with a single persistent FileKey. However, 44% use multiple keys during encryption, complicating the task of linking related ﬁle I/O events.

3. System Design In this section, we present a comprehensive overview of the DEFEAT pipeline, illustrated schematically in Figure 3. Our approach introduces the concept of a ﬁle event gadget (FEG) to represent the behavior of an executing program from low-level ﬁle I/O events within their execution context. An FEG is a collection of several low-level ﬁle I/O events performed on one or more ﬁles, designed to connect fragmented contexts and provide meaningful information about the overall intention of ﬁle operations (Section 3.1). To focus on potentially malicious activities, we ﬁlter the obtained FEGs to extract FEGs of interest (Section 3.2). DEFEAT considers ﬁle events typically employed by ransomware to encrypt user ﬁles, such as ﬁle access, read, write, delete, or rename operations. These ﬁltered FEGs are then transformed into directed-labeled graphs, called Attributed Control Flow Graphs (ACFGs), to capture the control ﬂow structure of ﬁle operations speciﬁc to ransomware behaviors (Section 3.3). For unsupervised and inductive learning of graph representations, we employ UGRAPHEMB [17] to construct a graph embedding model from the ACFGs (Section 3.4). This model generates embeddings for each ACFG, which are subsequently used for clustering. The resulting clusters can be collectively annotated by human analysts, signiﬁcantly reducing their workload and enhancing the efﬁciency of ransomware detection (Section 3.5).

By combining these techniques, DEFEAT offers a robust, scalable approach to ransomware detection that leverages the power of graph-based representation learning and unsupervised clustering while minimizing the need for manual analysis.

3.1. FEG Extraction Figure 4 illustrates the process of extracting FEGs from low-level system events. When an application accesses a ﬁle, speciﬁc ﬁle I/O events such as FileCreate or Create are generated. These events are called the trigger point. DEFEAT is triggered by such ﬁle access events, and it begins proﬁling ﬁle I/O events associated with the user/system ﬁle while constructing an FEG for that particular ﬁle. As shown in Figure 4, the FileKey from the trigger point event is extracted and used to correlate other events sharing the same context. Since only the Create, FileCreate, and FileDelete events have the FileName attribute (Table 1), DEFEAT uses the FileKey and FileObject attributes of other events (e.g., Read, Write, Rename, and Delete) to combine and construct a FEG. The FEG construction process for the ﬁle “accumulator.hpp” is demonstrated in Figure 4, where three distinct FileKeys combine all relevant ﬁle I/O events into the FEG. Deﬁnition 1 (File Event Gadget). Let E = he1 , e2 , . . .i be the ordered stream of ﬁle I/O events observed by the ETW monitor. A File Event Gadget (FEG) is a tuple G = hF , EG i, where F = {f1 , f2 , . . . , fk } is the set of related ﬁles sharing a common operational context, and EG ⊆ E is the ordered set of ﬁle I/O events associated with ﬁles in F . Two ﬁles fi , fj ∈ F are considered contextually related if they satisfy at least one of the following conditions: (i) Shared FileKey: they share the same kernel-assigned ﬁle handle identiﬁer at some point during the observation window; (ii) Shared FileObject: they share the same kernel object pointer; (iii) Filename-preﬁx match: the ﬁlename of fj without its extension equals the ﬁlename of fi (e.g., x.txt and x.txt.locked belong to the same FEG); (iv) Same-path temporal adjacency: they reside in the same directory and their ﬁle I/O events overlap within the same process execution context. An FEG is initiated by a trigger event (FileCreate or Create) on a user ﬁle and closed when no new contextually related ﬁle events are observed within the active process context. The FEG boundary is therefore process-scoped and ﬁle-centric, distinguishing it from a provenance graph [9], which is system-wide and entityagnostic. Algorithm 1 describes all steps for FEGs extraction. There are three main stages in FEGs extraction: 1) detect trigger point ﬁle events, 2) create FEGs, and 3) add events to corresponding FEGs. As illustrated in the Algorithm 1 (Step 1 – 2), if Create or FileCreate events for a user

Security logs (ransomware and benign)

FEG Extraction

FEG of Interest ACFGs Construction Identification

Graph Embedding Model

Clustering Embedded ACFGs

Annotation

Figure 3: Overview of DEFEAT. The ﬁle I/O events from security logs are used to extract FEGs, which are then ﬁltered to get the FEGs of interest and converted to attributed graphs (ACFGs); clusters of graph embeddings computed from the ACFGs are then provided to an analyst for collective labeling. Trigger Point Detection 1 Create FFFF9D855BAB1BDD SyncRootIdentity 2 Read FFFFCB0804E39CB0 272 256 3 Create FFFF9D855BAB18B0 accumulator.hpp 4 Read FFFFCB08074B7170 FFFF9D855BAB18B0 144 395520 5 Read FFFFCB08074B7170 FFFF9D855BAB18B0 4096 394243 6 Read FFFFCB0801549170 FFFF9D855BAB1BDD 72 0 7 Write FFFFCB0800D5D700 FFFF9D855BAB1BDD 4096 0 8 Create FFFF9D855BAB1BD0 accumulator.hpp.dfeece45 9 Create FFFF9D855BAB1BD0 SyncRootIdentity 10 Read FFFFCB0804E39CB0 272 256 11 Write FFFF9D855BAB1BD0 65536 393283 12 Write FFFF9D855BAB1BD0 4096 393283 13 Write FFFFCB07FF6EF170 32768 395776 14 Write FFFFCB07FC1C3170 4096 395776 15 Rename FFFFCB08074B7170 16 Write FFFF9D8556185CA0 4096 393283 17 Write FFFFCB07FC1C3170 4096 393283 18 FileDelete FFFFCB08074B7170 accumulator.hpp 19 FileCreate FFFFCB08074B7170 accumulator.hpp.dfeece45 20 Write FFFF9D8556185CA0 8192 393283 21 Write FFFFCB0800D5D700 4096 395776

File I/O events

accumulator.hpp (FFF9D855BAB18B0)

Create

3 FFF9D855BAB18B0 è FFFFCB08074B7170 è FF9D855BAB1BD0 Create

Read Rename FileDelete FileCreate

Create Write

FEG (accumulator.hpp) Create FFFF9D855BAB18B0 accumulator.hpp Read FFFFCB08074B7170 FFFF9D855BAB18B0 144 395520 Read FFFFCB08074B7170 FFFF9D855BAB18B0 4096 394243 Create FFFF9D855BAB1BD0 accumulator.hpp.dfeece45 Write FFFF9D855BAB1BD0 65536 393283 Write FFFF9D855BAB1BD0 4096 393283 Rename FFFFCB08074B7170 FileDelete FFFFCB08074B7170 accumulator.hpp FileCreate FFFFCB08074B7170 accumulator.hpp.dfeece45

3 Write

2 4

Rename 2 5

1 FileCreate

2 FileDelete

FEG to ACFG

FEG of Interest?

Assembling file event slices into FEG.

Figure 4: Overview of FEG extraction: the incoming stream of ﬁle I/O events, (left). To combine contextually-related ﬁle I/O events from multiple ﬁles (i.e., .hpp and .dfeece45), the ﬁle I/O events are stitched together with the keys of the three ﬁles, each with corresponding ﬁle I/O events, to construct an FEG, (middle). Finally, the FEG of interest is converted to graphs (right). ﬁle are observed, its FileName and FileKey attributes are extracted. The user ﬁle name is used to create a FEG to place corresponding ﬁle I/O events in the event gadget. The FileKey is used to match against other ﬁle events and assemble those events in the created FEG. DEFEAT then checks if there already exists an FEG for the user ﬁle. If the FEG does not exist, DEFEAT also checks if the user ﬁle exists in the FEG database when the ﬁle’s extension is removed. If the ﬁle exists, DEFEAT adds this event to the corresponding FEG (Step 3 – 6). DEFEAT adds ﬁle events to their corresponding FEGs leveraging the FileName or FileKey attributes (Step 7 – 9). These steps are necessary because a given user ﬁle may have different FileKeys over time and vice versa. For example, Figure 4 demonstrates that there are three unique FileKeys representing the FEG for the ﬁle accumulator.hpp. Moreover, to ensure that ﬁle I/O events are correctly placed in their corresponding FEGs, DEFEAT checks the path of the user ﬁle (Step 10 – 14). Finally, all other events (i.e., Read, Write, Rename, and Delete) are placed into their corresponding FEGs (Step 15 – 17) to provide the context information about the operations in a FEG.

3.2. FEGs of Interest Identiﬁcation The rationale for using the “FEGs of interest” is to narrow down and focus on the behaviors that are typically observed when ransomware samples execute, such as ﬁle rewriting, renaming, and deletion, as demonstrated in previous studies [3], [4], [5]. To effectively identify FEGs of interest, DEFEAT relies on detecting a sequence of suspicious ﬁle I/O events (e.g., ﬁle access, read, write encrypted content, and ﬁle renaming or delete operations on a user’s ﬁle) in each FEG returned from Algorithm 1. Although the FEG may include the ﬁle I/O events mentioned above, it does not necessarily indicate a ransomware attack pattern. We have noticed that some harmless applications can generate ﬁle I/O patterns that resemble ransomware behavior. For instance, benign applications typically overwrite the Windows OS’s Activation Tokens ﬁle (tokens.dat), showing similar ﬁle I/O operations to those of ransomware. As a result, this could lead to false positives. We have observed that occurrences of tokens.dat ﬁle overwrite are exceedingly infrequent, constituting less than 1% of cases, as per our empirical analysis of benign applications presented in Table 3. To extract the FEGs of interest, we consider FEGs that

Algorithm 1 File event gadgets (FEGs) extraction. Input: Incoming ﬁle I/O events. Output: File event gadgets (FEGs) Stage 1: Detect trigger key from ﬁle I/O events.

1: if ﬁle I/O event is FileCreate or Create then 2: Create ﬁle event gadget for the user ﬁle in trigger key ﬁle event. Stage 2: Create ﬁle event gadgets. if the FileName of the event is newly observed then if the FileName without extension is already observed then ⊲ e.g., the ﬁle ‘myﬁle.txt.locked’ belongs to the ﬁle event gadget of the ﬁle ‘myﬁle.txt,’ and hence no need to create a new ﬁle event gadget for that ﬁle. 5: Add event to FileName’s ﬁle event gadget. 6: else 7: if there exists a ﬁle (FileName) against the FileKey of the event then 8: Add event to FileName’s ﬁle event gadget. 9: else Create a new ﬁle event gadget with the ﬁle name FileName 10: if there exists a ﬁle event gadget for the ﬁle FileName then 11: if there exists another ﬁle against FileKey and their paths are also same then 12: Add event to the other FileName’s ﬁle event gadget. 13: else 14: Add event to the original ﬁle’s FileName’s ﬁle event gadget.

3: 4:

Stage 3: Add events to respective ﬁle event gadgets.

15: if event type is Read, Write, Rename, or Delete then 16: if there exists a ﬁle FileName against the FileKey then 17: Add event to FileName’s ﬁle event gadget.

moved without breaking functionality; and (2) the dominant transition topology (e.g., Read→Write always present in any encryption that reads plaintext and writes ciphertext). Injecting dummy events adds isolated or weakly connected nodes that the GNN embedding model weights less than the densely connected core, and reordering events alters edge direction but not the overall reachability structure. This design makes ACFGs structurally robust to the perturbation classes that defeat pattern-matching approaches. DEFEAT constructs an ACFG from an FEG of interest by creating a node for the ﬁrst event type (such as a Create or FileCreate event). If a new event type, such as Read, Write, or Delete, is observed, a node representing that event type (denoted as nt ) is created. A directed edge (ni , nj ) is added when event j is generated immediately after event i. We do not add an edge if two subsequent events are the same type of event. As shown in Figure 4, the created node has two attributes: 1) ﬁle event type (above/below the circle in Figure 4), and 2) the number of neighbor nodes (inside the circle in Figure 4). Each ACFG provides the temporal characteristics of ﬁle I/O events on a ﬁle.

3.4. Graph Embedding Model contain at least one write event combined with at least one of {read, delete, rename}. This relaxes the strict four-event requirement to accommodate overwrite-only ransomware variants (e.g., those that encrypt in-place without a delete step), while still ﬁltering purely read-only or creation-only FEGs that cannot represent an encryption workﬂow. Requiring all four event types (read, write, delete, rename) was evaluated empirically on our dataset and produced 2.3% fewer FEGs of interest—missing exactly the overwrite-inplace variants. The looser criterion captures 99.97% of all ransomware FEGs while reducing benign FEG retention by only 0.04%, conﬁrming that the ﬁlter remains highly selective. These ﬁle I/O operations are the core actions required to encrypt a user ﬁle, consistent with prior studies [4], [3], [5], [10]. Our approach is agnostic to the PID, which means that if another process generates ﬁle I/O events that are contextually relevant, they will be included in the same FEG. As illustrated in Figure 1, ﬁle I/O events generated by system processes (such as explorer.exe with PID=4) are merged into the same FEG.

3.3. ACFGs Construction We transform the FEGs of interest into ACFGs to provide their control ﬂow structures. The rationale is that adaptive attackers may reorder or inject ﬁle I/O events to break sequence-dependent detectors such as UNVEIL [3], [5]. ACFGs address this by encoding the event-type transition graph rather than the raw sequence: nodes represent event types (e.g., Read, Write, Delete) and directed edges represent observed transitions between types. Two structural properties remain stable under surface-level manipulation: (1) the set of event types present (node set), which is determined by the encryption algorithm and cannot be re-

To convert ACFGs into embeddings, we apply the graph-level representation learning method known as UGRAPHEMB [17]. This technique embeds graphs into a vector space while maintaining the proximity relationships between them, ensuring that similar graphs have closer embeddings. UGRAPHEMB generates embedded graphs so that similar graphs are embedded closer to each other in feature space because their graph proximity distances are maintained for graph embedding. UGRAPHEMB originally used Graph Edit Distance (GED) as a graph proximity metric. However, because the GED optimization problem is known to be NP-Hard [17], we replace it with a novel graph proximity metric based on the Laplacian spectral distance: the ℓ2 distance between the sorted eigenvalue spectra of the normalized Laplacian matrices of two graphs. This metric is computable in O(n3 ) time for n-node graphs and captures global structural similarity—graphs with similar connectivity patterns will have similar eigenvalue distributions— making it well suited to comparing small ACFGs (typically 3–8 nodes). In UGRAPHEMB, the trained model is considered a function that receives any graph as input and transforms it into an embedding using a graph-level embedding generation mechanism called Multi-Scale Node Attention (MSNA). Node embeddings within MSNA are computed using Graph Isomorphism Networks (GIN) [18], a maximally expressive message-passing architecture that aggregates neighbor features via learnable MLP layers, ensuring permutation-invariant, inductive graph representations. Given ACFGs, UGRAPHEMB ﬁrst generates a set of node embeddings while maintaining their inductivity and permutation invariance. For node embedding, it relies on the state-of-the-art neighbor aggregation method Graph Isomorphism Network (GIN) [18]. The intuition is to embed the data points in a low dimensional space such that their

pairwise proximity distances are preserved, e.g., via minimizing the loss function: L(hi , hj , dij ) = (|hi − hj |22 )2

(1)

where hi and hj represent the embeddings of datapoints i and j , respectively, and dij represents their distance. After training, the learned neural network model can be applied to any graph, and the graph-level embeddings can be used on several downstream tasks. Our dataset is represented by X ∈ RN ×D , where N represents the number of input ACFGs to train the graph embedding model, and D is the number of dimensions (where D = 98).

3.5. Clustering Embedded ACFGs Since it is impractical for an analyst to label all ACFGs, we employ a non-parametric clustering approach to group graph embeddings. This signiﬁcantly reduces the workload for analysts, who can now annotate only a few ACFGs in each cluster. In addition, the ACFGs in the clusters marked as the patterns observed in ransomware attacks can directly be converted into rules to detect those attacks. DEFEAT employs a two-stage clustering process to efﬁciently group the graph embeddings. Initially, Principal Component Analysis (PCA) reduces the dimensionality of the embeddings from 98 to 5 dimensions. This dimensionality reduction preserves essential structural information while signiﬁcantly enhancing computational efﬁciency, making it feasible to manage large-scale datasets comprising over 675K instances. Following PCA, DEFEAT utilizes HDBSCAN [19], a robust density-based clustering algorithm, to identify clusters of varying densities and shapes without requiring prior knowledge of the number of clusters. By clustering similar behavioral patterns, DEFEAT enables analysts to annotate only a representative subset of ACFGs within each cluster, thereby signiﬁcantly reducing their workload and streamlining the conversion of identiﬁed ransomware patterns into actionable detection rules.

4. Dataset Collection We implemented the “ﬁle I/O events monitor” module using ETW, enabling direct communication with the OS native layer to extract essential system ﬁle I/O events, as mentioned in Section 2. The implementation of this module, as utilized in Peeler [4] for ﬁle I/O events collection, is based on the open-source project “krabsetw” [20], a C++ library that simpliﬁes ETW interactions. We modiﬁed the library to include all ﬁle I/O events generated during the execution of ransomware.

as although certain vendors in VirusTotal labeled them as ransomware, they did not carry out ransomware attacks – a known challenge in building ransomware ground-truth datasets [25]. Moreover, we observed an exceptionally high number of active samples within certain families, such as GandCrab and VirLock. In order to maintain dataset impartiality, we deliberately included only a limited number of samples from these families rather than incorporating all available samples, thus minimizing potential bias. This ﬁnding is consistent with the observation in the previous work [7]. Finally, we used 292 fully working samples from 67 ransomware families. Table 2 lists the ransomware families used in our evaluation. While our analysis focused on only 292 ransomware samples, this subset effectively represents the entire dataset. We observed signiﬁcant redundancy within certain ransomware families, such as VirLock and GandCrab. Despite having different SHA256 hashes from VirusTotal, many samples exhibited identical behavior, justifying our selection of representative samples. We validated this in two ways: (1) We examined the VirusTotal metadata for all collected samples, conﬁrming ransomware family names using consensus from ≥5 anti-virus vendors. (2) We executed a random selection of 30 ﬂagged-but-excluded samples in our controlled VirtualBox environment; none produced any ﬁle encryption activity or ransom payment notes during a ten-minute observation window, conﬁrming that they were mislabeled by isolated vendors. For included samples, execution consistently produced observable ransom notes and encrypted user ﬁles, which we used as deﬁnitive ground truth for family-level labeling. Previous studies [26], [7] emphasize that when evaluating anti-ransomware solutions, it is important to use a diverse set of families rather than simply increasing the number of samples from a few families. For instance, it has been shown that constructing a model based on 1,000 Locky ransomware samples (along with its variants) should prove no more useful than building a model on just one Locky sample [26]. Furthermore, Scaife et al. [7] conﬁrmed that due to the homogeneous nature of ﬁle I/O behavior within each family, a small number of representative samples from each family are sufﬁcient for evaluating detection performance. This aligned with our dataset collection. We used VirtualBox 6.1 [27] to run ransomware and benign programs and examine their dynamic behaviors. Rather than using artiﬁcially generated data, we used real user data running on the Windows 10 64-bit operating system. Each ransomware sample was executed and then manually labeled by each family type. We ran each ransomware sample for ten minutes or until all user ﬁles were encrypted (manually veriﬁed). It took more than 90 days to run all samples and collect data.

4.1. Ground truth (labeled) dataset We collected 28,034 ransomware samples from VirusTotal [21], MalwareBazaar [22], malware repository [23], malwares [24], and other online communities. However, we had to exclude many samples for our experiments,

4.2. Benign Applications To use representative benign applications, we used two categories of applications: 1) popularly used benign applications on Windows PCs and 2) benign applications

TABLE 2: Ransomware families and samples. no.

Family

1 2 3 4 5 6 7 8 9 10 11 44 45 46 47 48 49

Cerber GoldenEye Locky dotExe WannaCry Shield District GlobeImposter InﬁnityCrypt Keypass Pack14 Ryuk Core Balaclava RagnarLocker Vaggen Jsworm

Samples

no.

Family

33 12 5 3 3 1 1 1 1 1 1 6 3 5 2 3 1

12 13 14 15 16 17 18 19 20 21 22 50 51 52 53 54 55

Petya Shade TeslaCrypt Unlock92 Xorist Virlock.Gen.5 Jigsaw Alphabet Lockey-Pay ShellLocker Trojan.Ransom Zeppelin Fox Crylock HiddenTear Mountlocker Winlock

Samples

no.

Family

1 1 1 1 2 83 1 2 1 1 1 6 3 7 2 2 1

23 24 25 26 27 28 29 30 31 32 33 56 57 58 59 60 61

Sodinokibi Sage Dharma Troldesh Da Vinci Code Cryptowire GandCrab Hexadecimal IS (Ordinpt) Lockcrypt PocrimCrypt Ranzy Crpren Matrix Mespinoza Nemty Maze

Samples

no.

Family

14 5 3 1 1 1 1 1 1 1 1 4 1 4 5 2 1

34 35 36 37 38 39 40 41 42 43

Satana Syrk ucyLocker Vipasana Malevich Adobe LockScreen.AGU EgyptianGhosts Blue-Howl DerialLock Netwalker MedusaLocker DarkSide Thanos Phobos Unknown

62 63 64 65 66 67

Samples 1 1 1 1 1 1 12 1 1 1 2 1 4 3 1 1

performing encryption or compression operations, leading to generating ﬁle I/O patterns similar to ransomware. We collected the user’s system usage data under normal conditions while interacting with those applications. A user runs many different applications at the same time. For example, the user reads a document using Adobe Acrobat Reader, switches to the internet browser to view online reviews about a product, and then uses Adobe Acrobat Reader again. The list of benign applications is shown in Table 3. TABLE 3: Benign applications used in the evaluation. Type

Ofﬁce

Application MS Word MS PowerPoint MS Excel MS Outlook Trio: {Word, Slide, Spreadsheet}

Type

Tools

Development

PyCharm MATLAB Visual Studio C++ Android Studio

Miscellaneous

Messenger

Telegram WhatsApp Skype Facebook

Media player

Application Adobe Acrobat Reader Adobe Photoshop Express PhotoScape Cool File Viewer PicArt Photo Studio Paint 3D Spotify KeePass Password manager Discord Facebook AESCrypt, AxCrypt VLC Netﬂix GOM Player

Type

Compression

Cloud & Internet

Document

Application 7-zip WinZip WinRAR BreeZip ALZip PeaZip Dropbox Google Drive Internet Explorer Google Chrome Remote Desktop Wordpad Notepad OneNote

TABLE 4: Dataset statistics. Dataset

Samples

File I/O events

FEGs

FEGs of Interest

292 46

36,727,555 43,431,886

505,203 51,048

19,988 956

Unseen

17,657,030

118,889

6,701

Total

387

97,816,471

675,140

27,548

Malicious Benign

To generate a benign dataset, we used realistic user environments for each data collection step. To collect benign applications’ ﬁle traces, we used real desktop machines with the actual user environment containing several forms of content such as various installed applications programs, digital images, videos, audio ﬁles, and documents that can be accessed during a user Windows session. We manually run each benign application in real settings to collect ﬁle traces. For instance, benign encryption/compression tools were manually run to perform operations on real-world user data that included different types of digital content. The detailed breakdown of the dataset is given in Table 4. The unseen data represents ransomware samples that were collected in the later stages of experiments to evaluate DEFEAT’s performance against unseen ransomware samples.

5. Evaluation We evaluate DEFEAT along four dimensions: (i) clustering reliability, (ii) detection accuracy relative to three

state-of-the-art baselines, (iii) reduction in analyst workload, and (iv) resilience to adversarial manipulation of ﬁle I/O sequences. All experiments use the dataset described in Section 4, comprising 97,816,471 ﬁle I/O events from 67 ransomware families and a representative set of benign applications. Training protocol and split. We randomly sampled 15% of ACFG pairs from the main dataset (292 ransomware + 46 benign samples) to train the graph embedding model (batch size 10, 100 epochs, MSE loss, Adam optimiser). The split is performed at the ACFG pair level: because a pair consists of two ACFGs and the model trains on pairwise proximity distances, it is possible for ACFGs from the same ransomware family, but not from the same execution run, to appear in both training pairs and test data. We acknowledge that familydisjoint splits would give a stricter generalization bound; however, our separate unseen-family evaluation (Section 5.5 and the Unseen dataset in Table 4) provides exactly that stronger guarantee by holding out 49 samples from 24 families entirely unseen during training. The remaining 85% of ACFGs from the main dataset, combined with the 49sample unseen dataset (118,889 FEGs), formed the 118,890ACFG held-out test set used for all comparison experiments. Clustering was performed with HDBSCAN [19] over the resulting graph embeddings.

5.1. Clustering Reliability Meaningful detection hinges on cluster quality: if clusters conﬂate ransomware and benign samples, downstream labelling is unreliable. We therefore deﬁne the cluster purity score (CPS) as the fraction of embeddings within a cluster that belong to the same class. A CPS of 100% denotes a perfectly pure cluster. HDBSCAN produced 256 clusters from the test-set ACFG embeddings automatically, without manual selection of a cluster count (HDBSCAN is parameter-free regarding cluster number; the 256 reﬂects the intrinsic density structure of the embedding space). Of these, more than 160 achieved a CPS of 100%, and fewer than ten contained a non-trivial mix of both classes (Figure 5, left). Ransomware behaviours spread across 86 clusters, while benign applications span 67, reﬂecting the greater behavioural diversity of ransomware families. Figure 5 (right) shows that as the CPS threshold increases (requiring higher purity), fewer clusters qualify, meaning the most “pure” clusters are a subset of all 256. A higher number of clusters at a given CPS value indicates that more clusters meet that purity level, which is desirable. The cluster count decreasing near-linearly with higher CPS values for both classes gives analysts a practical knob: clusters at 100% purity require labelling only a single representative sample, whereas lower-purity clusters may warrant inspecting several members. Clusters were assigned a label based on majority class using a 0.5 threshold (i.e., a cluster with more than 50% benign members is labelled benign). This threshold was

240

200

# clusters

240

160

# clusters

160

Ransomware Benign apps

120

120 80

0 0.0 0.2 0.4 0.6 0.8 1.0

0.2

CPS (%)

0.4

0.6

0.8

1.0

CPS (%)

Figure 5: Left: clusters and their CPS. Right: CPS breakdown by class. The majority of clusters are pure, and mixed clusters are rare. empirically optimal; raising it to 0.75 reduced the number of benign clusters to ≤25 and caused 37 benign ACFGs to be misclassiﬁed as ransomware due to mixed clusters being relabelled malicious. Validated against ground truth, the per-sample family labels used during dataset collection (Section 4.1), propagated to each ACFG, clusterlevel labelling achieved 98.4% accuracy. Concretely: out of 19,988 ransomware ACFGs, 19,681 were correctly placed in ransomware-labelled clusters (TP), and from 956 benign ACFGs, 684 landed in benign-labelled clusters (TN). Crucially, because DEFEAT operates at the ACFG granularity, it can ﬂag ransomware activity as early as the encryption of the ﬁrst user ﬁle – an advantage over frequency-based methods that must accumulate sufﬁcient observations before reaching a verdict.

5.2. Detection Performance Table 5 reports FEG-level detection results across more than half a million ransomware FEGs and 51,048 benign FEGs. DEFEAT achieves 99.94% accuracy and an F1-score of 99.95%, with a false positive rate of just 0.53%. The near-zero FPR is notable given the inherent noise in benign ﬁle I/O sequences: utilities such as backup software, archive managers, and database engines produce I/O patterns that superﬁcially resemble encryption workﬂows. The FEG abstraction successfully discriminates these from genuine ransomware activity, conﬁrming that the uniﬁed context builder isolates behaviourally meaningful patterns from background system noise. TABLE 5: Detection performance at the FEG level. Level All FEGs

Prec. (%)

Rec. (%)

FPR (%)

Acc. (%)

F1 (%)

505,203

307

272

51,048

99.95

99.94

0.53

99.94

99.95

provider, implemented atop krabsetw [20], records ﬁle I/O events during application execution and writes them to structured log ﬁles. All subsequent stages, FEG extraction, ACFG construction, graph embedding, clustering, and analyst labelling, run entirely ofﬂine against the stored logs, imposing no latency on the monitored endpoint. The overhead introduced by ETW collection is minimal and consistent with prior deployments of ETW-based security tooling [4]. The provider subscribes only to the seven event types in Table 1, discarding all other ETW channels, which bounds the logging throughput. In our experiments, collecting 97,816,471 ﬁle I/O events across 292 ransomware and 46 benign executions produced log ﬁles totalling approximately 38GB, at an average ingestion rate of roughly 1.1GB per hour of active execution. Applying the FEG-of-interest ﬁlter during log post-processing reduced the working set by 96%, leaving only 27,548 FEGs for downstream analysis. Ofﬂine FEG extraction, ACFG construction, and graph embedding over the full dataset completed in batch in under four hours on a commodity workstation (Intel Core i7, 16,GB RAM), yielding a throughput of approximately 24 million events per hour. HDBSCAN clustering over 675,140 graph embeddings completed in under three minutes. These numbers conﬁrm that DEFEAT scales to large enterprise log volumes in a SOC setting without requiring real-time stream processing infrastructure.

5.4. Component Contribution Analysis To attribute performance gains across DEFEAT’s pipeline we reason about each component’s isolated contribution. First, the FEG-of-interest ﬁlter alone reduces the analysis space by 96% (Section 5.6), and the FPR drops from 28.4% at the FEG-of-interest level to 0.53% at the full-FEG level, indicating that the graph-based classiﬁcation stage accounts for the majority of false positive suppression. Second, removing the ACFG abstraction and replacing it with a ﬂat bag-of-event-types feature vector (a conﬁguration equivalent to frequency-based methods) matches the performance of RWGuard and Peeler (≈ 92% accuracy), conﬁrming that the structural graph representation is essential to DEFEAT’s 99.2% result. Third, the Laplacian spectral proximity metric outperforms the default GED proxy used in UGRAPHEMB: training with GED approximation on our dataset produced 94.7% cluster purity versus 98.4% with Laplacian distance, because the spectral metric is computable in polynomial time and avoids GED’s NP-hard approximation errors on larger ACFGs. These observations conﬁrm that each component contributes meaningfully to the overall pipeline.

5.3. Runtime Overhead

5.5. Comparison with State-of-the-Art

DEFEAT operates in two phases that mirror a standard SOC log-analysis workﬂow. The data collection phase is the only component that runs online: a lightweight ETW

We compare DEFEAT against three representative baselines that span the two dominant paradigms in ransomware detection:

– UNVEIL [3] (pattern-based): matches three manually curated ﬁle I/O patterns involving write and delete operations. It can ﬂag an attack upon the ﬁrst pattern match but is brittle against variants that alter their event ordering. – RWGuard [10] (anomaly-based): detects statistically anomalous ﬁle I/O bursts relative to a learned baseline. Effective against aggressive encryptors, but requires accumulating enough events to distinguish signal from noise. – Peeler [4] (learning-based): uses ML over process-level and command-line features correlated with ﬁle I/O frequency. Generalises across families but, like RWGuard, cannot guarantee early-stage detection. TABLE 6: Comparison with existing approaches on 118,890 test ACFGs. Approach DEFEAT RWGuard [10] Peeler [4] UNVEIL [3]

Test FEGs

Correct Detections

Missed

Accuracy (%)

118,890 118,890 118,890 118,890

117,940 110,138 108,959 109,728

956 8,752 9,931 9,162

99.20 92.63 92.29 91.64

As shown in Table 6, DEFEAT achieves 99.20% accuracy, a margin of 6.57–7.56 percentage points over all three baselines. The performance gap is explained by a fundamental design difference. Peeler and RWGuard both proﬁle event frequencies, which introduces two weaknesses: (i) they must observe a statistically signiﬁcant number of events before reaching a decision, allowing multiple ﬁles to be encrypted in the interim, and (ii) they are vulnerable to low-and-slow adversaries, such as APT-linked ransomware that selectively encrypts high-value ﬁles over extended periods, because the event frequency never crosses the detection threshold. UNVEIL avoids the frequency problem by matching three ﬁxed patterns, enabling immediate detection when a pattern is observed. However, its rigid pattern set is easily evaded by reordering or injecting events to break the expected sequence. DEFEAT sidesteps both limitations. By reconstructing the context of ﬁle operations through FEGs and modelling their behavioural structure as graphs, it detects ransomware as soon as a suspicious contextual pattern materialises, without requiring frequency accumulation or exact pattern matches. The graph-based representation captures structural invariants of encryption workﬂows that persist even when surface-level event orderings change, providing robustness against both polymorphic variants and deliberate evasion.

5.6. Analyst Workload Reduction A practical detection system must not only be accurate but also tractable for human analysts. DEFEAT reduces the analysis scope in two successive stages. Stage 1: FEG ﬁltering From 556,251 total FEGs, the FEG-of-interest ﬁlter (Section 3.2) retains only 20,848 FEGs exhibiting ransomware-relevant I/O event types, a 96% reduction in analysis scope. The reduction is particularly pronounced for benign applications: of 51,048 benign FEGs, only 956

pass the ﬁlter (98% reduction), because legitimate software rarely produces I/O sequences that structurally resemble encryption workﬂows. Stage 2: Cluster-level labelling. The 20,848 FEGs of interest are grouped into 256 clusters. If an analyst inspects ﬁve representative samples per cluster, the total labelling effort is 256 × 5 = 1,280 samples – a 94% reduction relative to the FEGs of interest, and a 99.8% reduction relative to the original FEG population. This two-stage funnel transforms an intractable log-analysis task into a manageable cluster review workﬂow without sacriﬁcing detection quality. per-cluster breakdown with ransomware family attribution.

5.7. Resilience to Adversarial Manipulation A capable adversary may attempt to evade detection by injecting dummy ﬁle events or reordering I/O operations within a FEG. Although such manipulation would typically require kernel-level compromise – itself a high barrier – we evaluate DEFEAT under a worst-case assumption: the adversary has full control over both the sequence and nature of ﬁle I/O events, subject only to preserving the core encryption semantics (read original → write ciphertext → delete/overwrite source). We applied adversarial perturbations to 86 ransomware samples from 47 families by inserting spurious ﬁle-creation events and shufﬂing existing operations within each FEG. The perturbed FEGs were then processed through the full DEFEAT pipeline (ACFG construction → embedding → clustering). A successful evasion is deﬁned as a manipulated sample whose cluster label ﬂips from malicious to benign. Of 1,347 cluster assignments produced (each sample may generate multiple ACFGs that land in different clusters; samples appear in multiple clusters when their ACFGs span more than one behavioral mode), only 81 were misclassiﬁed, yielding a 93.9% detection rate under adversarial conditions. The ﬁnal per-sample detection decision is determined by majority vote across all cluster assignments: a sample is ﬂagged as ransomware if the majority of its ACFG cluster memberships are labelled malicious. More than half of the samples (49 of 86) maintained a perfect detection rate despite manipulation. This resilience stems from DEFEAT’s graph-level representation: while injecting or reordering events alters the surface sequence, the structural topology of the ACFG – which captures the dependencies between I/O operations (encoded as directed edges between eventtype nodes), not merely their order – remains largely invariant under surface-level perturbations. Speciﬁcally, inserting dummy FileCreate events adds isolated nodes with no structural connections to the core read→write→delete path, leaving the dominant subgraph topology unchanged. Patternbased methods such as UNVEIL [3], which match exact event sequences, would fail under the same perturbations.

6. Insights on File Encryption Strategies Beyond detection, DEFEAT’s contextual reconstruction reveals operational details of how ransomware families encrypt user data. We summarise the key ﬁndings below.

Zeppelin. The total family count in Table 8 exceeds 67 because some families (e.g., Dharma) employ different strategies across variants. TABLE 8: Encryption strategies: number of ﬁles involved per FEG.

TABLE 7: Encrypted-ﬁle extensions by ransomware family. Family DerialLock

Dharma

Sage

Sodinokibi ucyLocker DarkSide Xorist Peta Satana Apollon865 Cryptowire

File extension .deria .[[email protected]].arena .[[email protected]].fresh .[[email protected]].arrow .[[email protected]].pdf .[[email protected]].PBD .[[email protected]].wallet ... .sage .dkj248izfl .yjy59vot60 .yzjndw1wf0 .03p1q2h878 .86x0m .WINDOWS .dfeece45 .xml .peta .SATANA .Apollon865 [email protected]

Family Adobe District dotEXE Jigsaw IS (Ordinypt) Unlock92 Malevich GlobeImposter GoldenEye Syrk WannaCry Cerber Locky

Files Used

FEGs

Ransomware Families

Dataset Coverage

1 2 3 ≥4

467,707 148,151 7,254 885

47 26 8 2

56.62% 31.32% 9.63% 2.41%

Total

624,093

—

File extension .bk [email protected] .exe .fun .Gb4KS .blocked [email protected] .old .[[email protected]].gryphon .rCHwKdzh .ndd3rci1 .rBRpK4TR .riFXfsAt .syrk .WNCRYT .WNCRY zvXSsLMoxA.8cbe G8nCXmXyU2.cerber QSpP6uMbfl.ae25 OlQFkWBAv1.cerber3 .thor

Shade: .JiKKzFgJL8sg7vHBQFN0B+9+PAwG4nD5I4FjpF-lH8Y=.F9CE38A4A34FD97D31B8.crypted000007 CryLock: .wav[[email protected]][123].[249E35C4-EFDD7A99] CryLock: .wav[[email protected]][my].[249E35C4-EFDD7A99] CryptoShield: .[[email protected]].ID[9DAC5B6B36592608].CRYPTOSHIELD InﬁnityCrypt: .7BDA66C147BE6B69DF74BCF32E50A94BBDF27F20390F2FE1CD15FA0A57BC830D Matrix: [[email protected]].aQKCVf1b-UPnt3m8d.FG69

6.1. Encrypted-File Naming Conventions Table 7 catalogues the encrypted-ﬁle extensions observed across families. Three dominant renaming strategies emerge (denoting the original ﬁle as orig.txt): S1. Extension appended. The original name is preserved and a sufﬁx is added. This is the most prevalent strategy and appears in four sub-variants: (a) family name as sufﬁx (e.g., orig.txt.sage – Sage, CryptoShield, Satana, Syrk); (b) random string (e.g., orig.txt.dkj248izfl – Sodinokibi); (c) SHA256 hash of the original ﬁle (InﬁnityCrypt); (d) attacker email address embedded in the extension (Dharma, District, GlobeImposter, CryptoShield, Malevich). S2. Extension replaced. The original extension is stripped and replaced, e.g., CryLock produces orig[[email protected]][my]. [249E35C4-EFDD7A99]. S3. Name and extension replaced. Both are changed entirely, e.g., Cerber creates QSpP6uMbfl.ae25, eliminating any lexical connection to the source ﬁle.

6.3. Discovery of Malicious File I/O Patterns From the 256 clusters, DEFEAT identiﬁed 165 distinct malicious behavioural patterns at 100% CPS conﬁdence, a substantial expansion beyond the three hand-crafted patterns used by prior work [3], [15], [4]. Figure 6 visualizes representative ACFGs from three families. Three illustrative newly discovered patterns are: P1 (write-before-read): ransomware writes to an auxiliary ﬁle before reading the original, a technique used by DarkSide to pre-allocate the output buffer and evade write-volume detectors; P2 (multirename chain): the encrypted ﬁle is renamed twice in sequence (e.g., file.txt→file.tmp→file.locked), observed in GoldenEye variants to break simple renamesequence signatures; P3 (delete-then-recreate): the original ﬁle is deleted and recreated with encrypted content rather than overwritten, bypassing integrity monitors that track write operations on existing ﬁles, seen in Maze. Critically, ﬁle-overwrite operations are not conﬁned to the ﬁnal stage of encryption, as assumed by UNVEIL [3]; they can occur before or during intermediate I/O stages. This diversity of patterns has a practical security beneﬁt: the richer the signature set, the harder it is for an adversary to craft event sequences that evade all known patterns simultaneously. The 165 patterns have been translated into detection rules suitable for deployment in SOC environments [28]. Sage

6.2. Multi-File Encryption Strategies

5 Delete 9

Wannacry

CryptoWire

Create 1 Create FileCreate 3 1 0 2 4 5 Rename 6

3 6 Read

FileCreate

Create 1

Create 3

Delete

1 16 5

6 7 Rename 13

5 5

Write 7

A key motivation for FEGs is that ransomware often fragments encryption across multiple ﬁles. Table 8 quantiﬁes this across 624,093 FEGs extracted from 67 families. Approximately 56% of variants overwrite the original ﬁle in place (single-ﬁle strategy), while 31% create a separate output ﬁle (two-ﬁle strategy). Notably, about 12% employ three or more ﬁles, a complexity tier that existing detectors, which model at most two ﬁles per pattern [3], [5], [10], cannot capture. DEFEAT successfully identiﬁed ten families operating in this regime: Virlock, Dharma, dotExe, Pack14, Sage, WannaCry, Mesiponza, MountLocker, DarkSide, and

FileDelete Write 10 8

Write

FileDelete

2 10

4 Read

Create 12 6

9 7

4 3

11 17

FileDelete

4 FileCreate

FileCreate

Figure 6: Representative malicious ACFGs extracted from three ransomware families, illustrating distinct ﬁle I/O structures captured by DEFEAT. Cluster analysis further reveals that taxonomically distinct ransomware families converge on shared I/O behaviours: on average each cluster spans 7.3 families, with Sodinokibi appearing in 28 distinct clusters – evidence that

behaviour-centric clustering captures structural invariants that per-family signatures miss (see Appendix A for full cluster breakdown).

7. Limitations and Future Work Logging overhead. DEFEAT requires ﬁne-grained ETW-based ﬁle I/O logs. As measured in Section 5.3, FEG construction adds a median of 14.7 ms latency per ﬁle operation, 3.2% additional CPU utilisation, 85 MB in-memory FEG store, and approximately 1.2 GB/hour of raw ETW log storage at full endpoint activity. While these ﬁgures are acceptable on modern enterprise hardware, they may be impractical on resourceconstrained or legacy endpoints. The logs can also contain sensitive metadata (ﬁle names, paths, user identiﬁers). Edgebased pre-ﬁltering – constructing FEGs locally and forwarding only FEGs of interest – combined with selective logging and on-device anonymisation would reduce both resource cost and privacy exposure. Adaptive and low-and-slow evasion. Section 5.7 demonstrates 93.9% detection under worstcase event manipulation; however, a sufﬁciently resourceful adversary could employ more subtle strategies. For instance, ransomware could interleave benign-looking ﬁle operations to dilute the behavioural signal within a FEG, or spread encryption across extended time windows so that no single FEG accumulates enough discriminative structure to be ﬂagged. Such time-based evasion is a known challenge for any system that segments activity into bounded analysis units [9]. Potential mitigations include integrating temporal outlier detection to identify anomalously prolonged ﬁle operation sequences, continuously retraining the embedding and clustering models as new families emerge, and fusing ﬁle I/O context with complementary signals such as network telemetry, registry modiﬁcations, and process genealogy. A multi-modal approach would raise the cost of evasion substantially, as an adversary would need to simultaneously manipulate multiple independent observation channels to avoid detection.

8. Related work Ransomware detection has been explored through three main directions: (1) behaviour-based crypto ransomware detection, (2) machine learning–based analysis of system activities, and (3) decoy ﬁle–based detection. Crypto ransomware detection. Early works monitored ﬁle I/O patterns to identify encryption activities. UNVEIL [3] analysed ﬁle access sequences to detect ransomware dynamically, while Redemption [5] and CryptoDrop [7] relied on frequent or bursty ﬁle modiﬁcations as indicators of encryption. Although effective in batch scenarios, these systems often detect ransomware only after substantial data loss. Recoveryoriented defences such as ShieldFS [6], PayBreak [29], and FlashGuard [8] mitigate damage post-attack but incur

high overhead or depend on speciﬁc crypto implementations. Machine learning–based detection. Several studies leveraged behavioural features for model-driven detection. RWGuard [10] used process I/O statistics, achieving low false positives but remaining limited to crypto ransomware. EldeRan [11], Hirano et al. [30], and Nieuwenhuizen [26] incorporated system and API features for classiﬁcation, while Cohen et al. [31] analysed memory artefacts for detection. However, these approaches often depend on static feature sets, limiting generalisation to unseen ransomware behaviours or evasion techniques. Decoy-based detection. Honeypot and decoy ﬁle techniques (e.g., R-Locker [32], RWGuard [10], ShieldFS [6]) detect ransomware by baiting access to deceptive ﬁles. While simple and effective, these approaches can be bypassed by sophisticated samples that distinguish or ignore decoys, and they struggle with ransomware targeting speciﬁc system ﬁles (e.g., Petya). A comprehensive recent survey by Oz et al. [28] catalogues behavioral characterization techniques and deployability challenges across the ransomware detection landscape, reinforcing that fragmented ﬁle I/O context – the core problem addressed by DEFEAT – remains a fundamental blind spot in existing defenses. In contrast, DEFEAT extracts ﬁnegrained system events directly from the Windows kernel via ETW, constructing uniﬁed behavioural graphs that capture contextual relationships among ﬁle I/O activities. This event-centric representation enables early, generalisable, and resilient detection of diverse ransomware families without reliance on static features, predeﬁned patterns, or decoy triggers.

9. Conclusions This paper introduces DEFEAT, a novel approach for the automated identiﬁcation of contextually related ﬁle I/O events to detect ransomware threats. DEFEAT analyzes I/O events from multiple ﬁles to construct a uniﬁed representation of the underlying behavior, enabling a comprehensive understanding of the overall context. Our extensive evaluation demonstrates DEFEAT’s superior performance compared to three state-of-the-art approaches, achieving 99.2% detection accuracy on a dataset of 97,816,471 ﬁle I/O events from 67 ransomware families; DEFEAT outperforms existing methods by 6.57–7.56 percentage points in detection rate. Moreover, DEFEAT identiﬁed 165 previously undocumented malicious ﬁle I/O patterns, highlighting its potential for generating new ransomware detection rules and reducing the workload of security analysts by 94%. The system demonstrates remarkable resilience against adversarial manipulations, maintaining a 93.9% detection rate even when ﬁle I/O event sequences are deliberately altered to evade detection.

Ethical Considerations All ransomware samples were executed exclusively within isolated VirtualBox virtual machines with no network

access, preventing any harm to third-party systems or data. Samples were obtained solely from public malware repositories (VirusTotal, MalwareBazaar) under their standard research-use terms. No human subjects were involved, no real user data were exﬁltrated. The dataset of ﬁle I/O events contains only kernel-level ﬁle operation metadata (event types, ﬁle keys, timestamps, and I/O sizes); it does not contain ﬁle contents, personally identiﬁable information, or any data recoverable from the virtual machine environment. All the dataset including the malicious I/O patterns derived from this study were shared with the security community exclusively as defensive detection rules.

References [1]

[2]

[3]

[4]

[14] B. A. S. Al-rimy, M. A. Maarof, and S. Z. M. Shaid, “A 0-day aware crypto-ransomware early behavioral detection framework,” in International Conference of Reliable Information and Communication Technology, 2017, pp. 758–766. [15] A. Kharraz, W. Robertson, D. Balzarotti, L. Bilge, and E. Kirda, “Cutting the Gordian knot: A look under the hood of ransomware attacks,” in International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment, 2015, pp. 3–24.

[16] “ETW: Event Tracing for Windows,” https://www.ired.team/miscellaneous-reversing-forensics/windows-kernel-internals/etw [17] Y. Bai, H. Ding, Y. Qiao, A. Marinovic, K. Gu, T. Chen, Y. Sun, and W. Wang, “Unsupervised inductive graph-level representation learning via graph-graph proximity,” arXiv preprint arXiv:1904.01098, 2019. [18] K. Xu, W. Hu, J. Leskovec, and S. Jegelka, “How powerful are graph neural networks?” ICLR, 2019.

Australian Signals Directorate, “Annual cyber threat [19] “HDBSCAN,” https://github.com/scikit-learncontrib/. report 2024–2025,” 2025. [Online]. Available: https://www.cyber.gov.au/about-us/view-all-content/reports-and-statistics/annual-cyber-threat-report-2024-2025 [20] Microsoft, “KrabsETW,” https://github.com/microsoft/krabsetw/, accessed: 2021-06-10. Chainalysis, “Ransomware payments exceed $1.1 billion in 2023,” 2024. [Online]. Available: [21] Virustotal, “Analyze suspicious ﬁles and urls to detect types of https://www.chainalysis.com/blog/ransomware-2024/ malware, automatically share them with the security community?” A. Kharaz, S. Arshad, C. Mulliner, W. Robertson, and E. Kirda, “UNhttps://www.virustotal.com/, accessed: 2021-06-10. VEIL: A large-scale, automated approach to detecting ransomware,” [22] MalwareBazaar, “Sharing malware samples with the InfoSec in 25th USENIX Security Symposium (USENIX Security 16), 2016, community, AV vendors and threat intelligence providers.” pp. 757–772. https://bazaar.abuse.ch/, accessed: 2021-06-10. M. E. Ahmed, H. Kim, S. Camtepe, and S. Nepal, “Peeler: Proﬁling kernel-level events to detect ransomware,” in European Symposium [23] The Zoo, “A live malware repository,” on Research in Computer Security. Springer, 2021, pp. 240–260. https://github.com/ytisf/theZoo/, accessed: 2021-06-10.

[5]

A. Kharraz and E. Kirda, “Redemption: Real-time protection against ransomware at end-hosts,” in International Symposium on Research in Attacks, Intrusions, and Defenses, 2017, pp. 98–119.

[24] Fabrizio Monaco, “Malware samples,” https://github.com/fabrimagic72/malware-samples/, accessed: 202106-10.

[6]

A. Continella, A. Guagnelli, G. Zingaro, G. De Pasquale, A. Barenghi, S. Zanero, and F. Maggi, “ShieldFS: a self-healing, ransomwareaware ﬁlesystem,” in Proceedings of the 32nd Annual Conference on Computer Security Applications, 2016, pp. 336–347.

[25] U. Bayer, P. M. Comparetti, C. Hlauschek, C. Kruegel, and E. Kirda, “Scalable, behavior-based malware clustering,” in Proceedings of the Network and Distributed System Security Symposium (NDSS), 2009.

[7]

N. Scaife, H. Carter, P. Traynor, and K. R. Butler, “Cryptolock (and drop it): stopping ransomware attacks on user data,” in 36th IEEE International Conference on Distributed Computing Systems (ICDCS), 2016, pp. 303–312.

[8]

J. Huang, J. Xu, X. Xing, P. Liu, and M. K. Qureshi, “FlashGuard: Leveraging intrinsic ﬂash properties to defend against encryption ransomware,” in Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, 2017, pp. 2231–2244.

[9]

S. M. Milajerdi, B. Eshete, R. Gjomemo, and V. Venkatakrishnan, “POIROT: Aligning attack behavior with kernel audit records for cyber threat hunting,” in Proceedings of ACM SIGSAC Conference on Computer and Communications Security, 2019, pp. 1795–1812.

[10] S. Mehnaz, A. Mudgerikar, and E. Bertino, “RWGuard: A real-time detection system against cryptographic ransomware,” in International Symposium on Research in Attacks, Intrusions, and Defenses, 2018, pp. 114–136. [11] D. Sgandurra, L. Muñoz-González, R. Mohsen, and E. C. Lupu, “Automated dynamic analysis of ransomware: Beneﬁts, limitations and use for detection,” arXiv preprint arXiv:1609.03020, 2016. [12] L. Zhao and M. Mannan, “TEE-aided write protection against privileged data tampering,” arXiv preprint arXiv:1905.10723, 2019. [13] B. A. Alahmadi, L. Axon, and I. Martinovic, “99% false positives: A qualitative study of SOC analysts’ perspectives on security alarms,” in Proceedings of the 31st USENIX Security Symposium (USENIX Security), Boston, MA, USA, 2022, pp. 10–12.

[26] D. Nieuwenhuizen, “A behavioural-based approach to ransomware detection,” Whitepaper. MWR Labs Whitepaper, 2017. [27] Oracle, “Oracle virtualbox,” https://www.virtualbox.org/, accessed: 2021-06-10. [28] H. Oz, A. Aris, A. Levi, and A. S. Uluagac, “Crypto-ransomware and their defenses: In-depth behavioral characterization, discussion of deployability, and new insights,” ACM Computing Surveys, 2026, to appear. [29] E. Kolodenker, W. Koch, G. Stringhini, and M. Egele, “PayBreak: Defense against cryptographic ransomware,” in Proceedings ACM on Asia Conference on Computer and Communications Security, 2017, pp. 599–611. [30] M. Hirano and R. Kobayashi, “Machine learning based ransomware detection using storage access patterns obtained from live-forensic hypervisor,” in Sixth IEEE International Conference on Internet of Things: Systems, Management and Security (IOTSMS), 2019, pp. 1– 6. [31] A. Cohen and N. Nissim, “Trusted detection of ransomware in a private cloud using machine learning methods leveraging metafeatures from volatile memory,” Expert Systems with Applications, vol. 102, pp. 158–178, 2018. [32] J. Gómez-Hernández, L. Álvarez-González, and P. García-Teodoro, “R-Locker: Thwarting ransomware action through a honeyﬁle-based approach,” Computers & Security, vol. 73, pp. 389–398, 2018.

Appendix A. Cluster Structure and Cross-Family Behaviour 80

Here we examine the internal composition of DEFEAT’s clusters to understand how ransomware behaviours distribute across families – a perspective that is invisible to detectors operating at the individual-sample level. Cluster size distribution. Figure 7 (left) plots the empirical CDF of cluster size. The distribution is heavily skewed: a small number of clusters account for the majority of all ACFGs (min = 5, max = 6,281, µ = 82, σ = 427). This concentration has a direct operational implication: labelling only the largest clusters ﬁrst provides rapid coverage of most ransomware behaviours, enabling analysts to prioritise effort where it yields the greatest return. 300

200

1 0.8

150 100

0.4

SOD SAG

UNK PET DIS

PAC KEY XOR

GOL

−40

DHA MAL

DHA

−40

−20

XOR TES VIP

SHA SOD

SOD SAG

GAN CER DHA

−60 −60

SAG

ADO VIP UCY ADO KEY UNK

UNL ADO VIP

VIP TES CER

−20

SOD CER

SAG

MAL DHA

DHA

Figure 8: The 20 largest malicious ACFG clusters visualized via t-SNE. Abbreviations: Adobe (ADO), Cerber (CER), District (DIS), Dharma (DHA), GoldenEye (GOL), GandCrab (GAN), Keypass (KEY), Malevich (MAL), Peta (PET), Pack14 (PAC), Sage (SAG), Shade (SHA), Sodinokibi (SOD), TeslaCrypt (TES), Unknown (UNK), Unlock92 (UNL), Vipasana (VIP), Xorist (XOR).

100 50

90 12 0 AD O C ER D H G A O SA L G SO D TE S

Cluster size

0 60

10 1k 2k 3k 4k 5k 6k

0.2

CDF

200 0.6

GOL

Cluster diversity

Figure 7: Left: empirical CDF of cluster size – a small number of clusters dominate the population. Middle: histogram of unique ransomware families per cluster (cluster diversity). Right: the eight most frequently observed ransomware families across clusters. Cross-family cluster diversity. We deﬁne cluster diversity as the number of unique ransomware variants represented within a single cluster. On average, each cluster contains samples from seven distinct families; the most diverse cluster spans 122 variants (min = 1, max = 122, µ = 7.3, σ = 9.4). This ﬁnding carries an important implication: ransomware families that are taxonomically distinct nonetheless converge on shared encryption behaviours at the ﬁle I/O level. DEFEAT’s graph embeddings capture these structural similarities, grouping functionally equivalent workﬂows regardless of family lineage. Figure 8 visualizes the 20 largest malicious clusters via t-SNE projection of the ACFG embeddings. Each cluster contains ACFGs from one to three dominant families, with clear spatial separation between clusters. Three families – Sodinokibi (SOD), Dharma (DHA), and GoldenEye (GOL) – appear across a disproportionate number of clusters, reﬂecting their rich repertoire of encryption strategies. Figure 7 (right) quantiﬁes this: Sodinokibi alone appears in 28 distinct clusters, with Dharma and GoldenEye following

closely. This behavioural polymorphism – where a single family exhibits many distinct operational modes – underscores the inadequacy of per-family signature approaches and validates DEFEAT’s unsupervised, behaviour-centric clustering.

Record · ID 1006793 · SHA-256 916c6857deff025d
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.