Trust Propagation Failure in the Recursive-Execution Path of Nested Archives

Windows relies on provenance-related metadata to distinguish files that arrive from untrusted sources such as the web or email. In Windows environments, origin information associated with downloaded content and new technology file system (NTFS) alternate data streams (ADS) remains important for both security enforcement and forensic interpretation [1, 2]. When that provenance is dropped somewhere in the tool chain, downstream trust decisions can become less reliable.

Modern intrusion campaigns increasingly distribute payloads inside archives and use obfuscation, packing, or multi-stage delivery to complicate inspection. Recent work on malware detection, fileless malware, and packing-aware analysis shows that transformed or nested payloads can reduce the effectiveness of purely static inspection and increase analytical complexity [3-6].

Archive viewers add a second problem. They encourage a convenience workflow: browse the archive and double-click an item to run it. Recent usable-security research shows that user decisions are strongly shaped by interface cues, risk indicators, usability preferences, and habituated behavior, which can weaken the protective value of warnings when execution appears routine [7, 8].

In early 2025, major archivers shipped patches to preserve Mark-of-the-Web (MoTW) for nested archives. We examine patched 7-Zip v24.09 and Alzip v12.30 and show that the protection is concentrated in the explicit extraction routine, not the archive-viewer execution routine.

In this paper, recursive-execution path refers specifically to the workflow in which a user opens a nested archive inside the archive viewer and directly activates an inner payload, causing the application to materialize the file into a temporary directory (TEMP) and execute it. This term is used to distinguish that workflow from ordinary recursive extraction, where files are explicitly unpacked to a user-selected destination.

Despite recent advances in malware analysis, packing-aware detection, and multi-stage threat modeling [3-6], it remains unclear whether all file-creation workflows inside archive software preserve provenance consistently. Most prior work has focused on malicious delivery, detection, and reconstruction at a broader level, but less attention has been given to execution-oriented viewer paths that users can reach through ordinary browsing behavior. This leaves an important research gap: a patch may appear effective on the main extraction routine while still missing a secondary file-creation path.

This study, therefore, asks whether patched archivers preserve MoTW equally across explicit extraction and recursive-execution paths, and whether any residual gap can be explained by path-specific implementation differences. The paper makes three contributions. First, it experimentally verifies the residual gap using a controlled depth-3 nested archive. Second, it distinguishes the observed workflows using process attribution and call-stack evidence. Third, it proposes a more robust OS-delegated mitigation strategy that targets the specific file-creation point identified in the experiments.

3.1 Attack scenario: Depth-3 recursive execution

We model a depth-3 scenario in which an attacker wraps an executable inside multiple nested archives to exploit both scanner depth limits and provenance loss. The user downloads an outer ZIP from the web, which assigns ZoneId = 3. The user then navigates into the inner ZIP within the archiver UI and finally double-clicks the payload executable.

The recent patches cover the first transition: when the archiver materializes the inner ZIP into a temporary location, it propagates Zone.Identifier correctly. The vulnerable step is the second transition: when the user activates the payload inside the inner ZIP, the archiver extracts the executable into a random TEMP subdirectory and launches it.

Figure 1. Code path divergence model

This section is an analytical frame rather than a statement of directly observed fact. The experiments below establish differences in file creation, call-stack traces, and Zone.Identifier preservation. The code-path divergence explanation is presented later as an interpretation consistent with those observations. Figure 1 illustrates a model of hypothetical paths divided into explicit extraction and recursive execution.

3.2 Architectural divergence hypothesis

We hypothesize that archivers implement two distinct internal pipelines: a hardened extraction pipeline used for explicit "Extract" actions, and a legacy viewer execution pipeline used for double-click launches. Security patches targeted the primary extraction routine, while the temporary-execution routine remained unchanged.

3.3 Comparative analysis

Table 1 defines the comparison frame between the two workflows and clarifies why the same archive content can produce different trust outcomes depending on user interaction.

Table 1. Technical and security characteristics of explicit extraction and recursive execution paths

3.4 Trust washing in the temporary directory

When the recursive-execution path writes an executable into TEMP without Zone.Identifier, Windows treats the object as a locally created file. The directory itself is not inherently trusted, but the OS loses the "untrusted origin" marker that normally triggers friction at launch. At that point, the payload has been laundered: its content is unchanged, yet its provenance signal is gone.

5.1 Structural limits of manual propagation

Most vendor patches implement MoTW propagation as a post-write copy: after writing the primary stream, the tool creates Zone.Identifier and copies the parent’s metadata. This approach is brittle. Archivers create files through many entry points (toolbar extraction, drag-and-drop, context menu, CLI, viewer execution), and it is easy to miss a path. Even when developers remember the patch site, stream writes can fail independently of the primary file write, leaving a "clean" executable behind with no obvious error.

The experimental evidence does not prove that every archive workflow is vulnerable. Rather, it shows that the specific recursive-execution path observed in this study bypasses the patched explicit-extraction routine. For that reason, the architectural proposal below is presented not as a general redesign mandate, but as a targeted response to the file-creation path identified in the experiments.

5.2 Proposed delegation model via IAttachmentExecute

We propose moving from scattered ADS manipulation to the OS delegation model provided by IAttachmentExecute. The application should report provenance and allow Windows attachment services to apply policy and attach the appropriate trust evidence. This design centralizes decision making, reduces path-specific patchwork, and aligns with recent evidence-handling work that emphasizes preserving context and reference data across transformations [9, 12].

Because the observed gap occurs after temporary-file creation in the recursive-execution routine, the mitigation must target that same point in the workflow. In this sense, IAttachmentExecute::Save() is proposed as a direct remedy for the missing post-write trust-marking step identified in the experiments, not as a solution disconnected from the evidence.

5.3 Trust inheritance via SetReferrer

SetReferrer matters in nested archives. When the payload is derived from Inner.zip that already carries ZoneId = 3, the tool can call SetReferrer(path_to_inner_zip) and set an appropriate source (e.g., about:internet or the original URL). Windows can then apply a consistent zone decision to the derived executable even though it resides in a local TEMP (Figure 3).

Figure 3. IAttachmentExecute delegation workflow for derived files

5.4 Implementation strategy: Save() vs. Execute()

IAttachmentExecute exposes two policy entry points: Save() and Execute(). For archive viewers, Save() is a better fit. Execute() can launch the file but may interfere with the archiver’s UX and error handling (password prompts, progress UI, and custom handlers). Table 6 evaluates implementation options for repairing the specific gap observed earlier.

Table 6. Comparison of IAttachmentExecute methods for policy application in the recursive-execution workflow

5.5 Recommended implementation logic

A practical implementation integrates policy delegation into the viewer-execution routine (e.g., OnOpenItem): create the temporary file, delegate policy with IAttachmentExecute::Save, then launch using the existing execution pathway. The following C++-style pseudocode illustrates the flow.

// 1. File generation (existing logic)

std::wstring tempPath = CreateTempFile(payloadData);

// 2. Policy delegation (new security logic)

IAttachmentExecute* pAE = nullptr;

HRESULT hr = CoCreateInstance(CLSID_AttachmentServices, nullptr, CLSCTX_INPROC_SERVER,

                              IID_IAttachmentExecute, (void**)&pAE);

if (SUCCEEDED(hr)) {

  pAE->SetLocalPath(tempPath.c_str());

  pAE->SetSource(L"about:internet"); // or the original URL

  pAE->SetReferrer(parentArchivePath.c_str()); // e.g., Inner.zip

  pAE->Save();

  pAE->Release();

}

// 3. Execution (existing logic)

ShellExecute(nullptr, L"open", tempPath.c_str(), nullptr, nullptr, SW_SHOWNORMAL);

5.6 Practical relevance for engineering and security teams

In real-world software use, many users do not extract nested content manually. They browse the archive, inspect inner objects, and launch files directly from the viewer UI. For engineering teams, the finding matters because patch verification limited to the primary extraction function may leave secondary execution-oriented paths untested, even though those paths are reachable through ordinary user behavior. For security teams, the practical consequence is not that a universal SmartScreen bypass has been proven, but that provenance-based friction can be reduced when origin marking is silently lost during transient file creation.

5.7 Limitations and trade-offs

Policy delegation introduces overhead. Creating COM objects and calling Save() for every previewed file can add latency when users browse archives containing thousands of small objects. Tools can mitigate this by applying delegation selectively to executable or script-capable extensions (.exe, .msi, .js, .vbs, .doc*).

A second concern is provenance spoofing: a malicious tool could set a benign source string. Attachment services are not a full trust oracle; Windows still applies additional checks through SmartScreen and antivirus engines. The delegation model is meant to reduce accidental provenance loss, not to certify a tool as trustworthy.

This study also has boundary conditions that should be stated explicitly. The evidence is limited to patched 7-Zip v24.09 and Alzip v12.30, a depth-3 ZIP nesting structure, and a single benign payload under one Windows 11 desktop configuration. These constraints are appropriate for a controlled proof-of-phenomenon experiment, but they do not establish how frequently the same gap appears across other archive formats, greater nesting depths, alternate payload types, or different vendor implementations.