Exploring MSIX Threat Landscape

Exploring the MSIX Threat Landscape: VFS Abuse, DLL Hijacking, and AppDomainManager Injection

Speakers: Teruki Yoshikawa and Syogo Hayashi — NTT Security Holdings

Conference: NorthSec 2025 — May 15–16, 2025, Marché Bonsecours, Montreal

Watch on YouTube: https://www.youtube.com/watch?v=9mWdxsyAm-Q

Reading time: ~8 minutes

TL;DR

SOC analysts Teruki Yoshikawa and Syogo Hayashi of NTT Security Holdings examined how attackers are evolving beyond known MSIX-based malware delivery to exploit deeper Windows internals. The talk covers Virtual File System (VFS) redirection abuse, PSF Fixup DLL misuse, MSIX modification packages, and an autoupdate persistence mechanism — four novel attack categories that bypassed Microsoft Defender for Endpoint in April 2025 testing. Detection sigma rules and policy-based countermeasures are provided for defenders.

Introduction

The Windows MSIX packaging format, introduced in 2018 as a successor to MSI and APPX, was designed to simplify application deployment and improve compatibility on Windows 10 and later. But compatibility features built into the format — particularly the Virtual File System (VFS) and Package Support Framework (PSF) — have become a growing attack surface. Threat actors including criminal MaaS operators running RedLine, Lumma, and Raccoon stealers began exploiting MSIX packaging as early as 2021. By 2025, the format has become a well-understood malware delivery vector.

At NorthSec 2025, Yoshikawa and Hayashi moved the conversation forward: rather than documenting known abuse patterns, they presented four novel attack techniques they developed proactively — methods they anticipate attackers will adopt next. Their testing against Microsoft Defender for Endpoint found that only one of the four techniques triggered any alerts, making this research directly relevant to defenders building detection logic today.

How MSIX Works and Why It's Abusable

MSIX packages are ZIP archives containing application binaries, configuration metadata, and code-signing information. Two compatibility mechanisms make the format flexible but also exploitable.

The Virtual File System (VFS) redirects file access from well-known Windows directories to paths inside the MSIX package. When an application inside an MSIX container attempts to load System32\VC10.DLL, for example, the OS transparently redirects the access to VFS\SystemX64\VC10.DLL within the package. This redirection applies not just to the packaged application, but to any process running inside the MSIX container — including system binaries.

The Package Support Framework (PSF) enables legacy executables to run inside MSIX containers without source code modification. PSF can execute arbitrary PowerShell scripts before or after application launch, and can inject arbitrary DLLs into a process via PSF Fixup DLLs. Attackers have already weaponized PSF's scripting capability extensively: many observed campaigns deliver base64-encoded malware payloads via PSF-triggered PowerShell.

▶ Watch: MSIX fundamentals and VFS mechanics (2:00)

Known Attack Patterns: The Baseline

Before introducing their novel techniques, Yoshikawa and Hayashi reviewed the existing MSIX threat landscape. The attackers behind bat loader campaigns and various infostealer families favored a third-party tool called Advanced Installer, which simplifies MSIX creation and signing far beyond what Microsoft's native tooling provides.

Two patterns dominate current campaigns. In the first, a malicious executable serves as the application payload — when the MSIX is installed and launched, the malicious binary executes directly via Advanced Installer. In the second and more common pattern, PSF is used to execute a malicious PowerShell script before or after a legitimate decoy application. Because the malware runs in a PowerShell process rather than as a standalone binary, security products have difficulty attributing the behavior. These campaigns have been observed delivering RedLine, Lumma, and Raccoon stealers across a wide range of targets.

▶ Watch: Known MSIX malware campaigns and patterns (8:01)

Four Novel Abuse Techniques

Yoshikawa and Hayashi categorized their new research into four attack techniques. Their testing used a Windows 10 virtual machine running VMware and a payload that simply launched calc.exe. The evaluation target was Microsoft Defender for Endpoint as of early April 2025.

1. MSIX-Based AppDomainManager Injection

AppDomainManager injection is a known .NET technique in which a crafted configuration file causes a .NET host process to load an attacker-controlled assembly. The twist in this MSIX variant is delivery mechanism: because VFS redirects file access for any process running inside the MSIX container, it can redirect configuration file lookups — not just DLL loads — to files inside the package.

By using UpdateProcSetAttribute to execute a system-resident .NET binary (such as tzsync.exe) inside the MSIX container, the VFS becomes active for that binary. The attacker-controlled .config file inside the package is then loaded transparently, triggering assembly loading and arbitrary code execution within the system process. A process tree would show PSFLauncher64.exe as parent, with both a PowerShell instance and the target system binary running as children inside the MSIX container.

This technique produced no alerts in Defender for Endpoint testing. The researchers noted that EDRs typically do not log configuration file load events, making behavioral detection challenging. Instead, they suggest alerting on file write events into the package directory combined with subsequent .NET binary execution from within an MSIX container.

▶ Watch: AppDomainManager injection via VFS (12:00)

2. VFS-Based DLL Hijacking for MDE/UAC Bypass

The VFS redirection mechanism is broad enough to affect any process executing inside the MSIX container, including Windows system binaries brought in via UpdateProcSetAttribute. This allows an attacker to place a malicious DLL at a VFS path that shadows a legitimate system DLL, causing the targeted binary to load the attacker's version.

The researchers demonstrated using this mechanism to perform AMSI bypass by loading a malicious amsi.dll into a PowerShell process running inside the container, and UAC bypass by targeting an auto-elevating process such as CleanManager.exe with a similarly hijacked DLL. Both scenarios exploited the container execution environment as a privilege boundary crossing aid.

3. MSIX Modification Package Abuse

MSIX modification packages are a legitimate feature that allows a publisher to alter the behavior of an existing installed MSIX application — for example, adding configuration or overriding assets. Crucially, the certificates for the target application and the modification package do not need to match. An attacker can therefore create a modification package signed with an entirely different certificate and use it to inject malicious files into the VFS of a trusted, already-installed application.

The speakers drew a parallel to Ocean Loaders, a threat actor that used MST files (the MSI equivalent of modification packages) to execute malicious DLLs while disguising them as part of a legitimate installer workflow. The MSIX modification package approach enables an equivalent attack path against applications distributed via the Windows Package Manager ecosystem.

▶ Watch: Modification package technique and Ocean Loaders parallel (16:01)

4. Autoupdate-Based Persistence

The autoupdate mechanism in MSIX allows applications to check for and apply updates from a remote server. When an application is installed via an AppInstaller file, Windows automatically triggers update checks every eight hours in the background — without user interaction. Attackers can exploit this to deliver malicious payloads post-installation, potentially evading inspection at install time.

Yoshikawa demonstrated a fully packaged MSIX that uses a PSF Fixup DLL to register a Windows background task with a 15-minute time trigger. The background task checks an attacker-controlled infrastructure for updates, installs any available update components, and executes delivered code — all without user interaction. Update check traffic originates from svchost.exe, making it appear benign. The initial MSIX can contain only a legitimate decoy application at install time, with the malicious payload delivered only after initial deployment.

▶ Watch: Autoupdate persistence mechanism (18:00)

Countermeasures

The speakers provided three defensive layers:

Sigma-based detection rules targeting two specific behaviors: DLL loads from VFS paths into system binaries (to catch MDE/UAC bypass via VFS), and file write events into MSIX package directories combined with subsequent .NET binary execution (to catch AppDomainManager injection). The latter is necessary because configuration file load events are not logged by current EDR implementations.

App Control (formerly Windows Defender Application Control) can restrict which MSIX packages are permitted to execute. Policy can be scoped by package family name — retrievable via Get-AppxPackage — or by the issuing certificate authority. Certificate-based policies are more scalable for enterprise environments with many managed applications.

Policy CSP settings control whether users can install packaged applications at all. The Application Management Policy CSP can prevent non-administrator users from installing packages, and the Allow All Trusted Apps setting can be disabled to block sideloading — preventing the initial MSIX infection vector before it reaches the execution stage.

▶ Watch: Detection and policy countermeasures (22:01)

Notable Quotes

"We have researched new attack techniques that attackers would use in the future... only MDE bypass was detected, and all the other techniques triggered no alerts." — Teruki Yoshikawa

"By executing a system binary inside the MSIX container, VFS will also apply to that binary. This allows us to perform AMSI bypass by loading amsi.dll into PowerShell, or even perform UAC bypass by loading a custom DLL into an auto-elevate process such as CleanManager." — Teruki Yoshikawa

"The malicious contents can be delivered after installation. This might help avoid suspicion from both users and security products at the time the MSIX file is first installed." — Teruki Yoshikawa

Key Takeaways

1. VFS is a DLL hijacking primitive. Any process — including Windows system binaries — that runs inside an MSIX container is subject to VFS redirection, enabling DLL hijacking and configuration file injection without touching the filesystem outside the package.

1. MSIX modification packages cross certificate trust boundaries. A malicious modification package signed by an attacker-controlled certificate can override the VFS contents of a trusted, installed application.

1. Autoupdate enables post-deployment payload staging. MSIX's built-in update mechanism can be abused to deliver clean packages at install time and drop malicious code later, potentially evading initial-access security controls.

1. Current EDR telemetry has gaps. Configuration file load events are not logged by Defender for Endpoint, making AppDomainManager injection via VFS invisible to signature-matching detection without additional file write monitoring.

1. Defense requires layered policy. Combining Sigma rules on file write events, App Control certificate policies, and Policy CSP sideloading restrictions provides the most complete coverage. No single control addresses all four attack categories.