Hardware Performance Counter Analysis of Ransomware Behavior: Observed Inverse Correlations Across Heterogeneous x86 Platforms

Abstract

During startup, ransomware is associated with abnormal fluctuations in underlying hardware resources. Hardware Performance Counters (HPC) can characterize this ultra-early behavior without interference from software-based countermeasures. However, existing studies lack a cross-platform hardware-layer analysis paradigm and typically neglect the first 10 s post-execution. This study selects two platforms—Windows 7 (homogeneous x86) and Windows 10 (Intel performance hybrid architecture with P-core (performance core) and E-core (efficiency core))—and constructs a large-scale dataset (1721 ransomware and 1039 benign samples on Windows 7; 1562 ransomware and 718 benign on Windows 10). On Windows 7, 25 HPC events are monitored. On Windows 10, each event yields two instance-level metrics (P-core and E-core), resulting in 42 instance-level metrics. Using statistical analysis (Pearson correlation, fold change) and feature selection (Random Forest + clustering), four core metrics are independently selected per platform. Windows 7 favors LLC and branch events (increasing trends, fold change ≥ 1.5, e.g., LLC-store_std), while Windows 10 favors P/E-core branch and cache events (decreasing trends, fold change ≤ 0.667, e.g., cpu_atom_branch-load-misses_max). The 10 s window is divided into startup (0–2 s), key generation (2–5 s), and encryption (5–10 s) phases. Results indicate opposite correlation patterns: resource-enhanced disturbance (positive correlation, fold change ≥ 1.5) on Windows 7 versus resource-suppressed disturbance (negative correlation, fold change ≤ 0.667) on Windows 10. Critically, startup-phase HPC events exhibit substantially stronger correlation on Windows 10 (S-level, >85%) compared to Windows 7 (A-level, 70–84%). This difference may be associated with the fine-grained P/E-core separation, which preserves core-type behavioral information that is aggregated and lost on homogeneous platforms. This study contributes a cross-platform correlation framework, observes an architecture-dependent inversion pattern of HPC responses, and suggests that core-type granularity—rather than event quantity—is associated with stronger feature–behavior correlations on heterogeneous architectures, providing preliminary empirical insights for future lightweight detection system design.

1. Introduction

1.1. Background and Motivation

Ransomware remains a persistent threat in cyberspace. In its attack chain, the startup phase—before large-scale encryption begins—offers the narrowest window for early detection. Although malicious behavior during this phase is deliberately concealed, it is associated with specific fluctuations in underlying hardware resources. Hardware Performance Counters (HPCs), which capture low-level CPU events (e.g., instruction flows, cache behavior, memory management), operate at the hardware layer and are inherently immune to software-based anti-detection techniques such as packing and obfuscation. HPC-based analysis is therefore considered a foundation for early ransomware detection research.

1.2. Related Work

1.2.1. HPC-Based Malware Detection

The use of Hardware Performance Counters (HPCs) for security has been systematically examined in the SoK paper by Das et al. [1], which comprehensively analyzed the challenges, pitfalls, and perils of leveraging HPC events for malware detection. Their work highlighted that while HPC events exhibit strong correlations with malicious behavior, the community lacks standardized correlation analysis methodologies.

Following this line, Demme et al. [2] first demonstrated the feasibility of using HPC events to distinguish malware from benign software. Concurrently, Tang et al. [3] proposed an unsupervised anomaly detection approach using HPCs, showing that real-world exploits can be detected with nearly perfect certainty. However, their work did not analyze event–behavior correlations. Aurangzeb et al. [4] built a hardware profile-based detection model for Windows ransomware, prioritizing performance optimization without exploring intrinsic correlations. Thummapudi et al. [5] proposed a multi-dimensional hardware usage detection scheme but did not map hardware events to specific behavioral phases. Critically, all existing HPC-based studies treat events as black-box features on single platforms, leaving cross-platform correlation mechanisms entirely unexplored.

Recent theoretical advances include Pundir et al. [6], who presented a hardware-assisted runtime detection framework for crypto-ransomware, formally characterizing the relationship between hardware profiling and detection effectiveness. Zhao et al. [7] achieved high detection accuracy within a short time window using selected HPC events on large ransomware datasets. Anand et al. [8] employed hardware event characteristics for early feature selection, reaching promising accuracy within the 10 s observation window across multiple ransomware families.

However, these studies remain confined to single platforms and do not analyze cross-platform correlation mechanisms. Furthermore, the virtualization-induced distortion of HPC measurements (e.g., partial PMU virtualization in VirtualBox) and its impact on cross-platform comparisons have received little attention in the literature. As noted by Serebrin and Hecht [9], standard profiling tools rely on hardware performance counters that are not fully exposed to guests by most hypervisors, due to trap-and-emulate overhead and time-sharing of physical CPUs among multiple virtual CPUs. This is particularly relevant for our VirtualBox environment, where the Performance Monitoring Unit (PMU) is not virtualized at all [10].

Beyond ransomware detection, the broader applicability of PMU-based analysis has been demonstrated in other security domains; for instance, PMU-based control-flow attestation has achieved high accuracy in detecting control-flow hijacking attacks [11].

1.2.2. Phase-Aware Behavioral Analysis

Ransomware execution within the first 10 s is typically divided into three sequential phases: startup, key generation, and encryption. Existing studies support this partitioning: Anand et al. [8] confirmed that the early runtime can be divided into startup and encryption phases; Thummapudi et al. [5] showed that HPC indicators differ significantly across these phases; and Putrevu et al. [12] validated that different time windows capture distinct phase patterns. Guo et al. [13] further demonstrated the inherent “read-encrypt-write” I/O pattern in ransomware encryption.

Notably, few studies have mapped HPC events specifically to the startup phase (first 2 s) in cross-platform scenarios. Most recently, Binder et al. [14] performed HPC correlation analysis for ransomware detection but limited their work to a single platform (Intel Skylake), without comparing homogeneous versus heterogeneous architectures or mapping events to specific phases. More generally, the cross-platform generalizability of phase-specific HPC signatures—especially across different CPU microarchitectures and operating systems—remains an open question.

1.3. Research Gaps

Based on the above review, three significant gaps remain unaddressed:

Gap 1: Lack of cross-platform correlation. Existing HPC studies [2,4,5] are conducted on single platforms, with no comparative analysis across homogeneous (e.g., Win7 x86) and heterogeneous (e.g., Win10 P/E-core) architectures. As noted by Raff et al. [15], cross-platform malware detection faces fundamental challenges including architectural heterogeneity, which has left cross-platform HPC correlation mechanisms entirely unexplored—a limitation also observed in cross-architecture self-modifying malware detection [16]. Similarly, cross-architecture IoT malware detection has been shown to require platform-specific feature adaptation [17].

Gap 2: Neglect of ultra-early window.Most work focuses on encryption-phase behaviors. The first 10 s—particularly the first 2 s of startup—has not been systematically analyzed across platforms.

Gap 3: Feature selection imbalance. Existing methods prioritize statistical correlation over architectural interpretability, lacking multi-dimensional validation that balances relevance, discriminability, and uniqueness, as pointed out in hardware-assisted detection surveys [18].

1.4. Research Questions

To address the above gaps, this study focuses on two representative platforms: Windows 7 (Win7), representing a traditional homogeneous x86 architecture, and Windows 10 (Win10) running on an Intel performance hybrid architecture (P-cores (performance cores) and E-cores (efficiency cores), analogous to big.LITTLE in ARM). Based on our preliminary observations of HPC event correlations, we monitor 25 HPC events on Win7 and 42 instance-level metrics on Win10 (where each event naturally yields separate P-core and E-core instances). For each platform, four core metrics are independently selected.

We address two research questions:

• RQ1: What patterns characterize the correlation strength between HPC events and ransomware behaviors (startup, key generation, encryption) across Win7 and Win10? Which events exhibit the strongest associations within the first 10 s of execution?
• RQ2: How do cross-platform correlation patterns differ between ransomware and benign tasks, particularly within the first 2 s of the startup phase?

1.5. Contributions

This study makes three primary contributions:

1.

A cross-platform HPC–ransomware correlation framework. We integrate 10 s time-series data with three-phase behavioral partitioning (startup, key generation, and encryption), establishing a complete paradigm of “preprocessing → correlation analysis → validation” that addresses the gap in cross-platform correlation mechanism studies.

2.

Platform-specific core event identification.Through multi-dimensional quantitative analysis, we systematically characterize correlation strength differences across 25 Win7 events and 42 Win10 instance-level metrics, identifying both platform-common and platform-specific core events. This provides interpretable feature sets for understanding ultra-early startup-phase behavior.

3.

An architecture-dependent behavioral observation.We observe that HPC responses invert from “resource-enhanced disturbance” on homogeneous Win7 to “resource-suppressed disturbance” on heterogeneous Win10, with fine-grained P/E-core separation being associated with an increase in correlation strength from 54.90% to 89.91% during the startup phase.

1.6. Paper Organization

The remainder of this paper is structured as follows. Section 2 describes the materials and methods, covering the experimental environment (Section 2.1), data collection (Section 2.2), HPC event selection (Section 2.3), behavioral phase annotation (Section 2.4), and the correlation analysis framework (Section 2.5). Section 3 then reports the main results, including correlation analysis (Section 3.1), feature importance ranking (Section 3.2), and phase matching with correlation characterization (Section 3.3). Section 4 provides a discussion of the implications of these results, followed by Section 5, which concludes the paper and offers directions for future work.

2. Materials and Methods

2.1. Experimental Environment

The experimental environment was built on two physically distinct host machines to cover both legacy and modern x86 architectures, as detailed in

Table 1. Specifications of experimental hardware platforms.

Platform	CPU	RAM	Architecture Feature
A	Intel Core i7-7500U @ 2.90 GHz (2 cores)	8 GB	Legacy homogeneous (no P/E cores)
B	Intel Core Ultra 9 185H @ 2.3 GHz (6P+8E)	32 GB	Modern hybrid (P-cores & E-cores)

. However, it is important to note that the two platforms differ not only in CPU microarchitecture and memory size but also in the guest operating systems (Windows 7 vs. Windows 10) and host operating systems (Ubuntu 20.04 vs. 22.04). Consequently, the observed differences in HPC correlations cannot be uniquely attributed to any single factor (e.g., P/E-core granularity) and should be interpreted as joint OS-plus-architecture observations.

The two platforms represent two distinct computing paradigms: Platform A (i7-7500U) represents legacy homogeneous x86 architectures (e.g., industrial control systems, legacy workstations); Platform B (Ultra 9 185H) represents modern hybrid architectures with P-cores (performance cores) and E-cores (efficiency cores). This selection enables a systematic comparison of ransomware’s HPC fingerprints across representative paradigms, while acknowledging the confounding factors.

Following a virtualization-based approach similar to [6], each physical host was configured with Ubuntu Linux (20.04 for Platform A, 22.04 for Platform B) as the host operating system. VirtualBox (version 6.1.38 on Platform A, 7.0.12 on Platform B) was used to install both Windows 7 SP1 (64-bit) and Windows 10 21H2 (64-bit) virtual machines (VMs) on each host. This dual-OS setup on identical hardware allows for a controlled comparison of HPC event behaviors across Windows versions without hardware-induced confounding factors, but the host OS versions differ, which is a limitation discussed in Section 5.3.

Virtualization and PMU access(as shown in Figure 1).The Linux host used the perf tool (version 5.4 on Ubuntu 20.04, version 5.15 on Ubuntu 22.04) to access the Performance Monitoring Unit (PMU) of the Intel CPUs. VirtualBox does not virtualize the PMU; instead, the guest OS’s performance counters are emulated, and precise event counts may differ from bare-metal execution. This virtualization-induced distortion has been systematically studied in the context of anomaly detection, where sequential performance modeling has been shown to effectively identify irregularities in virtualized environments [19]. We therefore performed a sanity-check comparison on a small subset of samples (5 ransomware and 5 benign) between the VM and bare-metal execution for two representative events (cycles and instructions); the relative differences were within 12%, confirming that the observed patterns are not artifacts of virtualization. Detailed results are provided in Appendix A.

This platform design offers two core advantages:

1.

Non-interference: Monitoring operations on the Linux host do not interfere with ransomware execution inside the Windows VM.

2.

Data integrity: The isolated VM environment prevents ransomware from tampering with the data collection process or escaping to the host system.

On the Linux host side, access to the PMU of Intel x86 architectures was achieved using the perf tool [20]. Perf supports simultaneous monitoring of multiple hardware performance events and captures data that comprehensively reflects system behavior, including normal application execution, operating system operations, and ransomware activities.

All experiments focused on encryption-based ransomware targeting Windows systems. The study monitors 25 HPC events on Windows 7 and 42 instance-level metrics on Windows 10, following the selection criteria detailed in Section 2.3.

While our use of virtualization prioritizes safe malware execution, recent work has demonstrated that HPC events in virtualized environments can also pose side-channel risks [21].

2.2. Data Collection

Using the environment described above, we developed an automated Shell script-based collection pipeline. A dedicated script retrieves target executables, transfers them to the VM via SSH, identifies the target process ID upon execution, invokes perf to collect HPC events, and records data in vectorized format at a sampling interval of 100 ms (10 samples per second). This interval was chosen to balance temporal resolution and measurement overhead; within the 0–2 s startup window, it yields approximately 20 samples per execution, sufficient for statistical analysis. To ensure data independence, a pre-configured system snapshot was loaded before each VM startup, restoring the VM to a pristine state and eliminating cross-contamination from previous executions.

A large-scale dataset was constructed. On Windows 7, the dataset comprises 1721 ransomware samples from 39 families and 1039 benign samples. The same ransomware samples were ported to Windows 10, but samples that failed to execute or were incompatible with the platform were removed, resulting in 1562 ransomware samples and 714 benign samples on Windows 10. The dropped Windows 10 samples belonged primarily to families that rely on legacy system calls or deprecated APIs (e.g., CryptXXX variants). To avoid selection bias, we repeated the headline correlation analysis on the subset of families that executed successfully on both platforms (1562 ransomware and 714 benign samples); the observed inversion pattern remained consistent (see Appendix A).

Ransomware samples. Ransomware samples were collected from [22] and the dataset referenced in [23], spanning from 2008 to 2023. The samples encompass 42 families, covering a wide spectrum of ransomware behaviors including WannaCry, LockBit, REvil, and others.

Benign samples.The benign software dataset was collected from Windows applications and [24]. The samples cover a comprehensive range of application types, including encryption software, secure communication software, antivirus programs, backup software, text editors, file management tools, gaming applications, system utilities, drivers, compression software, and media players. This ensures coverage of common benign behaviors in real-world scenarios, providing a representative baseline for correlation analysis.

2.3. HPC Event Selection

To ensure cross-platform comparability between Windows 7 and Windows 10, the same HPC event definitions were monitored on both platforms. On Windows 7 (Platform A, Intel Core i7-7500U), the perf tool supports 28 measurable HPC events. Based on our preliminary correlation analysis and existing studies [1,2,3], three events—node-load-misses, node-store-misses, and ref-cycles—were excluded, leaving 25 valid HPC events for analysis. The complete list of 25 events on Windows 7 and the 42 instance-level metrics on Windows 10 is provided in Appendix A.

On Windows 10 (Platform B, Intel Core Ultra 9 185H), the Intel performance hybrid architecture (P-cores and E-cores) naturally generates two instance-level metrics for each event. However, due to platform-specific limitations, six events were unavailable (cpu_atom_L1-dcache-load-misses, cpu_atom_node-loads, cpu_atom_iTLB-load, cpu_core_iTLB-load, cpu_atom_node-stores, cpu_core_node-stores). Additionally, two E-core LLC events exhibited invalid data rates exceeding 30% and were discarded. After removing unsupported and ineffective instances, 42 instance-level metrics were retained.

Notably, the event definitions remain identical across both platforms; the increase from 25 events (Win7) to 42 instance-level metrics (Win10) reflects the natural separation of P-core and E-core instances on the heterogeneous architecture, not the addition of new event types.

2.4. Behavioral Phase Annotation

Based on the working mechanism of ransomware, empirical hardware behavior logs, and existing HPC-based ransomware detection studies [6,8,25], the malicious behavior of ransomware is divided into three core phases. Specifically, ref. [25] adopts a 10 s detection window and distinguishes pre-encryption from encryption activities; HiPeR [8] observes that most ransomware variants begin encryption approximately 8–10 s after execution, supporting our 5–10 s encryption phase; and RanStop [6] demonstrates that hardware-level anomalies are detectable within milliseconds of execution, supporting the 0–2 s startup phase.

Table 2. Summary of ransomware behavioral phases.

Phase	Time Window	Core Objective	Hardware Behavior Characteristics
Startup	0–2 s	Program loading, privilege acquisition	Lightweight: instruction translation, cache prefetching
Key Generation	2–5 s	Public/private key generation	Intensive instruction execution, enhanced cache
Encryption & Teardown	5–10 s	Batch encryption, trace cleaning	High-intensity → gradual tapering

summarizes the time window, core objective, and hardware behavior characteristics of each phase.

The phase-specific thresholds used for outlier removal and interval calibration (e.g., lower bound = 0.7 × median, upper bound = mean + 2.0$\sigma$ for startup; 2.5$\sigma$ for key generation; 3.0$\sigma$ and 0.5 × median for encryption) were derived from the empirical distribution of benign samples and validated via perturbation analysis (see Section 3.3.2). This ensures robustness against arbitrary parameter choices.

2.5. Correlation Analysis Framework

A three-stage framework was adopted. Stage 1 (Correlation analysis): Pearson correlation coefficients ($\left|r\right|$) were computed between each HPC metric and ransomware labels. To address the sensitivity of Pearson’s r to class imbalance, we additionally report Cohen’s d as a balance-insensitive effect size (see Section 3.1). Statistical significance was set at p < 0.05 and corrected for multiple comparisons using the Benjamini–Hochberg procedure (false discovery rate q = 0.05). Feature distinguishability was measured by the malicious/benign fold difference (≥2.0 high, $[1.5,2.0)$ medium, <1.5 low). Redundancy was identified when $\left|r\right|$ ≥ 0.8 between features. Stage 2 (Feature importance): Random Forest ranked non-redundant features by a three-dimensional score (association strength, fold difference, redundancy) using permutation importance rather than Gini importance to avoid bias toward high-cardinality features. Clustering reduced redundant features with the number of clusters K determined by the elbow method (see Appendix A). Stage 3 (Phase matching):The 10 s window was divided into startup (0–2 s), key generation (2–5 s), and encryption (5–10 s). Phase-specific thresholds were calibrated via statistical analysis, outlier removal, and interval calibration, followed by offline retrospective validation. Robustness was checked by perturbing each threshold by $\pm 20\%$; the phase alignment accuracy changed by less than 5%.

2.5.1. Validation of Virtualization Distortion on Windows 10 Platform

We performed the same validation on the heterogeneous Windows 10 platform (Intel Ultra 9 185H). As shown in

Table 3. Bare-metal vs. VirtualBox validation on Windows 10 platform (load/idle ratio).

Environment	Core Type	Instructions	CPU Cycles	Cache Misses
Bare-metal	—	36,118×	22,560×	3274×
VirtualBox VM	E-core (Atom)	47×	35×	6.3×
	P-core (Core)	126×	70×	1.2×

, the load-to-idle ratio was positive for all metrics across both bare-metal and VM environments, confirming that the direction of change is preserved under virtualization.

P-core measurements were stable and consistent (coefficient of variation < 5%). E-core measurements showed higher variability, which is consistent with known challenges in virtualizing performance counters on hybrid architectures (Linux kernel commit 4d7404e5ee0066e9a9e8268675de8a273b568b08 (2023): KVM disables vPMU support on hybrid CPUs due to vCPU migration issues and PMU capability enumeration challenges.). After removing three outliers (caused by apparent vCPU migration events), the E-core load-to-idle ratios remained positive (instructions: 47×, cycles: 35×, cache-misses: 6.3×), confirming that virtualization does not reverse correlation signs on either core type. The higher stability of P-core measurements suggests that performance cores are more reliable for HPC-based detection in virtualized environments.

2.5.2. Impact of Virtualization on HPC Measurements

Virtualization introduces known overheads that can affect absolute HPC counts, including trap-and-emulate for privileged instructions, VM exits, and CPU time-sharing among multiple virtual CPUs. However, the key conclusions of this study rely on relative comparisons (ransomware vs. benign) and the direction of correlations, rather than absolute values. As validated by the bare-metal sanity checks above, the sign of these relative changes is preserved under virtualization. Therefore, while absolute counts may shift, the observed correlation patterns—particularly the opposite signs between Windows 7 and Windows 10—are not artifacts of the virtualized environment.

3. Results

3.1. Correlation and Redundancy Analysis

• Overall Distribution of Effect Sizes (Cohen’s d)

To evaluate the separation between ransomware and benign programs, we report Cohen’s d, a balance-insensitive effect size recommended over Pearson’s r when class distributions are imbalanced. All p-values were corrected for multiple comparisons using the Benjamini-Hochberg procedure (false discovery rate q = 0.05).

On Windows 7, most HPC features show positive Cohen’s d (e.g., node-stores_std: d = 0.949), indicating that ransomware activity increases event values—a pattern we term resource-enhanced disturbance . In contrast, on Windows 10, the majority of features exhibit negative Cohen’s d with large absolute values (e.g., cpu_atom_branch-load-misses_std: d = −3.36), revealing a resource-suppressed disturbance where ransomware decreases event values.

Table 4. Effect size distribution (Cohen’s d) after FDR correction.

Effect Size	Win7 (Count/%)	Win10 (Count/%)	Interpretation
Large ($\left|d\right|$ ≥ 0.8)	35 (35.0%)	118 (70.2%)	Strong separation
Medium (0.5 ≤ $\left|d\right|$ < 0.8)	30 (30.0%)	28 (16.7%)	Moderate separation
Small ($\left|d\right|$ < 0.5)	35 (35.0%)	22 (13.1%)	Weak separation
Significant (FDR)	100 (100%)	168 (100%)	$p_{\mathrm{FDR}}$ < 0.05

Note: Based on all four statistical features (mean, std, max, med) for each event. Negative d (dominant on Win10) indicates resource-suppressed disturbance. All p-values are Benjamini-Hochberg corrected.

summarizes the effect size distribution on each platform. The opposite signs and the higher proportion of large effects on Windows 10 (70.2% vs. 35.0%) confirm the inversion phenomenon and indicate that the heterogeneous P/E-core architecture amplifies the HPC response.

Figure 2 and Figure 3 show the top-10 correlated events according to Pearson’s r (provided for intuitive comparison; the main conclusion relies on Cohen’s d). Consistent with the Cohen’s d analysis, Windows 7 exhibits only positive r (none strong), while Windows 10 shows strong negative r for events dominated by E-core std/max statistics.

2.

Category-Level Redundancy Analysis

Quantitative comparison reveals significant differences in feature coupling and information overlap, as shown in Figure 4a,b. We define high-redundancy features as those with pairwise inter-correlation above 0.8 (absolute value). Windows 7 has an average inter-feature correlation of 0.470, while Windows 10 has 0.546, indicating that Win10 exhibits higher feature correlation and more pronounced information overlap. Regarding high-quality low-redundancy features (not in high-redundancy set, $\left|r\right|\ge 0.1$, fold change $\ge 1.1$), Win7 has 72 such features, whereas Win10 has 57, indicating that Win7 contains richer independent and complementary features.

On Windows 7, dTLB address translation and CPU control categories exhibit relatively low internal correlation (0.394 and 0.397), indicating better feature independence, while Branch prediction and Cache categories show higher redundancy (0.655 and 0.644). On Windows 10, redundancy increases across all categories, with Branch prediction and Cache remaining the most redundant (0.706 and 0.579),as summarized in

Table 5. Category-level redundancy comparison.

Category	Windows 7		Windows 10
	Avg. |r|	High Red.	Avg. |r|	High Red.
Cache	0.644	0.829	0.579	0.796
Branch prediction	0.655	0.775	0.706	0.925
dTLB address translation	0.394	0.286	0.463	0.476
CPU control	0.397	0.250	0.504	0.500

Note: “Avg. |r|” is the mean absolute Pearson correlation among features within the same category; “High Red.” is the proportion of feature pairs with |r| ≥ 0.8.

. Notably, the dTLB category’s average correlation rises from 0.394 to 0.463, and its high-redundancy proportion increases from 0.286 to 0.476, suggesting stronger cross-core coupling in address translation behavior. The high-redundancy proportion is substantially higher on Win10 for all categories, confirming that feature redundancy is amplified on heterogeneous platforms.

The number of cross-platform universally stable features is zero, confirming that the two platforms have fundamentally different correlation structures and sensitive event types. No directly reusable stable feature subset exists.

3.

Summary and Recommendations

The observed differences in effect size, category-level redundancy, and high-quality feature distribution confirm that hardware architecture and operating system jointly determine HPC feature correlation characteristics. Therefore, cross-platform detection models cannot rely on a unified feature set. Platform-specific feature selection is recommended:

• Windows 7: Prioritize low-redundancy features from the dTLB address translation category, which exhibits the best independence.
• Windows 10: Apply aggressive feature selection and dimensionality reduction to highly redundant categories such as cache and dTLB.

This differentiated category-level optimization strategy can effectively reduce redundancy, improving model efficiency and generalization capability.

3.1.1. Difference Fold Change Analysis

The difference fold change between malicious and benign samples directly reflects the discriminative capability of HPC events.

Table 6. Difference fold change classification on Windows 7 and Windows 10.

Category	Win7 (%)	Win10 (%)	Key Observations
High-difference (fold ≥ 2.0)	45 (45.0%)	57 (33.9%)	Win7: higher proportion, focused on cache/LLC; Win10: focused on med features
Moderate-difference (1.5 ≤ fold < 2.0)	14 (14.0%)	26 (15.5%)	Similar proportions, Win10 slightly higher
Low-difference (fold < 1.5)	41 (41.0%)	85 (50.6%)	Win10 higher proportion, consistent with “high correlation but low difference”

Note: Based on all four statistical features (mean, std, max, med). Fold change is computed as μ_mal/μ_ben.

summarizes the statistical results.

The core high-difference event types differ significantly between platforms. On Windows 7, high-difference events are concentrated on last-level cache and memory nodes (e.g., LLC-store_med, iTLB-loads_med), with a higher proportion (45.0%) of features showing fold change ≥ 2.0. On Windows 10, high-difference events are concentrated on L1 cache and TLB (e.g., L1-dcache-stores_med, iTLB-load-misses_med), but the overall proportion of high-difference features is lower (33.9%), while the proportion of low-difference features is higher (50.6%). This aligns with the observation that Windows 10 exhibits “high correlation but low difference”—likely due to elevated benign baselines caused by background services. Additionally, Windows 10 exhibits core-type preference (32 events on P-cores vs. 26 on E-cores), whereas Windows 7 has no core differentiation due to its homogeneous architecture.

Despite these differences, commonalities exist: over 90% of events are statistically significant after FDR correction on both platforms, cache-related events are consistently sensitive to ransomware, and memory node events (e.g., node-loads) perform weakly on both platforms.

Based on this analysis, cross-platform ransomware detection requires platform-specific modeling: Windows 7 should prioritize std/mean features from cache and memory node events, while Windows 10 should focus on med features from P-core L1 cache and TLB events. The common screening logic—prioritizing cache events while excluding memory node events—can be reused to balance detection accuracy and efficiency.

3.1.2. Key Findings Summary

In summary, the correlation, redundancy, and fold change analyses reveal three key findings:

1.

Opposite effect directions and stronger separation on Win10: Windows 7 exhibits positive Cohen’s d (resource-enhanced disturbance), while Windows 10 exhibits negative Cohen’s d (resource-suppressed disturbance). The proportion of large effects ($\left|d\right|\ge 0.8$) is substantially higher on Windows 10 (70.2%) than on Windows 7 (35.0%).

2.

Different redundancy characteristics: Windows 7 exhibits lower overall redundancy (0.470 vs. 0.546) and more low-redundancy high-quality features (72 vs. 57), indicating better feature independence. Windows 10 shows higher redundancy across all categories due to its heterogeneous architecture, with Branch prediction and Cache categories being the most redundant.

3.

Divergent high-difference event types: Windows 7 has a higher proportion of high-difference features (45.0% vs. 33.9%), concentrated on last-level cache and memory nodes. Windows 10 has a higher proportion of low-difference features (50.6% vs. 41.0%), with high-difference events concentrated on L1 cache and TLB, and exclusively using median (med) features.

These findings confirm that cross-platform detection cannot rely on a unified feature set. The following section presents feature importance analysis to further identify the most discriminative features for each platform.

A notable observation: Among the 18 strongly correlated events on Windows 10 ($\left|r\right|\ge 0.6$), a clear pattern emerges: 12 events (66.7%) are E-core events, with branch-related events (e.g., cpu_atom_branch-load-misses) showing the highest absolute correlations ($r\approx -0.83$). This disparity suggests that efficiency cores capture ransomware’s branch behavior more distinctly than performance cores. We analyze the mechanisms underlying this observation in Section 4.

3.2. Feature Importance Ranking

Feature selection is essential to remove irrelevant and redundant features while preserving discriminative power. Following the taxonomy established by Guyon and Elisseeff [26], we adopt a hybrid filtering approach combining correlation-based screening and importance ranking. Feature importance was quantified using Random Forest [27] with permutation importance rather than Gini impurity, as permutation importance is unbiased toward high-cardinality features and provides a more reliable ranking when features have different scales or value ranges [28].

Based on the correlation and difference analysis above, we further evaluated feature importance following a three-stage pipeline: (1) initial feature screening based on correlation strength and fold change, (2) Random Forest permutation importance scoring, and (3) clustering-based optimization to reduce redundancy. The clustering number K was determined using the elbow method (see Appendix A), and sensitivity analysis for $K\in \{2,3,4,5,6\}$ confirmed that the selected feature set remains stable.

As defined in the abstract, resource-enhanced disturbance refers to positive correlation and fold change ≥ 1.5 (increasing trends), while resource-suppressed disturbance refers to negative correlation and fold change ≤ 0.667 (decreasing trends). These patterns are used throughout this section to characterize the observed directional differences between the two platforms.

3.2.1. Initial Feature Screening

Based on the correlation analysis above, we performed initial screening following three criteria: (1) remove features with $\left|r\right|\ge 0.95$ (near-perfect redundancy); (2) retain features with fold change $\ge 1.3$ or $\le 0.77$ (distinguishing malicious from benign); (3) retain features with $\left|r\right|\ge 0.20$ (moderate correlation with label). These thresholds were determined empirically based on the distribution of each metric: $\left|r\right|\ge 0.20$ captures features with at least weak correlation; fold change $\ge 1.3$ retains features with at least 30% difference between malicious and benign means; Cohen’s $d\ge 0.2$ corresponds to a small but non-negligible effect size [29]. The near-perfect redundancy threshold follows common practice in feature selection to remove virtually identical features.

After screening, 9 features were retained on Windows 7 and 14 on Windows 10, as shown in Figure 5.

All retained features satisfy correlation ($\left|r\right|\ge 0.20$), statistical significance after FDR correction ($p_{\mathrm{FDR}}<0.05$), discriminative fold change, and a small or larger effect size (Cohen’s $d\ge 0.2$).

Windows 7: The retained features are dominated by LLC storage, cache misses, and node events, all with fold change $>1$ (increasing trend) and positive Cohen’s d (e.g., node-stores_std: $d=0.949$), consistent with the resource-enhanced disturbance pattern.

Windows 10: The retained features are concentrated on branch mispredictions, bus cycles, and cache misses on both P-cores and E-cores, with fold change $<0.77$ (decreasing trend) and large negative Cohen’s d (e.g., cpu_atom_branch-load-misses_std: $d=-3.36$), consistent with the resource-suppressed disturbance pattern.

No common feature exists across the two platforms, confirming strong platform dependency and the absence of a universal feature subset.

3.2.2. Random Forest Importance Scoring

Note

The Random Forest classifier is employed solely as a quantitative tool to evaluate the discriminative power of the selected HPC features. The reported accuracy reflects feature quality, not the performance of a deployable detection system.

Evaluation Framework

Using the candidate features after initial screening as inputs and the malware/benign label as the target, we constructed a Random Forest model with 150 trees and 5-fold stratified cross-validation. Feature importance was quantified using permutation importance [27], which measures the decrease in model accuracy when a feature is randomly shuffled. Unlike Gini impurity, permutation importance is unbiased toward high-cardinality features and provides a more reliable ranking.

Cross-Validation Accuracy

On Windows 7, the model achieved a classification accuracy of $92.8\%\pm 0.7\%$ using the 9 candidate features. On Windows 10, the model achieved $98.5\%\pm 0.6\%$ using the 14 candidate features, which is comparable to recent HPC application classification results  [30].

Generalization to Unseen Families

To evaluate whether the selected features generalize beyond the training families, we performed leave-one-family-out validation on 51 unseen ransomware samples from three families (MedusaLocker, BianLian, and Adhubllka). As shown in

Table 7. Leave-one-family-out validation results.

Platform	MedusaLocker	BianLian	Adhubllka	Overall
Windows 7	33/33 (100%)	9/9 (100%)	2/9 (22.2%)	44/51 (86.3%)
Windows 10	33/33 (100%)	9/9 (100%)	9/9 (100%)	51/51 (100%)

Note: Bold values indicate the highest detection rate (100%) within each category.

, the model achieved 86.3% recall (44/51) on Windows 7 and 100% recall (51/51) on Windows 10. The lower recall on Windows 7 is attributed to the Adhubllka family (22.2%), which exhibited minimal encryption activity during the 10 s observation window. On Windows 10, all families were detected with 100% recall, demonstrating that the heterogeneous P/E-core architecture provides more robust and generalizable HPC features.

Feature Importance Ranking

Figure 6 shows the permutation importance scores for Windows 7 and Windows 10.

On Windows 7, the top-3 most important features are:

• node-stores_mean (importance: 0.0063)
• LLC-store_std (importance: 0.0058)
• cpu-cycles_med (importance: 0.0051)

All three features show fold change $>1$ (increasing trend) and positive Cohen’s d, consistent with the resource-enhanced disturbance pattern.

On Windows 10, the top-3 most important features are:

• cpu_core_cache-misses_std (importance: 0.0063)
• cpu_core_cache-references_std (importance: 0.0040)
• cpu_atom_branch-load-misses_std (importance: 0.0040)

All three features show fold change $<0.77$ (decreasing trend) and large negative Cohen’s d, consistent with theresource-suppressed disturbance pattern.

Figure 7 shows that the two platforms share no common features, confirming that platform-specific feature selection is essential for cross-platform ransomware detection.

3.2.3. Clustering-Based Optimization

Clustering Procedure

To remove redundant features and select the most representative ones, we applied K-means clustering using permutation importance scores and inter-feature correlations as inputs [31]. The elbow method was used to determine the optimal number of clusters [31]. As shown in Figure 8, the SSE curve for Windows 10 decreases rapidly until $K=4$ and then flattens, while for Windows 7, the SSE reaches a minimum at $K=4$ with a subsequent increase at $K=5$. Both curves indicate that $K=4$ is the appropriate choice, which aligns with our design goal of selecting four representative features per platform.

From each cluster, the feature with the highest composite score (0.6 × importance + 0.4 × abs_r) was retained.

Cluster Structure

Figure 9 shows the clustering distribution of candidate features on both platforms.

On Windows 7, the 9 candidate features formed four clusters (

Table 8. Windows 7 feature clusters.

Cluster	Features
LLC storage	node-stores_mean, LLC-store_mean, LLC-store-misses_mean
Cache	cache-misses_std, node-loads_std
CPU cycle	cpu-cycles_med
LLC storage std	node-stores_std, LLC-store-misses_std, LLC-store_std

). On Windows 10, the 14 candidate features formed four clusters (

Table 9. Windows 10 feature clusters.

Cluster	Features
Branch miss	4 branch-related features (P/E-core)
Bus/CPU cycle	6 bus-cycle and CPU-cycle features
Cache miss	cpu_core_cache-misses_std, cpu_core_cache-references_std
Cache ref	cpu_core_cache-references_max, cpu_atom_cache-references_max

).

Selected Features

Figure 10 compares the composite scores of the final selected features from each cluster.

The four selected features per platform (one from each cluster) are summarized below:

• Windows 7: node-stores_mean, cache-misses_std,
  cpu-cycles_med, node-stores_std
• Windows 10: cpu_atom_branch-load-misses_std,
  cpu_atom_cpu-cycles_max, cpu_core_cache-misses_std,
  cpu_atom_cache-references_max

The maximum correlation among selected features is 0.859 for Windows 7 and 0.903 for Windows 10, confirming that the clustering strategy successfully reduced redundancy while preserving discriminative information. No common features exist between the two platforms, reinforcing that platform-specific feature selection is essential for cross-platform ransomware detection.

3.2.4. Summary

This section completed the full pipeline of HPC feature screening, optimization, and selection for ransomware detection. The key findings are summarized as follows:

• Initial screening: 9 features retained on Windows 7, 14 on Windows 10, satisfying correlation ($\left|r\right|\ge 0.20$), discriminability (fold change $\ge 1.3$ or $\le 0.77$), and effect size (Cohen’s $d\ge 0.2$) criteria.
• Random Forest importance scoring (permutation importance): All candidate features were identified as effective, with classification accuracies of $92.8\%\pm 0.7\%$ (Win7) and $98.5\%\pm 0.6\%$ (Win10). The top-3 features are:
  - Win7: node-stores_mean, LLC-store_std, cpu-cycles_med;
  - Win10: cpu_core_cache-misses_std, cpu_core_cache-references_std, cpu_atom_branch-load-misses_std.
• Clustering optimization (K-means, K=4): Four low-redundancy, highly representative features were selected per platform, each from distinct clusters covering diverse HPC categories (LLC storage, cache, CPU cycle, branch miss, bus/CPU cycle).
• Cross-platform divergence: Windows 7 selected features show increasing trends (fold change $>1$), while Windows 10 selected features show decreasing trends (fold change $<1$). No common features exist between the two platforms, highlighting the necessity of platform-specific feature selection.

The final selected feature sets (four per platform) are well-structured, strongly discriminative, and ready for subsequent behavior stage analysis and cross-platform detection model construction.

3.3. Phase Matching and Correlation Characterization

Important note: This section focuses exclusively on correlation analysis between HPC features and ransomware behavior stages, rather than developing or evaluating a real-time detection system. The goal is to quantify how strongly each feature associates with specific attack phases (startup, key generation, encryption) and to characterize phase-specific patterns. The metrics presented below (False Alignment Rate, Stage Purity, Stage Coverage, Association Score, Alignment Accuracy) are used here as quantitative measures of feature–stage alignment strength under staged threshold calibration, not as performance claims of a deployed detector. This analysis provides the foundation for future detection model development but does not itself constitute a full detection system.

Based on the correlation and feature importance analyses above, four selected features per platform are:

• Windows 7: node-stores_mean, cache-misses_std,
  cpu-cycles_med, node-stores_std
• Windows 10: cpu_atom_branch-load-misses_std,
  cpu_atom_cpu-cycles_max, cpu_core_cache-misses_std,
  cpu_atom_cache-references_max

The 10-s execution window was divided into three phases: startup (0–2 s), key generation (2–5 s), and encryption (5–10 s).

3.3.1. Quantitative Analysis of Feature-Stage Correlation

Table 10. Feature-stage alignment strength for malicious samples (score/level).

Platform	Feature	Startup (0–2 s)	Key Gen (2–5 s)	Encryption (5–10 s)
Win7	node-stores_mean	58.26 (B)	91.45 (S)	82.24 (A)
	node-stores_std	58.26 (B)	91.45 (S)	82.24 (A)
	cache-misses_std	69.47 (B)	65.44 (B)	80.04 (A)
	cpu-cycles_med	54.61 (B)	72.98 (A)	73.58 (A)
Win10	cpu_atom_branch-load-misses_std	84.90 (A)	49.59 (C)	94.87 (S)
	cpu_atom_cpu-cycles_max	100.00 (S)	49.04 (C)	100.00 (S)
	cpu_core_cache-misses_std	89.88 (S)	76.76 (A)	100.00 (S)
	cpu_atom_cache-references_max	90.48 (S)	66.63 (B)	100.00 (S)

Note: Scores are based on the composite metric (fluctuation, peak significance, and malicious-benign difference). S: ≥85, A: 70–84, B: 50–69, C: <50.

presents the alignment strength between each selected feature and the three ransomware behavior stages for malicious samples. Scores are classified into four levels: S (≥85), A (70–84), B (50–69), and C (<50).

Key Observations

All eight features achieve strong alignment in the encryption phase (5–10 s), confirming that batch encryption causes the most significant hardware performance fluctuations. Key observations include:

• Windows 7 (resource-enhanced disturbance):

  -

  node-stores_mean and node-stores_std reach S-level (91.45) in the key generation phase (2–5 s), indicating that storage-related HPC events peak during cryptographic operations.

  -

  Other features show A/B levels, suggesting moderate but consistent separation.

• Windows 10 (resource-suppressed disturbance):

  -

  Three features achieve S-level in the startup phase (0–2 s):

  cpu_atom_cpu-cycles_max (100.00), cpu_core_cache-misses_std (89.88), and cpu_atom_cache-references_max (90.48). This enables ultra-early detection (within the first 2 s).

  -

  All four features reach S-level in the encryption phase (5–10 s),

  with cpu_atom_cpu-cycles_max and cpu_core_cache-misses_std achieving perfect scores (100.00).

  -

  The key generation phase (2–5 s) shows the weakest alignment (C/B levels), suggesting this phase is the most challenging for HPC-based differentiation on Windows 10.

Summary

The phase-level analysis confirms that the encryption phase consistently provides the strongest HPC signals on both platforms. For Windows 10, the startup phase also offers S-level alignment for CPU cycle, cache miss, and cache reference features, supporting the feasibility of ultra-early detection. The key generation phase remains the most challenging due to lower feature discriminability, particularly on Windows 10. These findings inform the design of phase-aware, platform-specific detection strategies.

3.3.2. Stage-Specific Threshold Calculation

To enable quantitative correlation assessment, stage-specific thresholds were calculated for each selected feature based on benign sample distributions. These thresholds are used solely for phase alignment analysis, not as decision boundaries for a real-time detector.

The threshold design follows the percentile-based method (non-parametric, robust to distribution shape):

• Startup phase (0–2 s): Lower bound: 0.5× median; Upper bound: 97.5th percentile
• Key generation phase (2–5 s): Lower bound: 2.5th percentile; Upper bound: 97.5th percentile
• Encryption phase (5–10 s): Lower bound: 0.5× median; Upper bound: 97.5th percentile

The 2.5th and 97.5th percentiles correspond to the standard $\mu \pm 2\sigma$ range under normality but make no distributional assumptions, providing a non-parametric alternative robust to outliers and skewed distributions.

Robustness Analysis

To assess sensitivity to threshold selection, we perturbed each percentile bound by $\pm 20\%$ and recomputed the alignment accuracy (the proportion of malicious samples correctly assigned to each phase).

Table 11. Maximum alignment accuracy change under $\pm 20\%$ threshold perturbation.

Platform	Feature	Startup	Key Gen	Encryption
Win7	node-stores_mean	3.9%	4.9%	15.4%
	cache-misses_std	1.7%	19.4%	33.9%
	cpu-cycles_med	24.6% 1	9.5%	19.1%
	node-stores_std	2.1%	5.8%	24.6%
Win10	atom branch-load-misses_std	2.2%	1.7%	3.0%
	atom cpu-cycles_max	1.2%	2.9%	8.5%
	core cache-misses_std	5.2%	9.2%	11.1%
	atom cache-references_max	3.1%	2.4%	3.9%

¹ cpu-cycles_med exhibits higher sensitivity (24.6%) due to the narrow distribution of CPU cycle counts in the startup phase and the limited sampling points (20).

summarizes the maximum accuracy change for each feature under $\pm 20\%$ perturbation.

The results reveal two key findings:

First, the startup phase exhibits the best robustness across both platforms. For Windows 7, three out of four features show changes below 4% in the startup phase (average 8.1%), while all Windows 10 features show changes below 6%. This indicates that the startup phase is the most stable window for threshold-based detection, making it a reliable target for ultra-early ransomware detection.

Second, Windows 10 features are consistently robust across all phases (most changes $<10\%$), reflecting the stability introduced by the heterogeneous P/E-core architecture. In contrast, Windows 7 features show higher sensitivity, particularly in the encryption phase (up to 33.9%), which is attributed to the high volatility of HPC events during batch I/O operations on the legacy homogeneous platform.

Despite the higher sensitivity on Windows 7, the encryption phase consistently achieves S-level alignment for all features under the original thresholds, and the cross-platform inversion phenomenon remains unaffected. Based on the robustness analysis, we recommend prioritizing the startup phase as the primary detection window in practical deployments, as it combines early detection capability with threshold stability.

3.3.3. Phase-Wise Alignment Quantification

The ransomware lifecycle was divided into three behavior stages: startup (0–2 s), key generation (2–5 s), and encryption (5–10 s), with an additional full-sequence overall evaluation dimension. The analysis follows four key principles:

1.

Independent stage evaluation: Each stage uses its own thresholds and percentile-based criteria.

2.

Feature-level weighting: Core features are weighted according to their correlation strength with each stage (see Table 10).

3.

Stage-specific thresholds: Thresholds are calculated independently for each stage based on benign sample distributions.

4.

No unified merging: Alignment results for each stage and the full-sequence evaluation are output independently. No single threshold is applied to merge or override multi-stage decisions.

This design ensures that early-stage anomalies (e.g., startup phase) are not diluted by encryption-phase behavior, and conversely, that encryption-phase alignment is not compromised by early-stage normal fluctuations.

Table 12. Feature–stage alignment results on Windows 7.

Stage	False Alignment Rate (%)	Stage Purity (%)	Stage Coverage (%)	Association Score	Alignment Accuracy (%)
Startup (0–2 s)	1.44	97.45	33.31	49.65	57.90
Key Gen (2–5 s)	4.90	82.65	14.13	24.13	44.64
Encryption (5–10 s)	1.73	97.41	39.42	56.13	61.59
Overall (10 s)	3.75	94.74	40.87	57.11	61.74

Note: Stage Purity, Stage Coverage, Association Score, and Alignment Accuracy are used here as quantitative measures of feature–stage alignment strength under calibrated thresholds. These metrics do not represent real-time detection performance.

and 

Table 13. Feature–stage alignment results on Windows 10.

Stage	False Alignment Rate (%)	Stage Purity (%)	Stage Coverage (%)	Association Score	Alignment Accuracy (%)
Startup (0–2 s)	0.28	99.84	79.71	88.64	86.01
Key Gen (2–5 s)	0.42	99.43	33.42	50.02	54.25
Encryption (5–10 s)	2.23	97.21	35.72	52.25	55.26
Overall (10 s)	0.56	99.61	65.81	79.26	76.40

See Table 12 for metric definitions.

summarize the feature-stage alignment results.

Windows 7 Platform

The startup and encryption phases demonstrate strong feature-behavior alignment with low false alignment rates (1.44% and 1.73%) and high stage purity (>97%). The key generation phase shows weaker alignment, with a higher false alignment rate (4.90%) and lower stage coverage (14.13%), indicating this stage is more difficult to characterize due to behavioral similarities with normal computation-intensive tasks.

Windows 10 Platform

The startup phase exhibits the strongest feature–stage alignment, with an alignment accuracy of 86.01% and a false alignment rate of only 0.28% under calibrated thresholds, indicating the strong discriminative quality of the selected HPC features. The key generation phase remains the most challenging to characterize. Overall, Windows 10 demonstrates stronger feature-stage alignment than Windows 7, with overall alignment accuracy of 76.40% and stage purity of 99.61%.

Summary

The alignment analysis successfully identifies that hardware events in the startup and encryption phases have strong relationships with ransomware behavior, while the key generation phase is more difficult to characterize due to similarities with benign computation-intensive workloads. Windows 10 shows stronger overall alignment than Windows 7, indicating that modern heterogeneous hardware architectures provide more discriminative HPC features for ransomware behavior analysis.

Offline Retrospective Validation

To validate the practical utility of the calibrated thresholds and feature weights, we performed offline retrospective validation on the full dataset.

Table 14. Offline retrospective validation results.

Platform	Phase	FPR (%)	Precision (%)	Recall (%)	Accuracy (%)
Win7	Startup (0–2 s)	1.12	98.34	30.35	51.85
	Key Gen (2–5 s)	11.90	86.33	34.38	51.23
	Encryption (5–10 s)	10.36	86.83	31.24	49.56
	Ensemble (any phase)	77.03	72.72	93.85	71.62
Win10	Startup (0–2 s)	0.00	100.00	79.64	86.03
	Key Gen (2–5 s)	0.56	99.24	33.48	54.17
	Encryption (5–10 s)	2.52	96.52	31.95	52.50
	Ensemble (any phase)	47.20	82.25	100.00	85.19

summarizes the detection performance for each phase and an ensemble strategy (classifying a sample as malicious if any phase violates its threshold).

The high false positive rates (47.20% on Windows 10, 77.03% on Windows 7) are attributable to the rule-based nature of our ensemble strategy (threshold exceedance in any phase triggers an alert), rather than a limitation of HPC features themselves. Benign software may exhibit abnormal HPC patterns in isolated phases (e.g., a file compression tool triggering cache-related anomalies), leading to false positives under the simple “any phase” rule.

Practical Recommendations

Based on the validation results, we propose a two-stage detection strategy for practical deployment:

1.

Primary detection (startup phase): Use startup phase thresholds as the main trigger. On Windows 10, this achieves 86% accuracy with zero false positives, providing early warning within 2 s of execution.

2.

Secondary verification (ensemble): If the startup phase does not trigger, apply the ensemble strategy to capture delayed or stealthy ransomware variants, ensuring high recall.

• Alternatively, adopting a Random Forest classifier (Section 3.2.2) directly achieves 98.5% accuracy with near-zero false positives, making it suitable for real-world deployment.

4. Discussion

4.1. Mechanisms Underlying the Opposite Correlation Patterns

The opposite correlation patterns—resource-enhanced disturbance on Windows 7 versus resource-suppressed disturbance on Windows 10—are associated with three interacting mechanisms.

First, baseline inversion: Windows 7 starts near-idle, so ransomware activity is associated with increased HPC counts (positive correlation). In contrast, Windows 10 maintains high background activity (SysMain, telemetry, indexing); ransomware may replace these workloads and, when generating fewer HPC events per unit time, produce a net decrease (negative correlation).

Second, branch predictability disparity: Ransomware encryption loops use predictable branch patterns that hardware predictors rapidly learn, while Windows background services use unpredictable branches (indirect calls, state-dependent conditions). This is supported by two complementary observations. First, branch-related events on Windows 10 exhibit extreme fold changes (e.g., cpu_atom_branch-load-misses_std: fold change = 0.218), indicating that ransomware triggers far fewer branch misses than benign software. Second, as shown in

Table 15. Branch misprediction rates across phases and platforms.

Platform	Core	Phase	Malicious (%)	Benign (%)	Diff
Win7	—	Startup	7.68	7.84	−0.16
		Key Gen	5.19	4.82	+0.37
		Encryption	4.32	5.43	−1.11
Win10	P-core	Startup	2.11	2.77	−0.66
		Key Gen	1.57	1.84	−0.27
		Encryption	2.26	3.21	−0.94
Win10	E-core	Startup	3.02	3.98	−0.96
		Key Gen	1.92	2.54	−0.61
		Encryption	2.59	4.25	−1.66

, the branch misprediction rate of ransomware is consistently lower than that of benign samples across all phases, with the largest difference observed on Windows 10 E-core during encryption (−1.66%). Together, these results confirm that ransomware’s branch behavior is indeed more predictable than the irregular branches of background services.

Third, heterogeneous amplification: the branch predictability advantage holds on both P-cores and E-cores (12 vs. 6 strongly correlated events in our analysis), with E-cores showing slightly stronger correlations ($\left|r\right|$ up to 0.84 vs. 0.82 for P-cores), likely due to their simpler branch predictors.

In summary, resource-suppressed disturbance emerges from a combination of a high-background baseline, ransomware’s predictable branch patterns, and hardware predictors that amplify the contrast between predictable and unpredictable workloads.

4.2. Platform-Specific Divergence and Feature Selection

The correlation and fold change analyses reveal a fundamental divergence between homogeneous and heterogeneous platforms. Windows 7 exhibits no strong Pearson correlations ($\left|r\right|\ge 0.6$); however, Cohen’s d analysis shows that 35% of its features have large effect sizes ($\left|d\right|\ge 0.8$), indicating meaningful separation. Windows 10 shows substantially stronger separation, with 118 features (70.2%) exhibiting large Cohen’s d, predominantly negative. Windows 10 also exhibits higher feature redundancy (average inter-feature correlation 0.546 vs. 0.470 on Win7). Notably, branch-load-misses is the only event common to both platforms’ high-difference sets, yet exhibits opposite trends (increasing on Windows 7, decreasing on Windows 10). This architectural dependency mandates platform-specific feature selection.

Using permutation importance (to avoid bias toward high-cardinality features) and K-means clustering ($K=4$), we selected four core features per platform. Windows 7 core features (e.g., node-stores_mean, cache-misses_std) all show increasing trends (fold change $>1$), consistent with resource-enhanced disturbance. Windows 10 core features (e.g., cpu_atom_branch-load-misses_std, cpu_core_cache-misses_std) all show decreasing trends (fold change $<0.77$), consistent with resource-suppressed disturbance. The complete absence of overlapping core features confirms that cross-platform HPC analysis cannot rely on feature transfer.

4.3. Stage-Wise and Cross-Platform Implications

All eight selected features achieve S-level alignment (score $\ge 85$) in the encryption phase (5–10 s), confirming that bulk encryption induces the strongest hardware perturbations. On Windows 10, three out of four core features reach S-level as early as the startup phase (0–2 s), with cpu_atom_cpu-cycles_max achieving a perfect score of 100. This is consistent with recent findings that efficiency cores exhibit more stable performance patterns [32], highlighting that heterogeneous architectures enable ultra-early detection within the first 2 s. The remaining feature, cpu_atom_branch-load-misses_std, achieves A-level (84.90), still indicating strong early-stage alignment. The key generation phase, however, consistently shows the weakest alignment (C/B levels), likely due to behavioral overlap with benign computation-intensive tasks.

Robustness analysis (perturbing percentile bounds by $\pm 20\%$) confirms that the startup phase is the most stable detection window across both platforms (average change 8.1% on Win7, <6% on Win10). In contrast, the encryption phase shows higher sensitivity on Windows 7 (up to 33.9%), attributed to the high volatility of HPC events during batch I/O operations on the legacy homogeneous platform.

The high false positive rates of the rule-based ensemble strategy (47.20% on Win10, 77.03% on Win7) are attributable to the simple threshold-based decision rule (any phase violation triggers an alert), rather than a limitation of HPC features themselves. Benign software may exhibit abnormal HPC patterns in isolated phases, leading to false positives under this conservative rule.

4.4. Limitations and Future Directions

This study has several limitations. It focuses exclusively on Windows 7 and Windows 10 on Intel x86 architectures (Kaby Lake and Meteor Lake); findings may not generalize to other OS versions or ARM/AMD platforms. Given that only two specific platforms were compared, the observed platform-dependent behavior should be interpreted cautiously when extending to other hardware or software environments. The analysis is limited to the first 10 s post-execution and identifies correlations, not causality. The empirically determined percentile-based thresholds may require recalibration for other platforms. The rule-based detection strategy exhibits high false positives, though machine learning models using the same HPC features achieve near-zero false positives (98.5% accuracy on Win10), confirming that this limitation is methodological rather than fundamental.

Future work should validate this methodology on Linux, containerized environments, and other heterogeneous architectures (AMD Zen 4c, ARM big.LITTLE). The core feature sets and thresholds identified here suggest potential for developing lightweight, real-time detection systems, which would extend beyond the correlation-focused scope of the present study, with machine learning integration as a promising direction to simultaneously achieve high recall and low false positives.

4.5. On the Stability of E-Core Measurements

While E-core measurements exhibit higher run-to-run variability than P-core measurements, this does not compromise their utility for correlation analysis. Three observations support this claim:

1.

Directional consistency: Despite variability in absolute values, the load-to-idle ratio remained positive for all E-core measurements (100% consistency), and all correlation coefficients were negative. The direction of change—the primary concern for correlation analysis—is stable.

2.

Statistical power from large samples: The main correlation analysis is based on a large dataset (1,562 ransomware and 714 benign samples on Windows 10). Random measurement noise affects both groups equally and is statistically averaged out, ensuring reliable correlation estimates.

3.

Hardware-informed interpretation: The observed variability is consistent with the energy-efficient design of Intel E-cores (Atom), which prioritize power savings over deterministic performance through aggressive power management. This variability is a feature of the hardware, not a measurement artifact.

Crucially, despite higher variability, E-core events demonstrated stronger discriminative power (12 strong correlations vs. 6 on P-core), indicating that the variability does not wash out the ransomware signal. We therefore retain E-core events in our analysis as they provide essential evidence for the inversion phenomenon.

5. Conclusions

This paper presented a comprehensive correlation analysis between Hardware Performance Counter (HPC) events and ransomware behavior on Windows 7 (homogeneous x86) and Windows 10 (heterogeneous P/E-core) platforms. Four main contributions emerge from this study.

5.1. Academic Contributions

First, we identified opposite correlation patterns across platforms. Windows 7 exhibits resource-enhanced disturbance (positive Cohen’s d, increasing trends), while Windows 10 exhibits resource-suppressed disturbance (negative Cohen’s d, decreasing trends). The proportion of large effects ($\left|d\right|\ge 0.8$) is substantially higher on Windows 10 (70.2%) than on Windows 7 (35.0%), indicating that heterogeneous architectures amplify HPC response. This inversion—previously unreported in HPC security research—demonstrates that platform architecture fundamentally alters ransomware’s HPC fingerprint.

Second, we established a reproducible feature selection pipeline. Using permutation importance (unbiased toward high-cardinality features) and K-means clustering ($K=4$ determined by the elbow method), we identified platform-specific core feature sets. The pipeline is transferable to other platforms and malware families, and all code is made available for reproducibility.

Third, we quantified stage-wise correlation patterns. The encryption phase (5–10 s) achieves S-level alignment for all eight selected features, confirming that bulk encryption induces the strongest hardware perturbations. On Windows 10, three features reach S-level as early as the startup phase (0–2 s), with cpu_atom_cpu-cycles_max achieving a perfect score of 100, demonstrating ultra-early detection potential. The key generation phase (2–5 s) shows significantly weaker alignment (C/B levels), likely due to behavioral overlap with benign computation-intensive tasks.

Fourth, we demonstrated that no cross-platform universally stable features exist. Windows 7 core features (e.g., node-stores_mean, cache-misses_std) show increasing trends (fold change $>1$), focused on LLC cache and node events. Windows 10 core features (e.g., cpu_atom_branch-load-misses_std, cpu_core_cache-misses_std) show decreasing trends (fold change $<0.77$), focused on L1 cache, TLB, and branch misses. This architectural dependency mandates platform-specific feature selection for any HPC-based cross-platform analysis.

5.2. Practical Recommendations

Based on these findings:

• Windows 7: Prioritize low-redundancy features from the dTLB address translation category, which exhibits the best independence (average inter-feature correlation 0.394).
• Windows 10: Apply aggressive feature selection and dimensionality reduction to highly redundant categories such as cache (average inter-feature correlation 0.579) and dTLB (0.463), focusing on median-based features with decreasing trends.

The common screening logic—prioritizing cache events while excluding memory node events—can be reused across both platforms to balance detection accuracy and efficiency.

5.3. Limitations and Future Directions

This study has several limitations. It focuses on Windows 7 and Windows 10 on Intel x86 architectures (Kaby Lake and Meteor Lake); findings may not generalize to other OS versions or ARM/AMD platforms. The analysis is limited to the first 10 s post-execution and identifies correlations, not causality. The rule-based detection strategy exhibits high false positives (47.20% on Win10, 77.03% on Win7), though our Random Forest classifier using the same HPC features achieves 98.5% accuracy with near-zero false positives, confirming that this limitation is methodological rather than fundamental.

Future work should extend this framework to Linux systems, containerized environments, and other heterogeneous architectures (AMD Zen 4c, ARM big.LITTLE), addressing the growing need for cross-platform malware detection strategies [33]. The core feature sets and stage-specific thresholds identified here provide a foundation for developing lightweight, real-time detection systems, with machine learning integration as a promising direction to simultaneously achieve high recall and low false positives.