ObfuscatedMalMem2022 Dataset
- ObfuscatedMalMem2022 is a volatile-memory dataset featuring engineered memory features used to detect obfuscated malware through binary and multi-class classification tasks.
- The dataset supports robust evaluation of ML models with near-saturation binary accuracy and challenges in distinguishing among ransomware, spyware, and Trojan samples.
- Variations in preprocessing methods and reporting discrepancies highlight practical challenges in feature extraction and model evaluation across studies.
ObfuscatedMalMem2022 is a name used in recent malware-detection literature for the Canadian Institute for Cybersecurity memory-malware corpus commonly referred to as CIC MalMemAnalysis-2022, CIC-MalMem-2022, or CIC MalMem 2022. It is a volatile-memory, feature-engineered dataset designed to support memory-based detection of obfuscated malware, with typical benchmark tasks including binary benign-versus-malicious classification and multi-class discrimination among benign, ransomware, spyware, and Trojan samples. Across studies, it is positioned as a benchmark for evaluating how well ML models retain discrimination power when malware employs obfuscation-oriented evasion, while several papers also document important schema differences, reporting gaps, and evaluation caveats that materially affect interpretation (Nassar, 2 Feb 2026, Hasan et al., 2024, P et al., 2024).
1. Nomenclature, lineage, and intended scope
The dataset’s official naming is not uniform across the literature. One study consistently uses “CIC MalMemAnalysis-2022” and states that the alias “ObfuscatedMalMem2022” matches the same CIC work and focus, while also noting that another common shorthand is “CIC-MalMem-2022” (Nassar, 2 Feb 2026). Another paper explicitly refers to the dataset as “CIC-MalMem-2022” and also as ObfuscatedMalMem2022, and a third uses “CIC MalMem 2022” as the official name attributed to the Canadian Institute for Cybersecurity at the University of New Brunswick (Hasan et al., 2024, P et al., 2024). In practical usage, these names point to the same CIC dataset lineage centered on obfuscated malware detection through memory feature engineering.
Its provenance is traced to Carrier, Victor, Tekeoglu, and Lashkari’s ICISSP 2022 work, “Detecting Obfuscated Malware using Memory Feature Engineering,” and to CIC’s VolMemLyzer, described as the Volatility Memory Analyzer, together with an extension focused on obfuscation-oriented memory features (Nassar, 2 Feb 2026). The dataset was built specifically to support memory-based malware analysis with emphasis on obfuscated samples, and later studies repeatedly use it to simulate realistic malware-detection conditions in which signature-based and heuristic systems are challenged by evasive behavior (Nassar, 2 Feb 2026, Hasan et al., 2024, P et al., 2024).
The intended scope is consistent even where reporting details differ. The dataset is used for binary malware detection, multi-class family or subtype classification, and, in one quantum-ML study, as a stress test for models intended to learn discriminative patterns in highly obfuscated malware samples (Nassar, 2 Feb 2026, Joshi et al., 4 Sep 2025). This suggests that the corpus has come to function not merely as a dataset for supervised tabular classification, but as a benchmark substrate for contrasting modeling paradigms under an obfuscation-focused threat model.
2. Data modality and reported feature representations
The core data modality is volatile memory analysis. In the most operationally detailed description, features are engineered from memory dumps captured during live malware execution, with memory artifacts consisting of live process memory snapshots or dumps captured from outside a Windows 10 VM running under VirtualBox, using the VirtualBox virtual memory management system (Nassar, 2 Feb 2026). Memory dumps were taken every 15 seconds up to 10 times per sample, and the resulting tabular records contain counts and descriptors derived from memory forensics, including features such as svcscan.nservices and svcscan.shared_process_services (Nassar, 2 Feb 2026). The same study states that the original CIC paper describes new obfuscation-relevant memory features, including API-hook-related features, although those particular API-hook features were not present in the Kaggle CSV used in that work (Nassar, 2 Feb 2026).
Feature inventories are not reported identically across papers. One paper states that the CSV file has 57 columns and that, after removing three constant-zero features—pslist.nprocs64bit, handles.nport, and svcscan.interactive_process_services—and excluding label columns, 52 features remained for modeling (Nassar, 2 Feb 2026). Another describes the dataset in tabular form with 55 engineered features per record and two labels, while not enumerating the individual feature names or types (Hasan et al., 2024). A quantum-ML study instead reports 57 features per sample and characterizes them functionally as behavioral or memory-oriented indicators, including process creation patterns, process injection indicators, dynamic library or module loading sequences, registry access or modification patterns, file-system modifications, network communication patterns, memory allocation anomalies, handle usage patterns, and threat-level-style summary indicators (Joshi et al., 4 Sep 2025). A further study states more generally that the dataset is composed of features extracted through memory analysis of memory dump processing done in debug mode, without enumerating individual features (P et al., 2024).
| Study | Reported feature view | Reported labeling view |
|---|---|---|
| (Nassar, 2 Feb 2026) | 57 columns in CSV; 52 modeling features after removals | Binary and four-class |
| (Hasan et al., 2024) | 55 engineered features; two labels | Binary and family classification |
| (Joshi et al., 4 Sep 2025) | 57 features; behavioral/memory indicators | Binary; also mentions 25 families |
| (P et al., 2024) | Memory-derived engineered features in debug mode | Binary and four-class |
These differences are consequential. They indicate that “ObfuscatedMalMem2022” often denotes a dataset lineage rather than a single universally fixed tabular schema. A plausible implication is that benchmark comparisons across papers are affected not only by model choice, but also by which release, mirror, preprocessing path, or feature subset was used.
3. Composition, labeling, and class structure
The most frequently reported dataset size is 58,596 records or samples (Nassar, 2 Feb 2026, Hasan et al., 2024, Joshi et al., 4 Sep 2025). One study states that malware samples consisted of 2,916 binaries sourced from VirusTotal and that benign processes were executed to simulate normal user behavior (Nassar, 2 Feb 2026). In the binary setting, that study reports a balanced dataset with 29,298 benign and 29,298 malicious records, with benign over-sampling performed using SMOTE to achieve balance (Nassar, 2 Feb 2026). Another paper likewise reports a 50% benign and 50% malicious split over the 58,596 records (Hasan et al., 2024).
For multi-class use, the predominant label schema is benign, ransomware, spyware, and Trojan. One paper states that malware subtype labels were extracted from a compound metadata column consisting of category, family, ID, and sample number, and reports class counts of spyware 10,020, ransomware 9,791, Trojan 9,487, plus benign 29,298 (Nassar, 2 Feb 2026). Another reports that within the malicious half, the distribution is 32.5% Trojan Horse, 33.67% Spyware, and 33.8% Ransomware, while still treating the dataset as balanced at the benign-versus-malicious level (Hasan et al., 2024). A separate study notes that the experiments use four classes and encodes them as benign, spyware, ransomware, and trojan (P et al., 2024).
Not all label descriptions align perfectly. The quantum-ML paper explicitly confirms binary benign-versus-malicious labeling for 58,596 samples, but also states that the dataset “encompasses 25 distinct malware families,” without enumerating them (Joshi et al., 4 Sep 2025). By contrast, the memory-analysis studies emphasize three malicious families or sub-types—Spyware, Ransomware, and Trojan Horse—alongside benign (Nassar, 2 Feb 2026, Hasan et al., 2024, P et al., 2024). This discrepancy is not reconciled in the literature cited here.
Another reported inconsistency concerns sample counts. One paper gives a small-class-count description of benign 2,916, ransomware 986, spyware 982, and trojan horse 948, summing to 5,832, while elsewhere in the same paper it states that the CIC MalMem2022 dataset has 58,596 samples (P et al., 2024). The text explicitly notes this discrepancy without resolving it. For dataset users, this makes it important to distinguish between the full record-level tabular corpus and any smaller subset descriptions that may refer to binaries, families, or another aggregation level.
4. Preprocessing and evaluation protocols
The dataset is generally used as a tabular supervised-learning benchmark, but preprocessing pipelines differ across studies. In one memory-analysis workflow, an 80/20 train/test split was stratified by multi-class labels, yielding 46,876 training rows and 11,720 testing rows, with min–max scaling to fitted on the training subset and applied to train and test to prevent data leakage; 5-fold stratified cross-validation was then performed on the training data, with scaling inside a scikit-learn pipeline (Nassar, 2 Feb 2026). That study reports no feature engineering beyond removing three zero-variance features and states that preliminary feature selection or reduction slightly reduced performance; PCA to two dimensions was used only for visualization, where benign-versus-malware separation appeared strong, but malware-subtype separation was weaker (Nassar, 2 Feb 2026).
Another study applies label cleaning, feature standardization for equal treatment of features and better convergence, and label encoding when required, with an 80/20 hold-out split and explicit class-imbalance interventions for multi-class experiments (Hasan et al., 2024). The imbalance regimes are original data, undersampling the majority benign class by Edited Nearest Neighbor, Near Miss, All KNN Undersampling, or Random Undersampling, and oversampling minority classes using ADASYN, which expands the training size to 117,193 after synthetic sample generation (Hasan et al., 2024). A quantum-oriented workflow instead centers features to zero mean, scales to unit variance, applies PCA to preserve variance while reducing qubit count, removes outliers, and performs feature correlation analysis to eliminate redundancy before amplitude encoding and optional QFT-based feature extraction (Joshi et al., 4 Sep 2025). Another classical-ML study reports data cleansing, one-hot encoding, MinMax scaling, an 80/20 split, and hyperparameter selection through rigorous random searches over several hundred iterations (P et al., 2024).
The most common reported evaluation metrics are accuracy, precision, recall, and F1-score. Their definitions are given in the cited literature as
and
Some studies also report balanced accuracy, macro-averaged recall, MCC, ROC-AUC, log loss, false positive rate, and false negative rate, depending on the experimental framing (Nassar, 2 Feb 2026, Joshi et al., 4 Sep 2025).
These protocol differences matter because they alter both difficulty and comparability. Resampling, fold construction, scaling regime, and dimensionality reduction are not secondary details for this dataset; they are primary determinants of the reported benchmark landscape.
5. Benchmark performance and operational characteristics
Across the cited studies, binary malware detection on this dataset is consistently close to saturation for mainstream tabular models. In one project, XGBoost was selected for both binary and multi-class tasks and achieved binary test accuracy and F1 of 99.98%, with classification latency of about 37.3 milliseconds for 50 sequential samples and about 3.49 seconds for 10,000 binary samples, excluding memory-dump acquisition and feature extraction or scaling time (Nassar, 2 Feb 2026). The same study reports that in 5-fold cross-validation, Random Forest, LightGBM, and XGBoost all reached 99.99% average accuracy and F1, with XGBoost yielding the smallest average log loss of 0.0006 (Nassar, 2 Feb 2026).
A separate evaluation reports that Random Forest, MLP, and XGBoost all achieved 0.9999 across accuracy, precision, recall, and F1 in the binary setting, while KNN reached 0.9991 across the same metrics (Hasan et al., 2024). Another study reports binary accuracy figures of 99.56% for Logistic Regression, 99.88% for Linear SVM, 99.21% for Naïve Bayes, 99.99% for Decision Tree, and 99.982% for Random Forest (P et al., 2024). Taken together, these results indicate that benign-versus-malicious separation in the available tabular representation is extremely strong.
Multi-class classification is materially harder. One XGBoost study reports four-class test accuracy of 87.54%, F1 of 81.26%, and average F1 over the malware sub-types of 75.03%, with per-class results of ransomware recall 0.7257, precision 0.7347, F1 0.7302; spyware recall 0.8019, precision 0.7771, F1 0.7893; and Trojan recall 0.7234, precision 0.7394, F1 0.7313 (Nassar, 2 Feb 2026). The same work measures multi-class inference at about 43.2 milliseconds for 50 sequential samples and about 6.24 seconds for 10,000 multi-class samples (Nassar, 2 Feb 2026).
In another study, XGBoost again performs best for family classification. On original data without resampling, it achieves accuracy 0.8815, precision 0.8812, recall 0.8815, and F1 0.8813, with the observation that no malware was mislabeled as benign and that misclassifications were confined to malware families (Hasan et al., 2024). Under ADASYN oversampling, XGBoost reaches accuracy, precision, recall, and F1 of 0.9427, outperforming Random Forest at 0.9395 and KNN at 0.9121, while MLP lags at 0.8211 (Hasan et al., 2024). A further classical benchmark reports a four-class Random Forest accuracy of 89.07%, precision 87.63%, recall 87.62%, and F1 87.62%, exceeding the cited dilated-CNN baseline of 81.83% accuracy in that setup (P et al., 2024).
The quantum benchmark reports a different performance profile. On ObfuscatedMalMem2022, QNN achieves 95% accuracy, 97% precision, 93% recall, F1-score 95%, false positive rate 2%, and false negative rate 5%, while QSVM reaches 94% accuracy and classical Random Forest and classical neural-network baselines are reported at 90% accuracy (Joshi et al., 4 Sep 2025). The same paper presents illustrative family-level improvements for Virus, Worm, Trojan, Backdoor, and Rootkit, but does not enumerate the 25 families it claims the dataset encompasses (Joshi et al., 4 Sep 2025).
The most stable comparative conclusion across studies is therefore narrow but clear: binary detection appears nearly trivial for multiple model classes on the reported tabular forms of the dataset, whereas multi-class subtype or family discrimination remains sensitive to class imbalance, schema choice, and modeling strategy.
6. Limitations, reporting discrepancies, and research significance
Several limitations recur in the literature. The most important methodological concern is potential data leakage arising from multiple memory dumps per sample. One study notes that up to 10 memory dumps may exist per sample and warns that record-level splitting may allow records from the same sample to appear in both train and test, thereby inflating generalization metrics; it recommends grouping by sample ID so that all records from a given sample remain in a single split, while also noting that benign records lack unique IDs in the CSV, which complicates strict grouping for benign data (Nassar, 2 Feb 2026). Another operational caveat is feature parity: the Kaggle CSV used in one study appears to omit some features mentioned in the CIC paper, including API-hook features, so users are advised to verify parity against CIC’s official release and documentation (Nassar, 2 Feb 2026).
Reporting gaps are also substantial. One paper explicitly states that the dataset URL, licensing information, storage footprint, tool versions, and OS or VM specifics are not provided (Hasan et al., 2024). Another says that the exact feature names, derivations, data types, extraction tools, access links, and licensing terms are absent, and that split strategy and confusion matrices are not reported (Joshi et al., 4 Sep 2025). A third paper likewise omits OS version, architecture, memory size, VM configuration, exact feature inventory, and named toolchains such as Volatility or Rekall (P et al., 2024). These omissions constrain strict reproducibility and make cross-paper benchmarking approximate rather than definitive.
Conceptual issues also appear in the class taxonomy. One study notes that Trojan is an implementation style that can subsume ransomware or spyware, and therefore future multi-class taxonomies might prefer mutually exclusive goals or family labels to avoid conceptual overlap (Nassar, 2 Feb 2026). Another limitation is that generalization to unseen malware families or unseen obfuscation variants is not evaluated in the cited family-classification work (Hasan et al., 2024, Joshi et al., 4 Sep 2025). Where the dataset is used to support strong detection claims, end-to-end deployment realism is further limited by the fact that reported latency often excludes memory-dump capture and feature extraction or normalization (Nassar, 2 Feb 2026).
Despite these caveats, the dataset occupies a distinct position in malware-detection research. It is described as filling a gap in memory-based detection for obfuscated malware and as complementing more common static and dynamic datasets such as EMBER, the Microsoft Malware Classification Challenge, AAGM, and image-rendered memory datasets such as Dumpware10 (Nassar, 2 Feb 2026). The significance of ObfuscatedMalMem2022 therefore lies less in any single headline accuracy figure than in its role as a shared benchmark for studying how engineered memory features interact with obfuscation, class imbalance, model complexity, and inference-speed constraints. In that sense, it has become a focal dataset for evaluating whether malware-detection systems can preserve practical efficacy when code-centric signals are intentionally degraded by evasive transformation.
