A Measurement Study of AI-Environment Realism Gaps in Malware-Analysis Sandboxes
arXiv:2607.14434v1 [cs.CR] 16 Jul 2026
Zhiyong Sui, Lamine Noureddine, Mst Eshita Khatun, Sideeq Bello, Babangida Bappah, Justin Woodring, Aisha Ali-Gombe Louisiana State University {zsui1, lnoureddine, mkhatu3, sbell49, bbappa1, jwoodr7, aaligombe}@lsu.edu Abstract—Sandboxing remains a core technique for observing suspicious program behavior, yet environment-aware malware increasingly suppresses execution when analysis is suspected. Prior generations of sandbox evasion focused on virtualization artifacts, timing discrepancies, and wear-and-tear realism. In this paper, we present the first systematic measurement study of AI-environment artifacts as a new sandbox-evasion surface. We operationalize this realism gap through AIprints, a probe framework that captures persistent artifacts left behind by AI-capable software ecosystems, including AI-assistant configuration directories, model caches, environment variables, local inference services, and package dependencies. We systematically extract 450 unique artifacts from 284 open-source AI projects on GitHub, compile them into unprivileged Windows probes, and evaluate them across seven commercial and open-source sandbox backends together with three AI-capable reference hosts. Our results show that traditional VM-detection baselines fail to reliably distinguish real AI-capable systems from modern sandboxes, whereas twelve AI-environment artifacts appear on the reference hosts and on none of the evaluated backends. A controlled 214-step installation experiment establishes a causal relationship between AI tool and package installation and measurable AI-environment artifact accumulation, while adaptive spoofing experiments reveal a fundamental operational asymmetry: reproducing convincing AI software environments is substantially more expensive than detecting shallow spoofing. Index Terms—sandbox evasion, malware analysis, AI artifacts, environment fingerprinting
1. Introduction Malware-analysis sandboxes are a foundational component of modern security infrastructure. Analysts routinely execute untrusted programs inside contained and instrumented environments because static analysis alone is often ineffective against packing, obfuscation, and runtimetriggered behavior [1], [2]. The entire containment approach rests on a fragile assumption: that the sandbox resembles a genuine endpoint closely enough to avoid detection. Malware authors have spent more than a decade attacking that assumption.
Defenders responded in three successive generations: first by scrubbing obvious virtualization artifacts [3]–[5], then by reducing timing and emulation side channels and deploying bare-metal analysis hosts [6], [7], and most recently by aging sandbox images to mimic the wear and tear of real user activity [8]. Each generation focused on reducing observable discrepancies between sandbox environments and genuine endpoints. Modern malware, however, is increasingly shifting from probing what a host is to probing what the host runs. In early 2025, Google’s Threat Intelligence Group disclosed HONESTCUE, malware that invokes the Gemini API to generate and execute payloads in memory [9]; shortly afterward, Trend Micro documented Lumma Stealer checking for GPU presence before detonation [10]. At the same time, AI-capable software ecosystems have become increasingly common across consumer, enterprise, and developer environments, creating a new class of persistent host-level footprints that differ fundamentally from traditional virtualization or wear-and-tear indicators. Thus, in this paper, we present the first systematic measurement study of AI-environment artifacts as a new sandbox-evasion surface. We operationalize this realism gap through AIprint, a probe framework that captures persistent artifacts left behind by AI-capable software ecosystems. Unlike earlier anti-analysis heuristics that infer human activity indirectly through behavioral traces such as mouse movement or process counts [11], [12], AIprint focus on system artifacts associated with functioning AI tooling, including AI-assistant configuration directories, model caches, environment variables, local inference services, and package dependencies. These artifacts emerge as a byproduct of installed AI software and are therefore substantially more expensive to reproduce convincingly than traditional virtualization or wear-and-tear indicators. To evaluate this AI-environment fidelity gap, we design a four-stage measurement methodology that systematically extracts 450 unique artifacts from 284 open-source AI projects on GitHub, compiles them into standalone unprivileged Windows probes, and executes them across seven commercial and open-source sandbox backends together with three AI-capable hosts. We further establish causality through a controlled cumulative-installation experiment on a clean machine and evaluate defensive spoofing strategies against
adaptive structural validation attacks. Our results show that traditional VM-detection baselines fail to distinguish AI-capable hosts from modern sandboxes, whereas twelve AI-environment artifacts—including .claude, .cursor, OPENAI_API_KEY, and Ollama port 11434—appear on the reference hosts and on none of the evaluated backends. Across 214 cumulative installation steps, AIprint detection rises monotonically from 0.6% to 17.8% while the traditional VM baseline remains effectively unchanged. Finally, we show that shallow artifact spoofing is insufficient against lightweight structural validation, creating a fundamental operational asymmetry in which reproducing convincing AI ecosystems is substantially more expensive than detecting shallow spoofing. Our paper makes the following main contributions: • We present the first systematic measurement study of AIenvironment artifacts as a new sandbox-evasion surface and organize these artifacts into a four-category taxonomy extracted from 284 GitHub AI projects through a reusable provenance-preserving pipeline (§4). • We evaluate AIprint across seven commercial and opensource sandbox backends together with three AI-capable hosts, showing that AI-environment artifacts discriminate where traditional VM-detection baselines do not (§6.1, §6.2). • We establish a causal relationship between AI-tool installation and AIprint detection through a 214-step controlled cumulative-installation experiment, using traditional VM detection as a negative control (§6.3). • We evaluate progressive artifact-spoofing defenses and adaptive structural validation attacks across five spoofing levels, exposing a fundamental operational asymmetry in which reproducing convincing AI ecosystems is substantially more expensive than detecting shallow spoofing (§6.4). • To support reproducible research, we will release the complete AIprint framework, artifact-extraction workflow, generated datasets, probe implementations, and experimental results upon publication. Paper outline. The remainder of this paper is organized as follows. Section 2 presents the background and related work on sandbox evasion and AI-environment realism. Section 3 introduces the overall measurement methodology and workflow. Sections 4 and 5 describe the artifact taxonomy, extraction pipeline, probe design, and sandbox execution infrastructure. Section 6 presents the empirical evaluation and defense analysis across all four research questions. Section 7 discusses limitations, implications, and broader considerations for sandbox realism, and Section 8 concludes the paper.
2. Background and Related Work Malware-analysis sandbox evasion has evolved through distinct generations of environment fingerprinting. First generation: virtualization artifacts. Early sandboxevasion techniques focused on deterministic fingerprints left
by virtualization platforms. Malware probed for artifacts such as CPUID vendor strings (e.g., VMwareVMware), MAC-address prefixes, hypervisor-specific drivers and processes, and characteristic registry keys [3]–[5]. Toolkits such as al-khaser aggregate hundreds of these checks into reusable anti-analysis frameworks [12]. Defenders responded by scrubbing or spoofing virtualization artifacts within sandbox images. Second generation: timing, emulation, and bare metal. As virtualization artifacts became easier to hide, malware shifted toward timing and behavioral discrepancies between analysis environments and physical hardware, including instruction latency, cache behavior, and imperfect emulation [6], [7]. Defenders responded through increasingly realistic emulation, bare-metal execution, and behavioraldivergence analysis to expose “split-personality” malware that suppresses malicious behavior during analysis [13]– [18]. Third generation: system wear-and-tear. As virtualization and timing artifacts became less reliable, malware increasingly evaluated whether a system appeared genuinely used rather than merely virtualized. Real endpoints accumulate traces of long-term human activity, including browser history, event logs, user files, and diverse background processes, whereas sandbox images are often freshly reverted and operationally sparse. Anti-analysis heuristics exploit this gap through indicators such as realistic process counts, mouse activity, populated user directories, and anomalous DNS behavior [11], [12]. Miramirkhani et al. formalized this idea as wear-and-tear fingerprinting, showing that environmental usage artifacts can distinguish genuine hosts from sandbox environments with 92.86% accuracy [8]. Defenders consequently adopted synthetic aging to simulate realistic system evolution and user activity. Fingerprinting the sandbox, or the real machine. A complementary line of work fingerprints sandbox infrastructures directly rather than validating environment characteristics. Systems such as SandPrint, AVLeak, and Androidenvironment fingerprinting identify analysis environments through high-entropy hardware allocations, emulator side channels, and mobile-environment traces [19]–[22]. However, many such indicators remain deterministic and can potentially be diversified or randomized by careful sandbox operators.
2.1. A Fourth Generation of Evasion We study a gap not addressed by prior generations of sandbox evasion: the presence or absence of persistent AI software ecosystems. Unlike earlier approaches that focused on virtualization artifacts, execution characteristics, or passive traces of human activity, this generation targets evidence of AI-capable computational environments, including local inference runtimes, model caches, package dependencies, runtime services, and AI-specific configuration state. This shift also changes the defender’s burden. Prior generations could often be mitigated through artifact scrubbing,
higher-fidelity execution, or synthetic aging. In contrast, mitigating AI-environment checks requires sandbox operators to deploy and continuously maintain functional AI ecosystems with evolving runtimes, dependencies, model artifacts, and potentially GPU-enabled infrastructure. Table 12 in Appendix A summarizes how the four generations differ in the environmental fingerprints they exploit and the operational cost of defending against them.
2.2. AI-Environment Realism The evasion surface studied in this work is driven by the rapid adoption of AI-enabled software ecosystems across consumer, enterprise, and developer environments. PyTorch averages over 80 million monthly PyPI downloads as of 2025 [23]; Ollama exceeds 100 million Docker Hub pulls [24]; and the JetBrains 2025 Developer Ecosystem Survey reports that 62% of professional developers use at least one AI coding assistant [25]. At the enterprise level, GitHub reports that Copilot is deployed across more than 77,000 organizations and used by over 1.8 million developers [26]. Beyond software engineering, operating-system vendors increasingly position AI capability as a standard endpoint feature through platforms such as Copilot+ PCs, Apple Intelligence, and Gemini-integrated productivity environments. These ecosystems leave behind persistent local artifacts, including model caches, runtime services, package dependencies, environment variables, AI assistants, and configuration directories that remain observable long after active use has ended. We refer to the resulting environmental characteristics as AI-environment realism. We conceptualize AI-enabled endpoints as a spectrum of AI personas, ranging from lightweight consumer AI integrations and enterprise AI-assisted workflows to fully provisioned local AI ecosystems. These personas collectively contribute to a widening fidelity gap between genuine endpoints and malware-analysis sandboxes. Three properties make AI-environment realism particularly relevant to sandbox evasion. First, ubiquity: AI tooling increasingly spans consumer, enterprise, and developer workflows, causing modern systems to accumulate artifacts from multiple AI subsystems. Second, persistence: artifacts such as model caches, runtime services, package dependencies, and AIspecific configuration directories survive reboots and remain observable long after active use has ended. Third, structural absence from sandboxes: malware-analysis environments are optimized for scalability and execution fidelity rather than reproducing genuine AI workflows, making convincing AI ecosystems operationally expensive to deploy and maintain. While all AI personas contribute to this ecosystem gap, local AI personas expose the richest and most externally observable artifact surface through installed runtimes, inference frameworks, GPU tooling, package managers, and evolving configuration state. Accordingly, this paper explores two motivating questions: Can AI-capable software ecosystems create observable differences between genuine endpoints and malware-analysis sandboxes? If so, do these
differences introduce a practical new surface for sandbox evasion and defensive adaptation?
2.3. Threat Model We model a malware sample executing as an unprivileged user-mode process on a Windows host. The adversary can invoke standard Win32 APIs accessible to normal user processes (e.g., PathFileExists, GetEnvironmentVariable, and connect) [27], [28], but has no kernel-mode access, administrator privileges, or ability to install additional software. We consider two adversarial objectives. Adversary A (AI-infrastructure reconnaissance) probes compromised hosts for locally accessible AI resources, including inference servers, exposed API credentials, GPU-enabled runtimes, or installed AI tooling that may support payload generation or post-compromise automation [9], [29]. Prior work has shown that environmental state itself can influence malware execution behavior [30]. Recent malware already demonstrates related behavior: earlier work documented GPU-presence checks in malicious documents [31], HONESTCUE invokes external Gemini APIs during execution, and Lumma Stealer checks for GPU presence prior to detonation [9], [10]. Adversary B (sandbox evasion) interprets the absence of persistent AI-environment artifacts as evidence of sandbox execution. Environments lacking indicators associated with AI-capable workflows—such as model caches, inference services, package dependencies, or AI-assistant directories (e.g., .claude/, .cursor/)— are treated as more likely to be analysis systems than genuine endpoints. Our evaluation focuses exclusively on Adversary B. Adversary A is included only to motivate the broader relevance of AI-environment artifacts in modern computing environments.
3. Methodology Overview Our methodology formalizes AI-environment realism as a measurable artifact surface and evaluates whether those artifacts systematically distinguish genuine AI-capable endpoints from malware-analysis sandboxes. Formally, let A = {a1 , a2 , . . . , an } denote the extracted AI-environment artifact set, where each artifact corresponds to a lightweight user-mode check (e.g., directory presence, environment variable, listening port, or installed package). Given an execution environment E , each probe evaluates an artifactpresence function f (ai , E) ∈ {0, 1} indicating whether artifact ai is observable within E . Our objective is to measure how artifact distributions differ across AI-capable endpoints and malware-analysis sandboxes, and to identify artifact subsets that exhibit strong cross-environment discrimination behavior. Our proposed workflow operates in four stages (Figure 1). Stage 1 (Extract) systematically harvests checkable
Stage 1: Extract
Stage 2: Probe
Stage 3: Evaluate
GitHub AI Projects
Clean Machine
284 repos
Parse Configs
Stage 4: Validate
Compile Probes Win EXE
Sandbox Backends
Collect & Compare
Reference Host
Cumulative AI Install
DNS exfil
Artifact Set
Classify
Growth Curve
450 unique §4.2
§5.1
§6
§6.3
Figure 1: End-to-end methodology. Stage 1: extract artifacts from 284 GitHub AI projects (§4.2). Stage 2: compile into unprivileged Win32 probes (§5.1). Stage 3: deploy to seven sandboxes and one reference host; classify artifacts into three discrimination classes (§6). Stage 4: validate causality via controlled installation on a separate clean machine (§6.3). RQ4 (defense evaluation) is addressed in §6.4.
artifacts from 284 GitHub AI projects by parsing configuration files and extracting persistent AI-environment indicators (§4.2). Stage 2 (Probe) compiles these artifacts into standalone, unprivileged Windows executables that perform artifact checks and report results via DNS-based exfiltration (§5.1–§5.2). Stage 3 (Evaluate) deploys probes across seven commercial and open-source sandbox backends and three reference hosts, then measures artifact discrimination behavior across sandbox and reference environments (RQ1– RQ2, §6.1–§6.2). Stage 4 (Validate) evaluates causality through controlled cumulative AI-software installation on a separate clean machine and assesses defensive spoofing strategies (RQ3–RQ4, §6.3, §6.4).
4. Artifact Corpus Construction 4.1. Artifact Taxonomy Prior sandbox-evasion research organizes checks by detection mechanism: VM artifacts probe hardware identity, timing checks measure execution speed, and wear-and-tear checks inspect accumulated usage [8], [19]. We adopt a complementary organization by artifact type, selecting categories that satisfy three criteria derived from the threat model (§2.3): (C1) low execution cost, (C2) no elevated privileges, and (C3) API behavior consistent with legitimate application startup behavior These criteria exclude, for example, WMI queries (which incur multi-second latency and may be monitored) and kernel-mode checks (which violate C2). We identify four artifact categories designed to satisfy all three criteria (Table 1). Their runtime and implementation characteristics are evaluated during the probing phase (§5.1. All four categories share a property that distinguishes them from prior evasion generations: the underlying APIs (PathFileExists, GetEnvironmentVariable, and connect) are routinely invoked during legitimate application startup and require no elevated privileges. In contrast, prior generations often relied on specialized instructions or monitoring-sensitive
operations, such as CPUID checks, RDTSC timing loops, or WMI queries [19].
4.2. GitHub Extraction Pipeline Rather than enumerating AI-environment artifacts manually, we construct the artifact corpus through an automated extraction pipeline that analyzes configuration files from real-world AI ecosystem projects hosted on GitHub. The pipeline preserves provenance by mapping each extracted artifact back to a specific repository and source file. Project Collection. We collect projects from two complementary GitHub sources. First, we crawl repositories associated with high-popularity AI-related topics (ai, llm, mcp), yielding 253 Windows-compatible projects after deduplication and filtering. Second, we collect 41 actively maintained projects from GitHub Trending using AI-focused keyword filtering. The combined dataset contains 284 unique projects and 4,576 extracted artifact checks. Throughout the paper, the Trending-41 dataset provides interpretable per-project analysis, while the larger Topics-253 dataset demonstrates extraction scalability. Artifact Extraction. For each project, we parse configuration-related files through GitHub’s raw content API, including README files, Python dependency manifests, and Docker configuration files. README files provide broad but weakly structured artifact coverage, while dependency manifests and Docker files expose authoritative package, environment-variable, directory, and port information. The extraction pipeline identifies artifact references, normalizes them into the taxonomy defined in §4.1, and preserves repository-level provenance for all extracted entries.
4.3. Artifact Filtering and Normalization Raw extraction yields 197 environment variables and 325 Python packages. We normalize the corpus through two filtering steps. First, we remove environment variables present in a stock Windows 11 installation (e.g., PATH,
TABLE 1: Artifact taxonomy. Counts shown are for the Trending-41 dataset; the Topics-253 dataset yields substantially larger artifact sets under the same extraction pipeline. Category
Representative Artifacts
Main Detection API
Representative Source Tools
Directories .claude, .cursor, .copilot, (19) .ollama, .cache/huggingface, .conda, .jupyter
PathFileExists() Claude [32], Cursor, Copilot, Ollama [24], HuggingFace [33]
Env. Vars (144)
OPENAI_API_KEY, ANTHROPIC_API_KEY, HF_TOKEN, OLLAMA_HOST, CUDA_PATH
GetEnvironmentVariable()
OpenAI [34], Anthropic [32], CUDA [35], Conda [36]
Ports (28)
11434 (Ollama), 1234 (LM Studio), 7860 (Gradio), 8888 (Jupyter)
socket() + connect()
Ollama [24], LM Studio [37], Gradio [38], Jupyter [39]
Packages (264)
torch, tensorflow, transformers, langchain, openai, chromadb
PathFileExists() PyTorch [40], on HuggingFace [41], site-packages/ LangChain [42]
TABLE 2: Top contributing Trending AI projects by artifact count (6 of 41 shown). Total 455 raw mappings across 41 projects; 450 unique after deduplication. Project
Dirs
Env
Ports
Pkgs
Total
vxcontrol/pentagi rowboatlabs/rowboat BerriAI/litellm ollama/ollama nvidia/cuda-toolkit anthropics/claude-code
3 1 0 1 1 1
62 16 12 3 2 2
9 5 3 1 0 0
46 29 22 2 2 1
120 51 37 7 5 4
Total (41 projects)
19
144
28
264
455
agreement for larger artifact sets. Because popular artifacts (e.g., .claude, OPENAI_API_KEY) appear across multiple projects, project-level scores should be interpreted as indicators of AI-ecosystem realism rather than precise evidence of individual project installation. Consequently, clustering serves as supporting evidence of environmentlevel AI capability, while our primary analysis focuses on artifact-level cross-environment discrimination behavior.
5. Probe Design and Measurement Infrastructure
HOME, COMPUTERNAME) to eliminate generic operatingsystem artifacts. Second, we exclude Python packages associated with general-purpose software development rather than AI/ML workflows (e.g., pytest, setuptools, wheel) using PyPI package metadata and classifier information. After filtering and cross-category deduplication, the final artifact corpus contains 450 unique artifact mappings across four categories: 19 directories, 144 environment variables, 28 network ports, and 264 Python packages. We intentionally preserve broad artifact coverage at this stage; subsequent evaluation identifies the subset that exhibits meaningful cross-environment discrimination behavior.
Having constructed the AI-environment artifact corpus (§4), we now describe AIprint, the measurement infrastructure that implements each artifact as a lightweight usermode check and collects results from constrained sandbox environments. Our design emphasizes low-privilege execution, minimal behavioral footprint, and compatibility with sandbox environments that restrict conventional outbound communication, while remaining consistent with the lowcost and user-mode design constraints defined in criteria C1–C3 (§4.1).
4.4. Artifact Clustering
We implement AIprint probes as standalone C++ Windows executables compiled with MSVC (Visual Studio 2022) in both 32-bit and 64-bit PE formats to maximize compatibility across heterogeneous sandbox environments. Each artifact corpus (Trending-41 and Topics-253) supports two execution modes: (1) project-level probes that compute aggregate artifact confidence scores and (2) single-artifact probes that report individual check outcomes. Each artifact category maps to a lightweight Win32 API operation. 1. Directory checks invoke PathFileExistsW() on expected AItool paths expanded from user-specific directories (e.g., %USERPROFILE%, %APPDATA%).
While individual artifact checks establish presence or absence, grouping artifacts by source project enables evaluation of whether a host exhibits a coherent AI ecosystem rather than isolated traces as shown in Appendix Algorithm B. For each project P , we compute a confidence score: |detected(P )| |total(P )| A project is considered “detected” if its confidence exceeds 15%, allowing small projects to trigger on a minimal number of matching artifacts while requiring broader
confidence(P ) =
5.1. Probe Architecture
Probe Tool
LZNT1 Compress
Hex Encode
Python Decoder
JSON Export
DNS Queries UDP
Check Results
Interactsh Server
Figure 2: DNS exfiltration pipeline. The probe compresses results, hex-encodes them into DNS subdomain labels, and transmits via UDP; an offline decoder reassembles the payload.
2. Environment-variable checks invoke GetEnvironmentVariableW() and test only for variable presence without inspecting contents. 3. Port checks attempt local TCP connections against expected inference-service ports. 4. Python-package checks verify package presence within detected site-packages/ directories. All checks execute entirely in user mode without requiring administrator privileges or UAC prompts, maintain lightweight execution behavior, and closely resemble legitimate application startup activity, thereby satisfying criteria C1–C3. Because commercial sandboxes frequently cache binaries by cryptographic hash, we generate multiple functionally equivalent probe variants through non-semantic PE modifications to ensure independent analysis across repeated submissions. Probe outputs are serialized into a compact structured format containing artifact identifiers, categories, and check outcomes before being forwarded through the DNS exfiltration pipeline described in §5.2.
5.2. DNS Exfiltration Commercial sandbox environments commonly restrict conventional outbound communication channels such as HTTP [43]. To ensure reliable result collection across heterogeneous backends, our measurement pipeline uses DNSbased exfiltration, leveraging the fact that sandbox environments typically permit DNS resolution for normal network operation. DNS exfiltration is a well-established technique documented in MITRE ATT&CK (T1048) [44], [45]. Figure 2 illustrates the pipeline. AIprint probe outputs are compressed using Windows’ native LZNT1 compression routines, encoded into DNS-compatible subdomain labels, and transmitted to an Interactsh [46] collection server through a sequence of DNS queries. An offline decoder reconstructs and decompresses the transmitted payload to recover structured probe results. Each execution session is associated with a unique identifier to support reliable reassembly across multi-query transmissions. Full protocol details are provided in Appendix C.
5.3. Sandbox Execution Pipeline We deploy probes across seven sandbox platforms spanning commercial, open-source, interactive, and multibackend malware-analysis infrastructures (Table 3). These
TABLE 3: Sandbox platforms used in the measurement pipeline. All platforms accept PE executables through public submission interfaces and execute AIprint probes within Windows guest environments. Platform
Type
Guest OS
Backends
ANY.RUN [47] Commercial Win 10 (x64) 1 CAPEv2 [48] Open-source Win 10 (x64) 1 Cuckoo [49] Open-source Unknown 2 Hybrid Analysis [50] Commercial Win 10 (x64) 1 Kaspersky [51] Commercial Unknown 1 Triage [52] Commercial Win 10 (x64) 2 VirusTotal [53] Multi-engine Various 7
platforms collectively represent the dominant deployment models used in automated malware analysis, including analyst-oriented triage services, enterprise threatintelligence systems, and open-source COTS deployments. Probe Variants. We execute five probe variants across all platforms and three reference AI-capable hosts: (Variant 1) a traditional sandbox-evasion baseline (SOTA) composed of 269 checks from prior anti-analysis frameworks, including al-khaser [12], pafish, VMDE, sems, and CheckPlease. (Variant 2) Topics-253 project-level probes, (Variant 3) Topics-253 single-artifact probes (4,150 individual artifact checks). (Variant 4) Trending-41 project-level probes, and (Variant 5) Trending-41 single-artifact probes (450 individual artifact checks). VirusTotal is architecturally distinct because submissions may be routed to multiple independent backend sandboxes executing different guest images. Accordingly, we treat VirusTotal backends as separate analysis environments throughout the evaluation. Reference AI-Capable Hosts. For comparison, we execute identical probes on three Windows 11 AI-capable reference hosts representing distinct local AI environment profiles. The hosts share the same hardware configuration (a 24-core (13th Gen Intel Core i9-13900KF) CPU, 64 GB memory, and an NVIDIA GeForce RTX 4090 GPU (24 GB VRAM)) but differ in their installed AI-tool ecosystems and resulting artifact density. They serve as proof-of-concept reference environments for AI-capable endpoints rather than as a population baseline (§7). Each probe variant is executed once per reference host and submitted once per sandbox backend, yielding a point-in-time measurement snapshot (February 2026).
6. Evaluation Our evaluation investigates whether AI-environment artifacts introduce observable differences between contemporary malware-analysis sandboxes and AI-capable endpoints, and whether that gap can be exploited or mitigated in practice. We structure the evaluation around four research questions: • RQ1: Do artifacts associated with the local AI persona expose a measurable realism gap between real-world AI-
capable systems and contemporary sandbox infrastructures? • RQ2: Which classes of AI-environment artifacts contribute most strongly to cross-environment discrimination? • RQ3: Do observed artifact differences arise causally from the installation and accumulation of AI software ecosystems? • RQ4: Can these AI-environment artifacts be reliably mitigated through defensive spoofing or synthetic AIenvironment provisioning? For each research question, we analyze results produced by our end-to-end measurement pipeline and discuss their implications for AI-environment-aware evasion.
6.1. RQ1: Do AIprints Discriminate Where Traditional VM Checks Fail? To determine whether AI-environment artifacts expose measurable distinction between genuine endpoints and sandbox environments, we first establish a baseline using AIprint probe Variant 1. Table 4 shows that traditional VM checks produce uniformly low trigger rates across all environments (1.9–7.6%). The reference hosts exhibit trigger rates ranging from 7.4%–9.9% (avg. 9.1%), providing only weak and inconsistent host-versus-sandbox discrimination. Many triggered indicators correspond to Hyper-V features enabled by default in modern Windows 11 systems, illustrating how traditional VM-detection fingerprints have become increasingly noisy and weakly discriminative in contemporary environments. In contrast, AIprints produce substantially clearer distinction at both the individual-artifact and project levels. Using the Trending-41 corpus, the reference hosts exhibit higher individual-artifact detection rates than every evaluated sandbox backend, while project-level clustering identifies substantially stronger AI-environment signals on the hosts than on six of the seven sandbox platforms (Table 5). These results indicate that AI-environment artifacts expose measurable environmental differences that remain observable across diverse contemporary sandbox infrastructures. TABLE 4: AIprint probe Variant 1 – SOTA baseline: 269 checks from 6 evasion projects. Environment
Triggered / 269
Rate
ANY.RUN Kaspersky Cuckoo (v1) Triage (v0) 1 Triage (v1) Hybrid Analysis CAPEv2 VirusTotal Cuckoo (v0)
5 8 8 11 11 12 15 8–19 21
1.9% 3.0% 3.0% 4.1% 4.1% 4.4% 5.5% 3.0%–7.0% 7.6%
Reference Hosts
avg. 24.6
avg. 9.1%s
6.1.1. Baseline Choice. We compare against traditional VM detection rather than wear-and-tear fingerprinting [8] because reproducing the latter would require a large-scale multi-user endpoint study beyond the scope of this work. AIenvironment artifacts are conceptually orthogonal to wearand-tear realism and could potentially complement existing realism-based classifiers. Summary: Traditional VM-detection checks produce uniformly low and weakly discriminative trigger rates across both sandbox and real environments. In contrast, AI-environment artifacts expose substantially stronger separation between contemporary malware-analysis sandboxes and AI-capable endpoints at both the individual-artifact and project levels.
6.2. RQ2: Which Artifacts Discriminate? Having established that AI-environment artifacts expose a measurable distinction, we now identify which artifacts contribute to cross-environment discrimination and whether those artifacts appear consistently across sandbox backends. As shown in Table 5, the reference AI-capable hosts consistently exhibit substantially higher project-level and individual-artifact detection rates than the evaluated sandbox backends, indicating that contemporary malware-analysis environments contain markedly sparser AI-environment footprints than real-world AI-capable systems. Detection rates also vary across the reference hosts themselves, reflecting differences in installed AI-tool ecosystems and resulting artifact density. 6.2.1. Cross-Sandbox Detection Rates. We observe that detection rates vary sharply across the sandbox backends. Five of seven sandbox platforms detect ≤7.3% of Trending41 projects, while one VirusTotal backend instance reaches 26.8%, illustrating substantial cross-backend heterogeneity. Hybrid Analysis exhibits an elevated project-level rate (29.6%) due to the presence of generic Python ecosystem artifacts that inflate clustering scores despite the absence of AI-specific tooling. Consistent with this interpretation, Hybrid Analysis triggers only 0.34% of individual artifact checks. 6.2.2. Three Artifact Classes. Of the 4,150 individual artifacts probed, only 27 triggered in all evaluated environments. We partition these artifacts into three disjoint classes based on their cross-environment behavior (Table 6). Class C forms the primary discriminating surface: twelve artifacts appear exclusively on the reference AI-capable hosts and are absent from every evaluated sandbox backend. These artifacts are uniformly AI-specific and include AI-assistant directories (.cursor, .claude, .copilot, .gemini), the HuggingFace model cache, the OPENAI_API_KEY environment variable, Ollama’s local inference port 11434, and additional AI-runtime configuration directories. 1. VMDE dynamically adds 1–7 entries when it detects VM artifacts; actual counts range 269–276. Rates are computed against the 269 base checks for consistency across all environments.
TABLE 5: AIprint detection across all evaluated environments. Six of seven sandbox platforms detect ≤7.3% of Trending-41 projects, while the reference AI-capable hosts consistently exhibit the highest project-level and individual-artifact detection rates. “—” denotes data not collected. Topics 253
Trending 41
Environment
Projects
Single
Projects
Single
ANY.RUN Kaspersky Triage Cuckoo CAPEv2 Hybrid Analysis VirusTotal (range)
0.4% 0.4% 0.4% 0.1% 11.5% 29.6% 0.4–11.9%
0.05% 0.05% 0.05% 0.07% 0.07% 0.34% 0.05–0.36%
0.0% 0.0% 0.0% 2.4% 7.3% 0.0% 0.0–26.8%
0.0% 0.0% 0.0% 0.2% 0.2% 1.3% 0.0–1.3%
33.2% 53.0% 45.1%
0.41% 2.4% 0.9%
46.3% 56.1% 34.1%
1.8% 10.0% 3.3%
+3.6–52.9%
+0.05–2.35%
+7.3–56.1%
+0.5–10.0%
Real Host 1 Real Host 2 Real Host 3 Discrimination Gap TABLE 6: Derived artifact classes.
tinction, with Ollama (11434) and Jupyter (8888) services observed only on the reference hosts. Environment variClass Count Composition ables produce mixed signal: AI-specific credentials such A: Sandbox-resident 10 Generic Python pkgs (Hybrid only) as OPENAI_API_KEY are host-exclusive, whereas generic B: Shared 5 OS env vars (PATH, HOMEPATH) variables (e.g., PATH) appear across all environments. C: Host-exclusive 12 AI IDE dirs, ML caches, Python packages discriminate least strongly because some API keys, LLM ports sandbox images ship generic Python ecosystems that partially overlap with AI-oriented dependency stacks. AddiTABLE 7: Class C artifacts exhibiting strong host-versus-sandbox tional project-level clustering results, threshold-sensitivity separation. analysis, and VirusTotal backend heterogeneity measureCategory Artifact Source Tool ments are provided in Appendix D. These additional experiments reproduce the same asymmetry observed in the main AI IDE Config ˜/.cursor Cursor AI results: AI-capable reference environments consistently exAI IDE Config ˜/.claude Claude Code hibit substantially richer AI-environment artifact presence AI IDE Config ˜/.copilot GitHub Copilot than contemporary sandbox backends. AI IDE Config ˜/.gemini Gemini CLI ML Cache LLM Data Python Env Notebooks GPU Runtime API Key Local LLM Notebooks
.cache/huggingface ˜/.ollama ˜/.conda ˜/.jupyter CUDA_PATH dir OPENAI_API_KEY Port 11434 Port 8888
HuggingFace Hub Ollama Anaconda Jupyter NVIDIA CUDA OpenAI SDK Ollama server Jupyter server
Summary: Twelve Class C artifacts appear on the reference AI-capable hosts only, creating a strong host-versus-sandbox distinction at the individual-artifact level. Because these artifacts span multiple independent AI-environment layers, defenders must reproduce a realistic AI software ecosystem rather than merely scrub isolated indicators.
6.3. RQ3: Causal Validation via Controlled Experiment 6.2.3. Discriminating Artifacts. Table 7 lists all twelve Class C artifacts observed exclusively on the reference AIcapable hosts and absent from every evaluated sandbox backend. We noted that the Class C set spans multiple independent layers of the local AI ecosystem, including AI assistants, local inference runtimes, model caches, GPU tooling, notebook infrastructure, and API credentials, suggesting that the observed distinction is ecosystem-level rather than tied to any single tool category. 6.2.4. Per-Category Analysis. Artifact discrimination varies substantially across categories. Directories provide the strongest separation: nine AI-specific directories appear on the reference AI-capable hosts and none on any evaluated sandbox backend. Ports also exhibit strong dis-
RQ2 identifies the AI-environment artifacts that discriminate between real hosts and sandbox environments; RQ3 investigates whether those artifacts arise causally from AI tools and package installation rather than incidental system configuration. To isolate causality, we perform a controlled cumulative installation experiment on a separate clean Windows 11 machine, progressively constructing a local AI ecosystem while repeatedly measuring the resulting artifact surface. The experiment proceeds in two phases. Phase A installs a curated set of anchor AI tools one at a time to establish direct causal linkage between specific software packages and the resulting artifact observations. Phase B performs large-scale automated package installation to evaluate how the measurable AI-environment surface expands as
Detection Rate (%)
5 +1.0
4 3 2
T_253 single-check T_41 single-check SOTA VM-detection (control)
+1.5
+0.5
1 0
T00 Baseline
T01 Ollama
T02 Cursor
T02c Gemini
T02b Claude
T03 HF Hub
T04 PyTorch
Cumulative Tool Installation
T05 LangChain
T06 Jupyter
T07 Copilot
Figure 3: Phase A: AIprint detection vs. anchor tool installation (10 steps). Topics-253 (solid) rises from 0.6% to 3.9%. SOTA (dashed) stays flat at ∼5.1%. The full 214-step trajectory is shown in Figure 4.
local tools and package dependencies accumulate. Across all installation steps, we execute the full probe suite together with the traditional VM-detection baseline, which serves as a negative control throughout the experiment. TABLE 8: Phase A cumulative installation sequence. The installed tools collectively span multiple layers of the local AI dependency stack. Step
Tool Installed
T01 T02 T02b T02c T03 T04 T05
Ollama (port 11434, .ollama/) Cursor IDE (.cursor/) Claude Code (.claude/) Gemini CLI (.gemini/) HuggingFace (.cache/huggingface/) PyTorch (torch) LangChain + OpenAI + Anthropic SDKs + OPENAI_API_KEY env var Jupyter (.jupyter/, port 8888) VSCode + GitHub Copilot (.copilot/)
T06 T07
6.3.1. Phase A Anchor AI Tools Installation. Figure 3 and Table 16 in Appendix D.2 show that AIprint detection rises monotonically as the local AI dependencies accumulate. Starting from a clean baseline, the system initially exhibits detection behavior comparable to sandbox environments, with no Class C artifacts present: Topics-253 passes 23 artifacts (0.6%), Trending-41 passes 3 artifacts (0.7%), and SOTA detects 14 VM indicators (5.1%). The baseline Topics-253 rate (0.6%) differs slightly from the reference workstation’s 0.41% (Table 5) because the two environments have different Windows configurations; the discrepancy arises from generic Class B artifacts rather than AI-specific tooling, as both machines contain zero Class C artifacts at baseline. Each successive installation step expands the measurable AI-environment surface, increasing both project-level and individual-artifact detection rates, while the traditional VM-detection baseline remains largely unchanged throughout the experiment. Dependencies Expansion Effects. Lightweight AI-assistant tools contribute relatively few new artifacts: Ollama (T01) adds +2 and Cursor (T02) adds +3. Claude Code (T02b) and
Gemini CLI (T02c) each produce ∆=0 because .claude/ and .gemini/ appear in the Trending-41 corpus but not in the earlier Topics-253 crawl; both remain confirmed Class C artifacts on the reference host (§6.2). In contrast, Python-based AI packages produce the largest expansion of the measurable artifact surface. LangChain/OpenAI SDK installation (T05) contributes +59 artifacts through transitive dependencies (e.g. pydantic, tiktoken, aiohttp), while Jupyter (T06) adds +42 and HuggingFace (T03) adds +21. These results suggest that application and package dependencies contribute more strongly to detectable AIenvironment artifacts than the primary executable alone. Why Trending-41 Single-Check Detection Plateaus. The Trending-41 single-check rate plateaus at 1.1% after T02, whereas Topics-253 continues rising from 0.7% to 3.9%. This difference reflects corpus composition rather than installation saturation. The curated Trending-41 dataset contains only 450 checks and is dominated by directories, ports, and environment variables, whereas the larger Topics-253 corpus (4,150 checks) contains substantially more Pythonpackage artifacts. Consequently, package-heavy installations from T03 onward primarily expand the Topics-253 detection surface. Traditional VM Detection Remains Largely Stable. The traditional VM-detection baseline remains nearly unchanged throughout the experiment, holding at 14/273 indicators (5.1%) through T01–T05 and increasing only slightly to 15/273 (5.5%) after Jupyter installation (T06). The additional indicator likely arises from Jupyter’s local network listener triggering a heuristic associated with VM-related services. Although minor (+0.4%), this effect suggests that AI package installation can indirectly influence traditional anti-analysis heuristics. 6.3.2. Phase B: Extended Package Installation. Phase A established direct causal linkage for 10 anchor AI tools. Phase B extends this process through large-scale package accumulation: 199 automated package-installation attempts via pip, followed by 5 manual installations requiring Docker or specialized tooling. Figure 4 shows the complete 214step trajectory. Topics-253 single-check detection rises from 3.9% at the end of Phase A to 15.3% after bulk installation and reaches 17.8% following retries and manual installs— a nearly 30× increase over the 0.6% clean baseline. The resulting growth curve exhibits a staircase pattern: successful installations introduce bursts of transitive dependencies, followed by temporary plateaus until additional packages are installed. Of the 199 pip-install attempts, 100 succeed (50.3%); many failures arise because GitHub repository names do not always map directly to installable pip package names. The final artifact distribution shows that Python packages dominate the measurable AI-environment surface. Of 735 passing artifact checks (17.8% of the 4,126 installable artifacts derived from the original 4,150 crawled artifacts), 719 are Python packages, compared to only 7 directories, 4 environment variables, and 5 open ports. This imbalance arises because individual package installations recursively introduce large transitive dependencies that ap-
15.0 12.5
both the clean baseline and the genuine AI-tool installation state constructed in RQ3.
10.0
TABLE 9: Cumulative defense levels for artifact spoofing.
7.5 5.0
Features regression
2.5
Lv. Action
Cost
Example
L1 L2 L3 L4 L5
Trivial Trivial Low Moderate High
.claude/, .ollama/ OPENAI_API_KEY=sk-... Ports 11434, 8888 torch, langchain Model files, config JSONs
1.8% 13
00
T_2
T_2
80 T_1
60
40
T_1
Cumulative Installation Step
T_1
20 T_1
00 T_1
0 T_8
0 T_6
0 T_4
0 T_2
T_0
0
0.0
Figure 4: Full growth trajectory across 214 installation steps.
pear across many projects’ artifact sets. At the project level, the final installation state detects 184/253 Topics projects (72.7%) and 30/41 Trending projects (73.2%). In contrast, the traditional VM-detection baseline remains effectively unchanged throughout all 214 installation steps, fluctuating only between 5.1% and 5.5%. This persistent stability reinforces that traditional VM indicators and AI-environment artifacts capture fundamentally different environmental properties.
6.4. RQ4: Defense Evaluation via Artifact Spoofing In RQ4, we evaluate whether analysts can realistically reduce the observed host-versus-sandbox asymmetry through artifact spoofing. We study two questions: (1) whether progressively richer spoofing strategies can mitigate AI environment detection, and (2) whether an adaptive attacker can distinguish spoofed environments from genuine AI-capable environments. Spoofing Setup. Using the same clean Windows 11 baseline and probe infrastructure from RQ3, we evaluate two cumulative spoofing strategies with progressively richer spoofing behavior (Table 9). Class-C (minimal spoofing): spoofs the 8 most commonly referenced Class-C artifacts—6 directories (.cursor, .claude, .copilot, .gemini, .cache/huggingface, .ollama), 1 environment variable (OPENAI_API_KEY), and 1 port (11434). We excluded four less consistently discriminative Class-C artifacts (.conda, .jupyter, CUDA_PATH directory, port 8888) from the minimal strategy because they have lower crossproject reference frequency and are more likely to appear on non-AI hosts. Full-Coverage Spoofing: spoofs every perproject check instance that failed the baseline scan—69 directory checks (from 19 unique paths), 1,362 environment variable checks (from 144 unique variables), 143 port checks (from 28 unique ports), and 46 Python package checks. The counts exceed unique artifact counts because the same artifact (e.g., OPENAI_API_KEY) appears in multiple projects’ check lists; spoofing one unique variable satisfies all projectlevel references. After each spoofing level, we execute the full probe suite and compare spoofed environments against
Strategy: ClassC (8 discriminators)
T253 single T41 single SOTA VM
T253 single T41 single SOTA VM
40 30 20 10 0
Summary: AIprint detection is causally tied to AI tools and package installation: a clean machine begins at sandboxequivalent levels (0.6%) and rises monotonically to 17.8% across 214 installation steps, while the traditional VMdetection baseline remains nearly unchanged (∼5.1%). Many detectable artifacts emerge from transitive dependencies introduced by the primary tools.
Create empty dirs + Set env vars + Open ports + Install packages + Populate data
Strategy: All (full coverage) 50
Detection Rate (%)
Detection Rate (%)
17.8%
T_253 single-check T_41 single-check SOTA VM-detection (control)
17.5
Baseline
L1
L2
L3
Defense Level
L4
L5
Baseline
L1
L2
L3
Defense Level
L4
L5
Figure 5: Detection under progressive spoofing: full-coverage defenses plateau at L3, lightweight Class-C spoofing remains near baseline, and traditional VM-detection rates stay unchanged throughout. TABLE 10: Probe detection under All defense (every failing artifact spoofed). Detection plateaus at L3. T253
T41
SOTA
Level
Single
Proj
Single
Proj
VM
Baseline L1 (dirs) L2 (+env) L3 (+port) L4–L5
0.6% 6.1% 36.4% 39.6% 39.6%
82 132 202 231 231
0.7% 3.8% 35.8% 41.8% 41.8%
12 19 28 33 33
5.1% 5.1% 5.1% 5.1% 5.1%
6.4.1. Defender Results. Tables 10 quantify detection behavior under progressively richer spoofing strategies. Shallow spoofing improves project-level detection substantially but exhibits diminishing returns. Under the All strategy, environment-variable spoofing (L2) produces the largest increase, raising Topics-253 detection from 6.1% to 36.4% because many project-level checks reference shared variables. In contrast, lightweight Class-C spoofing as shown in Table 19 in Appendix E.1 yields only modest gains because it introduces comparatively few AI-environment artifacts. As shown in Figure 5, both strategies reach ∼40% at L3 and subsequently plateau. Attempts to extend spoofing through user-space Python-package installation provide no measurable additional benefit because package placement and runtime structure remain inconsistent with genuine AItool installations. These results suggest that reproducing realistic AI-environment structure requires more than creating superficial artifacts: it demands coherent AI software ecosystems with consistent dependency structure, runtime behavior, and filesystem layout.
6.4.2. Adaptive Attacker Response. We next evaluate whether an adaptive attacker can distinguish spoofed artifacts from genuine installations through lightweight structural validation. For each spoofing level, we implement consistency checks that inspect expected filesystem structure, credential formatting, protocol behavior, package coherence, and cache realism. Across all defense levels, structural validation correctly identifies 4 of 5 tested artifacts as spoofed or incomplete as shown in Appendix E.2 Table 20. The only exception, .claude/, remained an installation artifact from the earlier RQ3 environment and therefore represents a conservative evaluation artifact rather than a spoofing success. Collectively, these results indicate that shallow artifact spoofing can inflate detection metrics, but reproducing structurally consistent AI ecosystems remains operationally expensive.
6.4.3. Operational Cost Asymmetry. Beyond detection effectiveness, spoofing introduces an asymmetric operational burden. Table 11 compares the defender effort required to reproduce realistic AI-environment artifacts against the lightweight structural checks required for attacker-side validation. Effort Level in Table 11 approximates the lines of code required for lightweight structural checks that distinguish spoofed artifacts from genuine installations. For example, at L1, an attacker only needs ∼5 lines of code to detect a non-empty directory, which can be executed in under 3 seconds. Other levels may require slightly more code and more involved checks (e.g., artifacts like models or JSON files in L5), but all remain substantially cheaper than reproducing the corresponding AI-environment artifacts. These results expose a structural asymmetry in fourth-generation sandbox evasion: attackers validate realism through lightweight consistency checks, while defenders must reproduce and maintain increasingly coherent AI software ecosystems. The cost of simulation, therefore, grows substantially faster than the cost of detection. TABLE 11: Cost asymmetry for Class-C defense. Level
Setup (sec)
Effort Level (LoC)
Artifact Check
L1 L2 L3 L4 L5
<3 <2 <6 0 ∼180
5 3 8 0 15
Dir non-empty Key prefix format HTTP req + JSON Import + version Timestamps, content
Summary: Artifact spoofing exhibits a fundamental cost asymmetry: validating AI-environment realism requires only lightweight structural checks, whereas reproducing convincing AI ecosystems demands coherent runtimes, dependencies, services, and ongoing ecosystem maintenance. As a result, reproducing realistic AI environments becomes operationally more expensive than detecting shallow spoofing.
7. Discussion Our evaluation results for RQ1–RQ4 suggest that AIcapable software ecosystems introduce a new realism gap for sandboxed execution environments. Defense Implications. RQ4 in particular exposes a fundamental operational asymmetry: validating AI-environment realism requires only lightweight structural checks, whereas reproducing convincing AI ecosystems demands increasingly complex and continuously maintained software stacks. Even aggressive spoofing strategies remain distinguishable from genuine installations due to inconsistencies across artifacts, runtimes, and dependency state. This burden is amplified in heterogeneous multi-backend infrastructures such as VirusTotal, where inconsistent provisioning across backends itself becomes a fingerprinting signal. These findings motivate future research on AI-aware sandbox environments that more closely reflect real-world AI ecosystems. Stealth of Probing. The underlying checks rely exclusively on common Win32 APIs such as PathFileExists(), GetEnvironmentVariable(), and connect(), all of which are routinely invoked by legitimate applications during startup. Consequently, detecting AIprint-style probing behaviorally may prove difficult without introducing substantial false positives, though we leave empirical measurement of such rates to future work. Limitations. Our study has several limitations. First, the proposed AI-based evasion is inherently targeted: non-AIcapable hosts may remain indistinguishable from sandboxes under these checks alone. Second, our evaluation compares sandbox backends against a limited number of reference systems. Third, the extracted artifact set represents a snapshot of the rapidly evolving AI ecosystem as of February 2026. Finally, while recent malware already probes GPUs and AI APIs [9], [10], [31], we do not claim confirmed in-thewild adoption of the specific AIprint probes studied here. Future work includes large-scale prevalence measurement across real endpoints, cross-platform evaluation on Linux and macOS, longitudinal tracking of sandbox adaptation, and hybrid classifiers that combine AIprint artifacts with traditional wear-and-tear features.
8. Conclusion We presented the first systematic measurement study of AI-environment artifacts as a new sandbox-evasion surface. Through artifact extraction from 284 GitHub AI projects, cross-sandbox evaluation across seven backends, controlled causal validation, and adaptive spoofing analysis, our results show that AIprints discriminate where traditional VMdetection baselines fail. Moreover, reproducing convincing AI ecosystems proves substantially more expensive than detecting shallow spoofing, creating a fundamental operational asymmetry for sandbox operators. More broadly, our findings suggest that sandbox realism is increasingly shaped not only by hardware fidelity or simulated user activity, but also by the software ecosystems installed on the host.
As AI-capable environments continue to proliferate across developer and enterprise systems, maintaining realistic AIenvironment fidelity may become an increasingly important challenge for future malware-analysis infrastructure.
References [1]
C. Willems, T. Holz, and F. Freiling, “Toward automated dynamic malware analysis using cwsandbox,” IEEE security & privacy, vol. 5, no. 2, pp. 32–39, 2007.
[2]
M. Egele, T. Scholte, E. Kirda, and C. Kruegel, “A survey on automated dynamic malware-analysis techniques and tools,” ACM computing surveys (CSUR), vol. 44, no. 2, pp. 1–42, 2008.
[3]
T. Petsas, G. Voyatzis, E. Athanasopoulos, M. Polychronakis, and S. Ioannidis, “Rage against the virtual machine: hindering dynamic analysis of android malware,” in Proceedings of the seventh european workshop on system security, 2014, pp. 1–6.
[18] F. Gorter, C. Giuffrida, and E. Van Der Kouwe, “Enviral: Fuzzing the environment for evasive malware analysis,” in Proceedings of the 16th European Workshop on System Security, 2023, pp. 8–14. [19] A. Yokoyama, K. Ishii, R. Tanabe, Y. Papa, K. Yoshioka, T. Matsumoto, T. Kasama, D. Inoue, M. Brengel, M. Backes et al., “Sandprint: Fingerprinting malware sandboxes to provide intelligence for sandbox evasion,” in International Symposium on Research in Attacks, Intrusions, and Defenses. Springer, 2016, pp. 165–187. [20] J. Blackthorne, A. Bulazel, A. Fasano, P. Biernat, and B. Yener, “{AVLeak}: fingerprinting antivirus emulators through {Black-Box} testing,” in 10th USENIX Workshop on Offensive Technologies (WOOT 16), 2016. [21] D. Maier, T. Müller, and M. Protsenko, “Divide-and-conquer: Why android malware cannot be stopped,” in 2014 Ninth International Conference on Availability, Reliability and Security. IEEE, 2014, pp. 30–39. [22] J. Oberheide and C. Miller, “Dissecting the android bouncer,” SummerCon2012, New York, vol. 95, p. 110, 2012.
[4]
T. Klein, “ScoopyNG – the VMware detection tool,” http://www. trapkit.de/tools/scoopyng/index.html, 2008.
[23] PyPI Stats, “Download statistics for PyTorch (torch),” https:// pypistats.org/packages/torch, 2026, accessed May 2026.
[5]
T. Vidas and N. Christin, “Evading android runtime analysis via sandbox detection,” in Proceedings of the 9th ACM symposium on Information, computer and communications security, 2014, pp. 447– 458.
[24] Ollama, “Ollama,” https://ollama.com/, 2024, accessed: Dec. 1, 2025.
M. G. Kang, H. Yin, S. Hanna, S. McCamant, and D. Song, “Emulating emulation-resistant malware,” in Proceedings of the 1st ACM workshop on Virtual machine security, 2009, pp. 11–22.
[26] GitHub, “GitHub Copilot,” https://github.com/features/copilot, 2026.
[6]
[7]
Y. Bulygin and D. Samyde, “Chipset based approach to detect virtualization malware aka deepwatch,” Blackhat USA, 2008.
[8]
N. Miramirkhani, M. P. Appini, N. Nikiforakis, and M. Polychronakis, “Spotless sandboxes: Evading malware analysis systems using wearand-tear artifacts,” in 2017 IEEE Symposium on Security and Privacy (SP). IEEE, 2017, pp. 1009–1024.
[9]
Google Threat Intelligence Group, “HONESTCUE: Distillation, experimentation, and integration of AI in adversarial use,” https://cloud.google.com/blog/topics/threat-intelligence/ distillation-experimentation-integration-ai-adversarial-use, Sep. 2025, accessed: Feb. 1, 2026.
[10] B. Tancio, F. Cureg, and J. Samaniego, “Lumma stealer’s GitHub-based delivery explored via managed detection and response,” https://www.trendmicro.com/en us/research/25/a/ lumma-stealers-github-based-delivery-via-mdr.html, Jan. 2025, accessed: Jan. 1, 2026. [11] A. Afianian, S. Niksefat, B. Sadeghiyan, and D. Baptiste, “Malware dynamic analysis evasion techniques: A survey,” ACM Computing Surveys (CSUR), vol. 52, no. 6, pp. 1–28, 2019. [12] “al-khaser: Public malware techniques used in the wild,” https: //github.com/LordNoteworthy/al-khaser, accessed: 2026-02-01. [13] C. Kruegel, “Full system emulation: Achieving successful automated dynamic analysis of evasive malware,” in Proc. BlackHat USA Security Conference, 2014, pp. 1–7.
[25] JetBrains, “Developer ecosystem 2025,” https://devecosystem-2025. jetbrains.com/artificial-intelligence, 2025. [27] Microsoft, “Pathfileexistsa function (shlwapi.h),” //learn.microsoft.com/en-us/windows/win32/api/shlwapi/ nf-shlwapi-pathfileexistsa, 2026.
https:
[28] ——, “Getenvironmentvariablea function (processenv.h),” https://learn.microsoft.com/en-us/windows/win32/api/processenv/ nf-processenv-getenvironmentvariablea, 2026. [29] Google Threat Intelligence Group, “GTIG AI threat tracker: Advances in threat actor usage of AI tools,” https://cloud.google.com/blog/ topics/threat-intelligence/threat-actor-usage-of-ai-tools, Nov. 2025, accessed: Jan. 10, 2026. [30] C. Kolbitsch, E. Kirda, and C. Kruegel, “The power of procrastination: detection and mitigation of execution-stalling malicious code,” in Proceedings of the 18th ACM Conference on Computer and Communications Security, ser. CCS ’11. New York, NY, USA: Association for Computing Machinery, 2011, p. 285–296. [Online]. Available: https://doi.org/10.1145/2046707.2046740 [31] D. Desai, “Malicious documents leveraging new anti-VM & anti-sandbox techniques,” https://www.zscaler.com/blogs/security-research/ malicious-documents-leveraging-new-anti-vm-anti-sandbox-techniques, 2016. [32] Anthropic, “Claude,” https://www.anthropic.com/claude, 2024. [33] “huggingface,” https://huggingface.co/, 2024, model repository and transformers library. [34] OpenAI, “OpenAI API documentation,” https://platform.openai.com/ docs/, 2024.
[14] A. Moser, C. Kruegel, and E. Kirda, “Exploring multiple execution paths for malware analysis,” in 2007 IEEE Symposium on Security and Privacy (SP’07). IEEE, 2007, pp. 231–245.
[35] NVIDIA, “CUDA Toolkit documentation,” https://docs.nvidia.com/ cuda/, 2024, gPU computing toolkit for AI/ML workloads.
[15] D. Kirat, G. Vigna, and C. Kruegel, “{BareCloud}: Bare-metal analysis-based evasive malware detection,” in 23rd USENIX Security Symposium (USENIX Security 14), 2014, pp. 287–301.
[37] “Lm studio,” https://lmstudio.ai/, 2026.
[16] M. Lindorfer, C. Kolbitsch, and P. Milani Comparetti, “Detecting environment-sensitive malware,” in International Workshop on Recent Advances in Intrusion Detection. Springer, 2011, pp. 338–357. [17] D. Balzarotti, M. Cova, C. Karlberger, E. Kirda, C. Kruegel, and G. Vigna, “Efficient detection of split personalities in malware.” in NDSS, 2010.
[36] “Anaconda distribution,” https://www.anaconda.com/, 2024. [38] “Gradio,” https://www.gradio.app/, 2026. [39] “Jupyter,” https://jupyter.org/, 2024. [40] A. Paszke, S. Gross, F. Massa, A. Lerer, J. Bradbury, G. Chanan, T. Killeen, Z. Lin, N. Gimelshein, L. Antiga et al., “Pytorch: An imperative style, high-performance deep learning library,” Advances in neural information processing systems, vol. 32, 2019.
[41] T. Wolf, L. Debut, V. Sanh, J. Chaumond, C. Delangue, A. Moi, P. Cistac, T. Rault, R. Louf, M. Funtowicz et al., “Transformers: Stateof-the-art natural language processing,” in Proceedings of the 2020 conference on empirical methods in natural language processing: system demonstrations, 2020, pp. 38–45. [42] “LangChain,” https://www.langchain.com/, 2024, lLM application framework. [43] G. Sharabi and Y. Khalaf, “Malware analysis on AWS: Setting up a secure environment,” https://aws.amazon.com/blogs/security/ malware-analysis-on-aws-setting-up-a-secure-environment/, 2024, accessed: Feb. 10, 2026. [44] MITRE ATT&CK, “Exfiltration over alternative protocol: Exfiltration over asymmetric encrypted non-c2 protocol,” https://attack.mitre.org/ techniques/T1048/002/, 2020, accessed: 2026-02-01. [45] A. Nadler, A. Aminov, and A. Shabtai, “Detection of malicious and low throughput data exfiltration over the dns protocol,” Computers & Security, vol. 80, pp. 36–53, 2019. [46] “An oob interaction gathering server and client library,” https://github. com/projectdiscovery/interactsh, accessed: 2026-02-01. [47] “ANY.RUN: Interactive malware analysis,” https://any.run/, accessed: 2026-02-01. [48] “CAPEv2: Malware configuration and payload extraction,” https:// github.com/kevoreilly/CAPEv2, accessed: 2026-02-01. [49] “Cuckoo sandbox is the leading open source dynamic malware analysis system,” https://sandbox.pikker.ee/, accessed: 2026-02-01. [50] “hybrid-analysis,” https://hybrid-analysis.com/, accessed: 2026-0201. [51] “Kaspersky threat intelligence portal,” https://opentip.kaspersky.com/, accessed: 2026-02-01. [52] “Recorded future triage,” https://tria.ge/, accessed: 2026-02-01.
Appendix B. Clustering Algorithm Algorithm 1 Artifact Clustering by Project Require: P : set of projects with artifacts P.A Ensure: Per-project confidence scores 1: for each project P ∈ P do 2: n←0 3: for each artifact a ∈ P.A do 4: if a.type = D IR then 5: n ← n + F ILE E XISTS(a) 6: else if a.type = E NV then 7: n ← n + G ET E NV(a) 8: else if a.type = P ORT then 9: n ← n + T CP C ONNECT(a) 10: else if a.type = P KG then 11: n ← n + F ILE E XISTS(a) 12: end if 13: end for 14: conf ← n / |P.A| 15: O UTPUT(P , conf ) 16: end for
Appendix C. DNS Protocol Details
[53] “Virustotal,” https://www.virustotal.com/gui/home/upload, accessed: 2026-02-01.
This appendix provides detailed technical documentation of our DNS-based exfiltration protocol. The protocol overview is presented in Section 5.2.
Appendix A. Sandbox Evasion Generations
C.1. Protocol Format
TABLE 12: Sandbox evasion generations. Each exploits a different realism gap between genuine endpoints and sandbox environments, requiring progressively more operationally expensive defenses (maintenance burden shown in parentheses).
Each exfiltration session begins and ends with marker queries: Start: s{sid}-start-{chunks}-{flag}.{domain} End: s{sid}-end-{chunks}.{domain}
Each data chunk uses the format:
Generation
Artifact type
Defense (cost)
1st: VM artifacts
Registry, CPUID, MAC Clock skew, TSC, cache behavior
Scrub indicators (one-time) Bare-metal / high-fidelity execution (one-time) Synthetic aging (periodic)
{hex1}.{hex2}.s{session}-c{chunk}.{domain}
Install & maintain AI ecosystem (ongoing
Payloads are compressed using Windows’ native LZNT1 algorithm via ntdll.dll’s RtlCompressBuffer(), achieving 60–80% size reduction. Compressed payloads use an 8-byte header: 4-byte magic (ZLIB), 4-byte original size.
2nd: Timing & emulation 3rd: Wear-and-tear realism 4th: AIprints AI-environment realism (ours)
Browser history, event logs & user activity Dirs, env vars, runtimes, ports, packages, model caches
where hex1 and hex2 are two 60-character hex labels (30 bytes each). Each DNS query carries 60 bytes of binary data. Chunks are sent to multiple Interactsh domains (default: 3) for redundancy.
C.2. LZNT1 Compression
TABLE 13: Compression ratios for typical payloads. Report Type SOTA (269 checks) Topics 253 single Trending 41 project
Original
Compressed
Reduction
27 KB 85 KB 12 KB
8 KB 25 KB 4 KB
70% 71% 67%
C.3. Timing and Reliability
D.3. Project-Level Clustering
The protocol uses 200ms inter-chunk delay, 2 retries per chunk per domain, and 3× redundancy on markers. For a 150-chunk report: Time ≈ 150 × 200ms × 2 = 60 seconds. Multi-domain merging recovers data when individual domains lose chunks.
Project-level clustering reproduces the same asymmetry observed at the artifact level. Core AI ecosystems such as CUDA, Claude Code, and Ollama exhibit substantially higher confidence scores on the reference workstation than on sandbox backends, while detections on sandbox platforms are primarily driven by generic Class artifacts rather than AI-specific tooling. Across all evaluated thresholds, the reference workstation consistently detects substantially more AI-project ecosystems than contemporary sandbox environments.
TABLE 14: DNS exfiltration protocol parameters. Parameter
Value
Bytes per query Compression Domains Retries per chunk Inter-chunk delay Collection service
60 (two 30-byte hex labels) LZNT1 (Windows native, 60–80% reduction) 3 (redundancy) 2 per domain 200ms Interactsh (open-source)
TABLE 17: Per-project detection: reference workstation vs. CAPEv2. Core AI tools show high confidence on the host and zero on the sandbox. Project
DNS exfiltration successfully retrieved results from all seven sandbox platforms (ANY.RUN, CAPEv2, Cuckoo, Hybrid Analysis, Kaspersky, Triage, VirusTotal) with 100% data recovery.
Appendix D. RQ2 Additional Experiments D.1. Threshold Sensitivity Table 15 confirms that the project-level discrimination gap is robust across detection thresholds. Even at the strictest threshold (50%), the reference host detects 10 projects vs. at most 5 for any sandbox backend.
Real Host
CAPEv2
nvidia/cuda-toolkit anthropics/claude-code microsoft/vscode-copilot ollama/ollama anaconda/anaconda huggingface/transformers openai/openai-python langchain-ai/langchain
60.0% 50.0% 50.0% 42.9% 28.6% 20.0% 20.0% 12.5%
0% 0% 0% 0% 0% 0% 0% 0%
Total Detected (≥15%)
19/41
3/41
D.4. VirusTotal Backend Heterogeneity
VirusTotal’s multi-backend architecture reveals substantial internal variation in project-level detection behavior. TABLE 15: Threshold sensitivity for project detection (TrendAcross the same probe binary, backend detection rates range ing 41). from 0% to 26.8% (Table 18), indicating that individual Bar Real Host CAPEv2 Best (vt v4) Min Gap backend environments expose different subsets of generic 5% 25/41 (61.0%) 5/41 (12.2%) 14/41 (34.1%) +26.9% AI-environment artifacts. However, despite this variabil15% 19/41 (46.3%) 3/41 (7.3%) 11/41 (26.8%) +19.5% ity, no VirusTotal backend contains any Class C artifact. 25% 16/41 (39.0%) 2/41 (4.9%) 8/41 (19.5%) +19.5% Thus, while project-level clustering varies across backend 50% 10/41 (24.4%) 1/41 (2.4%) 5/41 (12.2%) +12.2% instances, host-exclusive AI-environment artifacts maintain consistent sandbox-versus-host discrimination across the entire VirusTotal infrastructure.
D.2. Phase A cumulative installation Details
TABLE 16: Phase A cumulative installation results. Detection rises monotonically. “∆” counts artifacts that flipped from FAIL to PASS at each step. Step
Tool
T253
T41
∆
SOTA
T00 T01 T02 T02b T02c T03 T04 T05 T06 T07
Baseline Ollama Cursor Claude Code Gemini CLI HuggingFace PyTorch LangChain+OpenAI Jupyter VSCode+Copilot
0.6% 0.6% 0.7% 0.7% 0.7% 1.2% 1.4% 2.9% 3.9% 3.9%
0.7% 0.9% 1.1% 1.1% 1.1% 1.1% 1.1% 1.1% 1.1% 1.1%
— +2 +3 — — +21 +11 +59 +42 +1
5.1% 5.1% 5.1% 5.1% 5.1% 5.1% 5.1% 5.1% 5.5% 5.5%
TABLE 18: VirusTotal backend heterogeneity across identical probe submissions. Project-level detection rates vary substantially across backend instances, while Class C host-exclusive artifacts remain absent from all backends. “—” denotes data not collected. Backend 41 Proj 253 Proj 450 Single 41 Single vt v0 vt v1 vt v2 vt v3 vt v4 vt v5 vt v6
7.3% 0.0% 7.3% 7.3% 26.8% 0.0% 0.0%
11.5% 11.5% 2.4% 0.4% 11.9% — —
0.2% 0.2% 1.3% 0.2% 0.0% — —
0.07% 0.07% 0.36% 0.05% 0.07% 0.29% —
Appendix E. RQ4 Additional Results
E.2. Structural Attacker Check Details
E.1. RQ4 Probe Detection Under Class-C and All Defense TABLE 19: Probe detection under Class-C defense (8 discriminating artifacts only). T253
T41
SOTA
Table 20 provides detailed structural check verdicts across defense levels. Each row represents a Class-C artifact; each column shows the structural check outcome at that defense level. .claude passes at all levels because it is a genuine installation from the RQ3 experiment. All spoofed artifacts are correctly identified at every level. TABLE 20: Structural check verdicts (All strategy). ✓ = genuine, all others correctly flagged as spoofed/absent.
Level
Single
Proj
Single
Proj
VM
Artifact
Baseline L1 L2 L3 L4–L5
0.6% 0.7% 0.8% 0.8% 0.8%
82 83 113 117 117
0.7% 1.3% 1.6% 1.8% 1.8%
12 14 18 20 20
5.1% 5.1% 5.1% 5.1% 5.1%
.claude ✓ ✓ ✓ ✓ ✓ OPENAI_.. — Fmt Fmt Fmt Fmt Port 11434 — — NoHTTP NoHTTP NoHTTP torch ImpF ImpF ImpF Abs Abs .cache/hf NoMdl NoMdl NoMdl NoMdl Size
L1
L2
L3
L4
L5
✓ = genuine OK; Fmt = bad format; NoHTTP = no HTTP response; ImpF = import fail; Abs = absent; NoMdl = no models; Size = too small; — = not applicable.