Unmasking the MSIX Threat: A Defender’s Guide to Hunting Malicious App Installations

Listen to this Post

Featured Image

Introduction:

A recent Splunk blog post, “The Lost Payload: MSIX Resurrection,” has highlighted a sophisticated attack vector where threat actors abuse the MSIX application packaging format to bypass traditional security controls. This technique allows for the installation of malicious, developer-signed, or unsigned application packages, posing a significant risk to enterprise environments. This article provides a comprehensive threat hunting guide using Kusto Query Language (KQL) to detect these suspicious activities within Microsoft Defender.

Learning Objectives:

  • Understand the mechanics of MSIX and AppX package abuse for initial access and persistence.
  • Learn to implement and customize advanced KQL queries for hunting suspicious package installations.
  • Master the underlying Windows security logging and command-line auditing necessary for robust detection.

You Should Know:

1. Hunting for Suspicious PowerShell AppX Installations

This query forms the core of the hunt, identifying PowerShell processes used to install application packages.

let SuspiciousAppxInstalls =
DeviceProcessEvents
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any ("Add-AppxPackage", "Add-AppPackage", ".appx", ".msix")
| where ProcessCommandLine !contains "8wekyb3d8bbwe" // Common Microsoft Store Package Family Name
| where ProcessCommandLine !contains "cw5n1h2txyewy" // Another common Microsoft Package Family Name
| project ProcessTimestamp = Timestamp, DeviceId, DeviceName, ProcessAccountName = AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine;

Step-by-step guide: This query scours process creation logs for instances of `powershell.exe` or `pwsh.exe` where the command line includes keywords related to MSIX/AppX installation. The key to its precision is the exclusion of known, benign package family names (PFNs) associated with legitimate Microsoft Store applications. The `project` operator is used to shape the output, creating a clear timeline and context for each event.

2. Correlating with Developer-Signed Package Installation Events

This detection correlates a specific Windows Event Log with the suspicious process activity.

let DevSignedAppxPackageInstallation = DeviceEvents
| where AdditionalFields has "EventID=855"
| join kind=inner (
SuspiciousAppxInstalls
) on DeviceId
| where abs(datetime_diff('second', Timestamp, ProcessTimestamp)) <= 30
| project Timestamp, ProcessTimestamp, DeviceName, ActionType, ProcessAccountName, ProcessCommandLine, FileName, FolderPath, AdditionalFields
| sort by Timestamp desc;

Step-by-step guide: Windows Event ID 855 is logged when a developer-signed AppX package is installed. This query performs a temporal join, linking this installation event with the suspicious PowerShell process command we identified earlier. The `datetime_diff` function ensures we only correlate events that occurred within 30 seconds of each other, significantly reducing false positives and strengthening the alert’s confidence.

3. Detecting Unsigned AppX Package Installation Attempts

This query focuses on installations that bypass code signing altogether.

let AppXUnsignedInstallation = DeviceEvents
| where AdditionalFields has "EventID=603"
| extend Flags = parse_json(AdditionalFields).Flags
| where Flags == "8388608";

Step-by-step guide: Event ID 603, with the specific flag 8388608, indicates an attempt to install an unsigned AppX package. The `parse_json` function is used to extract the `Flags` field from the `AdditionalFields` column, which is stored in JSON format. This is a high-fidelity indicator of compromise, as unsigned packages should not be installed in a secured enterprise environment.

4. Final Unionized Query for Comprehensive Detection

This is the final, operational query that combines all detection logic.

DevSignedAppxPackageInstallation
| union (AppXUnsignedInstallation)

Step-by-step guide: The `union` operator is used to combine the results of the two primary hunting paths: the correlated events for developer-signed packages and the direct events for unsigned packages. This creates a single, comprehensive detection rule that security teams can deploy in their Microsoft Defender Advanced Hunting console.

5. Enabling Windows Event Logging for AppX

To ensure the underlying data is available, specific Windows auditing must be enabled.

Windows Command (Run as Administrator):

wevtutil sl Microsoft-Windows-AppXDeploymentServer/Operational /e:true

Step-by-step guide: This command uses the `wevtutil` (Windows Event Utility) to enable the `Microsoft-Windows-AppXDeploymentServer/Operational` event log channel. This is a prerequisite for generating Event IDs 855 and 603. Without this logging enabled, the KQL queries will return no results. This should be deployed via Group Policy across all enterprise endpoints.

6. Auditing for PowerShell Process Creation

Ensuring command-line logging for PowerShell is critical.

Windows Command (via Group Policy):

Navigate to Computer Configuration > Administrative Templates > System > Audit Process Creation. Enable “Include command line in process creation events”.
Step-by-step guide: This Group Policy setting is essential for the initial part of the query to function. It ensures that the full command-line arguments passed to `powershell.exe` are captured and sent to your security information and event management (SIEM) system or Microsoft Defender. Without this, the `ProcessCommandLine` field will be empty.

7. Alternative Hunting with Sysmon

For environments using Sysmon, this configuration provides similar visibility.

Sysmon Configuration Snippet (Event ID 1):

<RuleGroup name="" groupRelation="or">
<ProcessCreate onmatch="include">
<CommandLine condition="contains">Add-AppxPackage</CommandLine>
<CommandLine condition="contains">Add-AppPackage</CommandLine>
<CommandLine condition="end with">.appx</CommandLine>
<CommandLine condition="end with">.msix</CommandLine>
</ProcessCreate>
</RuleGroup>

Step-by-step guide: This XML snippet can be added to your Sysmon configuration file. It instructs Sysmon to log process creation events (Event ID 1) where the command line contains the specified keywords. This provides a data source alternative to Microsoft Defender’s `DeviceProcessEvents` table, allowing for detection in hybrid or multi-vendor environments.

What Undercode Say:

  • Proactive Defense is Non-Negotiable: The MSIX attack vector is a stark reminder that attackers continuously evolve, abusing trusted application frameworks. Relying solely on signature-based AV is insufficient; proactive hunting using advanced queries is essential.
  • Context is King for High-Fidelity Alerts: The brilliance of the provided KQL lies in its use of correlation and exclusion. By filtering out known-good PFNs and joining process events with installation logs, it transforms a noisy potential alert into a precise, actionable incident.

The analysis reveals a mature detection engineering methodology. Instead of creating a single, broad query, the approach is modular, building blocks of detection that are then correlated. This makes the logic easier to debug, maintain, and extend. For instance, other suspicious PFNs can be added to the exclusion list as they are discovered. This technique represents the cutting edge of modern security operations, where depth of data and quality of analytics trump volume of alerts. The dependency on specific Windows event logging also highlights the critical need for a robust and comprehensive logging strategy as the foundation of any security program.

Prediction:

The abuse of MSIX and similar application packaging formats is poised to increase significantly as software distribution continues to shift towards containerized models. We predict that within the next 12-18 months, this technique will be automated and integrated into popular penetration testing frameworks and malware droppers, making it a common entry-point for ransomware and state-sponsored actors. This will force a paradigm shift in endpoint protection, moving application control policies from a best practice to a mandatory control. Vendors will respond by enhancing their EDR solutions to deeply introspect package contents at runtime, not just during installation.

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Benjamin Zulliger – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky