PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey of Stealth Malware: Attacks, Mitigation Measures, and Steps Toward Autonomous Open World Solutions

Ethan M. Rudd, Andras Rozsa, Manuel Günther, Terrance E. Boult

arXiv:1603.06028v2cs.CRcs.CV

TL;DR

Stealth malware is difficult to recognize because it evades detection and can include previously unseen attack types, while conventional recognition algorithms make restrictive assumptions about the classes encountered. The paper surveys stealth technologies and countermeasures, identifies these assumptions, and formalizes an adaptive open-world recognition framework. It concludes that open-world recognition must manage unknown classes and open-space risk, while important operational questions remain about bounding that risk and handling misclassification costs.

  • Problem

    Stealth malware requires recognition methods that generalize to unseen malware while reducing human burden, but conventional algorithms commonly assume a fixed closed set of classes.

  • Method

    The paper surveys stealth technologies and countermeasures, then formalizes an adaptive open-world framework by relating intrusion recognition to novelty detection and other machine-learning research.

  • Results

    The paper identifies flawed assumptions in existing recognition approaches and shows how open-set and online recognition methods can manage open-space risk and support incremental updates.

  • Takeaways & Limitations

    Stealth-malware recognition should distinguish known classes from unknown classes while combining component-protection countermeasures with generic machine-learning solutions.

  • Takeaways & Limitations

    Operational deployment still requires experimentation to determine how tightly to bound open-space risk and how to weigh misclassifying unknown samples against available labeling resources and expected threats.

Abstract

from arXiv · show

As our professional, social, and financial existences become increasingly digitized and as our government, healthcare, and military infrastructures rely more on computer technologies, they present larger and more lucrative targets for malware. Stealth malware in particular poses an increased threat because it is specifically designed to evade detection mechanisms, spreading dormant, in the wild for extended periods of time, gathering sensitive information or positioning itself for a high-impact zero-day attack. Policing the growing attack surface requires the development of efficient anti-malware solutions with improved generalization to detect novel types of malware and resolve these occurrences with as little burden on human experts as possible. In this paper, we survey malicious stealth technologies as well as existing solutions for detecting and categorizing these countermeasures autonomously. While machine learning offers promising potential for increasingly autonomous solutions with improved generalization to new malware types, both at the network level and at the host level, our findings suggest that several flawed assumptions inherent to most recognition algorithms prevent a direct mapping between the stealth malware recognition problem and a machine learning solution. The most notable of these flawed assumptions is the closed world assumption: that no sample belonging to a class outside of a static training set will appear at query time. We present a formalized adaptive open world framework for stealth malware recognition and relate it mathematically to research from other machine learning domains.

I. INTRODUCTION

The paper surveys stealth malware technologies and countermeasures, arguing that realistic recognition requires addressing flawed assumptions in conventional machine-learning approaches. It introduces an adaptive open-world framework alongside a broader technical survey of stealth mechanisms and defenses.

  • Motivation: Stealth malware can combine virus, worm, botnet, and rootkit behaviors within one multi-component system.Such malware may spread across hosts, propagate through networks, communicate with command-and-control servers, and conceal itself from intrusion detection systems.
  • Machine Learning Challenges: Many machine-learning intrusion-recognition algorithms rely on flawed assumptions, especially the closed-world assumption that query samples belong to fixed training classes.The paper argues that these assumptions distort the mapping between machine-learning methods and realistic stealth-malware recognition.
  • Contributions: The paper surveys stealth malware technologies and countermeasures with greater scope and mathematical detail than prior narrowly focused surveys.Its coverage extends beyond rootkits to stealth-malware mechanics, countermeasures, and applied machine-learning examples.
  • Proposed Framework: The paper proposes an adaptive open-world mathematical framework that addresses six flawed assumptions and connects stealth-malware recognition with related machine-learning research.The framework is presented after surveying stealth technologies and network- and host-level countermeasures.
  • Scope: Over 90% of malware targets Microsoft Windows, motivating the paper’s primary focus on Windows examples.The paper also notes comparatively little academic research discussing Windows security.
  • Stealth Malware Technologies: Stealth malware includes rootkits, code mutation, anti-emulation, and targeting mechanisms, often used together.Rootkits hide files, processes, connections, or registry keys; code mutation changes code appearance; anti-emulation detects sandboxes; targeting mechanisms limit spread and collateral damage.

A. Type 1 Rootkits: Malicious System Files on Disk

Type 1 rootkits began as disk-resident system-file replacements, while later in-memory hooking redirects execution through injected or modified code. These techniques can conceal activity, but legitimate and dynamic loading behaviors complicate detection and implementation.

  • A. Type 1 Rootkits: Malicious System Files on Disk: Early rootkits masqueraded as disk-resident system programs, providing persistence across reboots but remaining easy to detect and remove.Modern rootkits instead emphasize stealth, activity logging, backdoors, and covert C2 channels.
  • B. Type 2 Rootkits: Hooking and in-Memory Redirection of Code Execution: Hooking redirects execution by modifying function pointers or overwriting code so malicious code runs before or after legitimate operating-system calls.Rootkits can filter returned data or requested functionality, including selectively hiding files.
  • B. Type 2 Rootkits: Hooking and in-Memory Redirection of Code Execution: Hooking is also used legitimately for hot patching, monitoring, profiling, and debugging, making malicious rootkit instances difficult to distinguish.DLL injection and event-hook chains provide additional user-mode routes for placing malicious callbacks into target processes.
  • 1) User-Mode Hooking:: IAT hooking changes executable function pointers to malicious code that commonly invokes the original API while altering or filtering its result.The technique can interpose on file-enumeration APIs to hide selected files.
  • 1) User-Mode Hooking:: IAT hooking is limited by PE parsing, API-oriented scope, runtime DLL loading, and dynamic resolution through LoadLibrary and GetProcAddress.DLLs loaded at runtime may lack IAT entries until use, while dynamically resolved DLLs have no entries to hook.
  • B. Type 2 Rootkits: Hooking and in-Memory Redirection of Code Execution: Detouring overwrites an in-memory code snippet with a jump, saves the displaced stub, executes malicious code, and may return to the original path.Generic patching is difficult because variable-length instructions require disassembly and careless stub handling can corrupt memory.

2) Kernel-Mode Hooking:

Kernel-mode hooking targets privileged Windows structures and drivers, making user-space detection harder while enabling broad manipulation of system calls and device operations. Correct implementation is technically demanding because kernel errors can crash the system and driver stacks require precise hook placement.

  • 2) Kernel-Mode Hooking:: Event-hook-chain injection prepends a malicious callback to a target process’s keypress chain, allowing each keypress to trigger keystroke logging.The technique uses a support program, a DLL-exported function, and SetWindowsHookEx to install the hook.
  • 2) Kernel-Mode Hooking:: Kernel hooks are harder for user-space anti-malware to detect because such software lacks the permissions needed to access kernel memory.Kernel hooks are commonly implemented through device drivers and target structures such as the SSDT, IDT, and IRP tables.
  • 2) Kernel-Mode Hooking:: The SSDT stores function pointers for system calls, which the operating system indexes to dispatch requested kernel functionality.SSDT hooks can redirect calls such as NTQuerySystemInformation to shell code that filters process information.
  • 2) Kernel-Mode Hooking:: Kernel hooking can supplement system calls with additional functionality, while IDT hooks are more limited because interrupts provide no return values for data filtration.Multiprocessing also makes IDT hooking harder because each CPU has its own interrupt table.
  • 2) Kernel-Mode Hooking:: Device-driver dispatch-table hooking requires sophisticated implementation because driver errors can corrupt shared kernel memory and crash the system.Stacked drivers additionally require attackers to understand stack behavior, hook placement, and I/O completion.

3) Hybrid Hooking:

Hybrid attacks combine user-space and kernel-space mechanisms to bypass defenses aimed at either layer. DKOM instead modifies kernel data structures, potentially hiding processes from both user- and kernel-mode views while leaving implementation and crash risks.

  • 3) Hybrid Hooking:: Hybrid hooks attack user and kernel space simultaneously to circumvent anti-malware and avoid the user-space allocation or DLL injection required by ordinary IAT hooks.One approach uses a kernel image-load callback to modify the target process after loading but before execution.
  • 3) Hybrid Hooking:: The Illusion attack combines kernel and user components to circumvent intrusion-detection systems that rely on system-call analysis.Its motivation is to manipulate behavior across the transition between user-mode requests and kernel-mode execution.
  • 3) Hybrid Hooking:: DKOM modifies dynamic kernel data structures rather than introducing ordinary hooks, with process hiding as its canonical example.The attack exploits distinct scheduler and resource-bookkeeping structures.
  • 3) Hybrid Hooking:: A hidden process can disappear from user- and kernel-mode programs while its threads continue receiving CPU time and executing.The Windows example relies on manipulating the executive-layer process representation without removing the scheduler’s corresponding data.
  • 3) Hybrid Hooking:: DKOM implementations are extremely difficult to detect, but incorrect kernel-data-structure changes can crash the kernel and expose the malware.The technique also has limited applications because it introduces little new kernel code beyond the modification logic.

D. Type 4 Rootkits: Cross Platform Rootkits and Rootkits in Hardware

Fourth-generation rootkits target virtualization layers, BIOS, hardware, or supply chains and are described primarily in proof-of-concept settings. Code mutation complements these low-level approaches by changing malicious code’s appearance to evade signature scans, though transformed code can impose overhead and remain detectable through emulation.

  • D. Type 4 Rootkits: Cross Platform Rootkits and Rootkits in Hardware: Fourth-generation rootkits operate at virtualization, BIOS, or hardware layers and require custom low-level components or physical and supply-chain compromise.The survey reports these technologies primarily in proof-of-concept settings.
  • E. Code Mutation: Code mutation avoids simple signature matching, but it can introduce greater runtime overhead and remain detectable through emulation.Emulation-based detection exploits execution behavior rather than relying only on static signatures.
  • E. Code Mutation: Metamorphic engines evade signature scans by changing registers, subroutine order, independent-instruction order, inserted no-op behavior, or semantically equivalent instructions.These transformations alter code representation across malware generations while preserving intended behavior.
  • E. Code Mutation: Android security suites often failed to recognize transformed malicious Dalvik bytecode, showing that code transformation techniques extend beyond native binaries.Android-specific examples include package renaming and resource-file encryption, alongside control, data, and layout transformations.

F. Anti-Emulation

Anti-emulation strategies let malware evade analysis environments, while emulation-based detection must balance realism, cost, and the malware’s ability to recognize or outlast the environment.

  • F. Anti-Emulation: Mutation engines alter instructions and runtime appearance without changing underlying functionality.This can reduce the value of analyses that depend on observing an unchanged code representation.
  • F. Anti-Emulation: Malware detects emulators through machine configurations, difficult-to-emulate functionality, delayed execution, and simulated human-input characteristics.Examples include hardware identifiers, GPU use, long delays, and analysis of mouse speed and curvature.
  • F. Anti-Emulation: Realistic emulation reduces hardware-based detection but cannot defeat anti-emulation tactics that depend on timing or behavioral requirements.Some malware executes only after extended idle periods or when particular conditions are satisfied.
  • F. Anti-Emulation: Emulated environments face a tradeoff between realistic analysis and implementation cost.The expanding use of virtualization also gives anti-emulation techniques a broader environment to target.
  • F. Anti-Emulation: Hook detection is easy to implement but can produce high false-positive rates because legitimate hooks are not inherently malicious.Detecting hooks can be strengthened by monitoring likely attack points or combining hook checks with signatures and heuristics.
  • F. Anti-Emulation: Memory-scanning approaches such as VICE inspect likely hook locations and identify suspicious jumps outside acceptable address ranges.Generic inline hooks remain difficult to detect with this method, while early function hooks are more observable.

B. Cross-View Detection and Specification Based Methods

Cross-view detection compares multiple system representations to expose inconsistencies, while invariant specifications define expected kernel behavior; both provide useful detection but face implementation and platform constraints.

  • B. Cross-View Detection and Specification Based Methods: Cross-view detection compares the same system aspect through multiple observation methods to reveal conflicting views.It can detect rootkits by comparing outputs from operating-system interfaces with independently obtained system information.
  • B. Cross-View Detection and Specification Based Methods: Correctly implemented cross-view detection can achieve few false positives, but it is difficult to implement and update.Its effectiveness depends on selecting suitable views and may require kernel-level interfacing.
  • B. Cross-View Detection and Specification Based Methods: Cross-view detection provides limited information about rootkit type and therefore must be combined with recognition methods for classification.Signature- or behavior-based recognition supplies information that cross-view inconsistency alone does not provide.
  • B. Cross-View Detection and Specification Based Methods: Invariant specification monitors kernel properties that should remain unchanged under normal operating-system behavior, especially for detecting DKOM attacks.The approach defines constraints of an uninfected system and periodically checks those invariants.
  • B. Cross-View Detection and Specification Based Methods: Invariant specifications decouple site-specific security constraints from system-specific constraints and can catch DKOM attacks violating those constraints with few false positives.Layered specifications can add organizational policies without changing low-level implementations.
  • B. Cross-View Detection and Specification Based Methods: Invariant specification requires substantial implementation effort and complete specifications are difficult across heterogeneous operating systems.Incorrect or incomplete platform knowledge can produce false positives, particularly for closed-source systems.
  • B. Cross-View Detection and Specification Based Methods: Hardware-based integrity checking observes a host through a clean supervisory machine without relying on the monitored kernel’s integrity.DMA cannot inspect CPU registers or cache contents and has difficulty locating and synchronizing dynamic kernel structures.

E. Virtualization Techniques

Virtualization enables inspection and control of guest operating systems from a more privileged layer, supporting rootkit detection and prevention but introducing platform and anti-emulation limitations.

  • E. Virtualization Techniques: Virtualization can detect kernel-level rootkits and interpose on system state, but it remains vulnerable to anti-emulation techniques.Its purpose is to inspect host resources without relying on the operating system’s integrity.
  • E. Virtualization Techniques: Livewire performs virtual machine introspection by translating raw hardware state into guest operating-system semantics for policy-based intrusion detection.A hypervisor-layer policy engine inspects guest objects through the translation provided by the operating-system interface.
  • E. Virtualization Techniques: Virtualization can prevent rootkits from executing code in kernel memory, including DKOM rootkits that must introduce code to modify kernel objects.SecVisor enforces write XOR execute permissions for kernel code pages through hardware virtualization.
  • E. Virtualization Techniques: SecVisor assumes kernel code and data are not mixed within memory pages and requires kernel modifications, limiting adoption on modern systems.It also fails for pages containing self-modifying kernel code.
  • E. Virtualization Techniques: NICKLE shadows kernel code in hypervisor-controlled memory and uses cryptographic comparisons with known-good code values before execution.Hypervisor indirection redirects guest requests to the protected shadow values.
  • E. Virtualization Techniques: Sherlock uses the Xen hypervisor and a separate security virtual machine to monitor and reconstruct guest-system-call execution paths.The reconstructed paths support analysis and notification of intrusion-related events.

C. Feature Space Models vs. State Space Models

Feature-space models classify malware using explicit vectorized features, whereas state-space models infer sequence probabilities under assumptions such as Markov dependence. The survey highlights scalability, representation, and closed-world limitations in these approaches.

  • C. Feature Space Models vs. State Space Models: Feature-space models represent signatures or behavioral features as dimensions and learn class manifolds in a high-dimensional space.Generative models estimate P(x, y), while discriminative models estimate P(y|x) directly.
  • C. Feature Space Models vs. State Space Models: Feature-space models do not explicitly represent probabilistic dependencies, and their accuracy-oriented features may be difficult to interpret.A useful classification representation is not necessarily intuitive to analysts.
  • C. Feature Space Models vs. State Space Models: State-space models infer probabilities over instruction, system-call, or network-communication sequences using dependencies among hidden states.They exploit recurring functional sequences in malicious binaries and behavior.
  • C. Feature Space Models vs. State Space Models: Markov-based state-space models make sequential inference tractable by treating recent events as independent of sufficiently distant events.The Markov assumption is not always valid but is often considered reasonable for sequential analysis.
  • C. Feature Space Models vs. State Space Models: HMMs combine transition probabilities, observation probabilities, and an initial-state vector, estimated through expectation maximization on observation sequences.The estimation seeks the maximum-likelihood model for the observed sequence.
  • C. Feature Space Models vs. State Space Models: Feature-space opcode analysis requires separate n-gram dimensions for sequence lengths and scales only to a few lengths, whereas HMMs encode sequential dependence through hidden states.The figure contrasts explicit n-gram histograms with a Markov sequence model.
  • C. Feature Space Models vs. State Space Models: HMM-based metamorphic-virus recognition commonly assumes a predominantly decrypted virus body and uses a thresholded per-opcode negative log-likelihood.These systems generally use a small hidden-state space and a larger opcode observation matrix.
  • C. Feature Space Models vs. State Space Models: Previously unseen stealth malware requires recognition systems that adapt quickly, because it can avoid known signatures and conceal harmful behavior as benign.The paper argues that adaptive systems must also provide interpretable information for operators and response modules.

A. Six Flawed Assumptions

Real intrusion recognition is an open-world problem: classifiers encounter unseen malicious and benign classes, while conventional methods assume a fixed closed set and may confidently mislabel unknowns. The paper identifies related risks involving anomaly labels, static models, negative-space coverage, and feature representation.

  • Real intrusion recognition includes classes absent from training, but most techniques evaluate only a fixed closed set of classes.
  • Unknown classes make closed-set classifiers potentially assign high-confidence known labels outside the support of training data, creating open space risk.Open-world systems must label sufficiently distant instances as “unknown”.
  • Binary intrusion detection remains open-set because “intrusion” and “no intrusion” are metalabels covering many known and unknown subclasses.
  • Anomalies do not inherently provide class labels; in open-set recognition, anomalous points require resolution by an operator, protocol, or other recognition modality.
  • Static anti-malware models are insufficient under concept drift because malicious behaviors and code signatures change, while full retraining may be infeasible.Efficient update mechanisms are needed to reduce temporal risk.
  • Effective intrusion recognition requires meaningful feature transformations because raw or aggregated heterogeneous logs may ignore nonlinear manifolds, temporal scale, and spatial bandwidths.

5) Model Interpretation is Optional:

Model interpretation is not optional for intrusion recognition: opaque or adversarially vulnerable models may provide alerts without the diagnostics needed for rapid and appropriate response. The paper therefore motivates recognition frameworks that provide additional diagnostic information.

  • Neural-network representations and final readouts may lack understood semantic meaning, limiting interpretation of intrusion decisions.
  • Adversarial examples can be misclassified with high confidence, while weak interpretability prevents systems from resolving many intrusions autonomously.
  • Without meaningful diagnostics, operators or anti-malware modules may waste valuable time diagnosing alarms, especially when signals such as hooking can also be legitimate.
  • Intrusion detection should move toward generic recognition frameworks that provide additional diagnostic information, as in diagnosis systems using Bayesian networks and rule mining.

6) Class Distributions are Gaussian:

The paper challenges Gaussian assumptions for modeling class distributions because anomaly detection depends on distribution tails, which Gaussian mixtures generally fail to capture. Statistical extreme value theory offers theoretically grounded alternatives for modeling those tails.

  • Many probabilistic intrusion-recognition models assume that class distributions are single- or multi-modal Gaussian mixtures.
  • Gaussian mixtures generally fail to capture distribution tails except in special cases, limiting their fit for anomaly detection.
  • Empirical anomalies are defined relative to a training-data model, whereas idealized anomalies are defined relative to the joint training-data distribution.
  • Naive Gaussian assumptions can mismatch empirical and idealized anomalies because anomalies are defined by distribution tails that tend to deviate from Gaussian behavior.
  • Statistical extreme value theory provides theoretically grounded functional forms for class-tail distributions.

B. An Open Set Recognition Framework

The framework treats stealth-malware intrusion recognition as open set recognition, where query samples may belong to unknown classes and decisions must control open space risk. It formalizes abating bounds and shows how thresholded novelty detectors, KDE, and selected GMM formulations fit this framework, while identifying assumptions and unresolved limitations.

  • Open Set Recognition: Novelty detection should identify samples unsupported by training data rather than assume that all benign behavior can be represented in advance.Benign behavior varies with hosts, configurations, software, users, and network conditions, making complete coverage infeasible.
  • Open Space Risk: Theorem 1 shows that thresholding positively weighted sums, products, minima, or maxima of bounded functions can constrain open space risk below any chosen ε.The component functions must have non-negative, bounded, monotonically decreasing bounds with distance from reference points.
  • Open Set Recognition: Many IDS novelty-detection methods, including thresholded neighbor methods, clustering, and KDE, therefore fit the open set recognition framework and manage open space risk.The result supports online isolation of unknown classes and thresholded density estimation for normal data.
  • Limitations: Thresholded KDE requires meaningful bandwidth and decision thresholds, and implicitly assumes local isotropy in the feature space.These requirements make the quality of feature-space representation important.
  • Parametric Models: Thresholded GMM density estimates also manage open space risk, but this guarantee applies to an individual GMM rather than necessarily to recognition functions combining multiple GMMs.Probability ratios and comparisons between GMMs can remain positive over unbounded regions and therefore lack the guarantee.
  • Limitations: Under additional factor assumptions, HMMs can manage open space risk, but enforcing those factors is unresolved and many existing HMMs lack the proof.The paper leaves construction of HMMs that both manage open space risk and adequately model data for future research.
  • Limitations: Non-negative coefficients are required for the theorem’s SVM-style function bounds, so several multi-class and one-class SVM variants are not proven to manage open space risk.The guarantee depends on the recognition function satisfying the theorem’s structural conditions.

C. Open World Archetypes for Stealth Malware Intrusion Recognition

Open world intrusion recognition combines closed-set classifiers with mechanisms that identify unknown samples, update models online, and prioritize novel data for labeling. The framework supports practical adaptation while requiring explicit open-space guarantees and attention to tail behavior and labeling capacity.

  • Open World Recognition: Closed-set classifiers can remain useful when fused with open-set recognition, which determines whether their class decisions are meaningful for unknown samples.Open-set components are needed to manage open space risk rather than abandoning closed-set methods entirely.
  • Open Set Decisions: A thresholded open-set density decision labels a query as unknown when every class-specific maximum density falls below the threshold τ.The appropriate threshold depends on security, latency, and available expert intervention.
  • Feature Spaces: Open-set and closed-set algorithms may operate in different feature spaces, including machine-learned transformed spaces.The framework is therefore not restricted to a shared raw feature representation.
  • Online Adaptation: Online open world recognition supports incremental model updates as new observations arrive, but many incremental intrusion-recognition functions are not proven to manage open space risk.Satisfying the theorem’s conditions is what distinguishes a formally supported open world classifier.
  • Label Prioritization: Because expert labeling capacity is limited, the framework prioritizes unknown samples by malicious likelihood to support incremental training.The proposed ranking favors unknown samples likely associated with known malicious classes.
  • Modeling Assumptions: Open world recognition is not confined to Gaussian assumptions because accurate tail behavior matters for recognition, where Gaussian mixtures can deteriorate.The paper contrasts the tails of unimodal Gaussian components with generally different data-distribution tails.

VI. CONCLUSIONS AND OPEN ISSUES

The paper surveys stealth malware and mitigation measures, identifies flawed assumptions in intrusion-recognition algorithms, and proposes an adaptive open-world framework. It also highlights unresolved operational, experimental, and dataset challenges for deploying open-world anti-malware systems.

  • Conclusions: The survey covers malicious stealth technologies and mitigation measures, emphasizing the need to combine integrity-protection countermeasures with generic machine-learning recognition.The paper frames this combination as important for addressing stealth malware and flawed assumptions in existing recognition algorithms.
  • Conclusions: The paper encourages the security community to consider these suggestions when developing future intrusion-recognition algorithms.This recommendation follows the paper’s analysis of flawed assumptions and related recognition research.
  • Open Issues: The authors propose a mathematically formalized open-world approach, but determining open-space bounds and operational openness remains an experimental and implementation challenge.The paper warns that overly aggressive bounds may degrade performance on predominantly closed-set problems.
  • Open Issues: Modern publicly available datasets containing realistic stealth-malware samples are scarce, limiting benchmarking and experimentation under open-world protocols.The authors identify dataset collection and distribution as vital for further academic research.
  • Open Issues: Existing intrusion-recognition algorithms can satisfy open-set requirements, but feature-space discrimination, interpretability, distribution modeling, and tail-boundary selection require further research.The paper identifies statistical extreme value theory as a promising starting point while noting unresolved distribution-modeling issues.

APPENDIX: API CALLS, DATA STRUCTURES, AND REGISTRY KEYS

The appendix table documents Windows system calls, data structures, registry keys, and system files used by the malware discussed in the section. Entries are arranged alphabetically and draw on documentation or summaries from the paper.

  • Windows APIs: ntdll.dll exports the Windows Native API used by user-mode operating-system components that operate without Win32 or other API-subsystem support.The entry distinguishes the Native API from higher-level API subsystems.
  • Windows System Files: ntoskrnl.exe provides the Windows NT kernel and executive layers, including hardware virtualization, process management, and memory management.The entry describes it as fundamental to the system.
  • Windows APIs: user32.dll implements standard Windows user-interface elements including the desktop, windows, and menus.The entry identifies the library’s role in creating and manipulating the Windows user component.
  • Table I: The table organizes Windows system calls, data structures, registry keys, and system files in that order and alphabetically.Its entries describe artifacts used by the malware analyzed in the section.
Loading 1603.06028v2…