Artificial Intelligence for Malware Detection and Analysis: A Comprehensive Review of Static, Dynamic, Hybrid, and Deep Learning Approaches

Modern malware is not usually comprised of only one executable with a fixed signature. It is typically used in multi-stage attacks through social engineering, exploitation of vulnerabilities, code that resides in memory, credential theft, lateral movement, and remote command execution. The same campaign can manifest itself in different ways across endpoints, mobile devices, cloud workloads, and Internet of Things (IoT) systems. The operational diversity has made it harder to come up with a fixed pattern of bytes or hashes that can detect malicious software in a detector. Recently, however, the way malware is detected has been transformed and is now considered a problem of integrating evidence from various aspects of file structure, program semantics, runtime behavior, network activity, and threat intelligence [1-4].

Signature matching remains valuable because it is fast, reliable for previously encountered samples, and inexpensive to scale. The problem with it is not that signatures are past their usefulness but that they are retrospective: a signature is best when analysts are able to isolate a stable indicator. But polymorphism, metamorphism, packing, encryption, process injection, and living-off-the-land execution intentionally disrupt that stability. In response, static-analysis research endeavors have sought to obtain more comprehensive representations of a sample, such as Portable Executable (PE) metadata, imported functions, strings and byte n-grams, opcodes, entropy, Control-Flow Graphs (CFGs), and visual encodings, without executing the sample [5-8]. While they are safe and scalable representations, many of these representations can be altered without changing the behavior of the program, thus leaving a permanent semantic gap between predictive correlation and malicious semantics.

Dynamic analysis is supposed to fill this gap by running a program in an artificial environment. The activities hidden in packed executables could be revealed from API calls, files and registry changes, process communications, memory activities, and networking. Nevertheless, the information obtained through dynamic analysis is dependent on the environment, runtime, user interaction, networking, and payload execution. Malicious programs designed to detect sandboxing would run differently, and a valid installer can create lots of activities in the operating system. Therefore, dynamic traces cannot be treated as ground truth but as part of an experiment outcome [3, 9-11].

Detection and classification are two different problems. A detection model detects whether a given sample is malware or not. In a classification model, one can use different classes such as family, campaign, behavior, or capability. While these classes are useful for response activities, they are much more unstable due to disagreement on family names by vendors and reuse of code by malware families. Hence, a good performance of a model on known families does not reveal much about its performance on unknown families [11-13].

Artificial Intelligence (AI) has changed how one interprets static and dynamic information. Well-constructed features still allow traditional approaches such as Random Forest (RF), Support Vector Machines (SVMs), gradient boosting, and logistic regression to be competitive, while deep learning (DL) models can work on byte-level features, images, event sequences, or graphs. Different architectures are focused on different properties of the data. For example, convolutional models catch local patterns, recurrent models retain the event order, transformers catch long-range dependencies, and Graph Neural Networks (GNNs) catch connections between program components [14-17]. This flexibility reduces manual feature design, but it can also encourage shortcut learning from compiler traces, packer signatures, collection periods, or duplicated families rather than from malicious behavior itself.

This is important since malware detection is a case of adversarial classification where the adversary can inject unused bytes, change the headers, introduce benign-looking calls, change the order of independent instructions, or even change the graph structure without changing the functionality. A detector that shows very good results on random-split evaluation can still be easily bypassed under temporal drift, family-disjoint testing, different sandbox conditions, or adaptive evasion [18-21]. In that way, this approach eliminates the use of hand-crafted features and increases the likelihood of the use of shortcuts, such as compiler traces, packers used, collection period, or family duplication instead of actual malice.

The evaluation design is actually part of the security claim, not an implementation detail. Malware datasets can differ in sources, labeling schemes, thresholds of antiviral consensus, duplication elimination, and time span. Thus, any improvement can be due to better model performance but can also come from easier labels, family duplication, an unrepresentative set of benign samples, or some preprocessing issues. In order to perform a valid comparison, one needs to disclose the origin of the dataset, apply chronological or family-disjoint tests when needed, employ external validation, per-class reporting, and feature collection costs [9, 12, 13, 22].

Review papers cover static, dynamic, hybrid, and AI-based malware analysis, whereas recent research pays attention to Windows PE benchmark bias, learned representations, cross-platform applicability, interpretability, and evasion strategies based on adversarial learning [3, 4, 23, 24]. The evidence accumulated as a result is very valuable but disjointed in terms of file formats, platforms, analysis techniques, and evaluation criteria used. A classifier that performs well on a Windows PE benchmark is likely to fail when it comes to detecting Android packages, analyzing sandbox traces, and identifying malware images. Thus, data provenance, feature extraction, model choice, and experimental setup ought to be considered as inseparable parts of the scientific claim made [9-12].

This review defines malware detection as an end-to-end evidence problem rather than the competition between individual classifiers. Therefore, the topics covered include malware basics, static, dynamic, and hybrid analyses, classical and deep learning methods, public benchmarks, evaluation techniques, comparative evidence, and future perspectives of research. The evidence obtained using each method is analyzed in terms of possible manipulations and omissions and the influence of the experimental setup on the validity of the claim made. Recent work on federated learning [25], continual adaptation [26], explainable graph models [27], multimodal fusion [28], and LLM-assisted analysis [29] is considered in the same operational context.

Section 2 reviews the literature and uses it to frame the gaps addressed by this paper. Section 3 then describes static, dynamic, and hybrid malware-analysis approaches. Section 4 turns to AI models, from conventional ML to deep, graph, and multimodal architectures. Datasets and evaluation practice are covered in Section 5, followed by cross-study comparison in Section 6, research priorities in Section 7, and the conclusion in Section 8.

1.1 Review scope and selection of representative studies

This paper is a critical narrative review, not a systematic or bibliometric study. The literature considered spans foundational malware-analysis work from the early 2000s through 2026, with greater weight on 2019-2026 research because it reflects current benchmarks, deep models, adversarial testing, explainability, adaptive learning, and foundation-model use. General framing is drawn from recent surveys [3, 4, 23, 24], benchmark design from widely used datasets and evaluation papers [9-12], and emerging adaptation and language-model work from representative recent studies [25, 26, 29]. Sources include peer-reviewed journals, major security and machine-learning conferences, benchmark and dataset papers, and a small number of preprints when they introduce data or methods not yet well represented in archival publications.

These studies have been selected so as to include coverage of static, dynamic, and hybrid evidence, as well as various modeling paradigms, such as classical machine learning (ML), Convolutional Neural Network (CNN)/Recurrent Neural Network (RNN)/Transformer models, GNNs, and multimodal evidence. Preference was given to papers providing adequate methodology for evaluation of the experiments conducted, papers presenting reusable datasets, as well as papers emphasizing the constraints for application of their approaches instead of accuracy only. Studies concerning Android and IoT have also been included for comparison of their findings with those from the Windows PE domain. Comparison was not made between findings obtained under different tasks, platforms, labeling schemes, or data splitting policies.

3.1 Malware fundamentals

3.1.1 Taxonomy and operational objectives

Classification schemes for malware are helpful in describing common goals, although modern specimens often combine features from different classes. A banking Trojan, for example, might include a rootkit, steal credentials, form a botnet, and then use ransomware. Using a single classification for the specimen is not sufficient, as it hides the complexity of the process. In detection studies, behavior-based classifications such as persistence, credential access, discovery, command-and-control, and impact are often a more robust target than specific families of vendors [1, 11, 73]. Table 3 describes common classes, typical evidence that they leave, and complexity of detection due to the behavior [1, 3, 4, 73].

Table 3. Major malware categories and detection implications

Family labels are to be considered noisy metadata, not the ground truth. Various vendors may assign different labels to one and the same lineage, merge different variants into one lineage, or change labels based on information about the campaign that emerges with time. These labeling noises need to be taken into account by the models of supervised learning, as they can cause classifier mistakes even if two samples share similar behavior. Research on malware families should address questions like aliasing, confidence threshold, and outliers, instead of assuming there is only one possible way of interpreting a family name [9-12].

Additionally, the notion of "sample" is itself unclear. Depending on the research, it can refer to a file hash, an unpacked payload, a module residing in memory, an Android package, a script, and the whole campaign. Equating those units can lead to mislabeling and wrong splitting into training and testing sets: several different droppers can drop the same payload, and a modular sample may change its behavior after obtaining other modules. Thus, studies should define clearly what they mean by file identity, lineage, behavior, and campaign, and specify what their task involves – binary detection, family classification, capabilities recognition, or campaign clustering [11, 13, 45].

3.1.2 Attack lifecycle and evidence generation

A typical malware attack will involve stages like delivery, exploitation, execution, persistence, privilege escalation, command and control, objective achievement, and adaptation. However, in practice, these attacks do not normally occur in a strictly sequential manner; a particular sample might backtrack to the discovery stage, gain another component, or just wait for an external signal before it begins its operation. Different artifacts are obtained through each phase, which are useful for detection purposes: static analysis for delivery, host-based detection for execution and persistence, network-based detection for command and control, and so on. Therefore, it is improbable for one detector alone to detect the whole attack. [3, 46, 73].

The importance of lifecycle reasoning is that it allows us to correlate each detection technique with the stage at which its evidence is generated. A pre-execution scanner can prevent a malicious file from doing any damage, but it cannot detect any credentials that have been acquired by an in-memory component. Conversely, a network detector can detect command-and-control activity only after execution has begun. Effective defense thus requires layering and evidence correlation, as we cannot assume that a single classifier is capable of seeing all of the stages. Figure 2 shows how the above operational process fits into the history of malware research, where increasing attention has been paid to adaptive and multi-stage attacks [1, 3, 73].

image004.png

Figure 2. Evolution of malware topics from conventional threats to advanced and adversarial techniques

3.1.3 Evasion as a property of the detection problem

Evasion changes either the available evidence or the model’s interpretation of that evidence. Packing and encryption hide bytes from static inspection; anti- Virtual Machine (VM) checks reduce the behavior visible in a sandbox; process injection changes attribution; and adversarial edits target features learned by a classifier. The same technique can affect several stages. A packer may obscure static strings, delay unpacking, and expose only a benign stub during a short execution window. Robust systems therefore need evidence diversity and explicit tests against functionality-preserving transformations [4, 5, 18, 19].

A useful way to compare evasion is by the cost imposed on the attacker. Cosmetic metadata edits are inexpensive and can defeat brittle static features; repacking and code virtualization demand more effort but still preserve the malicious objective; environment-aware behavior requires the attacker to reason about execution context. Features that remain stable only under low-cost edits should not be treated as strong evidence.

Figure 3 links the analysis mode to the evidence a detector can observe. That relationship should also guide robustness testing: a transformation is useful only if it is feasible under the stated threat model, not simply because it resembles a perturbation used in image classification [4, 18, 37, 65]. Table 4 takes the same view by matching evasion mechanisms to the evidence they disrupt and to practical countermeasures [4, 5, 37, 48].

image005.png

Table 4. Malware evasion techniques and defensive implications

Note: ML: Machine Learning; DL: Deep Learning; CFG: Control-Flow Graph; VM: Virtual Machine.

3.2 Static malware analysis

Static analysis refers to the analysis of a file before execution. This analysis method is operationally favorable in the sense that hashes, headers, imports, strings, entropy, and some pieces of the code can be extracted quickly and reliably. The problem is that most of the static characteristics relate to how a file looks and are susceptible to modification by packing, modifying compilers, changing sections, and similar operations without modifying the behavior of the program [5, 12, 14, 30].

3.2.1 PE metadata, imports, strings, and entropy

Metadata for PE provides a brief summary of a binary on Windows, listing sections, their layout, the entry point, subsystem, imports, resources, their sizes, timestamps, and permissions. Initial work has shown that this metadata could be used to recognize new executables [30], while EMBER [12] expanded the representation by adding histograms of bytes, statistics on sections, imports, exports, and information about the file as such. The resulting combination of numerical, count, and categorical data becomes very suitable for use in tree-based models.

At the same time, convenience implies vulnerability. Many fields of metadata may be changed without impacting the operation of the program: fake timestamps, normalized names for sections, unused imports, imitation of normal values. While these features are useful, they are not supposed to be taken as reliable evidence.

Thus, the provenance of the features is as important as the features themselves. Multiple different feature vectors can be produced from the same binary depending on the version of the parser used, malformed headers, packed sections, or truncated vocabulary. A static analysis should be reproducible and list the parser and its version and report the number of extraction errors where possible. Otherwise, some part of the model may reflect the assumptions of a specific parser instead of malware features generalized over the contexts. This problem is similar to the first attempts of formal specification of malicious behavior [78].

Static parsers can also recover Uniform Resource Locators (URLs), registry keys, command strings, cryptographic calls, process-manipulation APIs, and anti-analysis indicators. Such artifacts are cheap to inspect and often meaningful to analysts, but they are easy to hide through encryption, runtime loading, or small loader stubs. Entropy may suggest packing or encryption, yet legitimate installers and multimedia files can also have high entropy. No single artifact should therefore carry much evidential weight; the strongest static claims combine several independent signals and document how unresolved or missing features were treated [2, 12, 14, 32, 78].

The static features can be sorted by the cost of manipulating them. File hashes and exact byte signatures are highly discriminative but may be fragile; header fields and imports are inexpensive to edit but carry less semantic meaning; opcode and graph representations are more semantic but require reliable disassembly; and data-flow properties are difficult to modify without affecting functionality, yet they are typically much more costly to recover. This hierarchy indicates a realistic approach to designing inexpensive, editable indicators for quick triage and more expensive semantic analysis for more ambiguous or critical files. Figure 4 summarizes the range of extraction techniques commonly used to implement this progression [5, 30, 31, 78].

image006.png

3.2.2 Byte, opcode, and graph representations

Byte n-grams capture local patterns and do not disassemble, but they have a rapidly expanding vocabulary that can be affected by compiler and packer artifacts [31]. Opcode sequences eliminate some of the operand jargon and get closer to the semantics of the instruction, but disassembly is hard in packed, obfuscated, or self-modifying binaries. Control-flow and call graphs capture the relationships between blocks and functions and are appealing to GNNs [16, 33-36]. Cost is pushed upstream: an incorrect graph can lead to a sophisticated model reasoning over an incorrect program representation with confidence.

There is a second source of uncertainty, which is often masked in final accuracy numbers, that occurs when constructing graphs. It is possible to have incomplete or incorrect graphs because of indirect calls, exception-driven control flow, stripped symbols, overlapping instructions, and self-modifying code. Canonicalization can eliminate some differences on the surface, but it can also eliminate some rare behavior that differentiates a malicious branch. The results of graph-based studies should therefore include an indication of which nodes were successfully disassembled, the distribution of the size of the graph, any isolated nodes, any edges that were not resolved, and the impact of failures in the extraction. If the issue is not accounted for, an apparent gain from a GNN could be a consequence of a cleaner subset of samples, instead of improved reasoning about program structure [16, 33-35].

3.2.3 Raw-byte and image-based learning

Raw-byte learning and malware images reduce handcrafted feature design. MalConv [8] processes byte embeddings directly, while image approaches reshape bytes or derived statistics into two-dimensional patterns [6, 7, 14]. Image conversion is efficient and benefits from mature CNN architectures, but spatial adjacency in an image is imposed by the encoding rather than by program execution. A model may detect family-specific texture, padding, or packer style rather than malicious behavior. External validation on temporally separated and differently packed samples is therefore more informative than additional accuracy on the same image benchmark.

image007.png

Table 5. Comparison of static feature representations

Note: PE: Portable Executable; GNN: Graph Neural Network; CFG: Control-Flow Graph; API: Application Programming Interface; URL: Uniform Resource Locator.

Table 6. Representative static-analysis studies

Note: PE: Portable Executable; GNN: Graph Neural Network; URL: Uniform Resource; DNN: Deep Neural Network.

The most informative validation for raw-byte and image models is not another random split of the same corpus. It is performance under a changed packer, compiler, collection period, or benign-software source. Packer-stratified tests can reveal whether the model recognizes malicious content or merely a protection tool; salting and section-injection tests expose sensitivity to non-executed regions; and family-disjoint evaluation measures whether the learned representation extends beyond near-duplicate variants. Many visual pipelines convert the binary to an image, as shown in Figure 5, and it is important to remember that the geometry obtained is one of modeling and not a native property of program execution [6-8, 12].

Tables 5 and 6 are different in that Table 5 compares the features of the major static representations, while Table 6 indicates how these representations were applied in selected studies and where the major methodological limitations [5, 12, 14, 79].

Static analysis is most convincing as a quick first-pass filter. It is not very suitable for triage or risk scoring, and it can't define full behavior on its own. Evaluation must then encompass various packers and friendly vendors, timeouts, and edits that preserve functionality. Dynamic/hybrid analysis is the next step up from a static analysis when a sample is still uncertain or high impact, rather than making a confident static label.

Combined, Tables 5 and 6 illustrate why static features are still of operational value while also requiring clear extraction, time-aware testing, and protection from realistic representation changes [5, 12, 14, 79].

3.3 Dynamic malware analysis

Dynamic analysis observes a sample while it runs in an instrumented environment. The trace may include API calls, spawned processes, file and registry changes, memory activity, persistence actions, Domain Name System (DNS) traffic, sockets, and downloaded content. These observations are behaviorally richer than file metadata, but they are not complete: operating-system version, privileges, user activity, network access, execution duration, and sandbox artifacts all influence what appears in the trace [3, 15, 43, 44].

3.3.1 Sandboxing and behavioral telemetry

CWSandbox [43], Ether [44], and later open platforms such as Cuckoo illustrate different trade-offs between observability and transparency. Virtualized sandboxes are scalable and resettable, but they can be fingerprinted. Bare-metal analysis reduces some virtualization artifacts, yet it is more expensive to orchestrate and restore. No environment is perfectly transparent. A practical design uses multiple runs, varied stimuli, and explicit reporting of non-executing samples rather than silently discarding them.

Behavioral coverage is not assumed and should be quantified. Some useful metrics are the percentage of samples that successfully start; the number of unique processes and actions seen; the percentage of samples with network activity and the percentage with persistence; and the difference between evidence seen in multiple runs. This sort of reporting differentiates a model that learns from rich behavior from one that is judged based on empty, truncated, or environment-specific reporting. It also brings the latency–coverage trade-off to the practitioners. Previous automated behavior-clustering studies also demonstrated that dynamic labels and clusters are only as valid as the actions that are triggered by the execution environment [45]. Figure 6 shows the amount of information contained in real Cuckoo reports and how this information can be lost when a report is limited to API names [42].

Repeated execution is particularly critical for nondeterministic or trigger-dependent malware. The different actions of users, the local environment, the age of the system, the content of the documents, the permissions granted to the users, and the response of the network can reveal branches that were not identified in a single run. The traces that result should not just be strung together without provenance; analysts should be able to determine which behavior was consistently present and which was dependent upon a specific stimulus. A detailed look at the variety and depth of full sandbox reports. Figure 6 provides a concrete view of the richness and heterogeneity of full sandbox reports, illustrating why dynamic analysis is an experimental measurement process rather than a deterministic file parser [3, 4, 42].

image008.png

3.3.2 Application Programming Interface sequences, semantics, and behavioral graphs

Popular options are API calls, which are easy to extract and naturally map to sequence models. Frequency vectors are brief, without order. RNNs and GRUs maintain order but may have difficulty with extremely long traces. CNNs are used to capture local motifs and attention; Transformers are used to capture wider dependencies, and behavioral graphs represent causal or temporal relations. The representation should also preserve arguments and context, if possible. CreateFile and WriteFile are not in themselves negative things; meaning is given by the path, calling, process ancestry, timing, and subsequent network behavior. A related lesson from Android is that it has seen some success with API-level features and Markov abstractions, but the transfer will rely on the evolution of the platform, the choice of abstraction, and the stability of the platform vocabulary [55, 56]. Figure 7 shows one open-access architecture that attempts to preserve both sequence order and semantic information rather than treating calls as isolated tokens [41].

Mal-ASSF [41] shows semantic enrichment by associating the type of action and the resource in the name of an API. Ilić et al. [42] demonstrate the incompleteness of API-only pipelines: in their context, complete sandbox reports better performance than call sequences. The important takeaway is not that one thing always prevails, but that behavior is multi-channel. A detector should be able to maintain provenance for an analyst to determine if evidence is from a parent process, injected thread, child process, or network component.

The order of the events is also insufficient if they are coming from multiple processes or threads. Even if both invoke similar APIs, the process ancestry, call arguments, return values, object identifiers, and time gaps help distinguish a benign installer from a malicious injector. These relations can be represented by behavioral graphs and event-correlation models, but these require more storage and more preprocessing and are sensitive to instrumentation. Figure 7 illustrates the use of both sequence and semantic evidence; its overall message is that no API name is very informative when taken alone, but when considered together with its operation type, target resource, and surrounding context, it becomes more informative [15, 38-40].

No sequence model can infer an action that never appears in the trace. Dynamic studies should therefore report how many samples executed successfully, how long they ran, what stimulation was used, which environmental fingerprints were present, and how many traces were empty or incomplete. Cross-sandbox testing is especially useful because the instrumentation itself may become an unintended label. Tables 7 and 8 summarize these evidence sources and representative dynamic studies [3, 42, 43, 45].

image009.png

Table 7. Dynamic evidence sources and limitations

Note: API: Application Programming Interface;  JSON: JavaScript Object Notation.

Table 8. Representative dynamic-analysis studies

Note: RNN: Recurrent Neural Network; CNN: Convolutional Neural Network; API: Application Programming Interface; ML: Machine Learning; RF: Random Forest.

3.4 Hybrid malware analysis

Hybrid analysis combines what can be learned before execution with what becomes visible at runtime. Static evidence is inexpensive and complete for the file that is present; dynamic evidence is richer semantically but incomplete and costly to collect. Fusion may occur at the feature, representation, score, or decision level. The practical advantage comes from preserving which modality produced each piece of evidence and from handling missing or conflicting views explicitly [28, 46, 47, 49].

3.4.1 Fusion strategies and operational cost

Early fusion concatenates static and dynamic features before classification. Although straightforward, dimensional imbalance and redundancy can cause one modality to dominate the decision. Intermediate fusion: Learn the encoders separately and fuse the latent representations. This aids modality-specific processing, and failure to attribute is more difficult. Late fusion is the combination of calibrated scores or decisions, and it is simpler to audit, but it might fail to capture cross-modal interactions. A cascaded design (static triage plus dynamic escalation) can provide the optimal operational balance since only those files that are in limbo or high risk are subjected to sandbox cost. As a concrete example of score- and similarity-based hybridization, the static and dynamic API evidence can be combined without assuming that the two views are the same [49].

Failure cases should be incorporated into hybrid evaluation, which can otherwise obscure them. A sample may have a valid static view but no dynamic trace, or these may be quite different and produce sharply conflicting scores. The system should indicate whether it imputes the missing view, abstains from making a decision, or escalates the sample, along with an explanation of how each policy affects latency and the rate of false positives. This approach is more informative than assessing only samples for which all of the analysis components were successful. This evaluation should account for modality ablation, deliberate corruption of the views, and calibration experiments to prevent an apparent gain due to one predominant branch or due to accidental matchings between correlated features [28, 46-49].

Disagreement between static and dynamic views can itself be informative. An imported networking function that never executes may indicate an unused branch, sandbox evasion, or insufficient stimulation. A function observed at runtime but absent from the import table may instead point to late binding or obfuscation. HAPI-MDM (Figure 8) illustrates this relational use of static and dynamic API evidence. Future fusion methods should report whether cross-view consistency improves robustness or merely adds correlated features [46, 48, 49].

Table 9 places static, dynamic, and hybrid analysis side by side, focusing on how each strategy acquires evidence, where it is strongest, and what limits its use in practice.

For hybrid systems, acquisition policy matters as much as classifier accuracy. Running every file in a sandbox may improve coverage but is difficult to scale; a calibrated cascade can reserve expensive analysis for uncertain or high-impact samples. Escalation rate, mean and tail latency, and risk reduction per unit of compute are therefore more informative than a single fused accuracy score. These systems should be judged with latency, coverage, and calibration in addition to predictive performance [28, 46, 49, 50].

image010.png

Table 9. Static, dynamic, and hybrid analysis strategies

Hybrid performance is meaningful only when the full collection cost is reported. Useful reporting includes sandbox throughput, failed executions, feature-storage overhead, behavior under missing modalities, and latency at each stage. A small accuracy gain is hard to justify if it multiplies analysis time, whereas a calibrated cascade may reduce cost without sacrificing risk control. Table 9 therefore compares early, intermediate, late, and cascaded fusion not only by analytical strength but also by deployment burden [28, 46, 47, 49].

5.1 Public malware datasets

Dataset choice often determines the apparent difficulty of a malware problem. Family-classification corpora, binary detection corpora, Android application sets, dynamic traces, and image datasets support different claims. A model evaluated only on malware families cannot establish benign-versus-malicious detection. A dataset collected in one period cannot establish future robustness. Public datasets improve reproducibility, but many contain label noise, family imbalance, duplicates, missing timestamps, or features extracted by an obsolete toolchain [9, 12, 42, 96].

Public benchmark development has also expanded from competition-oriented datasets such as the Microsoft Malware Classification Challenge (BIG 2015) [97] to substantially larger resources such as MalNet [98], which provides image- and graph-based representations at scale. Benign examples deserve the same curation discipline as malware. If the benign set comes from one operating-system installation or one software repository, a classifier may separate vendors, signers, or build practices instead of malicious behavior. Antivirus-consensus labels introduce another issue: the results of scans may vary when it comes to borderline cases. It is important for benchmark designers to acknowledge this level of ambiguity, avoid rejecting tricky cases once the results are out, and indicate whether the labels were fixed at the point of collection or later revised. In terms of Android, several issues include the era of Drebin, consensus labels used by AndroZoo, and changes made to the platform that affect DroidAPIMiner and MaMaDroid [54-56, 99].

It is necessary to describe the lineage of datasets in question at the file and campaign levels. Hash deduplication filters out exact duplicates but does not eliminate recompiled or slightly altered samples; thus, family leakage can still happen. The mitigation measures include similarity-based deduplication, timestamp data, signer info, and lineage-aware grouping. Provenance of the labels is also essential: manual labelling, labelling by campaigns, and antivirus consensus make different scientific claims. Noisy binary labels are sufficient for preliminary analysis but not enough for detailed family classification [11-13, 22].

Table 12. Frequently used public malware datasets

Dataset governance should include a written version policy. Labels may change as vendors acquire new intelligence, family aliases may be merged, and legal restrictions may alter sample availability. A benchmark should therefore publish immutable split manifests, hashes or stable identifiers, feature-extractor versions, label timestamps, and a changelog that distinguishes corrected metadata from newly collected samples. EMBER2024 is a useful step because it broadens file-format and task coverage, but its long-term value will depend on transparent versioning and independent reproduction of its evaluation protocols [9-12].

Platform coverage is itself a dataset-design constraint. Windows PE has the richest set of reusable benchmarks in the literature reviewed here, whereas Android research is supported by corpora such as Drebin and large repositories such as AndroZoo [54, 99]. IoT studies more often rely on device- or network-specific telemetry and may be evaluated within federated or incremental-learning settings [57, 58]. Comparable public corpora for cloud-native workloads, containers, scripts, and memory-resident attacks are less standardized. Accordingly, cross-platform conclusions in this review concern transferable evaluation principles—provenance, temporal separation, uncertainty, acquisition cost, and robustness—rather than an assumption that the same features or benchmark maturity apply uniformly to every platform.

A defensible protocol should record stable identifiers, deduplication rules, collection dates, label sources, family-alias handling, and the split policy. Training and testing should be separated chronologically when temporal validity is claimed, and family-disjoint testing should prevent related variants from appearing on both sides. Open-set experiments should include families genuinely absent from training and allow rejection rather than forcing every sample into a known class. Table 12 summarizes the intended use and major caveat of representative public corpora; counts should be read as release-specific rather than permanent properties [10-12, 99].

Reproducibility also depends on versioning the feature extractor and the split manifest. A dataset name alone is not enough because labels, parsers, and available samples can change over time. Publishing stable identifiers, extraction code, configuration files, and split lists helps later studies separate model improvement from data revision. When raw malware cannot be redistributed, hashes, metadata, derived features, and auditable collection procedures can still be shared within legal and ethical limits [12, 42, 99].

5.2 Evaluation metrics and protocols

Evaluation metrics should reflect both class balance and the cost of errors. Accuracy is meaningful when classes and error costs are similar, but malware screening rarely meets that condition: false positives consume analyst time or block legitimate software, whereas false negatives permit compromise. Precision, recall, F1-score, specificity, Matthews correlation coefficient (MCC), ROC-AUC, and PR-AUC therefore answer different questions and should not be treated as interchangeable summaries [87, 101, 102]. PR-AUC is particularly useful when malware is rare, while MCC summarizes all four entries of the confusion matrix.

Temporal, open-set, and deployment claims need evidence beyond a single held-out score. In time-aware testing, results should be shown as the test window moves forward. Open-set studies should report how often unknown families are detected and what coverage is sacrificed when the model abstains. Deployment studies should add time to verdict, throughput, collection or sandbox cost, and alert volume at realistic prevalence [22, 87, 88, 101, 102]. Calibration also matters because ranking quality can remain stable while probabilities become overconfident after a distribution shift. For multiclass family attribution, macro- and micro-averaged scores should be accompanied by per-family support and a confusion analysis. Confidence intervals, explicit thresholds, hardware details, and comparisons across folds or temporal windows make the experiment easier to reproduce [11, 13, 87, 88, 101, 102].

precision $=T P /(T P+F P)$   (1)

recall $=T P /(T P+F N)$   (2)

specificity $=T N /(T N+F P)$   (3)

$F 1=2 \cdot$ precision ⋅ recall $/($precision + recall$)$   (4)

Table 13. Evaluation metrics for malware detection

Note: AUROC: Area Under the Receiver Operating Characteristic Curve; AUPR: Area Under the Precision–Recall Curve; MCC: Matthews Correlation Coefficient.

Confidence intervals on repeated splits, per-family or per-class metrics, a confusion matrix, calibration, feature-extraction time, inference time, hardware, and statistical comparisons across folds or temporal windows are recommended metrics to report [102]. An explicit decision threshold and the ensuing analyst workload at realistic prevalence should be included in the evaluation for operational claims. Table 13 collects the metrics most relevant to discrimination, calibration, and deployment, with their principal limitations [50, 87, 88, 101, 102].

Metrics become operational only after a prevalence and error-cost assumption is stated. A threshold that looks reasonable on a balanced laboratory set can flood analysts with alerts when malware is rare; a threshold tuned for precision can instead miss infrequent but severe threats. Reporting several operating points, expected cost under plausible prevalence, and calibration before and after temporal shift gives a more useful picture than one best F1-score [50, 87, 88, 101, 102].

Decision-theoretic evaluation makes these metrics operational by connecting a threshold to the expected cost of a decision.

That cost depends on malware prevalence, the burden of manual review, disruption caused by false blocking, and the consequence of a missed infection. Because these quantities vary across deployments, reporting several operating points is more informative than choosing the F1-maximizing threshold on a balanced test set. Calibration and abstention then become control mechanisms for deciding which samples can be handled automatically and which need deeper analysis or human review [50, 72, 87, 88].

7.1 Maintained, temporally honest, and open-set benchmarks

Future work requires maintained benchmark infrastructure rather than one-time dataset releases. A suitable benchmark should keep the acquisition time, lineage, file format, packer, label source, and benign software provenance and then impose chronological and family-disjoint evaluations. The presence of hidden or delayed test labels can help minimize retuning to a public test set, and periodic refreshes can help ensure that a detector is still learning new lineages and not simply memorizing an aging set of samples. The benchmark should not only provide overall performance but also degradation when it comes to sample age, family novelty, platform, and evidence available [9-12].

Benchmark governance is equally critical to benchmark construction. A maintained evaluation service could be used to audit duplicate leakage, to keep immutable split manifests, to publish versioned feature extractors, and to keep a private stream of future samples for independent testing. It should differentiate the changes due to malware evolution from the changes due to a new collection or labeling pipeline. Open-set protocols also require realistic unknowns; "blind-out" unknowns from random classes are less effective than other types of unknowns, such as families, packers, platforms, or behaviors that were genuinely absent from training. Such changes in confidence should be taken into account explicitly under shifts due to uncertainty, since confidence calibrated on an in-distribution test set may break down when the distribution shifts [13, 22, 62, 64].

There are multiple tiers of evidence that could be supported by a practical community benchmark. The first tier would involve less expensive public features for reproducible baselines; the second would feature the same features but would be evaluated in a controlled environment; the third would include dynamics and memory features; the fourth would involve adaptive attacks or deployment streams. This would enable wide-ranging participation without making the false promise that each outcome is a claim to the same operation. Restricted access packages should contain hashes, extraction code, configuration files, split lists, hardware information, and confidence intervals. Vetted test services can be used to manage access to malware instead of just omitting provenance [13, 22, 42, 65].

7.2 Semantics-aware detection, uncertainty, and safe abstention

The next generation of detectors should approach behavioral invariants. Data flow, call context, documentation, and deobfuscation can be combined in static models; arguments, return values, process lineage, memory objects, and network intent can be captured in dynamic models; and graph models can tie observations together across functions and processes. The goal is not to give up on statistical learning; it is to limit it with evidence that is more difficult to change without changing the attack. This principle was demonstrated in previous work on specification mining of malicious behavior, which showed that describing malicious behavior as a relation between actions, rather than as individual actions, is valuable and that this approach is also relevant for modern neural models [16, 33-35].

Uncertainty should be broken down as much as possible. Ambiguity due to lack of evidence is not the same as novelty due to a strange family, and both of these are different from disagreement between static/dynamic perspectives. Systems showing these differences may be able to select the most suitable action: re-run the execution, ask for memory analysis, obtain more related samples, or request analyst review. According to out-of-distribution detection research, the maximum Softmax confidence is a good baseline but not a complete solution, and large-scale uncertainty under shift studies reveal that calibration itself can worsen with a change in data distribution [22, 26, 50, 62, 103].

Selective prediction is more operational than forced classification. It is important to assess a detector based on the risk it takes at a selected coverage, rather than merely on the accuracy of the subset retained from the data. While conformal prediction and other distribution-free approaches can guarantee coverage under certain assumptions, assumptions of exchangeability can be violated by malware evolution, dependence between related variants, and adversarial sampling. Future research should then evaluate conformal/selective methods with chronological, family-disjoint, and cross-source shifts and document which cases are abstained from and how often further analysis leads to a correct classification, as well as whether abstention focuses on true hard-to-classify threats [67, 103, 104].

Direct measures of semantic validity are also required. A feature attribution should be an approximation to the program action or behavioral event that it claims to represent, and a graph explanation should be invariant to semantics-preserving rewrites. Counterfactual tests can be used to test the following: Does the removal or modification of the highlighted evidence result in a different model decision and a different malicious capability? This would shift explanation and robustness evaluation from visually convincing examples to falsifiable claims about behavior [18-20, 27].

7.3 Cost-aware multimodal cascades and missing-view robustness

A deployable hybrid system should acquire evidence progressively. Expensive steps such as dynamic execution, memory analysis, graph construction, or human review should be triggered when the expected information gain justifies their cost. The strategy must be optimized in light of losses resulting from undetected malware, false positive blocks, analysts' work, limitations of sandbox space, and response latency. The goal changes from the accuracy score achieved on the fully observed offline dataset to operational risk considerations [28, 49, 50, 72].

It is expected that some of the modalities will be missing. A sandbox could provide no traces, network information will not be available, and graphs will not be extracted from packed binaries. A multimodal detector is required to differentiate between "there is no evidence" and "evidence proves that this is benign," keep intact the contribution of every modality, and retain its calibrated scores even when input is corrupted or missing. Modality dropout and uncertainty-aware late fusion techniques look promising but should be tested on naturally missing and artificially hidden evidence, not just on masks [28, 42, 49].

Cascades need end-to-end reporting. Studies should state how many samples terminate at each stage, how often escalation occurs, the total latency, storage cost, sandbox failure rate, and the error profile of early exits. Otherwise, an efficient-looking cascade may simply discard the difficult samples before they reach expensive analysis. Recall and uncertainty should therefore be tracked across the entire acquisition path so that systems can be compared under the same resource budget [42, 49, 50, 61].

7.4 Analyst-centered explanations and evidence provenance

Explanations should be judged by what they help an analyst do. A useful explanation may reveal a malicious capability, point to supporting evidence, expose a model mistake, or guide containment. Evaluation should therefore measure fidelity and stability, but also practical outcomes such as investigation time, analyst agreement, error correction, and confidence. These tests are more informative than presenting an attractive heat map without showing whether it changes or improves an analyst's decision [27, 51-53].

Provenance should be maintained in all explanations. Highlighted bytes should be linked to file offsets and sections; API evidence should include arguments, process context, and timestamps; graph nodes should be linked to the recovered function or system object; and natural-language summaries should be linked to the events from which each claim is derived. Provenance enables an analyst to question the model and makes a post-incident audit possible. It also reduces the chance that a language model will create a strong but false impression of a correlation between two variables [27, 36, 72, 73].

The level of alerts and the cognitive load should also be considered when evaluating with a human-centered approach. The longer the explanation, the less useful it will be, and too many pieces of low-value evidence can mask what's important. Future systems should focus on providing short summaries of capabilities with drill-down options to the raw evidence, other hypotheses, and model uncertainties. Controlled studies with malware analysts are required to find out when explanations are beneficial to the decision-making process and when they only serve to reinforce the confidence in the wrong output result [27, 51, 52, 72].

7.5 Secure continual, federated, and MLOps-based adaptation

Continuous learning and federated learning can enable organizations to adapt to evolving malware without sacrificing the protection of sensitive telemetry; however, adaptation is an operation that cannot be done without due attention to security considerations. There are several differences among cross-silo clients, such as platforms, collection policies, class balance, and label delay, and it is possible that a global model will best fit the largest or cleanest client. Federated evaluation should measure client-level utility, cost of communications, privacy accounting, and performance of continuous-learning studies under partial participation [25, 57-59].

Another attractive poisoning surface is federated malware learning. Backdoor research has demonstrated that a malicious participant can craft a malicious update to be scalable such that the aggregation does not alter the targeted behavior while the normal validation is acceptable. The following is a list of data attributes that should be tested against adaptive attackers; in addition to benign heterogeneity, they should be tested: strong aggregation, update clipping, anomaly detection, secure aggregation, and trusted validation data [59, 69, 70]. Versioning data, feature extractors, models, thresholds, and rollback criteria are all essential components of operational ML Operations (MLOps), as technical debt is created by hidden data dependencies and feedback loops, making it challenging to audit or safely update a detector [61, 63].

Drift monitoring should tie alarms to actions. A loss in confidence could be due to a new malware family, a new compiler, a broken parser, a different benign population, or a change in the sandbox image. Each case should be treated differently in these situations. Monitoring should thus include feature-distribution tests, label-delay-aware performance estimates, family novelty, sandbox health, and post-deployment review. Retraining should only be performed after investigating the cause, and each update must be tested against a suite of historic examples to guard against silent regression [22, 58, 61, 63].

7.6 Foundation-model-assisted malware analysis under secure tooling

Foundation models are best treated as grounded analyst assistants rather than autonomous malware arbiters. They are able to analyze and summarize long sandbox reports, to normalize family aliases, to map observed actions to ATT&CK techniques, to identify related threat intelligence, and to write an analyst-facing explanation. These tasks can alleviate the problem of reading various reports but should be limited to structured inputs and outputs, deterministic extractors, and sources of retrieval with known provenance. The model should be given credit for saying that the evidence is insufficient rather than for providing a complete story [29, 60, 72, 73].

Assessment should be linked to measurable sub-tasks. A study can examine if the model is able to capture the correct API relationship, identify the supporting process event, refer to the appropriate report field, extract evidence from an existing technique, and refrain from identifying an artifact when it is missing. Model version, prompts, retrieval corpus, decoding settings, and permissions of the tool need to be noted, as silent service updates can influence the results. Human oversight is still required for critical decisions, particularly when the assistant offers a linkage between ambiguous evidence and a family or suggests containment [29, 60, 65, 72].

Analysis pipelines added by LLMs raise a new attack surface. Untrusted inputs include malware reports, strings, web pages, and threat-intelligence documents, and they can include instructions to redirect a model or its tools. In an indirect prompt, injected content can control an application without the user typing the malicious instruction. Malware assistants should therefore separate data from instructions, limit the permissions of the tools, validate the structured outputs, sanitize and validate the context retrieved, and wait for approval before performing actions or releasing sensitive information [71].

7.7 Resource-efficient and cross-platform deployment

Malware detection research is increasingly moving beyond server-side Windows classifiers. Mobile, IoT, cloud, container, and edge have distinct file formats, telemetry, resource constraints, and privacy issues. A representation appropriate for PE headers is probably not appropriate for scripts, firmware, Android Package Kits (APKs), or memory-resident cloud workloads. The cross-platform research should be able to identify reusable behavioral concepts (e.g., persistence, credential access, and command execution) and distinguish them from platform-specific observables and test transfer without adding the platform identity to the label [54-56, 99].

Resource utilization efficiency should be measured at a system level. The number of parameters and the inference time is incomplete if feature extraction requires disassembling the code, reconstructing the graph, or running the code for a long time in the sandbox or using a large memory trace. Distillation, quantization, pruning, early exits, and cascaded acquisition can be used for cost reduction, but the detector must be calibrated and retested for rare families and adversarial robustness. Energy consumption, memory consumption, throughput, and update bandwidth are important factors for IoT and federated environments [57, 61, 63, 76].

All these directions together indicate that systems around evidence, not a single classifier, are to be built. An ideal design would integrate time-maintained data and temporal evaluation [12, 13], multimodal or cascaded acquisition [28, 49], explicit robustness testing [37, 65], calibrated uncertainty [50, 62], controlled adaptation [26, 69], provenance-preserving explanations [27], and human review for consequential decisions [72]. Such a system may not maximize one benchmark score, but it is more likely to remain useful as malware and deployment conditions change.